I think these topics are related and often not in a good way.

They seemed disconnected at first. I never really thought about them together until I ran into the topics in a short space of time. Now I can't stop thinking about them! This relationship can explain some things that Testers & QEs have to deal with.

Let me explain!

What Is Quality Engineering?

Is it a fancy term for testing?

I don't think so! Some people do. At its core, I describe testing as primarily concerned with interacting with the product. You'll probably want to understand the context testing (and software development) operate in, but if you can't influence it, you can manage. Quality Engineering seeks to influence the context software development and testing occurs in, hoping to increase the odds of having a quality product at the end. I've noticed that more experienced testers seek to influence the system to make the testing more effective. Quality Engineers are expected to do that from the outset.

We'll come back to that later!

What Is Glue Work? 

When glue work doesn't happen, the project/product fails.

Tanya's brilliant presentation tells the story of a new software engineer who:

• Helps customers when no one else will and documents what she did so her team is interrupted less often.

• Facilitates discussions between key stakeholders that are talking past each other and unblocks delivery.

• Identifies the lack of unit tests makes the codebase unmaintainable, unreliable and prone to outages. She adds tests to eliminate those problems.

• Facilitates design reviews, raises pertinent questions and disseminates the resulting information to stakeholders.

This work no doubt looks familiar to Testers and Quality Engineers! Interestingly, Tanya calls this work Technical Leadership, and the big problem for the story's heroine is that none of that work was explicitly part of the job description!

You might see where this is going!

What Is Quiet Quitting? 

It's a term coined to describe employees sticking to their job description and not over-delivering.

Mainly since the pandemic, but no doubt before that too, folks are literally and figuratively tired of going above and beyond for little to no recognition. It's a "NO!" to more work without a pay rise or promotion and a "YES!" to less stress and increased work-life balance.

People are sick of being frowned upon for choosing to do their jobs.

Quality Engineering + Glue Work + Quiet Quitting = ? 

Let's put it all together!

I've described the following:

• People trying to influence the system, so software delivery becomes more effective and better products become more likely.

• This work is Technical Leadership, and it often occurs outside the job description and others' expectations.

• Doing work over and above your job description for no recognition is tiring, and people are opting out of that.

This is a situation that many, Many, MANY, MANY testers and quality engineers find themselves in. Either they're not "staying in their lane" (experienced tester!), or when they do (quality engineer!), they're doing it without explicit authority. In both cases, people don't recognise their contribution even when it adds value!

Whichever case it is, it gets real old fast 🙁.

What Can We Do About This? 

Honestly, I don't have any great ideas right now!

I think what happens at the outset is critical. Are we setting the right expectations in our orgs so that peers of experienced testers and quality engineers aren't surprised when they start doing work that isn't "interacting with the product"? What can the folks managing them do to help? What can they do to help themselves?

All ideas welcome!