Maybe getting rid of your QA team was bad
davidkcaudill.medium.com
Maybe getting rid of your QA team was bad
1–10 of 269 posts
Re: Maybe getting rid of your QA team was bad
#2[deleted]
Re: Maybe getting rid of your QA team was bad
#3In making the case for building up a QA org at my current startup, I repeat the mantra that QA is both a skillset and a mindset. Automated tests can tell us a lot, but skilled QA testers are amazing at edge cases to break things and providing human feedback about what looks and feels good gor users.
Re: Maybe getting rid of your QA team was bad
#4Microsoft is probably the one case where this sticks out the most, at least for me anyways. Noticeably more bugs in updates since they dropped their QA team, in Windows as well as cloud products.
Re: Maybe getting rid of your QA team was bad
#5But Microsoft fired their entire qa department, and their software is rock solid. Right! Right?
Re: Maybe getting rid of your QA team was bad
#6Another part is that there is barely any training for QA people. Even your average CS course will only graze the top of the topic, most usually some prof droning on about Java unit tests on some really old version of Java and a testing framework just as old.
There are no "Software Quality Assurance" academic degrees, there's barely any research into testing methodologies, there's barely any commercial engagement in the space aside from test run environments (aka, selling shovels to gold diggers), and let's face truth, also in tooling. And everything but software QA is an even worse state, with "training" usually consisting of a few weeks of "learning on the job".
Basic stuff like "how does one even write a test plan", "how does one keep track of bugs", "how to determine what needs to be tested in what way (unit, integration, e2e)" is at best cargo-culted in the organization, at worst everyone is left to reinvent the wheel themselves, and you end up with 13 different "testing" jobs in a manually clicked-together Jenkins server, for one project.
> Defect Investigation: Reproduction, or “repro”, is a critical part of managing bugs. In order to expedite fixes, somebody has to do the legwork to translate “I tried to buy a movie ticket and it didn’t work” into “character encoding issues broke the purchase flow for a customer with a non-English character in their name”.
And this would normally not be the job of a QA person, that's 1st level support's job, but outsourcing to Indian body shops or outright AI chatbots is cheaper than hiring competent support staff.
That also ties in to another aspect I found lacking in the article: users are expected to be your testers for free aka you sell bananaware. No matter if it's AAA games, computer OSes, phones, even cars...
Re: Maybe getting rid of your QA team was bad
#7This might be my personal experience, but I've never encountered a QA team that actually writes the tests for engineering.
I have only had QA teams that wrote "test plans" and executed them manually, and in rarer cases, via automated browser / device tests. I consider these types of tests to be valuable, but less so than "unit tests" or "integration tests".
With this model, I have found that the engineering team ends up being the QA team in practice, and then the actual QA team often only finds bugs that aren't really bugs, just creating noise and taking away more value than they provide.
I would love to learn about QA team models that work. Manual tests are great, but they only go so far in my experience.
I'm not trying to knock on QA folks, I'm just sharing my experience.
Re: Maybe getting rid of your QA team was bad
#8I can't agree more.
> Focus: There is real value in having people at your company whose focus is on the quality of your end product. Quality might be “everybody’s job”…but it should also be “somebody’s job”. Yes indeed, naturally every person have just one focus, having dedicated person focus on QA is important.
Another practice, or buzz word (or used to be buzz word:) ), Exploratory Testing, which can pretty much be conducted only by dedicated QA.
Re: Maybe getting rid of your QA team was bad
#9Another part is that there is barely any training for QA people. Even your average CS course will only graze the top of the topic, most usually some prof droning on about Java unit tests on some really old version of Java and a testing framework just as old. There are no "Software Quality Assurance" academic degrees, there's barely any research into testing methodologies, there's barely any commercial engagement in t…
To play devil's advocate here, I did not _really_ get training for my software engineering role. I got a little bit from 1-2 college courses, but the vast majority of my role I had to pick up on the job or on my own.
I can tell you, I definitely didn't get training for QA tasks, but here I am doing them anyways. It's just work that needs to be done.
Re: Maybe getting rid of your QA team was bad
#10Another part is that there is barely any training for QA people. Even your average CS course will only graze the top of the topic, most usually some prof droning on about Java unit tests on some really old version of Java and a testing framework just as old. There are no "Software Quality Assurance" academic degrees, there's barely any research into testing methodologies, there's barely any commercial engagement in t…
> There are no "Software Quality Assurance" academic degrees, there's barely any research into testing methodologies,
There's a lot of this actually. Entire communities of people working on software quality assurance. Practitioners in this space call their field "resilience engineering".
The field likes to talk a lot about system design. Especially in the intersection of humans and machines. Stuff like "How do you set up a system (the org) such that production bugs are less likely to make it all the way to users"