System Verification and Acceptance Specification¶
0. Document Control And Verification Baseline¶
| Item | Baseline |
|---|---|
| Document ID / type | SPEC-TEST / System Verification and Acceptance Specification |
| Baseline | the source revision, the build and config, the environment, the role and tenant, and the dataset are recorded together |
| State | PASS, FAIL, BLOCKED, NOT_RUN and NOT_APPLICABLE |
| Verification level | the document, the unit, the integration and DB, the browser and work, and the external and deployment levels are separated |
| Safety | the approved fixture, backup, cleanup, authority and external effect boundaries are stated |
| Acceptance | running a test, fixing a defect, the user sign-off and the release approval are judged separately |
The test results and examples in the template are not real execution evidence. Only reproducible current execution information and evidence are recorded as a result.
1. Verification Targets And The Distinction Of Completion¶
It defines the per-requirement test conditions, the expected results, the acceptance criteria and the evidence of the whole system. Authoring a test specification, running an automated check, and the real work acceptance are three different completions. This document is not a Booking test result collection, and it does not perform the CRUD of every area first in order to author the current document structure.
2. Test Layers And Common Scenarios¶
| Layer | What it proves | What it does not prove |
|---|---|---|
| Document and structure check | a link, a required item, an ID and a generated match | the approval of a requirement meaning, a product execution |
| Unit and model check | the branch, calculation and error contract of a fixed input | a real MySQL, browser or provider |
| Integration and DB check | a real save, the atomicity, the concurrency and the re-query | the real per-role UI path, the operational deployment |
| Screen and work acceptance | the real behaviour and result in the specified environment, role and data | another role, another Client, another environment |
| External and deployment acceptance | the real result of that file, device, provider or deployment | another external effect and the whole Production |
The common scenarios are the normal case, a required or boundary input, the authority and tenant isolation, a duplicate request, a concurrent edit, a lost response, a partial success, a correction and reversal, and the follow-up impact. A scenario that does not apply is distinguished with the reason.
3. Per-Area Test And Acceptance Contents¶
| Test group | The area and the linked requirement | The main acceptance result | The current detail |
|---|---|---|---|
| TST-01 | administration, access and settings / SYS-F01 | a valid authority, a settings change and recovery, and no change without authority | the test specification organisation is incomplete |
| TST-02 | master data / SYS-F02 | the reference, change, duplication and application scope | the test specification organisation is incomplete |
| TST-03 | trade / SYS-F03 | the item, the price, and the separation of contract and fulfilment | the test specification organisation is incomplete |
| TST-04 | inbound and outbound / SYS-F04 | the source, the quantity, the execution result and the failure recovery | part of the Receipt evidence |
| TST-05 | field work and Transload / SYS-F05 | the assignment, execution, correction and follow-up impact | the §3.3 detail cases are written; the real role, DB and provider acceptance is NOT_RUN |
| TST-06 | weighing / SYS-F06 | the ticket, the correction and the original preservation | the §3.4 detail cases are written; the real device, role and DB acceptance is NOT_RUN |
| TST-07 | inventory and warehouse / SYS-F07 | the ledger, remaining quantity, placement, allocation and reversal | §3.5 and [Receipt RCP](../../packages/modules/inventory/RECEIPT_DESIGN.md; the real full C2 acceptance is NOT_RUN |
| TST-08 | transport and Booking / SYS-F08 | the save, copy, role, link and output | Booking acceptance partially recorded |
| TST-09 | equipment and yard / SYS-F09 | the assignment, movement and return, and the independent state | the test specification organisation is incomplete |
| TST-10 | documents and output / SYS-F10 | the source, preview, file and the real output and dispatch | part of the Booking evidence |
| TST-11 | billing and settlement / SYS-F11 | the source, the rate, the amount, finalisation and correction | the test specification organisation is incomplete |
A TST number is a test group contents number of this document and is not an executed test ID. The existing BKG, SCN and RCP and test file identifiers are linked as they are. The existence of an existing check file is not marked as the completion of the acceptance of every area.
3.1 Current Check Owner And The Evidence Limit¶
The execution command and the check selection follow the test guide. The files below are focused check entry points and do not replace the whole test group or the real execution result. The reverse traceability to a requirement, the design and the source uses RTM.
| Test group | An example of the current focused owner | The confirmed scope | The real acceptance that is separately needed |
|---|---|---|---|
| TST-01 | identity/access·policy·platform administration contract tests | the typed decision, the input and output, and part of the DB adapter | a real per-role menu, page, API, record and action matrix |
| TST-02 | the master-data contract and each company and commodity adapter test | the reference shape and part of the tenant validation | the real C1 and C2 data quality, duplication and a change during a reference |
| TST-03 | scripts/tests/contract/commercial-order.test.ts |
the order and line parser, and the contract | a real MySQL transaction, the state and correction, and the role UI |
| TST-04 | fulfillment module/policy tests | the execution order, the create policy and the source contract | a real Inbound and Outbound save and a separate follow-up Receipt |
| TST-05 | transload completion simulated-DB test | the lock, commit and read-back, and the unknown branch | the real Loader and Office role, DB, partial effect and provider |
| TST-06 | scripts/tests/contract/phase2a-scale-evidence.test.ts |
the ticket and evidence decision contract | a real device and manual capture, a correction, and a consumer reconcile |
| TST-07 | inventory contract and Receipt and Allocation focused tests | the command and branch, and part of the simulated DB | the real C2 receipt→placement→allocation→reversal and the read-back |
| TST-08 | the Booking Web and DB contract and the existing BKG matrix | the scope stated in the per-detail Booking record | the unexecuted role, field, document output and link combination |
| TST-09 | the focused tests per yard and equipment owner | the source contract of the target command | the real movement, occupancy, return and partial recovery |
| TST-10 | scripts/tests/contract/document-preview.test.ts |
the HTML renderer and the PREVIEW contract | the pagination, the physical print, and the issue, store, email and provider |
| TST-11 | scripts/tests/contract/settlement-source.test.ts |
the AP and AR source line calculation and the difference | a real finalisation, correction, posting, payment and provider |
Even if a check file name exists, a target page E2E that is only registered or a mock-only result is not promoted to a real screen or DB acceptance. For the same reason, a document generation check PASS is not a PASS of a work specification content or a product behaviour.
3.2 System Integration Acceptance Scenarios¶
| ID | Scenario | The independent result to confirm |
|---|---|---|
| SYS-AT-01 | Agreement to the Fulfillment execution link | the identity, state and lines of the Agreement and the execution are separated, and the source is traced |
| SYS-AT-02 | Work and Scale evidence to Receipt | the work and Scale original is unchanged, the Lot and ledger are created, and a Placement success or failure is judged separately |
| SYS-AT-03 | Inventory Lot to Allocation to Outbound | the save and reversal of the relation, the remaining weight and quantity and the target line, and the over-allocation block |
| SYS-AT-04 | Booking to the outbound execution and document | the Booking and execution link cardinality, and the Packing source, overlay and preview state |
| SYS-AT-05 | Delivery to Yard to Container return | the Delivery, queue, occupancy, equipment and load and return state, and the partial result recovery |
| SYS-AT-06 | a source change to Document, Billing and Settlement | the source revision, the preview, the amount projection, and the finalisation, dispatch and payment effects are separated |
| SYS-AT-07 | tenant and role isolation | the C1 and C2 of the same capability and the per-role read, write and record scope, and no change |
| SYS-AT-08 | a lost response, a duplicate and a concurrent edit | the exact owner read-back, no duplicate effect, and the conflict and user recovery |
Each integration scenario is performed in the same approved data and environment after the related individual area test is ready. Every role, exception, provider and Production is not accepted with a single happy path.
3.3 TST-05 Transload Detail Test¶
| TC ID | Linked requirement | Preconditions and execution | Expected result | Current result |
|---|---|---|---|---|
| TRN-TC-01 | SYS-F05-R03 | Plan Preview and Apply on the appointment per tenant, a duplicate operator, and the 10 operator boundary | only a valid type and target are stored, the operator deduplication and the limit are applied, and the planner is re-read; the assignment and start are unchanged | NOT_RUN |
| TRN-TC-02 | SYS-F05-R03 | a UUID loader assign, a queue order change, then an unassign | the authoritative result of the assignment and the plan applied value, the DOCKED transition in an allowed state, and the unassign recovery | NOT_RUN |
| TRN-TC-03 | SYS-F05-R04 | check-in, staging, dock, cancel and after-clear are run in allowed and forbidden states | the Yard queue and location, the warehouse placement, the planner and the Transload change by the per-command rule, and there is no change in a forbidden state | NOT_RUN |
| TRN-TC-04 | SYS-F05-R04 | a No Show and a forbidden state attempt from SCHEDULED, PRE_PLANNED and ARRIVED | the plan, queue, remark and terminal inventory and placement are cleared and re-read; there is no change in a forbidden state | NOT_RUN |
| TRN-TC-05 | SYS-F05-R05 | a start of a DOCKED Transload and of an Unload each, including an equipment or location claim failure | the owner claim per type, the planner STARTED, the staff job event and the Transload re-read; on a failure the start is not complete | NOT_RUN |
| TRN-TC-06 | SYS-F05-R06 | a Complete Transloading with a photo count, a bale, seal and quantity boundary and valid values | a missing input is rejected with no change; when valid, the terminal result, equipment, planner and time, and the placement and Yard read-back | NOT_RUN |
| TRN-TC-07 | SYS-F05-R06 | the presence of an active warehouse location, and a Complete Unloading with a normal or a Space Review | a missing location is rejected; when valid, the independent results of the purchase lot and Inventory placement and of the Transload, planner and time | NOT_RUN |
| TRN-TC-08 | SYS-F05-R07 | an Undo from ARRIVED, DOCKED, work in progress and UNLOADED, and a returnToAutoPlanned combination |
only the allowed reversal and the per-step equipment, placement, Yard, planner and time compensation are performed; a non-target such as the provider is kept | NOT_RUN |
| TRN-TC-09 | SYS-F05-R08 | a normal and an error run of Spare, Leftover, Domestic, Scale and Document Submitted each | the field, state and follow-up owner result of the dedicated command, and the no change and the recovery, are independent of each other | NOT_RUN |
| TRN-TC-10 | SYS-F05-R02, R09, R10 | a lost commit response, a provider failure and a duplicate request, and a C1 and C2 capability and role combination | the result is judged by the owner read-back, only the external effect is resumed, there is no duplicate physical work, and a non-applicable C2 is NOT_APPLICABLE | NOT_RUN |
The current source and the simulated-DB focused checks are only the preparation basis of the cases above. A PASS verdict requires a real C1 and C2 role screen of the specified revision, an approved fixture, a before and after MySQL read-back, and the file and object and provider attempt and result evidence. A document generation check does not change the product test result of this table.
3.4 TST-06 Scale Detail Test¶
| TC ID | Linked requirement | Preconditions and execution | Expected result | Current result |
|---|---|---|---|---|
| SCL-TC-01 | SYS-F06-R03 | a first stage create in the correct and the opposite direction on the INBOUND and OUTBOUND Order per tenant | in the correct case a Ticket, source and bridge read-back, and in the opposite direction SCALE_ORDER_MISMATCH with no change |
NOT_RUN |
| SCL-TC-02 | SYS-F06-R03,R09 | a create with the same Ticket UUID and the same or a different payload, and a lost response | the same intent recovers the same Ticket, a different intent is an idempotency conflict, and there is no duplicate Ticket | NOT_RUN |
| SCL-TC-03 | SYS-F06-R04,R05 | a combination of a negative axis, a zero total, non-finite, a missing stage, gross<tare, and a zero or positive net | the input and evidence state and the blocker are exact, and a positive net and readyForReceipt only in VALID | NOT_RUN |
| SCL-TC-04 | SYS-F06-R04,R06 | the same stage with the same weights, different weights with or without a reason before completion, and a PATCH after completion | IDEMPOTENT, a reason-required correction event, and a normal reweigh of a completion is blocked with no change | NOT_RUN |
| SCL-TC-05 | SYS-F06-R06 | an editor expectedUpdatedAt that matches and does not match, and a weight and time change remark with or without one | a CAS success and an authoritative re-read, or a conflict; the before and after lineage and the linked Transload snapshot are confirmed | NOT_RUN |
| SCL-TC-06 | SYS-F06-R07 | a DELETE of FIRST_STAGE and of COMPLETE each with an expected lifecycle and a reason | the Void and Reversal event, the soft-delete, the link release and the same intent read-back, and no change on a lifecycle mismatch | NOT_RUN |
| SCL-TC-07 | SYS-F06-R08 | active Transload, finalized Lot/Ledger, Delivery-linked Equipment each present, then reversal | SCALE_REVERSAL_BLOCKED, Ticket·links·consumer ledger no change |
NOT_RUN |
| SCL-TC-08 | SYS-F06-R02,R05 | a VALID Ticket is selected as Receipt evidence, and an invalid or missing Ticket is also tried | only the shared-lock valid evidence runs the Inventory owner; the Ticket itself and the other consumers are unchanged | NOT_RUN |
| SCL-TC-09 | SYS-F06-R06,R09 | a correction list and read-back in an environment where the event schema is and is not applied | in AVAILABLE the count, latest and before and after, and when it is not applied it is SCHEMA_NOT_APPLIED; a false zero is forbidden |
NOT_RUN |
| SCL-TC-10 | SYS-F06-R01,R10 | a C1 and C2 role and capability, a device and manual, the no-scale policy, and a preview | only the applicable command is exposed and allowed, and the provenance is preserved; an unapproved combination is BLOCKED or NOT_APPLICABLE | NOT_RUN |
A focused check such as the current scripts/tests/contract/phase2a-scale-evidence.test.ts is the scope of the evidence calculation and the simulated lock and callback. A PASS of the cases above requires a real role screen, a before and after read-back of an approved MySQL fixture, the device and manual provenance, the output, and the downstream no change evidence.
3.5 TST-07 Inventory Detail Test¶
| TC ID | Linked requirement | Execution | Expected result | Current result |
|---|---|---|---|---|
| INV-TC-01 | SYS-F07-R05 | a Receipt with a normal and an error of the source and item, remaining, policy, Scale and no-scale, and location | when valid the Lot and Ledger, and on an error no change and an exact blocker | NOT_RUN |
| INV-TC-02 | SYS-F07-R06 | a Placement failure after the Receipt commit, and a retry of the same or a different location | the same Lot identity and 0 additional ledger, and only the Placement is the authoritative result | NOT_RUN |
| INV-TC-03 | SYS-F07-R07 | a query of a partial, hold and closed Lot with a quantity and weight mismatch | the two remaining quantities and the status, source and ownership are shown independently, with no arbitrary conversion | NOT_RUN |
| INV-TC-04 | SYS-F07-R08 | a partial and full allocation, an overdraw and a concurrent apply | the target item and relation, the net balance and the ledger are exact, and the overdraw rolls back | NOT_RUN |
| INV-TC-05 | SYS-F07-R08,R09 | an exact target, relation and Lot read-back after a lost Apply response | if it exists there is no replay, and if it does not only the missing command is resumed with the original identity | NOT_RUN |
| INV-TC-06 | SYS-F07-R09 | a partial and a final Reverse, and the follow-up FULL and EMPTY Container and delivery state | when allowed the Lot, target and container are re-aggregated, and when in progress a conflict and no change at all | NOT_RUN |
| INV-TC-07 | SYS-F07-R09 | a Receipt correction and reversal, and the active allocation, placement and Scale lineage | only the allowed owner changes, the ledger and the provenance are preserved, and there is no automatic downstream cancellation | NOT_RUN |
| INV-TC-08 | SYS-F07-R06,R09 | a direct Container loading success, a failure before the commit, and a lost response | the Container, time and UUID are preserved, the same request recovers, and there is no duplicate allocation | NOT_RUN |
| INV-TC-09 | SYS-F07-R04,R10 | a full allocation → Closed → re-entry into the detail → Reverse → Available | the same Lot is recovered and re-read in the real role UI and DB; an unimplemented path is FAIL or NOT_RUN | NOT_RUN |
| INV-TC-10 | SYS-F07-R10 | C1 custody and C2 owned stock, the cost applicability, and the document and billing after a reversal | the ownership, custody, source and cost are separated, and the result is per Packing, Invoice, Billing and Settlement owner | NOT_RUN |
The existing RCP and the simulated writer and UI checks are reused, but a PASS is not promoted unless the revision, role and fixture are the same as the real full C2 flow.
4. Individual Test Case Format¶
It records the case ID, the requirement ID, the purpose, the Client, role and environment, the prior data and state, the execution procedure and input, the expected screen, API, DB and follow-up result, the real result, the basis revision and execution time, the evidence location, and the data cleanup and residue. A save, provider or operational data test is run only when a real approval and preparation matching that effect exist.
5. Preservation Of Existing Results And Non-Execution¶
The real result is distinguished as PASS / FAIL / BLOCKED / NOT_RUN / NOT_APPLICABLE. A past result is is valid only in the scope of its original source, environment, role and data. The existing Booking acceptance recordand the Receipt record are preserved as a partial basis and are not merged into a full PASS of the new system specification.
6. Acceptance Verdict And Traceability¶
The expected and the real result of the required requirements, exceptions and follow-up impacts per area are linked in RTM. When a defect is found it is linked to the relevant implementation owner, but this document authoring work is not automatically turned into a feature fix project. The unwritten items of the document structure and a real product defect or a test non-execution are reported separately.
6.1 Verdict Of The Current Whole Documentation Work¶
The table below is the verdict record of the existing documentation work. A later link and path cleanup does not update this result or the verdict of the environment at the time. The current execution state is checked in the relevant Task and the original evidence.
| Scope | Result | The basis and the limit |
|---|---|---|
| the 9 specification structure and area sections | PASS | a source Markdown, metadata and basic 9 generation and reader check; it is not a completed area detail |
| the existing Booking and Receipt detail preservation | PASS | the existing document ID, legacy chapter and links are confirmed in a generation check; it is not a real re-execution of the feature |
| the whole area source mapping | PASS | the current source-reconciled and candidate state is reflected in each section; it does not mean an undetermined policy or the physical schema is complete |
| the real acceptance of every area | NOT_RUN | this request is document authoring and does not run a DB fixture, a work mutation, a provider or Production |
| the real new 9 Wiki screens | BLOCKED | a delay or a timeout of the local existing Wiki response; it is not replaced by a document generation PASS |
7. Test Case, Execution And Evidence Card¶
| Field | Authoring criteria |
|---|---|
| TC ID, revision and traceability | REQ, AC, BR, UI, DATA, IF and SEQ, and the applied context |
| Purpose and priority | the risk, and the normal, boundary, error, authority, concurrency and recovery type |
| Environment, account and data | the revision, the runtime, the role and tenant, and the fixture source, isolation and cleanup |
| Procedure and input | the reproducible steps and the mutation and external effect scope |
| Expected result | the screen, API, DB and follow-up effect, the no change, and the quantitative tolerance |
| Real result | the executor and the time, the observed value, and PASS, FAIL, BLOCKED or NOT_RUN |
| Evidence | the EVD ID, the location and hash, the protection and preservation, and the defect and re-execution link |
8. Close, Release Verdict And Change Review¶
A required combination, a non-execution, a defect, a waiver and a remaining risk are not hidden from the denominator. A GO, CONDITIONAL GO or NO-GO records the baseline, the verdict scope, the approver and the validity period. A changed requirement, design, interface, schema or screen re-reviews the affected test case and the validity of the previous RUN.¶
Source:
new-system/docs/specifications/TESTS.md— ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged. A user instruction quoted inside the text is kept in its original language.