Practice: Independent Testing
The Independent Testing practice is targeted for more mature test organizations that are looking for a reliable, reproducible way of testing their products.
Purpose

In many cases, the companies which need a more formal approach to testing are developing safety-critical systems, such as air traffic control, missile guidance, or medical delivery systems, where a failure can harm people.

But the criticality of a system is not necessarily immediately obvious. It's likely that the impact of a defect could cause the business using the software considerable expense in lost revenue and, possibly, legal expenses. In this information age, with increasing demands on providing electronically delivered services over the Internet, many information systems are now considered mission-critical. That is, companies cannot fulfill their functions and they experience massive losses when failures occur.

A continuous approach to quality, initiated early in the software lifecycle, can significantly lower the cost of completing and maintaining your software. This greatly reduces the risk associated with deploying poor-quality software.

How to read this practice

The best way to review a practice is to adopt a multi-prong approach: Use different perspectives driven by artifacts, activities, test cycles, or roles, and shift among them when your focus changes from what you need to produce to how or when an activity is performed.

  • Artifacts: Start with the main work products, Test Artifacts. Move to the secondary set of artifacts, and decide which ones are important to you and your organization.
  • Activities: Analyze the main Test Iteration [Template], which gives an overview of all of the activities performed as part of a typical test cycle. Drill down into each activity to better understand the tasks and artifacts employed.
  • Test lifecycle: Depending on the role that you play in the test organization, you might want to focus only on specific aspects of testing. See Test Tasks.

Review the guidelines, concepts, and, if applicable, tool-related guidance.

Additional Information
For more information on this practice,  see the practice resource page on IBM® DeveloperWorks®.
Relationships