My colleague Wiebke Bergholz explains what test management is, how it’s structured and how it fits into 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?
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.
How does test management differ from quality assurance?
Test management should not be confused with quality assurance. Often, both terms are equated. 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
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
The individual components of a software are tested on lowest level of the system architecture by the developer himself. It is to be determined whether the component was converted according to the specifications.
The interaction of all subsystems is checked during the integration tests. Error states of the interfaces between individual components can be uncovered here.
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.
The acceptance test represents the final acceptance by the customer or user. A final test is therefore carried out before the system is put into operation.
Download our infographics about the test levels in software projects for sharing.
Error costs: The rule of ten
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 even 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 are already identified 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 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
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 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, a rethink is often necessary. 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 must be performed and successfully completed. 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 individual.
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 serve 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 better due to the short development cycles. 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’ll help you with your CRM projects from evaluation to testing to successful implementation and further use. Find out more about our services.
Wiebke Bergholz is a consultant at ec4u and focuses on technical consulting in the areas of customer journey management, requirements engineering and test management.
https://www.ec4u.com/ec4u-blog/wp-content/uploads/sites/3/2020/10/projektmanagement_iStock-1227008534-1.jpg269710Juliane Waackhttps://www.ec4u.com/ec4u-blog/wp-content/uploads/sites/3/2016/02/Logo-ohne-Schriftzug.pngJuliane Waack2020-10-15 09:00:372020-10-13 12:14:34Test Management as part of agile Software Projects