Building an SQA Team in a Startup Environment
“No one can whistle a symphony. It takes a whole orchestra to play it.” — H.E. Luccock
In the startup era, many new companies are forming development teams, including Software Quality Assurance (SQA) teams. To create a proper team, we should check from another perspectives to align the team to the current business flow.
Having had the privilege of working in a variety of startup environments, I wanted to share insights on how I built an SQA team. This article will discuss the necessary preparations and key considerations.
It is important to note that the flow examples given below are not standard or fixed but come from my experience in building teams.
Precondition:
Before actually making a plan, it’s a good idea to start discussing various things to find out more about what kind of SQA is needed. Such as:
- Aligning the plan with business objectives, this will help decide which approach is better for the overall plan including costs related to tools and testing environments for SQA.
- Align with the hiring team to help you decide on a better approach to the hiring pipeline and on the level of SQA to hire (budget, open slots, etc).
Planning Items:
Without further ado, let’s look at what needs to be planned in building an SQA team.
Plan the Resource Allocation
Determining the optimal ratio of QA testers.
- 1:2 Ratio (1 QA per 2 Developers), this might suits for High-intensity projects or projects with complex testing requirements.
- 1:4 Ratio (1 QA per 4 Developers), this is most common practice for balance approach.
Allocate resources based on expertise (web, mobile, performance).
- Skill mapping by skill matrix
- Identification of Expertise
Encourage cross-functional knowledge sharing.
- Knowledge Transfer Sessions
- Documentation and Best Practices
- Rotation Programs
Plan the Recruitment and Hiring Process:
- Recruit and hire team members based on identified skill sets and roles. It would be better to use skill matrix to align with the needs.
- The recruitment flow must be short and straightforward. For example, no more than 2 stages for Junior to Mid levels.
- Make the interview process as objective as possible, such as asking right, wrong, and ending with conditional questions to find out the candidate’s soft skills.
Plan the Test Environments
Planning test environments is vital for effective software testing. A well-planned environment enhances the reliability of test results and reduces the risk of issues surfacing in the production environment.
Plan the Automation Strategy
- What to automate first?
Referring to this pyramid, the initial focus should be on API testing, as it offers greater impact and advantages compared to the UI automation approach.
- What next?
However, over time, the required focus may shift towards another approach, determined by the platform where bugs are frequently reported or occur. You can use this metric of data to help your decision:
Plan the Performance Metrics and Reporting:
SQA OKR:
- is a performance framework for aligning and tracking goals across an organization, driving synergy between individual, team, and overall business goals.
- You can see the entire detail about OKR in my other article: https://medium.com/@putraagung/how-to-determine-okrs-for-software-quality-assurance-4f295e80d588
Test Coverage:
- Percentage of the application that has been tested. It measures the extent to which your tests cover the features and requirements.
- The coverage also means how many scenarios that have been covered by automation.
Defect Density:
- To measure the density of defects per test case, providing insights into the quality of testing relative to the number of test cases executed.
Testing Progress:
- Testing progress details include the assigned QA, Jira ticket, ticket status, SQA story points, number of defects under each Jira ticket, and the number of test cases associated with each Jira ticket.
- *This can be performed using Jira Filter and Dashboard.
Defect vs Bug Comparison:
- To assess the quality of testing at the conclusion of product implementation and gather feedback as part of the process for generating action items.
- Defect vs Bug should consist of:
- *Assume Defect is Staging issue, and Bug is Production issue
Closing Thoughts:
What is described above is an outline of how a leader makes a plan to create a good SQA team.
There are still many other things that need to be planned so that the team is more perfect, such as defining the testing process and methodology, implementing Software Testing Life Cycle (STLC), implementing a good quality culture, and so on.
What really needs to be done is to communicate with stakeholders and the development team so that they also understand the concept of establishing SQA and can comply with the business plan they are building.
Don’t think you are alone when faced with a plan, especially if the plan is for long-term implementation. Mistakes in planning can disrupt stability and harmony between the SQA team and other teams.
Happy planning!