| Table of Contents | ||||
|---|---|---|---|---|
|
...
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
...
How to track modifications to backlog items. E.g. when testing, if something needs to be added, what should we do?
PO and users:
test in ACC
They can test on the first day of the next sprint - will will give them a list of what we completed and they can test if they can, if not, that is ok - maybe 1 hr of testing for them
Dev - send a screenshot of new UI before the functionality is built to get feedback from PO via email. Do not need to send screenshots for things such as bugs, and FR translations. Only things we need feeback on.
PO walkover - two days before the end of sprint - 15-30 min to take a quick look if screenshots are not enough - flexible. PO may not need it every week.
Can show him work still in progress
Users can test in test environment if they wish after sprint review. We can give them a few bullet points of what we worked on. Either at end of review or first day of sprint.
Formulating a definition of done - checklist of things:
Criteria
Unit testing
Automated testing
QA Testing
No other sign-off is necessary as PO has seen screenshots, walk-through and review
Future consideration:
Security
Code coverage
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?
Scope
Time
Quality
Automated Testing
How can we implement?
How can we keep QA involved?
What is the outcome of implementation? E.g. less QA manual testing
...