Test Management – Part 1: The Test Cycle and Phases
Introduction
In a digital world nothing works without a software. It’s easy to program something, but how does the product look like? For example, you write a piece of software for a washing machine and then it is deployed within a vacuum cleaner. Starting the cleaner, the message „Please close the door!“ will appear. This error could be avoided, if testing process was a part of the development and a fundamental part of the product vision. Test management is getting more and more important, because basically everything in our life is being managed or controlled by something based on software.
The blog series consisting of 3 parts will give an overview about test management approaches and their successful implementations. The first blog post focuses the test phases and cycles. The second one will summarize different methods and tools used in test management. There are several tools which can be used to automize testing if the content is suited for it. The last post will demonstrate the documentation and reporting possibilities of test management to ensure project management and the development team with first grade results of how effective and efficient their software development really is. Testing may take up some time and resources and cause delays, but it is necessary and crucial for a successful software development project.
All the described practices are applicable for classic and agile software development.
Definition of Testings by ISTQB
The International Software Testing Qualification Board (ISTQB) describes testing as “the process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects” [1].
Often neglected while test planning is that the preparing and postprocessing of the software product can take much time. Additionally, the entire test plan needs to be compared to the client requirements to ensure that all these are covered by the tests. Concluding these activities is the need for thorough documentation while effectively reporting the evolving test results – all the while correcting, assessing and amending the tests for inaccuracies.
The finished software increments are deployed in major or minor software releases. In order to ensure that bug fixes and new functionalities do not affect the original software, numerous regression tests need to be implemented.
The Test Cycle and Phases
The fundamental process model is the V-model (see graphic), which is to be understood as ”a sequential development lifecycle model describing a one-for-one relationship between major phases of software development from business requirements specification to delivery, and corresponding test levels from acceptance testing to component testing”[2]. The following diagram visualizes a test cycle and shows the differences in the sequence between the classical and agile approach.
Especially for classic project handling (waterfall method), this model is significant. In the agile environment, each development module envisions a corresponding test step. For agile software development, this is to be understood as that the V-model goes through frequent and recurring test cycles.
When planning and designing test cases, the test pyramid has established itself as the best method to follow [3]. This applies to both classic and agile software developments. The testing of the pure functionality of the software can be automated. There are a lot of tools available on the testing market. Consider the initially mentioned example of the vacuum cleaner and the washing machine: The user can test the new software only by manual checks and give feedback regarding accordance to the requirements.
Summary and Conclusions
In summary, the development method is irrelevant regarding testing, because the models can be used for agile and classic project management. No matter which development method you choose, the clarification of the requirements is decisive for the further development. The clearer all the software requirements are, the closer the software end result will be to the original product vision and therefore save test time and resources - especially for the end user.
Klick here to get to part 2 that focuses on different methods and tools in testing. The goal is to present examples of these, because finding a suitable tool can be frustrating. Part 3 is about Documentation and Reporting.
[1] https://glossary.istqb.org/en/search/testing
[2] See glossar of the German testing board
[3] A graphical model representing the ratio of the test scores of the individual test stages, with more scope at the base than at the top. https://glossary.istqb.org/gb/search/testpyramide