Responsibilities and roles | DevOps

Responsibilities & roles

In DevOps, people should work together closely, and the team should have the required people to make the project successful. So, a well-balanced set of skills and competences are required to be successful as a team. Every team needs to have expertise in the required competences. No one needs to be the expert in all competencies, if at least one person in the team is the expert for each relevant competency. Or, if not present in the team, this competency should be readily available from a system team, shared services, guild, center of expertise, etc. Besides this, everyone in DevOps should understand and adopt the six DevOps principles and practices.



Working in cross-functional DevOps teams also means that all team members should be prepared to take on any of the roles if necessary. For instance, a developer must be willing to take on a testing role if the need arises. Especially if there is time pressure on the testing activities. On the other hand, testers should be willing to assist other team members in their activities where they can according to the project's needs. This may require specific technical skills and knowledge from a tester. Working together is a two-way street and requires the willingness to learn from each other.

And always keep in mind: Collaboration is about communication, communication is about transmitting, receiving, understanding and acting. Without proper communication a team won't work as a team. Good collaboration starts with psychological safety. Psychological safety is being able to show and employ oneself without fearing negative consequences of self-image, status or career [Kahn 1990]. 

When talking about responsibilities & roles in DevOps in respect to quality & testing, we advise to apply the following three guidelines (for a detailed description refer to "Continuous improvement"):

  • Create quality awareness with all people involved.
  • Integrate QA & testing activities in all DevOps activities.
  • "Integrate" QA & testing activities in all people involved.

In the following sections you will find a description of common roles, an alternative competence model and the changing role of testers.

Common roles

While there is no "magical" structure for DevOps, it is important to understand the roles and responsibilities of the DevOps people. Keep in mind that the roles and responsibilities of one DevOps implementation differ from the other. In the table below you will find an example of some common roles. If you want to use these, you can adapt them to your own organization.

When we talk about a role, we mean that a person can adopt this role in the team whenever this is necessary. So, a person can have multiple roles sequentially or even in parallel. In a DevOps team, it is not common for people to have specific functions, meaning that they only have responsibilities for that function. Instead, the team as a whole has all responsibilities and the team members support each other by adopting the role(s) that they are capable of doing at the moment such a role is required to achieve the team's goals.

Please note that in the broad definition of a team, the product owner and the Scrum master / Agile coach are also seen as team members. These roles have specific responsibilities and cannot be performed by just any other team member.

In this example, a distinction is made between common responsibilities and QA & testing responsibilities. This is done to emphasize that QA & testing activities are integrated with all development roles and activities.

Responsibilities & roles in DevOps

Common responsibilities
QA & Testing responsibilities
Business Analyst
  • Co-author user stories
  • Provider of clarification of user stories
  • Provider of information about non-functional characteristics (e.g. security, performance, usability)
  • Prioritizer of user stories
  • Sharer of knowledge
  • Ensurer that user stories are clearly understood (INVEST)
  • Reviewer of acceptance criteria and test cases
  • Organizer of quality risk analysis
  • Participator in acceptance test
  • Evaluator of test results
  • Author of acceptance criteria
Developer (programmer) / software engineer
  • Co-author user stories
  • Author of code
  • Collaborator with product owners and testers
  • Responsible of checking in code into a version control system
  • Author of unit/system tests
  • Automator of unit/system tests
  • Executor of unit/system tests
  • Evaluator of test results
  • Code review
Quality engineer / Quality architect / Tester / End-to-end test manager / SDET
  • Co-author user stories
  • Supporter of coding
  • Supporter of operations tasks
  • Reviewer of user stories
  • Moderator of risk analysis sessions
  • Supervisor in applying quality measures
  • (Assistant) author of test cases and test data
  • Executor of tests
  • Author and maintainer of automated tests
  • Evaluator of test results
  • Communicator of status of quality and risks, and of necessary mitigation actions
Operations manager / Operations person / Operator
  • Co-author user stories
  • Provider of information about non-functional characteristics
  • Deployer of software
  • Responsible for run
  • Technical and performance monitoring
  • Capacity and availability management
  • Environment manager (e.g. of test environments)
  • Author of non-functional tests (e.g. performance, security and maintainability)
  • Participator in writing regression test cases
  • Executor of tests
  • Evaluator of test results
  • Monitoring production
System architect
  • Designer of system architecture
  • Aligner with enterprise architecture
  • Provider of information about non-functional characteristics
  • Co-author user stories
  • Participator in system tests
  • Evaluator of test results
  • Contributor of standards for the team
Scrum master, Agile coach or Agile lead
  • Facilitator
  • Eliminator of roadblocks and impediments
  • Protector of the team
  • Guardian of the DevOps culture
  • Propagator of qa & testing awareness and practices
  • Support team members in their quality engineering activities
Product owner
  • Input to user stories
  • Input to non-functional characteristics (e.g. security, performance, usability)
  • Prioritizer of user stories
  • Sharer of knowledge
  • Responsible for the product vision
  • Ensurer that user stories are clearly understood (using "INVEST")
  • Input to and review of acceptance criteria and test cases
  • Participator in acceptance test
  • Evaluator of test results
  • Supporter in writing user stories
  • Provider of clarification of business processes
  • Sharer of knowledge
  • Co-author user stories
  • Participator in acceptance test
  • Evaluator of test results

Alternative competence model

The DevOps Agile Skills Association (DASA) has described a DevOps Competence model with the essential skills needed in DevOps. DASA has identified four skill areas, and eight knowledge areas, and outlined the expected behavior or knowledge for each of these twelve capabilities [DASA 2019].

The skill areas are:

  1. Courage
  2. Teambuilding
  3. DevOps leadership
  4. Continuous improvement

The knowledge areas are:

  1. Business value optimization
  2. Business analysis
  3. Architecture & design
  4. Programming
  5. Continuous delivery
  6. Test specification
  7. Infrastructure engineering
  8. Security, risk & compliance

Some more information on this model is presented in Skills matrix.

The work of the test professional changes

Some people were originally trained to work in the function of tester or test professional. We see a shift from functions to roles in DevOps; any member of DevOps will do some testing activities over time (actually the Scrum guide states there are no functions, just roles [Scrum 2017]). The traditional test professionals will see a change in demand for their work. DevOps requires people with quality and test knowledge to be involved in the development project continuously right from the start, as well as other team members to be involved in, and take responsibility for, testing tasks. Of course, this requires adequate training and coaching. Also, the quality measure "pairing" will enable this because when people work together on the same task they will learn on the job.

To produce quality, there is an increasing need for the whole team to focus. Testers are therefore no gatekeepers or able to "assure" quality is tested in the product. Instead, quality is increasingly built in from the start through collaboration and continuous involvement.

Test professionals in DevOps must have technical knowledge of the software they are testing and need to understand the impact on automation as well as the functional implications. Some iterations may be development heavy, some automation heavy, some test heavy; a tester in DevOps needs to be adding value in all instances.

This change in role requires specific skills. More about these skills.