How we're setting up QE's to fail

How I Think Quality Engineering, Glue Work And Quiet Quitting Are Related and what we can do about it!

I believe modern context-driven testing is the right way to go. However, I believe the way we're setting this up dooms people to burnout and failure. I'd like to change that!

This is probably more readable on my blog post: https://typeshare.co/vernonrichards/posts/how-i-think-quality-engineering-glue-work-and-quiet-quitting-are-related Quality Engineering, Glue Work and Quiet Quitting. I think these topics are related and often not in a good way. They didn't seem quite disconnected at first. At least, I never really thought about them together until I ran into the topics together, in a short space of time. And now I can't stop thinking about them! I think the relationship can explain some things that QEs have to deal with. Allow me to elaborate! What Is Quality Engineering? Is this just a fancy pants term for testing? I don't think so! Some people do and that will come again later. I describe testing, at its core, as being primarily concerned about interacting with the product. You'll probably be interested in understanding the context in which testing (and software development) operates but you if you can't influence it, you can manage. Quality Engineering seeks to influence the context that software development and testing occurs in, with the hopes of increasing the chance that you have a quality product or service at the end. I've noticed that the more experienced you become as a Tester, the more you seek to influence the system to make the testing work more effective, whereas Quality Engineers are often expected and encouraged to do that from the outset. Remember that last part too because it will be important 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. In the story, our intrepid newbie solves the following problems: - She helps important customers when no-one else will and documents what she did so her team is interrupted less often. - Facilitates a discussion between key stakeholders that are talking past each other and gets the delivery unblocked. - Identifies that their 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 probably looks familiar to the Testers and Quality Engineers in the house! Interestingly, Tanya calls this work Technical Leadership and the big problem for the heroine of the story is 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. Particularly 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 and/or promotion and a big "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/or others expectations. - Doing work over and above your job description for no recognition is tiring and people are opting out of that. I think 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 and people don't recognise their contribution. Even when it actually adds value! Whichever case it is, it gets old real 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 key. Are we setting the right expectations in our orgs so that the 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!