Getting rid of QA teams are a slow ticking bomb frequently imho. Cause some issues are might not be even breaking functionality. You can mess up some tracking/analytics and managers will make wrong decisions based on incorrect data.
But personally I feel like within few years everything might change a lot. Machines 100% will be be better at coding, maintenance and testing things.
Maybe getting rid of your QA team was bad
11–20 of 269 posts
Re: Maybe getting rid of your QA team was bad
#12Microsoft 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.
The revenue keeps rolling in so, clearly, they made the right business decision... >sighI use a lot of MSFT software and services in the "day job". I wish there was some kind of consequence to them for their declining quality.
Re: Maybe getting rid of your QA team was bad
#13This 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…
in the classic model, most QA orgs were a useless appendage. partially by construction, but largely because QA gets squeezed out when dev is late (when does that happen?). they aren't folded in early, so they twiddle their thumbs doing 'test infrastructure' and 'test plans', until they finally get a code drop and a 48 hr schedule to sign off, which they are under extreme pressure to do.
but every once and a while you ran across a QA organization that actually had a deep understanding of the problem domain, and actually helped drive development. right there alongside dev the entire way. not only did they improve quality, but they actually saved everyone time.
Re: Maybe getting rid of your QA team was bad
#14Another 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.
> To play devil's advocate here, I did not _really_ get training for my software engineering role
Yeah and that is my point. It would be way better for the entire field of QA if there were at least a commonly agreed base framework of concepts and ways to do and especially to name things, if alone because the lack of standardization wrecks one's ability to even get testers and makes onboarding them to your "in house standards" a very costly endeavour.
Re: Maybe getting rid of your QA team was bad
#15This is a symptom of a larger issue in tech where C/E suites are trying really hard to turn engineers into some sort of fungible cogs in the system that can be swapped in and out and in different parts of the system and still have everything work perfectly in order.
Re: Maybe getting rid of your QA team was bad
#16QA Engineers are some of the best debuggers too. They have their hands in the pipeline, src and test directories, and often work with all aspects of developing and deploying the application.
When I was a QA lead I often ran into software engineers that couldn’t be bothered to read a pipeline error message (and would complain daily in Slack) and when it came to optimizing the pipeline they would ignore base problems and pretend the issues that stemmed from the base problems were magical and not understood. Wasting days guessing at a solution.
The disrespect a QA engineer sees is not exaggerated in this article. Since most companies with QA orgs do not have a rigorous interviewing process like the Engineering orgs, the QA engineers are seen as lesser. The only SWE that have respect for them that I’ve met are the people who worked in QA themselves. The disrespect is so rampant that I myself have switched back to the Engineering org (I tried using seniority as a principal engineer and even shifted as a manager to make changes, but this failed because Engineering could not see past their own hubris and leadership peoples will not help you). My previous company before I was laid off hired a new CTO who claimed we could just automate away QA needs but had no examples of what she was talking about. This is the level of respect poured down from the top about building good software.
Re: Maybe getting rid of your QA team was bad
#17I stepping-stoned through QA on my way into development, now a decade something ago, and this part stands out as especially true in my experience:
> This created a self-reinforcing spiral, in which anyone “good enough at coding” or fed up with being treated poorly would leave QA. Similarly, others would assume anyone in QA wasn’t “good enough” to exit the discipline. No one recommends the field to new grads. Eventually, the whole thing seemed like it wasn’t worth it any more. Our divorce with QA was a cold one — companies just said “we’re no longer going to have that function, figure it out.”
I've worked with a handful of talented career software QA people in the past. The sanity they can bring to a complex system is amazing, but it seems like a shrinking niche. The writing was on the wall for me that I needed and wanted to get into fulltime dev as QA got increasingly squeezed, mistreated, and misunderstood. At so many companies QA roles went into a death spiral and haven't recovered.
Now, as the author points out, a lot of younger engineers have never worked with a QA team in their career. Or maybe have worked with a crappy QA team because its been devalued so much. So many people have never seen good QA that no one advocates for it.
Re: Maybe getting rid of your QA team was bad
#18I remember a time before agile and devops. Seems like QA has always been looked down on, and always considered a bottleneck.
Re: Maybe getting rid of your QA team was bad
#19This 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…
This is because there is no formal way to run a QA org, people get hired and are told to “figure it out”. Then as other posters said the other orgs ignore the QA org because they have no understanding of the need. What you’re describing is a leadership problem, not a QA usefulness problem.
Re: Maybe getting rid of your QA team was bad
#20I had a boss at Yahoo who gave our QA to another team because "Facebook doesn't use QA, we shouldn't either". I can't remember if it was Facebook or MS, but he was willing to buy all of us a book talking about how amazing it was.
Long story short, it wasn't. It was like taking away a crutch. Of course we could have been more diligent about testing before having QA validate it, but it slowed development down so much trying to learn all the things we never thought to test that QA did automatically.