How Worksoft Certify Business Process Testing Works
Worksoft Certify business process testing follows four stages. A real process is captured from the people who run it. Each screen it touches is mapped into a shared library of objects. The process test is assembled from reusable steps and fed with data. Then it runs, and each step leaves evidence behind.
The picture below follows one order through four systems.
Process Capture From Real User Activity
Most business process tests start with process capture. A business user completes the real task while a recorder watches, and the tool turns each click and entry into a test step. Worksoft markets a separate product, Business Capture, for discovering processes across applications at scale. Certify's own capture feature records individual tests.
Capture matters because the people who know a process best are rarely testers. A finance clerk knows every exception in the month-end close. A test built from their real steps is closer to reality than one written from a specification. It still needs review, though, because a recording shows what happened once, not every variation the process allows.
A few habits make capture work better. Record the normal path first, then the main exceptions one at a time. Use test data that can be reused, not a real customer who will change next week. Keep each recording short and focused on one task. And ask the user to explain what they check on screen, because those checks become the test's verification points.
The Object Model: Applications, Windows and Objects
Under the recorded steps sits an object model. Each application is described as a set of windows, meaning distinct screens, and each window as a set of objects, such as a field, a button or a table. Tests refer to these objects rather than to raw screen positions.
This is the part that decides test maintenance cost. When an upgrade moves a field or renames a button, the fix happens once, in the object library, and every test that uses that object picks it up. User reviews single out this design as a strength compared with script-based tools. They also note that setting up objects and windows correctly is where most of the learning curve sits.
A simple example shows why this matters. Say fifty tests use the customer number field on the sales order screen. An update renames that field, and in a script-based suite, someone may need to edit fifty scripts. In an object-based suite, someone updates one object, and all fifty tests run again. Multiply that by every field an upgrade touches, and the difference in test maintenance becomes large.
Processes, Steps and Test Data
A test in Certify is a process made of steps. Common sequences, such as logging in or creating a customer, can be built once and reused as sub-processes across many tests. That keeps the suite smaller and easier to change.
Test data is kept apart from the steps. The same order-to-cash test can run with a domestic customer, an export customer and a customer on credit hold, simply by feeding it different data. Good test data design is often harder than building the tests, because enterprise processes depend on master data, open documents and the state of other systems at the moment the test runs.
Teams usually mix three sources of data. Some tests create their own data as a first step, such as a new customer or material. Some use a stable set of master data that is refreshed on a schedule. And some use masked copies of production data, where privacy rules allow it. Each choice has trade-offs: tests that create their own data are the most reliable but take longer to run. Shared data is faster, but one test can change it for the next.
Test Execution and Audit Evidence
Once built, tests can run on a schedule or be triggered as part of a release. Users report built-in reporting and scheduled execution, so a full regression pack can run overnight without anyone watching.
Each run produces a step-by-step record with screenshots. The vendor presents this as automatic documentation of each process step. For regulated businesses that record is often as valuable as the test itself. It gives auditors and validation teams audit evidence that a process was tested, on which version, with which data, and with what result.
Test execution is only half the job, and the other half is reading the results. When a test fails, someone has to decide whether the software broke, the data was wrong, or the test itself needs updating. A clear triage routine keeps that quick. Look at the failed step and its screenshot first, check the data next, and only then raise a defect. Teams that skip this routine end up with long lists of failures that nobody trusts.
In a mature setup the suite is triggered automatically whenever a transport or release reaches the test environment, and the results are waiting for the team the next morning, which is what continuous testing means in practice for an estate built on packaged applications.
