Test Management as part of agile Software Projects

Project management expert Wiebke Bergholz explains what test management is, how it's structured, and why it is an important part of agile project management.

In recent years, test management has become an increasingly important part of software projects. A holistic test management not only saves time and money in the long run, but also leads to satisfied users and developers. But what exactly is test management and how can it be established in agile software projects?

Content:

1. Test management vs quality assurance
2. Test management goals
3. The four test levels in software projects
4. Error costs: The rule of ten
5. How test management works in agile projects

The International Software Testing Qualification Board (ISTQB) defines test management as

"The conception, planning, estimation, monitoring, reporting, control and completion of test activities."

This definition shows that test management covers the entire test process - from planning the entire test process, to specification and execution of individual tests, to the documentation of results and holistic test reporting.

Test management vs. quality assurance

Test management should not be confused with quality assurance. Often, both terms are used interchangeably. However, even if both topics are closely related, there are still differences.

Quality assurance is not exclusively responsible for identifying and eliminating error conditions, but also analyzes the causes for non-compliance with requirements. The continuous quality assurance serves to optimize all processes and thus also supports an appropriately and flawlessly executed test management.

Test Management Goals

Back to Overview

One of the goals of test management is to define a standardized approach for testing and test reporting within a software project. A standardized approach can make the respective test activities more comprehensible, and consistent reporting can also provide more transparency of the test progress in the project.

The goals of the testing itself depend strongly on the respective test level in which testing takes place, i.e. on the respective level of the system architecture. Thus, the primary goal of component testing is to identify as many error states of the respective individual components as possible. Meanwhile, the primary goal of acceptance tests is to prove that both the functional and non-functional requirements of the stakeholders have been implemented in the overall system.

The four test levels in software projects

Back to Overview

Component tests

The individual components of a software are tested on the lowest level of the system architecture by the developer themselves. It is to be determined whether the component was converted according to the specifications.

Integration tests

The interaction of all subsystems is checked during the integration tests. Error states of the interfaces between individual components can be uncovered here.

System tests

The integrated overall system is tested. The goal is to determine whether all functionalities have been implemented according to the functional and non-functional requirements.

Acceptance tests

The acceptance test represents the final acceptance of the customer or user. A final test is therefore carried out before the system is put into operation.

Error costs: The rule of ten

Back to Overview

According to "The rule of ten" of error costs, the later an error is discovered in the course of the project, the higher the costs for correcting it. Specifically, the rule states that the cost of an undetected error increases tenfold from project phase to project phase.

This also means that the correction of error conditions that are only discovered during acceptance tests is significantly more cost-intensive than if they had already been detected during requirements gathering or software development.

For this reason alone, it makes sense to involve a test manager or suitable test resources at an early stage in order to identify possible error states during the requirements recording. An early consideration during the development of the software can also ensure that not only the component tests take place but that suitable system and integration tests can be started in time.

How test management works in agile projects

Back to Overview

Agile software projects differ significantly from classic projects, as they not only focus more and more on the needs of the customer, but also allow for shorter development cycles and more frequent releases through regular iterations. For these reasons, close cooperation between the individual team members is essential, especially between developers and testers.

Due to the regular iterations during an agile project, both development and testing of the developed components have to take place continuously and in close coordination with each other. The responsibility for planning and controlling the test activities is often shared between the team members. In order to ensure such collaboration within a team, it's often necessary to rethink how things are being done.

The following points can support this:

Creation of a "Definition of Ready"

A "Definition of Ready" - DoR for short - is defined and agreed to by the product owner and the entire team. The DoR is a checklist with various criteria that must be met to include a requirement in a sprint. The INVEST rule is often used for this purpose:

• Independent
  

  The requirement stands on its own and is independent from other requirements.

• Negotiable

  The content of a requirement is negotiable and is described in detail by the team step by step.

• Valuable

  The requirement makes sense and offers added value to the user of the software.

• Estimable

  The effort of the requirement must be estimated by the development team.

• Small

  The scope of a requirement should be appropriate so that it can be realized within an iteration or sprint.

• Testable

  The requirement has acceptance criteria and can be tested using these criteria.

Creating a "Definition of Done"

The "Definition of Done" - DoD for short - is also agreed upon by the product owner and the team. The DoD consists of criteria that must be met for a requirement to be considered "done". These criteria can be different in each project team but should include which tests are performed (and must be completed successfully). A DoD aims to build a common understanding of the quality criteria within the team. This ensures that each team member strives for the same quality goals and knows what is expected of each and everyone.

Realization of the test activities from the beginning

As already mentioned, it is essential to integrate test resources into the projects from the very beginning. Especially in agile projects, simultaneous development and testing is necessary to fulfill all core activities within an iteration. The current status of planning, execution and control of the individual activities within the iterations must be made available transparently so that every team member has the same level of knowledge. Regular status meetings are required for this purpose.

In agile software projects, the team as a whole is responsible for planning, execution and control of all development and test activities as well as for transparent and appropriate documentation and communication within the project team. Short-term changes to the software can be taken into account much better due to the short development cycles, and any error conditions that occur can be identified and corrected immediately.

In short, the agile project approach offers many advantages over the classic project approach and also a holistic test management can be realized in an agile environment.

We offer you managed services and technological services to realize your digital software projects, develop innovative solutions and customizations, and strengthen topics such as maintenance, cyber security and more.