5 ms·
The QA model you're describing isn't universal. In most of my roles there hasn't been any sort of separate QA team that stands between the dev team's code and p
by SpicyLemonZest 3y ago
The QA model you're describing isn't universal. In most of my roles there hasn't been any sort of separate QA team that stands between the dev team's code and production. So if you have a small enough set of customers that you can be confident they won't hit certain categories of bugs, or won't care too much if they do... it's tempting, and I've seen it done on occasion.
- The_Colonel 3y agoYes, that's somewhat common, esp. in smaller companies. But the article's thesis still doesn't hold up since in that case it's the dev team which is given blame for the prod bugs. Dev team never prefers for the bugs to pop up in prod as opposed to during dev/QA. (accepting low impact bugs is something different which IMHO the article did not write about)
- SpicyLemonZest 3y agoIsn't accepting low impact bugs exactly what you accomplish by skimping on testing? "I know there may be some issues lurking here, but the blame for customers finding them will be less than the blame for missing this deadline, so I'm not going to go looking for them." I've seen multiple teams where the incentives are structured that way.
- The_Colonel 3y agoYou can't evaluate the impact of the bug if you haven't found it. Without testing, you're letting all sorts of bugs into production - both low impact and catastrophic data destruction bugs.
- harimau777 3y agoThere's a difference between the dev team being blamed versus an individual developer.