QA Chronicles, Part Two: Bridging QA and UX for Better Outcomes
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 I 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 the previous post, I recommend you check it out for a broader context. Here is the link: QA Chronicles, Part One: Building a QA foundation
Five months ago, I traded my manager’s hat for a tester’s headset, diving right into the depths of a challenged team. In the previous post, we navigated through the findings during the first months and the initial changes we implemented to improve the team’s performance and quality. Now, let us talk a bit more about a crucial step in our shift-left approach: forging a solid connection between QA and User Experience (UX).
Previous Approach
Initially, the only interaction between the QA and the UX team was an Estimation Session with the Development team. That was when the newly designed tickets were presented to the team for the first time. Questions were asked regarding implementing these changes, and the discussion about each ticket was focused on understanding how to implement it into the current codebase. The QA team would also participate in the estimation to provide testing insight and adjust expectations, as we have more overall context of the effort needed to complete past tickets.
Although this was good, more was needed. First, it provided only some information and time to design test cases. Second, the time to run them against the UX design was already short. Lastly, documenting them so the Development team had them available by the time they picked up the ticket was also challenging.
Building the Bridge
We had a left shift as a goal, as it would increase the product’s overall quality. As such, we looked at the current UX process to see at which point the QA team could get involved without being too time-consuming and disrupting the UX team. There, we found the Feature Presentation meeting was the ideal candidate for the job. During this meeting, the client discusses the presented designs with the UX team, asks for changes, requests new things, and extensively explains the business reasoning behind the requested features.
This was awesome for us because, while this discussion was taking place, we could identify test cases, provide input about current behavior and constraints in the existing business logic, and ultimately, have a deeper understanding of the features and their purpose. Also, this usually happened way before a ticket was in the backlog. So now, we have plenty of time to document the test cases and add them to the tickets when created.
Extending the Bridge
As this team is using Figma for the UX designs, it struck me that it allows adding attributes to the elements so that we can add the Test IDs to the design, and I loved this idea for two reasons:
- Test IDs have been in place and available from the beginning. The Development team can implement everything we need to automate the test cases.
- Additionally, we know what to expect and start building the automation simultaneously or even before the Developer starts working on the changes.
This works as a QA process for the UX design. This approach forces the QA Engineers to look at each screen and all its elements in the design, making it more likely to spot design errors and to play out each scenario that will be automated with the design, making sense of them before they are implemented. This last part is still a work in progress. We still need to define at which point and how we will carry out this new task, but the team is on board with the idea, and meetings are already set up to discuss this approach.
Conclusion and Next Steps
This could be the last significant change we must make to our current workflow to achieve our goal. After this is in place, we must adjust the details and get used to the approach. In a couple of weeks, we will post the last part of this series to lay out the full scope of what we achieved with these changes and what we learned from all of this.
Stay tuned!
