Hum...
So the title of your message concerns me. Don't think in terms of codeing and testing, think engineering. Ensuring quality at the end is doomed to failure. Assure functional quality during development. For example: * TDD or unit testing tend to get rid of lots of defects before they are even committed to the codebase. * Continuous integration ensures that your product builds as a whole throughout development. * Having a clear definition of "done" means that acceptance testing can start on finished stories during the iteration. * An iteration/sprint should be long enough to engineer (build and test) a useful peice of functionality. Not coding sprints followed by test sprints. All this adds up to not having a lot of quality debt at the end of an iteration. Specifically on the what do you do at then end of an iteration. Typically the team gets together and asks; "What went well?", "What went not so well?" and "What things could we try and improve next iteration?" These may be related to the quality of the product but might equally concern any other aspect of building software. The team picks a couple of the top things they think they could improve and works on them during the next iteration, over time these small improvements add up. This is reflection-adaption but it applies to all aspects of what you do not just product quality. Thanks, Ade ________________________________ From: [email protected] [[email protected]] on behalf of Anne Wax [[email protected]] Sent: Wednesday, December 22, 2010 7:39 AM To: [email protected] Subject: After the Code is Done - Strategies to Ensure Quality What do you do at the end of a sprint or a release cycle to ensure quality? We've seen some blogs that talk about stop-reflect-adapt and review-reflect-repeat. What do you all do when you have completed an interation or a release cycle to ensure your product's excellence? Do you step back to review and improve before moving on to the next cycle or project? What happens in "real life" and what is the ideal? Thank you, Anne http://www.agileweboperations.com/stop-reflect-adapt-the-3-steps-to-stop-writing-bad-code http://www.agilejournal.com/blogs/blogs/all-about-agile/704-how-to-implement-scrum-in-10-easy-steps-step-10-review-reflect-repeat -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en. -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
