I usually try to stay on the technical side of things when it comes to technology and how it is implemented, because there is so much to share, engage, and learn on the technical side itself. And then, I talk about and consult on Testing Process Consulting because the process of testing directly affects the Quality of the product. I generally do not venture into Project Management or People Management side of things due to lack of time.
But, once in a while, project management topics that indirectly affect the effectiveness of testing get my attention. In the past many months, I have heard two or three times in the social media about the ideal ‘Developers-to-Testers’ ratio and how to arrive at it. I guess this is an attempt to merge the development and the testing teams into a single team, and in the process trying to figure out how much developers’ work can be assigned to a tester.
This view of allocating personnel for Software Engineering this way is incorrect. As we all in the Software already know, a developing software is a very dynamic entity driven by context. A couple of lines code change made by a developer in an hour might lead to a full week worth of testing by 3 or 4 testers because of the scope. Likewise, 6 or 7 developers would have worked on an update, which might need just a quick cursory check by a tester or two on a weekday afternoon to make sure that things are working fine. Then, how can an ideal number for developers:testers ratio be derived? This notion itself is wrong.
If this is about reducing testing itself by reducing the number of testers, and having one or two ‘quality coaches’ in the team who can guide the developers on how to test, let me tell you, that also is a bad idea. As I already wrote about it, every aspect of software design consideration involves significant amount of expertise and cannot be covered by one or two quality coaches – because of the expertise involved, and the bandwidth involved.
The right approach of allocating the right number of people for development and testing is to look at the product context itself, and see how much of effort is involved in developing and testing, and allocate those many number of people. For the same project, these numbers would vary time to time, forget about fixing a standard ratio across multiple projects! By denying the right number of people required for the context, we are negatively affecting the quality of the product.
I have been talking to performance and security testing professionals, and I can appreciate their views on how involved their work is. To cut corners on testing effort on software will make things worse for the product as well as its customers. I’ve been vocal about this in social media and I hope this idea of undermining Software Testing effort does not materialize.
Feel free to chat with me about Testing Process Consulting.