Recently I attended a great presentation at my local SPIN meeting (Milwaukee SPIN Group). The presentation, “Separation of Duties: Why projects deserve a Project Manager and a Business Analyst”, was on the BA and PM roles and why both are necessary and complementary roles. In the presentation the speakers discussed their experiences. Some discussion went to how people sometimes try to fill both roles at the same time and how they might not be as effective at both. They also discussed how a PM isn’t necessarily as good at the details as a BA and how a BA isn’t necessarily as good at keeping the whole project moving as the PM.

This made me think about Testers and their role in the project. In the presentation, it was stressed that the PM’s role is to keep track of the project and remove barriers to completion. And it was explained that the BA’s role is to understand the customer’s needs and communicate those needs in the form of requirements. The Tester’s role on the project is to test the product, identify issues with the software and communicate the coverage of their testing to the team. Each of those statements is a simplification, but a valid simplification.

I find that a significant number of testers really want to be helpful. Sometimes too helpful. Testers often have a diverse set of skills and like to show off how helpful they can be, and so they may find themselves volunteering to do most anything; including things that have nothing to do with testing. Is being helpful a bad thing? Not necessarily. The problem lies not within the desire to be helpful, nor in the act of being helpful. It lies in understanding the role expected of me on my project and letting the desire to be helpful take me out of my role and introducing riskh.

I was recently reminded of the fact a tester needs to be careful about being too helpful and keep in mind their accepted role on the project. It was in a context where there is a client implementation and Test Leads exist on both the client side and on the vendor side. The Test Lead at the client (Clint), who is doing their best to look after the risks in their project was asking about functionality that the vendor Test Lead (Vendi) thought might be possible, but wasn’t sure. Vendi was also not sure if the functionality had been promised to the client and what might be the impact to attempting the functionality. As such, Vendi wanted to be helpful and could have offered some suggestions, but these suggestions might never have been possible. Promising this to the client could have been a problem, so Clint explained that he would pass on the question to the Lead BA (Barbara). After all, Barbara is the person who should be nailing down the requirements and would understand if the functionality request was a scope change.

Saying “Tester, Know thy Place” is a bit extreme. In general, most of the time I’ve heard this said it was out of ignorance of what testers can do and can contribute to a project. At the same time, testers do need to know and understand their role on the project. It’s perfectly fine to be helpful; being helpful can often buy a lot of valuable goodwill that can get you time or resources you need when testing. I just always try to remember that sometimes I can help best by doing the testing and letting the BA, the PM and the other team members perform their roles.