3 ms·
My point still is valid. Even these particular guys certainly would have written buggy code. A QA process could correct it.
by Haskell 18y ago
My point still is valid.
Even these particular guys certainly would have written buggy code. A QA process could correct it.
- Retric 18y agoI worked without testing for 2 years and released a single bug into production. In that specific case I thought something might have been wrong but they needed it ASAP so I said who cares. My father once had a tester say "Ops I stopped testing your code over a year ago" when he released a fix to some buggy code someone else wrote which still had a few bugs. After adding a formal QA process I stopped double checking how buggy my code so I could get more done but I have ended up releasing more bugs. So I have little respect for formal QA.
- bad_user 18y agoQA is really useful, but there's a big downside to it. When you have people who's job is to test code, developers get lazy and sloppy. Also, bugs do appear in production if you can release code the same day you wrote it, but you can fix it as soon as you find out about it. In big companies that work with milestones (sprints in agile speak), only really critical bugs can be fixed between releases. Not to mention that most bugs are fixed after code-freeze, when all the deliverables of that milestone are ready, long after you find out about it. So I guess it's best to have QA, but also the freedom to deploy code on production whenever you want.