Test Development process/STLC

When starting a test we have to consider various things like what are we testing? How are we testing? Etc., the three key things that are used to define the above mentioned criteria are

1.      Test Conditions

2.      Test cases

3.      Test scripts

Basically all the above are documented in some way or other for our reference and understanding.

a.       Test conditions are documented in a Test Design Specification.

b.      Test cases are documented in a Test Case Specification.

c.       Test procedures are documented in a Test Procedure Specification.

 There may be various levels of formal documentation procedures are involved. In a well organized formal testing all activities are documented and tracked. The bugs’ wills be recorded and referred for future reference. It also includes the exact inputs and outputs of the test activity which was carried out. Most of the organization will have very formal test documentation procedures to keep track on the testing activities. The formalities level is influenced by the organization nature, and the time for completion of the project.

There can be other way to define or describe the STLC which is most commonly followed by all.

·         Test Strategy

·         Test Plan

·         Test Design

·         Test Execution

·         Test Reports/Results

The categorization may vary but the theme remains same which is discussed below.

Identifying Test Conditions

A test condition is simply something that we could test. If we are looking to measure coverage of code decisions, then the test basis would be the code itself, and the list of test conditions would be the decision outcomes. Test analysis is the process of looking at something that can be used to derive Test information. It could be a system requirement, a technical specification, the code itself (for structural testing), or a business process. Sometimes tests can be based on an experienced user's knowledge of the system, which may not be documented.

When identifying test conditions, we want to identify as many as we can, and then we will start being selective about which ones to take forward to develop in more detail and combine into test cases. We could call them 'test possibilities'. The test conditions that are chosen will depend on the test strategy or detailed test approach. Test conditions should be able to be linked back to their sources in the test basis - this is called traceability.

Traceability can be either horizontal through all the test documentation for a given test level (e.g. system testing, from test conditions through test cases to test scripts) or vertical through the layers of development documentation (e.g. from requirements to components).

Test Cases Specifications/Test Design

A test case is something which is used to carry out tests so that it will cover the entire functionality of the code and the software characteristics being tested. A test case usually covers all the possible outcomes and functions of the software.

Say for example, if a text box is under test whose property is only to accept only text input. For this test the typical tests will be carried by entering the text value to check if it is accepting the value and any character or number to find if it is rejecting the input. Here the test cases that can be used are

            Case 1: Input=123

Case 2: Input=ABC

Case 3: Input=1B3

Case 4: Input=@#$

Case 5: Input=! %A

So all the five test cases will check the validation of the data and cover all the possible and unexpected input to the textbox. Here the specification or identifying the appropriate test cases is essential so that the minimal no of tests can be carried out. Also the test case should have expected outcome for the input values that are used for the test case so that we could manage the test pass/fail criteria for the specific product.           

In addition to the expected results, the test case also specifies the environment and other things that must be in place before the test can be run (the preconditions) and any things that should apply after the test completes (the post conditions).

Test Script and implementation

The test cases are to be grouped in a sensible way for executing them and to specify the sequential steps that need to be done to run the test. For example, a set of simple tests that cover the breadth of the system may form a regression suite, or all of the tests that explore the working of a given functionality or feature in depth may be grouped to be run together. Some test cases may need to be run in a particular sequence. For example, a test may create a new customer record, amend that newly created record and then delete it. These tests need to be run in the correct order, or they won't test what they are meant to test.

The document that describes the steps to be taken in running a set of tests (and specifies the executable order of the tests) is called a test procedure in IEEE 829, and is often also referred to as a test script. It could be called a manual test script for tests that are intended to be run manually rather than using a test execution tool. Test script is also used to describe the instructions to a test execution tool. An automation script is written in a programming language that the tool can interpret.