Five essential elements are required for successful software testing. If any one of the five is missing or inadequate, the test effort will most likely fall far short of what could otherwise be achieved. Exploring these five essentials can help improve the effectiveness and efficiency of any software testing program.
Here are the five essential test elements:
The purpose of testing is to find defects, not to pass easy tests. A test strategy basically describes which types of testing seem best to do, the order in which to perform them, the proposed sequence of execution, and the optimum amount of effort to put into each test objective to make testing most effective. A test strategy is based on the prioritized requirements and any other available information about what is important to the customers.
Because there are always time and resource constraints, a test strategy faces up to this reality and outlines how to make the best use of whatever resources are available to locate most of the worst defects. Without a test strategy, a software company is apt to waste time on less fruitful testing and miss using some of the most powerful testing options. The test strategy should be created at about the middle of the design phase, as soon as the requirements have settled down.
A testing plan is simply that part of a project plan that deals with the testing tasks. It details who will do which tasks – starting when, ending when, taking how much effort and depending on which other tasks. It provides a complete list of all the things that need to be done for testing, including all the preparation work during all of the phases before testing. It shows the dependencies among the tasks to clearly create a critical path without surprises. The details of a testing plan can be filled in starting as soon as the test strategy is completed. Both the test strategy and testing plan are subject to change as the project evolves. If modification is necessary, start with the strategy first, and then the testing plan.
Test cases (and automated test scripts if called for by the strategy) are prepared based on the strategy which outlines how much of each type of testing to do. Test cases are developed based on prioritized requirements and acceptance criteria for the software, keeping in mind the customer’s emphasis on quality dimensions and the project’s latest risk assessment of what could go wrong. Except for a small amount of ad hoc testing, all test cases should be prepared in advance of the start of testing.
There are many different approaches to developing test cases. Test case development is an activity performed in parallel with software development. It is just as difficult to do a good job of coming up with test cases as it is to program the system itself. In addition to figuring out what steps to take to test the system, the requirements and business rules need to be known well enough to predict exactly what the expected results should be. Without expected results to compare to actual results, it will be impossible to say whether a test will pass or fail. A good test case checks to make sure requirements are being met and has a good chance of uncovering defects.
In addition to the steps to perform to execute test cases, there also is a need to systematically come up with test data to use. This often means sets of names, addresses, product orders, or whatever other information the system uses. Since query functions, change functions and delete functions are probably going to be tested, a starting database of data will be needed in addition to the examples to input. Consider how many times those doing the testing might need to go back to the starting point of the database to restart the testing, and how many new customer names will be needed for all the testing in the plan. Test data development is usually done simultaneously with test case development.
Obviously a place and the right equipment will be needed to do the testing. Unless the software is very simple, one PC will not suffice. A system with all of the components of the system on which the software eventually will be used is best. Test environments may be scaled-down versions of the real thing, but all the parts need to be there for the system to actually run.
Building a test environment usually involves setting aside separate regions on mainframe computers and/or servers, networks and PCs that can be dedicated to the test effort and that can be reset to restart testing as often as needed. Sometimes lab rooms of equipment are set aside, especially for performance or usability testing. A wish list of components that will be needed is part of the test strategy, which then needs to be reality checked as part of the test planning process. Steps to set up the environment are part of the testing plan and need to be completed before testing begins.
For those who want to improve their software testing or those who are new to software testing, its is essential to make sure you have all five of these testing elements in place. Many testers struggle with inadequate resources, undocumented requirements and lack of involvement with the development process early in the software development life cycle. Pushing for all five of the essentials and proper timing is one way to significantly improve the effectiveness of testing as an essential part of software engineering.