docs(sdlc): finalize ISO 29110 evidence package

2026-08-26 12:35:57 +07:00
parent c7821b9d2d
commit 45b2415beb
53 changed files with 195 additions and 27 deletions
@@ -15,7 +15,7 @@

 ## 1. Objective and status disclosure

-Define the Test Cases used to verify and validate system behavior against Customer Requirements and the SRS. This document specifies the cases and records their execution. All 34 cases were executed and passed over the test window 10/08/26–14/08/26 by Parin Ngamkham (QA/Tester) on the internal testing server, confirmed by the project user on 17/08/26. Per-case execution dates within that window were not separately recorded.
+Define the Test Cases used to verify and validate system behavior against Customer Requirements and the SRS. This document specifies the cases and records their execution. All 34 cases were executed and passed over the test window 10/08/26–14/08/26 by Parin Ngamkham (QA/Tester) on the internal testing server, confirmed by the project user on 17/08/26. Per-case execution dates, exact deployed commit identifiers, and detailed actual-result observations within that window were not separately retained.

 BRN WMS has an assigned QA/Tester (Parin Ngamkham), independent of the Developer (Thanakorn Sathitwitayakul) who implemented the system. Test execution and results in the Test Report are attributed to this independent role, not to self-testing by the developer.

@@ -28,6 +28,16 @@ Two environments are used, and the distinction matters for how the results shoul

 Because functional and non-functional test execution runs on the internal testing server, destructive and high-risk cases — for example the TC-NFR-003 failure/rollback simulation — could be exercised without risk to customer data.

+### 1.1 Execution baseline and retained evidence
+
+| Field | Record |
+|---|---|
+| Tested environment | Internal testing server used by the supplier-side QA/Tester during 10/08/26–14/08/26; the exact host identifier was not separately retained. |
+| Closest retained repository state at the end of the test window | Git commit `dd48a8b` — Demo Data Population, committed 14/08/26. This identifies the closest retained repository state by date; it is not asserted as the exact deployed commit for every test case. |
+| Delivered software baseline | Git commit `6c39700`, committed 17/08/26. This is the delivered baseline, not the exact tested build; it includes post-test-window delivery, branding, and deployment-preparation changes. |
+| Per-case evidence retained | Test specification, expected result, pass status, test window, responsible tester, environment needs, and requirement traceability in this document and work products 13 and 16. |
+| Evidence limitation | Per-case timestamps, transaction/data identifiers, screenshots, logs, and detailed observed-result notes were not separately retained. No such details should be reconstructed or backdated. |
+
 ## 2. Test case specification

 | No. | Test Case ID | Test Item | Input Specification | Output Specification | Environment Needs | Special Procedural Required | Intercase Dependency | Status | Test Date |
@@ -67,7 +77,11 @@ Because functional and non-functional test execution runs on the internal testin
 | 33 | TC-NFR-009 | Traceability completeness | Review the Traceability Record for gaps on any Must requirement | No unexplained gap found | Traceability Record (work product 13) | — | — | Passed | 10/08/26–14/08/26 |
 | 34 | TC-NFR-010 | Time-zone consistency | Compare stored/displayed operational times and scheduled-job execution time against Asia/Bangkok | Times and execution follow the configured time zone | Web browser, Node.js scheduler logs | — | Requires TC-FR-022 | Passed | 10/08/26–14/08/26 |

-## 3. Approval
+## 3. QA execution declaration
+
+By signing the Prepared by block below, the QA/Tester confirms that they executed all 34 test cases on the internal testing server during 10/08/26–14/08/26, compared the observed behavior with each specified output, recorded all 34 cases as passed, and reported no unresolved test anomaly. The declaration applies to the application state used during that test window and does not represent Git commit `6c39700` as the exact tested build.
+
+## 4. Approval

 ### Prepared by

@@ -17,7 +17,7 @@

 Confirm that BRN WMS covers the Customer Requirements and SRS through executed testing, per the Test Cases and Test Procedures (work product 15) and the project schedule. All 34 defined test cases were executed over the test window 10/08/26–14/08/26 and passed, with no open test defect reported.

-Execution was performed by Parin Ngamkham (QA/Tester), independent of the Developer, on the internal testing server. Per-case execution dates within the window were not separately recorded. Customer-side acceptance testing on the production environment is recorded separately as the Validation Result (work product 22).
+Execution was performed by Parin Ngamkham (QA/Tester), independent of the Developer, on the internal testing server. Per-case execution dates, exact deployed commit identifiers, and detailed actual-result observations within the window were not separately retained. Customer-side acceptance testing on the production environment is recorded separately as the Validation Result (work product 22).

 ## 2. Scope (as planned in Test Cases and Test Procedures)

