I get many questions regrading where to find a good source to learn "Scrum". One of my favourite is
http://www.mountaingoatsoftware.com/topics/scrum
Thursday, November 18, 2010
Wednesday, November 3, 2010
Is the Sprint truly complete if QA still has work to do and how should it be solved using SCRUM?
Consider this as a solution. I will explain the reasoning behind after the solution. I do not know how big the team is, but I am working based on a 3 developers, 2 analysts scenario... the ratio can be changed....
>>Solution:
- Have Analysts. One position that cover both QA and business analysis roles.
- Keep user stories short.
- Release as often as possible to your testing environment. Every day, or every time a testable section is available.
- Consider regression testing every iteration. If automated, consider it more often than once every iteration. If manual, then at least once. (i.e. also consider this in iteration planning/Estimation)
- Extra: Consider unit testing. This will promote the team to focus on quality, rather than functionality.
- Define "done" as ready for live.
>>Reasoning:
Each iteration analysts are working on user stories for future iterations and test scripts for the current iteration. Also have another analysts taking on the role of testing the functional scripts of a user story not worked by him/herself. Once deployed to the testing environment, the analyst will test. The aim here is to avoid lingering untested features and undiscovered bugs from being in the system for too long. By doing the above, you will have the analysts busy with user stories and testing, thus eliminating the worry of people not having work to do.
By having user stories small enough, you will have proper functional testing, and since you are covering for regression testing, you are ensuring all testing from your end. within the iteration, you covered for the unit, functional, and regression testing.
If doing manual regression testing, then analysts, and developer cover the testing using the test scripts to ensure coverage.
Remember that in scrum, you use the "Skill set" and not the "role" or "position" of a person. so "theoretically" you can have developers only who are good at user stories/dev/testing... etc. So when dealing with an issue. think of the team doing something rather than the person with such and such role doing something.
>>Solution:
- Have Analysts. One position that cover both QA and business analysis roles.
- Keep user stories short.
- Release as often as possible to your testing environment. Every day, or every time a testable section is available.
- Consider regression testing every iteration. If automated, consider it more often than once every iteration. If manual, then at least once. (i.e. also consider this in iteration planning/Estimation)
- Extra: Consider unit testing. This will promote the team to focus on quality, rather than functionality.
- Define "done" as ready for live.
>>Reasoning:
Each iteration analysts are working on user stories for future iterations and test scripts for the current iteration. Also have another analysts taking on the role of testing the functional scripts of a user story not worked by him/herself. Once deployed to the testing environment, the analyst will test. The aim here is to avoid lingering untested features and undiscovered bugs from being in the system for too long. By doing the above, you will have the analysts busy with user stories and testing, thus eliminating the worry of people not having work to do.
By having user stories small enough, you will have proper functional testing, and since you are covering for regression testing, you are ensuring all testing from your end. within the iteration, you covered for the unit, functional, and regression testing.
If doing manual regression testing, then analysts, and developer cover the testing using the test scripts to ensure coverage.
Remember that in scrum, you use the "Skill set" and not the "role" or "position" of a person. so "theoretically" you can have developers only who are good at user stories/dev/testing... etc. So when dealing with an issue. think of the team doing something rather than the person with such and such role doing something.
Subscribe to:
Posts (Atom)