Test Execution¶
All test results should be logged in ClickUp under Trove > Test Cases. Test results are also saved under Trove > Test Cases > Test Results.
The goal is to manually perform test cases step by step and record the outcome of each one.
Types of testing¶
System testing¶
Test the complete, integrated system against formal requirements by following the test cases created during the Test Cases Design phase.
Exploratory testing¶
Use intuition and experience to "wander" through the app and explore based on what you see — not tied to written test cases.
Cross-browser testing¶
Ensure UI and functional test cases work across supported browsers (Chrome, Firefox, Safari, Edge) and devices. Use high-priority test cases for this.
Recommended tools: BrowserStack, Playwright
Automated E2E testing¶
API endpoints and key customer flows are covered by automated tests that run on every pull request. These do not replace manual execution but reduce the need to manually retest stable, well-covered flows.
- API endpoints — Writing API E2E Tests
- Customer frontend flows — Writing Playwright Tests
- Overview of what runs automatically — Automated Testing
Running your test cases¶
Step 1 — Follow the steps exactly¶
Follow all steps created during the test case design phase. Do not skip steps or deviate from the written instructions.
Step 2 — Update the status on each task¶
| Status | When to use |
|---|---|
| To Test | Test case has not been started |
| Testing In Progress | You have started working through this test case |
| Pass | Actual result matches expected result |
| Failed | Actual result differs from expected result — create a bug report |
| Blocker | Actual result blocks certain features or modules, preventing further testing |
| N/A | Feature is not applicable |
Step 3 — Collect evidence¶
- Take screenshots or screen recordings for every Fail
- Take screenshots for Pass as well, for audit purposes
Recommended tools:
- ClickUp Recording (built-in recorder)
- Loom (embeds directly into ClickUp)
- Snipping Tool (Windows)
- Screenshot App (Mac)
Example test results¶
Scenario: Login Page
| Action | Expected Result | Actual Result | Status |
|---|---|---|---|
| Enter "user123" in the Username field | Text appears in the field | Text appears in the field | PASS |
| Enter "Password!1" in the Password field | Characters are hidden (dots) | Characters are hidden (dots) | PASS |
| Click the "Login" button | User is taken to Dashboard | User is still on Login Page | FAILED |
| Enter "user123" in Username | Text appears in the field | Cannot perform (page didn't load) | BLOCKED |
| Open Profile Settings | Settings menu opens | Settings menu opens | PASS |
| Click "Delete Account" | Confirmation popup appears | Button has been removed from the app design | N/A |
Progress tracking¶
| Metric | Formula |
|---|---|
| Test Execution Progress | (Executed Test Cases / Total Test Cases) × 100 |
| Passing Rate | (Passed Test Cases / Total Executed Test Cases) × 100 |
| Defect/Bug Count | Total number of bug reports created |
| Blocker Count | Number of test cases currently blocked |
Reports¶
| Report | When | Purpose |
|---|---|---|
| Test Progress Report | During execution | Monitor whether testing is on track to meet the deadline |
| Test Summary/Completion Report | After execution is done | Shows total passes, fails, and any remaining risks |
Do's and don'ts¶
Do:
- Capture screenshots and logs
- Use clear pass/fail criteria
- Prioritise by risk
- Vary your test data
Don't:
- Assume "it works on my machine"
- Skip steps
- Clutter bug reports
- Ignore the UI during functional tests