4. Deliver: Testing: 2. Preparing for Testing: A Guide to Success

Testing (often called User Acceptance Testing or UAT) is the bridge between development and launch. It is the phase where the project transforms from a concept into a working business tool.

While critical, testing is historically the highest point of friction in a project’s lifecycle. By design, the process is negative: it requires your team to actively hunt for flaws, issues, and breaks.

Without careful preparation, this "fault-finding" mindset can lower morale, blur the lines of scope, and delay the launch.

To ensure a smooth delivery, it is essential to move the team’s mindset from "criticising" to "verifying." The following guide outlines common friction points and actionable steps to mitigate them.

Potential Points of Friction

Understanding exactly where testing phases typically stall is the first step to preventing delays. The following table outlines the most common friction points teams face, paired with specific, actionable resolutions.

To remove this friction and ensure your project stays on the agreed timeline, we recommend implementing these measures prior to the start of testing.

Potential Points of Friction	Recommendations for Success
Confusion: Bugs vs. Preferences Testers often flag approved designs as bugs because they dislike the UX or were not involved in approvals. This floods the log with "wishlist" items and disagreements, obscuring actual defects.	Set the "Rules of Engagement" Define exactly what a "Bug" is (broken logic/deviation from spec). Establish a separate "Post-Launch Wishlist" for subjective feedback. Have a client triage owner to decline requests to reduce time
The "Why wasn't this caught?" Frustration Testers can feel frustrated finding issues, believing internal QA should have caught them. This creates a negative atmosphere where testing feels like "raising problems" rather than verifying solutions.	Clarify the Purpose of UAT Position this phase explicitly as the final verification layer to catch edge cases. Remind the team that finding bugs is a success, not a failure of the process.
Process & Knowledge Gaps First-time users struggle to distinguish between "I don't know how to use this" and "This is broken." Apps often require specific steps; diverging from them makes the system appear broken.	The "Pre-Flight" Walkthrough Conduct a mandatory demo 24 hours before testing. Show the "happy path" so testers understand the intended functionality. Provide "Balanced Scenarios" that guide testers without being so rigid that they miss edge cases.
Unclear or Duplicate Reporting Multiple testers reporting the same issue, or logging vague tickets (e.g., "It doesn't work") without steps to reproduce, causing triage paralysis and eating into resolution time.	Appoint a "Triage Gatekeeper" Designate one internal lead to review all feedback before it goes to developers. Use visual tools like Marker.io to automatically capture technical data (browser, OS, console errors).
Environmental & Data Blockers Testing on unsupported browsers (e.g., IE), slow connections, or lacking standard peripherals (mouse/screens). Confusion caused by placeholder data or polluting Production reporting with test data.	Standardise & Document Explicitly list supported browsers and required hardware (e.g., dual screens). Provide a "Data Cheat Sheet" and strict naming rules (e.g., "Use 'TEST' in surname") to protect Production data.
Access & Permissions Testers attempting to verify end-to-end processes without the correct user profile permissions (e.g., trying to approve a purchase as a standard user).	Profile Preparation Ensure specific test accounts are created and verified prior to Day 1. Do not ask testers to use their own live logins if those logins do not have the required permissions.

Potential Points of Friction

Recommendations for Success

Confusion: Bugs vs. Preferences

Testers often flag approved designs as bugs because they dislike the UX or were not involved in approvals. This floods the log with "wishlist" items and disagreements, obscuring actual defects.

Set the "Rules of Engagement"

Define exactly what a "Bug" is (broken logic/deviation from spec). Establish a separate "Post-Launch Wishlist" for subjective feedback.
Have a client triage owner to decline requests to reduce time

The "Why wasn't this caught?" Frustration

Testers can feel frustrated finding issues, believing internal QA should have caught them.
This creates a negative atmosphere where testing feels like "raising problems" rather than verifying solutions.

Clarify the Purpose of UAT

Position this phase explicitly as the final verification layer to catch edge cases.
Remind the team that finding bugs is a success, not a failure of the process.

Process & Knowledge Gaps

First-time users struggle to distinguish between "I don't know how to use this" and "This is broken." Apps often require specific steps; diverging from them makes the system appear broken.

The "Pre-Flight" Walkthrough

Conduct a mandatory demo 24 hours before testing. Show the "happy path" so testers understand the intended functionality. Provide "Balanced Scenarios" that guide testers without being so rigid that they miss edge cases.

Unclear or Duplicate Reporting

Multiple testers reporting the same issue, or logging vague tickets (e.g., "It doesn't work") without steps to reproduce, causing triage paralysis and eating into resolution time.

Appoint a "Triage Gatekeeper"

Designate one internal lead to review all feedback before it goes to developers.
Use visual tools like Marker.io to automatically capture technical data (browser, OS, console errors).

Environmental & Data Blockers

Testing on unsupported browsers (e.g., IE), slow connections, or lacking standard peripherals (mouse/screens).
Confusion caused by placeholder data or polluting Production reporting with test data.

Standardise & Document

Explicitly list supported browsers and required hardware (e.g., dual screens).
Provide a "Data Cheat Sheet" and strict naming rules (e.g., "Use 'TEST' in surname") to protect Production data.

Access & Permissions

Testers attempting to verify end-to-end processes without the correct user profile permissions (e.g., trying to approve a purchase as a standard user).

Profile Preparation

Ensure specific test accounts are created and verified prior to Day 1.
Do not ask testers to use their own live logins if those logins do not have the required permissions.

Recommended Action Plan

Timeframe	Action Item	Details & Owner
3 Weeks Prior	Confirm Scope & Team	Lock the scope (no new features). Select the testing team (aim for a mix of tech-savvy and standard users).
2 Weeks Prior	Environment & Tooling Setup	Generate test data (e.g., create dummy accounts with specific attributes). Verify all test user permissions are active.
1 Week Prior	The "Rules of Engagement" Comms	Send the "UAT Kick-off" email. Share the "Data Cheat Sheet" (Logins, URLs, supported browsers). Explicitly explain the difference between a Bug and a Wishlist item.
2 Days Prior	Pre-Flight Walkthrough	Host a 30-minute demo showing how to set expectations around testing, execute testing, explain priority levels, explain how to raise a quality feedback item and walkthrough the intended workflows. Answer functional questions so testing time isn't spent on training.
Day 0 (Start)	Live "Drop-in" Workshop	Host the first 2 hours of testing as a live session (online or in-person). Have a delivery expert present to instantly unblock users and clarify issues in real-time.
During Testing	Daily Triage & Freeze	The Triage Gatekeeper reviews logs daily at 9:00 AM. Strict Code Freeze: Do not deploy new features during this window; only fix critical bugs. Owner: Project Lead