| < Day Day Up > |
|
An excellent reference on the subject of software testing, Testing Computer Software [11] by Cem Kaner, contains 12 appendices describing some specific areas of testing (or testing domains) that a dedicated Test Team should always focus its time and effort on. Those 12 areas recommended by Kaner are as follows:
User-interface errors
Error handling
Boundary-related errors
Calculation errors
Initial and later states
Control flow errors
Errors in handling or interpreting data
Race conditions
Load conditions
Hardware errors
Source, version, and ID control errors
Testing errors
Professional testers generally create a series of test cases specific to the new application that will cover each of the test areas listed. Of course, the level of testing is usually constrained by both time and resources. Many times, some of these test domains are omitted in lieu of basic functional testing. Although I do not recommend omitting any of these areas, the reality of a corporate environment is that deadlines more often than not drive the delivery schedules, and these organizations frequently pay dearly for the tradeoff between a more thorough testing process or faster project delivery.
Instituting an SPMO in an organization and subsequently implementing SEP as part of a software program management initiative will help prevent such mistakes. Effective software program management will enable the organizational project teams to begin establishing more realistic, process-driven schedules. In the long run, instituting this change will make a big difference on the organization’s bottom line. Now, let’s begin with a review of the testing domains that should be a part of any product test plan. Remember, the purpose of this section of the book is to help you, as the Program Lead, be aware of all of the test issues and areas that could cause a program initiative to fail. What follows in the next few sections is not intended to be a crash course in formal testing of a product.
| < Day Day Up > |
|