General Conditions for All Items (Task or Bug)

Condition	Description
AC Clarity	Acceptance Criteria must be written in a clear, unambiguous, and testable manner.
Git Merge Flow for Stage Update	The developer must prepare and follow a clear Git merging process for updating the stage server. This ensures all new features and bug fixes are successfully deployed and verified on the stage server before production release. For an example The steps may include: Creating/reviewing a pull request PR into the appropriate branch Ensuring all automated checks and code reviews are completed Merging PR only after required approvals Deploying the merged code to the stage server Confirming successful deployment and notifying the QA team for verification.
User/Business Context	Task or bug description must include user needs, feature goals, and business value where relevant.
Complete Design States	Delivered designs must cover all applicable UI states, including Empty, Error, and Success.
Data Migration Plan	If the change affects the data model, a migration strategy must be defined and documented.
QA Test Time Consideration	During the planning meeting, the QA team should specify the time required for testing each feature, and the Development team should adhere to this schedule.
Status	For a task or bug to be marked "Ready for QA" in the project management tool (Oktuple Status), it must be done solely by the assigned developer.
Development Complete	The code for the task/bug is fully implemented and passes developer-level testing (This should be done for every AC).
Merged to Test Branch	Code is merged into the appropriate test environment (e.g., staging, UAT).
Regular Test Deploy Schedule	The QA team must be informed of deployment times to the test environment via Wave notifications before deployment. Additionally, changes to the deployed version should be communicated regularly in the patch note.
Build/Deployment Complete	The build is successful and the feature is deployed to the QA environment.
Test Environment Stable	QA environment is available and not under maintenance. All updates and merge requests to the staging server must be communicated to the test team in advance to avoid any disruption in the testing process.
Test Data Ready	All required test data is available, or clear instructions and necessary tools for its generation are provided, with responsibility assigned to either the Development or QA team as pre-agreed.
Design/UI Review Complete	UI changes are approved by the design team, if applicable.
No Known Critical Blockers	There are no open blockers that prevent QA from testing the item. All upstream dependencies are noted in the dependency table, keeping the item in a "QA Blocked" status until resolved. These dependencies should be discussed daily to ensure quick resolution.
Postman API Collection Shared	For API features or bug fixes, a tested and up-to-date API collection (e.g., Postman) is shared with QA. It includes necessary headers, authentication details, sample payloads, and expected responses.
Feature Toggle Info Provided	If a feature is behind a toggle, QA is informed on how to access it.
Root Cause Explained (Requirements for Bug Fixes)	(If available) A short explanation of the root cause is shared.
API Contracts Finalized	If a feature involves API calls, the contracts are finalized and documented.
Performance Benchmarks	For tasks involving performance improvements, the Product Manager is responsible for defining and clearly indicating the expected performance benchmarks.
Security Considerations	If the feature touches authentication, authorization, or data privacy, related notes are included.
Developer Availability	Developers should be available to quickly resolve testing blockers or answer questions during test execution.
Joint Test Execution	In sensitive or critical cases, joint test execution between QA and Development is recommended.