Business Use Case Testing (BUCT)

The problem with traditional testing

Traditional testing answers: "Did the API return 200?"

BUCT answers: "Did the business outcome actually happen?"

In distributed systems, individual components can all pass their tests while the business workflow silently fails. A payment can be authorised without an invoice being generated. An order can be created without inventory being decremented. These are logical regressions — invisible to unit and integration tests, fatal to the business.

The high-speed risk gap

AI coding assistants are generating code faster than manual tests can keep up. Traditional testing becomes a bottleneck. BUCT acts as a strategic control layer that scales alongside AI-driven development.

BUCT vs traditional testing

Dimension	Traditional testing	BUCT
Primary focus	Technical integrity — units, APIs, schemas	Business outcomes — workflows, rules, revenue paths
Core question	Is the code right?	Is the business right?
Failure mode caught	Crashes, schema errors, status codes	Logical regressions, silent business failures
Cross-service coverage	Limited	Full orchestration awareness
Scales with AI codegen	No — becomes a bottleneck	Yes — acts as a control layer
Risk level	Low-level technical risk	High-level business and brand risk

Implementing BUCT

In the Service Onboarding section, we learnt how to onboard a service and perform integration testing of your micro-service and discussed how BaseRock tests your application on two levels - Service level and Application level.

Now we will focus on application level, i.e., Business Use Case Testing, that provides double-layered validations - functional layer and business layer.

Below is the user flow to utilise BUCT in test automation.

flowchart TD
  classDef phase1 fill:#eceff1,stroke:#90a4ae,color:#263238
  classDef phase2 fill:#e8eaf6,stroke:#5c6bc0,color:#1a237e
  classDef phase3 fill:#e8f5e9,stroke:#43a047,color:#1b5e20

  A[Login]:::phase1
  A --> B[Create a business flow]:::phase2
  B --> C[Upload BRD or PRD]:::phase3
  C --> D[Extract use cases]:::phase3
  C --> E[Associate a service]:::phase3
  D --> F[Map use case to test case]:::phase3
  E --> F
  F --> G[Generate playbook]:::phase2
  G --> H[Execute]:::phase2

1. BRD ingestion

Go to the Business Flows section from the left panel and create a flow as shown in the screen below.

Upload your Business Requirement Documents (.txt or .pdf) in the Requirements tab.

2. AI-driven use case generation

Navigate to the Use Cases tab and click Generate Use Cases. The platform parses the document, and the AI converts abstract business statements into structured, executable test scenarios as shown below.

Example

BRD input: "When a customer places an order, it should be fulfilled and invoiced."

BUCT output: A multi-step flow validating payment authorisation, inventory decrement, invoice generation, email dispatch, shipment trigger, and audit logging.

3. Associate a service

For BUCT to know the details of the actionable endpoints, the user must add an existing onboarded service under the Services tab within the Business Flow.

To learn service onboarding in detail check here.

4. Use case to test case mapping

Click the three dots in the top-right corner and select Map Use Cases to Test Cases. This will generate test cases for the respective use cases. If the tests cannot be produced, they will be marked as missing test cases, showing the coverage gap between the requirement and the service under test.

If the test cases were already generated inside the service then extracted business use cases will be mapped to the relevant test cases — ensuring full cross-service coverage, not just endpoint-level coverage.

5. Test cases

These test cases are end-to-end tests which can be executed based on the selected playbook which carries all the steps present in the complete flow in simple english. Users can select any existing playbook from the dropdown and add some business specific verifications at the end under "Verification Steps" prompt area.

Note

If you are interested in just integrations tests and not end-to-end, refer to this section: Integration Tests

6. Playbook generation

Business use case level playbooks get automatically generated once the use case to test case mapping is complete.

Each playbook orchestrates a complete flow across all the microservices involved in the business use case — eliminating siloed, service-by-service validation. Rather than testing services in isolation, a playbook sequences actions end-to-end: from the first user-facing interaction through every downstream system required to fulfil that business outcome based on the context ingested by BaseRock either via BRD or MCP server integration of tools like Confluence or Notion.

This means playbooks validate not just whether each service functions correctly on its own, but whether the complete business journey delivers the expected result — start to finish.

BaseRock generates multiple playbooks per business use case, each targeting a distinct testing scenario:

Happy path — the expected, successful completion of the workflow
Edge cases — boundary conditions and uncommon but valid inputs
Negative cases — invalid inputs, missing data, and error-handling paths

Users can then open and edit any playbook using natural language, based on their domain-specific testing plan.

E-commerce: Place an order

Consider a checkout flow spanning three services — Account, Order, and Payment.

A BUCT playbook for the "Place an Order" use case sequences the entire journey in a single execution:

Authenticates the user via the Account service
Creates an order via the Order service
Processes payment via the Payment service
Validates the end-to-end outcome — order confirmed, payment charged, inventory updated

Separate playbooks cover scenarios such as a payment failure, an out-of-stock item, or an unauthenticated checkout attempt — each as a distinct, independently executable flow.

7. Agent-based execution

Once mapping is done and playbooks and configurations are set, users can start testing with the help of the BaseRock agent.

The BaseRock Agent executes deterministic end-to-end flows inside your CI/CD pipeline. Works across microservice and monolithic architectures.

To learn more about the BaseRock agent, refer to the BaseRock Agent Usage section.

8. Use case execution result

Once test execution is triggered by user, thay are navigated to the test run result page that has 2 tabs - Test Case View and Use Case View as shown in the below screen

In the Use Case View tab users can hover over any use case to see the exact set of test cases corresponding to it and their respective result.

BUCT Example for better understanding: eCommerce order placement

PRD statement: "When a customer places an order, it should be fulfilled and invoiced."

Traditional testing validates BUCT validates Step-by-step breakdown

POST /orders returns HTTP 200
Response schema matches spec
Required fields are present

It does not validate whether the business outcome actually happened.

Payment gateway authorisation succeeded
Inventory decremented by correct quantity
Invoice was generated
Confirmation email was dispatched
Shipment workflow was triggered
Audit logs recorded with correct timestamps and user attribution

Step 1 — Order creation

Confirm order ID is generated
Validate status is initialised correctly

Step 2 — Payment

Confirm payment authorisation
Ensure transaction_status = SUCCESS
Assert no duplicate charges

Step 3 — Inventory

Verify stock reduced by purchased quantity
Assert no negative inventory state

Step 4 — Notifications

Confirm confirmation email trigger
Validate email contents — Order ID, pricing, delivery address

Step 5 — Shipping

Confirm shipment record creation
Validate correct warehouse assignment

Step 6 — Audit & compliance

Confirm transaction log entry
Validate timestamp and user attribution

Architecture

BUCT runs on two components:

Control plane
- Parses source code and PRDs
- Generates business use cases
- Maps requirements to test coverage
Agent
- Executes end-to-end business flows
- Handles setup and teardown per playbook
- Validates runtime-generated values (dynamic IDs, timestamps)

Why the split?

The control plane (intelligence) stays separate from the agent (execution), making BUCT portable across any CI/CD system.

Key capabilities

AI-driven flow generation

Use cases generated directly from PRD text — no manual scripting.
Cross-service orchestration

Validates workflows spanning multiple services, not just individual endpoints.
Playbook composability

Reusable, version-controlled playbooks reduce duplication across test suites.
Deterministic execution

Consistent results for AI-generated code across environments.
Revenue-path confidence

Prioritises validation of business-critical flows over low-level noise.