@@ -27,6 +27,8 @@ Execution was performed by Parin Ngamkham (QA/Tester), independent of the Develo
 | 2 | Non-functional test | 10 non-functional requirements (NFR-001–NFR-010), test cases TC-NFR-001–TC-NFR-010 |
 | 3 | Environment | Internal testing server (supplier side). Customer production UAT is recorded separately in work product 22. |
 | 4 | Period | Test window 10/08/26–14/08/26; completion confirmed by the project user 17/08/26. Per-case execution dates within the window not separately recorded. |
+| 5 | Closest retained repository state | Git commit `dd48a8b` dated 14/08/26. It is the closest retained state by date, not a claim that every case used that exact commit. |
+| 6 | Delivered software baseline | Git commit `6c39700` dated 17/08/26. It post-dates the test window and is not represented as the exact tested build. |

 ## 3. Execution summary

@@ -78,15 +80,25 @@ Execution was performed by Parin Ngamkham (QA/Tester), independent of the Develo
 | 33 | TC-NFR-009 | NFR-009 | Traceability completeness | Passed | 10/08/26–14/08/26 |
 | 34 | TC-NFR-010 | NFR-010 | Time-zone consistency | Passed | 10/08/26–14/08/26 |

-## 5. Related indirect evidence
+## 5. Evidence basis and limitation
+
+The retained per-case record consists of the test specification and expected result in work product 15, the pass result and test window in this report, the named responsible QA/Tester, and the requirement links in the Traceability Record. Per-case timestamps, transaction/data identifiers, screenshots, logs, and detailed actual-result notes were not separately retained. The test results must therefore be read as a signed manual execution record, not as a claim that those additional artefacts exist.
+
+The closest retained repository state at the end of the test window is `dd48a8b` (14/08/26). The delivered baseline `6c39700` was committed on 17/08/26 after the recorded test window and includes delivery, branding, and deployment-preparation changes. This report does not claim that a complete 34-case regression run was performed against `6c39700`.
+
+## 6. Related indirect evidence

 The Correction Register records 28 defect corrections found and fixed during development.

-## 6. Recommendation
+## 7. QA execution declaration
+
+By signing the Prepared by block below, the QA/Tester confirms that they executed all 34 test cases on the internal testing server during 10/08/26–14/08/26, compared the observed behavior with each specified output, recorded all 34 cases as passed, and reported no unresolved test anomaly. The declaration applies to the application state used during that test window and does not represent Git commit `6c39700` as the exact tested build.
+
+## 8. Recommendation

 Future regression testing should record per-case execution dates and detailed observations at the time of execution, alongside the tester and environment already identified here.

-## 7. Approval
+## 9. Approval

 ### Prepared by

@@ -9,20 +9,21 @@
 | Project period | 05/01/26–24/08/26 |
 | Release | 17/08/26 V1.0 |
 | Standard | ISO/IEC 29110 Basic Profile |
-| Review round | Round 2 completed 17/08/26 — independent verification performed by Yaowalak Bangchomphoo, Document Control |
+| Review round | Round 2 completed 17/08/26 — Round 2A document-control verification and Round 2B technical work-product verification |
 | Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
-| Round 2 verifier | Yaowalak Bangchomphoo — Document Control, independent of the document preparer |
-| Status | Final — Round 2 independent verification complete |
+| Round 2A verifier | Yaowalak Bangchomphoo — Document Control, independent of the document preparer |
+| Round 2B technical reviewers | Noppong Chareunsook — System Analyst; Parin Ngamkham — QA / Tester; Apirach Supattaratpateep — Project Manager |
+| Status | Final — Round 2 document-control and technical verification complete |

 ## Objective

-Confirm the correctness and completeness of the SDLC work products delivered so far, against ISO/IEC 29110 Basic Profile document-control expectations, before they are treated as ready for Project Sponsor review.
+Confirm the correctness and completeness of the SDLC work products against ISO/IEC 29110 Basic Profile document-control and technical work-product expectations before they are treated as ready for Project Sponsor review and authorization.

 ## 1. Deliverables under review

 PM work products 1–10 and SI work products 11–20 (this and work product 22 are excluded, being the verification/validation records themselves).

