QA Ops for a better process and tackling technical debt

One of the biggest challenges I face in my current role is handling my main responsibilities and balancing the extra work required to stay out of technical debt or to de-clutter. We’re a small team of 3 QA Engineers plus a co-op now, and before that for over a year it was just me and a couple co-ops, taking care of over 10 applications let alone Backend or Web components. Time was not a luxury we had.

One of our teams had the concept of Ops (or Operations), where they look at things besides their daily work that need to be addressed. It’s also for tackling and discussing issues that made it to production. It was a small fraction of time each week. I thought we could incorporate the same idea for QA.

Every week, the QA team now sits together and discusses areas we believe need work so we can improve efficiency, clarity, organization, processes, or anything at all. Basically, how can we as a team improve ourselves so our lives are easier and minimize missed bugs or test cases. This didn’t arise out of nowhere. There were scenarios where test cases were not run because of ad-hoc test plan/run creation and issues made it to production. We also realized our test cases, which were written by many people in multiple ways, were out of date or repetitive or confusing. We needed something to give us more discipline.

Here is a high level overview of some things we came up with:

• Test case management – updating test cases, adding anything missing, removing unnecessary test cases, benching old test cases
• Bug management – clearing old bugs, closing bugs that are no longer an issue
• Automation code cleanup – refactoring code to be cleaner, adding missing test cases, removing unnecessary test cases, improving speed of tests
• Re-organize our onboarding for testers from our outsourced exploratory testing company – improve onboarding by re-writing cycle details, minimize duplicate bugs between testers, minimize logging of already known defects, set better focus for each cycle

Each one of these has bullet points associated as concrete actionable items.

We look at each high level task and decide priorities based on what is hurting us the most and which one do we deal with most frequently. Then we break up the tasks between us and allocate a chunk of time each week to work on them. It didn’t have to be just that specific time. Any downtime we have during the week would also go towards QA Ops.

This is still a work in progress. We’re figuring things out as we go along. Will this help us? I truly believe so but I can’t say for sure without data to back it up. I don’t have that explicit data to share just yet but will be looking to add analysis in the process. Look for another post in the future with the results 🙂