4 ms·

QA teams primary benefit shouldn't be running automated tests that the developers could do. It should be to do exploratory testing and trying to break things.

QA teams primary benefit shouldn't be running automated tests that the developers could do. It should be to do exploratory testing and trying to break things. There should be a adversarial, yet respectful, relationship between dev and QA where dev tries to get their software released and QA is finding reasons why it shouldn't be released. If there's only developers who test their own code then they're not incentivized for finding the ways their code breaks. They'll downplay the faults or even be blind to them because they're too close to the implementation and aren't "thinking like a user". It seems odd to me when those in charge ignore the problems of disbanding QA. But I assume it's because the management may not be incentivized to promote quality software. Instead the incentives are to crank out features. That said, maybe the market for the software doesn't punish the software makers for having buggy software. In such a case, ignoring QA work is a rational decision.

timwis 5y ago
Another solution is to incentivise the developers by lowering the barrier between them and their users, and changing the success measures from outputs to outcomes.
Clubber 5y ago
>It seems odd to me when those in charge ignore the problems of disbanding QA. But I assume it's because the management may not be incentivized to promote quality software. Instead the incentives are to crank out features. >That said, maybe the market for the software doesn't punish the software makers for having buggy software. In such a case, ignoring QA work is a rational decision. I think there are a lot of things that promote cost cutting in software quality: 1. Consolidation: There's usually 1 big player that everyone uses. When that's the case there is nowhere else to go. 2. Lock in: Even if there was somewhere to go, once you've committed your business to a software vendor, it's really hard (time + expense) to switch. 3. Executives get bonuses based on income: The easiest way to juice the numbers is to cut employees and departments. The results of cutting QA won't get noticed by the market for a few years. 4. Over reliance on automated unit testing by management: I think unit testing is great, but it's really hard to utilize it on user XP. It was never meant to be a replacement to manual QA testing, but an augmentation. Of course refer to #3. 5. Reduction in autonomous middle management: Executives say cut this and cut that, middle management who actually know the process have little to no say, or won't say because they don't want to lose their jobs.
dlandis 5y ago
> If there's only developers who test their own code then they're not incentivized for finding the ways their code breaks. It totally depends. In many cases it will come back to the original developer if their code breaks in production. That is a lot of incentive to test as thoroughly as possible before releasing.
- solatic 5y ago
  Only insofar as ensuring that the software doesn't crash in production, or otherwise cause an event that would cause on-call to be paged. If the customer has a bug, and an issue is opened in the bug tracker, what does the developer care? Forty hours a week is forty hours a week. The developer isn't responsible for delivering business features on-time, and middle management can't be held responsible for delays that are "inevitable" and "outside their control".
rubicon33 5y ago
Beautifully articulated. This is exactly what’s going on. Incentives are simply misaligned with expectations. In all likelihood, the market doesn’t reward quality software as much as it rewards robust feature sets.
- honey-badger 5y ago
  Not necessarily. In all likelihood, the market punishes bad software quality, but with a longer and more complicated feedback loop. It is easy to see the increased traction due to building new features. It is difficult to understand the slow, grinding attrition that happens due to bad quality.
RankingMember 5y ago
> There should be a adversarial, yet respectful, relationship between dev and QA where dev tries to get their software released and QA is finding reasons why it shouldn't be released. The mutual respect aspect is key. If the dynamic isn't right, people end up feeling attacked and it can create a contentious environment. Same goes for code review work.
cranky908canuck 5y ago
An old-timer developer at my shop says this: A developer's job is to make QA's jobs boring. A QA's job is to catch developers making themselves look stupid. As a developer, I'm happy that QA is better at the job than the developers. Playing this game in a way that all can laugh over lunch is good for the culture as well as the business.
bradknowles 5y ago
Fire all your operations people first. The developers can do all their own DevOps. That saves at least half the budget. Then fire all your QA people, because they just keep getting in the way, and the developers can do all of their own QA anyway. Then don't be surprised when they fire all the developers because they've got this new "no code" thing. But then who is left to implement the "no code"?

timwis 5y ago

Another solution is to incentivise the developers by lowering the barrier between them and their users, and changing the success measures from outputs to outcomes.

Clubber 5y ago

>It seems odd to me when those in charge ignore the problems of disbanding QA. But I assume it's because the management may not be incentivized to promote quality software. Instead the incentives are to crank out features. >That said, maybe the market for the software doesn't punish the software makers for having buggy software. In such a case, ignoring QA work is a rational decision. I think there are a lot of things that promote cost cutting in software quality: 1. Consolidation: There's usually 1 big player that everyone uses. When that's the case there is nowhere else to go. 2. Lock in: Even if there was somewhere to go, once you've committed your business to a software vendor, it's really hard (time + expense) to switch. 3. Executives get bonuses based on income: The easiest way to juice the numbers is to cut employees and departments. The results of cutting QA won't get noticed by the market for a few years. 4. Over reliance on automated unit testing by management: I think unit testing is great, but it's really hard to utilize it on user XP. It was never meant to be a replacement to manual QA testing, but an augmentation. Of course refer to #3. 5. Reduction in autonomous middle management: Executives say cut this and cut that, middle management who actually know the process have little to no say, or won't say because they don't want to lose their jobs.

dlandis 5y ago

> If there's only developers who test their own code then they're not incentivized for finding the ways their code breaks. It totally depends. In many cases it will come back to the original developer if their code breaks in production. That is a lot of incentive to test as thoroughly as possible before releasing.

solatic 5y ago
Only insofar as ensuring that the software doesn't crash in production, or otherwise cause an event that would cause on-call to be paged. If the customer has a bug, and an issue is opened in the bug tracker, what does the developer care? Forty hours a week is forty hours a week. The developer isn't responsible for delivering business features on-time, and middle management can't be held responsible for delays that are "inevitable" and "outside their control".

rubicon33 5y ago

Beautifully articulated. This is exactly what’s going on. Incentives are simply misaligned with expectations. In all likelihood, the market doesn’t reward quality software as much as it rewards robust feature sets.

honey-badger 5y ago
Not necessarily. In all likelihood, the market punishes bad software quality, but with a longer and more complicated feedback loop. It is easy to see the increased traction due to building new features. It is difficult to understand the slow, grinding attrition that happens due to bad quality.

RankingMember 5y ago

> There should be a adversarial, yet respectful, relationship between dev and QA where dev tries to get their software released and QA is finding reasons why it shouldn't be released. The mutual respect aspect is key. If the dynamic isn't right, people end up feeling attacked and it can create a contentious environment. Same goes for code review work.

cranky908canuck 5y ago

An old-timer developer at my shop says this: A developer's job is to make QA's jobs boring. A QA's job is to catch developers making themselves look stupid. As a developer, I'm happy that QA is better at the job than the developers. Playing this game in a way that all can laugh over lunch is good for the culture as well as the business.

bradknowles 5y ago

Fire all your operations people first. The developers can do all their own DevOps. That saves at least half the budget. Then fire all your QA people, because they just keep getting in the way, and the developers can do all of their own QA anyway. Then don't be surprised when they fire all the developers because they've got this new "no code" thing. But then who is left to implement the "no code"?