PMO-06.10 Phase 06: Monitoring and Controlling

User Acceptance Testing Signoff

نموذج اعتماد اختبار قبول المستخدم

tasleemat asset PMO-06.10 template --lang en

Deliverable Summary & Governance Boundaries

Lifecycle Phase Alignment

Phase 06: Monitoring and Controlling

Sizing Tier Requirements

Validation Contract

This deliverable conforms to a strict companion Draft 2020-12 JSON Schema for automated structural and semantic validation.

tasleemat validate PMO-06.10 ./completed_data.json

Template Markdown (Bilingual)

<!-- LLM INSTRUCTIONS: Fill in the [ Add details... ] placeholders based on project context.

Context and Definition:
A user acceptance testing signoff records a decision rather than a test
report. The testing was performed and written up elsewhere; what this
document holds is the business's agreement that the thing tested is the
thing they asked for.

It is the only artifact in this set that cannot be taken back quietly.
Development testing continues past a failure, and a failed unit test is
ordinary. Acceptance means the business has signed, and once that happens
the project moves to the next phase and the outstanding findings stop being
worked on.

The two sections that carry the form are the criteria and the known
defects. The criteria have to exist before the testing, or the result
describes an outcome rather than confirming a decision. The defects are
recorded rather than resolved because that is the deliberate trade: a
critical defect blocks acceptance, and a non-critical one is accepted
knowingly, by somebody who has the authority to accept it and who will
still be there after go-live.

It can receive information from:
*   The test plan and the test cases executed against it
*   The defect log, which is where anything found is already recorded
*   The requirements or acceptance criteria the build was measured against

It provides information to:
*   Product acceptance form, which records the same decision for the deliverable
*   Project closure or phase closure, which needs the acceptance date
*   Transition to operations checklist, which is gated on this signature

Tailoring Tips:
*   Agree the criteria before the testing starts. Criteria written afterwards
    describe what happened rather than deciding whether it was acceptable.
*   Record what was accepted, not only what passed. An empty defects section
    tells the reader the testing found nothing, and a reader who suspects that
    has no way to check it.
*   Say which build and which environment. A pass somewhere other than where
    the business will work is not a pass, and the signature does not carry that
    distinction.

Alignment:
The user acceptance testing signoff should be aligned and consistent with:
*   The test plan, because the signoff is against the cases the plan defines
*   Product acceptance form, which records the same decision at deliverable level
*   Transition to operations checklist, which cannot start until this is signed

Section Instructions:
*   Test Summary: what was tested, named specifically enough that the criteria
    below can be read against something.
*   Testing Environment: where the testing ran and against which build.
*   Pass/Fail Criteria: what was decided before the testing began.
*   Known Defects: what was found and accepted rather than fixed, with severity
    and who accepted it.
*   Business Owner Sign-off: the decision in the business's own terms, covering
    what is accepted, with what, and what happens if it does not work.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Project_Name}} - {{Project_ID}}</h2>
<h1 dir="ltr" align="center">USER ACCEPTANCE TESTING SIGNOFF</h1>

