What if the test documentation is written per the detail level in this post…
Document enough detail such that you can explain the testing you did, in-person, up to a year later.
…and the tester who wrote it left the company?
How are new testers going to use the old test documentation for new testing? They aren’t, and that’s a good thing.
Add test detail as late as possible because things change. If you agree with that heuristic, you can probably see how a tester leaving the company would not cause problems for new testers.
- If test documentation was written some time ago, and our system-under-test (SUT) changed, that documentation might be wrong.
- Let’s suppose things didn’t change. In that case, it doesn’t matter if the tester left because we don’t have to test anything.
- How about the SUT didn’t change but an interfacing system did. In this case, we may feel comfortable using the old test documentation (in a regression test capacity). In other words, let’s talk about when the write-tests-as-late-as-possible heuristic is wrong and the test documentation author left the company. If you agree that a test is something that happens in one’s brain and not a document, wouldn’t we be better off asking our testers to learn the SUT instead of copying someone else’s detailed steps? Documentation, at this level of detail, might be a helpful training aid, but it will not allow an unskilled tester to turn off their brain. Get it?
How are people going to understand old test documentation if the tester who left, must be available to interpret? They won’t understand it in full. They will probably understand parts of it. An organization with high tester turnover and lots of audit-type inquiries into past testing, may need more than this level of detail.
But consider this: Planning all activities around the risk that an employee might leave, is expensive. A major trade-off of writing detailed test documentation is lower quality.