Systematic System Testing
Two days
The meaning of the phrase System Testing depends so much on the boundary of what is called 'the system'. One very common and useful boundary includes all the computerised components as well as the user and operator screens. Using this as a guide, testing this 'system' is often performed by an independent system test team.
The independent test team is usually given the task of checking that the system does what the developers say it does, that the system has no detrimental effect on other systems and is ready to go into final user acceptance activities and then production.
Checking that the system does what the users want is left to the user acceptance test team, checking that all internal bugs have been removed is done by the developers leaving the independent system test team to concentrate on giving the system a clean bill of health with respect to all the other systems that the organisation runs.
Objectives:
- to cover all the issues related to the independent system test activity as it typically occurs in large organisations whether it is for new or maintained systems
- to cover all the techniques that the independent system tester might need to use
- to identify the tools that the tester should consider using
- to determine the documentation necessary both to perform the work and document the results
Intended for: Independent system testers and release testing team members
Key points:
The background to testing in general
Where does system testing fit into the System Development Life Cycle? The techniques surveyed. The testing process, the 1 2 3 model, the use of prototypes, simulation, mechanisation and modelling. The difficulties with real time and embedded systems. The economics, where system test material construction best fits into the SDLC. Where system test running best fits into the SDLC. Entry and exit criteria.
The techniques available to testers
The use of walkthroughs, inspections, reviews and formal technical reviews on code, designs and other deliverables, the documentation of reviews; function based, component based and structure based testing techniques. Valid and not valid equivalence data classes, boundary value tests, cause effect testing. The specification of the Key Performance Factors (KPF).
The data entry screen exercise.
System testing the non functional attributes
System testing parts of the system and showing they fit to the whole. Areas to inspect: the clerical interface (HCI), facilities, volumes, stress, security, performance, reliability, backup, recovery, maintainability, documentation, running acceptance tests. The use of prototypes, models, simulation and mechanisation.
The data entry exercise re-visited.
Planning the system testing
Planning the system testing towards the end of user level design, the 1 2 3 model, entry criteria, and establishing the exit criteria from both the unit and integration tests. Creating test material as the design proceeds. Using the standard check list approach. The Hoyles case study, the user acceptance test team have planned the testing that they intend to do, the system testers must plan likewise.
Documentation
Meeting the exit criteria from the system test, documenting the test results achieved. Adjusting the techniques to suit the development process. The packaged and signed off deliverables the code, the test material and the test results.
Doing the testing
Checking the exit criteria from the unit and integration testing, the coverage achieved by the developers. Testing the clerical interface, general facilities, volume, sensitivity, stress, performance, instability, configuration, compatibility, reliability, recovery/restart, archive, serviceability, documentation, conversion and implementation. Special consideration for Client Server and GUI. The tools to use and be used by others.
Incremental system testing
Incremental system testing strategies, all at once and function by function. The use of test harness, the design of the system for incremental testing and delivery. The relationship between the developers, the independent test team and the user acceptance test team.
The final exercise defining the entry and exit criteria, the guarantee to be provided for the specific users, the project sponsor and the other users of the other computer systems.
This course complements and covers much the same material as the User Acceptance Testing but the work is done entirely from the view point of the computer specialist working in the independent test team, whereas the User Acceptance Testing assumes no computer specialist knowledge. Staff may attend both courses.
All text © QBIT. This information may not be reproduced in any form without written permission