How to automate Test-Design with Specmate – Part 2: End-to-End Testing of Business Processes

This article is a sequel to our blog post Structured Test-Design With Specmate – Part 1: Requirements-Based Testing published by my colleague Maximilian. So far, Maximilian introduced you to our tool Specmate –  a tool that helps you to automate your test-design. He explained how to model requirements using cause-effect-models and how to automatically generate test specifications based on them.

However, Maximilian told you only half the story (I’m sure you were already guessing that based on the Part 1 in the title. 😉 ): Not all requirements are like the ones in his examples. Many requirements are of a different nature and can’t be specified easily using cause-effect models.

In this post, I’ll demonstrate the second way of modeling requirements in Specmate: Business processes. Furthermore, I show how to generate automatically end-to-end tests based on these business processes.

Rule-based vs. Process-based Requirements

In our last blog post, we talked about requirements which are in a rule-based style “If this and that, then the following … except for … then …”. A large number of requirements in practice can be denoted in this style and cause-effect models are quite intuitive to model them. The basic characteristic of this kind of requirement is that they are more or less isolated from other requirements and/or cover just parts of the system. This comes handy since we can also test these requirements separately.

But this is only half of the story: Many business requirements are of a completely different nature. They are less of a rule-based nature but more of a process-like nature. Something like “First, the user enters A. Based on the input, the system does either B or C. Afterwards, the system asks the user for D, after that….”. Furthermore, these interaction scenarios by a user often cover larger parts of the system.

At this point, it turns out that cause-effect models are no one-size-fits-all modeling solution for all types of requirements: Cause-effect models just don’t work for process-like requirements.

Step 1: Business Process Models in Specmate

To test process-based requirements, we equipped Specmate with a second modeling technique: Namely, business process models (BPMs). We added a basic graphical modelling editor in specmate to create and maintain BPMs directly in Specmate.

A business process in Specmate

This figure shows a simple example BPM as modeled in Specmate. Note that typically business processes are larger and contain several hundred actions. In the example, we model the process of creating a new contract, starting from capturing personal and insurance data. Depending on the insurance type (car insurance or liability insurance) the specific data for this contract type is captured. Afterward the tariff is calculated and the contract is sent.


However, to be honest, the business-model editor is more for demo purposes. In real-world settings, we assume that business processes are maintained outside Specmate and are just imported. Nevertheless, our editor is quite smooth :-).

Step 2: Deriving End-to-End Tests

Why did we want to have modeled requirements in Specmate again? Oh yes, we wanted to (as far as possible) automatically generate test cases based on requirements. And how does a test for a business process look like? Well, it’s more or less a walkthrough through the business process from the start to finish. That’s why it’s called End-to-End Test.

A test specification for an end-to-end test is nothing more than a description of a path through the business process from start to end. Actually, we just have to describe in which direction we turned in case of decisions since all steps in between can be retrieved by looking at the business process.

Since BPMs are a semi-formal modeling technique, we could automatically generate test specifications by generating paths through a BPM.  Theoretically, all possible paths could be determined automatically. However, similarly to the cause-effect models, we need heuristics to limit ourselves to the relevant paths. So far, Specmate uses edge-coverage (aka C1-coverage) to select test cases with respect to the process graph. That means every connection of the model is part of at least one test case.

Example test-specification

From the simple BPM, Specmate generated two test-cases: One for each type of insurance.

Step 3: Automatically generating Test Procedures

So, what’s missing to get a test-procedure from a test-specification? Actually not much. Since business processes are already on an operational level giving step-by-step descriptions of how to walk through a process, a basic test procedure can be generated automatically.

Example test-procedures

In the example, Specmate generates two test-cases, one test-case for each of the two insurance types. Figure 6 shows the generated test-procedure for the case car insurance. Each action in the business process is mapped to a step in the test-procedure. For the condition in the BPM, Specmate creates an additional test-step. Note that the test-steps already reference the correct test-parameters.

You can adapt the generated test procedure, for example, add detailed test data or expected outcomes. From there, you can export the test procedures to test management tool or proceed by creating automated tests.


In this second article on Specmate I showed how requirements can be modeled using business processes in cases where cause-effect graphs are not suitable. From the process models Specmate can automatically derive test-cases and test-procedures. You can use the test-procedures for the actual testing in a test-management tool or go on with automating them.

Long story short … (TL;DR)

  • Cause-effect-modeling just fits for requirements of a rule-based nature.
  • We can model process-based requirements using business process models (BPMs) in Specmate.
  • For business process test-specifications, Specmate can generate test procedures automatically.
  • Stay tuned for the next episode of this series 🙂

Leave a Reply