Put People First in Agile Distributed Testing

Posted by Deborah Hartmann Preuss on Sep 07, 2006

Sections

Process & Practices,

Architecture & Design

Topics

Teamwork ,

Customers & Requirements ,

Agile

Tags

Testing ,

Distributed Teams ,

XP

Baiju Joseph's new article on StickyMinds, Building an Effective Test team for "Distributed Agile", argues that, in order to build an effective testing team for distributed Agile, we need to focus on individuals and interactions over processes and tools. Based on the author's experience in setting up distributed agile testing teams, he lists numerous criteria that must be met in order to reach this goal.

Joseph writes about the Extreme Programming (XP) model, in which developers write unit tests, 100% of which are automated, complemented by Acceptance Tests (Customer Tests) written based on User stories. Test engineers write the Acceptance Tests with the help of customers (in some organizations customers themselves write the acceptance tests for some of the top priority features).  He calls this combination of practices "Extreme Testing".

Many software development organizations in India have started moving towards agile development methodologies as it helps the organizations to respond to changing business environments very quickly and provide better customer satisfaction.  Joseph writes "In today’s business environment it is not really the big that win the battles rather it’s the fast that win the battles over the slow." Time to market is very important in today’s fast changing world. Agile development helps us to deliver the value to the customer rapidly through a divide and conquer approach and prioritization. The right 20% of effort will yield 80% of the value, so we do a lot of those in Agile development and Extreme Testing.

Joseph's position is that Extreme testing is the best way to survive extreme change. Basic values like open communication, tight feedback loop in the features teams, simplicity and courage are the key in extreme testing. And he notes that, unlike traditional approaches, in an XP project, testing isn’t a final hurdle it is a journey along the full development cycle.  To build an effective testing team for Distributed Agile,  tool reporting is not sufficient for team communication - people must be communicating via higher-bandwidth mechanisms, demos must be frequent to keep confidence high among different parts of the team, travel is recommended.  Human communication and feedback is very important.

Baiju Joseph is a senior quality assurance manager with Ariba Technologies, Bangalore. Prior to Ariba, Baiju worked with Novell Software System test team and the Ministry of Information & Broadcasting.

1. Back to top

   Extreme Testing or Extremely Dangerous Testing?

   by John Tyson

   That was my first thought when I read "...developers write unit tests, 100% of which are automated, complemented by Acceptance Tests (Customer Tests) written based on User stories."
   
   This makes it sound like the only testing is Unit testing and UAT. But after reading the source article, the author did state "There is one more important type of testing..." The keywords are "one more." A common misconception about Agile development is that since developers are always unit testing (and sometimes using the "test first" approach), there is no need for professional testers. A big mistake.
   
   Misc Thoughts/Observations/Ramblings
   Yes, communications is very important, perhaps more so in Agile environments, since documentation may be sparse. Given that one of the tenants of Agile is frequent, face-to-fact communications, this would seem to be at odds with outsourcing whenever that outsourcing involves geographic separation. If you include different time zones, languages and culture, it makes it even more contradictory (Agile and Outsourcing or "Distributed Agile").
   
   There are a couple of advantages to having automated unit tests, that aren't usually mentioned. The first is that you can be fairly sure that the dev has run them as opposed to just taking their word.
   
   The second benefit is that coverage analysis could be performed on the unit tests.

   Reply

• Older >