ven the best outsourced testers can’t be expected to operate the way you want them to — unless you give them a little guidance. Without that, they won’t know if you’re ok with them making up their own tests, reporting bugs the way they’ve always done it, or when to share their progress, offer testing ideas, or flag potential roadblocks to testing deadlines.

Having your ducks in a row and communicating your expectations to your outsourced testers ahead of time makes it much easier for everyone to get moving in the right direction.

To help jumpstart your planning, we’ve put together a list of five things to consider when managing outsourced testers.

Note: If you haven’t read our Setting Up For Outsourced Testing blog, you’re going to want to before you dive into these steps.

That’s because it covers how to prepare for outsourced testing, from detailing your testing process to developing product training to ensuring testers uphold security requirements — all things you’ll want to have in place before you start thinking about managing your testing projects.

5 Steps to smooth outsourced testing management

1. Choose a test planning approach that works for your product and your goals

We put this one first for a reason: What you want to get out of your outsourced testing should inform your testing strategy. And outsourced testers need to know what you want in order to deliver it.

If you want neat and tidy results for testing a highly specific area of your product:

A more scripted test case management approach would likely work better for you. Testers go through a set of pre-defined test cases and follow step-by-step instructions to determine whether a test passed or failed.

Though it ensures specific functionality is tested, it also limits the discovery of unexpected issues.

If you want a fresh set of eyes on an area of your product to uncover bugs you never thought to check for:

Take a more exploratory approach, where outsourced testers have free rein over your app, making up their tests as they go along, with their brain engaged.

This method is particularly useful for uncovering edge cases, usability issues, and real-world scenarios that scripted tests often miss. On the other hand, it makes it harder to guarantee that certain features were tested.

If you want to test specific areas for a specific amount of time:

Go for session-based test management (SBTM). It strikes a nice balance between scripted and exploratory testing in that you assign testers areas of an application to test for a certain period of time.

That way, you know you’re getting the test coverage you need but still give testers the freedom to decide how to test.

When you might use each approach

We have to start with a disclaimer here — every product and platform is different, which means they may require a different approach to testing than what might be “generally accepted” for a certain industry.

So, use these as suggestions or starting points and modify as needed:

• Finance, accounting, and healthcare applications typically require more tightly controlled testing with predefined test cases, as they’ve got strict regulatory requirements, like IFRS, GDPR & CCPA, GAAP, SOX, and HIPAA.
• E-commerce platforms might benefit from a mix of scripted regression testing (to make sure new things aren’t breaking the old things) and exploratory testing (to capture unexpected user behaviors).
• Mobile applications are a good candidate for SBTM to balance real-world usability and performance.

2. Define testing responsibilities

You know how the saying goes, “If you fail to plan, you plan to fail.” And planning isn’t just about what your outsourced testers are going to test or how they’re going to test them. It’s also about who is going to be doing what.

There are a couple of ways you could go about doing this:

Go more hands-off

One option is to delegate almost everything to your outsourced testers. Based on deadlines you give them, they decide which of their team members is testing what, and they report their results to you.

Sounds great, right?

The caveat with this one is that you really have to trust your outsourced testing partner. Do they have the knowledge and proven expertise to operate at the level you want them to?

Run a few test tests (see what we did there?) to avoid a horror story like this one in r/QualityAssurance:

“An outsourced team completely ignored the test cases. They were responsible for updating them, and never did. They had control for a couple years, and by the time it was noticed they pretty much had to be trashed.”

Go more hands-on

You could also go in the opposite direction, where your team spearheads the testing project. You write test cases, you decide who is testing them, and you measure outsourced testers’ progress toward your goals.

While this option adds predictability (you’re the one in charge!), it could limit the outsourced team’s ability to identify the unknown unknowns — you’re inserting your own biases and knowledge directly into test scripts that they execute. Not to mention it adds a lot of prep and follow-up work to your plate.

Go hybrid

In this scenario, your team offers some high-level guidance about what to test and by when, but the outsourced tester(s) have autonomy over how the testing gets done.

Your team provides high-level guidance while testers define the specifics of test execution. This is a nice happy medium, giving each party some control and opening the door to unexpected bugs or enhancements. Plus, it spreads out the work.

3. Outline the bug reporting process

Chances are you have an internal bug reporting process already. Now, you just have to adapt it to external testers.

Will they be using the same tool?

Going this route not only provides immediate visibility into testing progress, it ensures outsourced testers use the same terminology and classification you use, such as:

• Severity levels
• Reproduction steps
• Screenshots or video evidence

