InfoQ

News

Put People First in Agile Distributed Testing

Posted by Deborah Hartmann on Sep 07, 2006 07:50 AM

Community
Agile
Topics
Teamwork ,
Customers & Requirements
Tags
XP ,
Testing ,
Distributed Teams
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.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Extreme Testing or Extremely Dangerous Testing? by John Tyson Posted Sep 8, 2006 3:04 PM
  1. 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.

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.