Testing Flashcards
1
Q
Before going live with a hospital information system, the system should be thoroughly tested to assure that it is operating properly.
A
System Test Plan
2
Q
The system test plan consists of the following four steps:
A
Develop the overall test plan.
Create the test scripts.
Carry out the testing
Troubleshoot and system’s failings as soon as possible
3
Q
will help to define the problem(s) that the new information system is expected to address.
A
A feasibility study
4
Q
It will also answer questions regarding cost, goals, and specific outcomes.
A
A feasibility study
5
Q
are software applications, such as those commercially available or prepared by third parties, which need to be integrated into the other software of the information system.
A
Components
6
Q
completed to determine if the software meets specifications and functions properly and whether it meets interaction requirements of the system.
A
Testing
7
Q
May be tested by the developer and by the user
A
Components
8
Q
are parts of a component with predictable properties.
A
Features
9
Q
the term used to describe the addition of more and more features to a program.
A
Feature Creep
10
Q
Features may include the following
A
Management of database
Ability to generate reports.
Ability to integrate with other components of a system and scalability
E-mail and other customizable alerts.
Time keeping/login and logout times.
Communication among different levels and multisite capabilities.
Real-time processing.
Ability to establish uniform procedures.
Ability to provide feedback
11
Q
a computer program that allows two or more programs to exchange information.
A
Interface
12
Q
If the connection is direct, the interface is ______
A
Point to Point
13
Q
allows transfer of data only between two programs
A
Point to point interface
14
Q
allows information to transfer from one system to a number of different systems.
A
Interface Engine Software
15
Q
a de facto industry standard, although different vendors have different configurations.
A
Serial Peripheral Interface (SPI)
16
Q
allows master/slave communication from the master device to single or multiple slave devices
A
SPI
17
Q
full duplex and facilitates communication in both directions simultaneously.
A
SPI
18
Q
facilitate communication in both directions but only in one direction at a time.
A
Half duplex interfaces
19
Q
used to communicate with a variety of peripheral devices, such as sensors, clocks, liquid-crystal displays, universal serial bus ports, and communications
A
SPI
20
Q
human–computer/machine interface
A
User interface
21
Q
allows interaction between the user and the machine (e.g., computer, other electronic devices), permitting the user to make input and to see outputas a result.
A
User Interface
22
Q
The design of this interface must consider the needs of the user and ease of use.
A
User interface
23
Q
Current and new interfaces include:
A
Touch screens and touch user
Graphical user
Gesture
zooming
Voice user
natural language
Zero input
24
Q
Often used in simulations, the device has a combined use of input and output.
A
Touch screens and touch user
25
This allows an interface between devices, such as the keyboard and computer. It includes object-oriented user interfaces as well as application-oriented interfaces.
Graphical user
26
This allows input from gestures and mouse/stylus movements.
Gesture
27
This allows changes in scale of output.
Zooming
28
Input is by keystrokes or voice commands, and output is by voice commands.
Voice user
29
This allows input by keystrokes in natural language (e.g., questions), and output is the response.
Natural Language
30
Input derives from sensors.
Zero - Input
31
highlighted words, icons, images
Links
32
allow access of information at one point from a different point.
Links
33
must be tested individually to ensure they function properly.
Links
34
keyboards, mouse, microphone, stylus, webcams
Input devices
35
terminals, printers, projectors, and screens
Output devices
36
Devices can be in four different states when connected to a system:
Undefined
Defined
Available
Not available/ stopped
37
The system does not recognize the device.
Undefined
38
Information about a specific device is present in the database but not available to the system.
Defined
39
Information about a device is present in the database and configured to the operating system.
Available
40
Information about the device is present in its driver, but the device is not available.
Not Available/ stopped
41
these should be assessed for accuracy.
Reports
42
These reports contain data about the system itself, including hardware and software, as well as workstations and servers. May be generated by systems or data sets.
Configuration
43
Often include built-in templates and provide fact-finding to glean information from databases.
Informational
44
Usually are automated, showing changes that occur in the system over a period of time.
Change
45
Usually are automated to show how the system or elements of the system compare to a baseline.
Baseline
46
These reports show summaries of actions, processes, and data.
Summary/ management
47
Are issued at predetermined periods, such as monthly claims reports.
Periodic reports
48
reports are issued when faults occur or data are outside of normal parameters.
Error/ Exception
49
have a lower power demand than CRTs or plasma displays (used primarily for large screen televisions); additionally, they are more lightweight and smaller.
LCD - liquid crystal display
50
assessed through analysis of the internal environment (e.g., staff, physicians, board) and external environment (e.g., vendors, patients, agencies).
Systems environment
51
Analyzed to identify trends, needs, and expectations
Data
52
involves using software tools specifically designed to test features of an information system, such as the graphical user interface (GUI).
Automated Testing
53
especially valuable in the types of testing that may not be practical to do manually, such as stress testing in which a system is tested with large numbers of simulated users.
Automated testing
54
This is a form of functional testing that determines if an input results in the correct output, using test cases focused on the system’s operational profile.
Black box
55
This type of testing does not require knowledge of code or inner product design.
Black box
56
This introduces faults into the system to show what happens to the system when the component fails to function properly.
Fault Injection
57
This tests the ability of the system to function after introduction of a component.
Operational system
58
this may require a huge amount of testing to determine how the system will deal with component failures or problems.
Operational system
59
Wrappers are used to limit the component software in some way; that is, the wrapper may check or limit input into the component or check or limit output to the system.
Defense building
60
are often employed when commercial software is purchased that only partially meets requirements.
Wrappers
61
part of software/hardware testing, determines if hardware or software applications can work together.
System Integration Testing (SIT)
62
done after unit testing and before system and acceptance testing and involves testing how all the units function together.
System Integration Testing
63
This is a type of black box testing that should not require knowledge of code or inner product design.
System Integration Testing
64
The purpose of the testing is to identify problems or faults within the component parts (assemblages) or within the entire information system that affects performance.
SIT
65
Approaches to integration testing include
Big Bang - all components
Top Bottom (higher level components)
Bottom up (lower level components)
66
verifies that a code is functioning properly and determines if users are able to carry out certain functions or whether features in the software work as expected.
Functional testing
67
may include manipulating data, conducting searches, using user commands, and accessing user screens
Functional testing
68
also conducted as part of functional testing.
Integration testing
69
should be completed on units during development and on the system as a whole after integration.
Functional testing
70
should also be conducted from the perspective of the end-user, so functional tests should always be designed to correspond to end-user requirements.
Functional testing
71
should be able to identify system level faults and problems.
Functional Testing
72
a type of nonfunctional reliability testing that evaluates the system's ability to function under different loads, such as during normal use times and peak times with multiple users to determine maximum capacity and problems that might be encountered.
Load or Volume testing
73
involves evaluating the effect of volume on the system to determine limits.
Volume testing
74
Testing tries to determine at which exact point problems arise.
Volume testing
75
should always be concluded before a system becomes live to prevent crashes and loss of data if limits are exceeded.
Volume testing
76
essential because incorrect data can lead to serious problems with the system and provide false information.
Validating data integration across disparate systems
77
completed after integration testing and involves testing the system as a whole to determine if it meets requirements, functions as needed, and meets expected outcomes.
performance effectiveness
78
Testing is completed to ensure that the system is in compliance with the ADA requirements.
Accessibility testing
79
This type of exploratory testing is usually done once, and the user attempts to identify problems in an unstructured way by trying various means to elicit errors.
Ad hoc testing
80
This is essentially a form of error guessing in which the user bases testing on previous experience with software.
Ad Hoc testing
81
This may include certification testing to determine if the application functions properly in a target operating system or database.
Compatibility testing
82
focusing on user experience, can encompass a wide range of tests, such as testing the system in different web browsers, evaluating the bandwidth handling capacity, determining if peripherals (e.g., printers) function properly, evaluating the function of tools (e.g., messaging), and testing access to databases.
Compatibility testing
83
This type of error testing is done to determine if there are errors resulting from incorrect programming, coding, or resource failures, how the system responds, and whether errors result in negative effects, such as corrupted data
Exception handling testing
84
may involve hardware and software.
Exception handling
85
This type of testing uses the results of previous testing to determine the types of additional testing indicated, based on user experience, and does not follow a specified pattern of testing.
Exploratory testing
86
This may be done after conclusion of other tests to verify that no significant defects remain.
Exploratory testing
87
allows users to interact with devices through the use of images, such as icons, rather than text, must be tested to ensure it meets specifications.
Graphical user interface (GUI)
88
This tests the procedures needed to install, uninstall, and upgrade applications.
Installation testing
89
This testing is done to identify problems requiring maintenance with equipment or applications or to evaluate the effectiveness of repairs.
Maintenance testing
90
often done on software already in use when it is changed in some way or installed in other hardware.
Maintenance testing
91
This involves purposely crashing the system and evaluating the system’s ability to recover.
Recovery testing
92
Techniques include restarting the computer in the middle of an action, unplugging the device during data retrieval, and restarting a browser after accessing a number of different windows to determine if memory and access to the windows remain intact after restarting.
Recovery testing
93
This tests the system after a change, such as installation of a patch or a change in configuration, to determine if the change has introduced faults into the system.
Regression testing
94
This is rapid run-through testing to determine if results seem reasonable and the system appears to work correctly.
Sanity testing
95
testing may be done during development and before more rigorous testing to find obvious faults.
Sanity Testing
96
This tests the ability of the system to function under increasing loads (scaling up) or under increasing nodes (scaling out), such as adding computers or servers to the system.
Scalability testing
97
This testing is done to determine if data security is adequate in protecting confidentiality.
Security testing
98
tests authentications, access controls, availability of information, and nonrepudiation (ensuring a record remains of messages sent and received).
Security testing
99
This involves attaching an electronic device to power and observing the result (“smoke”).
Smoke/ power on testing
100
identifies overloads or overheating.
Smoke/ power on testing
101
These tests are used to determine the ability of the system to perform under specified workloads.
Software Performance
102
testing may include load testing, stress testing to determine upper limits, endurance testing to determine the length of time a system can function under an anticipated load, spike testing to determine if the system can function with a sudden dramatic increase in load, configuration testing to determine if the system functions with changes in configuration, and isolation testing to repeat tests that resulted in failures or system problems.
Software performance
103
This tests the ability of end-users to use the system and applications adequately.
Usability testing
104
activities encompass both the hardware and software aspects of keeping the system “caught up” in terms of maintenance.
System maintenance
105
Specific system maintenance tasks include:
Troubleshooting hardware and software problems.
Keeping an adequate supply of replacement hardware (e.g., printers, cables, and monitors) and consumables (e.g., toner and ink cartridges).
Performing system back up procedures according to a predefined schedule.
Making sure the system has enough storage capacity.
Applying system upgrades and software patches.
Making sure disaster recovery plan is in place and ready for implementation.
106
Type of architecture, downtime necessary for maintenance, standards for connectivity, environments for testing, response times, and supporting technologies.
Technical criteria
107
Security standards, data standards, options for storage, capabilities related to providing reports, integration with health information exchanges.
General/ managerial criteria
108
Correct client identification with unique identifiers across multiple registration sites and ability to track client’s location and use of services.
Registration
109
Indicates details about orders, provides notification of duplicate orders, produces audit trail, supports documentation, generates claims, provides clinical decision support, and displays results.
Computerized physician order entry reporting
110
Pulls documentation (e.g., claims) from various departments.
Integrated Documentation
111
Appointments, testing, and procedures.
Scheduling
112
Provides automatic coding.
Medical Records
113
Provides summaries, insurance information, and charges.
Billing
114
may result in the hardware freezing or software malfunctioning. I
System Failure
115
Common causes of system failure include
user/operator error, power disruptions/disconnections, overheating, and equipment malfunction or failure.
