Software Test Design Fundamentals

Whether beginning a completely new software product or adding in features and bug fixes to an existing one, tested verification is the measure of success in the coding process. It is the direct comparison of the intent of the code to its outcome. For this reason, test cases tend to be based on use cases wherein a specific activity is examined to see that it does what it was designed for and doesn’t do anything detrimental to the system’s overall intent.

The concept of testing uses of features is stretched to cover bug fix regression testing where the bug symptom is an impairment of the use of a feature. The fix inspired by the symptom is verified and additional test cases are crafted to remove unintended consequences from the fix that show up in, supposedly, unrelated parts of the system.

Unit tests are less related to use cases and more to white box knowledge of the code. A given input should inspire thus and such a set of outputs. String a number of these input/output combinations together and you have a feature/fix that has an associated use case.

The Basic Elements of Test Design

What could go wrong? It’s the give-away phrase for many a plot line in all manner of fiction. It is also the prime question behind designing a test case.

It is the concept behind the negative half of the positive/negative distinction in test case design. Positive tests actuate a function as it is intended to operate giving it ‘normal’ input data in the expectation of seeing the desired output. The negative test intentionally disturbs the system with an odd action or corrupt data item to see that it gracefully deals with the unexpected.

To use both test modes, a test setup is required. This may be as simple as a short list of test steps such as:

• make this entry in the text box
• click on that radio button and
• click on Submit.

The first two steps are the setup for the third which initiates the actual test. That said, test setup may be as complex as creating a whole array of database records, preparing service test stubs and starting a string of background processes. Test design must account for all these preliminary actions to make the test results accurate and valid.

That part about accurate and valid bears repetition. A primary aspect of a test case is a well thought out, thoroughly documented test outcome. The tech performing the test needs an exact description of what to look for in the results to accurately report test success or failure. Too many test cases become useless because the requirements for passing the test were inadequately defined.

Assembly into a Test Plan

Test cases are grouped and assembled into test plans to facilitate efficiency. Testing all the aspects of a feature focuses the operator’s attention on that feature so that variations from desired operation will stand out better and draw attention which results in a more useful defect report. This is where test management experience comes to bear.

A test designer’s experience of numerous test projects over the years creates an ingrained knowledge of what to look for when testing. This ‘QA Perspective’ is the signature of the test professional and the primary distinction between a development engineer and a test engineer. Good test case design and management practices are vital for building a tool kit of high quality, time-tested working concepts that will significantly reduce project test planning and design times.

Contact Us