logotyp
  1. Introduction to BPM
  2. Implementation
  3. Methodology and design guidelines
  4. Testing

Overview of testing

Testing should happen throughout development. Many iterative development proponents argue that tests should be built before the code or components they relate to. There may be reasons not to take this approach, but developers should consider providing mechanisms for testing components (test services, test harnesses) to be part of the deliverables for the development process.

Iterative testing – not a “big bang” event, but ongoing throughout development

  • Unit and functional testing for each iteration
  • Write test cases based on user stories for acceptance testing
  • Set up procedures for generating and resetting test data in each environment

Something may happen often, but has little or no impact on the intended goals for the process, it’s probably not worth investing lots of time on tests to identify that defect. Conversely, if something is extremely unlikely to occur, but has catastrophic impact if it does, you must test for it.

Sizing of testing:

  • Scale the effort to the value of the process.
  • Push responsibility for testing the components down to the right level.
  • Focus on verifying the orchestration
  • Focus on validating the highest risk items in your process
  • For example: Highest volume services, Highest volume user-touch processes
  • Focus on creating tests to verify defect fixes

Types of testing

For most BPM solutions, the testing effort needs to be organized slightly differently than for pure-code development – you can focus more on testing the logic embodied in the business process definition (BPD) than on the expression of that logic in code.

Manual testing

Testing by a formal QA group outside the project team may dictate production of additional documentation beyond what is required to develop a BPM solution effectively. Identify and negotiate organizational expectations early on in project initiation.

For less complicated solutions, usually manual testing will suffice. The effort to develop test services/harnesses is sometimes not justified based on the effort and return.

Automated testing

  • Unit (white box) – test inputs/outputs of a specific unit
    • Works well with services
    • Can be written as a service to call the service being tested
  • Functional (black box) – test system
    • Works well with coaches
    • Can be implemented with 3rd party tools
  • Performance Testing for high volume solutions

IBM Business Process Manager tool

uploads/dw012.png
Fig. 5.3.7/1

  • Use the Process Designer to analyze, run, and track quality of the solution
  • Simulate and analyze
    • Use simulation to uncover resource shortages or bottlenecks before full implementation is performed
  • Identify and track Issues
    • Use IBM services to run each unit test, a suite of unit tests, or an entire regression suite
    • Generate load with scripted calls to a web service or event
  • Measure and analyze
    • Use Business Performance Warehouse to analyze the results of tests
    • Use Business Performance Warehouse to report analyze find vs. fix rate
    • Use Process Designer to measure performance of integrations using tracking points
    • Use Process Designer to measure performance of services using tracking points

Implementation testing in IBM Business Process Manager can be handled in a number of ways, many of them that are similar to other software systems.

  • Manual testing can be handled within BPM both as is, using the process inspector to run processes, and with some additional help from the process authors, by creating test services that allow a quality assurance team or the process authors to test individual coach screens and integration services.
  • Automated unit tests in IBM Business Process Manager can be created as services that call another service with particular inputs and check the outputs, raising an exception if the output is unexpected. Automated functional tests can also be created using third- party tools