Lecture 14 - Software Testing (Part I)

Testing
Objectives & Principles of Testing

Testing is the process of executing a program with the intent of finding an error.

It demonstrates that software functions appear to be working according to specifications and that performance requirements have been met. Testing can be conducted at different levels and ways it basically takes two forms.

1. Verification
This refers to the set of activities that ensure software correctly implement a given function. Verification means "Are we building the product right?" (Is it correct with respect to the software specifications?).

2. Validation
Validation is a set of activities which ensures the software that has been built satisfies customer requirements. "Are we building the right product?" (are the software specifications correct?)

Static vs Dynamic Testing
Before the implemented program is tested on a computer, series .of tests are being performed on various documents manually. such testing is usually called as static verification and include desk checking, dry running and code reviews etc.

Dynamic testing is the process of running a program or part of a program on a computer with view to identify the errors. This includes various stages of testing methods.

Debugging
Debugging is consequence of successful testing and its objective is to remove the defects uncovered by tests. The debugging process works from symptom to cause. Because the cause may hot be directly linked-to the symptom. It may be necessary to enumerate hypotheses explicitly and then design new tests cases to allow confirmation or rejection of the hypothesized cause.

Some among the main difficulties in debugging are:

• The symptom and the cause may lie at locations in the code that are quite remote from one another.
• The symptom may disappear by the removal of another error, but only temporarily
  The symptom may be cause not by an error but by misjudgment
• The symptom may be caused by human error (incorrect test plans, is interpretation of specifications).
• The symptom may be difficult to reproduce (in real-time systems input sequences are indeterminate)

Stages of Dynamic Testing
There are four basic testing stages, progressing from smaller to larger scope. They are typically known as:

• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing

Unit Testing

Unit Testing focuses verification effort on the smallest unit of software design that is the module.

It is typically the work of the programmer as it requires detail knowledge of the internal program design & code.

Each and every module or unit in the system will be tested in isolation.

The amount of Testing needed will vary in proportion to the size & the complexity of the module been tested.


Integration Testing

Integration testing is a systematic technique for constructing the program while conducting tests to uncover errors associated with linking.

The aim of integrated testing is to identify

1. Data being lost between modules.
2. Sub functions may not produce the derived functions when combined.
3. One module can have an adverse effect on another module.


System Testing

System Testing fully exercises the computer based system. It verifies that all system elements have been integrated & perform the allocated function.

The following are the types of System Testing.

Recovery Testing
A system test that causes the siw in a variety of ways & verifies recovery is properly performed.

Security Testing
Security testing attempts to verify that protection mechanisms built in to system will in fact protect if from improper or illegal penetration.

Stress Testing
Some systems are designed to handle specific work load, so stress testing will be processed to see whether this system can process intended work load.


Acceptance Testing
 
This type of testing process is carried out by the users rather than software developer. They concentrate on validating requirements.

Typically errors or omissions in the System requirements are deleted & performance related problems are also detected.

An Acceptance Test can range from an informal test drive to a planned and systematically executed series of tests. In fact acceptance testing can be conducted over a period of weeks or months.


Software Testing Strategies
 
A software testing strategy provides a road map for the software developer, quality assurance team and the customer. The road map describes its steps to be conducted during testing process.

A testing strategy should incorporate

1. Test Planning
2. Test Case Design

Test Planning
Test Planning is concerned with setting out standards for the testing process which will be carried out in the near future.

• Software engineers - To design & conduct testing
• The technical staff - To get an overall picture of testing

Contents of a Test Plan

• The Testing process - Description of the major phases.
• Requirement Tractability - Users are interested on system meeting its requirements and therefore testing should be planned so that all requirements are individually tested.
• Test items Products to be tested should be specified.
• Testing Schedules & resource allocation
• Test recording procedures- The results of the test must be systematically recorded. lt must be possible to audit the testing process. This will verify the correctness of the testing process.

Test Case Design
Test case is an outline which tests a feature or set of features. It provides developer a systematic approach for testing; therefore it will ensure the completeness of test and provide the highest likelihood for uncovering errors in software. Test cases consist of :

• Test Data
• Expected Results
• Purpose of having the particular test data

Top down Testing

This method tests the higher level modules before testing its detail components.The program is represented as a single abstract component where sub components are represented by stubs. Stubs simulate the functionality of the lower level modules. After the top level components are tested, then the sub components are implemented and tested in the same way. This process continues until the lowest level modules are implemented.

Advantages

• Can detect unnoticed design errors very early, early error detection means that extensive redesign & re implementation may be avoided.
• Allows you to make a working limited system early in the development process which gives a psychological boost to those involved in the system development.
• Working Limited system in the initial stages can demonstrate the feasibility of the system to management.

Disadvantages

• Strict to the Top down testing is impractical, because sometimes it is not possible to simulate some complex components using stubs.
• Test output may be difficult to observe
• It may be difficult to find top level input data that will exercise a lower level module in a particular derived manner.

Bottom up Testing

Bottom up testing is the converse of Top down Testing

It involves testing the modules at the lowest level of the hierarchy and then working up the hierarchy until the final module is tested.

When using bottom up testing, test drives are used. Drivers simulate the functionality of higher level modules.

Advantages 

• Testing low level modules are easier because they produce the output in term user requirements
• Easier to create test cases & observe output. (Easy to deliver small amount of data where as giving for higher level system)

Disadvantages

• A working system is not available until all modules are tested.(No hierarchy)
• Higher level errors may cause change in lower level modules.