You are here

You are here

How to build a rock-star QA team using test coverage methodology

public://webform/writeforus/profile-pictures/fritz.png
Michael Fritzius President, Arch DevOps, LLC
 

Growing your quality assurance (QA) team can be daunting. You may need to consider dozens of different options that span multiple dimensions, such as languages or functionality. It may seem like an impossible task to find—and hire—those few candidates who can do everything.

So you struggle and drag your feet, hoping that a unicorn will pop up. But somehow you never seem to hit your goals. As a result, quality suffers and product shipments get delayed.

There is a better way. Apply what you already do with testing to the hiring process. Using your test coverage methodology when hiring will make it easier to grow your team. In the process you'll build a team that has quality skills in all the right areas.

Here's how to do it.

[ Learn best practices for reducing software defects with TechBeacon's Guide. Plus: Get the report "Agile and DevOps Reduces Volume, Cost, and Impact of Production Defects" ]

Avoid the groupthink trap

There are a lot of risks in QA testing. The obvious ones are scary: You miss a bug and it turns into a multimillion-dollar lawsuit. Or you make a substantial investment in QA to avoid the bugs, only to have the business side deem your accomplishment a waste of money.

But some risks are hidden, and a big one is falling into the groupthink trap. This is when everyone on the team thinks the same, works the same, and tries to solve problems in the same way.

In QA, you're always going to be finding new problems your team has never encountered before. And when these problems require new solutions, you're not going to solve them by saying, "That's just the way we do it here." If the old ways had worked to begin with, you would have already caught the bugs and they wouldn't be a problem.

As a result, you have to come up with new ways to address those challenges. Often, that solution can come from understanding past experiences with another client, language, or industry.

Testers who have seen similar problems with a different client, or on a project from 10 years earlier, will be able to apply that knowledge to your current issue and help you solve it faster.

But you shouldn't be looking for testers who've done everything. That's an unrealistic requirement that will cause you considerable delays and cost you big dollars. There is a better way.

Hire team members who vary in their experiences

Remember, you're building a team of specialists, not a group of individual contributors. You want professionals who will add to the skill base in different ways.

In a music group, you don't have four people playing drums and guitar and singing all at the same time. On a basketball court, you don't have five guards or five centers. Someone who plays guard won't make a great center, and vice versa.

You need a variety of skills and abilities on your QA team, too. A great way to get those differing skills and abilities is to look for testers who have varied experience.

[ Understand what your team needs to know to take advantage of test automation with TechBeacon's Guide. Plus: Get the Buyer's Guide For Software Test Automation Tools ]

Define your skill gaps, and seek to fill them

The place to start is with a gap analysis, and your first step should be to create a needs map. List out all the tasks you want your team (not just one individual) to perform: functional testing, penetration testing, etc. Or consider the types of clients you work for: small businesses, large businesses, and the like.

Do this for multiple characteristics. I recommend choosing at least five that you think will have the biggest impact for your company and your clients. These might include:

  • Technology experience: Desktop software, mobile apps, web apps, internal software
  • Types of organizations supported: In-house, contract, outsourcing, partnership
  • Experience in company of your size: Startups and small, mid-sized, and large companies
  • Experience with different types of testing clients: Startups and small, mid-sized, and large companies
  • Usage testing experience: Functional testing, security testing, speed, load/performance, boundary cases, corner cases
  • Development methodology experience: Agile, waterfall, fragile
  • Testing experience: New to the industry, some experience, mid-career, decades
  • Locations/metro areas where they've worked: Silicon Valley, innovation hubs, rural communities, urban centers
  • Languages: Java, Python, Ruby, .NET
  • Industry sector experience: Finance, medical, cloud computing, education, agriculture
  • Personality type: Leader, follower, cheerleader

Next, take a look at how much of this needs map your current team covers. It can be as simple as creating a matrix of skills checked off by various team members (or, for new teams, candidates). What's left uncovered is where you should be spending your time searching.

Finally, whether you're looking to expand your team or build one from scratch, you need to evaluate your candidates to learn which ones cover most of your matrix.

There are a lot of combinations to consider. Suppose you have a short list of 10 finalists for three positions, and all have the minimum required skills (such as knowing Java and having been working for at least two years).

Of those 10, you have 120 different possible team combinations you could select. Which of those teams would give you the best coverage across your most important characteristics?

Looking at teams in this way gives you a perspective that you would miss if you evaluated candidates only via an individual ranking compared to one another.

The big thing to remember, though, is that you’re not looking for any one candidate who can do everything. You’re building a team, which means that you don’t have to try to find those few people in the world who can do everything. When you do it right, you’ll have all the languages you need covered, for example, even if every person on your team is only good with one or two of them.

When you build your team using the test coverage methodology, you’ll be better prepared for those unanticipated problems. And you’ll avoid that groupthink mentality that often inhibits teams from quickly solving problems.

Map out your approach

When you apply test coverage methodology as you build, you will have a more comprehensive view of your team's skills and experience, and you will be able to solve a broader array of testing problems from the start.

To begin, create a needs map and build a matrix of your current coverage of those need areas. This will expose the gaps you need to fill. Then evaluate your candidates based on those holes. 

Applying test coverage methodology to your hiring process will give you a better team and result in a better process and product overall. 

[ Practice quality-driven development with best practices from QA practitioners in TechBeacon's Guide. Plus: Download the World Quality Report 2019-20 ]