Maybe getting rid of your QA team was bad

I strongly disagree.

I worked at a company with a world-class QA team. They were amazing and I can't say enough nice things about them. They were comprehensive and professional and amazing human beings. They had great attention to detail and they catalogued a huge spreadsheet of manual things to test. Engineers loved working with them.

However -- the end result was that engineers got lazy. They were throwing code over to QA while barely testing code themselves. They were entirely reliant on manual QA, so every release bounced back and forth several times before release. Sometimes, we had feature branches being tested for months, creating HUGE merge conflicts.

Of course, management noticed this was inefficient, so they formed another team dedicated to automated QA. But their coverage was always tiny, and they didn't have resources to cover every release, so everyone wanted to continue using manual QA for CYA purposes.

When I started my own company, I hired some of my old engineering coworkers. I decided to not hire QA at all, which was controversial because we _loved_ our old QA team. However, the end result was that we were much faster.

1. It forced us to invest heavily on automation (parallelizing the bejesus out of everything, so it runs in 2. Engineers had a _lot_ of motivation to test things well themselves because there was no CYA culture. They couldn't throw things over a wall and wash their hands of any accountability.

We also didn't have a lack of end-to-end tests, as the author alludes to. Almost all of our tests were functional / integration tests, that run on top of a docker-compose set up that simulated production pretty well. After all, are unit tests where you mock every data source helpful at all? We invested a lot of time in making realistic fixtures.

Sure, we released some small bugs. But we never had huge, show stopping bugs because engineers acted as owners, carefully testing the worst-case scenarios themselves.

The only downside was that we were slower to catch subtle, not-caught-by-Sentry bugs, so things like UX transition weirdness. But that was mostly okay.

Now, there is still a use case for manual QA -- it's a question of risk tolerance. However, most applications don't fit that category.

I share the same experience that the QA team writes test plans not and “code level” tests

That said, those test plans are gold. They form the definition of the product’s behavior better than any Google Doc, Integration Test, or rotating PM ever could.

I had a buddy who liked to do that kind of thing. I think his favorite trick was just to enter nothing in a form and hit enter to see what happens. It's probably his favorite because it deleted the database on some little thing I wrote at one point and we got a good laugh over it and I got a good lesson out of it.

i never felt that devops and qa were at odds the way that this article suggests they are. in my experience nobody wants to or knows how to do run QA correctly so the org shoots themselves in the foot and does one of two things:

1. hire a contractor who just has no idea about anything. 2. hire someone and place them outside the engineering org (on the support team as a "support engineer" seems pretty popular) where they have little to no interaction with either engineering _or_ customers and expect them to work miracles.

The type of testing QA should be doing is different from the type of testing that devs should be doing. One doesn't substitute for the other.