Communication tools and skills for software testers on agile teams

Tim Van Tongerenwww.testgeek.com

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)

Benefits of agile development

Reduce cost of moving information

Reduce time from decision to feedback

(Cockburn & Highsmith, 2001)

Some agile methodologies

Extreme Programming (XP)

Scrum

Crystal

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)

Extreme programming

Pair programming & test-driven development (TDD)

100 % unit tested code in each build

Small releases occurring often

Customer tests

(Jeffries, 2001)

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)

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)

Scrum’s task board

(Cohn, 2003b)

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)

Crystal categories

(Cockburn, 2002)

Criticality (Defect causes loss of …)

(L) Life L6 L20 L40 L80

(E) Essential money E6 E20 E40 E80

(D) Discretionary money D6 D20 D40 D80

(C) Comfort C6 C20 C40 C80

1-6 -20 -40 -80

Number of people

Sweet spots of agile

2-8 people in one room

Onsite usage experts

One month increments

Fully automated tests

Experienced developers

(Cockburn, 2002)

Test-driven development

Even with 100% unit tested code, we still might have

Incompleteness Inconsistency Ambiguity Incorrectness

Methods of agile development

Reduce cost of moving information1. Place people physically closer2. Replace documents with

conversations and whiteboards

Reduce time from decision to feedback

3. Make user experts available to team4. Work incrementally

(Cockburn & Highsmith, 2001)

1 - Place people physically closer

Foosball

Warrooms

Common areas

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).

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)

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)

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)

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)

Osmotic communication

During radical collocation, communication travels through osmosis.

People ask more questions

People overhear important conversations

(Cockburn, 2002)

2 – Conversations & whiteboards

Face-to-face conversations

Rich communication

Feedback

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)

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)

Feedback in small groups

Having more participants in software meetings makes interactions more effort-intensive.

(Seaman & Basil, 1997)

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).

Business justification

Coordination and communication correlate with higher team performance and product quality.

(Sawyer & Guinan, 1998)

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)

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).

Key elements

Centrally located Important information only Easy to read Not used to assign blame Inspires informal communication

(Van Tongeren, 2003)

Information radiator in XP

(Bossavit, 2003)

Big Visible Chart in XP

(Jeffries, 2004 - http://www.xprogramming.com/xpmag/BigVisibleCharts.htm )

Lava lamps (build reports)

(Clark, 2004; Clark, 2004b; Marick, 2005)

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).

3 - Make user experts available

Feedback (before UAT or Beta)

User satisfaction

Pair testing with subject matter experts

Cost of fixing bugs

User satisfaction

User satisfaction is higher when the developers exceed communication expectations.

(Hornik, et al, 2003)

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)

4 - Work incrementally

Shorter releases Simplicity (Risk-based) Start early Talk with developers often

Much automated testing Some manual testing

(Crispin, 2003)

Automated acceptance testing

Pair programming of test scripts (Crispin, 2003).

Automate something useful quickly (Faught & Bach, 2005).

Some functional test tools

FIT : define acceptance tests in HTML tables

FitNess : tests defined in a Wiki

Selenium : web testing inside the browser

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).

Review of methods

Reduce cost of moving information1. Place people physically closer2. Replace documents with

conversations and whiteboards

Reduce time from decision to feedback

3. Make user experts available to team4. Work incrementally

(Cockburn & Highsmith, 2001)

Tips for testers on agile teams

Reduce cost of moving information1. Be close with developers2. Big visible test metrics

Reduce time from decision to feedback

3. Be close with users4. Risk-based automated & exploratory

testing

Agile tips for all teams

Increase quality of information1. Be close with developers, even if

you are clarifying documentation2. Big visible test metrics, even if you

have a defect tracking system Increase quality with feedback

3. Be close with users, even if you are clarifying documentation

4. Risk-based automated & exploratory testing

Thank you!

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.

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.

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.

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.

References

Kohl, J. (2004). Pair testing: How I brought developers into the test lab. Better Software, 6(1), 14-16.

Marick, B. (1998). When should a test be automated? International Software Quality Week. San Francisco, California, May 26-29, 1998. Retrieved from http://www.testing.com/writings/automate.pdf on April 4, 2005.

Marick, B. (2001). Agile methods and agile testing. Software Testing and Quality Engineering Magazine, 3(5). Retrieved from http://www.testing.com/agile/agile-testing-essay.html on March 23, 2005.

Marick, B. (2005). Honeybees, blimps, and lava lamps. Better Software, 7(2), 8.

McDonald, D. (2005). The blackberry brain trust. Wired, 13(1), 127-129.

Morales, A. W. (2003). Extreme quality. Software Development, 11(2), 8.

References Pettichord, B. (2003). Where are the testers in XP?

Stickyminds.com Post January 27, 2003. Retrieved from http://www.stickyminds.com/sitewide.asp?sid=1&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28testers+in+XP%29%2A&sidx=0&sopp=10&ObjectId=6217&Function=DETAILBROWSE&ObjectType=COL on May 13, 2003.

Sawyer, S. & Guinan, P. J. (1998). Software development: Process and performance. IBM Systems Journal, 37(4), 552-569.

Seaman, C. B. & Basili, V. R. (1997). Communication and organization in software development: An empirical study. IBM Systems Journal, 36(4), 550-563.

Teasley, S., Covi, L, Krishnan, M. S., & Olson, J. S. (2000). How does radical collocation help a team succeed? Proceedings of the 2000 ACM conference on Computer supported cooperative work, 339-346.

Teasley, S., Covi, L, Krishnan, M. S., and Olson, J. S. (2002). Rapid software development through team collocation. IEEE Transactions on Software Engineering, 28(7), 671-683.

Van Tongeren, T. (2003). How we got them to read the writing on the wall. Software Testing and Quality Engineering Magazine, 5(6), 12-14.