The podcast episode this post is written about can be found here.
This week I listened to a podcast in which the podcasters stage an argument between a 1990s “traditional” test manager and a modern test manager. I chose this podcast from about 4 I thought sounded interesting, because I wanted to know the current state of the industry and where we came from. It was enormously helpful in demonstrating the difference in how software gets tested these days compared with how it was done previously.
The one playing the role of the 90s manager explains how at his company, testing is kept largely separate from development. After software is implemented, it’s sent to software testers, whose job it is to find bugs. If they do find bugs, the project is sent back to the developers for them to fix. The second round of testing might reveal that the bug wasn’t fixed after all, and the result can be an endless game of ping-pong where the product doesn’t get released for ages.
Laid out in this way, it was clear how this inefficient setup led to the modern strategy of integrating software development and testing. The modern test manager explains that at his company, test specialists are embedded in the development team from the beginning, and the whole team is in charge of ensuring the quality of the product. The developers actually write most of the tests for their own code as they go along and end up finding most of the bugs. Test specialists may write more complex tests or write diagnostic tools, but mainly their job is to see the big picture and make sure that all the testing that needs to get done gets done. In fact, the modern manager says that most of the bugs that the team members who specialize in testing find don’t find them through writing typical tests or test automation, but through data analysis and looking at how customers use a product.
I gathered through listening to this conversation unfold that the basic idea of the modern setup is that catching bugs earlier makes them way less hassle to fix, so testing isn’t pushed to the end. Everybody in the team is capable of doing everything required for both implementation and testing, but they each specialize in a particular area. Going forward, I’ll make sure I don’t conceive of the testing process as entirely separate from the development process, but rather as something that goes along with code implementation in order to prevent headaches down the line.