Agile Zone is brought to you in partnership with:

An agile software developer that likes cake and Continuous Delivery Steve is a DZone MVB and is not an employee of DZone and has posted 9 posts at DZone. You can read more from them at their website. View Full User Profile

Testing Antipattern: Release Testing

03.12.2013
| 2699 views |
  • submit to reddit
Release testing is a flawed strategy that discourages product quality

In many organisations, an agile product team will contain co-located developers and testers in accordance with the first principle of the Agile Manifesto, which states that ”our highest priority is to satisfy the customer through early and continuous delivery of valuable software“, supported by Lisa Crispin affirming ”a team commitment to quality, a team responsible for testing” and Kevlin Henney arguing that ”if defects are a source of waste, and testing is one way of uncovering them, then having a phase at the end of the development lifecycle labeled testing is a sure way of ensuring poor quality“. By continuously testing new product features mid-development we can explore assumptions and challenge business value in addition to finding defects, leading us to Elizabeth Hendrick’s commonly-held view:

Testing is an activity, not a phase


However, while many product teams boast co-located developers and testers, it is not uncommon for an organisational antipattern to emerge - Release Testing, in which detailed functional and/or integration testing scenarios are executed post-commit and pre-production by a siloed release testing team, and then fed back to the product team. This approach has a number of fatal flaws:

  • Increased lead times due to slower rate of feedback
  • Increased lead times due to testing occurring on the critical path to release
  • Product team abstracted away from the consequences of defects
  • Release testing team abstracted away from contributing to the product

While it is important to note Dr. Deming’s argument that no team or individual is to blame for such deficiencies, and that we can improve lead times by reducing batch sizes, it is the separation of authority from responsibility that is especially worrying in this instance – our product team is not incentivised to care about quality, while our release testing team is not incentivised to care about product features. By dissolving our release testing team into our product team, we can improve our product lead times and reap the benefits of our entire testing team being involved in the product development process.

Published at DZone with permission of Steve Smith, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: