Eliminating Communication Issues with Your Testing Team

Success of a software project strongly depends on efficient teamwork. The latter, in its turn, requires a proper level of communication within the team. The bigger the project team is, the more focus is needed on the processes of interaction and knowledge sharing within it. And even more – if it is an offshore team.

While it is usually a PM’s responsibility to engage the teammates and to resolve any issues they come across, there are certain areas where customer’s impact is decisive. If you are considering employing an offshore team for your project, the following typical problematic situations might be useful for you to take into account.

Typical blockers on the top level

Insufficient requirements for the product

Quite a widespread situation, sadly. Requirements can be scarce or even missing at all. In such a case, when it comes to hiring an outsourcing QA team, there is usually no time to amend it and the offshore team has to handle it. Naturally, the following risks are introduced for such a project:

• Time loss. QAs will have to discuss unclear moments internally, ask numerous questions and spend hours in meetings. This situation may not only frustrate the team but lead to negative consequences for your project, for example, to the delayed release.
• Incorrect assumptions and as a result, false alarms or ignored defects. This is what you would want to avoid at all costs.

Of course, there would not be a substantial lack of requirements if the project would be properly planned through and managed before the outsource QA team jumps in. Yet, some quick solutions could improve the situation even now:

Proactive approach:

• Assign high priority to amending the requirements. Someone will have to do it on the go, clarifying at least most critical functionality parts. QA team might come with their own proposals so hopefully you will be able to reach proper clarity about your product in time.

Reactive problem-solving:

• If you’ve discovered an issue, be ready to answer the questions of the QA team. As shown above, enhanced collaboration might be your best chance at this point so never avoid a discussion initiated by them.

Outdated documentation

A different problem with a similar outcome: the project documentation has been perfectly completed a while ago, yet it is not helpful today because no one bothered to review it lately while the product was rapidly evolving.

Risks:

• Misunderstanding. Expect even more confusion on the outsourced QA team side (and more risks for your project). Existing requirements are likely to be used to start writing test cases prior to exploration of the product itself. As a result, a good deal of this work will appear to be worth nothing.
• Lots of false alarms. This can be a huge problem that can slow down the QA process and possibly your business activities. After the discrepancy between the documentation and the actual state of the product is understood, the team will rely on exploratory testing mostly.

The outdated project documentation might not be your #1 problem. However, it can eventually become completely irrelevant if you continue to neglect it, so at this point it is strongly recommended taking some measures:

Proactive approach:

• You should never forget to review and update your documentation. Perhaps, right now the project can go on without a renewed documentation, especially when another release is quite close. But you can already see that constantly postponing this review has caused some trouble. In order to ensure smooth business processes, it is better to exit this cycle right now.

Reactive problem-solving:

• If you have faced the problem called outdated documentation, don’t hesitate to get help from the QA team. They have been the main – and very active – users of the product lately, which makes their knowledge about its latest version almost unparallelled. And if they have any suggestions, be sure to listen to them.

Frequent changes

Unplanned changes, small and big, as well as unforeseen limitations, needs for library or driver upgrades, belated decisions to get rid of some legacy code and so on – some of these things could hit a smoothly planned project anytime.

Risks:

• Loss of work results. Sometimes the drastic change of priorities makes days of testing obsolete because that specific piece of functionality suddenly gets postponed or even completely reworked.
• Loss of focus and motivation. It is important to concentrate on a task in order to obtain good results. Therefore, frequent switching to new tasks does not help to concentrate well. As a result, your offshore QA team might eventually lose its productivity, that will definitely will have a negative on your project.

Business processes don’t work perfectly. No matter how good your planning (in particular, test planning) is, some changes are inevitable. But it is not the end of the world. All you need is to improve the mood and closely collaborate with everyone involved to try adapting to the situation:

Proactive approach:

• Be sure to inform the team about the forthcoming changes in advance. Timely warning can save lots of time and effort as the team will be able to quickly reorganize their schedule by themselves so you can stay focused on your strategic goals. Also, be open to discuss the tactical moves with your remote QA team. It would be best if they could voice their opinions on upcoming changes.

Reactive problem-solving:

• If changes have already occurred, engage your QA team to be proactive and flexible. No one wants a failed project or wasted effort, so initiative from your QAs to mitigate risks on their level might turn out to be very helpful for your project (thus, for your business).

Issues with the environment

The problems with the test environment are quite common too. These may include various types of issues: from a shortage of devices (when two testers both urgently need to test some fixes on that specific iPhone X) to test servers going down right before the release to production. As usually, this happens when least expected so just get braced for:

• Debates and complaints about someone taking a device someone else needs.
• Testing blocked because of a non-responding server.
• Remote testers unable to access shared documentation because of connectivity issues in your network.

Problems like this are trivial though rather annoying. Unlike with other issues, the problems with the environment are easy to predict, therefore, to take countermeasures.

In other words, you should use proactive approach and:

• Make a careful assessment of the available resources before making any commitments (e.g. agreeing about the next urgent release).
• Create the disaster recovery plans, including auxiliary servers and internet providers.

Lack of availability or openness

Efficient collaboration with your QA team is one of the factors affecting the success of your project. Therefore, you should maintain a stable communication flow with them. If you have noticed at some point that most of the questions and suggestions from remote QAs get answered after a long pause or get lost among other information, it might be time to pay high attention to this problem. Otherwise, it may lead to the following issues:

• Remote QAs get blocked when a clarification is needed.
• Various issues (environment, documentation, etc.) are not solved in time.

Small issues that keep on coming may grow into an avalanche at a crucial point. To fix the above problems we recommend the following:

Proactive approach:

• Establish regular communication with your QA team. You may follow the standard Agile practices or just establish a fixed time for a daily/weekly call so that routine organizational issues and questions would always be heard.

Reactive problem-solving:

• You should always be available when an emergency occurs. You don’t want the work to get stopped so better not to leave the team to fight through it on its own.