Documentation of functionality or test cases is always imperfect. The trick is to do enough to serve your needs, and not waste effort on documentation that will never be used. Specifications and requirements have a way of changing and getting out of date, that quickly makes them obsolete. The effort to go back and keep them up to date needs to be weighed against the benefit of moving on to the next thing.

Documenting what testing should be done, and what was done is an area that should be adjusted to the situation. Who is doing the testing? If you are outsourcing testing to unknown contractors, who have little familiarity with your application, you will need to document test cases in exquisite detail. If you are using a small team, of dedicated testers who quickly become experts in the application, the level of documentation can be much more high level.

What are the stakes involved in the software? Software that deals with financial, medical, nuclear situations will require much more rigorous process and documentation. Most businesses, can do with much less as speed of delivery is more important.

How complex is a specific piece of functionality? If it needs to operate by a set of complex rules and algorithms, than more documentation is warranted. If you are essentially cloning existing simple functionality, a simple reference to that maybe sufficient.

How large is your team? The bigger the team, the more will need to be documented to facilitate keeping the team on the same page.

For features, is there enough detail to implement as described? Can a developer quickly clarify any ambiguity? Does a developer have the authority to make decisions when there is ambiguity? Is there enough detail for a tester, to know what to test, and what is important?

When a developer is handing off a feature to be tested by others, is there enough information to know what and how to test? If the developer already tested some aspects of the feature, on specific platforms, is that communicated so that testers can focus on areas that might have been missed?

As you situation changes, you will need to adjust your level of detail to that required by the situation. Be aware of your own leanings of over or under documenting.

Key Point

  • Use good judgement on how much time to invest in documentation. Cost in time must be weighed with other priorities, and the benefit of having the documentation.

Resources