True, it’s an assumption – but probably a safe one – that the majority of professional software testers can’t code. This seems to be the cause of perennial hand-wringing by some testers who feel the need to justify their lack of technical skills, and frustrated developers who interact with them. An even safer assumption, however, is that most developers can’t test. Curiously, this doesn’t garner much debate or discussion, despite it being of far greater importance and concern to successful software development. To be fair, a large number of people claiming to be professional testers can’t test either. Manually executing steps from a test script, especially one written by someone else, rarely comes close to actual testing. Unsurprisingly then, automating the execution of similar test steps doesn’t make developers proficient testers either. So who does know how to test? Who should test? Think of the best tester you’ve ever encountered. Most organizations often have one tester who can find significantly more – and significantly nastier – bugs than everyone else, and they do it surprisingly quickly. They’re the people who know how to test. Unfortunately this skill is often assumed to be some sort of magical power to “break software” bestowed on a select few at birth, and therefore alarmingly little attention is placed upon developing this skill in others. But imagine if that wasn’t the case. Imagine if everyone involved in software development, testers and developers alike, were all thinking and testing like the best tester you’ve ever encountered. Such a team would produce exceedingly higher quality software, far more efficiently. So why isn’t this the norm? Partly it’s due to traditional approaches to software development (such as waterfall), emphasizing requirement traceability and test repeatability over good testing. For these teams, the priority is on how many tests passed or failed rather than on which tests were valuable or not (which partly explains the legion of testers who aren’t very good testers). Furthermore, the traditional notion that testers need to be independent from developers in order to be effective not only creates a ”wall” between test and development teams that discourages developers from caring about the quality of their work, it also obscures great testing. This prevents developers from recognizing, understanding and learning it. The testing profession is also to blame for doing a poor job at communicating and promoting such skills. Agile methodologies avoid the quality “wall” problem by taking a whole team approach to quality. But when developers find themselves responsible for testing, typically they’ll try to solve this the same way they solve most problems: through code, in the form of automated tests. Test automation is crucial, but automation proficiency can be mistaken for good testing skills by developers who have never been exposed to, let alone taught, great testing skills (the Dunning-Kruger effect). The fact that agile’s early adopters were primarily developers, and that agile advocates teams of generalists over specialists, also means that testers have had to expend a lot of effort justifying their place in agile teams over the years (and for many the struggle […]
Previous Topic
