@huib.schoots has already made the point I would have made, and likely more eloquently. So I will just support from an example from my personal experience.
When I first started testing, I did not know better. My first task was to write down an extensive series of regression tests for our system, which I did. This certification-approved scheme turned out to be very long, very precise, and was intended to be used to educate new colleagues about our system. Everybody except management took a turn at the tests, and after a couple of people I learned something important. The tests I wrote, in the way I wrote them were completely ineffective at teaching about what the system did, but were very effective at telling me who could follow a list of instructions.
After what I still refer to as “the incident”, which has little to do with trainging and a lot to do with testing (we had a release which passed every test we could think of and was very poorly received by our clients), we got the chance to revise the initial training.
I changed the system documentation as follows:
- I borrowed the flow diagram from the UI guys. (1 page)
- I borrowed the flow diagram from the hardware guys (1 page)
- I summarized the two diagrams with plain text (1 page)
Then, when someone new was sent to test to learn about our system, I did the following:
- I walked them through the system
- I had a conversation (led by them) about what was going on. It had to be led by the new person, since they had different priorities for their role than I had, and I couldn’t effectively predict what they needed to know from me.
- In the event of a programmer or tester, I allowed them to test a current scenario for a day (Session based testing, I give them a scenario, they have a few hours to test, then we talk about the testing), while allowing them to ask any question at any time.
What I noticed was this:
- People read and understood the documentation better than anything which was previously presented.
- After our department was “reorganized” (end of project), my old team mates would ask me to do the same for their new team, so the perception of the effectivity of that training was quite high.
- After training, my new team mates would be much more open in asking me questions than the ones who used the lengthy book of documentation.
As for my hit-by-a-bus scenario, that was covered by having team mates who understood testing (which, given that I talked to all of my team mates about testing every day, was everyone). I expected the following tester to make the tests their own. Which I suppose brings me to a following (supporting?) point.
It is often better to have a team which understands what you do than to have a document which describes it.