Communication tools and skills for software testers on agile teams

1. Communication tools and skills for software testers on agile teams Tim Van Tongeren www.testgeek.com

2. Manifesto for agile software development • Individuals and interactions over process and tools. • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan. (Marick, 2001)

3. Benefits of agile development • Reduce cost of moving information • Reduce time from decision to feedback (Cockburn & Highsmith, 2001)

4. Some agile methodologies • Extreme Programming (XP) • Scrum • Crystal

5. Extreme programming • “XP is designed for small, colocated teams aiming to get quality and productivity as high as possible. It does this through rich, short, informal communication paths…” (Cockburn, 2002)

6. Extreme programming • Pair programming & test-driven development (TDD) • 100 % unit tested code in each build • Small releases occurring often • Customer tests (Jeffries, 2001)

7. Testing in XP • Testers fall into the “Customer Test” role. • Tests are driven by User Stories • Most tests are automatic • Test reporting is public (Jeffries, 2005; Jeffries, 1999)

8. Scrum • Month-long sprints with only 9 people and no scope creep • Scrum master runs a short, daily scrum meeting • What have you done since the last meeting? • What has impeded your work? • What do you plan to do before the next meeting? (Cohn, 2003)

9. Scrum’s task board (Cohn, 2003b)

10. Crystal • Shrink-to-fit • Teams must be collocated • 1-3 month releases • Pre and post release workshops • Test cases are a work product (Cockburn, 2002)

11. Crystal categories (Cockburn, 2002)

12. Sweet spots of agile • 2-8 people in one room • Onsite usage experts • One month increments • Fully automated tests • Experienced developers (Cockburn, 2002)

13. Test-driven development • Even with 100% unit tested code, we still might have • Incompleteness • Inconsistency • Ambiguity • Incorrectness

14. Methods of agile development • Reduce cost of moving information • Place people physically closer • Replace documents with conversations and whiteboards • Reduce time from decision to feedback • Make user experts available to team • Work incrementally (Cockburn & Highsmith, 2001)

15. 1 - Place people physically closer • Foosball • Warrooms • Common areas

16. Closeness • Interactions tend to require more effort when the participants work in physically distant locations (Seaman & Basili, 1997). • “…continuous dialogue within a close space generates a problem-solving bond…” (Bailey, 2004).

17. Dot com? • “The new building … has plenty of natural light and places for spontaneous discussions. A foosball table in the second-floor lounge has already become a popular venue for brainstorming and blowing off steam. … And chalkboards are everywhere, even in the outdoor atrium.” (McDonald , 2005)

18. Physicists! • “…for more than 30 years, the particle physicists have been eating at the same table, the astrophysicists at another, and the mathematicians at a third. So what did he advise us? No long tables. We want people to talk to each other.” (McDonald , 2005)

19. Closeness by design • "...having development teams reside in their own large room...had significantly higher productivity and shorter schedules... The teams reported high satisfaction about their process and both customers and project sponsors were similarly highly satisfied." (Teasley, et al, 2002)

20. Radical collocation • "Teams in these warrooms showed a doubling of productivity. Why? Among other things, teams had easy access to each other for both coordination of their work and for learning, and the work artifacts they posted on the walls remained visible to all." (Teasley, et al, 2000)

21. Osmotic communication • During radical collocation, communication travels through osmosis. • People ask more questions • People overhear important conversations (Cockburn, 2002)

22. 2 – Conversations & whiteboards • Face-to-face conversations • Rich communication • Feedback

23. Closeness by coincidence • Xerox representatives would "gather in common areas, like the local parts warehouse, hang around the coffee pot, and swap stories from the field." (Brown & Gray, 1995)

24. Coffee breaks • “I can’t count the number of times that new solutions have been found because of a chance meeting during a coffee break.” (Bailey, 2005)

25. Feedback in small groups • Having more participants in software meetings makes interactions more effort-intensive. (Seaman & Basil, 1997)

26. Feedback in very small groups • Discussion with peers was more used and more valuable than documentation and formal inspections (Kraut & Streeter, 1995). • Pair testing with developers (Kohl, 2004).

27. Business justification • Coordination and communication correlate with higher team performance and product quality. (Sawyer & Guinan, 1998)

28. 2 – Conversations & whiteboards • “Whiteboards” can be • big visible charts • information radiators • index cards • sticky notes • lava lamps • Designing closeness by coincidence (Cockburn, 2002; Van Tongeren, 2003; Cockburn, 2004; Marick, 2005)

29. Information radiators • "These communal workrooms encourage greater visibility, prominently displaying story status... Bug status, outstanding issues and the team calendar are also posted“ (Morales, 2003). • Just as heating ducts blow air into a room, posters radiate information into the room (Cockburn, 2002).

30. Key elements • Centrally located • Important information only • Easy to read • Not used to assign blame • Inspires informal communication (Van Tongeren, 2003)

31. Information radiator in XP (Bossavit, 2003)

