© University of Colorado, 2010Ending an IterationKenneth M. AndersonUniversity of Colorado, BoulderCSCI 5828 — Lecture 24 — 04/08/20101GoalsReview material from Chapter 9 of Pilone & MilesEnding an IterationSystem TestingBug ReportsIteration Review2Ending an IterationFollowing the agile practices we’ve covered each iteration will havecustomer-driven functionality (user stories; feedback)compiling code & monitored builds (continuous integration)solid test coverage and continuously tested code (TDD)reliable progress tracking (burn-down chart)pacing that adapts to the team (iteration plan; velocity)and with this you may find yourself with spare time at the end of an iteration3What else can be done?At the end of an iteration, you can reflect on things you’d like to add to daily work practice to provide additional benefitsSuch asprocess improvements (what’s not working?)system testing (we’ve got unit tests and integration tests)refactoring of code based on lessons learnedcode cleanup and documentation updatesdesign patternsenvironment updates, R&D, personal development time4Data in Burn DownOne way to reflect on the iteration is to look at the burn-down chartIt can provide insight into the effectiveness of the teamWere we ahead, were we always behind?Are we good at adapting to change?5Unplanned Tasks6Burn DownDays LeftWorkLeft04420 0IdealBurn DownRateThis burn-down chart shows the team getting burned with unplanned tasks and/or user storiesThe drop to zero at the end is NOT the result of some heroic effort on the part of the team; likely it is simply a result of scoping downBad Estimates7Burn DownDays LeftWorkLeft04420 0IdealBurn DownRateThis burn-down chart shows the team had bad estimates; everything took longer than plannedNot getting to zero means the team needs to learn how to re-scope: delaying tasks and stories to subsequent iterationsIntegrating System Tests8Our techniques do not provide time for system testingA system test exercises the functionality of the system from “front to back” (UI to persistence layer) in real-world black-box scenariosDevelopers are too biased to do system testing, they know the code too well and do not necessarily have access to realistic test dataYour end users should be the ones performing system tests on real dataIf that’s not possible, you need a testing team!Off by OneIn each iteration, the developers are concerned with the current set of user storiesThey test constantly but those are unit/integration testsA test team, then, can perform system testing on system n-1 during iteration nDuring iteration 1, the test team gets ready for iteration 2Reviewing stories, writing tests, installing tools, etc.This leads to more being done in each iterationand the book views them as separate iteration cyclesthat is, more iterations9More iterations, more problemsRunning two iteration cycles meansLOTS more coordination which requires LOTS more communicationWill require “cross pollination” of standup meetingsForces testing into a “box”: fixed time stepMay not be able to cover all functionality within a single iterationBug fixing mixes in with new workIf the testing team is finding bugs, guess who has to fix them?Tests are written against a moving target10More problems, more talkIn order to deal with these problems, you just needMORE communication to enable better coordinationand remember, in agile approaches, we value direct communicationWe do have to worry about this on one level (Mythical Man Month) but remember that agile approaches avoid a lot of the documentation that slow traditional SE approaches down11Effective System TestingGood, frequent communication (devs., test team, customer)Known starting and ending state of systemDocument your test suitesEstablish clear success criteria (when can we go live?)Automate your testsDevs and test team work together (avoid fights!)Test team understands big picture view of systemAccurate system documentation12Test results?We eventually want to see all tests passbut before we do, the results of testing are bug reportsBug life cycleTester finds bugCreates a bug report and submits it to issue tracking systemDevelopers create a story or task to fix the bugEnters iteration plan and handled as normalDevelopers fix the bugTester checks the fix and verifies the bug is goneTester updates the bug report (sets status to closed/resolved)13Bug TrackersPlenty of systems out there to do bug trackingFogBugz, Bugzilla, Mantis, TestTrackPro, ClearQuestImportant because theylet you prioritize bug reportsrelated to success criteria “go live when only priority 4 bugs remain”let you keep track of everything related to a bug fixlet you generate important metrics related to life cycle qualitybug submission rate? location of bugs? bugs outstanding?14Bug ReportsGood bug reports containA summary that describes the bug in 1-2 sentencesThe steps needed to reproduce the bug (see it in action)Expected Output vs. Actual OutputConfiguration Information: Platform, version, etc.Severity: how bad is the impact of this bug?Priority: how quickly do we need to fix this bug?Current Status15Iteration ReviewAt the end of an iteration, take time to reflect and identify how the process can change to make things run smoothlyA good iteration review requires that youprepare ahead of time: bring a list of things to discussbe forward-looking: what should we do to improve the next iteration?calculate your metrics: velocity, burn-down rate, etc.review a standard set of questions that helps the team look for opportunities to improve16Review QuestionsWas the quality of our work acceptable?Was the pace acceptable?Are you comfortable with your current work assignments?Are our tools getting in the way? Are there new tools to consider?Was our process effective? Does something need to change?Performance problems? Bugs to discuss?Testing effective? “Bad smells” to get rid of17If you have extra timeIf you have “free” days at the end of an iterationFix bugs and/or refactor and/or update documentationTackle a user story from the next iterationPrototype solutions needed in the next iterationTraining or Learning Time: Google’s “20% time” practice18Wrapping UpThe end of an iteration is a time for reflectionWhat should we change to make the next iteration better?It is also a time for catching up or getting aheadLearn to use iterations wellPay attention to burn-down rates and what they tell you about the teamPace the iteration ; if you have
View Full Document
Unlocking...