Thursday, September 30, 2010

The Business Analyst is the Tester!

I just ran into this article on CIO website: Why You Need to Break Down the Wall Between Business Analyst and QA Teams. I am a bit surprised about the fact that this wisdom surfaces only now.

I know that usually BA's and Testers are different people and have a different role. I sometimes also deal with BA's who don't like testing. However in most projects, I have always tried to make the BA the tester or one of the testers of the system. It only makes sense. The BA is the one who writes the requirements based upon his interpretation of the what is required. If lucky, the BA is doing much of the design as well.

The developers interpret this interpretation of the BA and build the system. If you then have Testers that are positioned far away from the original BA, then they test the system on their interpretation of the interpretation of the BA. You have a high risk that you end up with something that was not envisaged by the business and was not envisaged by the BA.

Having the BA doing the testing, you remove one level of the indirection and at least get something close to what the BA had envisaged. Because the BA was the person who dealt with the source of the requirements, it is the best you can get.

Of course, intensive testing involvement by the key business users will give even a better result. However you should never only rely on them because there the risk is too high they only do it superficially and won't go through all the scenarios you will encounter during normal business use. Specialist testers in combination with the original BA(s) and end users will give in my opinion the best results. And yes, testers should be involved in early stages of the requirements and design.

I found that I achieved my best results with my super coordinators (I called them Service Delivery Managers) who play a mixed analyst, design, project coordinator and testing role during the project where they work closely with dedicated BA's for requirements, design and testing. Those people are then also fantastic to help out with the business roll out and assist business users with their normal day use. (see also "Why Business Requirements don't work")

Besides this, you'll be doing the BA a favour to make them participate in testing. This way the BA gets direct feedback of how well he has done his requirements and design work. If a BA would only be involved in the early stages of a project and never is actively involved in the outcome, the will not know if he has done a good job or not. Testing makes a BA a better BA!

1 comment:

  1. Its interesting that the CIO article you refer to mentions "Agile" practices and states "even if they don't know what they are".

    I think that the point you hit on well and seems a consistent theme across the IT solutionns delivery spectrum is breaking down the barrier between the business stakeholders and the technical delivery team.

    Traditionally the BA is a big part of this interface and as you describe, the value of experience in both camps cannot be underestimated as it can be such a lynch pin role in the success or failure of a project.

    In theory a well implemented Agile process for solutions delivery should help to bring down these barriers as well in a variety of ways.

    One aspect of agile development that is worth examining in relation to your post above is the concept of 'test driven development'. This feature of agile ties in very well with the idea of a BA being involved in the testing of a project.

    The concept being that in order to write a piece of functionality properly a developer first needs to understand the requirements well enough to know how that functionality will be tested - thus by writing (or attempting to write) the tests first, prior to developing the code, it is quite likely that potential inconsistencies in the requirements or miscommunication or misunderstanding of requirements will be identified and resolved earlier in the exercise.

    Adhering to the test-driven development methodology effectively forces the technical team to think about the end stakeholder goals very early in the process.

    Having the tests written before hand then provides a benchmark that will help to prevent the technical team getting carried away with over-architecting a solution to the extent that they lose sight of the original requirements and goals of the project.

    There are numerous other ways a properly implemented Agile methodology can help to increase communication and feedback between the delivery team and the business takeholders.

    This includes shorter and more regular delivery/feedback cycles, requirements management mechanisms which explicitly cater for adjusting to changing understanding of business processes and various other features about the way teams and communication are structured that if implemented properly can achieve signficant benefits.

    The business stakeholders are a key part of making the process work, so if the business stakeholders are not participating in, understanding or seeing those benefits then the Agile process is not being implemented properly and the disconnect still remains.

    Because the Business Analyst plays a key role as an interface between the technical team and the business stakeholders, a BA with a good grasp of the ideas and objectives behind Agile methodolgy can play a key role in facilitating an effective implementation of this methodology.


You are welcome to leave any response or thoughts that you have as feedback.