Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

The Agile End Game


Final Testing

Repeat after me: The release iteration is not a testing phase. The release iteration is not a testing phase. The release iteration is not a testing phase. The majority of testing occurs throughout the project in the form of confirmatory testing performed by the development team itself, or investigative testing performed by independent testers to catch any pernicious bugs that slip through the cracks (again see "Agile Testing Strategies," January 2007). Having said that, as indicated in Figure 2, you will still do some testing during the release iteration.

  • First, the independent investigative testing efforts to verify the output of the last construction iteration still need to occur. Some of the defect stories will be addressed during the release iteration, although many will be put on the work items stack for "Release N+1" of the system.
  • Second, some release-specific testing efforts, in particular pilot/beta testing where you deploy your system to a subset of your end-user community, may occur. You may also need to do true acceptance testing where authorized project stakeholders work with the system and decide whether it truly meets their needs.

Although "agile acceptance testing," also known as "customer testing," is a part of the confirmatory testing efforts that occur throughout a project, you may still need to perform a final release acceptance testing effort where people outside of the team are involved. Testing of your installation/deployment scripts is particularly important during the release iteration because you don't want any surprises when you actually try to deploy.

Don't get me wrong, the activities that I've described as release testing in Figure 2 can and should be done much earlier in the lifecycle. My point is that these forms of testing are particularly pertinent during the release iteration to assure your stakeholders that your system is truly ready for deployment. Many organizations require that a system be put through some sort of formal sign-off process before deployment regardless of the development paradigm. The good news is that the increased focus on quality and testing by agile teams streamlines this effort.

[Click image to view at full size]

Figure 2: Testing during the release iteration.

More Than You Think to Releasing a System

The common rhetoric within the agile community is that our software is always "production ready" because we deliver tested, working software at the end of each construction iteration. This is a good thing, and for simple systems, you might be able to simply copy the software onto a production server and declare success. In more complicated situations, you may need to:

  • Hold acceptance reviews with stakeholders.
  • Finalize relevant documentation.
  • Translate the UI and supporting documentation into other languages.
  • Finalize and validate testing efforts.
  • Create physical collateral, such as manuals and installation media, for disbursement to end users and your operations and support (O&S) staff.
  • Ship physical collateral and hardware.
  • Replace and/or install physical assets, including workstations, servers, and network components.
  • Replace existing software with new versions.
  • Update existing databases, including any relevant data migration and/or database schema changes.
  • Update any O&S test environments used to simulate production problems.
  • Train end users and O&S staff.
  • Run the existing system in parallel with the new release during a defined transition period.
  • Fix any discrepancies discovered during the transition period.
  • Train the team that is taking over maintenance and evolution of the system.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.