So spot on! I moved from QA to Engineering leadership about 10 years ago because I got tired of trying to test in quality when all my teams could do was test out bugs. I thought I was going to head off quality problems at the source. It took me several years to figure out that I was engineering the quality system.
I agree, do you have any actionable advice for people who test but aren't in a position to alter the goal from producing a lower quality product to a higher quality product that doesn't need to be tested as much?
This is a hard position, and a lot of testers spend their entire careers there.
The most useful thing you can do without formal authority is make the cost of low quality visible to the people who set the goals. Not "we found 47 bugs" but "this issue delayed the release two weeks" or "this bug affected X customers." When quality problems show up as business problems, the conversation changes.
Within whatever scope you do control, raise the bar anyway. Build relationships with developers who care. Name tradeoffs explicitly when you're asked to ship something that isn't ready. Put the decision where it belongs wherever you can (and avoid absorbing accountability for outcomes you can't control).
The system usually won't change until the pain gets bad enough. The best thing you can do in the meantime is to make sure the right people understand what's causing the pain.
So spot on! I moved from QA to Engineering leadership about 10 years ago because I got tired of trying to test in quality when all my teams could do was test out bugs. I thought I was going to head off quality problems at the source. It took me several years to figure out that I was engineering the quality system.
I hope everyone who reads this gets this takeaway. Thank you for reading.
Every time this topic comes up, I point back to "You Can't Test the Wings Back on an Airplane" by Elisabeth Hendrickson
Here's a copy:
https://www.ayeconference.com/Articles/wingsbackonairplane.html
I agree, do you have any actionable advice for people who test but aren't in a position to alter the goal from producing a lower quality product to a higher quality product that doesn't need to be tested as much?
This is a hard position, and a lot of testers spend their entire careers there.
The most useful thing you can do without formal authority is make the cost of low quality visible to the people who set the goals. Not "we found 47 bugs" but "this issue delayed the release two weeks" or "this bug affected X customers." When quality problems show up as business problems, the conversation changes.
Within whatever scope you do control, raise the bar anyway. Build relationships with developers who care. Name tradeoffs explicitly when you're asked to ship something that isn't ready. Put the decision where it belongs wherever you can (and avoid absorbing accountability for outcomes you can't control).
The system usually won't change until the pain gets bad enough. The best thing you can do in the meantime is to make sure the right people understand what's causing the pain.