Knowledge transfer process from a QA Engineer perspective

Olya Kovalenko
10 min readOct 22, 2018

--

The first time, I discovered knowledge transfer to be a serious process, was on my current project when I faced a knowledge holder who had no documentation at all and all the information was within’ his head. It is worth noting that my colleague was not interested in the knowledge transfer and the first sessions were quite chaotic without a certain structure. To understand what kind of data and it’s volume was also problematic.

It was at that moment I realized that I needed a plan and decided to search for articles with a similar topic in order to organize my sessions more accordingly and with a definite structure.

Now I want to share my knowledge and practical experience in transferring knowledge from one QA engineer to another.

Let’s Begin,

What is Knowledge Transfer and why is it important?

Knowledge transfer is a systematic process for capturing critical knowledge from senior members to share or distribute their knowledge and skills to the employees within an organization for varying reasons. There are so many reasons to capture knowledge, like onboarding new hires, transfer of the finished project to a support, or expanding knowledge within a team or company, etc. All of these reasons require a particular volume of knowledge to be transferred. How much and what kind of knowledge depends on the goals of the desired outcome.

When knowledge is transferred from one team member to another, it becomes stored and ultimately enhances the company’s competitiveness, which allows situations to be avoided with knowledge-bottlenecks when the only person with critical knowledge on projects becomes unavailable and the whole process hangs.

To do so effectively, according to my research, we must create a formal process around knowledge management that includes the creation of knowledge repositories where useful information can be stored for retrieval.

Knowledge Transfer plan and learning styles

Instead of doing the knowledge transfer on the ad-hoc basis, it is important to properly plan it. It is necessary to decide what we need to keep, and how to store and share information.

Very important aspects to consider when developing a knowledge transfer plan is the different learning styles. Visual learners prefer pictures and diagrams. So videos, webinars, and infographics will become useful data transfer tools. Auditory learners prefer to listen to information, so audio lectures are an obvious means of communication. Other employees will be reading and writing learners who will have a natural preference for quizzes, checklists, and wikis. Finally, kinesthetic learners prefer to acquire knowledge by doing simulations and role plays, as well as mentoring.

The knowledge transfer plan should take into account these different learning styles and should offer different ways to transfer to the recipient the knowledge necessary to fulfill their role in the project.

I understand that this part is easier to say than do, and people perceive transmit information differently, so I want to consider several ways on how knowledge can be organized:

Documentation. Project documentation is the most efficient way to pass the knowledge between team members. The biggest problem with documentation is that it becomes outdated super-fast. Team members not only need to create it but also keep it updated. Try to minimize the number of things that should be documented by avoiding mistakes, making your software easy to understand (inline commenting, workflows, checklists, etc.).

Mentoring. A mentor assigned to an intern is usually a senior team member who has not only deep experience in the tools and the specifics of the project but also has a solid mental ability: to teach, explain and motivate. Mentors assign practical tasks and give detailed feedback and recommendations after each stage.

Paired work (pair testing). Pair testing is usually done using a tester and a developer or two testers, but the tester can be combined with someone who can help in the investigation, such as a customer or a business analyst. Both will work on the same machine with one person executing the test with the mouse and keyboard, and another will be giving feedback, asking questions, taking notes and making observations. Both sides should take part in a joint discussion about the test scenario. This approach is a great way to achieve knowledge sharing.

Team code reviews. Team members check code written by colleagues for any logical errors and mistakes, as well as its compliance with the requirements. This method helps less experienced team members to learn the code base and new techniques and technologies. The code review stimulates communication around the structure of code, style, and architecture as a natural part of the working day, this also increases the quality of the project, as more people are familiar with the code base. Code reviews pretty effectively distribute project-specific knowledge within the team.

