Area of responsibility of a test manager within the agile process?

Question

At first glance, Scrum doesn't say anything about how to test and who should take responsibility for it.

Sure, it is always said that in Scrum the team is testing. But who bears the responsibility?

If you look at the standards of the ISTQB, a test manager has tasks like

• the creation of a test team,
• the creation of a test concept,
• Creation of test cases by the testers,
• Creation and execution of test cases by the test team,
• and much more (see below)

How does an agile test process fit into this, which doesn't prescribe all this?

The testers in the team - or rather the development team itself - are now confronted with these things and the competence of the testers grows because they have to cover the entire test pyramid. This means that the testers are now responsible for unit, service and system testing and have to master testing, domain and coding, as they should automate all tests, if not have to.

The question is which test organization, apart from agile testing the test manager should take over. According to ISTQB, he takes over the conception of the processes and the management of the testers.

But the Scrum process does not define exactly that!

Even after studying the roles of Scrum, it is not clear: Who takes over the tasks of the test manager? or how they are distributed? In order to answer the questions, it is first necessary to determine which tasks a test manager performs in the classic test and quality assurance process.

According to the International Software Testing Qualifications Board (ISTQB), the certification body for testers, the tasks and areas of application of the test manager go beyond the control of the test project. He manages the test department or the test team and thus the resources for the tests.

He prepares reports, escalates to development, technical department and project management, assesses test projects, enforces compliance with the company's quality processes and procedures, procures the testing tools for the organization and reviews the test plans and test cases.

Are there clear guidelines on how the test manager should organize himself inside or outside the agile process?

I ask this question consciously here and not in the Scrum area!

I find that these questions are not a classic Scrum topic in themselves, but a special topic between both aspects, but more in the direction of test management organization.

Is this division of tasks, therefore, more strategic and operational?

Answer 1

One of the foundation principles of the Agile Manifesto is self-organizing teams:

The best architectures, requirements, and designs emerge from self-organizing teams.

PS: It includes processes

And the Scrum Guide (which came before the Manifesto) talks about it too:

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

Which means that the team is the single group responsible for organizing the processes by which the product will come to be.

In a nutshell, the reason for this is that the team is the group closer to the development work. They are the ones with the expertise on the domain and the problem - and the ones able to build solutions. All other stakeholders serve to assist the team in their work, giving support in specific areas, enabling the team to focus on building value-adding solutions.

Given that, it is clear that the question above is a specific instance of a more general question:

Who is the responsible for any given development activity?

And you have two answers:

If we are looking from the perspective of someone outside the Development Team, the answer is The Team. They are a self-organizing group aimed at creating a product (which may include certain documents and other artifacts).

If we are looking from the perspective of someone inside the Development Team, the answer is Whomever the Team decided. As self-organizing, the team members have to develop internals channels of communication and decision-making to reach the collective goal: The product.

In one team certain tasks may be usually carried out by two people; while in another the same may be carried out by a single person.

In one team certain activity may be carried out always by the same people; in another there may be rotation.

In the end, context will drive decisions, as stated on the Context-Driven Testing principles:

• The value of any practice depends on its context.
• There are good practices in context, but there are no best practices.
• People, working together, are the most important part of any project’s context.
• Projects unfold over time in ways that are often not predictable.

PS: ISTQB stands for International Software Testing Qualifications Board, it is not "the certification body for testers", it is "a certification body for testers". It does not hold any authority whatsoever, per se. There are good practices and ideas that ISTQB promote and there are good practices and ideas that ISTQB do not promote. It is your responsibility as a professional to make judgments about the approaches to be taken in certain contexts, even if it means going completely in opposite direction that other people would take.

Answer 2

Scrum indeed doesn't define the role of a test manager. Nor does it define the roles of the janitor, the CEO or a personal assistant. That doesn't mean that an organization must do without them, but rather that those roles are not involved in the process of creating a product.

In an organization that aims to be agile, with self-organizing and empowered teams, some responsibilities shift from the managers to the team. These responsibilities are essentially the division and allocation of work.

The thing that mostly has to change when comparing agile and traditional organizations is the leadership style of a manager. Where a directive leadership style might work in a traditional organization, an agile organization calls for a facilitating leadership style, as the manager has no say in the day-to-day work but has to provide the framework (high-level processes) and facilitate the teams to be able to do the work.