I seem to find quite a few job postings for Business Analysts that have a couple of lines in the ‘tasks to perform’ description that scare me like:
- Define test strategy and test plan
- Develop and execute test cases
- Perform stress and load test scenarios
It’s not that I don’t believe I am capable of these tasks at some level of competence; after all most BAs have had to perform these activities at some point in their career. I don’t believe a BA should be expected to do Quality Assurance tasks. I can understand the temptation to leverage Business Analysts to perform Quality Assurance tasks, namely:
- BAs already have a good understanding of requirements, use cases, etc. so it should be easy for them to come up with testing approaches and test cases
- BAs are ‘analytical’ in nature and thus are well suited to QA activities
- After the requirements are done BAs just typically sit around or are moved to another project, so we might as well give them something to do so they can be with the project for its entire lifecycle (and be held accountable for ensuring in the end user needs are met)
While these arguments all have some level of credibility, I don’t believe that having BAs perform QA tasks should be considered good practice. Don’t get me wrong, I believe that BAs need to work closely with testers to ensure that requirements are well understood, that requirements can be traced end-to-end, and to help facilitate discussion amongst the team to develop a testing approach. I don’t even mind having to execute test cases if the team’s in a crunch and need some more people to run through scenarios. But overall, I believe that having a Business Analyst being in charge of testing activities (especially if it’s on the same project as doing BA tasks) is not a good idea for the reasons I discuss below.
Quality Assurance is a Separate Role
As the BABOK V2.0 has so eloquently stated, Business Analysis is about working with stakeholders within an organization to identify solutions that will help the organization meet its goals. The BABOK barely mentions testing, only to indicate that a Tester is “response for determining how to verify that the solution meets the requirements defined by the Business Analyst.” These are two distinct roles that while they involve leveraging common knowledge and artefacts (e.g. requirements) they definitively involve disparate activities, techniques, and tools.
Quality Assurance is its Own Profession
Not only is QA its own role, there are organizations that promote the tasks performed by testers as its own profession. There are even separate bodies of knowledge, designations and certifications that have been developed around QA activities. Like any profession it takes time to become adept at performing QA tasks, just as it does to become proficient at BA tasks.
While individuals may develop expertise in both Business Analysis and Quality Assurance over several years (in which case they can perform either role) it is unlikely that most BAs have the level of knowledge to adequately perform QA tasks.
Bias Inherent in Performing Both Roles
For me this is the most important consideration – if you are the Business Analyst (or one of the BAs) involved in the gathering of requirements, you end up developing certain biases based on your knowledge of the business and the problem(s) that are to be solved by the solution being developed. Such biases are rarely at a conscious level, but do occur frequently.
The BA can become so intimate with the requirements that they may not realize when certain assumptions are undocumented, or may unwittingly ignore certain paths or scenarios that need to be tested because they understand the recourses that can occur in those circumstances. In essence the BA may become so ‘in tune’ with the requirements as documented that they may omit or neglect circumstances or exceptions in testing plans that need to be considered. An unbiased third party without such intimate knowledge would have a much easier time to spot any inconsistencies.
Such biases can impact the veracity of testing activities. For example, if the BA starts to write test cases based on what’s in their head rather than what is documented, traceability can become an issue. If the BA omits certain test case scenarios since they know that they are unlikely to occur, are not documented, or the BA already knows how the system will handle the scenario (since they saw it at the last demo), then not only is the current testing phase impacted, regression testing on future changes to the system can become compromised.
Lost Opportunity to Have Another Set of Eyes in the Process
As noted above, a BA can form a biased view of the solution and the project based on their work and job duties. It never hurts to have another brain in the fold that is tasked with, among other things, finding holes in documented processes, looking for requirements that may be under-developed, and generally ensuring that the solution is free from issues that would cause stakeholders to reject it. There are few downsides to including another person given the risks inherent with one person performing both sets of duties.
Get a Tester
Overall, if your organization has the capacity to have dedicated Quality Assurance professionals they will pay for themselves in spades (just as Business Analysts do). Using BAs for testing purposes may seem like a slick thing to do, but in my opinion it is almost never the right choice given the option to go with a separate individual.
What do you think? Leave a comment and let me know your experiences. Have you been a BA who has been forced into QA duties? Do you think there’s no issue with someone doing ‘double duty’?