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.
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.
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.
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 🙂