32. Big Visible Chart in XP (Jeffries, 2004 - http://www.xprogramming.com/xpmag/BigVisibleCharts.htm)

33. Lava lamps (build reports) (Clark, 2004; Clark, 2004b; Marick, 2005)

34. Not just for agile methodologies • The essence of good design is facilitating coordination among developers (Herbsleb & Grinter, 1999). • Warroom, information radiator, and daily meetings have been used on CMM Level 4 projects for the Department of the Navy (Keuffel, 2003).

35. 3 - Make user experts available • Feedback (before UAT or Beta) • User satisfaction • Pair testing with subject matter experts

36. Cost of fixing bugs

37. User satisfaction • User satisfaction is higher when the developers exceed communication expectations. (Hornik, et al, 2003)

38. Time with users • “I recommend developers spend time actually doing the job of the user… Not only do developers continue to gain more information and insight but they also build relationships with the end-users.” (Bailey, 2005)

39. 4 - Work incrementally • Shorter releases • Simplicity (Risk-based) • Start early • Talk with developers often • Much automated testing • Some manual testing (Crispin, 2003)

40. Automated acceptance testing • Pair programming of test scripts (Crispin, 2003). • Automate something useful quickly (Faught & Bach, 2005).

41. Some functional test tools • FIT : define acceptance tests in HTML tables • FitNess : tests defined in a Wiki • Selenium : web testing inside the browser

42. Manual testing • Automation isn’t always the answer (Crispin, 2003). • Will the tests be reused? What is the cost of maintenance (Marick, 1998). • Exploratory testing by a subject matter expert (Kaner, 1988; Pettichord, 2003).

43. Review of methods • Reduce cost of moving information • Place people physically closer • Replace documents with conversations and whiteboards • Reduce time from decision to feedback • Make user experts available to team • Work incrementally (Cockburn & Highsmith, 2001)

44. Tips for testers on agile teams • Reduce cost of moving information • Be close with developers • Big visible test metrics • Reduce time from decision to feedback • Be close with users • Risk-based automated & exploratory testing

45. Agile tips for all teams • Increase quality of information • Be close with developers, even if you are clarifying documentation • Big visible test metrics, even if you have a defect tracking system • Increase quality with feedback • Be close with users, even if you are clarifying documentation • Risk-based automated & exploratory testing

46. Thank you!

47. References • Bailey, P. M. (2004). A formula for successful peer reviews. Better Software, 6(9), 14-16. • Bailey, P. M. (2005). Creative license. Better Software, 7(3), 18-23. • Bossavit, L. (2003) Information radiator. Posted April 10, 2003. Retrieved from http://www.ayeconference.com/wiki/scribble.cgi?read=InformationRadiator on March 25, 2005. • Brown, J. S. & Gray, E. S. (1995). The people are the company. Fast Company, 1(1), 78-81. • Clark, M. (2004). Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Apps. Raliegh, NC: Pragmatic Bookshelf. • Clark, M. (2004b). Bubble, bubble, build's in trouble. Posted August 26, 2004. Retrieved from http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/Devices/BubbleBubbleBuildsInTrouble.rdoc on March 25, 2005.

48. References • Cockburn, A. & Highsmith, J. (2001). Agile software development: The people factor. IEEE Computer, 34(11), 131-133. • Cockburn, A. (2002). Agile Software Development. Boston, MA: Addison Wesley. • Cockburn, A. (2004). What the agile toolbox contains. CrossTalk, 17(11), 4-7. • Cohn, M. (2003). An introduction to scrum. Software Quality Association of Denver. Denver, Colorado, April 8, 2003. • Cohn, M. (2003b). The task board. Posted September 29, 2003. Retrieved from http://www.mountaingoatsoftware.com/taskboard.php on March 25, 2005. • Crispin, L. (2003). XP testing without XP: Taking advantage of agile testing practices. Methods & Tools, 11(2), 2-9.

49. References • Faught, D. & Bach, J. (2005) Not your father’s test automation: An agile approach to test automation. Stickyminds.com. Posted January 7, 2005. Retrieved from http://www.stickyminds.com/sitewide.asp?sid=1&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28faught%29%2A&sidx=4&sopp=10&ObjectId=8392&Function=DETAILBROWSE&ObjectType=COL on April 4, 2005. • Herbsleb, J. D., & Grinter, R. E. (1999). Architectures, coordination, and distance: Conway’s law and beyond. IEEE Software, 16(5), 63-70. • Hornik, S., Chen, H., Klein, G., & Jiang, J. J. (2003). Communication skills of IS providers: An expectation gap analysis from three stakeholder perspectives. IEEE Transactions on Professional Communication, 46(1), 17-34. • Jeffries, R. E. (1999). Extreme testing. Software Testing and Quality Engineering Magazine, 1(2), 23-26.

50. References • Jeffries, R. E. (2001). What is extreme programming? Retrieved from http://www.xprogramming.com/xpmag/whatisxp.htm on March 23, 2005. • Jeffries, R. E. (2004). Big visible charts. Retrieved from http://www.xprogramming.com/xpmag/BigVisibleCharts.htm on March 25, 2005. • Jeffries, R. E. (2005). XP questions and answers. Retrieved from http://www.xprogramming.com/qa/xp_q_and_a_QA.htm on March 25, 2005. • Kaner, C. (1988). Testing Computer Software. New York, NY: McGraw Hill. • Kraut, R. E. & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM, 38, 69-81. • Keuffel, W. (2003). Leveraging expertise. Software Development, 11(2), 56.