Agility á la RapidRep Quality Master

Test automation in agile software projects

In agile software development, the teams organise themselves autonomously. Everyone plans, implements and tests on his/her own responsibility. Within short cycles, new product intermediate states emerge, which have to be tested regularly and ad hoc. The constant refactoring has the consequence that in addition to the unit tests, attention is necessarily paid to the system and integration tests, in order to test the interaction with other components. Besides the conventional approach following the V-Model, the RapidRep Quality Master also supports the less formal (from an agile point of view) ad hoc mode of working. The RapidRep Test Suite supports the automation of test cases in the Quality Master via the interactive Test Runner GUI as well as in batch mode. Other products that support the RapidRep Quality Master API can be used as well. Creating evaluations and management reports is a task for which the RapidRep Reporting Suite is ideally suited.

Agile testing refers to testing software in an agile development project. Its effects on the working methods of a tester and test manager are far reaching. Agile software development (in this article we only refer to the project management framework Scrum as its most popular representative) clearly allows teams more liberties in their workings and requires in return that they organise themselves autonomously and independently. For this effect, the Scrum framework contains useful presets, because even an agile team requires rules.

The client does not need to worry whether his product is developed adhering to the V-Model or to agile methods. The requirements on software quality remain unaffected. Agile procedures strongly impact on the realisation of the quality assurance and the quality management in general (compare Standards according to ISO 9000 et seqq.). Quality assurance and consequently the software test lose their independence because testing becomes an interdisciplinary task within the team. Each developer is simultaneously responsible for the quality of his artefacts.

The software delevopment in Scrum provides a product release in regular intervals (e.g. monthly) whose range of features increases with each so called sprint. It is typical that because of the constant refactoring, existing components are often changed and new components are added all the time. As a consequence, quick feedback in testing is essential. Thus, tools for automatic testing are very important.

In contrast to the conventional test procedure, the tests in each sprint have to prove that

• the individual components function (unit tests)
• their interaction with other components works flawlessly (integration tests)
• and the system, if deployed as a whole into a test environment, corresponds to the requirements implemented so far (system tests).

For the unit and integration tests, agile test projects almost always employ test tools for automation that are based on xUnit (e.g. JUnit for Java, Nunit for .NET). The necessity to compile defects recedes into the background in Scrum, because the defects can be reproduced at any time and due to the constant exchange within the team, they are quickly communicated and patched. Defects that cannot be detected automatically or cannot be patched in the current sprint should be documented according to IEEE 829.

The utility and benefits of test automation can be significantly increased if the team adopts the mode of thought of test-driven development/test-first programming. At this, code for testing the new feature is written first. Only then the actual program expansion gets implemented.

The automation of system tests is considerably more complex and costlier. The reason is that the program is not examined under laboratory conditions but has to be tested in a complex test environment that closely resembles the productive system. Eventually, the final product has to function with input from a graphic user interface, for example, requires connection to a data warehouse or communicates with a middleware.