How Model-Based Test Automation Actually Works
This is the section the rest of the page depends on, and it is the one every competing page compresses into a paragraph.
You Describe the Application Once, as Reusable Modules
Before writing any test, you scan the application. The tool inspects a screen and records what is on it: the fields, the buttons, the tables, and how to find each one.
What comes out is a module. A module is a description of one piece of the application — a login screen, a customer search, an order entry form — with its controls named in business terms rather than technical ones.
That renaming is the quiet part that matters. The person who built the module decides that a particular field is called Customer Number. From then on everybody who uses that module works with Customer Number rather than with whatever the underlying control is called. The technical detail is captured once, by somebody who understood it, and then hidden.
Build enough modules and you have a description of your application that other people can use without knowing how it is built.
A Test Case Is an Assembly, Not a Script
With the modules in place, a test case becomes a list of modules in order, each with the values you want to use.
Log in, with these credentials. Search for a customer, with this number. Create an order, with these lines. Check the confirmation, with this expected total.
The values are supplied separately from the steps, as steering parameters, which is what lets one test case run twenty times with twenty different data sets without twenty copies existing. The steps say what happens; the parameters say with what.
The effect is that test cases become short and readable. Somebody who knows the business process can read one and tell you whether it is correct, which is not true of most automation code. It also means the same module is used by every test that touches that screen — which is where the next point comes from.
Why This Changes Maintenance Rather Than Authoring
Authoring the first test in a model-based tool is slower than writing a script, not faster. You have to build the modules first, and until they exist you have nothing to assemble.
The change arrives later. When the application moves a field, a scripted suite needs every test that touches that field edited. A model-based suite needs the module edited once, and every test using it is repaired at the same moment.
That is the entire economic argument for this class of tool, and it explains why it suits large suites. With twelve tests, editing each one is annoying. With nine hundred tests and a packaged application that is upgraded twice a year, editing each one is not possible. A suite that cannot be repaired after an upgrade is a suite that gets abandoned.
So the honest claim is not that model-based test automation makes testing faster. It is that it makes a large suite survivable.
Codeless Test Automation Does Not Mean No Skill Required
Tosca is described as codeless, and that description is accurate about syntax and misleading about difficulty.
What goes away is the programming language. Nobody writes a loop, declares a variable or debugs a null reference. That genuinely opens the work to business testers, and it is a real advantage where the people who understand the process are not developers.
What does not go away is test case design. Deciding what to test, choosing the data that will expose a defect, working out how to leave the system in a clean state afterwards, deciding what a test should assert. All of that is the actual skill, and it is unchanged. A team that automates without it produces a large suite that passes reliably and catches nothing.
The modelling itself is also a skill. Modules built badly — too large, too specific, keyed on things that move — produce a suite with all the maintenance problems of a scripted one and none of the benefits.
The first few weeks of a Tosca programme decide this, which is an argument for having somebody experienced present at the start rather than at the end.
The Cost Nobody Quotes: Building the Model Before the First Test Runs
Here is the number missing from every evaluation.
Before the first test executes, somebody has to scan the screens, build the modules, name the controls sensibly, and decide how the application is going to be divided up. On a large packaged system this is weeks of work, and it produces nothing anybody outside the team can see.
That is uncomfortable in an organisation that funded the tool on a promise of faster testing. The first month looks slower than doing nothing, because it is.
Two consequences worth planning for. Scope the first phase around building a model for one business process rather than around a number of automated tests, so the milestone matches the work. And expect a question at week three about why nothing is automated yet, from somebody who saw the demonstration. Having the answer ready is part of the job.
