distributedlife

The waterfall model is about structured transition between development phases. However due to a combination of unskilled labour and constantly changing or ambiguous requirements the documentation that actually gets to test is irrelevant or doesn’t exist at all.

Why should I wait for documentation if I’m not going to get it anyway? The extension from this is the V-Model which brings testing into every single phase of the process. This is fine but what usually happens is that every phase has documentation and this documentation requires testing documentation to accompany it and then testing to go on it. This is a lot of work. Each of these documents then needs to be maintained. So if we get into the development phase and a requirement needs to be changed we have to go back and update the requirements, which causes changes to the testing documentation, this then requires re-testing. While this is going on development and testing during the development phase needs to occur.

This is not a pleasant place to work. Every change request causes documentation ripples throughout the project. Each document also needs to be maintained throughout the course of the project and then after the project. This is often more documentation that I’ve ever seen required. The V-Model is more about keeping testers busy during the early phases of the project than about documenting what you need to.

This is what I like about Agile. When it is being done properly is that Agile is about succinct relevant documentation. Documentation is also my biggest problem with Agile. Far too often I see “Agile” being implemented as “We don’t need to document anything“. Then they throw their hats in the air and wander off to the pub. At this point I am talking about both business oriented documentation (what the system should do) and technical documentation (how the system does it).

An argument for not documenting in Agile is “the code documents the system” which is a load of bull pie. The code documents what the system does not what it should do. The same applies to unit tests, while they provide some degree of intent you are still assuming it was coded correctly according to business intent.

To me the root cause of the problem lies in the follow areas. Agile is too often No Design Up Front (NDUF) when it should be EDUF (Enough Design Up Front). When you jump straight into coding you don’t have to produce the technical documentation. At the end of sprint one the tester has to work on system with no real understanding of how it should work or how it does work.

A solution to this problem is to encourage the mindset that documentation is a legitimate sprint artefact. It is important and the documentation does need to be a 700 page epic. From a tester’s perspective, all that needs to be documented is the relevant content. If you don’t know what that means, ask the tester. They should have a pretty good understanding of what documentation they need.

Very briefly we use technical documentation to identify the scope of the following non-functional testing types: Performance, Stress, Load, Availability, Penetration, Integration and Deployment testing. Integration is one of the biggest focal points here, by understanding the discrete components in the system we can best ensure that they system operates as it should when depend components go missing or misbehaves.