My QA Journey

When I began one of my first internships as a 19-year-old Functional Tester at Jack in the Box, I didn’t even think I would eventually end up working in tech. I recently got promoted to become a QA Lead at Transpire (a digital consultancy) 🎉. This made me reflect on my last 10 years and how I ended up here. I wanted to share my lessons and at the same time, highlight the colleagues who have helped me get here.

Lesson 1 — The little things matter

Over the last 10 years, something I have enjoyed the least is documentation (not a surprise). Like many testers, I prefer doing the actual testing more than writing test cases, test plans, bug tickets, or Slack messages. Yet, documentation has ended up playing a big and important part in my role as a QA. Writing detailed bug tickets has helped developers debug easier at a later time while writing detailed test cases has helped other QAs onboard onto the project easily. Additionally, I consider test plans as a team-approved source of truth for QA-related activities when it comes to the scope of testing and process. If anything ever diverges from it, a detailed approved test plan can always help mitigate those issues.

Along with details in the documentation, the little things that matter include asking questions and being curious regardless of how insignificant you think the question is. Even when your question or observation does not seem substantial to yourself, different minds may uncover something missed or undefined.

With automation tests, it’s important to keep a consistent coding format and ensure that test class names and IDs are easily understandable and consistent. This helps with the overall maintenance of the tests and allows other people (both Developers and QAs) to easily be able to pick up these tests.

Shoutout to:

• Doug Bark (my first QA manager) who introduced me to the world of testing when I was a Functional Testing Intern (and corrected me when I thought QA stood for Quantity Assurance 😂)
• Gimmy Chu for encouraging me to be curious and ask questions (especially technical)
• Cam Liston who taught me the importance of succinct documentation
• Jaswanth and Kelly Wason for teaching me all the best practices in automation testing

Lesson 2 — A QA’s role is not only to find bugs but to help drive the overall quality of the product and user experience.

What makes a bug, a bug? Is it only a failed requirement? Is it a missed requirement? What if there is a very confusing user flow? Whose job is it to find bugs?

Finding bugs is not only the QAs role and not the QAs only role. In my previous articles, I talked a lot about how QAs can help drive quality as a team and that quality is a team responsibility. The earlier that QAs can be involved in the software delivery cycle (such as discovery or refinement sessions) the earlier QAs can raise questions, concerns, and issues.

Working as a Project Manager at Harvest Digital Planning taught me how to empathise with the clients and the end user of the product. Since I was involved in both the development/testing phase as well as the account management side, I felt accountable for the quality I delivered directly to the client. If I had delivered something that didn’t work as expected or was difficult to use, I would be the direct contact. This then forced me to focus more on spending time testing the features we built and the overall usability before handing it over.

Shoutout to:

• Adam Smith and Brian Ashton for mentoring me and allowing me to explore a role that works end to end from the discovery phase to delivery
• Beth Henderson, Ben Ross and Paul Greenwell stressing the importance of understanding end users needs before building a product
• Jo Tan for teaching me the importance of design in user experience and helping me incorporate it into the QA process

Lesson 3 — Developers are QAs biggest ally (other than other QAs)

I have to attribute most of my growth in both my technical capabilities and testing capabilities to working with the best developers throughout the last 10 years. I have learned something from every single developer I have ever worked with.

While working purely as a manual QA, one of my first projects was testing a middleware project that focused on moving a ton of fast-flowing data from a relational database to AWS serverless shiny technology. It was overwhelming trying to understand the AWS resources and how a manual tester could test something without an actual user interface. With close collaboration and a lot of help from developers, I learned a tremendous amount about AWS to the point where I was able to finally start probing questions and recommendations in refinement sessions. More importantly, they valued testing and never put it as an afterthought when in refinement sessions or while building.

Shoutout to:

• Luke Hill and Justin Bush who taught me a lot about testing in AWS (and in general) and the best ways for developers/QA to collaborate
• Pete Nguyen and Matt Whelan for giving me the confidence to try out and drive QA processes within teams
• Alex Eggers for teaching me how to set up automated Android UI tests step by step

Big thank you to everyone I have ever worked or collaborated with…

For me, the best part of being a QA is that we sit at the intersection of Developers, Designers, and Business Analysts/Product Owners. Being able to work with talented teams and clients from all disciplines has helped me learn as much as I know today. To add to that, being able to converse and collaborate with the wider QA community has taught me more than I could ever read or study about.

Lastly, shoutout to the entire team at Transpire for encouraging and supporting my transition into my first QA Lead role.

QA, here is to the next 10 years. 🥂