For all bespoke systems, whether written in house, or externally, or, indeed, any off the shelf packages that have been adapted, testing is an integral part of the system’s development process and we follow this at Picaso Consulting
Testing normally roughly follows the structure of the well known V-Model, although some testing systems do recognise a simpler, four stage testing procedure as outlined in this article. Testing, therefore, can be broken down into four elementary stages:
Testing the logic of the system
The technique of dry running can be used to make sure that the logic that has been set down by the analyst is correct. The programmer or analyst will trace, often by hand, the progress of a number of sets of data through the system’s schematic diagram or flow charts. If all data follows produce the results that are expected, the individual programmes can then be written.
Programme Testing
Each program is then thoroughly tested with test data, which is carefully selected to make sure that all of the sections of the programme are working properly. This part of the testing process should be documented very carefully with the data being tested, expected results, actual results and any discrepancies being recorded and sent for further investigation.
The programme testing documentation created at this stage is of vital importance for overall system knowledge and is critical for subsequent system maintenance.
System Testing
Once it has been established that the individual programmes are working correctly, the system should be tested as a whole. This is an equally important task, and the results should be documented in the same way as those for testing programmes. It is not only the software that is being tested during the system testing process, it is also important to test operating procedures and the human-computer interface, for example.
System testing can be carried out prior to installation or immediately after implementation. The maxim holds that the more pre-installation testing that is carried out, the lower the risk of failure following installation. However, this offline testing cannot always find all of the problems within a system as some will only appear during the live phase of testing.
Acceptance Testing
The final phase of testing needs to be carried out by the eventual users of the system and this will be the first opportunity to do this as the previous testing procedures should have been completed by the system programmers and analysts. It is probably of greater importance to ensure that the eventual users of a system will accept it as whether or not it actually meets the initial specification. Users will normally operate the system with dummy data and their use of the system will be monitored very closely. On completion of this process, the users will report their objective and subjective findings in order that final refinements can be made, where necessary.
The involvement of the end users does not however, have to wait until this point as their early involvement will undeniably assist in identifying potential difficulties earlier in the design process.
Conclusion
The four stages of software testing here also correspond to the well known software development lifecycle where each phase of software writing is matched by a corresponding phase of testing, which, in turn links to the V-Model as used throughout industry today.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment