Using Agile techniques in traditional requirements – Think about testing early

Thinking about testing early can be a total game changer. We have previously discussed using user stories at length but today we show how user stories can also help solve a test-related problem.

In traditional development, it’s very common that test cases are written too late in the process. This results in shortcomings in the requirements being discovered so far along in the process that it’s too late or too expensive to address the problems.

However, if the tester writes test cases in parallel with requirements, the result is that the acceptance test cases are completed when the requirements are finished. The test cases then function as the next level down in detail, on the level beneath requirements.

One problem that many people run into in agile development is that they don’t have time to regression test the existing code base sufficiently. Iterations are short, usually 4 weeks from start to delivery. Better regression tests can be achieved by executing iterations consisting of design, implementation, and low-level tests.

After a few iterations you complement with one iteration that only consists of test activities. This iteration can have varying goals, such as focusing on system testing, integration with other systems, regression, or performance. After that, you continue Agile work with short iterations.

When you start working in Agile, there’s a risk that too little test documentation is written. If the iterations are approximately one month long, you don’t need a particularly comprehensive test plan. Test planning will, of course, always need to be done, but it does not have to lead to a test plan being written. One approach is to write shorter test plans, while another is to develop a testing strategy for every system or maybe a strategy that covers all testing for one particular system.

The testing strategy describes things that don’t change from iteration to iteration. Typical examples include the testing environment, test data, and a description of the goal of different tests. Having a documented testing strategy is a great security net to fall back on when there are doubts or uncertainties during test execution.