Objectives: Introduction Over View of System Analysis and Design
Download 0.94 Mb. View original pdf
|
- Navigate this page:
- 5. Procedure Testing
- 6. Human factors Testing
| 4. Recovery Testing Analysts must always assume that the system will fail and data will be damaged or lost. Even though plans and procedures are written to cover these situations, they also must be tested. By creating a failure or data loss event where the users are forced to reload and recover form a backup copy, analysts can readily determine whether recovery procedures are adequate. The best – designed plans usually are adjusted or augmented after this test. 5. Procedure Testing Documentation and run manuals tell the user how to perform certain functions are tested quite easily by asking the user to follow them exactly through a series of events. It is surprising how not including instructions about when to depress the enter key, about removing diskettes before powering down, or what to do when the paper – out light on the printer lights up can raise questions. There is, of course, no substitute fora well – designed set of procedure manuals. Analysts concentrate on the major and critical details of a systems design and include them in the documentation. They also pay attention to the little details, when designing the system. But often descriptions of the details do not get into the documentation. This type of testing not only shows where they are needed but also where they are wrong, that is, where actions suggested in the documentation do not match those that must actually betaken to make the system. 6. Human factors Testing What do users do if, after submitting a transaction through a terminal, the screen goes blank while the data are being processed They may not take the actions the analyst wants or expects, instead responding in unusual ways they may depress the send key several times, turn the power switch on the terminal off and back on, unplug it and replug it, or beat on the terminal. Obliviously, they will do just about anything if the analyst has not given them some message on the screen to indicate that their request has been received, that it is being processed, and that there will be a short delay. This is what human factors testing is all about – finding answers to questions about how people will react to the system in ways not anticipated. And as a general rule, as strange as the above actions may sound, the people are right they are taking actions that are normal under the circumstances. It is the responsibility of the analyst to anticipate questions that will arise in the minds of the users as they interact with the system. If a screen will go blank during transaction processing, the analyst should make sure that it displays a message informing the user that processing is occurring. Even that is not enough if the delay will be more than a second or two. For processing that will take long periods, the analyst should have the screen give the user a message telling approximately how long it will take and providing an option to cancel the request. The user may decide to have that one – hour job run some other time when the system is not so busy. If the system is going into along sorting step, the analyst should keep the user informed about how much of the sort is completed. Users appreciate systems that display the numbers of records sorted or the percentages completed. Also the analyst should be sure to watch how people enter data. Do they use different keystroke form those anticipated (such as the top row of numbers on the typewriter pad rather than those on the numeric keypad Are any keystrokes awkward and therefore error prone (for example, having to hold down the shift key with the little finger while depressing the + key with the index finger How will the user of a system feel after working with the system fora lengthy period of time Glare on the screen or simply too much detail on one display is physically and mentally irritating. Slight modifications in the display contents or the location of the equipment are important human factor concerns that dramatically affect the user and, therefore, the system overtime. These simple testing questions are of monumental importance and extremely helpful in finding flaws that can cause the system to fail. Some analysts will find these flaws the hard way – through bad experiences. It is difficult to forget the system that was damaged because a user banged on the terminal when data were submitted and accepted by the system without displaying a response. But, following the guidelines above, the analyst can avoid those situations. Download 0.94 Mb. Share with your friends:
|