How to build a successful QA team from scratch?

The bare minimum that the QA team should cover is executing manual tests. These tests include:

• Interactive testing
• Integration testing
• Load testing
• Non-functional testing
• Regression testing
• Sanity testing
• Security testing
• Single-user performance testing
• Smoke testing
• Stress testing

Note that this list is missing unit testing. The reason for that is simple: in a healthy situation, unit tests are done by developers before they ship the code to QA. Your testers may need to know their way around unit tests as an insurance, but they won’t be the ones creating and executing them.

Another major requirement is working with different testing approaches. Your project will likely need both white box testing (the QA know the source code) and black box testing (the QA approaches the software just like a user would). There’s also a mixed approach — grey box testing — but doing that is certainly outside of the minimum scope. 

Automation testing specialists are expected to do exactly what their title says. This would require the following:

• Knowledge of the primary programming language / framework used for test automation
• Reasonable grasp of the programming language used by developers for the project
• Proficiency with test automation tool(s), such as Selenium
• Good understanding of the product and domain to see what needs to be automated
• Decent manual testing skills to avoid nudging colleagues for small things

There are also common skills that will be relevant regardless of the QA team structure: 

• Creating test documentation
• Writing actionable bug reports
• Analytical approach to testing the product
• Good time management
• Solid communication skills
• The ability to put yourself into savvy or clueless user’s shoes

Treat this as more of an ideas list rather than a checklist. If someone on your team or a potential candidate fails to contribute with one of these skills, it is not necessarily a deal breaker. A lot of things in QA are learned through experience, so it is just the matter of whether your product, QA management structure, and/or budget can accommodate for some early mistakes.

These skills alone, however, will not be what makes or breaks your team from day 1 and until the end of the project. You will have to look at metrics for QA process measuring the QA output in a scientific way. They will have you answer two key questions: 

• Are we on track with our QA goals?
• Are our QA results (e.g. detected defects ratio) in line with industry standard?

Look at these metrics, apply context, and discuss with other stakeholders to see if your QA is on the right path. Getting the people with the right skills is a great start, but testing still takes some monitoring and adjustment even under perfect conditions. Read on to get tips on how you can mitigate less-than-ideal conditions while you’re assembling a QA team. 

Let’s explore the four key roles when building a QA team from scratch. 

• Team Lead is the main person responsible for Quality Assurance in the company. They mostly do high-level things, such as creating and maintaining test documentation (and not just test strategy). The Team Lead also provides mentoring directly or sets up their Senior colleagues to provide advice. There is next to none hands-on testing work for someone in this position
• Test Manager is the person in charge of individual QA projects. As a rule, they are assigned to just one project and assume full responsibility for quality. Test Managers make project-specific test plans or simply make the team observe an existing test strategy.
• Manual QA Specialist is a hands-on tester that interacts with the product the most. They analyse requirements, create test cases, group them into test scenarios, run tests to find defects, report defects into a software test tool, and work with developers to resolve them. During downtime, manual specialists can do exploratory testing to improve the test suite
• Automated QA Engineers take care of the automated effort. They too contribute to the test suite and work with developers on resolving discovered defects. We’ve covered how and why you may want to adopt test automation in a separate article.

Let’s look at the key steps of building a QA team for manual and automated testing.

• Assign the responsible person. This will usually be the Test Manager reporting directly to the Project Manager.
• Assess your resources. View the timeline and requirements together with the Project Manager and the Product Owner. See whether your company has enough seniority and capacity to tackle the project. Discuss the requirements for new hires or outsourced specialists if you will need any.
• Prepare project documentation. Depending on the maturity of the company’s QA, you are looking at making a test plan based on the larger test strategy or creating the missing test strategy. These are more than rules: the description of procedures and tools will save you time on introducing new people.
• Pick the right tools for the job. Your QA suite is usually dictated by the test strategy, but you would usually want an automated testing tool for Agile teams to consolidate all the testing effort.
• Onboard the team. Present the QA documentation and how the testing workload fits into the project’s timeline. Answer the questions of the team. Make adjustments if needed.

Here are some of the challenges that you may face when building a software QA team.

• Lack of human resources. The existing QA talent pool may not be deep enough to build a new team. The natural answer is hiring new people or outsourcing some of the tasks
• Insufficient seniority. The team may not have enough experienced specialists to tackle a complex project. There could be a lack of experience with certain types of testing and/or lack of business understanding. Depending on the timeline, extra training could be a solid alternative to finding new people
• Vague requirements. Unclear scope and complexity of user stories will make it difficult to assess the QA workload and pick the right testers. This needs to be settled with the Product Owner before you proceed
• General disregard for QA. It can happen that some stakeholders view testing as an obstacle to releasing rather than a necessary effort. What you could do here is show other stakeholders, perhaps even non-tech people, the potential consequences of poorly tested releases. Bring some domain knowledge and graphs with you
• Fast-paced release schedule. This is more of a consideration than an obstacle, but you need to account for it while building a team. When software requires frequent feature updates with little time to test, you will need some hard-hitting QA specialists. Senior testers are definitely preferred to Junior ones. Test automation engineers are a must as well.

Building a QA team takes senior personnel and good planning. You need to have QA people identify the needed skills in their future colleagues and organisational support from the management to nail the scope. The better you build your team, the more polished your software will be.