Test Case Execution Guide (Spreadsheet)

Important Note: The images on this page are examples. Your assignment may look different!

If you prefer listening, you can check out this step-by-step video guide here.

---

Before you accept:

1. Before doing anything, make sure you check:

   • Device or environment requirements (OS, browser, app, etc.)

   • Deadline — when your testing needs to be completed

   • Special instructions like language, connection, or app/build specifics

   Knowing this upfront saves time and prevents surprises later.

2. Check if you meet the requirements

If anything doesn’t match your setup, don’t try to stretch it. Reply immediately and decline the invitation.

• Use “Reply all” so the test manager knows right away

• This keeps the process fair and ensures someone else can take your spot

3. Confirm or Decline Your Participation

Once you know you’re eligible:

• Hit “Reply all” to confirm and you can start testing right away

• If you don’t respond within a few hours, your spot might be given to someone else

Think of this as your first step in keeping the testing process smooth and efficient for you and for the team.

 

---

Prepare to test

• Open the Tester Spec (link in the invitation). Read it thoroughly — scope, app link, bug tracker, attachment rules.

• Open the Test Case (TC) document (link in the invitation). Work only on the provided document, do not copy or execute tests elsewhere unless instructed.

---

TC spreadsheet — what to fill (fast reference)

Top header/device cells: add device, OS, browser, app/build info as requested.

Editable columns (you may edit only these):

• Status (Pass / Fail / Blocked / Skip this test)

• Attachment URL (required for Failed or Blocked, unless spec says otherwise)

• Actual result (required for Failed or Blocked)

• Related issues (BUG ID) (required for Failed or Blocked)

• =Remarks

Do not edit identification or instruction columns: TC ID, Section, Subsection, Test Case Name, Preconditions, Steps to Reproduce, Expected Results.

---

How to complete each TC

1. Read the Steps to Reproduce and the Expected Results.

2. Perform the steps on the assigned device/environment.

3. Choose Status:

• Pass — observed behavior matches Expected Result. (No attachment required unless Tester Spec says otherwise.)

Example of a Pass test case:

• Fail — observed behavior differs. Must add Attachment URL, Actual result, and BUG ID (see flow below).

Example of a Fail test case:

• Blocked — cannot execute due to a prior issue preventing access. Must add Attachment URL, Actual result, and BUG ID.

Example of a Blocked test case:

• Skipped— the step cannot be completed for reasons outside your control (e.g., feature not available in your country). Add reason in Remarks.

Example of a Skip this test test case:

4. If Fail or Blocked: attach evidence (video/screenshot/log) as a TesterWork URL and add any related BUG ID(s) and the Actual result.

---

Adding attachments (summary)

• Upload files to Dashboard → Tests→ Attachments.

• Copy the Public URL (use the “Copy URL” action) and paste it into the TC Attachment URL cell.

• Do not paste Google Drive or other external links — ALL attachments must be TesterWork URLs.

• For more information, please see the How to Provide Attachments page.

---

Bug linking flow (Fail or Blocked)

1. Search the bug tracker / Known Issues to see if the issue already exists.

• If it exists → copy the BUG ID into Related issues.

• If it does not exist → submit a bug report, then copy the new BUG ID into Related issues.

2. Add attachment URL and Actual result.

3. If multiple BUG IDs apply, separate them with a comma and a space (e.g., PWT-20-1, PWT-20-2).

---

Important variations (check Tester Spec)

• Some TC docs don’t require attachments at all (no Attachment column).

• Some tests request video recordings per section or attachments even for Passed cases — this will be flagged in the Tester Spec.

• Some TCs must be executed directly on our platform — follow instructions in the invitation.

---

Status checklist (one-line definitions)

• Pass: Expected result observed.

• Fail: Unexpected behavior — add BUG ID, attachment, actual result.

• Blocked: Cannot continue due to a blocking issue — add BUG ID, attachment, actual result.

• Skipped: Cannot perform due to external restriction — add reason in Remarks.

Do’s and Don'ts

Do’s

• Confirm/decline via Reply All to the invitation.

• Test only on the assigned device/environment.

• Read the Tester Spec and the TC instructions before starting.

• Check Known Issues List / bug tracker before filing new bugs.

• Add required details for Fail/Blocked (BUG ID, Attachment URL, Actual result).

• Use TesterWork attachments and paste the TesterWork URL in the TC.

  Complete the work before the deadline.

• Complete the task before the deadline.

• Respond promptly to any Test Manager requests during execution.

• Missing device or OS in invite? Reply All and inform the Test Manager before starting.

  Unsure about a status or requirement? Contact the Test Manager via the invitation (Reply All) or open a Zendesk ticket.

  Always contact the Test Manager for any test-related issues (e.g. Missing device or OS in invite, you’re unsure about a status or requirement, etc)

Don’ts

• Don’t test on other devices unless explicitly allowed.

• Don’t abandon an execution after confirming participation.

• Don’t record or upload internal documents or personal data (Tester Spec, invitation email, bug tracker). Blur sensitive info if recording is required.

• Don’t upload non-TesterWork links (e.g., Google Drive).

• Don’t edit non-editable TC fields (Steps to Reproduce, Expected Results, TC ID, etc.).