A business process document, also called a business process definition or design. It describes one process area of an implementation: the steps, the apps, the roles, the requirements and the custom builds.

Does it need a particular template?

No. Two common layouts are read: a design-led one with roles, a best-practice flow, gaps and a functional design, and a requirements-led one with a requirement register, key decisions, controls and a test list. Anything it cannot place it leaves out rather than guesses at.

Is a language model writing these test cases?

No. The requirements, gaps, test cases and scenarios are built by rule from the document, so the same document always gives the same result and every line can be traced. Nothing is added that the document does not say.

What is the difference between a test case and a test scenario?

A test case is one component check: a single step run in one app or transaction. A test scenario is a set of test cases strung back to back in the order the process runs.

How does coverage from tables work?

A posting leaves a journal entry that stores its transaction code. Given an extract of journal entries counted by transaction code, each test case that names a posting transaction can be checked against it. Display steps and master data changes leave other traces, and the assessment says which table would show each.

What happens to the document I upload?

It is read to produce the assessment and is not stored. The list of documents assessed in a session is kept in your browser only, so a second document can be compared with the first.

BPD assessment — requirements, gaps, test cases and test scenarios from a business process document

About the BPD assessment

A business process document says how a process will run: who does what, in which order, in which app, and where the design leaves the standard. Specforge reads it and returns what a program needs next. You get the requirements the document carries, the gaps it leaves, a test case for each step, and the scenarios that string those cases end to end. Each result points back to the line of the document it came from. Specforge does not sell the software or the implementation, so the reading is independent.

How it works

1Upload or paste the documentA Word file is best, because its headings, step tables and requirement lists come through intact. PDF and plain text work too, up to 8 MB. You see the text before anything is assessed.
2RequirementsThe requirements come back as a traceability matrix. Each sub-process is a grouping with one Feature row, and under it a row for every work item: configuration, a custom build, a master record, security, an operating procedure, a training manual. Each row keeps the document's own id and words, and shows the tests that cover it. A field the document makes mandatory is a row too.
3GapsThe parts of the process the document does not cover, measured against the requirement corpus for that process area. Then what looks missing from its own lists: a build the register points at that the list does not describe, and whether it says how existing data reaches the new system. That conversion check runs on every document. Each gap is a count you can check.
4Test casesOne test case per step, on the Fiori app or transaction code the document names for it, with a precondition, an action and an expected result. Where a step states its postings, the postings are the expected result.
5Test scenariosThe test cases of each flow strung back to back in the document's order, with the hand-offs between owners and a refusal test at each control point. Assess a second document and the scenarios that run across both appear.
6CoverageEach test case is sorted by the system table that would prove it ran. Paste journal entries counted by transaction code and you see which cases have postings behind them, which have none, and what was posted that no test names.

What you get

A requirements traceability matrix: groupings, typed work items and a trace to the tests that cover each one
The process the document does not cover, and what is missing from its own lists, as counts you can check
One workbook with every output on its own sheet
Test cases on named apps and transactions, ready to download as a spreadsheet
Test scenarios within a document and across documents
A statement of how much of the test set system tables can evidence

Who it's for

Test leads, functional leads and program managers who receive process designs and have to turn them into a test plan. Also finance and audit owners who need to know which requirements have a test behind them before a test cycle is called complete.

Common questions

What is a BPD?: A business process document, also called a business process definition or design. It describes one process area of an implementation: the steps, the apps, the roles, the requirements and the custom builds.
Does it need a particular template?: No. Two common layouts are read: a design-led one with roles, a best-practice flow, gaps and a functional design, and a requirements-led one with a requirement register, key decisions, controls and a test list. Anything it cannot place it leaves out rather than guesses at.
Is a language model writing these test cases?: No. The requirements, gaps, test cases and scenarios are built by rule from the document, so the same document always gives the same result and every line can be traced. Nothing is added that the document does not say.
What is the difference between a test case and a test scenario?: A test case is one component check: a single step run in one app or transaction. A test scenario is a set of test cases strung back to back in the order the process runs.
How does coverage from tables work?: A posting leaves a journal entry that stores its transaction code. Given an extract of journal entries counted by transaction code, each test case that names a posting transaction can be checked against it. Display steps and master data changes leave other traces, and the assessment says which table would show each.
What happens to the document I upload?: It is read to produce the assessment and is not stored. The list of documents assessed in a session is kept in your browser only, so a second document can be compared with the first.