Test Suites Versus Test Plans

As the old saying goes “One of the nice things about standards is there is so many to choose from.” Well the same applied to testing. We have seen many loose definitions and usages applied to testing and whilst some are subject to speculation at Testnetic we thought we would take a moment and outline our approach which we believe is the most correct and valuable and how to use it in the real world.

What do the ISTS say?

The peak body for software testing is the International Software Testing Board (as an aside worth getting involved with to develop a testing career further). Their definition are;

test case Ref: After IEEE 610 A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.

test plan Ref: After IEEE 829 A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.

test suite Synonyms: test case suite , test set A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one.

So when using Testnetic our focus is on the creation of test cases and subsequently grouping those test cases into a Test Suite. There might be several test suites that form part of a comprehensive test plan. This typically is an external word document that is circulated amongst testers and developers. Certainly many elements of test suites could be exported to from part of the test documents.

Using Test Suites Effectively

With Testnetic our approach is the have the ability to create, modify and copy any test suite to become part of a test plan. You can perform these functions here:

A use case for instance is the testing using different environments, stages, functions or versions. Simply copy a test suite, change the name and when testing change either parameter.

So we hope that provide some additional insights, and please should you have any questions. insights or comments we welcome you input here.

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email