The real world system selected to discuss the approaches to the testing process is the testing of MICROSOFT Operating System WINDOWS.
Since Microsoft WINDOWS is a large system and usually large systems are tested with a mixture of strategies rather than a single strategy, we have identified the following testing approaches to complete the testing of WINDOWS.
Strict top-down approach is difficult to implement because of the needs to produce stubs. For complex components, producing stubs which simulate its activity can be impractical. In the case of WINDOWS or any operating system development and testing there will be lot of components which involve in system calls and which can be very complex need to be developed and tested at the early stages rather than simulating its functionality. Lets take the Save function in WINDOWS applications which will save the contents on to the hard disc. Simulating this function will be a nightmare. Therefore we use bottom-up approach over top-down approach in first testing the functionality of the lower level components and working up the hierarchy until the final module is tested in testing WINDOWS operating system. Therefore top-down approach is not appropriate for testing WINDOWS.
Since WINDOWS is an object based system with the functionality of the system divided into individual components and these individual components having the capacity of being highly reusable the Bottom-up testing and development should be used.
For example an individual component in WINDOWS can be a print function which sends contents on to the printer attached to the computer. By using Bottom-up approach we can develop the print function and test it using a test driver program. Once it is ready this function can be re-usable in MS-WORD, MS-PROJECT ect by distributing the test driver and test data along with the print function, so that it can be used and tested from the different higher level modules (like MS-WORD). Therefore bottom-up approach is appropriate for testing WINDOWS.
Microsoft WINDOWS is an operating system and handles different events. The events can be user interrupts, mechanical interrupts, system interrupts and failure modes. Each of these events need to be tested individually and the behavior is examined to detect errors. Once each class of events has been tested, these events are presented to WINDOWS in random order and with random frequency. The behavior of WINDOWS is examined to detect errors. Therefore thread testing is appropriate for WINDOWS.
Microsoft WINDOWS is an operating system and has an upper threshold on the workload it can handle. Like for example it can handle applications up to sizes of 64MB. If an application greater than that is loaded and is tried to run on WINDOWS, the operating system needs to handle it by exiting normally rather than crashing the entire system. Stress testing will help in looking at the behavior of the system when loads beyond maximum load have been fed to WINDOWS. This will also help in finding some undetected errors. Stress testing can involve system calls, number of jobs running concurrently etc to name a few.
Therefore Stress testing is appropriate for WINDOWS to make sure that the system does not crash when maximum threshold exceeds.
Microsoft releases more than one version of WINDOWS and also is developed for multiple platforms like PCs, Macintosh. Back-to-Back testing is required
When a new version of WINDOWS is planned for release we should make sure that the original functionality has not been altered unless desired. Therefore the testing for the latest version as well as earlier version are performed and results have to be compared to look for potential problems.
Also a particular version is released on multiple platforms. Testing needs to be done on both the platforms and results compared. differences in outputs suggest problems which should be investigated in more detail. Therefore back-to-back testing is appropriate for testing WINDOWS
Software Engineering - A Practitioners Approach, Fourth Edition, Roger S. Pressman
Dr. Hines Class Notes