3 ms·

Sorry if I came off snarky in my question. I def didn't mean it that way. Your explanation makes some sense, but (IMO) engineering teams should just strive to

• alinajaf 16y ago
  I used to believe this until I actually worked in a team with dedicated testing staff. While it is entirely the responsibility of the developer to test changes and functionality to the best of their ability, testing is arguably a skillset in itself. Our QA will test any new changes from every possible angle (will that work on all international sites? For all products? What if a user gets half way through that process, opens a new tab and changes to a different point in the flow, makes some changes, then comes back to the first tab and continues? What happens then?) That and thorough regression testing mean that no matter how subtle any introduced bugs might be, QA will make sure that at the very least it won't effect sales (or whatever core business process is absolutely mission critical). While in theory developers could do all of this, having staff that set out deliberately to break developers code creates a really good dynamic in the workplace. We mark stories as code complete and expect testers to come back with at least one round of bugs. A lot of the time we'll spot them just as or just before we commit, but the testers are good at digging down and finding edge cases that developers often miss.