-## 2. Verification items
+## 2. Round 2A — Document-control verification

 Each row checks the document-control header, content, project coverage, and approval block.

@@ -49,27 +50,62 @@ Each row checks the document-control header, content, project coverage, and appr
 | VR-19 | Product Operation Guide | Yes | Yes | Yes | Yes | Passed |
 | VR-20 | Maintenance Documentation | Yes | Yes | Yes | Yes | Passed |

-## 3. Risk and constraint note
+## 3. Round 2B — Technical work-product verification

-1. Round 1 was a self-review by the document preparer (the Developer). Round 2 was performed on 17/08/26 by Yaowalak Bangchomphoo, Document Control, who is independent of the Developer and whose assigned role covers identifiers, versions, approvals, distribution, repository content, and evidence — the same attributes the verification items in Section 2 check. Per-item reviewer notes were not retained beyond the pass/fail results recorded above.
-2. Test execution, verification, and validation facilitation (work products 15, 16, 22) are now assigned to Parin Ngamkham, QA / Tester, independent of the Developer who prepared this record. This mitigates the self-testing concern for those three work products specifically. Round 1 of this record and of work products 1–14 and 17–21 was a self-review by the Developer who authored them; that self-review was superseded by the Round 2 independent verification performed by Document Control on 17/08/26.
+| ID | Verification performed | Responsible reviewer | Result |
+|---|---|---|---|
+| TV-01 | Customer Requirements are complete, internally consistent, feasible within the agreed project scope, and expressed in a testable form. | Noppong Chareunsook — System Analyst | Passed |
+| TV-02 | All 34 Customer Requirements resolve to valid SRS and Software Design references in the Traceability Record. | Noppong Chareunsook — System Analyst | Passed |
+| TV-03 | Referenced software components and design units exist in delivered baseline `6c39700` and agree with the controlled Software Design and Software Components records. | Noppong Chareunsook — System Analyst; Parin Ngamkham — QA / Tester | Passed |
+| TV-04 | All 34 test cases map to controlled requirements and contain defined inputs and expected results. | Parin Ngamkham — QA / Tester | Passed |
+| TV-05 | Test totals reconcile across work products 13, 15, and 16: 34 defined, 34 executed, 34 passed, and no unresolved test anomaly reported. | Parin Ngamkham — QA / Tester | Passed |
+| TV-06 | All 28 Correction Register entries resolve to valid implementation commits and applicable verification test-case references. | Parin Ngamkham — QA / Tester; Apirach Supattaratpateep — Project Manager | Passed |
+| TV-07 | Traceability is complete from each approved requirement through SRS, design, test case, and recorded result; the stated coverage totals reconcile. | Noppong Chareunsook — System Analyst; Parin Ngamkham — QA / Tester | Passed |
+| TV-08 | Software User Documentation, Product Operation Guide, and Maintenance Documentation agree with the delivered software scope, architecture, and controlled deployment approach. | Apirach Supattaratpateep — Project Manager; Noppong Chareunsook — System Analyst | Passed |
+| TV-09 | No unresolved technical verification finding prevents the recorded acceptance decision. | Apirach Supattaratpateep — Project Manager | Passed |
+
+## 4. Risk and constraint note
+
+1. Round 1 was a self-review by the document preparer (the Developer). Round 2A was performed on 17/08/26 by Yaowalak Bangchomphoo, Document Control, who is independent of the Developer and whose assigned role covers identifiers, versions, approvals, distribution, repository content, and evidence — the attributes checked in Section 2.
+2. Round 2B technical verification was performed by the assigned System Analyst, QA/Tester, and Project Manager. Noppong Chareunsook reviewed requirements, design, components, traceability, and technical documentation; Parin Ngamkham reviewed tests, correction references, components, and traceability; Apirach Supattaratpateep reviewed correction disposition, documentation agreement, and overall technical disposition.
 3. All 34 functional/non-functional test cases and all 12 UAT/validation scenarios were executed over 10/08/26–14/08/26 and passed.
-4. Future reviews should retain per-item reviewer notes alongside the pass/fail result, so the basis of each verification decision is auditable and not only its outcome.
+4. The test and validation baseline/evidence limitations are disclosed in work products 15, 16, and 22. Round 2B verifies the controlled records and their internal consistency; it does not create per-case observations or represent delivered baseline `6c39700` as the exact tested or validated build.
+5. Per-item reviewer notes were not retained beyond the pass/fail results recorded above. Future reviews should retain those notes alongside each result so the basis of each verification decision is auditable and not only its outcome.

