Exemple QA

Iată cum este documentată testarea.

Două exemple ilustrative arată cum DOKRAVE planifică, execută și raportează o rundă de testare: domeniu, scenarii, rezultate, constatări și retestare.

Cere o ofertă de testare

Despre aceste exemple

Ambele sunt demonstrații sintetice, bazate pe tipare uzuale de testare API și integrări. Numele, datele și detaliile de sistem sunt generice și nu descriu niciun client sau sistem de producție. Documentația este afișată în engleză, așa cum este de obicei documentația de testare.

01

Creare comenzi prin API

Testare funcțională, de autentificare și de validare a datelor

Un endpoint de creare a comenzilor este verificat pentru cereri valide, control al accesului, câmpuri obligatorii și date stocate. Un defect inițial de autentificare este găsit, remediat și retestat.

  • 6 scenarii
  • 5 Reușit
  • 1 Eșuat
  • 1 constatare/constatări
Raport (PDF)Scenarii (CSV)
Prezentare generală / În domeniu / Abordare

Prezentare generală

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.

Obiectivul testării

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

În domeniu

  • 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.

În afara domeniului

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

Abordare

  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.

Scenarii de test și rezultate

  • API-01

    Valid authenticated request

    Reușit
    Pași
    Submit a complete, valid order request with a permitted account.
    Rezultat așteptat
    The endpoint accepts the request and returns the documented success response and order reference.
    Rezultat
    Pass in this illustrative scenario.
  • API-02

    Request without authentication

    Eșuat
    Pași
    Submit an otherwise valid request without credentials.
    Rezultat așteptat
    The request is rejected; no order is created.
    Rezultat
    Failed. The unauthenticated request was accepted and an order could be inserted.
  • API-03

    Missing required field

    Reușit
    Pași
    Omit a field defined as mandatory in the API contract.
    Rezultat așteptat
    The API returns a clear validation response; no incomplete order is created.
    Rezultat
    Pass in this illustrative scenario.
  • API-04

    Persisted data verification

    Reușit
    Pași
    Retrieve the created order in the application and in the database, and verify the relevant stored fields.
    Rezultat așteptat
    Stored values match the submitted request and business rules.
    Rezultat
    Pass in this illustrative scenario.
  • API-05

    Authentication defect retest

    Reușit
    Pași
    Repeat the unauthenticated request after the access-control change.
    Rezultat așteptat
    The request is rejected and no order is created.
    Rezultat
    Pass on retest.
  • API-06

    Full repeat after the fix

    Reușit
    Pași
    Repeat API-01, API-03 and API-04 after the access-control change to confirm nothing else was affected.
    Rezultat așteptat
    All earlier results still hold.
    Rezultat
    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)

Constatări

API-F01 · Severitate / 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.

Retestare / urmărire: The access-control behaviour was corrected and the unauthenticated request was repeated. The request was then rejected, and the earlier scenarios were repeated successfully.

Concluzii

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.

Instrumente și tehnici

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

Integrare e-commerce–ERP

Testare de integrare, sincronizare a datelor și tratare a excepțiilor

Fluxul de date dintre o platformă e-commerce și un ERP este verificat pentru direcția sincronizării, clienți, importul comenzilor și o excepție de produs lipsă. Excepția nu este tratată conform specificației.

  • 6 scenarii
  • 4 Reușit
  • 1 Eșuat
  • 1 Reușit cu soluție ocolitoare
  • 1 constatare/constatări
Raport (PDF)Scenarii (CSV)
Prezentare generală / În domeniu / Abordare

Prezentare generală

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.

Obiectivul testării

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.

În domeniu

  • 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.

În afara domeniului

  • 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.

Abordare

  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.

Scenarii de test și rezultate

  • INT-01

    New product synchronisation

    Reușit
    Pași
    Create two products in the e-commerce platform.
    Rezultat așteptat
    Corresponding products are created in the ERP with the expected mapped information.
    Rezultat
    Pass in this illustrative scenario.
  • INT-02

    No reverse product synchronisation

    Reușit
    Pași
    Create a counterpart product in the ERP, edit it and delete it, then check the e-commerce platform.
    Rezultat așteptat
    ERP-side changes and deletions do not trigger an update in the e-commerce platform.
    Rezultat
    Pass in this illustrative scenario.
  • INT-03

    Existing customer order

    Reușit
    Pași
    Place an order using a customer already present in the ERP.
    Rezultat așteptat
    The order is imported and associated with the correct customer.
    Rezultat
    Pass in this illustrative scenario.
  • INT-04

    New customer order

    Reușit
    Pași
    Place an order using a customer not yet present in the ERP.
    Rezultat așteptat
    The customer is created or matched according to integration rules, and the order is imported correctly.
    Rezultat
    Pass in this illustrative scenario.
  • INT-05

    Order with missing product

    Eșuat
    Pași
    Place an order containing a product that does not exist in the ERP.
    Rezultat așteptat
    The integration follows the specified exception rule, such as creating a designated placeholder product while retaining the original product description.
    Rezultat
    Failed. The expected placeholder was not created and the order remained pending.
  • INT-06

    Retry after prerequisite is addressed

    Reușit cu soluție ocolitoare
    Pași
    After the missing-product condition is addressed, retry the pending order.
    Rezultat așteptat
    The order is imported without duplication and retains correct customer, product and order information.
    Rezultat
    Pass after manually creating the required placeholder. This is a workaround, not evidence that automatic exception handling was fixed.

Constatări

INT-F01 · Severitate / 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.

Retestare / urmărire: 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.

Concluzii

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.

Instrumente și tehnici

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.

Spuneți ce trebuie testat.

Descrieți sistemul, ce se schimbă și termenul. Veți primi întrebări sau un pas următor propus.

Cere o ofertă de testare