Saturday, February 11, 2012

Handling common issues in Scrum Testing

I would like to point out some of the common issues/challenges which we have faced while following the agile/scrum testing. We have learned a lot over a period of time and we are trying to find right approach which would eventually help us to improve our scrum testing practices.

Challenge1: Most of the time QA finds quite a lot of regression issues during final stages (stabilization weeks) which leads unpredictability on the product release. What is the best way to do the regression testing to capture defects in the early stages?

Solution: You need to do incremental regression testing along the way, probably every sprint. This takes careful collaboration with the developers to figure out what to release to the test lab every sprint so that it can be regression tested.

Challenge2: What would be best way QA can work with development to understand the complete test scenarios / cases?

Solution: QA needs to talk to the Dev. team constantly. Be in their grooming sessions. Act as one team. Work as one Team. Be SMEs for them during development, so that the testing is done on their box as part of their work before it ever gets to you.

Challenge3: Most of the times QA has been pointed out as a root cause of delay in release (which is a trend all over the world), even though they do get better every release but we are not their yet to show our class. What is the best way to improve QA process here?

Solution: Integrate it into the development process. Make sure QA & Dev works together as one team.

Challenge4: What are all the QA best practices we can follow (as per scrum)?

Don’t separate verification testing from development. By the time QA gets to the code, it must beknown to work, the only question should be validation that it does the right thing.

Do validations constantly, either intermingled with development, or as a separate thread. Think of the code as leapfrogging from Dev to QA.

Every sprint a new build is dropped on QA, it does validations (not verification, that’s done in dev, but possibly by testers on the team) to find new stories that are dropped back on the backlog. The PO prioritizes them alongside everything else, and it keeps going.

Always remember that it’s about the product, not the code. The product is not finished until it’s been validated and defects have been corrected. Therefore, the developers are not finished until that happens, either.

Last but not the least…”It must be thought of as one big team, not two teams… “

This is exactly what i am proposing to my management to get the ball rolling in the right direction but it has its own challenge:-)