QA Process
Project Case Study :: Documentation
Case Study Overview
With so many complexities to this mobile app, the relationship with my QA has been instrumental to ensuring design implementation.
This app features cross-functional products and services across many user roles/privileges, is translated into 14 languages, and is accessibility compliant.
This case study talks about the QA strategies I’ve implemented within the team.
Goals
- Create a process for quality assurance that doesn’t fully rely on QA input.
- Assign values to fixes before launch.
- Educate Engineers on reoccurring mistakes or buggy functionality.
The Rating System
I implemented a rating system for what we call “design bugs.” Between 8 different developers, implementations were executed differently between products and it was too much to account for our one QA on the team.
She and I had already been meeting on a regular basis to talk about design bugs, but she came to me with concerns about not knowing what is critical to fix and what can be fixed in another sprint.
We came up with this simple rating system.
QA/Design Reviews
By educating my QA on visual design and brand standards, she’s able to be my eyes on every QA build. When she is unsure, she comes to me, and for larger product launches, we set up a time to go over screen-by-screen for inconsistencies or improvements we find and assign a rating system of priorities to fix before launch.
I use Microsoft OneNote to document bug fixes with the rating scale.
Jira Labeling
Eventaully we implimented a labeling system for when engineers were done with their tickets, they’d add the “Design Review” label so I can approve the builds before going to QA.
Results & Outcomes
Design Fixes used to sit in the backlog like a graveyard. Now they are organized within the process to prevent less critical post-production tickets from piling up. We also created dedicated sprints to close out the Design Bug 1 and 2 ratings.
Design Review Tickets Closed
%
Decrease in Design Review Failures
%