Case Studies

Overview

We are developing an Internet environment titled "LIGHT VIEWS" for learning the process of O-O testing. It is an interactive hypermedia courseware geared towards a distributed learning community model for visualizing O-O software testing process through web based software. The Internet technology has been used as an enabler for creating pedagogically sound material such as active participatory learning in collaborative environments. The courseware has adopted the good principles of instructional design and human computer interaction. It contains four case studies, which focus on various aspects of O-O testing with UML design diagrams extended with design by contract notions of Eiffel. The case studies in the courseware are geared to learn about the various test strategies employed in testing O-O software systems. A short textual description of the problem is provided interspersed with passive learning material containing UML diagrams. These diagrams can be stepped through moving from one state to next in a system directed fashion. UML diagrams with the learner controlling the interactivity and also the paths taken as a consequence are part of the active learning material provided. Links to O-O theory, and glossary terms of relevance to O-O testing in general and to these case studies in particular are also part of the courseware.

O-O testing process

A quality O-O testing process should contain effective testing strategies for the various activity levels of software development from specification to implementation to test a class, a group of interacting cluster of classes, component, subsystem and system. Test plans are developed for testing each of these levels. Coverage requirements are spelt out as part of the test requirement as well. Developers and testers are then required to focus on test goals set for the activity level under test. The focus of specification-based testing such as black-box testing (also known as functional testing or interface testing) is on checking the interface behaviour. The tester here is concerned with matching expected results with actual results - not how the internals of the component being test works. White-box testing is used to check the structural aspects of code units. Unit testing involves testing the implementation until the coverage goals are met. Integration testing is performed on tested units, where units may be a class or a group of classes. System tests are run on tested components or subsystems. We follow a testing approach that takes into consideration the unique aspects of object-oriented systems with the notions of abstraction, and inheritance/polymorphism constrained by assertions. This strategy is also useful in regression testing. We have a modified incremental development/testing strategy that differs from a pure bottom-up approach of unit and white-box testing moving up to integration, interface and system testing. We recognise that O-O systems are built around abstractions of objects, and it is more practical and useful to check the functionality of an object as a whole rather than method at a time. Testing each method would be very expensive. So, for unit testing, we use the grey-box testing strategy that combines the black-box and white-box approach. This enables us to use a black-box approach to test the functionality of units, followed by coverage tests to check that the unit is satisfying the requirements for function coverage. Code coverage is also used in detecting unused (dead code) functionality. Review sessions are promoted instead of exhaustive white-box testing based on path or branch coverage. We promote incremental iterative development releases, which means that we need to run regression testing of previously tested components to ensure that any extension or modification has not introduced any structural or behavioural problems. The errors introduced at these releases must be tracked and reported with appropriate recommendations for rework as defects with severity ratings. We consider a test case as being made up of a class under test, test data and a test driver to exercise the test. Test data are produced for testing the class (objects) under test. A test driver (program) is usually composed of a sequence of steps that exercises the object(s) under test, signals assertion failures and reports any failure of the test. The test driver (program) can be used to exercise the object(s) under test by running it against the objects to be tested.