Other Best Practices for Testing


Several best practices, when combined with iterative development, will help achieve optimal results from testing. Note that most of these best practices are applicable regardless of the lifecycle model being used.

Involve Testing Expertise During Requirements Elicitation

Earlier, this chapter explained how iterative development enables testing earlier in the project lifecycle. Even more benefits can be realized by involving testing expertise during the requirements elicitation activity. Obtaining the perspective of an experienced tester during requirements elicitation, before the requirements are finalized, helps the project in a number of ways. A tester can examine the requirements and do the following:

  • Is the requirement testable? Functional requirements (even supplemental ones) should be reviewed by someone with experience and expertise in testing. If the requirement is not easily tested, it will be difficult to prove that it is working. For example, a requirement that states "The system must be available 24 hours a day, 365 days a year" would take a full year to prove. If the requirement is written as a percentage of availability, such as "The system shall be available for use 99% of the time," it can be measured for short periods and extrapolated to longer periods.

  • Is the requirement subject to multiple interpretations? Consider the requirement from earlier in this chapter: "The system shall support a concurrent load of 500 users while maintaining a response time of less than 2 seconds." This requirement could be interpreted multiple ways. Viewed conservatively, you could interpret a "concurrent load of 500 users" as 500 users logging in and then idling. Viewed aggressively, you could interpret it as 500 users simultaneously performing a computationally intense function. A more plausible scenario might be as follows: "Out of 500 users, 10% will be logging in, 20% will be performing search functions, 10% will be logging out, 30% will be running reports, 20% will be browsing items, and 10% will be idle." Even this is a little vague; for example, what reports will 30% of the users be running? The point is to clearly and succinctly define the goal. Many requirements are written or stated by users who do not have expertise in this area, so they need guidance. This is one of the ways testers can add value early.

  • Getting testers involved in the requirements early gives them a "sneak preview" of what they need to test so that they can generate test ideas that will help them implement tests more rapidly as releases begin being produced.

Keep Testing Staff in the Loop

A common complaint heard from testing personnel involves changes to requirements and the project in general. As test planning takes shape, many artifacts are created that are tied to the requirements. If the requirements change, the artifacts tied to those requirements may need to change as well. Therefore, make sure that testing personnel are aware of any changes to requirements. If you are using an automated requirements management tool, this will be easier.

Replicate the Production Environment

Another important aspect of proper testing involves testing in an environment that mimics the production environment as closely as possible. If possible, the best arrangement is to test in the exact environment, including using the same machines, operating system, networking environment, and so on that will be used when the system is in production. In most cases, this is probably not possible. Therefore, a test environment must be created. It should be physically separate from the machines on which development is performed. It also must be carefully controlled to ensure that no changes to the operating system, hardware configuration, and so on, are made without being carefully documented.

Even if you believe you have created a testing environment that duplicates every possible aspect of the operational environment, you will probably find something that was overlooked when the system is placed into production. For this reason, it is a best practice to schedule some time for final testing on the actual operational environment before the new system is placed into production.

Testing Is Part of the Delivered Product

The customer that accepts delivery of the product should be assured that the product has been tested to meet its requirements. For requirements that have defects outstanding, these defects should be listed in the product's release notes. A process for reporting any new defects should be defined and communicated to the customer.




Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

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