Testing Services provides a platform for QA professionals to discuss and gain insights in to the business value delivered by testing, the best practices and processes that drive it and the emergence of new technologies that will shape the future of this profession.

« Performance Modeling - Implementation Challenges and Benefits | Main | Is your Performance Testing in an Agile SDLC really 'agile'? »

Testing of Business Process Implementations

 

There is no well-defined framework or solution when it comes to a testing strategy for BPM implementation. Testing methodology, to a great extent depends on the specific implementation (available points of interception, data protocols, transport protocols, traceability of business and design requirements etc.). In other words, not all BPM implementations are exact in nature. However, there are two major focus points when it comes to testing a BPM implementation

(a)    Service level validation

(b)   Business Process / Integration validation

Service level validation focuses on validating the service as a standalone entity. Tools exist which facilitate the automated validation of the functionality embedded behind the end point url. Some of the common tools are IBM RIT, CA LISA, HP Service Test, Parasoft SOATest, and Infosys IP Middleware Testing Solution. It has been witnessed in several engagements and projects that focus should not only be on the functional aspects of the service, but also on the performance, security and governance aspects. This helps in shift left of the entire validation process.

Business Process validation focuses on orchestration testing or choreographic validation of composite services. It doesn't stop at validating the routing logic alone. There is much more. Business Process validation is often not done using the Presentation tier. This means that the test requirements, tools and strategy are not going to be the same as used in Functional Presentation Tier testing. Key advantages with the process layer testing are:

(a)    Early Defect Detection

(b)   Reduced analysis

Below graph shows the defect detection pattern for two similar projects, where a white box testing for the Business Process Layer was done (Project A) and where it was not done (Project B). We can see that testing is halted by the critical 1 or 2 middle tier defects on the initial days in Project B (black box testing).

 

BPM.png

  Figure 1: Defect Detection Pattern

The defects in BPM testing are 'pin point' defects. They are isolated and the defective flow / attribute is pin pointed. This is different from the black box testing defects, where majority of the defects in the middle tier manifest as 'page not found' or 'service not available' to the end user.

To conclude, Business Process Method implementation requires a different testing strategy. The test strategy, to a great extent depends on the underlying technology architecture. Plugging in 3rd party BPM products from vendors like IBM, TIBCO and Pega will help eliminate the redundant development efforts to a great extent (more on the different BPM products in my next blog). Industry specific products are also available from most of these vendors. Nevertheless, validation of the integrated middle tier is of utmost importance as the architectural landscape DNA of every enterprise is different.

 

Comments

Good. A simple depiction of a very strong message. The importance of BPM testing is well articulated.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.