Introduction to Object Oriented Testing Methods

Object oriented testing begins in the small with a series of tests designed to exercise class operations and check whether errors exist as one class collaborates with other classes. Use based testing along with fault based testing is applied to integrated classes. In the end, use cases are used to uncover errors at software validation level.

Encapsulation can create a minor problem when testing because testing reports on concrete and abstract state of an object. Multiple inheritance complicates testing by increasing number of contexts for which testing is required. Black box testing methods are appropriate for object oriented systems as they are for systems developed using conventional software engineering methods.

The strategy for fault based testing is to hypothesize a set of possible faults and then derive the tests to prove each of that hypothesis. The effectiveness of these techniques depends on how testers see a plausible fault.

Inheritance complicates the testing process. even though the base class has been properly tested, there is a need to test all classes derived from it.

Scenario based testing will uncover errors that occur when any actor interacts with the software. It concentrates on what the user does and not what the product does. This type of testing uncovers interaction errors.

Surface structure is an externally observable structure of object oriented program. Testing surface structure is similar to black box testing. Deep structure refers to the internal technical details of object oriented program. It exercises dependencies, behaviors and communication mechanisms. It is similar to white box testing.

Black Box Testing Technique - Orthogonal Array Testing (OATS)

Orthogonal array testing enables you to design test cases that provide maximum test coverage with reasonable number of test cases. This type of testing can be applied to problems which has relatively small input domain but too large to accommodate exhaustive testing. Orthogonal array testing is more suitable in finding errors associated with faulty logic within a software component.

Orthogonal arrays are two dimensional arrays of numbers which possess the interesting quality that by choosing any two columns in the array you receive an even distribution of all the pair-wise combinations of values in the array.

The benefits of orthogonal array testing includes:
- lower execution time.
- lower implementation time.
- code coverage is high.
- overall productivity increases.
- the analysis of results take less time.

Orthogonal array testing uses the following terminology:
- Runs are the number of rows in an array.
- Factors are the number of columns in an array.
- Levels are the maximum number of values that can be taken on by any single factor.

Orthogonal array testing (OAT) helps in optimizing testing by creating an optimized test suite, detects all kind of faults, guarantees the testing of pair wise combinations, less prone to errors, simpler to generate and is independent of platforms and domains.

Basis Path Testing - A white Box testing technique.

Basis Path Testing uses the algorithmic flow of the program to design tests. Test cases that are written to test the basis set execute every statement in the program at least once.

- A flow graph should be drawn only when the logical structure of a component is complex. The flow graph allows you to trace program paths more readily. When compound conditions are encountered in a procedural design, the generation of a flow graph becomes slightly more complicated.

- Independent program path is a path which has at least one new set of processing statements or a new condition. An independent path should move along one edge that has not been traversed before. To know how many paths to look for, cyclomatic complexity is a useful metric for predicting those modules that are likely to be error prone. It can be used for test planning as well as test case design. Cyclomatic complexity provides the upper bound on the number of test cases that will be required to guarantee that every statement in the program has been executed at least one time.

- There are few steps to derive test cases or the basis set.
A flow graph is drawn using the design or code.
The cyclomatic complexity of flow graph is evaluated.
A basis set of linear independent path is determined.
Test cases are prepared forcing the execution of each path in basis set.

- Graph matrix is a square matrix whose size is equal to the number of nodes on flow graph. It is a tabular representation of a flow graph. Adding link weight to the each matrix entry, graph matrix can become a powerful tool to evaluate program control structure during testing.

What are the characteristics of testing and a good test?

Testing goal is to find errors. It should exhibit a set of characteristics that achieve the goal of finding the errors with minimum effort. The characteristics of software testing includes:
- How easily a software can be tested? i.e. test-ability
- How efficiently it can be tested? i.e. oper-ability
- What you see is what you test? i.e. observability
- How much we control the software so that testing can be automated and optimized? i.e. controllability
- Isolating problems and perform smarter retesting by controlling scope of testing i.e. decomposability.
- The program should be simple so that it can become easy to test i.e. simplicity.
- The fewer the changes, the fewer the disruptions to testing i.e. stability.
- The more information we have, the smarter we will test i.e. understandability.

