Phase 1: Planning

Definition of Ready (DoR):

  • 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.

Definition of Done (DoD):

  • 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.

Phase 2: Development

Definition of Ready (DoR):

  • 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.

Definition of Done (DoD):

  • 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)

Phase 3: QA for feature

Definition of Ready (DoR):

  • 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.

Definition of Done (DoD):

  • 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.

Phase 4: Release (DoR)

  • 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.

Notes (WIP)

  • 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.