QA examples

See how testing is documented.

Two illustrative examples show how DOKRAVE plans, executes and reports a test round: scope, scenarios, results, findings and retest.

Request a test estimate

About these examples

Both are synthetic demonstrations based on common API and integration testing patterns. Names, data and system details are generic and no customer or production system is described. The documentation is shown in English, as test documentation commonly is.

01

API order creation

Functional, authentication and data-validation testing

An order-creation endpoint is checked for valid requests, access control, required fields and stored data. An initial authentication defect is found, fixed and retested.

  • 6 scenarios
  • 5 Pass
  • 1 Fail
  • 1 finding(s)
Report (PDF)Scenarios (CSV)
Overview / In scope / Test approach

Overview

A synthetic demonstration of testing an API endpoint that creates business orders. It covers request handling, authentication, input validation and verification that submitted data is correctly stored.

Testing objective

Verify that an order-creation endpoint accepts valid authenticated requests, rejects unauthorised or invalid requests, and persists submitted information consistently.

In scope

  • Successful order creation using a valid authenticated account.
  • Access control when no valid authentication is supplied.
  • Required-field and malformed-input handling.
  • Verification of created order data in the application and underlying data store.
  • Retesting after an authentication defect is corrected.

Out of scope

  • Full penetration testing or a formal security assessment.
  • Load, stress or performance testing.
  • Testing every API endpoint or all possible business rules.

Test approach

  1. Review the endpoint purpose and expected request structure.
  2. Use an API client or interactive API documentation to submit requests.
  3. Compare responses with expected behaviour.
  4. Verify persisted order data through the application and, where appropriate, read-only database queries.
  5. Record defects with reproducible steps and retest after a change.

Test scenarios and results

  • API-01

    Valid authenticated request

    Pass
    Steps
    Submit a complete, valid order request with a permitted account.
    Expected result
    The endpoint accepts the request and returns the documented success response and order reference.
    Result
    Pass in this illustrative scenario.
  • API-02

    Request without authentication

    Fail
    Steps
    Submit an otherwise valid request without credentials.
    Expected result
    The request is rejected; no order is created.
    Result
    Failed. The unauthenticated request was accepted and an order could be inserted.
  • API-03

    Missing required field

    Pass
    Steps
    Omit a field defined as mandatory in the API contract.
    Expected result
    The API returns a clear validation response; no incomplete order is created.
    Result
    Pass in this illustrative scenario.
  • API-04

    Persisted data verification

    Pass
    Steps
    Retrieve the created order in the application and in the database, and verify the relevant stored fields.
    Expected result
    Stored values match the submitted request and business rules.
    Result
    Pass in this illustrative scenario.
  • API-05

    Authentication defect retest

    Pass
    Steps
    Repeat the unauthenticated request after the access-control change.
    Expected result
    The request is rejected and no order is created.
    Result
    Pass on retest.
  • API-06

    Full repeat after the fix

    Pass
    Steps
    Repeat API-01, API-03 and API-04 after the access-control change to confirm nothing else was affected.
    Expected result
    All earlier results still hold.
    Result
    Pass. The change was approved.

Illustrative request (generic data)

POST /api/orders
(no Authorization header)

{
  "customerId": "C-1042",
  "currency": "EUR",
  "lines": [
    { "sku": "SKU-001", "quantity": 2, "unitPrice": 19.90 }
  ]
}

Expected:  401 Unauthorized, no order created
Observed:  201 Created, order inserted   (defect API-F01)

Findings

API-F01 · Severity / impact: High

Unauthorised order creation

The endpoint accepted a valid order-creation request without an authenticated session or valid credentials. This could allow unauthorised order creation.

Retest / follow-up: The access-control behaviour was corrected and the unauthenticated request was repeated. The request was then rejected, and the earlier scenarios were repeated successfully.

Outcome

This demonstration combines functional API checks with access-control verification and data-persistence checks. It illustrates a defect loop: reproduce, document, verify the change and retest. It is not a full security audit.

Tools and techniques

Illustrative tools: Postman or Swagger UI for API requests; application-level verification; read-only SQL queries where database access is available.

Synthetic demonstration. Names, data and system details are generic. Outcomes are illustrative and are not a claim about a named customer or production system.

02

E-commerce to ERP integration

