2007-May-12 - Time is never enough for Transfer of Info before one leaves
Last month, 2 interns leaved our team. About a couple of weeks before they leaved, they started to prepare for the materials and documents about the module they owned. And in the last week, they held a meeting with the successors to transfer all the information, and answered successors' questions about the modules during the whole week. After that, they leaved.
Everything sounds good, and it seems the successors got everything they needed to handle the modules. But when a real cycle of test came, a large amounts of practical questions popped up. Lots of the questions were about whether a certain behavior of the product was correct, how to set up the specific testing environment, what did the test case mean to do...
Shouldn't all these questions have been answered during the transfer of information, or their answers be found in the documents the interns prepared? Not until then did we realize that the transfer of information was not completed at all.
I think there are mainly 2 reasons for this:
1. The successors cannot really LEARN the modules and ask the correct questions until they practically test by themselves.
2. No standards/templates for the documents and materials they should prepare. And nobody review the doc they prepared either.
Based on the 2 reasons, I think first of all, we should start the transfer of information 2 weeks earlier, leaving enough time for the successors to finish a core cycle of test on the new modules. So that those practical questions (test cases, testing environment, expected results related) can turn up before the person leaves.
Secondly, we need a checklist. It's actually difficult to set up a template for the materials because test requirements vary. Some module may require special testing environment. Some may use specific testing tools. So maybe we can provide a checklist as detail as possible to make sure everything on the list are prepared. Here are some example items:
Feature spec, test plan, test cases (with clear description and expected result), environment set up guide, testing tools, automation testing scripts, known-issues, open bugs, trouble-shooting guide, other testing tips.
But even then, we should still have some responsible QAs review the docs and materials.
Lastly, I think it is better to prepare these documents during our working routines instead of doing it one month/week before one leaves. But this depends on every engineer themselves.
| 
