Test Documentation in Agile Projects

In this article your will learn how does Test Documentation in Agile Projects differ from Test Documentation in more traditional, waterfall Projects?

As we have previously stated, the agile approach has a number of effects on the tester’s role. If you’re used to working in a more traditional approach, you might feel uncertain about working in an Agile project because it will operate in a different way than what you’re used to.

How Test Documentation work in Agile Projects?

It is true that there are differences, however, be aware that you can leverage your testing skills within an Agile project so that your testing skills are put to good use, just as all the skills in the team are useful. This philosophy applies extremely well to the matter of test documentation in Agile projects. Many people who work traditionally find that there is a lot of test documentation, much of which has to be maintained throughout the system’s lifetime. In Agile work, it is common to work in short sprints or iterations, which consist of tasks where the system is designed, coded and tested. The team might carry out ten releases per year, compared with the 2-4 which is common when working traditionally.

As each sprint is focused on only a few requirements, it is natural that the documentation may not be as extensive. In traditional work, documentation has to be more expansive, especially when developing larger portions of the system. In agile projects the test plan often consists of only a single page or two. Since the test plan is a short paper, it is highly advisable to supplement it with a testing strategy. The test strategy describes how the system is usually tested. Think of the test plan for a moment. A test plan contains many headlines and much of the content is the same from release to release.

Typical examples include a description of the test environment, what should be prioritized in the tests, what roles are needed and a comprehensive description of the system. All of this can be described in the test strategy instead. This way you will get a good connection between a test plan that describes what should be tested at this time and a test strategy that describes what is always important but is not specific to this sprint. The test strategy is a living document and evolves over time and is relevant even when personnel come and go from time to time. It is important to strive to not over-document.

Always document what is needed but document just what is needed for the work to be done. These are some commonly used documents in agile testing:

• A test strategy that describes how the system is usually tested.
• A test plan for each sprint.
• Test specifications which contain test cases.
• Test Ideas for exploratory testing and test logs in which the outcome is noted.
• Checklists for installation testing and regression testing.

Test cases are often replaced by checklists and exploratory testing.

In traditional work, there are often lots of test cases. They also occur in Agile work, sometimes largely, and sometimes to a lesser extent. The disadvantage of the traditional test case in an Agile project is that it takes quite a lot of time to plan and write them. In many cases, checklists or “test ideas” work better. Make a checklist per area to be tested and in each case describe in 1-2 lines what should be tested. In the end, your checklist will look like a bunch of one liners.

It is also wise to create a supplementary checklist with general tests. There are several examples of such checklists in our blog. If the need arises in the future, checklists can be converted to traditional test cases. The agile manifesto contains a number of values or principles that are regarded as key success factors for agile work. One of these is “working software over comprehensive documentation”. Of course, this does not mean that all documentation is unnecessary.

Documentation is a tool to achieve the goal, and the goal is working software.

In traditional development, you can sometimes feel that the documentation is a goal in itself and the documentation becomes a product that is not used. In agile, work is different. Inevitably there is documentation needed for system maintenance and management. It may include the user documentation and system documentation, but the question you need to ask yourself is ‘what is needed during the current work?’ Document only what is needed, but certainly what is needed.