Do you know how to request a "Test Please"?

Last updated by Jean Thirion [SSW] 5 months ago.See history

Testing is a fundamental aspect of software development, serving as the quality assurance checkpoint that ensures a product functions as intended, meets user expectations, and operates reliably in various environments. This crucial phase helps identify and rectify issues, enhances user satisfaction, and ultimately safeguards a software's reputation and success.

✅ The ideal 'Test Please' workflow

When requesting a review or approval (commonly called a "Test Please") for a piece of work such as a video edit, blog post, or design preview, it's important to follow a consistent and transparent workflow:

  1. Post the preview link in the PBI – Add the link to the version or preview at the top of the relevant PBI (Product Backlog Item)
  2. Use the PBI discussion to tag reviewers – In the comments section, use @ to mention the team members you want to review the work, and write a clear message (e.g., “Test please 🙏”)
  3. Keep all feedback and iterations in the same thread – Reviewers should reply in the same PBI discussion with comments or with a confirmation like “Test passed ✅.” Any required changes or back-and-forth should also stay within that thread to keep the full history in one place
  4. Follow up professionally via Teams – If there's no response after a reasonable time, follow up with a “warn then call” (e.g., “Hi Adam, calling in 1 min about the preview link”), and reference the PBI so the full context is easy to access

This process ensures feedback is traceable, transparent, and tied to the work item.

'Test Please' via email

When there’s no project backlog in place, it’s acceptable to send a 'Test Please' request via email.

These are the steps you should take when requesting a "Test Please" via email:

  1. Find 2 free testers to send the email below
  2. Stop working on the project until you receive either a "pass" or "fail" email
  3. Create your "Test Please" following this template:

Note to developers: If current version is better than the last version you can release (even with a test fail) as long:

  • The bugs reported in the test fail existed in the old version
  • 2 people have tested it
  • The changes in this version are fairly important to get out
  • You get to work on the failures ASAP

❌ Don't send a 'Test Please' content via IM

You may use IM (e.g. Microsoft Teams) to point the tester to the 'Test Please' email.

"Ping! I need you to check my 'Test Please' email
See subject: Product Name v1.11"

Getting input from a extra people

If you require input from a few people that were not originally cc'd on the email or on the 'To Myself', like getting feedback on a design, it's nice to give everyone the entire task context.

You have 2 options:

  1. Keep the "test" in the same thread (recommended)
    In this case, just add the people you need to the thread, asking them specifically for a 'Test Please' on what you need
  2. Create a new thread for the 'Test Please' This is for when you have a good reason not to (e.g. avoiding too long email threads; too many people cc'ed, etc). In this case, make sure you include the original thread subject in your email, so people know the main task is happening there

This way everyone will have the entire history of the task and its progress.

Note: A @ mention is all you need if you are following the ideal workflow 😉


'Test Please' specifics

Email draft 'Test Please'

In most cases, you can get your email 'Checked by xxx'.

For really important stuff you may need to actually send a 'Test Please' email to test your email. In these cases:

  • Add 'Test Please' highlighted in yellow to the top of the email body
  • Do not add 'Test Please' to the subject (it is too easy to forget removing it later!)

Windows Forms 'Test Please'

For Windows Forms test you should include this info to the email:

  • The latest version of {{ PRODUCT NAME }} has been uploaded to \frog\SSW\Download[ApplicationverX-XXbeta.exe
  • Test on a fresh VPC image of Windows
  • Install into a non-default directory
  • Check the installation folder for misplaced items
  • Test Unit Tests via "Help - Run Unit Tests"
  • (If Applicable)Test the "Create" and "Reconcile" buttons. Read Rules to Better .NET Projects
  • Test open and closing forms and saving values
  • Test most buttons and menus and links
  • Disable your network connection and test again (check for unhandled errors)
  • If your test fails, please rename the executable to ApplicationverX-XXfailed.exe

Note: For clients on fixed-price contracts, the 'Test Please' reply marks the start of the 30-day warranty period.


We open source.Loving SSW Rules? Star us on GitHub. Star
Stand by... we're migrating this site to TinaCMS