Asking developers to do QA is broken – why anyone should own QA

[author here] Both are solid points!

Regarding the incentive structure, I think you're right - there's no way to eliminate the friction that comes from competing incentives. Our experience has been that empowering the product organization to make that tradeoff themselves leads to the optimal outcome for the business. The goal isn't to eliminate the tradeoff between speed and quality, but surface it, and put it in the hands of the people who are the business decision makers, which tends to be product.

Re test data - we had seen this bottleneck with our previous product, which was purely about crowd testing. What we've seen since we shipped no code automation is that much of the data seeding by less mature teams can be done through the tests themselves. This is suboptimal, but with automation so cheap and fast, it works. Then over time the engineering team can seed the states that are most often created through the tests.

[author here] You are absolutely right: the optimal setup is a cross-functional team of domain experts collaborating on solving the customer's problem. The article is meant to point out that siloing QA to either just dev or just QA is an anti-pattern that is unstable and will not work, long term, without significant pain.

I think the challenge is that, while we agree on the optimal setup, it's almost never done like this. There's lots of reasons why, but the main one (imo) is organizational scaling. The logic of scaling teams tends towards specialization, especially because developer time is extremely expensive.

There are many ways to address the problem of QA. From our perspective, if they don't broaden the ownership of QA from just developers or just QA engineers (which is where all the current products are targeted), they will exacerbate this specialization problem.

Wherever I worked so far as a software developer we had the QA department very close. In the same room or next door. They were there from the beginning until the end, tested our software continuously.

If we developed something, that was hard for them to test or to understand, they gave us a hard time. So we tried to make software testable. Do meaningful logging. Make things repeatable. Develop tools to export state/parts of the database, that can be restored. So you can actually test one feature and don't have to do 100 steps every time you need to test Feature X.

All that also greatly helped the developers, because a lot of companies develop software, that the developers can't even try out, because it only runs in a QA system they don't have access to. That's horrible.

My org has mixed teams. We find devs are terrible at being QAs. This is not through lack of willingness but they're always either overtesting or undertesting and usually missing the test boundaries. So we use the SDET model, software developers trained in testing to build out the automation and high quality QAs with lots of domain knowledge to do the static and exploratory testing.

In my experience (hiring manager for QAs), there's no way I can get SDETs for anything like the price of a journeyman dev. I'm probably looking at a 20-40% premium right now for someone decent.

I guess this debate entirely depends on the product and the customer base. If you make a product like Excel or Photoshop you probably need enough people to have taken an independent look before releasing it to the customers. QA is a legit formal step and protects the reputation, time and money for the organization. Smart QA teams will automate their processes and I have seen some pretty sophisticated automated test suites. In such a setup fluent communication between dev and QA is probably critical.

On the flip side there are organizations which do not have the burden of fickle customers. An example of such an institution is a high frequency trading firm. The firm that I work for has two roles, developer or trader. These companies hire exclusively on-campus and with very transferrable skill-sets between the two roles. In such an environment, where both the writer of the application and the user is equally competent, the role of QA is a burden, there isn't much to add. The trader proposes an idea, developer implements it, trader has all the incentive to make the idea work and the two basically figure out ways to get a feature in prod as fast as possible and ensure that you make money. The success is tangible, the money is directly linked to the bonus you make. I see similar parallel in a startup where the people who generate the idea and people who implement the idea are the same pool. In such empowering environments, the proximity of user and developer just pushes for excellence.

Most of the time the advocates and critics of QA do not realize that it is all context. QA as a role saves embarrassment, money, time etc. but that does not mean an engineering team is incomplete without a QA.

I do feel that this article is offensive to QA community when it portrays QAs as inferior members of team doing work that is not worth the `expensive` developer.