🫱🏾🫲 Quality Experience: How to Introduce QA Practices to Your Organization
🖥️ Whether your tech stack is brand new or teetering with age, any time is a good time to introduce Quality Assurance practices within your organization.
What do I mean by QA practices? For this article, QA practices are defined by specific standards set within an organization that increases the product's efficiency, and quality and reduces communication confusion when bugs or defects are discovered during the development process.
Wait, why didn’t you say “best practices”? I avoid the word “best” because “best” could be applied to any type of practice that hasn’t been verified or fully vetted. It’s a word that’s easily applied but hard to prove. This idea comes from one of my favorite talks by Viktor Slavchev in his talk “‘Worst’ Practices of Software Testing”. This a recommended watch for anyone wanting to learn about the QA process.
I’ll approach these practices in a more holistic sense. Creating processes that provide clarity and ease of use is more likely to be embraced by those within your organization.
We’ll discuss:
Empathy
Documentation
Process
Mindset
🌊 Let’s dive in:
👂Empathy - “I believe you.”
Creating a thriving QA culture needs to begin with empathy. Our users can be anyone from our clients to the developer building the feature. As unfortunate as it feels, when a developer says, “It’s working on my machine” that’s absolutely true! Their process and their environment shape their experience. This is true for the end user as well. When a report comes back with a user stating that something is broken, we can fully trust that their process and their environment is shaping their experience. Where communication breaks down is when we take both the process and the environment as truth. These are variables, not elements that can’t be changed. When any user comes to the QA and says, “This is what I’m experiencing”, continue the conversation by believing them. (And, devs, if a QA says that it’s broken on their machine, believe them.) Beginning conversations with empathy fosters conversations of openness and curiosity - which leads to solutions for all users working with the end product.
🗺️ Documentation - “This is the way.”
Each tool a team embraces and process applied in the SDLS should have documentation around it. The documentation should include why the tool or process is chosen and how it should be used throughout the organization. Documentation should be clearly written, accessible to the appropriate teams, and organized for easy discovery. This also includes documentation that covers the application the engineering team is creating and how it should operate for anyone using it.
Yes, documentation can become stale. Giving teams the freedom and time to update their docs often helps keep them up-to-date and evergreen.
🥾 Process - “This is the how.”
Do your users have a way to report issues? Does everyone in your organization know how to report a bug if found? Creating defined processes for every type of user paves the way for clear communication when bugs are discovered. Who is the person responsible for triaging issues that come in? Do you have channels dedicated to bug reports and status updates? Included are some easy ways to report, triage, and find resolutions for bugs reported:
Create a system for end users to report bugs and make this system clear and available so they won’t spend time hunting your site on how to make a report.
Within your organization, set up a form using Google Forms, ClickUp, Shortcut, or any tool that your team already uses. Again, this form should be easy to access when a bug is discovered.
Set up specific communication channels that are dedicated to bug reports. To avoid unnecessary noise, limit these bug reports to reports with higher severity levels.
Elect specific people in your organization to triage and troubleshoot bugs as they are reported. This can be anyone from the Support team, the Product Management team, or the QA team. Clearly defining who will do this helps keep “too many cooks out of the kitchen” when a bug is reported
Define when status updates will be given on high severity bugs. This can be anywhere from 15 minutes to an hour. Lower severity bugs can have an increased time span since the issue may be more annoying than limiting functionality for the user
🤔 Mindset
Taking a note from Ted Lasso, “Be curious, not judgmental.” When issues appear (in any software or process), it’s easy to start the blame game. It’s much harder, but more helpful to start the problem-solving game. Begin by asking questions - what browser is the client using? What type of device is in use? Is there any event within the tool suite that could be disrupting the use of the application? So many variables can disrupt a user’s experience. Being curious will open far more paths than blaming a team within the organization.
Making these changes within your organization may feel nerve-wracking in the beginning. Choosing to change what’s always been done will create an environment where users can speak freely when issues arise and team members can find and fix what prevents a smooth user experience for your clients.
What practices have you introduced to your organization that has increased efficiency and connectivity with your users? I would love to hear your thoughts.