docs(sdlc): record real test results, open defects ISS-029–032, conditional acceptance

sdlc/ISO29110-audit-prep.md

@@ -11,9 +11,9 @@
 | How did you track progress, and what did you do when something slipped? | Progress Status Records (15 periods), Minutes of Meeting |
 | What risks did you identify, and were they reviewed? | Software Project Plan §9 (R1–R8); expect "show me a risk that changed during the project" |
 | How were changes requested, assessed and approved? | Change Report |
-| How were defects recorded and closed? | Correction Register ISS-001–028, each linked to a commit and a test case |
+| How were defects recorded and closed? | Correction Register: ISS-001–028 fixed, each linked to a commit and a test case; ISS-029–032 open from the system test, handed to corrective maintenance |
 | How is the repository controlled and backed up? | Project Repository, Project Repository (Backup), Software Configuration (`main`, baseline `6c39700`) |
-| Did the customer formally accept the product? | Acceptance Report, Validation Results |
+| Did the customer formally accept the product? | Acceptance Report (Accepted with conditions), Validation Results, Minutes of Meeting 24 Aug |
 
 ### Software Implementation (SI)
 
@@ -23,7 +23,7 @@
 | Pick one requirement and show its design, code, test and result | Traceability Record — most common test; rehearse 2–3 requirements end to end |
 | Show the design and how it maps to the code | Software Design (units UN01–UN13 with file paths) |
 | Who reviewed which documents, what was found, and how was it fixed? | Verification Results V0.1–V1.0 (4 rounds) |
-| Show the test cases and test results, including a failure and its retest | Test Case and Test Procedures (45), Test Report, Correction Register |
+| Show the test cases and test results, including a failure and its retest | Test Case and Test Procedures (45), Test Report (38 passed, 5 failed, 2 not tested), Correction Register |
 | What exactly was delivered, and can you rebuild it? | Software, Software Components, Product Operation Guide |
 | Are user, operation and maintenance documents available? | Software User Document, Product Operation Guide, Maintenance Document |
 
@@ -32,6 +32,7 @@
 | Point | What to show | What to say |
 |---|---|---|
 | No change requests in 8 months | Change Report parts 1–3; Minutes of Meeting 18 May (Rack → Bin), 10 Aug (Task 4.7 decided) and 19 Aug / 24 Aug (Task 4.7 done) | "Change control was used: 3 items were judged against the criteria and none qualified." Rehearse the advisor's test: "if we removed it, could we still deliver?" |
-| All 45 test cases passed in one run | Correction Register: 28 issues found and fixed during development, each linked to a commit and a test case; Test Case and Test Procedures pass rule: defects logged and retested until they pass | "The formal run came after the defects were fixed, so a clean run is the result of that work." If git history has real failing test runs, have one ready |
+| Open defects at acceptance | Test Report: TC-UN04.006, TC-UN08.002, TC-UN11.001, TC-UN12.001, TC-UN12.004 failed, TC-UN13.002–003 not tested; Correction Register ISS-029–032; Acceptance Report conditions; Minutes 24 Aug actions | "The run found four high-severity defects. We recorded them, told the sponsor, and acceptance was conditional on fixing them under corrective maintenance." Be ready to show the fix plan and its status. Do not claim they were fixed before 24 Aug |
+| UAT ran alongside the system test | Validation Results (test order row); Minutes of Meeting 10 Aug | "The entry criterion said UAT after 100% pass. The sponsor approved running both in 10–14 Aug at the 10 Aug meeting, and the deviation is recorded in Validation Results." |
 | Risks never re-rated | Software Project Plan R1–R8; risk table in every Progress Status Record | Pick 1–2 risks that actually occurred (R1 → Rack/Bin decision; R7 → evidence prepared before UAT) and show where they were handled. Do not change ratings in the records now |
-| Interviews must match the documents | One rehearsal session with the three people | Developer: how a defect is logged (ISS-002 → commit `92d116f` → TC-UN08.002). QA: run TC-UN08.002 (rollback test). PM: trace CR13:001 → SR09:003 → UN08.002 → TC-UN08.002 → Passed in Test Report and Validation Results |
+| Interviews must match the documents | One rehearsal session with the three people | Developer: a fixed defect (ISS-002 → commit `92d116f` → TC-UN04.002) and an open one (ISS-030 → TC-UN08.002, GL posting outside the document transaction). QA: run TC-UN04.002 and show the TC-UN08.002 failure. PM: trace CR13:001 → SR09:003 → UN08.002 → TC-UN08.002 → Failed → ISS-030 → acceptance condition |