I need complete start to end scrum process for testing a change. From taking a bug/enhancement from the product backlog , getting a BRD/FSD, writing Test scenarios......to........logging bugs to Jira or what ever is the end.
Scrum does not define any processes for testing, its more about a general iterative software development workflow and describes communication points and artefacts.
The cycle of a Scrum sprint is that the team commits to a certain number of stories and at the end of their sprint. Those stories should meet the teams definition of done. Which should including testing practises, but the team should come up with what they need to bring the highest quality to make and keep their stakeholders happy. I would start with the most simplest DoD and add steps as your are running into issues.
Some things to keep in mind when defining a test process into the DoD:
- Try to prevent a mini waterfall, do not plan testing at the end of the sprint or task. Read this post: http://www.agilecoachjournal.com/index.php/2014-02-03/scrum/a-sprint-is-not-a-2-week-waterfall/
- Introduce XP practises like TDD and make sure each story has automated test coverage: http://en.wikipedia.org/wiki/Extreme_programming_practices#Test_driven_development
- Less is more, do not introduce a full fletched process into an Agile workflow, unless its absolutely necessary. Make sure you have a continuous improvement process going and have a natural evolution of the teams workflow, with a focus on better quality.
- Fix defects created in the sprint in the sprint and make sure the product is a in releasable state at any time.
- Read the book Agile Testing: http://agiletester.ca/
Handling defects is a more complex topic and could be handled in different ways, either:
- Keep a zero bug policy. In the next sprint first fix all the defects, learn from them and lower the teams velocity accordingly.
- Plan in defects like any other story, since defects are just changes like any other feature, why would they be handled differently?
Keep in mind that not all defects are equal. Some might lower customer satisfactions, while others might be used as features by some clients. Be sure to prioritise defects in the same way as features. Thats why I like the number 2 better then the number 1, but don't let your bug-list grow out of control.