We know that a lot of knowledge is required by the tester before starting any test related tasks (even test planning). The knowledge is gathered and assimilated by the tester before the project starts or just after the project starts. The process by which this knowledge is gained is called Knowledge Transfer. Knowledge transfer is quite visible when a new team member joins the team and the existing team members (including the business people or the client) spend time in communicating with the new member to bring him or her up to speed. In an industry with a fondness for acronyms, knowledge transfer is also called KT.
Knowledge transfer is critical for testing. If your knowledge transfer has gone haywire, you could end up with people questioning your abilities (or worse, you could be out of the project). Remember that your successful performance depends on a good knowledge transfer to you. View my Domain Knowledge for Testers videos for industry domain knowledge in several industries. For example, view the video on Banking domain knowledge.
Sometimes the knowledge transfer happens in a chaotic, incomplete or hurried way due to any of the following problems:
a. Incorrect identification of knowledge givers
b. Lack of motivation on part of the knowledge givers
c. Communication challenges between you and the knowledge giver
d. Problems due to remoteness
e. Lack of trust (especially damaging to knowledge transfer)
The approach for knowledge transfer should take care of the above problems. Further, the approach should attempt to transfer knowledge that is located obviously in the documentation and processes and not so obviously in the team's behaviors and minds.
The knowledge transfer should have the following phases. Phases 3, 4 and 5 may be done in parallel. Otherwise, it is best to execute the phases in the given order. Even though the knowledge transfer may be initiated and closed by someone else (e.g. the client or the project manager), you are directly impacted by the success of the knowledge transfer. Therefore, you should take an active part in the process.
1. Prepare
The key people possessing the (most) knowledge in the various areas e.g. application functionality, application infrastructure etc. should be identified. It is not sufficient to inform the knowledge givers about the task. The knowledge givers should be motivated to impart the knowledge to you. This is usually best accomplished if the performance of the knowledge giver is somehow linked to the knowledge gained by you.
The one or more mechanisms of knowledge transfer should also be decided:
a. Demonstrations
b. Discussions
c. Providing documents as required by you
d. Replying to questions asked by you
e. Mentoring
f. Instant messaging
g. Wikis
2. Understand the client
It is important for you to understand the client organization (their business objectives, the purposes for which they use the application and so on). If the client cannot impart the knowledge to you, a business person (e.g. the business analyst) may impart the knowledge about the client.
3. Get familiar with the application
This is an important phase of the knowledge transfer since you would be spending a major part of her time with the application. A person very familiar with the application may demonstrate the functions and features of the application to you. Further, you should get a hold of a demo installation of the application in which you may explore the functions and features.
You should also get the (correct versions of) application documentation. Examples of application documentation include the system requirements, functional requirements, installation/ operating manuals, help files/ user guides, test cases, test plans and so on. This is the time to observe the application, read the documentation and ask as many questions are required to learn the nuances of the application.
4. Get familiar with the development, project management and test processes and systems
You should be familiar with the application development life cycle (e.g. agile, iterative or any other model), project management process (e.g. project planning, tracking, control, reporting and so on) and the test process (covering for example, build verification tests, new features tests, automated regression tests, defect life cycle and so on).
Further, you should understand (or learn and understand) the systems used for project management (e.g. Microsoft Project, TargetProcess) and any other systems used for test management (e.g. QC, Bugzilla).
5. Study the application environments
You should at least be familiar with the existing or proposed test environment (a.k.a. QA environment/ test bed/ test lab). It would be good for you to know about the other application environments for example, development environment, and staging environment and the production environment. The information about the application environments is usually available with the people playing the role of release/ deployment engineer or configuration manager or IT support (especially for production environments).
6. Provide feedback
You should provide feedback to the knowledge givers throughout the process of knowledge transfer. It is important to understand and internalize knowledge not only to respect the efforts of the knowledge giver but because this knowledge would be continuously used throughout the project.
Now that you are familiar with the various phases and aspects of the knowledge transfer, you should apply this knowledge in your next project. A good knowledge transfer would give you a definite advantage.
