InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Integrating Testers on to the Agile Team

Posted by Mark Levison on May 13, 2008

Sections
Process & Practices
Topics
Agile ,
Collaboration ,
Adopting Agile
Tags
Testing ,
Pair Programming

Integrating Testers into the team is an oft repeated Agile mantra, but we don't spend much time thinking about what it means or how to do it.

What is the role of testers on the team? To:

  • Help define and elicit the acceptance criteria (or requirements)
  • Provide information about quality not to find bugs via automated tests, exploratory tests, ...
  • Work with the customer to identify risks
  • Put more testing effort into the areas where the developers tests (unit and integration) are weakest. For instance if we know that the team has test the Data Layer well, but the GUI layer has been harder to Unit Test then the testers should focus more effort on the GUI layer.

Compiled from (Cem Kaner, Johanna Rothman (pdf), and Jonathan Kohl).

Testing as part of an Agile team is quite different experience than most are used to. As Jonathan Kohl, co-founder of Kohl Concepts, notes: "The difference is that on an agile project, we find the important bugs faster. We are more involved with testing throughout development. Now that the developers are doing rigorous work themselves with solid automated unit tests, the products I test are much more robust."

Antony Marcano, Independent agile testing consultant, talks about the lessons he's learned:

  • Writing acceptance tests requires collaboration: preferably Customer, Tester & Programmer.
  • Testers and Developers should nurture each other's skills.
  • Testing tasks should be part of sprint backlog and not a separate Test Plan
  • Use Exploratory Testing to generate feedback
  • Before fixing bugs write automated tests that reproduce them.

On Simon Baker's team, co-founder of Energized Work, the developers write most of the acceptance tests. This frees the testers to do Exploratory Testing, work with the Product Owner to connect with the customer and help the team understand the users (not just the stories). Developers work on vertical slices (small parts of stories) that satisfy specific acceptance criteria. When the slice is complete the developer works with the tester to explore the slice and understand the acceptance test. The team treats defects as a stop the line event. Either the developer fixes it in the next slice or if its no longer under development a defect task is created. The defect task becomes the highest priority task for the team. Testers find that although they use the same skills, they spend a lot more time collaborating with peers and less time filing bugs.

  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

No comments

Watch Thread Reply

Educational Content

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.