QA

Phase 1: Planning

Scope Defined: The features to be implemented are clearly defined and scoped out.
Requirements Gathered: Gather and document all the necessary requirements for the feature.
Stakeholder Input: Ensure relevant stakeholders have provided input on the document scope and content.

Document Complete: All sections of the document are filled out with relevant information.
Reviewed by Stakeholders: The document has been reviewed and approved by stakeholders.
Ready for Development: The document is in a state where developers can use it to begin implementation.

Task Breakdown: The development team has broken down tasks based on the document.
Communication Plan: A plan is in place for communication between developers and writers if clarification is needed during implementation.
Developer Understanding: Developers have a clear understanding of the document content.

Code Implementation: The feature is implemented according to the document specifications.
Developer Testing:
- Unit tests and basic integration tests are completed
- Developer also completed self-testing for the feature (please add this as a comment in the ticket, with the tested OS and as much info as possible to reduce overlaping effort).
- (AC -> Code Changes -> Impacted scenarios)
Communication with Writers: Developers have communicated any changes or challenges to the writers, and necessary adjustments are made in the document. (Can be through a note in the PR of the feature for writers to take care, or create a separate PR with the change you made for the docs, for writers to review)

Test Note Defined: The test note is prepared outlining the testing items.
Environment Ready: PR merged to nightly build, Nightly build notes updated (automatically from pipeline after merged).
Status: Ticket moved to the column Testing and assigning to QA/writers to review.
Test Data Prepared: Relevant test data is prepared for testing the scenarios.

Test Executed: All identified test items are executed on different OS, along with exploratory testing.
Defects Logged: Any defects found during testing are resolved / appropriately logged (and approved for future fix).
Test Sign-Off: QA team provides sign-off indicating the completion of testing.

Pre-release wait time: Code change to pre-release version should be frozen for at least X (hrs/days) for Regression testing purpose.
- Pre-release cut off on Thu morning for the team to regression test.
- Release to production (Stable) during working hour on Mon morning (if no blocker) or Tue morning.
- During the release cut off, the nightly build will be paused, to leave room for pre-release build. The build version used for regression test will be notified.
Pre-release testing: A review of the implemented feature has been conducted, a long with regression test (check-list) by the team.
- Release checklist cloned from the templat for different OS (with hackMD link)
- New key test items from new feature added to the checklist.
- Split 3 OS to different team members for testing.
Document Updated: The document is updated based on the review and feedback on any discrepancies or modification needed for this release.
Reviewed by Stakeholders: New feature and the updated document is reviewed and approved by stakeholders. The document is in its final version, reflecting the implemented feature accurately.

API collection run: to run along with nightly build daily, for critical API validation
Automation run: for regression testing purpose, to reduce manual testing effort for the same items each release on multiple OS.