LogiGear One-Page Test Plan - Web Service Testing

It is often a challenge for testing groups to communicate their needs to other members of the software development team. The myriad test types, the testing sequence, and scheduling considerations can be overwhelming when not organized into a comprehensible plan that others can read at a glance. The LogiGear One-Page Test Plan is a distillation of test types, test coverage, and resource requirements that meets this need. The LogiGear One-Page Test Plan is task oriented. It lists only testing tasks—because some members of the product team may not be interested in ''testing approach," "features not to be tested," and so on. They just want to know what is going to be tested and when. Because one-page test plans are so easy to reference, if they are adequate for your process, they are less likely to be disregarded by impatient team members.

The LogiGear One-Page Test Plan does not require additional work. It is simply a distillation of the standard test-plan effort into an easily digestible format. The LogiGear One-Page Test Plan is effective because it details the testing tasks that a testing team should complete, how many times the tasks should be performed, the amount of time each test task may require, and even a general idea of when the tasks should be performed during the software development process.

The LogiGear One-Page Test Plan is easy to reference and read. Twenty-page test plans are regularly ignored throughout projects, and 100-page test plans are rarely read. One-page test plans, on the other hand, are straightforward and can easily be used as negotiating tools when it comes time to discuss testing time and coverage—the usual scenario being, "What testing time can be cut?" The test team can point to test tasks listed on a one-page test plan and ask, "Are we prepared to accept the risk of not performing some of these tests to their described coverage?"

Developing a One-Page Test Plan
The process of completing a one-page test plan is described in the following steps.

Step 1—Test Task Definition
Select the test types that are required for the project. Decisions should be based on the unique functionality of the system under test. Discussions with developers, analysis of system components, and an understanding of test types are required to accurately determine which test types are needed.

Step 2—Task Completion Time
Calculate the time required to perform the tests. The most difficult aspect of putting together a test plan is estimating the time required to complete a test suite. With new testers, or with tests that are new to experienced testers, the time estimation process involves a lot of guesswork. The most common strategy is divide and conquer. That is, break the tasks down into smaller subtasks. The smaller subtasks are easier to estimate. You may then sum up from those. As you gain experience, you miss fewer tasks and you gain a sense of percentage of tasks that you typically miss so you can add an n percent for contingency or missing-tasks correction.

Informed estimates may also be arrived at if testing tasks are similar to those of a past project. If time records of similar past testing are not available, estimates may be unrealistic. One solution is to update the test plan after an initial series of tests has been completed. A 20 percent contingency or missing-tasks correction is included in this example. As testing progresses, if this contingency does not cover the inevitable changes in your project's schedule, the task completion time will need to be renegotiated.

Step 3—Placing the Test Tasks into Context
Once the task list has been developed and test times have been estimated, place the tasks into the context of the project. The development team will need to supply a build schedule. Determine how many times tests will be run during development. For example, documentation testing may only be performed once, or it may be reviewed once in a preliminary phase and then again later after all edits are complete. A complete cycle of functionality tests may be executed once per development phase, or possibly twice. Acceptance tests are run on every build. Often, a full bug regression occurs only once per phase, though partial regression tests may happen with each build.

Step 4—Table Completion
Finally, multiply the numbers across the spreadsheet. Total the hours by development phase for an estimate of required test time for the project. Add time for management, including test-plan writing/updating, test-case creation, bug database management, staff training, and other tasks that are needed for the test team and for completion of the project.

Step 5—Resource Estimation
Take the total number of hours required for the alpha phase, divide that by the total number of weeks in the alpha phase, and then divide that by 30 hours per week. That gives you the number of testers needed for that week. For example, if you need total testing hours for alpha of 120, a 4-week alpha phase, and testers have a third-hour testing week, your project requires only one tester [(120 ÷ 4) ÷ 30 = 1]. Apply this same process to arrive at estimates for the beta phase and project management also. Note that I use only 30-hour testing week for a full-time tester because by experience, know that the other 10 (overhead) hours are essentially used for meeting, training, defect tracking, researching, special projects, and so on.

LogiGear One-Page Test Plan
The LogiGear One-Page Test Plan can be invaluable in negotiating testing resource and testing time requirements with members of the product team. Figure provides an example of the LogiGear One-Page Test Plan.

LogiGear One Page Test Plan

LogiGear One Page Test Plan


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Web Service Testing Topics