Purpose

In many respects, the Test discipline acts as a service provider to the other disciplines. Testing focuses primarily on evaluating or assessing product quality, using a number of core practices:

  • Find and document failures in the software product: defects, problems.

  • Advise management on the perceived quality of the software.

  • Evaluate the assumptions made in design and requirement specifications through concrete demonstration.

  • Validate that the software product works as designed.

  • Validate that the requirements are implemented appropriately.

An interesting difference exists between Test and the other RUP disciplines: Essentially Test is tasked with finding and exposing weaknesses in the software product. To get the biggest benefit, you need a different philosophy or mindset than that used in the Requirements, Analysis and Design, and Implementation disciplines. Whereas those three disciplines focus on completeness, consistency, and correctness, the Test discipline focuses on what is missing, incorrect, or inconsistent.

A good test effort is driven by questions such as these:

  • How could this software break?

  • In what possible situations could this software fail to work predictably?

Test challenges the assumptions, risks, and uncertainty inherent in the work of other disciplines, and addresses those concerns using concrete demonstration and impartial evaluation. You want to avoid two potential extremes:

  • An approach that does not suitably or effectively chal-lenge the software and exposes its inherent problems or weaknesses.

  • An approach that is inappropriately negative or destructive ”adopting such a negative approach, you may find it impossible to ever consider the software product of acceptable quality. Taking such an approach can alienate the Test effort from the other disciplines.

Information presented in various surveys and essays states that software testing accounts for 30% to 50% of software development costs. It is, therefore, somewhat surprising to note that most people believe computer software is not well tested before it's delivered. This contradiction is rooted in a few key issues:

  • Testing software is very difficult. How do you quantify the different ways in which a given program can behave or misbehave?

  • Typically, testing is done without a clear methodology, creating results that vary from project to project and from organization to organization. Success is primarily a factor of the quality and skills of the individuals in the test team.

  • Productivity tools are either used inefficiently or not at all, which makes the laborious aspects of testing unmanageable. In addition to the lack of automated test execution, many test efforts are conducted without tools that let you effectively manage extensive Test Data and Test Results.

  • Flexibility of use and complexity of software make complete testing an impossible goal. Using a well-conceived strategy and appropriate tools can improve both the productivity and effectiveness of software testing.

High-quality software is essential to the success of safety-critical systems ”such as air traffic control, missile guidance, and medical delivery systems ”where a failure can harm people. These systems have to exhibit extremely high reliability and be tolerant to failure. The criticality of a typical Management Information System (MIS) may not be as immediately obvious, but it's likely that the impact of a defect could cause the business using the software considerable expense in lost revenue and possibly legal costs. In this information age, with increasing demands on providing electronically delivered services over the Internet, many MIS systems are now considered mission-critical; that is, when failures occur, companies cannot fulfill their functions and they experience massive losses.

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 of deploying poor-quality software and having to fix it in a subsequent release.



The Rational Unified Process. An Introduction
Blogosphere: Best of Blogs
ISBN: B0072U14D8
EAN: 2147483647
Year: 2002
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net