White papers > Software Test Plans

Page 2

	Write Your Software Testing Plan Today  Quickly adapt our test plan template to your project

Step Two: Outline the Test Suite

Once you have prioritized your QA goals, it is time to outline the system test suite. A test suite document is an organized table of contents for your test cases: it simply lists the names of all test cases that you intend to write. The suite can be organized in several ways. For example, you can list all the system components, and then list test cases under each. Or, you could list major product features, and then list test cases for each of those.

One of the best test suite organizations is to use a grid where the rows are types of business objects and the columns are types of operations. Each cell in the grid lists test cases that test one type of operation on one type of object. For example, in an e-commerce system, a Product business object would have test cases for each of the following operations: adding a product to the system, listing or browsing products, editing products, deleting products, searching products, and calculating values related to the product such as shipping cost or days-until-shipment. The next row an e-commerce test suite grid might focus on the Customer Order business object and have test cases for almost all the same operations.

The advantage of using an organized list or grid is that it gives you the big picture, and it helps you put your finger on any area that needs more work. For example, in the e-commerce grid, there might be a business object "Coupon." It is obvious that shoppers use coupons, but it is easy to forget to test the ability for administrators to create coupons. If it is overlooked, there will be a clearly visible blank space in the test suite document. These clear indications of missing test cases allow you to improve the test suite sooner, make more realistic estimates of testing time needed, and find more defects. These advantages allow the found defects to be fixed sooner and help keep management expectations in sync with reality, which helps keep the project out of crisis-management-mode.

How ReadySET Pro Helps

The ReadySET Pro test suite template is pre-populated with reusable sample lists and grids that help you organize your test cases around business objects, operations, or requirement priority. These lists and grids help you achieve your desired specification-based coverage criteria. For example, it is very easy to see whether you cover every type of business object that your system uses.

As stated above, starting with the ReadySET Pro templates can definitely save some time. In this particular step, you can expect to save some time on the actual writing. But more importantly, the templates guide your thinking toward a more complete test suite that will lead to a better quality product in the end. Since so much tine and effort in software development goes into tracking, diagnosing, repairing, and retesting defects, improving quality saves a significant amount of time.

Step Three: List Test Case Names

After you have outlined your test suite, this step becomes much easier to do well. Having an organized system test suite makes it easier to list test cases because the task is broken down into many small, specific subtasks.

Put your finger, or cursor, on each list item or grid cell in your test suite. Then, for each one, ask yourself about the relevant system requirements. If you have a written use case document, you will often be able to turn each use case into one or more test cases. There may be some list items or grid cells that really should be empty. For example, an e-commerce application might not have any delete operation for the Customer Order business object. Explicitly mark with "N/A" any cells that logically should not have test cases. If you cannot think of any test cases for a part of the suite that logically should have some test cases, explicitly mark it as "TODO".

The name of each test case should be a short phrase describing a general test situation. Append a unique number to each test for the given test situation. For example: login-1, login-2, login-3 for three alternative ways to test logging in. And, sales-tax-in-state-1 and sales-tax-out-of-state-1 for two different situations where collected sales taxes are reported to the government according to two different procedures. Use distinct test cases when different steps will be needed to test each situation. One test case can be used when the steps are the same and different input values are needed.

As you gradually fill in the test suite outline, you may think of features or use cases that should be in the software requirements specification (SRS), but are not there yet. Quickly note any missing requirements in the SRS document as you go along.

Before moving on to the next step, it is worth highlighting the value of having a fairly complete test suite outline. The test suite outline is a useful asset that can help your project succeed. At this point, you can already get a better feeling for the scope of the testing effort. You can already roughly prioritize test cases. You are already starting to look at your requirements critically and you may have identified missing or unclear requirements. And, you can already estimate the level of specification-based test coverage that you will achieve.

How ReadySET Pro Helps

The test suite template is pre-populated with the names of sample test cases for an e-commerce application. This reusable sample text is centered around the process of user registration and login. That gives you a big head start if you are building an application that requires login. The sample text can also be helpful for applications without login, because the samples demonstrate the correct tone, phrase structure, and level of detail.

Step Four: Write Some Test Case Descriptions

In step three, you may have generated between ten and fifty test case names on your first pass. That number will go up as you continue to make your testing more systematic. The advantage of having a large number of tests is that it usually increases the coverage.

The disadvantage to creating a big test suite is simply that it is too big. It could take a long time to fully specify every test case that you have mapped out. And, the resulting document could become too large, making it harder to maintain.

A good strategy is to be selective before drilling down to the next level of detail. For example, you might prioritize the test cases based on the priorities of the features or use cases that they test. Also, it's a good idea to first write descriptions rather than get into detailed steps for each test case. Going deep into the details of just a few test cases may be enough to shake out ambiguity or incompleteness in the requirements. The remaining cases should all be specified eventually, however you might choose to rely on ad-hoc testing for lower priority features in early releases.

For each test case, write one to three sentences describing its purpose. The description should provide enough information so that you could come back to it after several weeks and recall the same ad-hoc testing steps that you have in mind now. Later, when you actually write detailed steps in the test case, you will be able to expect any team member to carry out the test the same way that you intended.

The act of writing the descriptions forces you to think a bit more about each test case. When describing a test case, you may realize that it should actually be split into two test cases, or merged with another test case. And again, make sure to note any requirements problems or questions that you uncover.

How ReadySET Pro Helps

The test cases template is pre-populated with descriptions of several test cases focused on user registration and login. As mentioned in the previous steps, that reusable text can give you a big head start, and demonstrate the correct tone, phrase structure, and level of detail.

Page:   1   2   3     Next >>