Well, that depends on what your clients need. How do you know what your clients need? I can think of two ways:
- Ask them. Be careful. Per my experience, clients inflate their test documentation needs when asked. Maybe they’re afraid they’ll insult the tester if they don’t ask for lots of test documentation. Maybe they’re intent to review test cases is stronger than their follow-through.
- Observe them. Do they ever ask for test case reviews? If you are transparent with your test documentation, do your clients ever give you feedback? Mine don’t (unless I initiate it).
Here is what I ask of my testers:
Document enough detail such that you can explain the testing you did, in-person, up to a year later.
Before I came up with the above, I started with this: The tester should be present to explain their testing. Otherwise, we risk incorrect information.
If the tester will be present, why would we sacrifice test time to write details that can easily be explained by the tester? In my case, the documentation serves to remind the tester. When we review it with programmers, BA’s, users, other testers, auditors, or if I review it myself, the tester should always be present to interpret.
What if the tester leaves?
I’ll talk about that in the next post.