One of my favorite characteristics about QA experts and testers is our everlasting dedication to speaking up when something isn’t right. This is a blessing when stakeholders agree with the concern you raised, and it’s resolved or planned for resolution in a release. And it’s a curse when stakeholders do not agree with your concern, and you walk away feeling like quality justice was not served.
In most cases, testers are the first users of features and end to end experiences in your software. Even when other testing is executed by users or designers, that testing is typically more focused on only parts of the application and is not necessarily a wholistic view of features when they are put together.
Our goal as testers is to not only uncover bugs; but we also advocate for the user experience, and we care about having a positive impact on how well the software development process is functioning.
How do we truly advocate and influence quality when we have a need to balance both working towards the best user experience with the need to have an efficient development process?
There are three solid ways to organize around advocating for and influencing quality:
- Practices…you have practices that support what you want to achieve.
- Knowledge…you have a solid understanding of how software is built, quality processes, and are experts in your software.
- Caring…you care about quality, and you want to foster others to care and take action.
An effective way to get others to feel and believe that quality is attainable is to show them that you can drive towards desired outcomes with strong quality practices that you have ritualized on your team.
An example of how you can do this is by having a solid test planning process. A positive outcome here would be that testing planning supports good habits like refinement and early testing.
Our team has a flexible, iterative, and transparent way to plan for testing new features. We create Quality Plans (QPs), which are a hybrid between a detailed test plan and detailed test cases. QPs are intended to be a lightweight way to document and communicate about what we are testing. They are created early-on in the development process and we use them throughout for refinement, early test execution, automation, and to eventually grow into detailed test cases. The intention is to bring agility into test planning, and they are a required step in our development process (other than some exceptions).
Our test planning process is an embedded part of how we work, and all stakeholders are brought into this. This QA practice fosters everyone caring about quality from start to finish.
The goal is to have QA practices with roots in repeatability that become a normal part of planning and development conversations. These influence quality by becoming a part of every planning conversation and not just one offs. Other practices could be standardizing use of Jira for all deployed work, QA involvement from the start of a project, and standard functional automation frameworks.
If you want to have influence over others, it helps to know what you are talking about; not only because you are a credible resource, but also because you can use critical thinking to apply what you know to just about any situation.
On our team, we apply this in no clearer a way than test execution planning. A typical part of our day or week is to plan testing for upcoming feature branches, a major regression testing effort, or a normal release candidate validation cycle. These test runs have many different success criteria, but we usually need the following:
✔️Broad testing coverage of the application surface.
✔️Deep testing coverage of the changed area, new thing, or high risk areas.
✔️A short break/fix cycle with Product prioritizing, Development fixing, and QA retesting.
✔️A delivery timeline to hit!
Each criteria above requires our QA team to have strong knowledge in: 1) software development methodologies; 2) QA and testing methodologies; and 3) a very strong understanding of how our software works, what areas are fragile, what changes tend to create breakage in other areas, and what has historically been problematic.
Our QA team is consistently involved in conversations around test planning for team deliverables. Being highly knowledgeable in order to speak to what is best for our products and releases while always considering quality is an influence on how others also see quality. We show them by executing on what we know best, that quality belongs to all parts of a project and others can use their areas of expertise to do the same.
Showing you care about something is a great big influencer. One of the dictionary definitions is: feel concern or interest; attach importance to something. I’ve never met a person working in QA or testing who doesn’t passionately care about quality…we have made caring about quality our career! It’s not always glamorous to fight (hard) for getting that minor bug fixed, or explaining why something is a very major issue even if others do not see it at first, however, we do this over and over because we deeply care about releasing the highest quality software possible and about the experience our customers will have while using our software.
Why does this have an influence over others? An easy way to see this is by looking at the opposite scenario. How much would someone care about quality if we didn’t show how important it is? Of course other people do care about quality without someone else telling them to, but it becomes a multiplier when you demonstrate that you are staunch about a subject.
Quality teams have a big impact on how quality is viewed at your organization, and a best case scenario is when we can have a strong influence over quality with actions and behaviors.
I am grateful to work for an organization who is all-in on quality. Our team is empowered to implement embedded quality practices, utilize our expertise while continuing to grow, and we freely show how much we care.
Leaning on your QA team to advocate for quality is normal, but quality comes much more naturally when actions and behaviors influence others and how you operate.