Sharing Testing Responsibilities Among Multiple Teams

If you follow my blogs, you’ll notice they have a reoccurring theme: Testing. After reading some of my previous posts you may be under the impression that testing is a piece of cake. But, as we all know, most paths to greatness contain a few bumps in the road. What you might not know is that our testing effort relies heavily on collaboration with third-party vendors. Working with those vendors can also pose challenges. I want to share some of those challenges so you can get a real picture of all the moving parts in our testing process.

Everybody Hates QA

On most project teams, quality assurance (QA) is the most loathed part of the process. Poor QA can cause a product to be released with all types of bugs and issues. On the flip side, too much QA can be a nightmare for project managers and cause friction between testers and developers who don’t check their code. It’s a balancing act to get to the testing phase and even more of a feat to get through it. So you can imagine the headaches that can arise from incorporating third-party vendors into the testing mix.

One source of testing issues stem from not identifying who’s responsible for what. Clearly pinpointing which team members should take ownership of each part of the testing process is fundamental.

If your vendor is implementing new code, then you expect them to perform unit testing. Unit testing involves testing only the new code to ensure that its implementation was successful.

Simple unit testing can help mitigate regression testing, which your internal team should be responsible for. Regression testing is meant to confirm that the existing functionality still works and was not broken by the new code implemented by your vendor.

This sharing of responsibilities is definitely easier said than done, which leads me to my next tip.

Communication is Key

I know you’ve heard the phrase, “communication is key,” and that couldn’t be more true than when working with groups outside your organization. You also need to identify how you will communicate to achieve testing success. Whether you prefer to use phone, email, text, video conferencing, or discussion forums, everyone should be on the same page about where team communication and collaboration takes place. It’s your responsibility to determine what’s best for how your team works.

Daily check-ins, spreadsheets detailing what is being implemented and tested, and weekly touch point calls are just a few ways our team stays on the same page with our vendors. This can certainly be a trial and error task, but never underestimate how problematic poor communication can be for your testing team. Where and how you choose to communicate is important, but the real key is what you’re communicating.

Do you remember the telephone game? The first person in a line whispers something to the next person and so on and so forth. Typically, what the first person whispered is not what the last person hears.

Now imagine that across different teams, in different locations, using various means of communication. The message you’re trying to convey can easily become lost in translation. And just like the telephone game, it only takes one person to completely misinterpret an email and send your whole testing process into a nosedive.

Rule of thumb: Mean what you say. Be clear and concise. When possible, use imagery such as screenshots with annotations to get your message across more clearly.

It’s everyone’s responsibility to make sure that anyone involved in the testing process is using the same terminology with the same meaning. Keep in mind, when you don’t understand something that has been communicated it’s your responsibility to ask for clarification.

Everyone interprets things differently; there’s always the chance for a breakdown in communication. However, implementing a real process to avoid a communication breakdown can make all the difference in creating a smooth testing phase.

Plan for the Road Ahead

My last (but certainly not least) little tidbit is plan, plan, plan! I cannot say that enough. Your team and your vendors MUST plan in order to be successful. Plan when code should be released into your testing environment, plan when your vendors should confirm their code by, and plan when your QA team should start regression. Those are all very important parts in creating a solid testing schedule.

You don’t want to start regression testing while your vendors are still developing and you don’t want your vendors to unit test after you’ve started regression. Typically it’s the vendor’s responsibility to implement some sort of code release schedule that your team’s testers can plan for. Plan for testing far in advance to save your team and vendors time, effort, and of course, money.

Taking into account how important thorough testing is to your project’s success, it’s great to consider all the good and the bad that comes along with sharing responsibilities. Knowing the possible pitfalls only opens up opportunities for improvement within your team. I believe success can be measured in different ways. It’s not only about how much time and effort you spend on a task, but how efficient you are in completing that task.

Work smart, not hard, and success is sure to follow.

Related to: 

• User Testing