DoD and 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.
- 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.
Feature branch → Nightly Build (Dev branch) → Pre-release (Release Candidate Branch) → Stable (Main)
