Working Well with your Test Team
Business Analysts and Testers are the two cornerstones of software projects delivery. The BAs define the business needs, they validate solution options, and they remain present throughout the project delivery to ensure the project’s objectives are met.
The Testers’ role is to ensure that the solution does operate in the way that it has been specified before it is implemented: they verify that there are no defects, and that the users can achieve their outcomes without introducing new risks or issues into the organisation.
Is there anything you could do to enhance the collaboration between these two teams in your organisation?
Clarify your own understanding of the work the Testers do
Does your Business Analysis Team understand the complexity of testing, or is it an amorphous phase they have no real interest in? Do they appreciate that the test plan will vary depending on the nature of the solution? Do your BAs understand the Test Team’s structure, the tools and templates they use, their dependencies, or how they test non-functional requirements (NFRs)?
Awareness of their operational model and what’s important to them is hugely beneficial to understand the types of pressure they face and how the Business Analysis Team fits into it all.
Conversely, make sure that the Testers know how your team operates
The Test Team may not appreciate the challenges that you face on every project to agree the scope – the back and forth with senior stakeholders who can be reluctant to sign off. They may not realise the importance of some of the documentation that you produce, or why it takes so long to get it right.
Taking the time to explain how your team operates will increase the Testers’ appreciation of your skills and avoid misunderstandings or assumptions on the execution of your work, particularly when it feeds into their own deliverables.
Avoid functional silos
Avoid the “them and us” culture, which can be a real barrier to success. Functional silos become particularly problematic when the project team is under pressure, for example if the delivery isn’t on track. They can easily create an unhealthy tension within the project team.
An effective counter to this is to collaborate and involve your Tester(s) early into, and throughout, your analysis work. Make them aware of what you’re working on before the business case is approved. Give them an opportunity to review your requirements and feed into them before they are signed off. Walk them through the business processes so they understand the intentions behind the new system.
Not only will their feedback improve the quality of your analysis work, but it will also deliver a myriad of efficiencies during the project delivery, from the Test Team resource allocation planning to the ability to produce an early strawman of the Test Plan, for example.
Listen to the Test Team’s feedback
Recognise that sometimes the BAs’ work can fall short of quality expectations and address these issues appropriately, whether individually or at team level. Is there an unusually high number of change requests on all projects from a particular BA for example, in which case they may need some coaching on their requirements engineering skills? Or should you consider new standards or templates, or maybe even some team training, if common analysis problems are emerging across multiple projects?
Advertisement
Be very clear about your role on the project
Let the Tester(s) know how you are working through any issues, particularly if they are not of your own making, to avoid any misunderstandings about the quality of your work. In extreme but not uncommon cases, the solution is agreed, and a new system purchased, without a clear definition of the business need or other systems it may need to integrate with.
On these projects, your role as a BA is to retrospectively write the requirements, and unfortunately, you’ll need to battle with business users throughout the analysis and design stages to justify the scope, particularly the elements that the new system doesn’t support but they would like to have. It’s not insurmountable, and you will likely come up with viable manual workarounds.
It’s important for the Testers to be aware of this history so that the Testing phase, and specifically user acceptance testing (UAT) can be managed effectively, as these contentious, out of scope items, may be raised as bugs by users in UAT.
Conclusion
Business Analysts and Testers work together to guarantee that solutions are fit for purpose. With mutual respect and an appreciation of each other’s work, the teams should naturally be able to collaborate effectively and work through the challenges of the project delivery.
This doesn’t mean that the two teams will always agree on the best option to resolve them, but they will understand each other’s perspective and be more inclined to compromise or make concessions where they are necessary and possible.