- Overview
- State of the Practice
- Impact on Testing
- Solutions to the Challenge
- Solution Impediments
- Guidelines for Success
- Plan of Action
This chapter is from the book
This chapter is from the book
This chapter is from the book
Solutions to the Challenge
Control the Scope of Testing
It only makes sense that when it comes to testing, you should not bite off more than you can chew. A good way to define the scope of testing is to relate test objectives to system or project objectives. There should be a one-to-one correspondence between what the system should do or be and what should be tested. It might take many tests to validate a system objective, but all tests should point back to a major test objective.
Control Management Expectations
We need to manage expectations in all project areas, but especially in testing. When pressured into a last-minute “rush job,” some testers estimate what percentage of a complete test can be performed and ask management, “Which parts do you want me to test?” This can be a shock to some managers who expect you to work through the night to test that ultra-important last-minute project. However, it does raise awareness that testing is not just a quick, afterthought job.
Base Test Cases on an Independent Set of Criteria
One of the most common complaints from testers under pressure is that there are no defined requirements. The result of having no requirements is that testers (and everyone else, for that matter) are left to their own devices in determining what the system is supposed to do. The chances are slim that everyone’s expectations will be the same. You need some kind of evaluation criteria to determine what to test and whether or not the test was successful. If you have no evaluation criteria and no way to measure the results, why bother with testing a specific function? With limited time available, you should focus testing on those functions that can be measured.
Perform Risk Assessments
With only so much time available for testing, you need some way to rank testing activities. Risk is the perfect criteria for prioritizing items to be tested, test cases to be performed, and the like. There are several risk assessments in the public domain that address risk from the project perspective. You can perform risk assessment on an informal basis using likelihood of failure and impact of failure as ranking criteria.
Reuse Your Testware
When time available for test planning and testing is at a premium, you should design test products (such as test plans, test scripts, and test data) that can be used in future tests of the same software, or as templates for future projects. When creating reusable testware, make sure the scripts are modular and that standards exist for the format of test products. Also, take care to keep the test scripts free of detailed test data. The advantage of keeping the test scripts and test data separate is that you have fewer scripts to maintain, plus you can design many different tests simply by combining scripts and data in different ways. In addition, modular test products greatly facilitate the transition to automated testing.
In Figure 8.2, three simple test scripts are combined in different ways. The three scripts are add a customer, change a customer, and delete a customer. These three scripts become the source for several tests. This is a very different approach from writing a single script for testing all three functions.
)
Figure 8.2 Modular Test Script Usage.
Estimate the Testing Effort Based on Measurable Criteria
Instead of using near-random time estimates of the number of weeks required for testing, base your estimates on the number of test cases, system size, testable requirements, and other measurable criteria. Then you will have information on hand to support your estimates. Try tracking test times and using the historical information as a basis for future estimates. Testable requirements are a good basis for early estimates because they don’t deal with lines of code, number of modules, and so forth.
Use Automation
This solution appears last in this list to emphasize the point that test automation is important but not the only option in dealing with heavy work loads. The temptation is to bring in a test tool at a crisis moment, but this is seldom effective—in reality, more than a tool solution is usually required. When used as part of an overall testing process, with trained people, automated test tools can be a great help to testers and developers alike. A test that might take days to perform can be performed in minutes with an automated test tool.