All companies that ship products always want to put out a quality product. But when it comes to identifying what parts of the equation make up the testing delivery, opinions can fly off in different directions quickly. Conversations around needing a QA team can then turn into debates about costs, tools, scheduling, resourcing, compliance, security, efficiency, and other discussions that involve a handful of choices. But once the planning and budgeting are settled, it helps to have a plan in place to justify the best QA strategy to put forth in achieving the product quality goals. In this blog, we can explore a few high-level pointers on building a well-balanced QA team around your product requirements.

Scope the requirements

Begin by identifying the requirements of the project. Determine the goals and outcomes of the project. Due diligence in understanding what the project is, what the functionality and features will be, and how it impacts or affects the customer. The requirements will determine what your blueprint will be when formulating a strategy on how to properly QA the project. Looking at the size, complexity, impact, and timing will pave the way on how you assemble your QA resources and approach for the project. These projects often involve multifold stakeholders, so it’s just as important to look at the project from start to finish and determine your test strategy at each step. (ie: testing a demonstration is much different than testing a final release). It is inevitable that the scope and timeline of the project will evolve as development begins, so by buffering 20% of overestimates into your planning, you can hopefully prepare for the unknowns coming at a later time. Pay attention specifically to the KPIs and deliverables of the project, as these will need to be broken out and tracked individually in the next stage: Developing the Test Strategy.

Develop the right Test strategy

Every project begins with a plan that guides and identifies the execution of the quality initiatives. The test strategy will assist in the identification of the requirements, such as standard tools needed for project execution, team duties, product quality target, implementation, and analyzing the outcome. Your framework should specify how communication is ordered, division of roles, and supporting the solutions made when the QA team raises issues and concerns. It also should illustrate the coordination of reporting, document risk and failover measures, and track a schedule of events performed by the team’s functionality.

You’ll want to develop a test plan that captures specific QA approaches to the strategy. The test plan should break down activity and planning around the project’s KPIs and deliverables. They should be clearly identifiable, measurable, and actionable. You can track them in; however, tool you want with agile planning, test matrix, burn down charts, etc. The test plan should also present a timeline of QA team activities and how It fits into the overall project milestones. An example of a feature:

Functional requirement Example:

Identify resources

Now it’s time to assemble the QA team. From the test strategy, you should be able to now identify what services and skills you will need to fulfill all the requests of the projects. Fortunately, in QA, there are only a handful of crossover roles that can tackle the majority of software testing projects. Structure the types of roles and quantity of resources needed to justify the work. Some of the most common positions are Dogfood testers, Test Analysts, Test Engineers, SDETs, Test leads, Test Managers, and Test Architects. These roles are much better explained by the internet, so I’ll reference a few other sites with more information:

• The Multiple QA Roles & Responsibilities in Software Testing
  
• QA Roles and Responsibilities: Who Do You Need on Your Software Testing Team?
  
• All You Need To Know About Quality Assurance Team Structure
  

Once you’ve identified the type of roles and positions needed for the QA team; next you’ll need to consider how many to hire and division of labor. Budgeting the quantity of staff is often closely tied to operating budget and availability. Create a well-balanced amount of experience. Mix your team up with seniority and leadership experience as well as strong engagement and those willing to tackle detailed tasks. Effective software testing needs a balance of critical thinking, diligent test execution, automating repeatable tasks, and sometimes after-hour research on difficult to repro bugs. Build a team of learners and mentors, but manage the team and focus on the common goals at hand. For a team size greater than 5, implement a leader who follows up with day-to-day issues but has a handle on team operations. In agile development, QA often works in an embedded environment with engineering, so understanding real-time development and testing is necessary for culture fit and implementation. Code lands quickly, so testing often requires keeping up with incoming changes and quick turnaround of defects. Your team will adjust quickly to the team dynamics and pivot when priorities and requirements change daily. By consistently communicating and staying on top of daily issues, will effectively be the key to adoption and integration of the team.

Identify tools

Selecting the right tools for the project is another key to effective communication and adoption. Most times in software development, the teams work under the same umbrella of communication and development tools. For example, if your company communicates best on slack channels, then formulate your test strategy around communicating testing updates in the proper channels, adding relevant data that the project team has agreed upon. If a dashboard of weekly project updates is preferred, then select a tool that allows stakeholders to view and comment on relevant data as requested. When automating manual test cases, work with your development team to identify the programming language and IDE they use, so your testcases can integrate cleaner into the test framework (ie: if front end code is JavaScript, then write API tests in JavaScript). While tool compatibility is not often required, it is recommended and appreciated if it’s easy to integrate and embed into the teams’ current environment. Finally, make sure your account for maintenance and support as well. Test cases often get outdated, automated tests can trigger false positive failures, and test devices often become obsolete when new hardware and OS changes. By keeping up with tools support, engineering teams will tend to trust test results and respond more positively when defects are filed and need fixes.

Training and Documentation

Requirements will evolve, stakeholders will come and go, and company tools can change for different reasons. When this happens, it’s important to keep documentation updated and stored in a place where QA teams can easily access instructions. New members will get hired, technology may change, and features get dropped. It is inevitable that test cases may fail based on irrelevance or broken functionality, and it’s not often clear if it’s a bug or a design change. Be sure to maintain documentation when major changes happen, but it’s also needed for training new members. In addition, hold frequent documentation review sessions with key project stakeholders like product managers or Program managers. Often, your documentation may expose functionality or processes that have changed in the original requirements and will need to be addressed from a higher level since a high-level decision may have changed unknowingly. Documentation is the responsibility of each QA team member, as everyone should have a specific stake in the project; they hold subject matter expertise. By documenting this information frequently, it not only holds the individual accountable for their knowledge and feedback but also can be referenced later for training and referring to historical documentation.

Conclusion

Building a QA team works best when you collaborate directly with a project from the start and build relationships with the stakeholders throughout the project timeline. Developing a test strategy will clarify the project requirements and direct your decisions on what types of resources are needed to execute against the KPIs and deliverables. Once the team is assembled, delegate tasks based on skillset, prioritization, and interest across the QA team, communicating clear goals and deliverables expected from that employee. Utilize and implement the right tools needed that demonstrate efficiency and delivery. And document all your work, regularly updating and maintaining changes when it happens. By following this simple framework, you are on your way to building out a balanced QA team!