Agile Testing

 Agile Is All about Feedback

Bret Pettichord, CTO of WatirCraft and co-author of Lessons Learned in Soft- ware Testing, shared these thoughts on the importance of feedback to agile development.
Agile methods allow your team to get feedback regarding the software you are building. That’s the point. The feedback works on several levels. Pair programming gives developers instant feedback on their code. Sto- ries represent units of work where testers and analysts can give feed- back to developers. Iteration releases facilitate feedback from outside the team. Most agile practices are valuable because they create feed- back loops that allow teams to adapt.
A lot of teams adopt Agile with a grab-bag approach without quite real- izing the point of the practices. They pair-program without discussion or changing drivers. They send code to QA that the testers can’t test be- cause the story boundaries are arbitrary; they can’t tell whether they found a bug or just the end of the story. Iterations become schedule milestones rather than real opportunities to improve alignment and ad- just objectives.
The reason Agile teams can do with less planning is because feedback al- lows you to make sure that you are on course. If you don’t have mean- ingful feedback, then you’re not agile. You’re just in a new form of chaos.
On my last project, we defined our stories so that they made sense to everyone on the team. Our analysts, testers, and developers could all understand and review individual stories. But we found that we had to create a larger grouping, which we called features, to facilitate meaning- ful review from outside our team. We made sure all the stories in a fea- ture were complete before soliciting feedback from outside the team.
Being able to give and receive meaningful feedback is often a challenge for people. Yet it is crucial to success with Agile.
Agile teams get into terrible binds when executives or clients hand them a list of requirements at the start, tell them to use Agile (because it’s faster), and then don’t want to participate in the feedback process.
Agile isn’t faster all by itself. Agile is only a benefit in a world that ac- knowledges the value of adapting. And that adaptability needs to go all the way to whoever is funding the project. It is not enough for the team to be agile. The sponsors need to be agile too. Are all of the require- ments really required? Do we know exactly what the software needs to look like from the start?
Agile is faster because feedback allows you to find and focus on the most valuable features. If you are certain you know what needs to be built, don’t use Agile. If you don’t have time to gather and act on feed- back from customers, then don’t use Agile. If you are sure that everyone understands exactly what needs to be done from the start, then don’t use Agile.
Agile practices build a technical and organizational infrastructure to facil- itate getting and acting on feedback. If you aren’t going to adapt to feedback, then this infrastructure is waste that will only slow you down.
To us, the value of agile development isn’t that it’s faster but that it delivers enough value quickly enough to help the business grow and succeed. Testers play a key role in providing the feedback that allows that to happen.

SUCCESS FACTOR 1: USE THE WHOLE-TEAM APPROACH When the whole development team takes responsibility for testing and qual- ity, you have a large variety of skill sets and experience levels taking on what- ever testing issues might arrive. Test automation isn’t a big problem to a group of skilled programmers. When testing is a team priority, and anyone can sign up for testing tasks, the team designs testable code.

Here’s a sample “stop, start, continue” list from Lisa’s team: Start: 􏰀 Sendingoutnextsprint’sstoriestousearlier. 􏰀 Don’tdolazy,single-recordprocessing.Thinkofeveryservicecallas a remote call. 􏰀 Communicateanydatabasechangestoeveryone. Stop: 􏰀 Acceptingstorieswithoutcompleterequirements. Continue: 􏰀 RunningFitNessetestsforthecodeyou’reworkingon. 􏰀 Documentingwhatcameupinmeetingorinformaldiscussions. 􏰀 Communicatingbetterwitheachother. 􏰀 Showing mock-ups early. 􏰀 DoingFitNessedrivendevelopment.

software company during the time we wrote this book, gave us the following examples of metrics his team provides to their PMO. 􏰀 Testexecutionnumbersbystoryandfunctionalarea 􏰀 Testautomationstatus(numberoftestsautomatedvs.manual) 􏰀 Linegraphofthenumberoftestspassing/failingovertime 􏰀 Summaryandstatusofeachstory 􏰀 Defectmetrics

SUMMARY At this point in our example iteration, our agile tester works closely with pro- grammers, customers, and other team members to produce stories in small testing-coding-reviewing-testing increments. Some points to keep in mind are: 􏰀 Codingandtestingarepartofoneprocessduringtheiteration. 􏰀 Writedetailedtestsforastoryassoonascodingbegins. 􏰀 Drivedevelopmentbystartingwithasimpletest;whenthesimple tests pass, write more complex test cases to further guide coding. 􏰀 Usesimpleriskassessmenttechniquestohelpfocustestingefforts. 􏰀 Usethe“PowerofThree”whenrequirementsaren’tclearoropinions vary. 􏰀 Focusoncompletingonestoryatatime. 􏰀 Collaboratecloselywithprogrammerssothattestingandcodingare integrated. 􏰀 Teststhatcritiquetheproductarepartofdevelopment. 􏰀 Keepcustomersintheloopthroughouttheiteration;letthemreview early and often. 􏰀 Everyoneontheteamcanworkontestingtasks. 􏰀 Testerscanfacilitatecommunicationbetweenthecustomerteamand development team. 􏰀 Determinewhatthebest“bugfixing”choiceforyourteamis,buta good goal is to aim to have no bugs by release time. 􏰀 Addnewautomatedteststotheregressionsuiteandscheduleittorun often enough to provide adequate feedback. 􏰀 Manualexploratorytestinghelpsfindmissingrequirementsafterall the application has been coded. 􏰀 Collaboratewithotherexpertstogettheresourcesandinfrastructure needed to complete testing. 􏰀 Considerwhatmetricsyouneedduringtheiteration;progressand defect metrics are two examples.