- cross-posted to:
- programmer_humor@programming.dev
- cross-posted to:
- programmer_humor@programming.dev
cross-posted from: https://dubvee.org/post/861635
Not OC: Just found this on my old hard drive while grabbing some other stuff.
cross-posted from: https://dubvee.org/post/861635
Not OC: Just found this on my old hard drive while grabbing some other stuff.
Non-IT, but dealt with the range of them. I feel like QA is probably the most important job, but hear me out.
Developers achieve the objective. We’re living in their reality.
Designers make it useful, without them it would be an esoteric product.
Project managers take the reigns and keep things moving along. Without them, feature bloat and endless development cycles would occur.
QA is the one linking everything to the public. They seem superfluous, but they are the safeguard. Are they tedious? Yes. Are they a PITA? Also yes. But their objective is to ask a single question: “is this gonna come back to bite somebody in the ass?” Is probably the most important and they’re the first person who gets paid to think about it in any detail aside from the sys admin.
The sys admin, to be fair, is literally Neo from the matrix, left to stop every visible bullet left from QA (such that they’re visible bullets and not a wall of lead). They know the damage and triage the wounded, can’t blame them for being bitter about dealing with the wounded every day.
But we all know deep down that engineer that has the mentality, “how can we…” but doesn’t necessarily think through every possible way that we apes can mess things up. And to that effect, enough monkeys banging on typewriters for long enough, something is gonna go wrong.
Perspective from a biologist, so keep your salt unless you’re gonna bitch about your blots.
I actually think QA is the one that shouldn’t be a separate role. Test cases ought to be written by the product owner or project manager as part of defining a feature to implement, and they should do manual testing of a feature before marking it done. Implementing automated tests is probably already the developer’s job.
I agree. Quality is everyone’s job. “QA” as a synonym for “the people that make sure things don’t break” doesn’t actually prioritize quality as an inherent attribute of the product.
Developers need to write tests and build automatic testing harnesses so they can effectively own the code they write and guarantee its quality. A subset of developers might be “QA platform developer” or something similar, but this is to build tooling for testing, not the actual tests themselves.
Designers can’t produce turd of a design and pass the buck. E.g., “That wasn’t the intention of the original design.” and similar terrible defenses. They have to be responsible for the design all the way through to deployment, not just when they call the design spec “complete”. They also need to take feedback from the other groups they work with, instead of thinking their design is above criticism from the non-designer plebs.
Project managers must to prioritize quality initiatives within the project, instead of just driving at feature work or begrudgingly prioritizing critical bug fixes. This includes things like improving developers’ and sysadmins’ lives through tooling and observability. That pile of tech debt the developers and sysadmins has been talking/yelling/screaming about for months/years will eventually fall over and kill everyone, metaphorically of course… unless you work in a safety-critical industry, like medical or transportation.
Sysadmins (and other operator roles, like SRE) have to be empowered to tell everyone else to pound sand when a new proposed deployment is broken or under-tested, or when deployments have been too broken unexpectedly recently.
I dunno how it works in IT, but this is how it works in my organization. Every step in the chain is supposed to uphold its own quality and not pass defects on to other teams.
AND we have a QA department, because even the best team has blind spots about their own work.
As a dev I worked with a QA person who also took on the project management role. Pairing with a skilled QA more than doubled my productivity. Big props to QA if they are willing to embed and iterate.
Competent QA is awesome but super rare in my experience. Most times they are tasked with automating integration tests, their code is bad, they don’t know how to properly configure things, debug even their own code, solve problems. They’re people who couldn’t cut it as devs.
I’m sure I’ll get hate from the QA peeps for saying this.
Yeah bad QA folks abound. Also release engineer roles seem to attract low skilled folks like honey.