Testing in agile software development
Agility does not change the importance of testing, but it does change the organisation of software production
// Digital Transformation, IT Processes and Organisation, IT Quality Improvement
Agile forms of organisation have their roots in software development. Traditional software projects using the waterfall or V-model as a method usually use strong processes, often supported by powerful test suites, to determine quality. Test cases are generated from the existing documentation - requirements specification, technical specification. Test execution is planned in advance so that all resources - personnel, test cases, systems - are available within the set test period. During the test period, test and troubleshooting phases alternate until the finished product is finally ready for installation and use. Agile software projects run differently by questioning this step-by-step approach. Combining classic (software) test management with the requirements of an agile organisation is a methodical challenge, but also holds many opportunities.
Agility changes the principles of test management
The "Manifesto for Agile Software Development" formulates guiding principles which at first glance are not compatible with classical testing principles:
Processes and tools are not as important as individuals and interaction. Test tools in particular offer the possibility to evaluate the test progress and the quality of the product by documenting the test execution and by means of error tracking.
Documentation is less important than a functioning system. But where can good test cases be derived from if there is little documentation?
The cooperation with customers in the project is more important than contractually fixed requirements. The foresighted planning of testing aims at a concrete performance framework.
Although changes in the project are not necessarily desired, they are nevertheless taken into account, which makes the preparatory creation of test cases and the long-term planning of test periods appear to make little sense.
A first conclusion could therefore be that structured testing is not possible when developing software in agile projects. This conclusion would not only be wrong, but fatal, because it would mean that the quality of products developed in an agile way could not be tested.
- Individuals and interactions more than processes and tools
- Functioning software more than comprehensive documentation
- Cooperation with the customer more than contract negotiation
- Responding to change more than following a plan
The goal remains: Testing serves the quality of software development
Even in agile projects, quality can and must be checked. Agile testing must be designed in such a way that it optimally supports the goals of agile software development. These programmatically set goals are: "high customer satisfaction", "high product quality", "high development speed", "fast reaction to changes" and "high team motivation". To further consider the values of testing from the "classical" approach is not always easy. These are good planning, traceability and verifiability of the test activities and also a high level of systematics of the test design, resulting in a high and reproducible test coverage.
Quality assurance in agile software projects is possible if testing is performed according to the principles described below.
1. In an agile environment, it is not possible to run through the test levels used in classic projects (e.g. unit, integration and system testing) in terms of time. However, the goals associated with these test levels are still valid. In agile projects, it is therefore advisable to work in micro test cycles in which test objectives with different contents are covered, so that the classic test phases are understood as content-related test types rather than phases. Ultimately, this means the dissolution of the test stages.
2. Agile software development offers the great advantage of being able to react quickly to changing requirements. In order for test activities to support this advantage, as many systematic test cases as possible - both structure-based (unit tests) and business oriented tests - should be designed and automated. Test automation is thus an important factor, as already completed parts of the software should be checked for freedom from errors again with every cycle by means of regression tests.
3. Test management, error management, documentation work and similar activities are considered to be low expenses in an agile environment. The manpower should therefore primarily be invested in operational test activities to ensure software quality and not in documentation.
4. In an agile environment, timely feedback on quality, i.e. the rapid execution of tests and the rapid reporting of errors found, is essential. To achieve this, it is necessary to involve the testers in the function definition before a development cycle. This approach also promotes the indispensable close cooperation between developers, testers and customer representatives. In addition, direct communication with a large degree of omission of documentation supports fast feedback.
To deliver high quality software, testing is essential - even in agile software projects. The challenges for testing in an agile environment are the time component and the flexibility of content. Testing must therefore adapt to the development process in terms of content and time, and rapid feedback on current quality is necessary.
A balance between a high degree of automation and lightweight manual exploratory tests can provide the required speed. Tests that relate to the usability of software cannot usually be automated. Agile teams should be aware of this. Corresponding tests must therefore be covered by exploratory testing. For this purpose, it is helpful if programmers support the work of testers in automation. In return, testers, with their critical skills, provide the assurance at every stage of the project that they are on the right path to a high-quality software product.
In agile software development, therefore, testers are part of the development team, thus dissolving the classic separation between testers and developers. The testers thus contribute their specialist knowledge directly to the development process. In the future, the challenge will be to put together teams that have the necessary know-how on all sides to ensure agility and quality in software development.