A good test has the following characteristics:
- A good test has a high probability of finding an error.
- A good test is not redundant.
- A good test has the highest likelihood of uncovering a whole class of errors.
- A good test should be neither too simple nor too complex.

There are two ways to test an engineered product:
- Knowing the internal workings of product and tests can be conducted that can ensure that internal workings are performed according to specifications and all internal components are exercised properly.
- Knowing the output or the function for which the product is designed, tests are conducted to demonstrate each function is fully operational and checking the errors at the same time.

Introduction to Debugging? What strategies include debugging?

When the software testing is successfully done, the next step is debugging. Debugging is the process of removing the error that has been uncovered during the testing process. Debugging process starts with the execution of a test case. The results that are attained are assessed and the actual and expected values are compared. Debugging is the process that matches symptom with the cause.

In debugging process, there is a possibility of two outcomes:
- cause is found and corrected.
- cause is not found

Debugging sounds difficult and here are some reasons why it is so:
- The cause and symptom may be located remotely.
- Sometimes when some other error is corrected, the symptom disappear.
- Human error can cause a symptom.
- Timing problem can cause a symptom.
- Non errors can cause symptoms.
- Symptoms can be intermittent.
- There is a possibility that causes are distributed across different tasks running on different processors.

Debugging strategy includes finding and correcting the cause of software error by the use of three strategies:
- Brute force uses the philosophy of let the computer find the error. Memory dumps are taken, run-time traces are invoked and program is loaded with output statements.
- Backtracking is the process which starts at the site where symptom is uncovered, source code is traced backward until cause is found.
- In cause elimination, cause hypothesis is devised and data is used to prove or disprove the hypothesis. On the other hand, list of possible causes is developed and tests are conducted to eliminate each.

Introduction to Validation testing? What is the validation criteria?

Validation tries to uncover errors, but the focus is at the requirements level, i.e. on the things that will be immediately apparent to the end user. It begins at the end of integration testing, when all individual modules are packaged and interface errors are uncovered and corrected. In validation testing phase, testing focuses on user visible actions and output that is user recognizable. The criteria of software entering into validation phase is that it functions in a manner that is reasonably expected by the customer.

In software requirements specification, there is a section called validation test criteria. Test plan lists out the tests to be conducted and a test procedure defines test cases. These plan and procedure are designed to ensure that all the functional requirements are satisfied, behavioral characteristics are achieved, performance requirements are attained, usability is met and documentation is done.

Configuration review ensures that all elements of software configuration are properly developed, cataloged and every necessary detail is given. It is also known as audit.

Alpha testing is done at developer's site. It does not happen at usual workplace. The real users are simulated by using these techniques and carrying out tasks and operations that a typical user might perform.

Beta testing is done at end user sites. The developer is not present. It is the live application of software in an environment that is not controlled by the developer. The end user records all the problems that he faces and reports to the developer.

Object Oriented Software and its Test Strategies...

In testing object oriented software, the objective of testing remains the same. The nature of object oriented software changes both testing strategy and testing tactics.

UNIT TESTING IN OBJECT ORIENTED CONTEXT
In object oriented software, an encapsulated class is the focus of unit testing. Encapsulation means that class and class object packages the attributes and operations that manipulate the data. A class contains many operations so unit testing these operations must also vary.
Class testing for object oriented software is analogous to module testing for conventional software. It is not advisable to test operations in isolation. Unit testing of conventional software focus on algorithmic detail of module and the data that flows across module whereas unit testing for object oriented software focus on operations encapsulated by class.

INTEGRATION TESTING IN OBJECT ORIENTED CONTEXT
An important strategy for integration testing of object oriented software is thread based testing. Threads are set of classes that respond to an input or event. Each thread is integrated and tested individually. Regression testing is done.
Another strategy is the use based tests that focus on classes that do not collaborate heavily with other classes.

The behavior of drivers and stubs also changes during integration testing of object oriented software. Drivers test operations at lowest level and for testing whole group of classes. Stubs are used where collaboration between classes is required but one or more collaborating class is not fully implemented.