What is Business Process Assurance?

What is Business Process Assurance?

The evolution of traditional QA or SQA to Business Process Assurance (BPA)



Back to Basics



To err is human. So it is logical to accept that every human activity in the software development lifecycle (SDLC) is bound to have errors. There have been many names given to these errors - bugs, errors, issues and defects to name a few. And so are many names to the various big and small activities aimed at finding and removing these defects - testing, unit testing, code walkthrough, peer-review, quality control, quality assurance, system testing, functional testing, end to end testing, user acceptance testing, post-production testing, integration testing, smoke testing, blackbox testing, whitebox testing, shakedown testing, model office testing and the dizzying list goes on.



Many have gone ahead and put some quantitative metrics around the problem to satisfy the needs of maturity models like the CMMI. Metrics like Defect Removal Efficiency and Cost of Quality come to mind. In fact "Defect Estimation Process" might be surprising to some but some organizations claim to have process capability baseline data that gives them the ability to estimate defects even before a project can begin.



If we really go back to the basics all of the above seem like a deer in the headlights.



The first question to ask is - Why does an organization write software?. The obvious answer seems to be to improve productivity by plugging the inefficiency holes in their business processes. Does it not then make sense to define all such activities aimed at removing the human errors in the SDLC as "Business Process Assurance" where we are not just testing one program or some middleware or some Service Oriented Architecture (SOA) or whatever the acronym of the day, but we are assuring that the Business Process is implemented the way the business wants in order to remain competitive. E.g. We are testing the "Change the Beneficiary" process in case of a life insurance policy. This can mean testing of a customer service web based portal and then a business integration middleware and then the beneficiary management system and then the document management system that sends the letter out. Only then can we assure quality in the business process the way the end customer experiences it.



Business Process Assurance (BPA)



BPA can then be defined to include all such activities aimed at detection and removal of defects throughout the SDLC and across all the systems that work together to fulfill a business process. Sounds like a loaded definition and a lofty task? Not actually when you have a process in place. Unfortunately not many books or articles are written on this topic. We aim at defining a practical process architecture based on our experience implementing this on many engagements - specially in the Insurance Industry.



There are various flavors of development methodologies ranging from Test First; Agile; Unified; Model-Driven; Feature-Driven; Waterfall or what have you. All organizations seem to have their own tailored process that suits their corporate culture. The way we have explained BPA in this article, lends itself very easily to be tailored to fit ANY of the methodologies that one chooses to follow. What matters is implementing the principle in spirit which is - all individuals involved in the SDLC, regardless of their role, should have one and only one aim in mind that is of delivering the business process experience exactly the way the business stakeholders have envisaged it.



Isn't BPA same as UAT?



Another argument we have heard during our experiments with BPA in the early days is - Isn't BPA the same as UAT where the end users run their acceptance tests that are purely based on business processes? The answer is No. Because although on the face of it, it might sound similar there are fundamental differences. For starters, UAT is traditionally done at the very end when the system is already built and usually too late and expensive to fix defects originating in poor understanding of requirements. BPA requires various disciplines to be followed throughout the lifecycle and not just done at the very end.



BPA Process Architecture



We have evolved the BPA Process Architecture by refining it across multiple engagements and implementing this with some large initiatives with a Fortune 100 customer. Each one of these disciplines requires a detailed discussion, but for the scope of this article, here is a quick summary.



1. Visual Representation - A picture speaks a 1000 words. So rather than reams of process documentation, insist on visual representation of the Business Process that is being implemented new or being modified. This can be in the form of UML Swimlane diagrams. If one does not exist then the BPA team can create one. This not only reinforces the understanding but also helps identify fundamental flaws that the business analysts or subject matter experts might have overlooked.

2. Close The Needs Gap - Review Business Case and Business Requirements and question the "real business need" if it does not clearly stand out in their specifications. This is the MOST important step to avoid the trap of "I don't know what I want, but I definitely know what I don't want".

3. Business Processes List - At the onset of the project, the BPA team needs to work with the business stakeholders to identify a clear list of Business Functions and a breakdown of each into the underlying Business Processes that are affected in this project. All further work will be based on this breakup. Tracebility Matrix will tie everything back to this and so will all Tests, Defect Reports and so on. This is a critical step in expectations management between business and technology. Through this mechanism it is easy, for example, to explain those business processes experiencing more defects. And also much easier to explain / justify the development and testing costs as they are now presented in the form understood by business.

4. Traceability Matrix - Start a Traceability Matrix listing each requirement on it and maintain this matrix throughout the lifecycle. This is at the heart of the BPA process. This is a living document updated throughout and ultimately becomes the key assurance document that explains "under the hood" details of how each business process was specified, coded, tested, defect fixed and released. Depending on the lifecycle methodology the level of documentation might be low or high. But BPA requires that a full comparison be made of the Functional or Technical specifications to the User Requirements. Also compare any other interim artifacts created like a wireframe, design mockup, data dictionary, Interface Control Document (ICD), meta-data spreadsheet etc. All discrepancies found within these specifications should be termed as "defects" and reported exactly the way defects in the code are reported and fixed. This is not fun, but someone has to do it!

5. Unit and Integration Testing - Again depending how pronounced these disciplines are based on the lifecycle methodology, conducting these activities fall outside the BPA team's realm. These are the tasks better performed by the development team. The BPA discipline simply requires proof of these activities being done for each business requirement to keep the Traceability Matrix updated.

6. System Testing - Also traditionally called QA, is performed typically by an independent team focused on functional testing. This should be performed strictly by way of listing Business Functions broken down into Business Processes and their alternate / exception scenarios as per Traceability Matrix. Business Process Tests should be designed and run for each such process scenario. A test management tool like HP / Mercury Quality Center with the Business Process Testing module can be very helpful to organize this testing effort and also ensure easier automation of these tests.

7. Automation - This is the MOST critical discipline of BPA. Typically, automation has been viewed as something done "after" the system testing so that future regression tests can be run more effeciently. However, it is possible to automate even the system test. We have developed a methodology based on the keyword-driven testing approach that allows us to develop automated test cases even before the application is built. This helps reduce the test execution time by anywhere between 30 to 50%. HP Quality Center seems to provide excellent support to these BPA concept by providing easy mapping of business process tests; keyword-driven testing support in QuickTest Pro. The concept of reusable test components makes it easier to manage automation scripts as opposed to custom built frameworks that soon become yet another "system" to maintain. Finally tests are possible to be driven by parameters and test data that is easy to maintain.



Equipped with clear proof of Business Process Assurance in the form of the Tracebility Matrix, the Acceptance Testing team can design their subset of tests that are enough to convince them to make this new or updated system part of their business operations. Even better if they can use the automated components and run the acceptance tests in record time in their own environment with their own data.



Tailoring



We have created a detailed process architecture for all the above disciplines complete with Templates and Best Practices for QA teams to evolve into their new role of BPA. Here is an example of how the above disciplines can be tailored to an organization's software process. In this case the Unified Process is considered and the above disciplines tailored. Each hump and its height represent how pronounced each discipline is and for what duration during the Unified Process phases. If an Agile approach is followed then these discipines will be mapped to each Iteration within each phase and be performed more frequently - so more humps will appear in the diagram.





http://blogs.ebusinessware.com/wp-content/uploads/2009/05/bpa-unified-map1.jpg



Mapping of BPA disciplines to the Unified process stages