Page Comparison

Sprint Architecture

Length: 10 business days

Day 1

Dev:

QA:

Day 2:

Day 3:

Day 4:

Day 5:

Day 6:

Day 7:

Day 8:

Day 9:

Day 10:

Testing

Discussion with Grace - April 4

Bugs addressed during the sprint. Leave some space for bug testing during the sprint

10 business days

First 3 days:

• Ad-hoc testing

• UAT prep - documentation regarding the previous sprint

• Users can test what was completed last sprint - Grace or Steve, do not need two team members

• TGD team - QA team tests first, and then PO or user tests, and the user or PO marks it as done. User or PO testing does not need to be complete during the same sprint.

Issues to think about:

• How to track modifications to backlog items. E.g. when testing, if something needs to be added, what should we do?

Test Cases

Questions:

• What will the test cases be used for? (e.g. backlog testing, automated testing, future use)

• How can we minimize the amount of work required to write a test case? E.g. focus on developing a specific feature per sprint, so test case writing can start on day 1 - ? Perhaps identify which backlog items will need test cases at the beginning of the sprint, so test case writing can start at the beginning?

Automated Testing

• How can we implement?

• How can we keep QA involved?

• What is the outcome of implementation? E.g. less QA manual testing

Unit Testing

{Add short write-up, description}

Release Planning Architecture

2 month release schedule - Release Train

Total: 4 sprints

Sprint 1

Dev:

60% - New development

10% - Bug Fixes

20% - Tech debt

10% - Release activities

QA:

70% - Backlog item testing

20% - User testing - day 10? Either PO or QA?

10% - UAT prep

Sprint 2

Sprint 3

Dev:

QA:

50% - ACC environment testing

50% - UAT testing (with users) - Test environment?

Sprint 4

Dev:

50% - Release activities

?? % - Critical bug fixes?

?? - ??

Dev - Release Architecture Needed

Manual to automated - Jugraj is working with Henry on this

One click deployment

Patch fixes - how do we implement?

...

Backlog Item Breakdown

Release Process

We will ship once per sprint.

Daily Breakdown

Length: 10 business days

One-off Sprints

• Bug fix only sprint

• Full regression test

Backlog item checklist

Shippable Stories

UAT

• Product Owner or QA:

  • Provide list of backlog items to users

  • Users can test in ACC if they have time

  • If users do not have time, they do not have to test (not required)

  • Users should only test one hour max

Sprint Testing

• UAT testing sheet

• Smoke testing

Sprint Branches

Sprint Environments

*When work in QA is ready for next release, they will be pushed to ACC

Deployment

Current: Manual deployment

Future: One-click deployment (Jugraj is working with Henry)

Definition of Done

• Acceptance criteria is complete

• PO (or equivalent) has approved screenshot of UI for new work (as needed)

• Unit test is complete

• Test case is written

• Playwright test is written

• Changes don’t introduce any new security defects, code-quality issues, or lower the code-coverage percentage

• QA manual (main functionality and other components it interacts with) test is complete in correct branch

• Documentation for security groups

Future consideration

Definition of done future consideration

• Security

• Code coverage

Testing