-## 4. Recommendation
+## 5. Recommendation

 Retain per-item reviewer notes alongside the recorded results in future projects to strengthen the audit trail.

-## 5. Approval
+## 6. Reviewer declarations

-### Prepared by (Round 2 independent verification)
+By signing the applicable blocks below, the assigned reviewers confirm that they performed the Round 2 checks attributed to their roles, found the referenced work products consistent with the controlled project evidence, recorded the listed checks as Passed, and identified no unresolved verification finding affecting acceptance.
+
+The Document Control signature confirms Round 2A. The System Analyst, QA/Tester, and Project Manager signatures confirm their respective Round 2B technical checks. The Project Sponsor signature authorizes the recorded verification disposition.
+
+## 7. Approval
+
+### Round 2A verified by

 Name: Yaowalak Bangchomphoo  
 Role: Document Control
 Signature: ______________________________________________  
 Date: ___________________________________________________

-### Reviewed by
+### Round 2B requirements, design, components, traceability, and technical documentation verified by
+
+Name: Noppong Chareunsook  
+Role: System Analyst / Technical Reviewer  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Round 2B tests, corrections, components, and traceability verified by
+
+Name: Parin Ngamkham  
+Role: QA / Tester  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Round 2B reviewed and dispositioned by

 Name: Apirach Supattaratpateep  
 Role: Project Manager  
@@ -19,10 +19,20 @@ Confirm with the Project Sponsor, acting as Customer Representative, that the de

 ## 1. Disclosure

-All 12 defined validation scenarios were executed and passed over the validation window 10/08/26–14/08/26 by Seri Viriyasakultorn, acting as Customer Representative, on the customer production environment, and confirmed by the project user on 17/08/26. Per-scenario execution dates within that window were not separately recorded.
+All 12 defined validation scenarios were executed and passed over the validation window 10/08/26–14/08/26 by Seri Viriyasakultorn, acting as Customer Representative, on the customer production environment, and confirmed by the project user on 17/08/26. Per-scenario execution dates, exact deployed commit identifiers, transaction/data identifiers, and detailed actual-result observations within that window were not separately retained.

 This is user acceptance testing on the customer's own production environment, and is distinct from the supplier-side test execution recorded in work products 15 and 16, which ran on the internal testing server under the QA/Tester. Formal acceptance is recorded by the authorized Accepted decision in the Acceptance Report.

+### 1.1 Validation baseline and retained evidence
+
+| Field | Record |
+|---|---|
+| Validation environment | Customer production environment used by the Customer Representative during 10/08/26–14/08/26; the exact host identifier was not separately retained. |
+| Closest retained repository state at the end of the validation window | Git commit `dd48a8b` — Demo Data Population, committed 14/08/26. This identifies the closest retained repository state by date; it is not asserted as the exact deployed commit for every validation scenario. |
+| Delivered software baseline | Git commit `6c39700`, committed 17/08/26. This is the delivered baseline, not the exact validated build; it includes post-validation-window delivery, branding, and deployment-preparation changes. |
+| Per-scenario evidence retained | Scenario, related requirement and test-case identifiers, expected outcome, pass status, responsible Customer Representative, validation window, and the signed confirmation in this document. |
+| Evidence limitation | Per-scenario timestamps, transaction/data identifiers, screenshots, logs, and detailed observed-result notes were not separately retained. No such details should be reconstructed or backdated. |
+
 ## 2. Validation scenarios

 | No. | Scenario | Related Test Case(s) | Related Req ID(s) | Expected outcome | Status | Tester |
@@ -48,11 +58,15 @@ This is user acceptance testing on the customer's own production environment, an
 | Scenarios executed and validated | 12 — executed 10/08/26–14/08/26 by the Customer Representative |
 | Scenarios pending | 0 |

-## 4. Recommendation
+## 4. Customer validation declaration
+
+By signing the Reviewed and confirmed by block below, the Customer Representative confirms that they performed all 12 validation scenarios on the customer production environment during 10/08/26–14/08/26, compared the observed behavior with each expected outcome, recorded all 12 scenarios as passed, and reported no unresolved acceptance anomaly. The declaration applies to the application state used during that validation window and does not represent Git commit `6c39700` as the exact validated build.
+
+## 5. Recommendation

 Formal acceptance was completed through the authorized Accepted decision in the Acceptance Report. Future validation should record per-scenario execution dates and observations at the time of execution.

-## 5. Approval
+## 6. Approval

 ### Prepared by