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 in a software development team working on a digital product for an external client. This is a typical scenario for us, where we build engineering teams for external clients.

Previous Approach

Initially, the only interaction between the QA and the UX team was an Estimation Session with the Development team. That was the moment when the newly designed tickets were presented to the whole team for the first time. Questions were asked regarding the implementation of 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, it was not enough. First, it did not provide us with all the information and time to design test cases. Second, the necessary time to run them against the UX design was already short. Lastly, documenting them so that the Development team had them available by the time they picked up the ticket was also a challenge.

Building the Bridge

We had as a goal a left shift, 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 without disrupting the UX team. There, we found the Feature Presentation meeting was the ideal candidate for the job. During this meeting, the client discusses with the UX team the presented designs, 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 there was even a ticket in the backlog. So now, we had 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 we can add the Test IDs to the design, and I loved this idea for two reasons:

1. Test IDs are in place and available from the beginning. The Development team can put in place all we need to automate the test cases.
2. Additionally, we know what to expect and start building the automation at the same time 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 is what I believe could be the last major change we need to make to our current workflow to achieve our goal. After this is in place, we just need to 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!