| **Date Prepared:** {{Current_Date}} | **Project Manager:** {{Project_Manager_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- | :--- |

---

## Acceptance Record

### Test Summary

[ Add details... ]

---

### Testing Environment

[ Add details... ]

---

### Pass/Fail Criteria

[ Add details... ]

---

### Known Defects

[ Add details... ]

---

### Business Owner Sign-off

[ Add details... ]

---

### Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Quality Assurance (QA) Manager** | {{QA_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
| **Product Owner** | {{Product_Owner_Name}} | _______________________ | [ .... - .... - .... ] |
| **Client Representative / Business Owner** | {{Client_Representative_Name}} | _______________________ | [ .... - .... - .... ] |
---

<div dir="ltr" align="right" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>Electronic Audit Trail: Hash SHA256: {{Audit_Trail_SHA256_Hash}}</span> <br>
  <strong>Template:</strong> USER ACCEPTANCE TESTING SIGNOFF | <strong>Ref:</strong> PMO-06.10 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

User Guide & Practitioner Instructions

Tasleemat Forms Guide

Project Artifact: User Acceptance Testing Signoff

Document Reference: PMO-06.10

This document provides a comprehensive, professional reference to understand the purpose and effective usage of the User Acceptance Testing Signoff in alignment with the Tasleemat framework.

1. What?

Five statements rather than a table, because their lengths are not comparable and a table would pretend they are: what was tested, where it was tested and against what was decided beforehand as the standard for passing, what was found and accepted rather than fixed, and the business's decision in its own terms.

2. Why?

Because acceptance is the point at which the work stops being the project's and becomes the business's. A test report can be reopened; a signature cannot be withdrawn by the team that asked for it. That is what makes the record worth keeping carefully, and it is also why the criteria and the defects matter more than they would in a test report: the criteria establish what was actually agreed, and the defects are what the business knew about when it agreed.

3. When?

Once per release or per acceptance milestone, after the testing has been executed and before the project moves to the next phase or to operations. Not drafted in advance and not revised afterwards: a signoff edited after a problem is found is a signoff that cannot be relied on, because the reader has no way to tell what was agreed from what was accepted later.

4. Who?

Signed by the business owner or client representative, who is the party accepting the risk and is the only one with the authority to accept it, with the quality manager accountable for the testing having been done against the plan and the project manager for the schedule consequence of the date. The client signature is the one that matters and the one most often missing, which is how a project reaches go-live with nobody having agreed to anything.

Tailoring Tips

Agree the criteria before the testing starts. Criteria written afterwards describe what happened rather than deciding whether it was acceptable, and a reader cannot tell the two apart.
Record what was accepted, not only what passed. An empty defects section asserts that the testing found nothing, which is almost never what happened, and a reader who suspects that has no way to check it.
Say which build and which environment. A pass somewhere other than where the business will work is not a pass, and the signature does not carry that distinction.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Approved Project Baselines (PMO-04.01.01)
- Work Performance Data & Logs (PMO-05.01 - 05.12)
Optional / Contextual:
- Risk Register (PMO-04.08.02)
- Vendor Agreements (PMO-04.09.04)

2. Downstream Dependents

Mandatory:
- Change Requests (PMO-05.03)
- Project / Phase Closeout (PMO-07.03)
- Lessons Learned Summary (PMO-07.01)
Optional / Contextual:
- Transition to Operations Checklist (PMO-07.04)
- Value Realization Register (PMO-01.03)

5. How?

To accurately complete the User Acceptance Testing Signoff, populate the following sections based on the project context (ensuring reference to parameters.md for the general project variables):

Test Summary: What was tested, stated so that a reader can tell whether this was the whole release or a slice of it, and so that the criteria below can be read against something. "The system" is not a test summary; "the three checkout flows plus the refund path" is.
Testing Environment: Where the testing took place and against what. The environment and the build are part of what was accepted: a pass on a developer's machine is not a pass on the environment the business will use, and a signature that does not record which one was tested cannot be relied on at go-live.
Pass/Fail Criteria: What was decided before the testing began, not what was concluded after it. The criteria are what make the result mean anything: "the system works" cannot fail, because every system works on the day it is demonstrated, and a criterion written afterwards describes the outcome.
Known Defects: What was found and accepted rather than fixed, with the severity and who agreed to carry it. This section is what makes the signature honest: an empty defects section says the testing found nothing, which is almost never what happened, and a reader who knows that stops trusting the signature. Anything still open at go-live is discovered by somebody with no authority left to stop it.
Business Owner Sign-off: The decision, stated in the business's own terms rather than as a signature alone. What is being accepted, what is being accepted with, and what happens if something turns out not to work. This is the line that is read later when the question is whether the business agreed to this.

Associated Templates

6. Reference Example

A fully completed, gold-standard reference example illustrating this artifact in practice is available:

📖 Completed Example: 06_10_User_Acceptance_Testing_Signoff_Example.md

LLM Generation Prompt & Agent Instructions

User Acceptance Testing Signoff - LLM Generation Prompt

SYSTEM INSTRUCTIONS: This document is the detailed instruction set for generating the User Acceptance Testing Signoff. When asked to populate the template, follow the guidance for each section below to produce the requested content. Refer to parameters.md for the general project variables.

Context and Definition: A record of a decision rather than a test report. The testing was performed and written up elsewhere; what this document holds is the business's agreement that the thing tested is the thing they asked for. It is the only artifact in this set that cannot be taken back quietly: development testing continues past a failure, and once the business has signed, the project moves on and the outstanding findings stop being worked on.

Alignment & Dependencies: * Pre-requisites (Inputs): * Mandatory: Approved Project Baselines (PMO-04.01.01), Work Performance Data & Logs (PMO-05.01 - 05.12) * Optional: Risk Register (PMO-04.08.02), Vendor Agreements (PMO-04.09.04) * Downstream Dependents: * Mandatory: Change Requests (PMO-05.03), Project / Phase Closeout (PMO-07.03), Lessons Learned Summary (PMO-07.01) * Optional: Transition to Operations Checklist (PMO-07.04), Value Realization Register (PMO-01.03)

Acceptance Record

Test Summary

Instructions: What was tested, stated so that a reader can tell whether this was the whole release or a slice of it, and so that the criteria below can be read against something. "The system" is not a test summary; "the three checkout flows plus the refund path" is.