QA/testing in scrum team

This was the original guidance I gave the team on what to do after we migrated from waterfall to Scrum. I'll try to get back to this and see how things have changed in a month or so. FYI ... I'm giving up on this position and moving on as I don't really feel challenged as a QA specialist (who's not an automation specialist but rather a manager) in this way of working. I'm moving on to a position as a Test Strategy Manager at another company. More updates later!

QA in the Scrum teams

Release planning

1. Estimate risk areas for code
2. Are there any special QA considerations?
3. Is there an order for the chosen tasks to be done in to make a more meaningful release?
4. Are there items that should be done sooner because they are more risky?
5. Are there things that need to be developed to help QA, IE a method of accessing an algorithm that would otherwise require a GUI?
6. Lightweight test planning, identifying assumptions, risk, priority, scope. Does QA need time to learn things?
7. Test data sets? Define/create
8. Is there a test environment that isn’t a developer sandbox?
9. What sort of reporting is happening?
10. Be alert to a need for load or security testing.

Beginning of Sprint
1. Prioritization (planning poker) – include QA time.
2. Are there special QA items to be added into the sprint?
3. Think about “happy path” test cases and get to developers ASAP.
4. Be alert to items where the testing severely outweighs the development time
5. Create or obtain necessary test data
6. Be alert to the testability of the work items. Ask how to test if it’s not clear
7. Verify environment is ready for testing

Sprint Zero
1. Set up server and get it stable.
2. Investigate the items being considered for the backlog from a “what does it need to do” aspect – prepare for the product planning/prioritization meeting.
3. Get automation running on the team server.
4. Meet daily to discuss progress, etc. (start Scrum meetings).
5. Do you need something deployed that’s not part of the standard setup, such as Multimailer or Jobs Police? Work with the WSEs to get this created.
6. Spend time learning Selenium.
7. Attend workshops on the product backlog.
8. Investigate development/testing options for items in product backlog in preparation for the product planning meeting.
9. Work on integration with your team.

During Sprint
1. Lightweight scripts for “happy path” – execute as soon as done.
2. Daily code drops into environment (should get a report of what’s been finished or this work should go on information radiator) then test
3. Work with developer when testing? At the least show defects right away and get them fixed ASAP.
4. Script out more complex cases
5. Run automation against build daily
6. Daily standup – any blocking issues? Find out what is ready to test today and tomorrow.
7. Get information on areas that aren’t defined well to make sure you’re testing things as intended, not as designed
8. Develop scripts for non-happy path (bad data etc.) and run these when the developer says it’s ready.
9. Do exploratory testing regularly
10. Bugs that can’t be fixed in the time left should be put into the sprint backlog – bugs fixed right away don’t need to be documented
11. Define what automated tests should be added to the regression and work to get them created.
12. Keep track of bugs/code failures on information radiator
13. Make sure team is aware of QA progress in general
14. Work to improve quality of code in general
15. Keep an eye on the next iteration
16. Participate in product backlog definition if necessary
17. Be mindful of testing from other points of view
18. Be alert to estimates that didn’t include enough time for bug fixes
19. Review plans for testing with developers so they know what’s coming. Work to resolve discrepancies.
20. Ask developers for feedback on high risk areas of code.

End of Sprint
1. Participate in review of code with owner
2. Make sure carryover bugs have made it into product backlog
3. Execute end to end and system tests in a stable system

Pre-release
1. Define acceptance tests
2. Pass on information to Ops team about condition of code
3. Execute integration testing with other code likely to be released with this code
4. Verify automation has been created to capture new functionality
5. Define if there will be any tests that can only be tested in the live environment if this had not been previously done

Taking project through release
1. Verify pre-release environment is ready for testing
2. Execute automation as required
3. Execute acceptance tests
4. Perform integration, system, end to end, and exploratory testing against pre-release environment with new code
5. Work with developers to get bugs fixed ASAP
6. Work with release manager/scrum masters to make sure code quality is appropriate for release
7. Write up bugs so they can be monitored by all projects in release
8. Participate in release of product to live
9. Participate in testing of fixes to any errors found after release