Analyzing the Software Team Generalist
I have seen several teams lately that are abolishing the notion of roles. There are no developers, and there are no testers; these groups only have “team members.”
This starts with teams that work as distinct units with separate managers and work handoff protocol. Eventually someone realizes that they could probably get to production more efficiently. Testers start working closely with their development counterparts, then testers are embedded on development teams. And the logical conclusion of this is changing test specialists into developers.
This can and does work great for some teams, but something is lost in the process.
The most important thing to realize is that testing is a skill set, just like software development. It takes time, study, and practice to become a good software tester. I see people forgetting this because anyone can casually test software and find a problem. However, not anyone can test effectively, deeply, and rigorously.
Taking the test team and having them write production code or test tooling all the time means they are no longer focusing on the skill of testing. They may want to, but there are only so many hours in the day. Splitting those hours means we have to be okay with developing a skill set much more slowly, or not at all.
The other important thing to note is a mindset difference. This gets mentioned a lot, so I’ll do this with a specific example. Developers are in the business of building software. When they test software, and they do frequently, it is often with the questions “Am I done?” or “Did I build what I think I built?” in mind. Developer testing is confirmatory. Testers, on the other hand, are asking open-ended questions with the intent of falsifying the idea that this change is done. Every time I test a change, I am looking for ways is might fail.
I was recently working on a change to a data collection tool. Data was supposed to automatically save after a person types into a field in the tool. All our programmatic tests came up green, but after some testing I discovered that there were cases where autosaving failed. Development thought we were done, but after some time performing skilled testing, I thought there was a little more work to do.
When we merge these roles, there is the chance that the mindset gets blended. Maybe test specialists learn some development skills and developers learn some testing skills, and that’s a good thing. But there is also the chance that everyone on the team starts to think in the same way and we lose a critical perspective: the ability to analyze work at a deeper level than “done with implementation.”
For the most part, I think it is great to have generalist software development team members. However, what we usually ends up being meant by “generalist” is that everyone is a programmer. If you want to have developers with testing expertise, you might want to let them become testers first.
