How to Build a QA Team Like a Test Case

As any quality assurance professional will tell you, crafting a detailed software test case involves diligent planning, thorough documentation and accommodation of requirements. Good test cases will test whether software features and operations run as expected.

The same level of focus goes into building a QA team. To think about the task a bit more abstractly, what would a test case for building a team look like? As a manager, you must ask yourself questions, some similar and some vastly different, to arrive at the answer. Let’s get into these questions as we define our QA team in the form of a test suite.

What are your requirements?

Software has requirements, and so does your team. This is the perfect starting point, as it puts the focus on the most important areas. Answer these questions to begin to define your team requirements.

1. What is the budget?

You must start with finances. No budget means no hires. How many team members can you afford? Some companies will have an overall bank — or pool of resources — from which you can pull, and others will requisition the specific number of people you can hire. Either approach works if you have some wiggle room and the amount of work isn’t overwhelming. 

2. What is the area of coverage?

This area requires an understanding of the oncoming project and its number of complex features. It also helps to have an idea of how it will scale, which gives you an idea of the scope of the team as well as the skill sets and levels of experience needed for success.

3. What are the attributes for a great QA analyst/engineer?

Assessing the tester’s strengths is probably the most important step, albeit a subjective one. The manager makes the call here, and should have their priorities clearly defined before the first interview. 

What are the prerequisites for team members?

Finding the right talent is crucial to building a top-notch QA team. A seasoned QA manager knows that the most successful candidates possess a unique blend of skills and characteristics. From the ability to adapt swiftly to ever-changing environments to a keen eye for the smallest details, these professionals must ensure that every product meets high quality standards. 

Their technical knowledge, both of manual and automated approaches, and a collaborative, enthusiastic mindset go a long way toward team success.

Here are the four key traits that I look for in a QA analyst/engineer:

Versatility. In my experience, QA is the discipline in the SDLC that consistently deals with chaos more than any other. Unforeseen challenges can delay development and, when schedules are blown, QA teams are expected to make up for it; we are the caboose of the train. This dynamic requires a level of adaptability, the ability to listen and the patience to absorb whatever information comes down the pike.

Attention to detail. Ultimately, quality assurance serves as the customer advocate, catching errors before they create a bad user experience. QA teams need people who notice when an image is a single pixel off. Most importantly, QA teams need individuals who are not afraid to identify and speak about these issues.

Tech-savviness. Software ends up on a device, whether it’s a web browser on a laptop, a mobile device or a gaming console. When QA professionals are familiar with your customers’ most-used devices or platforms, it increases the chances of success. When I interview candidates, I ask what devices they use in their personal life. Most people are familiar with their iPhones, but a lot of gamers know their consoles like the back of their hand. This level of familiarity can be a huge asset.

Personality. I look for problem solvers, individuals who are patient but eager. This is the standard QA temperament for the most part, QA team members who look for challenges and are happy to be a part of the resolution. Communication is key, not only with teammates but with cross-functional teams, stakeholders and executives. QA professionals must be open to collaboration. They must also gain an understanding of the big picture while breaking down the parts of the whole, and that often means making compromises to support the larger group. The people who are cognizant of this may be the next leaders of the QA department.

What preconditions will allow the team to succeed?

In software test cases, preconditions describe the actions a user or system takes for the functionality to work successfully. In keeping with the theme, let’s address the preconditions that managers must be aware of to maintain team success.

1. Encourage QA team members to take ownership and responsibility for the project. It’s one thing to just do a job that someone tells you to do, and it’s quite another to drive your own efforts. The latter helps earn trust and spreads the expertise throughout the team.
2. Team members must also feel safe to fail. Managers must address mistakes as learning experiences — not as failures that require disciplinary action.
3. Make use of the talent pool. Be aware of your individual team members’ interests and strengths, then cater to them.
4. Practice transparency. People are better motivated when they know the “why.” If you give someone a list of five things to do without details, it’s just a to-do list. If you give them the context of the request, they may have fewer extraneous questions and can move forward with confidence.
5. Keep the heat off. As a manager, you work for two groups: your boss and your reports. Keep them both in the loop, but defuse any tension off your reports. They should understand the demands without experiencing the stress.
6. Evangelize. When I first started in QA, I heard from various corners of the company, “We have a QA department?” I was determined to make sure everyone knew we were there. And, as a manager, it’s up to you to celebrate their achievements. Mention team members’ names in meetings, and implore them to speak up for themselves and share their expertise.

What are the criteria for fail determination?

Even the best test cases don’t always pass. The same goes for personnel decisions. Sometimes a lack of time causes the failure; other times, it’s something completely random. And, of course, it can also be management’s fault.

Management failures include:

Micromanagement. Let employees do the job you hired them to do, and don’t hang over them like a helicopter manager. There’s no singular way of doing things. Chances are, if you trust them, they might even find a better way.

Under-management. Being too hands-off is also a problem. Team members need guidance, and sometimes they don’t even realize it. You must be available and present to support them, even if it’s just providing moral support.

Self-aggrandizement. Don’t try to be the smartest person in the room. Team members are the ones doing the work. They can speak for themselves, and they deserve the credit.

Individual contributor failures include: 

Lack of communication. Poor communication within the QA team or cross-functionally with other teams leads to failure. Your work doesn’t exist in a closed box. There might be questions you haven’t even considered.

Information hoarding. Some people feel they can create job security for themselves if they don’t share certain key bits of knowledge. What information hoarding actually does is create an overdependence on a specific team member, damaging the team’s reputation. For example, if only one person knows how to run a specific type of testing, that person will be in demand every time it’s needed. If that person is out of the office, that testing cannot be done.

What are the criteria for pass determination?

When you’ve hired and built your team well, QA analysts and engineers can achieve amazing things for the business. Here are some characteristics of successful QA hires:

• handle any device thrown at them;
• work well independently and collaboratively with teammates
• lead a project from start to finish
• offer valuable knowledge and opinions
• show motivation and investment in their career
• become a source of truth for behavior of the software
• build and maintain cross-functional relationships.

If you are clear on your intent when running your test cases for hiring, you should be able to create a team that communicates and supports each other, all while working together.