For most companies, this is the easiest way to integrate outsourced testers into a typical testing workflow. But it also may come with an additional cost: licenses for each outsourced tester.

Will they submit bugs in batch?

To avoid paying for extra licenses, you could have outsourced testers track their tests in a spreadsheet that gets handed off to your internal team for de-duplication and review.

But if you don’t say exactly how you want that spreadsheet to look, you could run into consistency issues. And those could require more work on the backend that lags your entire process.

Whichever workflow you choose, set up regular triage meetings or asynchronous review processes to help clarify defects, refine test approaches, and improve overall testing effectiveness. More on that in #5.

4. Figure out how (and when) you’re going to measure progress

There are lots of ways to measure how well testing is going. And people have lots of opinions on how it should be done. Just Google “how to measure testing progress Reddit,” and you’ll find a smattering of heated posts.

The thing is, there’s no one right way to do it.

Like test planning, you have to find out what metrics will give you, your team, and your boss the confidence that testing was up to snuff. Here are some ways to show that your outsourced testing team is doing the work you want them to do — and doing it well:

• Test completion rate. This should be easy to track, even in spreadsheets. It’s just how many tests were completed within a specific time period (and, ideally, in comparison to a previously stated goal).
• Pass/fail rate. This is more of a gauge of software stability than it is of testing efficiency or quality. But it does act as an indicator of something potentially fishy going on. For instance, if you’re asking outsourced testers to test an area of the product that’s notoriously full of bugs or has never been tested before, it would be weird if they didn’t report any issues.
• Code coverage, which shows how much of the application — could be in terms of number of features, lines of code (you’ll see this referred to as LOC), or number of user stories — has been tested. The greater the code coverage and the higher the pass rate of what’s been tested, the more confident you should feel about a release.

For additional inspiration, consider the metrics in this post:

But if we have one word of advice here, it’s that you shouldn’t rely on any one metric alone. A Redditor in r/ExperiencedDevs warns:

“Metrics that are arbitrarily created just make you question their validity and usefulness. I’d say that [you just need] a collective agreement to create meaningful test cases. No need to cover everything but mostly critical stuff. Coming up with exceptional cases to cover is hard. Wasting time on that just slows you down, so you push out less features.”

So, make sure you’re tracking things that actually demonstrate testing effectiveness. You’ll also need to decide when you’re going to be assessing these metrics. Weekly? Monthly? Quarterly?

Try to align reporting with when your leadership team wants an update and your product release deadlines. Once you decide on a specific cadence, try wrapping reporting into your communications with outsourced testers:

• Send everyone a monthly report so they are aware of how they’re doing.
• Add progress metrics to your weekly standup agenda.
• Enable outsourced teams to pull metrics themselves — straight from your testing tool.

That way, everyone stays on the same page throughout the project.

5. Establish a forum for feedback

No matter how much you plan, there will always be things you don’t account for, things that aren’t communicated as clearly as you thought, and things that could be improved. The same goes for your outsourced testers.

Having a way for both parties to share feedback helps you identify new opportunities and address any issues quickly (sometimes even proactively). You could:

• Set up joint Slack or Teams channels for real-time feedback.
• Have testers log feedback in your testing tool.
• Organize a regular meeting to exchange thoughts and ideas.

Though you don’t have to require a specific format for sharing feedback, this one from a Redditor in r/SoftwareTesting is a straightforward and useful template:

• This is the problem or idea. Cap it at two or three sentences.
• This is why you should care about it. Assess the possible damage or return on investing in a new process or idea as specifically as possible. Keep this part short as well.
• This is a possible way forward. Offer possible remedies or other helpful processes as a potential future solution — and be ready to hear other opinions.

A testing tool that’s as flexible as you want it to be

Just because your outsourced testing team is testing one thing now doesn’t mean they’ll be testing that same area of your product later.

And if your planning, execution, and tracking will need to change dramatically with that new type of testing, you shouldn’t have to throw your testing tool out the window — it should be customizable enough to support your new requirements.

Though we’re biased, we know that our customers have used Testpad for very stringent testing and more exploratory testing. It can handle complex test cases, allowing for notes, attachments, and time tracking. It gives you the ability to pull instant reports and save or print a copy as an audit trail.

Testpad can handle ad hoc testing, where users log their tests and results as they go. It even allows you to invite guest testers to run tests (without them needing a login).

We like to think it’s a kind of “Goldilocks” of testing platforms: it offers teams and their leaders just the right amount of structure and freedom.

Think it just might be the platform for you? Give it a try — free — for 30 days.

If you liked this article, consider sharing