QA Chronicles, Part Three — Reaping the Rewards of Transformation

Jose Perez
GBH.TECH
Published in
3 min readSep 3, 2024

This post is part of a series named “QA Chronicles”, where I present our experiences in improving Quality Assurance (QA) practices within a software product development organization. Although with a focus on real-world experience, we believe these practices can and will be reused in other endeavors. In this series, we will present the different strategies we implemented to improve the Quality Assurance practice of a software development team working on a digital product for an external client. This scenario is typical for us, where we build engineering teams for external clients.

If you haven’t seen any previous posts, I recommend you check them out for a broader context. Here are the links:

It’s been three weeks since I returned my manager hat after this insightful ride. This was the kind of experience that changes your perspective about how to approach everyday problems, and in this case, I want to share the impact of the implemented changes on this and other projects.

Collaboration between QA and the rest of the team

The QA team was able to regain the team’s trust by implementing a consistent testing process that focuses on making sure everyone has the information they need when they need it. In other words, the documentation is clear and reflects what the team does, not the other way around. Also, the automated tests run in the defined moments. They are always available and functional, allowing the team to rely on these to decide if a change is ready for further testing from the QA engineer.

Additionally, the team feels confident enough to try new shift-left gradual implementations, which means they can handle whatever issues might arise from doing something new.

The QA area

We concluded that the current QA Review process needs to be improved. During this review, I would check a project’s documentation on the QA side and its automation to identify improvement opportunities and give that feedback with pertinent recommendations to the team. Still, these flags usually result from something else, so we need to treat these flags as alerts of a more significant issue, identify the root cause, and guide the team to a solution.

Test Automation

By far, the most outstanding improvement achieved was the early implementation of test automation, as we could test and prove that it would save many hours for the whole team. The automated smoke tests that run for every PR have caught an incredible number of bugs before the ticket is sent for code review, increasing the velocity of the feedback loop with the development team and freeing a lot of time for the QA team to add more test cases to the full regression and to do more exploratory testing in the application.

This smoke suite doesn’t need to have dozens of test cases; in fact, it shouldn’t have more than 5 or 6 on your average start-up application. What matters is which ones you choose and how easily a developer can identify and debug the issue if there is any. If you take the time to get this right, it will free you a lot of time to do more of the stuff that delivers direct value to your stakeholders.

Teamwork

Finally, we understood that we need to bring closer all the disciplines that intervene in the development workflow and make sure we collaborate from an informed perspective, knowing what should or shouldn’t be expected to be handled by each role and making sure we all always agree and are aware of those responsibilities. This is the one thing that will prompt the most significant changes in all areas, as we will need to figure out and implement explicitly in our processes how we can help each other area to deliver as much value as possible.

Conclusion

We often convince ourselves that we cannot achieve certain things, that only very large corporations or very mature teams can have decent automated pipelines, shift-left approaches, and try out new things, but sometimes, it is the implementation of those things that allows a company and a team to grow exponentially.

--

--

Jose Perez
GBH.TECH
Writer for

I am a QA Manager with +8 years of experience in +10 different projects. Let's explore the Software Quality Assurance world together.