Q&A sessions. Questions are the interactive element of your knowledge transfer process. Such sessions allow filling gaps and drawing new ideas for topics that have not yet been covered in the plan. If the team members are distributed in various locations, and face-to-face interaction is impossible, then online screen-sharing, live chat, email, and on-call support is a handy way to answer any questions that may come up during the knowledge transfer period. Such sessions could be recorded and re-played later if needed.

Simulation. Technology has allowed the simulation to become a primary and effective way of knowledge transfer. Depending on the project specifics, videos and training courses with 3D animation can be used to simulate specific functions and tasks. This is a great way to provide a “hands-on” experience in a controlled environment.

The right questions when creating a plan

What kind of knowledge should be accumulated?

Why are you interested in collecting this knowledge (your goal)?

Who is involved in knowledge sharing?

How and in which form will the knowledge be delivered to the end user?

When will the meetings on the knowledge transfer take place and how are they coordinated with the general schedule?

How will you know you have achieved your goals?

How will you measure efforts?

The steps in the Knowledge Transfer implementation

Who is the customer. Before you start creating your plan you need to know what your customer wants and why. It is very important to learn the information about the client, the needs, the business goals and why it was decided to develop a specific application.

This type of information can be easily found on the company’s website or on the Internet, on the company’s internal resources (if available), by communication with the company’s representative or product owner, etc.

Become familiar with the application. Getting to know the application is a very important part of knowledge transfer and it can take place in different ways, depending on whether the application is already in development or just planned.

If the product is at the planning stage, it is best, to begin with, the on-site kick-off meeting with the customer and get all the necessary information in the direct work mode.

When the product is already under development or there is a first version of the product in the market more options are available such as ad-hoc testing, demo, presentations, training sessions, pair testing, and others.

I would like to pay some attention to the first impression of the product. I consider it is a good practice to start learning of the product informally, without preparation of documentation and expectation for results to understand is the product user-friendly, has intuitive navigation and UI, etc. Then create a list of all the noticed shortcomings, questions, and improvements for further discussion with the team.

And if this is an IoT project or it uses any devices for the interaction, do not forget to ask for the list of these devices and their manuals.

At this stage, it makes sense to request access to project and testing documentation, such as:

  • Solution architecture
  • System requirements
  • Functional requirements
  • User guides
  • Test plan
  • Test cases
  • Use cases
  • Checklists
  • Test data (users and accounts, data for registration, additional specific data)
  • Etc.

When you have an access to documentation, a walkthrough of regression test cases (critical path) could be done as a part of shadow resource (where you’re not billed directly to the client, but still work on the project). It will allow you to be more familiar with the application and identify the gaps in regression test cases if any and align them with the product owner or project manager.

The application environments and accounts. It is very easy to get acquainted with the application when it is in the market. You can easily find it and install. What if the application is at the development stage or it is only in the plans?

When the application is in the planning, based on previous experience, you can discuss the testing environment for the application with your team. Most often used are DEV, QA, Staging, Production. Of course, for different kinds of projects, many variations of the test environment are used, depending on the configurations and requirements. But what is extremely important is to clearly understand what and for is used. This will avoid mistakes, such as unplanned testing on the production.

First of all, you need to think about all kinds of accounts and access:

  • Access to project repository if you are going to build apps locally
  • Environment user accounts for testing the app
  • Creating automated scripts of environment deployment or creating system images
  • Links for CI/CD

Information systems. Whilst involved in the working process information systems can reduce the number of routine procedures that are undertaken by the user eliminating the possibility of chaos. All the systems are structured in a way to provide easy access to the stored information, to keep in order all data flows and keep track of all troubleshooting issues, etc.

We need to identify the correct contact person who is responsible for all issues regarding each system. This person could be the support staff or system administrator.

Certain types of systems can be:

  • Bug tracking system
  • Knowledge base system (wiki)/information portal
  • The monitoring system (logs, analytics)

Who are the team. In large companies, a new project is often equal to a new team and meeting with the team is also part of the knowledge transfer ritual. If there is a corporate portal with employee profiles, check out the professional skills and achievements of your team members and any other information that you can get.

