Managing a QA Team for the First Time

Problem

For quite some time, we were using an offshore QA team based in India. A year ago, we decided to terminate the contract and bring all our QA efforts in-house. Though QA and Development were kept separate in the past, it was decided that an in-house QA effort will report to Development. The rationale behind the new organizational structure was that since QA worked closely with Development, it should report to the same manager.
 

However, as a manager, I had scarce knowledge of QA; I had never been a QA engineer and had no knowledge of tools and processes they were using. Furthermore, since we were not working anymore with contractors, I had to start hiring for QA roles. I had no idea what to look for in candidates and, once hired, how to onboard them.
 

Actions taken

First off, I deep-dived into the code and explored the existing automation. I was not happy with what I found. A lot of failed test cases were not cleaned up, many irrelevant features were still being tested, the whole process was very inefficient, difficult to maintain, and unscalable. Since that was the only automation framework we had, I had to fix it first before advocating for building an improved framework.
 

I started by removing some tests that were no longer relevant and fixing those that were meaningful. Upon deep-diving into the code, I encountered an unfamiliar QA framework and programming languages I never worked with before. Surprisingly I felt confident because I am a natural hacker. I am not the most skillful person when it comes to building things from scratch, but I am an outstanding hacker.
 

It didn’t take me long to familiarize myself with QA in general and be able to interview incoming candidates and assess their skills. In the end, we hired three senior QA engineers, and I relied on their expertise to further improve my knowledge of QA.
 

With their feedback, I felt confident that we should get rid of the low-quality QA framework developed by the contractors. I wanted us to build a new scalable and reusable framework. I encouraged our recently hired senior engineers to architect the new framework, and I was overseeing and managing the process from a high-level perspective. Finally, we managed to migrate from the old framework to the new one successfully.
 

Lessons learned

• When you are switching from one domain to the other, don’t be hesitant to deep-dive into a new subject matter. Try to familiarize yourself as much as you can with the new domain through reading, talking to experts, and of course, rolling up your sleeves.
• Building a team from scratch is particularly taxing when unfamiliar with tools or technology. You need to acquire at least some basic understanding of tools and technology to be able to hire people who will later bear the brunt of executing the work.