What about integration testing? TDD and CI help for building solid code, but there is also a need to test everything together. Perhaps it is UI whitebox testing, or some other style if tests that don't tend to get developed in the normal course of an iteration.
Erick Sent from my iPhone On Dec 22, 2010, at 1:11 PM, Anne Wax <[email protected]> wrote: > Hi all and thank you. There's lots to think about here, and I will reread > later tonight. > > I wanted to answer some of your questions and key points. > > By end of an iteration I meant end of a sprint, the end of finishing a set of > features to address a business need that takes longer than one sprint, and > at the point when a version of the software is released for Production use > (vs for testing/pilot use). We'll see if these designations open up a whole > new can of worms regarding what is 'agile' or not 'agile'. > > re: the real world and ideal - it is not about giving up, but rather having > processes that build in the ideal (refactor as you go) and recognize that > sometimes you have to deliver, and then finish. For example, on a larger > project you might have multiple sprints to build a significant piece of > functionality, but then as you are finishing, you think of a better way to do > it. The schedule does not allow the immeidate refactoring, but it is needed. > Or what about when the installation or training documentation is hard to > write as you go until the product has been developed. > > I am coming from the perspective of a large enterprise system used by over 20 > customers with set delivery schedules/dates. Yet we are using many agile > tools such as scrum, daily builds, teams of testers and developers working > together on each sprint, unit and web testing, refactoring, etc. And we are > trying to do a better job all the time. > > Thanks for all your input. I enjoy these discussions and am often watching > the conversations. > > Anne > > On Wed, Dec 22, 2010 at 7:52 AM, Ade Miller <[email protected]> wrote: > 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. > > -- > 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.
