📦 Releases

🧑‍💻Pre-Release

Ideally, it is preferable to have a test server that is not only a clone of production but also gets new releases deployed to it first so QA can test in a smilar environment that hasn't had several random database migrations and branches merged. The test server should only receive release deployments for pre-release testing.

🗂 Task Release Workflow

• Create task titled as Release (version)
• Itemize all tasks that are part of this release
  • Link Tasks and PRs
  • Copy Acceptance Criteria from each task into the Release Task
    • Be sure to include any new requirements found in testing the individual tasks
• Run through each requirement of each task
  • Mark individual tasks as Pass or Fail in Release Task
    • Go to each individual task and comment " ✅ QA PASS - Pre-Release (version)" for posterity
    • If there are failures early on, notify the developer ASAP, otherwise wait til test completion before sharing report
    • If most requirements pass, run through basic regression, e2e, risks/priorities
    • If all requirements pass, run through thorough regression, e2e, risks/priorities

🏁 Post-Release

• After release is deployed to Production attempt to test the requirements on Production with a focus on Risks and Priorities.
• With an ideal production-like test server you can do more thorough post-release testing to double check all of the requirements still pass. This can be less thorough, assuming pre-release testing on the test server was performed aggressively to trigger potential failures.

🐕 Dog-Fooding

• Invite your teammates or coworkers outside of the team as appropriate to test the application in any capacity they prefer.
  • Some may barely test, some may be more thorough but some may find issues outside of scope.
  • More commonly "dog-fooding" is performed over a perior of 1 or 2 weeks in a situation where the team uses the application as if they are end-users.
    • This of course can be performed individually by QA if time and deadlines permit.