The idea of testing being separate from dev comes, I think, from a few false assumptions (and is tightly coupled with waterfall thinking). The first assumption is that testing is a lesser art than programming. 1/9
You can’t waste the time of those highly-paid developers doing something as mundane as testing, so let’s throw the tests to low-paid “testers.” 2/9
That naturally leads to thinking of “testing” as a separate skill from development rather than being an integral part of it, and that leads to thinking that “testers” have some magical ability to see things and think of issues that the developers can’t conceive of. 3/9
I see that more as an attempt at job security than any sort of reality. Good devs can see the issues just fine, and if the dev’s aren’t good, you can train them. 4/9
That testers-as-second-class-citizens thing also leads to the mistaken assumption that testing isn’t nearly as important as slinging code. In fact, if you don’t test and code at the same time, the coding goes much more slowly. Testing and coding are inseparable. 5/9
You can’t do one without the other, and both must be done concurrently. 6/9
The next problem is thinking that software dev is done on an assembly line, where you can’t test most things until the product is “finished,” so there’s s QA step at the end of the line. That led to a throw-it-over-the-wall approach to testing, which never worked. 7/9
A separate QA dept. was always a bottleneck that slowed down everything. Nonetheless, people who should know better, still hold on to that concept, saying that some things (e.g. performance or integration) are better handled by throwing the code over the wall. 8/9
I just don’t see it. Bottlenecks are bottlenecks. Problems discovered later rather than earlier are much more expensive to fix. IMO, testing and dev must go on simultaneously, and be done by the same people. You don’t have time for silos. QA is a skill, not a job title. 9/9
