Skip to main content

Wrkbelt Test Strategy

Introduction​

The Wrkbelt Scheduler Tool is designed to streamline booking processes, manage booking flows, and integrate with client admin systems. This QA Test Strategy defines our testing approach to ensure Version 0.0.1 meets quality expectations, minimizes bugs, and supports a successful User Acceptance Test (UAT) with the entire team.

Testing Objectives​

  • Ensure the booking flow works as expected across all supported scenarios
  • Detect and eliminate critical bugs before UAT
  • Automate key E2E workflows and API interactions
  • Integrate automated tests into the CI/CD pipeline (GitHub Actions)
  • Conduct manual exploratory testing and feature validation
  • Provide clear test documentation for future iterations

Scope of Testing​

Automated Testing​

End-to-End (E2E) Testing​

Using Playwright, we validate:

  • All critical booking flows from start to finish
  • Correct handling of catastrophic errors (redirect to phone screen)
  • Express links creation, editing, and status tracking
  • Client admin actions (CRUD operations for bookings, flows, and routers)

API Testing​

Our API testing suite verifies:

  • All API endpoints (Scheduler Tool + Client Admin API)
  • RBAC authentication & authorization
  • Socket communication and data management
  • Secure access and job-type synchronization with ServiceTitan

CI/CD Integration​

Tests are executed as part of our deployment process:

  • Tests run automatically via GitHub Actions
  • Results are reported via Playwright HTML reports
  • Slack notifications for test results

Manual Testing​

Feature Testing​

Objective:
Ensures that each individual feature works as expected according to business and technical requirements.

Entry Criteria:

  • Story/Task status "Ready for QA"
  • Clearly defined acceptance criteria
  • Passed unit tests and static code analysis

Execution Process:

  1. Review feature requirements & acceptance criteria
  2. Prepare test cases or checklists
  3. Execute manual tests and log defects in Jira
  4. Return Story/Task to developer if critical issues exist

Exit Criteria:

  • Feature functions as expected without major defects
  • No critical UI or business logic issues remain unresolved

Exploratory Testing​

Objective:
Uncover hidden defects, edge cases, and unexpected behaviors that predefined test cases may miss.

Execution Process:

  • QA or Developer freely explores features without predefined scripts
  • Report unexpected issues & usability concerns

User Acceptance Testing (UAT)​

Objective:
Ensure that the Wrkbelt Scheduler Tool meets business needs, is user-friendly, and is ready for investor demonstration.

UAT Participants & Responsibilities:

  • Quality Lead: Organizes UAT, ensures test coverage
  • Developers: Fix issues found during UAT, participate in testing
  • Product Manager: Ensures business needs are met
  • Stakeholders: Test real-world scenarios and provide feedback

Entry Criteria:

  • All planned features deployed to test environment
  • Automated E2E & API tests passing without major failures
  • No open high/critical bugs
  • UAT test scenarios/checklists prepared

Execution Process:

  1. Preparation: QA team prepares UAT checklists
  2. Kickoff Meeting: QA presents testing scope
  3. Testing Period: Users test real-world scenarios
  4. Bug Triage: QA & Devs review and prioritize issues
  5. Retesting & Sign-Off: Validate fixes and obtain stakeholder approval

Exit Criteria:

  • All major booking flows function correctly
  • No critical issues remain unresolved
  • Stakeholders approve the release

Test Documentation​

Documentation Guidelines​

  • Create during or before feature testing
  • Focus on regression testing and UAT scenarios
  • No documentation needed for one-time checks

Documentation Types​

  • Test Cases: For well-described E2E scenarios
  • Checklists: For high-level testing coverage and exploratory testing

Test Environments​

EnvironmentPurpose
LocalTest before merging to master
StagingTest after deployment

Bug Management​

Tracking​

All bugs are tracked in Jira with the following priority levels:

  • Highest: Blocks progress
  • High: Serious problem that could block progress
  • Medium: Potential to affect progress
  • Low: Minor problem or easily worked around
  • Lowest: Trivial problem with minimal impact

Definition​

A bug is a software defect found after feature testing. Issues found during feature testing should be handled in the Story/Task ticket.

Exclusions​

The following are not included in Version 0.0.1:

  • Performance testing
  • Security testing
  • Accessibility testing
  • Metrics tracking

Summary​

This QA Test Strategy ensures that Wrkbelt's Scheduler Tool (v0.0.1) is thoroughly tested before release, supports investor readiness, and delivers a stable user experience. The plan prioritizes E2E test automation, API validation, and UAT to ensure a quality product delivery.