Agile Testing in
The agile way to more quality and efficiency
With the introduction of agile methods, user requirements are the focus of software development. Future users are more involved in the development process and ensure through their input that important issues are actually implemented and that the application is easy to use and perfomant. To verify this, functional and bug-free software must be delivered often and continuously. The high demands on the non-functional part of the software also have to be tested continuously: has it been coded cleanly, does the application meet the security requirements, does it function stably and is it easy to maintain? In one sentence: constant, frequent and error-free code delivery is a question of quality.
What distinguishes agile from classical testing
In classical test management, development and testing are clearly separated and all four test stages run one after the other: the test phase begins with the completion of the product. First the individual components are tested (component test), in the next stage, the integration test, the interaction of the individual components is checked, and finally the functions of the entire product are put through their paces, first internally (system test) and finally by the customer (user acceptance test). The roles are clearly distributed. The development team develops, the test team tests and the test management controls and steers.
If you want to deliver stable and error-free software continuously (with each iteration) in an agile environment, tests must be carried out continuously. In the long run, it is not feasible to run through one test stage after the other according to classical test methods, because the iterations are short and things have to be done quickly. Agile testing also has component, integration and system tests, with the difference that these do not run one after the other, but in parallel within an iteration, and are sometimes even embedded in the development. The agile approach also does not know any clearly distributed roles: Ideally, software developers and architects as well as testers, test and quality managers are part of the development team and support each other. The team has a common goal: high quality through high test coverage, efficient test execution and documentation. This can only be fulfilled through a balance between a high degree of automation and few manual tests.
Efficient distribution of tests: The test pyramid
A look at Mike Cohen’s test pyramid shows how an efficient test strategy can be designed, how the distribution of tests to the individual test levels should be planned and which areas make the most sense for test automation.The broad base of the pyramid is formed by a high number of component tests in the form of automated unit tests. They are relatively easy to create in parallel with application development, can be carried out quickly, are correspondingly inexpensive and guarantee a high level of test coverage. They ensure that most errors are already detected during development.
The middle level of the test pyramid is formed by integration tests (API tests). API stands for Application Programming Interfaces. Automated API tests ensure that components work together as specified. API tests are very well suited for test automation because they are usually subject to few changes and are easy to maintain. At this point, it should be noted that non-functional tests such as load and performance tests are not considered in the test pyramid, but are important for user acceptance and can also be automated very well in some cases. System tests (GUI tests) are at the top of the pyramid. GUI (Graphical User Interface) is the term used to describe the graphical user interface. Automated GUI tests check whether all functions run as desired. Their automation is quite feasible due to a selection of tools, but the choice of tests to be automated should be considered very carefully, as they are more complex to create and maintain and thus cost-intensive. As a rule, GUI tests require considerable rework to keep up with frequent changes.
It is advisable to automate only as many GUI tests as necessary and as few as possible and to introduce them successively, for example by securing existing functions sprint by sprint using automated regression tests. Exploratory and end-to-end tests are hardly suitable for test automation. The latter because of their complexity. Explorative tests because of their degree of freedom. The explorative tester explores the application without having previously determined exactly which test steps are to be executed. One advantage is that less preparation is required, documentation is kept to a minimum and errors are found away from existing test scenarios.
Quellen: Buch: Agile Testing: Manfred Baumgartner, Martin Klonk, Helmut Pichler, Richard Seidl, Siegfried Tanczos (2018): Der agile Weg zur Qualität