Business Process Execution Testing (BPET) is the new matra for software testing. Actually it has been slowly rattling in my mind for some time. Now I am finally acknowledging it in light of the challenges with one of my recent implementations. However, I was struggling to put those thoughts together and consolidate them in a framework. Finally this new acronym came to my mind and I said lets just express it. I just hope no one has used this acronym before!
But anyway, I think one of the fundamental reasons for high customer dissatisfaction with software systems is the lack of coherence with the operational processes. The reason being that the traditional software testing approach is bottom up starting with unit testing and graduating to integration testing and system testing. As a result the software is tested and verified for the way it was built and/or designed to built.Howevever when put to use, there are signficant operational gaps which make the system of little use and reduces its acceptance by the end user community. This has to change!! The wave is of business processes driven application and system design and testing needs to take on this paradigm shift heads on. This paradigm shift can be absorbed and addressed by imbibing and adopting the BPET philosophy!
First of all this philisophy is geared towards testing the software the way it is going to be used. How? You guessed it by mimicing business processes. So this approach starts with understanding the key business processes that support the organization and map them to the system identifying the ownership and roles of the system and its various components that support it. The rest of the plan is to define and develop test cases that verify these processes execution and the success and failure of the system to support the actions.
But two fundemental changes do exist with the traditional approach to testing. One is that the actors in this case (testers) are not traditional software testers but subject matter experts, operational staff who understand the business and have significant domain knowledge. The second but higly controversial, I assume since it causes radical mindset change is the defect priortization in this philosophy. A bug that crashes the application shall get a medium rating if it has minor operational risk.The situation that resulted in a bug is an exception and it is unlikely to occur or there is a reasonable workaround or avoidance strategy. At the same time a result that is not even technically an error – say, a degradation in performance during regular hours may be a showstopper since it means lack of customer response by customer help desk which means the 1000 calls being addressed every hour are not getting addressed. I think this is paradigm shift for both the business stakeholders and the software developers but it is the right way to execute the test strategy. After all it doesn’t matter whether the software is perfect or not as long as it meets the business process needs. BPET is the new mantra Amen!!!
I shall be further elaborating this area in my future blog updates!!!