Building a Quality Narrative

The Problem

One of the biggest pain points I’ve heard across the testing community is the difficulty in demonstrating the value that testing/quality roles bring to an organization – which can lead to burnout, frustration, and even layoffs (and that’s just from my own experience!). 

I’ve always known how much value our roles bring; we see that value in the work we do every day. But over my career, I’ve seen that value proposition disappear by the time it hits leadership teams. While visibility is a complex problem that will look different across organizations, you can implement different strategies to improve the visibility of work in the organization. 

What is the “Quality Narrative”? 

The Quality narrative is taking all the pieces of work you do as a part of your role/organization and packaging them in a way that tells a story of the value of your work. As people, storytelling can be a valuable way to show impact that may not be completely quantifiable, like much of the work our role does. We can quantify things like code coverage, bugs reported, errors traced, etc. But there is quite a bit of work we do (or can do) that is not quantifiable. For example, things like bug triage/management, documentation, process improvements, etc., are not trackable by sheer numbers. But we can use those activities, in combination with quantitative data, to tell a story of how we create impact across product quality, processes, & overall engineering enablement. 

Sounds great, but what would this look like in practice? 

Example Scenario

Testing roles can vary pretty drastically, company to company and person to person. It's one of the things I love about the industry — but the nebulous role descriptions often lead to misunderstanding of the value we can bring. 

I’ve been wrestling with this idea for a while, especially after I was laid off. It was a macro version of the micro-problem I had been facing in my job search — how do I tell my story that is compelling & encapsulates the value I bring to the market? 

I landed on a single sentence, highlighting the 3 main areas I can impact with my work — test architecture, process design & optimization, & product quality.

So let’s use an example based on the work I have done previously, and how we can develop a narrative off of those main pillars. 

Product Quality Pillar

Let's start with the easiest pillar, product quality. Obviously, exploratory/functional testing, writing test scripts, facilitating bug bashes, & filing bugs are all good examples. A great data point to track is the number of bugs found before the launch vs. those reported after the launch. But what about beyond those things? 

Do you write documentation on the product and/or features? 

Do you create test data? 

Do you help with the product requirements for new features? 

Do you manage the bug triage? 

All of these are part of product quality, but are often not considered because they are not “measurable numbers”. 

One of the solutions I implemented was building a main Quality Plan document for the large features I supported. In that document, I laid out the known risks & mitigation strategies (if applicable), linked the detailed user scenarios I wrote, high-level release criteria, rollout strategy, test automation/code quality improvement opportunities, bug fix opportunities, & embedded the bug triage list for testing the feature. I used this data to provide high-level summaries for executives as well as sharing the data in our project Slack channels. 

After we launched a feature, I developed what I called “post-launch feature analyses” where I would combine quantitative data (bug fixed vs. released, code coverage, monitors, etc.) with qualitative data (asked team members to give me feedback on how the SDLC went, challenges they faced, etc). I then laid out the top problems found & proposed optimization solutions at the short-term & long-term levels. This could also be converted to be part of a retro ceremony. 

This pillar is where other ad hoc work can be communicated, like: 

• creating & maintaining documentation → standardizing practices across engineering teams, improving team understanding, improving project outcomes

• creating internal educational content/trainings → driving team understanding & adoption of tool/processes, communicating feature changes & enhancing team readiness

• creating test data → enhanced team efficiency & enabled engineers to focus on writing code

Process Design & Optimization Pillar

As I’ve grown in my career, I’ve realized I often do a lot of work in process optimization. These can be big or small changes, but they create an impact regardless. 

It wasn’t until I designed the “post-launch feature analysis” that I realized how much impact I can, and was, making on the processes that made up the SDLC. Some of the issues that came up in the first project I utilized this process in were very simple optimizations. Things like: 

• we need to align on an expectation of a single source of truth that engineers will work from so they are not duplicating their work (design team had a different process than the product/engineering team) 

• we need to track open decisions & decision points visibly for the teams working on the feature

• core functionality should not drastically change once engineering is working on it (easier said than done)

Some of these issues came up in the SDLC, and I resolved them once the problem was identified. I included that work in a basic summary of the quality work done on that feature as part of that analysis. 

There was process optimization work I was doing outside of the SDLC as well. This included:

• establishing & leading monthly observability meetings on the system I supported, sharing monthly trend summaries to highlight potential reliability & performance issues over time

• creating on-call runbooks–documents that show how to debug a system or solve specific problems–to improve incident response efficiency

• creating office hours meeting to improve collaboration & reduce rework

Technical Architecture 

I know testers of various levels of coding experience, or what a lot of people think when they think of technical architecture. While the tech stack is obviously one way to impact this area, it is not the only way. 

I consider myself a “dabbler” when it comes to coding. Almost everything I have learned has been in a work context — typically through solving a problem I stumble across. For example, writing test scripts to propose using a new tool or type of testing or investigating & solutioning testability issues. 

But there is an opportunity for those who don’t necessarily want to write code at any point. You could collaborate with the DevOps team to identify challenges with test environments & data, highlight code quality opportunities like removing “dead” code, and mapping dependencies to user experiences to facilitate data-driven decision making. 

Just remember – you are the expert in quality. That is the expertise you bring to each situation you are in!

Conclusion

The best-case scenario is this can be a top-down approach, where there is a Quality leader who can drive this narrative with the rest of the leadership, and the Quality team members drive the narrative at the individual contributor level. But regardless of the company hierarchy/structure, you can develop a quality narrative within your range of influence. 

First, develop your “pillars” or main areas of impact. Within each pillar, highlight the work you and your team are doing to create a positive impact. Share regular updates during and outside of the SDLC. For example, a monthly Slack update or email, giving a highlight of the value you or the quality organization delivered. 

The more you can highlight the main areas where you and your team make an impact, the better. 

Say it often, say it at every level. 

Document the work you do, even the qualitative work. 

Experiment with different ways to share & visualize the story until you find the way that communicates the impact you are driving.

Sidney Karoffa is a QA engineer & systems designer focused on engineering enablement. Passionate about UX, test innovation, & process optimization. Strong believer in democratizing technology & knowledge.

Learn more about Sidney and her work on LinkedIn.