An Agile environment requires an adapted test process. In our previous blog we have shown how we apply the elements of TMap HD to lay the foundation to redesign the test process.
This blog is the sequel. It is about our "Quest for Quality" using the building blocks of TMap HD and the tools from “TMap in Scrum”. With this we illustrate the test process that was eventually designed.
TMap HD Building Blocks
TMap HD is a quality driven test approach, which is very suitable for an Agile environment. Using the building blocks, a test process is constructed that is tailored to our specific situation. We have used several building blocks in order to translate our values into a concrete strategy.
Building Block 7: Test Strategy
The project we are working on has a strict deadline. This means that we have to use the time and resources that we have as efficiently as possible. A good test strategy helps us to determine how to distribute test capacity to the test objects. For this an assessment needs to be made on the basis of risk, time and the desired result.
Building Block 6: Product risk analysis
The ‘Product Risk and Benefit analysis’ (PRBA) helps us gain insight into the risks and priorities. By basing the distribution of test capacity on the PRBA, we can justify the balance of time, risk and the desired result. We have composed the PRBA so that everyone can influence the distribution of test capacity. The Product Owner determines the priority of the User Story (Benefit). Based on the technical complexity and in consultation with the developers the chance of failure is determined and the damage is determined by the entire team.
Building Block 20: Structured Reviewing
The goal of the test strategy is to find the most critical errors as early and cheaply as possible. This is consistent with the feature of a quality driven approach "Test in all phases and start as early as possible” (Building Block 17: Quality-driven characteristics). We do this by evaluating the requirements, in the shape of User Stories and screen designs. In these User Stories the acceptance criteria are worked out to give context to the screen designs. This ensures that the agreements made with the Product Owner are communicated to the developers completely and unambiguously.
Building Block 16: Using test tools
Another feature of a quality driven approach is that the tests - where useful - must be automated as much as possible. This is to test more, better and more frequently. We achieve this by automating the regression test and the test design. For this we use 'Model Based Test Design’.
The values established by us will be integrated into the test process through a combination of these building blocks. The activities resulting from this will be incorporated into the scrum model, and then the test process will be integrated with the development process.
The TMap phases in the Scrum model
“Failing to plan is planning to fail.”– Mr. Mikkel
It is important to design a test process that is aligned with the other activities in the sprint. It should also be able to respond to the changing environment of the project. For this, we used the image below, taken from the book “TMap NEXT in Scrum”. In this image all phases of TMap NEXT are built into a representation of the scrum model.
Capturing the Process
Ultimately, the image below shows how the process has taken shape. Capturing it in this way - since we are still in the transition phase from waterfall to Agile – does not fully reflect Agile thinking. However, it is important to clarify our approach in this way for all concerned. But we do handle this process in an Agile way. We plan test activities per sprint and perform those activities with the highest priority first. We have presented this process to the test manager and the head of the development team, resulting in enthusiastic reactions. We will use our experiences in the next few weeks to optimize the process thanks to the principle of 'continuous improvement'.
Published: 11 March 2016
Author: Kristel Beekmans and Thomas Vink
