4 ms·
Having been through the decision process in the past for whether to go when centralized QA, dedicated QA on teams, or automated testing as an engineering respon
by yodon 5y ago
Having been through the decision process in the past for whether to go when centralized QA, dedicated QA on teams, or automated testing as an engineering responsibility, I came away with the personal opinion that the quality of automated test frameworks has improved so drastically in the past five years or so that we really are in a different place than we were when concept of dedicated QA teams was invented long ago. Large scale software engineering is a human coordination problem (see Conway's Law and the Mythical Man Month), and the time required for engineers to write tests after already understanding the requirements is small compared to the time required for the organization to have someone else try to separately understand the same information and separately write the test. That didn't use to be the case, but today it is. I get not wanting to take time to write tests, just as I get not wanting to take time to document your code, but that's not a good enough reason for introducing the inefficiencies of having someone else try to do something that is best described as your own job (again, the economics used to be different because writing tests used to be slow and inefficient, but that is changing/has changed).
I will say however that I think you do generally still need a team (or individual at smaller shops) dedicated to tooling for automated testing to make the process of writing tests efficient for all those who are writing tests.
- ccalloway 5y agoThe problem with this is that a person who makes a mistake when doing something is much more likely than someone else to make a mistake when evaluating that same piece of work.
- Veuxdo 5y agoExactly. The problem isn't "writing tests", is writing test cases.
- yodon 5y agoThe really big wins happen when you get a framework in place that gives you a formal language like Gherkin for expressing what needs to be tested. That's a win because it starts giving product a way to specify requirements that are both clearer and more explicitly test-like. That starts integrating test design into the spec process as opposed to having test design happen during the implementation process.
- candiddevmike 5y agoAutomated tests (at least when it comes to web) are unlikely to catch graphical and UX issues in my experience, even when you're doing screenshot comparisions--things get missed. I've also had manual QA discover unrelated UX bugs too.
- yodon 5y agoI'm a big fan of a small "red team" QA approach where human testers are basically using their brains to do intelligent fuzzing and hunting for edge case breakage. That's very different from what most centralized QA teams spend their time on today.
- honey-badger 5y agoA valuable perspective, and brilliantly articulated. The process of software creation and its quality assurance is so intricately intertwined due to the nature of software itself, that it is near impossible to neatly divide labour.