QA & Compliance Training Guide » History » Version 1
Redmine Admin, 12/26/2025 11:37 AM
| 1 | 1 | Redmine Admin | h1. QA & Compliance Training Guide (Tinggit Platform) |
|---|---|---|---|
| 2 | |||
| 3 | *Audience:* QA, Security, Compliance |
||
| 4 | *Purpose:* Explain how quality, validation, and auditability are enforced using Redmine |
||
| 5 | |||
| 6 | {{toc}} |
||
| 7 | |||
| 8 | --- |
||
| 9 | |||
| 10 | h2. 1. Your Role in the Process |
||
| 11 | |||
| 12 | QA & Compliance owns: |
||
| 13 | |||
| 14 | * Definition of Done validation |
||
| 15 | * Test verification |
||
| 16 | * Audit readiness |
||
| 17 | * Release validation |
||
| 18 | |||
| 19 | You do NOT: |
||
| 20 | * Redefine scope |
||
| 21 | * Change sprint commitments |
||
| 22 | * Adjust metrics |
||
| 23 | |||
| 24 | --- |
||
| 25 | |||
| 26 | h2. 2. QA During the Sprint |
||
| 27 | |||
| 28 | QA activities include: |
||
| 29 | |||
| 30 | * Validating Acceptance Criteria |
||
| 31 | * Executing test cases |
||
| 32 | * Logging defects early |
||
| 33 | |||
| 34 | Sprint bugs: |
||
| 35 | * Must be fixed within the sprint |
||
| 36 | * Block story completion |
||
| 37 | |||
| 38 | --- |
||
| 39 | |||
| 40 | h2. 3. Definition of Done Enforcement |
||
| 41 | |||
| 42 | A story is DONE only if: |
||
| 43 | |||
| 44 | * All tests pass |
||
| 45 | * No open sprint bugs |
||
| 46 | * Acceptance Criteria met |
||
| 47 | * Evidence is available |
||
| 48 | |||
| 49 | Stories failing DoD must not be accepted. |
||
| 50 | |||
| 51 | --- |
||
| 52 | |||
| 53 | h2. 4. Sprint Close Validation |
||
| 54 | |||
| 55 | Before sprint close, QA must verify: |
||
| 56 | |||
| 57 | * Completed In Sprint is correctly set |
||
| 58 | * Spillover items are justified |
||
| 59 | * No hidden unfinished work exists |
||
| 60 | |||
| 61 | QA acts as a *quality gate*, not a bottleneck. |
||
| 62 | |||
| 63 | *Authoritative reference:* [[Sprint Close Process]] |
||
| 64 | |||
| 65 | --- |
||
| 66 | |||
| 67 | h2. 5. Release Validation |
||
| 68 | |||
| 69 | Before a release is closed: |
||
| 70 | |||
| 71 | * Verify all release issues are Done |
||
| 72 | * Confirm QA sign-off |
||
| 73 | * Ensure release notes are accurate |
||
| 74 | * Validate deployment references exist |
||
| 75 | |||
| 76 | *Authoritative reference:* [[Release Management Process]] |
||
| 77 | |||
| 78 | --- |
||
| 79 | |||
| 80 | h2. 6. Audit Execution |
||
| 81 | |||
| 82 | Audits rely on: |
||
| 83 | |||
| 84 | * Saved queries |
||
| 85 | * Sprint history fields |
||
| 86 | * Issue history |
||
| 87 | * Wiki documentation |
||
| 88 | |||
| 89 | Audits must be reproducible without explanation. |
||
| 90 | |||
| 91 | *Authoritative reference:* [[Sprint History, Metrics & Audit]] |
||
| 92 | |||
| 93 | --- |
||
| 94 | |||
| 95 | h2. 7. Compliance & Exceptions |
||
| 96 | |||
| 97 | For compliance-driven urgency: |
||
| 98 | |||
| 99 | * Ensure traceability |
||
| 100 | * Ensure documentation |
||
| 101 | * Preserve history |
||
| 102 | |||
| 103 | Emergency never means undocumented. |
||
| 104 | |||
| 105 | *Authoritative reference:* [[Edge Case & Exception Handling]] |
||
| 106 | |||
| 107 | --- |
||
| 108 | |||
| 109 | h2. 8. Common QA & Compliance Pitfalls |
||
| 110 | |||
| 111 | * Allowing “almost done” stories |
||
| 112 | * Skipping documentation |
||
| 113 | * Approving releases under pressure |
||
| 114 | * Fixing data instead of process |
||
| 115 | |||
| 116 | --- |
||
| 117 | |||
| 118 | h2. 9. Final Reminder |
||
| 119 | |||
| 120 | *bq.* Quality is enforced by discipline, not heroics. |
||
| 121 | |||
| 122 | If data cannot be audited later, it is not done. |