"We have use the scrum process for about 6 months and I feel we are still practicing mini waterfalls. I really need help to defining the role of QA from start to finish. Are we suppose to write test plans? While we are waiting for development, we are unable to write test cases because the specs are not fully define and items that are being added are changing. In the end, we have the product not fully testing and catching up with the next sprint. No test cases are done and no automation is done. Seems like it is what we were doing before."To me this sounds like a case of going to short iterations too fast! Most of my thoughts on the role of QA in an Agile project (Scrum or not) are articulated in the two recent posts I've already made on this topic, but here are a couple more thoughts...
Opinions may vary on this, but IMHO, if there are no test cases and no automation, you're just not going to succeed with any Agile methodology, Scrum or otherwise. One of the major principles of Agile is that you have working software at the end of every iteration. If it hasn't been tested, how do you know if it is working? It sounds to me like you've got complete chaos.
Do you have an Agile coach on the team? Do you have certified Scrum Masters on the team? If not, I'd highly recommend getting one or both of these.
I believe that for any Agile project to succeed, each story must go through a full and complete mini-lifecycle prior to the end of the iteration. That is, whatever process it would have gone through in your old methodology, it should still go through and it should happen during the term of the iteration. My preference would be that it go through those steps in immediate succession. That is, before code begins on any story, you are clear what you are setting out to accomplish (requirements), you have a plan for doing it (design/spec), and you have created as many test cases as possible. I'm not saying that all of the requirements are known at the start, but that you do as much as you can. Same for designs, specs, test cases. Worst case, all of these should be done for whatever code is done at the end of the release.
For instance, if story 1234 has code associated with it that performs 4 functions, then you better have the requirements, design, and test cases rock solid at the end of that iteration and those test cases better all be automated and passing. By "rock solid" on the requirements and design I mean that at a minimum, the coder better be able to articulate it to you. If they avert their eyes and hem and haw, how will anybody be able to use it?
If at the end of the iteration you don't have near 100% of what you have come to expect just prior to starting your release process (delivery to customer), then you need to stop immediately, do a retrospective, and take immediate corrective actions!!
Good luck and be sure to keep post updates on your progress.
1 comment:
The QA role is fundamental to the success of the iteration. Stories should not be brought into an iteration if they do not have defined acceptance criteria. Starting a story that doesn't have a defined ending doesn't make sense. The QA should be the gateway for incoming stories and should only allow stories to come in which have the acceptance criteria defined in sufficient detail to allow test cases to be developed.
As an agile consultant I would strongly advise that the you look closely at the planning game that brings the stories into play. It sounds that this process is not working correctly.
Post a Comment