What can be useful:

  • Members of the team
  • Hierarchy and responsibilities, reporting
  • Remote team members (pay attention to time zone)

Processes within the project. Depending on the project size, the amount and timing of work for each team, the processes can be very different. There is no single and universal solution for all cases, so it is very important to understand which kind of processes already exist:

  • Application development life cycle (e.g. agile, waterfall or any other model)
  • Project management process (e.g. project planning, tracking, control, reporting, etc.)
  • Test process (e.g. testing activities, test automation, etc.)
  • Delivery process (CI/CD workflows)

Evaluation and feedback. Measuring the success of knowledge transfer is always a challenge. Knowledge transfer is achievable as a one time process if used in one setting with one team. However, if a team is set on using a continuous approach to this idea then it is required for a selected person (e.g. a specialty manager) to both organize the team and the processes, and document accordingly.

Depending on the volume, complexity, and criticality of the knowledge and skills transferred, on the number of participants, the approaches used for evaluating the results may be different.

The main aim is to measure how effective the knowledge transfer was and whether its goals are achieved. It is also important to analyze the quality of the process in terms of missing areas, changes in the structure of data presentation. Analyze the time frames for the tasks and how well they fit the plan. Measure that the data recipient is able to put knowledge and skills into practice independently.

At different phases, you can apply different methods to assess progress and the level of improvement, for example, after each session, after reaching a certain milestone or completing a process.

A small overview of the tools used in practice in an IT project:

Feedback. One of the tools that can be used throughout the entire period of knowledge acquisition. It can be provided after each session or after a certain batch of information in order to improve the quality of the presentation.

Questionnaires and quizzes. This tool is quick to set up and easy to maintain or improve. Allows participants to interactively answer questions at any time to maintain the level of knowledge even after a long time.

Exercises. Solving real problems is an excellent way to try out the knowledge gained in practice and for the one who evaluates knowledge, results will tell which nuances need to be worked out.

Test case development. It will allow assessing how deeply knowledge a specialist has received and is he able to transfer them to practical cases with coverage of the blind zones and corner cases in the application.

Useful Tools

As we have already found out earlier the knowledge transfer is not only documentation or oral transmission. Thus, depending on the content type and method, you can use different applications to transfer information.

Knowledge base system (wiki)/information portal: Confluence, JIRA, Google docs, etc.

Presentation: Google Slides, Prezi, Microsoft PowerPoint, etc.

Screenshoter/screen recorder: Monosnap, Greenshot, Jing, etc.

Мind maps and diagrams: XMind, Lucidchart, Coggle, Draw.io, etc.

Mockups and UI Prototyping Tool: Moqups, InVision, etc.

Screen Sharer: TeamViewer, Skype, Slack, Vysor, etc.

Test Cases: Zephyr, Hiptest, etc.

Cloud Storage: Dropbox, Google Drive, etc.

Task tracker: JIRA, Pivotal, Trello, etc.

Conclusion

Knowledge transfer is not the easiest task that can be completed as soon as possible, but requires careful preparation, setting goals and selection of executors.

I described some points that will allow to gather thoughts and outline a plan of action, but each specific case requires to figure out the most appropriate way to transfer knowledge within the organization or project. The key to success is in finding the right format for your team. You can study the documentation, watch online courses, receive instructions on the email, but the most effective type is face to face interaction, properly established communication and continuous feedback.

A smart constructed knowledge transfer system will reduce the time of routine operations, eliminate the chaos in the documentation and the head, and also establish the correct habits in the organization of documents, test data, and so on. Lack of strategy can lead to the fact that the team spends too much time to become productive and bring results.

For all team members, it is important to have a place where they can find necessary information, share their information instead of keeping everything in their head. And also this approach will help standardize the processes within the organization, which will make everything consistent.

Thanks to Lohika (https://www.lohika.com.ua) company for help in preparing thе article.

--

--