Quality Assurance Engineering for any Organization size
With the constant drive toward automation, quality assurance engineers are a necessary function within any good tech organization. Finding the right candidate is becoming increasingly more difficult. Whether they’re in an office or working remotely, the most important thing is the structure of the team.
The functions of QA engineering varies based on size of the organization, nature of the engineering being done, and overall age of the business. While these may not be the only factors to a well oiled QA team, recognizing these factors can help the QA team grow effectively. By identifying the type of team currently in place or the team that needs to be built out, finding the right candidate doesn’t have to be a nightmare.
What does the QA team look like?
Everyone strives for the golden ratio 4:1 for developers to QAs, but as any good rule, this is meant to be broken. I recently had a former coworker leave for an organization where she would be one of two QAs for a developer pool of 60. The main difference being, the developers are writing the automated tests. QAs responsibility is primarily to maintain the quality of the test cases being written and maintain the framework, but are still expected to understand the full functionality of the system.
While it is a lovely idea to have a 30:1 ratio, the nature of the work being done and the application being worked on will not allow it. QA team structure is often dependent on how the engineering team is broken up. Most teams have shifted toward building out the team based on the application workflows they own. Logically, the QAs would be distributed, to those teams, at that golden ratio, if possible. From a budgetary standpoint, the goal is how to get that ratio as high as possible, while still maintaining a quality product.
What does the QA candidate look like?
In the example of the 30:1 team, the framework for the automation is written in the same language as the application being tested. This allows software engineers to quickly step in and add to the automation framework without issue. The QA engineers on the team would have to be able to maintain the framework and police PRs for both the automation and application repos, but for the most part would be able to ensure regressions are functioning and enhance the testing suite. This candidate needs to have the passion for making and maintaining the framework for automation, while having the skills to understand the application with short ramp up.
In this scenario and newer teams requiring a senior QA engineer to build out automation framework, the best kind of candidate is a full-ish stack engineer. Meaning, someone who may be on a path toward being a full stack engineer, or may be a few marks shy of full stack, but has a passion for technology. This allows the organization to get an engineer who is going to be able to ramp up quickly, but still be able to learn new skills on the job.
For organizations who are expanding further pushing out different application streams for the overall business, the QA team is typically running a bit fuller. Keeping closer to the golden ratio (4:1) is essential to keeping the positions filled. These candidates may be a little greener with respect to their engineering skills, but should be able to understand the core concepts behind QA testing. Having a QA team filled with engineers who are primed to grow within an organization is mutually beneficial.
What does a QA’s career look like at an organization?
For most QAs, they weren’t dreaming of becoming a tester when they were growing up. More often than not, it’s a position that finds you or it’s a stepping stone to the dream career. For me, it was something I grew into, and knew that was where I thrived. Originally, I had thought this was going to just be a small stepping stone, but it had turn into a bit of a passion.
For a lot of other people, this is a stepping stone to becoming a software engineer. Since that goal is the most common, it makes sense to have the QA team structured in a way so if an engineering position becomes available, the QA knows enough about the application, team, and product, that the hardest ramp up is going to be getting the IDE set up correctly.
Having a clearly defined career path for a QA is essential, regardless of the route they want to take. No one who constantly has to plan for the worst possible scenarios wants to have to think too hard on what the future may hold for them. Early conversations after onboarding a new QA engineer should be centered around what goals the QA has, both professionally and personally. These candid conversations set the expectations on both sides of the table to ensure a clear line of communication for the employee.
Ultimately…
While it may be hard to find the right candidate with all the right skills, it’s always important to remember the best candidates are going to be the ones who have a good attitude. When it comes to QA, we are more often than not, are the bearers of bad news. Having someone who is able to communicate clearly and concisely within the team are going to provide the biggest payoff to the organization.