Integration, data synchronisation and exception-handling testing

Data flow between an e-commerce platform and an ERP is checked for sync direction, customers, order import and a missing-product exception. The exception is not handled as specified.

  • 6 scenarios
  • 4 Pass
  • 1 Fail
  • 1 Pass with workaround
  • 1 finding(s)
Report (PDF)Scenarios (CSV)
Overview / In scope / Test approach

Overview

A synthetic demonstration of validating data exchange between an e-commerce platform and an ERP system. It focuses on synchronisation direction, product and customer data, order import and handling missing product records.

Testing objective

Verify that supported e-commerce data is transferred to the ERP as specified, synchronisation occurs only in the intended direction, and exceptions are handled in accordance with integration requirements.

In scope

  • Product synchronisation from the e-commerce platform to the ERP.
  • Confirmation that ERP-side product changes do not trigger unsupported reverse updates.
  • Order import for an existing customer and a newly created customer.
  • Order handling when an order contains a product not yet available in the ERP.
  • Retry behaviour after the missing-product condition is addressed.

Out of scope

  • Testing all features of the e-commerce platform or ERP.
  • Payment-provider, tax-calculation or shipping-carrier certification.
  • Performance, volume or resilience testing beyond the stated scenarios.

Test approach

  1. Confirm intended data-flow direction and expected mapping rules.
  2. Create and update controlled test records in the source system.
  3. Verify corresponding records and values in the ERP.
  4. Check that ERP actions do not create unintended reverse synchronisation.
  5. Create orders for existing and new customers, then verify imported order details.
  6. Introduce a missing-product condition and compare observed behaviour with the agreed exception rule.

Test scenarios and results

  • INT-01

    New product synchronisation

    Pass
    Steps
    Create two products in the e-commerce platform.
    Expected result
    Corresponding products are created in the ERP with the expected mapped information.
    Result
    Pass in this illustrative scenario.
  • INT-02

    No reverse product synchronisation

    Pass
    Steps
    Create a counterpart product in the ERP, edit it and delete it, then check the e-commerce platform.
    Expected result
    ERP-side changes and deletions do not trigger an update in the e-commerce platform.
    Result
    Pass in this illustrative scenario.
  • INT-03

    Existing customer order

    Pass
    Steps
    Place an order using a customer already present in the ERP.
    Expected result
    The order is imported and associated with the correct customer.
    Result
    Pass in this illustrative scenario.
  • INT-04

    New customer order

    Pass
    Steps
    Place an order using a customer not yet present in the ERP.
    Expected result
    The customer is created or matched according to integration rules, and the order is imported correctly.
    Result
    Pass in this illustrative scenario.
  • INT-05

    Order with missing product

    Fail
    Steps
    Place an order containing a product that does not exist in the ERP.
    Expected result
    The integration follows the specified exception rule, such as creating a designated placeholder product while retaining the original product description.
    Result
    Failed. The expected placeholder was not created and the order remained pending.
  • INT-06

    Retry after prerequisite is addressed

    Pass with workaround
    Steps
    After the missing-product condition is addressed, retry the pending order.
    Expected result
    The order is imported without duplication and retains correct customer, product and order information.
    Result
    Pass after manually creating the required placeholder. This is a workaround, not evidence that automatic exception handling was fixed.

Findings

INT-F01 · Severity / impact: Medium to high, depending on business context

Missing-product exception not handled as specified

When an order contained a product absent from the ERP, the expected placeholder-product handling did not occur and the order remained pending.

Retest / follow-up: A placeholder was created manually and the order was retried successfully. This showed a workaround and recovery path; it did not verify a permanent correction. Recommendation: create the placeholder product, or confirm the exception rule is implemented, before the integration goes live.

Outcome

This demonstration covers integration behaviour across systems, including data-flow direction, customer handling, order import and exception recovery. It shows why testing must verify not only successful synchronisation but also behaviour when required data is missing.

Tools and techniques

Illustrative tools: e-commerce test environment, ERP test environment, integration logs and application-level data verification.

Synthetic demonstration. Platform and system references are generic. The missing-product behaviour and manual workaround are illustrative, not a claim about a named customer or production integration.

What needs testing?

Describe the system, what is changing and your deadline. You will get questions or a proposed next step.

Request a test estimate