Business Analysis and Testing

Over the last ten years, some variation of the “do business analysts do system/acceptance testing” has been one of the most common questions I’m asked. Most often, it comes in one of two forms: somebody complaining that their extensive QA experience doesn’t qualify them for certification, or somebody who hates testing hoping for a definitive industry assertion that it’s not their job.

Now, I’m not under any illusions that writing this will solve the issue once and for all — I’m sure it will continue to come up, and not everyone will agree with my position. However, at least I can point to this article in future.

Disclaimer: While this is the same answer I would have given when I could officially speak on behalf of IIBA, it may not reflect IIBA’s current or future position on this topic.

So what is my position? It’s this:

1. System testing is not business analysis, but;
2. Many companies have good reasons to combine the business analysis and testing roles into a single job profile.

Let me dig into that further. My starting point has always been that when talking about “business analysis” I am not focusing on a specific job description, but rather a set of competencies and skills that enable a person to perform a set of tasks towards a desired outcome. If you’re a “business analyst” I expect that you can analyze a business to understand a problem, challenge, or opportunity faced by an enterprise, and to define a solution acceptable to key stakeholders that will resolve the issue. You also need to do the many other things needed to deliver that result, such as elicitation, facilitation, and so on. The key point is that analysis ends when the solution to a problem is defined and recommended, not when it’s implemented.

To talk about business analysis in general, we have to do this. We must define what it is without reference to the specific job of every person with that as a title. Just because your job title includes the words “business analyst” doesn’t mean you only do business analysis. It also doesn’t mean you’re not a business analyst if you don’t have that job title. So in defining something as business analysis, it should be an activity that’s common to every role that does BA work, including business process analysts, business architects, product owners, business systems analysts, and so on.

So why do I (and others, as this has been discussed in depth every time that the BABOK® Guide has been revised) draw the line here? There are two major reasons, The first is that once testing starts, we are no longer analyzing the enterprise. Instead, the emphasis shifts to ensuring conformance with a set of requirements (including quality requirements).

When writing test cases, do you go out and interview stakeholders about what they need from the system, and then build tests around that stakeholder information and throw the BRD away? Obviously, no — the test cases are built with reference to the requirements, and a test case that isn’t rooted in the requirements typically requires a change request before anyone will even consider it. The point of reference isn’t the business, it’s whether the system performs as specified. At this point, you’ve taken a clear step away from doing work that could be described as “analysis of a business”.

A further clue comes from looking at other roles that meet our definition of business analysis, including business process analysts, business architects, product owners, and others. Do they test software? If no, do they at least do something analogous? Looking at a few examples:

1. Business process analysts may use simulation tools or trials to assess whether a proposed process redesign meets business goals — but that’s more like prototyping in IT.
2. In 6 Sigma, we closely monitor the outcomes of working systems and investigate the root cause of variation — but again, that’s about conforming to performance outcomes needed by the business, not about testing against requirements.
3. Product owners in agile may produce requirements in a form that lend themselves to testing, but there are no separate test cases and the PO isn’t responsible for performing the tests — that’s typically done by the development team.

In other words, all the analogous activities involve investigating a business need or defining solutions that meet that need, rather than ensuring conformance to requirements. They all fall on the same side of the line. Determining the requirements an existing or proposed solution must meet is business analysis; but determining whether an existing or proposed solution complies with a set of requirements is not.

So why is testing so commonly part of the job responsibilities of an IT BA? I think it’s mostly a matter of convenience.

In a traditional project lifecycle, neither business analysis or testing staff are required for the entire duration of the project. The business analysis work is mostly done up front, declining once the development team moves into actually constructing the solution. However, a BA usually needs to be involved throughout as issues come up, changes are made, and so on.

On the other hand, the need for testing staff starts to ramp up just as the BA work finishes, as test cases need to be built and tests have to be performed. Combining the business analysis and testing roles eliminates a handoff that would otherwise be required and ensures that the BA will stick around through the end, so their knowledge is always available to the project team.

But that kind of brings us back full circle — as IT development moves away from the classical waterfall approach, the need for these skillsets to be combined is going away. Again, it shows that there really is no inherent connection between business analysis and software testing. It’s a linkage born out of convenience, not out of necessity.