COVER is available within the Sogeti service: STaaS (Software Testing as a Service).
Model-Based Testing
Wikipedia:
Model-based testing is software testing in which test cases are derived in whole or in part from a model that describes some (usually functional) aspects of the system under test (SUT).The model is usually an abstract, partial presentation of the system under test's desired behavior. The test cases derived from this model are functional tests on the same level of abstraction as the model. These test cases are collectively known as the abstract test suite. The abstract test suite cannot be directly executed against the system under test because it is on the wrong level of abstraction. Therefore an executable test suite must be derived from the abstract test suite that can communicate with the system under test. This is done by mapping the abstract test cases to concrete test cases suitable for execution. In some model-based testing tools, the model contains enough information to generate an executable test suite from it. In the case of online testing, the abstract test suite exists only as a concept but not as an explicit artifact.
Test Case Design: Manually or Automated?
There are several tools that can help with the creation of test cases.
Why don't we succeed in automating the Test Cases Design Process? In this short article I will explain that, if test collaborates with design, we can make huge progress on this topic!4 Examples of Test Case Design
Let’s imagine a business process that is documented by the design team on one page. Test will create the test cases. In the first example the description is done in plain text. In that case it is not possible to automate the test, and also it is not possible to use a formal test specification technique:
Example 1: Test Design from plain text: many interpretations and assumptions...
Creating test cases from plain text may look easy, but when you ask 5 test engineers to create the test cases you get 5 different sets without any insight in the quality of the coverage.
Choosing the process flow diagram technique for describing the business process, will result in less interpretations and assumptions, therefore in much better test cases:
Example 2: Manual Test Design: Process Cycle Test (TMap®)
The advantage of formal Test Case Design techniques like Process Cycle Test (PCT) is that it can be automated! How? The first step of deriving test cases with PCT, is to identify the paths and path combinations within the process flow diagram. Step 2: Instead of manually combining those path combinations to test cases, the path combinations (joined with a short description) can be inserted in STaaS/COVER. Step 3: The test cases are generated. Comparing with manual test case design: much faster; less knowledge is needed, but you need STaaS/COVER (services):
Example 3: Using STaaS/COVER: much Faster!
Most of the time, designers make these process flow diagrams in modeling tools (like MsVisio, Protos, Aris, BiZZdesigner,..). A common feature of the modeling tools is exporting the models in XML-format. STaaS/COVER can read XML! So, let’s skip all manual steps and generate test cases directly from the process flow diagram:
Example 4: STaaS/COVER XML interface
STaaS/COVER can generate test cases within minutes. Of course, before using the test cases you must do a sanity check to confirm the tool understood the model correctly but nevertheless the time can’t be beaten manually.
Collaborate!
Test Case Design can be automated (I’m already working with these tooling on a daily basis).
But, besides getting the right tool(s), there is an important condition: the Test Base must have a minimum level of quality.
For instance: instead of describing business processes in plain text, they should be specified with the help of activity diagrams or process flow diagrams (and that is not (yet) common knowledge within the design processes). To get an automated Test Design process, let’s join the forces: Together, Design and Test can make projects much faster and cheaper!
Rob Kuijt
Model-Based Testing "basic"
Most participants in the Model-Based Testing world are very ambitious...
Practically everyone in the MBT world tries to Generate Test Cases for direct automatic execution, based on test specific models. I think this is a bridge to far for most companies using for instance mainly ERP-software. In the ERP-scope most of the testing is still done manually, and jumping to this ultimate form of Model Based Testing (Generate Test Cases for direct automatic execution) will be very tricky and/or costly. That's why Sogeti is introducing also a basic form of Model-Based Testing (STaaS/COVER), using the same models as the developers do.MBT: Generate Test Cases for direct automatic execution
Does this mean that Generating automated tests is a dead end? NO! It is a very good approach for testing high risk functionalities, which are to risky or to complex to test manually. Making test specific models is a costly business and top designers/test engineers are needed to make it work. So be sure to pinpoint these heavy coverage and tooling only on the high risk areas. AND!! Do not try to make the test specific models in the Testing Silo! Look for collaboration with the design department to get these test specific models in the same configuration mnagement as the models the devlopers use to build the software. Preferably in an "ALM Center Configuration Management".
MBT-basic: Using the same models as the developers do
On the other hand, when the ambition of Model Based Testing is lowered to only generating the test cases, it is a complete different story. Especially the generation of the (more global) logical test cases can be done from the same (functional and/or requirement) models the developers use as a bases for creating the software. For instance process flows (activity diagrams), decision tables and pseudo code are a perfect basis for generating (logical) test cases. Enrichment of these models (in collaboration with the design department) will bring us to the next step: Generating the physical test cases. In that case the Test Cases are no longer Configuration Items (costly maintenance!) but Test Cases become Work Items (if desired: directly generated from the same models the developers use to build the software).
Rob Kuijt
©Design2Test