Professional Documents
Culture Documents
1. Assure that the start-up icon for the application under consideration is unique
from all other current applications.
2. Assure the presence of a control menu in each window and dialog box.
3. Assure the correctness of the Multiple Document Interface (MDI) of each
window - Only the parent window should be modal (All child windows should be
presented within the confines of the parent window).
4. Assure that all windows have a consistent look and feel.
5. Assure that all dialog boxes have a consistent look and feel.
6. Assure that the child widows can be cascaded or tiled within the parent window.
7. Assure that icons which represent minimized child windows can be arranged
within the parent window.
8. Assure the existence of the "File" menu.
9. Assure the existence of the "Help" menu.
10. Assure the existence of a "Window" Menu.
11. Assure the existence and proper location of any other menus which are logically
required by the application.
12. Assure that the proper commands and options are in each menu.
13. Assure that all buttons on all tool bars have a corresponding menu commands.
14. Assure that each menu command has an alternative(hot-key) key sequence
which will invoke it where appropriate.
15. In "tabbed" dialog boxes, assure that the tab names are not abbreviations.
16. In "tabbed" dialog boxes, assure that the tabs can be accessed via appropriate hot
key combinations.
17. In "tabbed" dialoged boxes, assure that duplicate hot keys do not exist
18. Assure that tabs are placed horizontally across the top (avoid placing tabs
vertically on the sides as this makes the names hard to read).
19. Assure the proper usage of the escape key (which is to roll back any changes
that have been made).
20. Assure that the cancel button functions the same as the escape key.
21. Assure that the Cancel button becomes a Close button when changes have be
made that cannot be rolled back.
22. Assure that only command buttons which are used by a particular window, or in
a particular dialog box, are present.
23. When a command button is used sometimes and not at other times, assure that it
is grayed out when it should not be used.
24. Assure that OK and Cancel buttons are grouped separately from other command
buttons.
25. Assure that command button names are not abbreviations.
26. Assure that command button names are not technical labels, but rather are names
meaningful to system users.
27. Assure that command buttons are all of similar size and shape.
28. Assure that each command button can be accessed via a hot key combination
(except the OK and CANCEL buttons which do not normally have hot keys).
29. Assure that command buttons in the same window/dialog box do not have
duplicate hot keys.
30. Assure that each window/dialog box has a clearly marked default value
(command button, or other object) which is invoked when the Enter key is pressed.
31. Assure that focus is set to an object which makes sense according to the function
of the window/dialog box.
32. Assure that option button (AKA radio button) names are not abbreviations.
33. Assure that option button names are not technical labels, but rather are names
meaningful to system users.
34. If hot keys are used to access option buttons, assure that duplicate hot keys do
not exist in the same window/dialog box.
35. Assure that option box names are not abbreviations.
36. Assure that option box names are not technical labels, but rather are names
meaningful to system users.
37. If hot keys are used to access option boxes, assure that duplicate hot keys do not
exist in the same window/dialog box.
38. Assure that option boxes, option buttons, and command buttons are logically
grouped together in clearly demarcated areas.
39. Assure that each demarcated area has a meaningful name that is not an
abbreviation.
40. Assure that the Tab key sequence which traverses the defined areas does so in a
logical way.
41. Assure that the parent window has a status bar.
42. Assure that all user-related system messages are presented via the status bar.
43. Assure consistency of mouse actions across windows.
44. Assure that the color red is not used to highlight active GUI objects (many
individuals are red-green color blind).
45. Assure that the user will have control of the desktop with respect to general
color and highlighting (the application should not dictate the desktop background
characteristics).
46. Assure that the GUI does not have a cluttered appearance (GUIs should not be
designed to look like a mainframe character user interfaces (CUIs) when replacing
such data entry/retrieval screens)
Testing GUIs
Modern software applications often have sophisticated user interfaces.
Because the number of lines of code (or reusable components) required for
GUI implementation can often exceed the number of lines of code for other
elements of the software, thorough testing of the user interface is essential. .
For this checklist, the more questions that elicit a negative response, the
higher the risk that the GUI will not adequately meet the needs of the end
user.
For windows:
Will the window open properly based on related typed or menubased
commands?
Can the window be resized, moved, scrolled?
Is all data content contained within the window properly addressable with a
mouse, function keys, directional arrows, and keyboard?
Does the window properly regenerate went it is overwritten and then
recalled?
Are all functions that relate to the window available when needed?
Are all functions that related to the window operational?
Are all relevant pulldown menus, tool bars, scroll bars, dialog boxes and
buttons, icons, and other controls available and properly displayed for the
When multiple windows are displayed, is the name of the window properly
window?
represented?
Is the active window properly highlighted?
If multitasking is used, are all windows updated at appropriate times?
Do multiple or incorrect mouse picks within the window cause unexpected
side effects?
Are audio and/or color prompts within the window or as a consequence of
window operations presented according to specification?
Does the window properly close?
For pull down menus and mouse operations:
Is the appropriate menu bar displayed in the appropriate context?
Does the application menu bar display system related features (e.g., a clock
display)?
Do pulldown operations work properly?
Do breakaway menus, palettes, and tool bars work properly?
Are all menu functions and pull down subfunctions properly listed?
Are all menu functions properly addressable by the mouse?
Are text typeface, size and format correct?
Is it possible to invoke each menu function using its alternative textbased
command?
Are menu functions highlighted (or grayedout) based on the context of
current operations within a window?
Does each menu function perform as advertised?
Are the names of menu functions self explanatory?
Is help available for each menu item and is it context sensitive?
Are mouse operations properly recognized throughout the interactive
context?
If multiple clicks are required, are they properly recognized in context?
If the mouse has multiple buttons, are they properly recognized in context?
Do the cursor, processing indicator (e.g., an hour glass or clock), and pointer
properly change as different operations are invoked?
Data entry:
Is alphanumeric data entry properly echoed and input to the system?
Do graphical modes of data entry (e.g., a slide bar) work properly?
Is invalid data properly recognized?
Are data input messages intelligible?
Four Stages of GUI Testing
The four stages are summarised in Table 2 below. We can map the four test stages to traditional test s
Checklist Testing
Navigation Testing
An application backbone with at least the required menu options and call mechanisms to call the win
Windows that can invoke the window under test.
Windows that are called by the window under test.
Obviously, if any of the above components are not available, stubs and/or drivers will be necessary to
For every window, identify all the legitimate calls to the window that the application should allow and
Identify all the legitimate calls from the window to other features that the application should allow and
Identify reversible calls, i.e. where closing a called window should return to the ‘calling’ window and c
Identify irreversible calls i.e. where the calling window closes before the called window appears.
There may be multiple ways of executing a call to another window i.e. menus, buttons, keyboard comm
Note that navigation tests reflect only a part of the full integration testing that should be undertaken. Th
Application Testing
Application testing is the testing that would normally be undertaken on a forms-based application. This
We define desktop integration as the integration and testing of a client application with these other com
To derive a list of test cases the tester needs to ask a series of questions for each known interface:
Is there a dialogue between the application and interfacing product (i.e. a sequence of stages with di
Is information passed in both directions across the interface?
Is the call to the interfacing product context sensitive?
Are there different message types? If so, how can these be varied?
In principle, the tester should prepare test cases to exercise each message type in circumstances whe
Client/Server communication testing complements the desktop integration testing. This aspect covers t
In the most common situation, clients communicate directly with database servers. Here the particular
The response times of transactions that involve client/server communication may be of interest. These
Synchronisation Testing
There may be circumstances in the application under test where there are dependencies between diffe
Examples of synchronisation are when:
The application has different modes - if a particular window is open, then certain menu options becom
If the data in the database changes and these changes are notified to the application by an unsolicite
If data on a visible window is changed and makes data on another displayed window inconsistent.
In some circumstances, there may be reciprocity between windows. For example, changes on window
In the case of displayed data, there may be other windows that display the same or similar data which
Prepare one test case for every window object affected by a change or unsolicited event and one tes
Prepare one test case for every window object that must not be affected - but might be.
Non-Functional Testing
The tests described in the previous sections are functional tests. These tests are adequate for demons
Soak Testing
In production, systems might be operated continuously for many hours. Applications may be co
These tests are normally conducted using an automated tool. Selected transactions are repeat
Compatibility Testing
Whether applications interface directly with other desktop products or simply co-exist on the sa
These tests normally execute a selected set of transactions in the system under test and then s
Platform/Environment Testing
In some environments, the platform upon which the developed GUI application is deployed may
imise etc.)
, size, location
ed to be in place:
ubs and/or drivers will be necessary to implement navigation tests. If we assume all required components are ava
ow that the application should allow and create test cases for each call.
res that the application should allow and create test cases for each call.
hould return to the ‘calling’ window and create a test case for each.
before the called window appears.
dow i.e. menus, buttons, keyboard commands. In this circumstance, consider creating one test case for each valid
on testing that should be undertaken. These tests constitute the ‘visible’ integration testing of the GUI components
aken on a forms-based application. This testing focuses very much on the behaviour of the objects within windows
a client application with these other components. Because these interfaces may be hidden or appear ‘seamless’
roduct (i.e. a sequence of stages with different message types to test individually) or is it a direct call made once o
ch message type in circumstances where data is passed in both directions. Typically, once the nature of the inter
integration testing. This aspect covers the integration of a desktop application with the server-based processes it
h database servers. Here the particular tests to be applied should cover the various types of responses a databas
ommunication may be of interest. These tests might be automated, or timed using a stopwatch, to obtain indicative
e there are dependencies between different features. One scenario is when two windows are displayed, a chang
s open, then certain menu options become available (or unavailable).
otified to the application by an unsolicited event to update displayed windows.
other displayed window inconsistent.
dows. For example, changes on window A trigger changes in window B and the reverse effect also applies (chang
display the same or similar data which either cannot be displayed simultaneously, or should not change for some
change or unsolicited event and one test case for reciprocal situations.
be affected - but might be.
s. These tests are adequate for demonstrating the software meets it’s requirements and does not fail. However, G
for many hours. Applications may be comprehensively tested over a period of weeks or months but are not usual
d tool. Selected transactions are repeatedly executed and machine resources on the client (or the server) monitor
op products or simply co-exist on the same desktop, they share the same resources on the client. Compatibility Te
ions in the system under test and then switch to exercising other desktop products in turn and doing this repeated
veloped GUI application is deployed may not be under the control of the developers. PC end-users may have a va
ed components are available, what tests should we implement? We can split the task into steps:
test case for each valid path by each available means of navigation.
of the GUI components that a ‘black box’ tester should undertake.
objects within windows. The approach to testing a window is virtually the same as would be adopted when testin
or appear ‘seamless’ when working, the tester usually needs to understand a little more about the techn ical impl
e the nature of the interface is known, equivalence partitioning, boundary values analysis and other techniques ca
ver-based processes it must communicate with. The discussion of the types of test cases for this testin g is simila
are displayed, a change is made to a piece of data on one window and the other window needs to change to refle
ect also applies (changes in window B trigger changes on window A).
ld not change for some reason. These situations should be considered also. To derive synchronisation test cases
oes not fail. However, GUI applications have non-functional modes of failure also. We propose three addi tional GU
onths but are not usually operated for extended periods in this way. It is common for client application code and b
(or the server) monitored to identify resources that are being allocated but not returned by the application code.
client. Compatibility Tests are (usually) automated tests that aim to demonstrate that resources that are shared w
d-users may have a variety of hardware types such as 486 and Pentium machines, various video drivers, Microso
into steps:
ould be adopted when testing a single form. The traditional black-box test design techniques are directly applicabl
ore about the techn ical implementation of the interface before tests can be specified. The tester needs to know w
ysis and other techniques can be used to expand the list of test cases
ases for this testin g is similar to section 3.4 Desktop Integration, except there should be some attention paid to tes
ow needs to change to reflect the altered state of data in the database. To accommodate such dependencies, the
e synchronisation test cases:
propose three addi tional GUI test types (that are likely to be automated).
client application code and bespoke middleware to have memory-leaks. Soak tests exercise system transactions c
resources that are shared with other desktop products are not locked unnecessarily causing the system under te
arious video drivers, Microsoft Windows 3.1, 95 and NT. Most users have PCs at home nowadays and know how
niques are directly applicable in this context.
The tester needs to know what interfaces exist, what mechanisms are used by these interfaces and how the inte
date such dependencies, there is a need for the dependent parts of the application to be synchronised.
ercise system transactions continuously for an extended period in order to flush out such problems.
me nowadays and know how to customise their PC configuration. Although your application may be designed to op
interfaces and how the interface can be exercised by using the application user interface.
be synchronised.
uch problems.
cation may be designed to operate on a variety of platforms, you may have to execute tests of these various config
tests of these various configurations to ensure when the software is implemented, it continues to function as des
continues to function as designed. In this circumstance, the testing requirement is for a repeatable regression test
a repeatable regression test to be executed on a variety of platforms and configurations. Again, the requirement f
ns. Again, the requirement for automated support is clear so we would normally use a tool to execute these tests
a tool to execute these tests on each of the platforms and configurations as required.
GUI Testing Checklist
CONTENTS:
Section 1 - Windows Compliance Testing
1.1. Application
1.2. For Each Window in the Application
1.3. Text Boxes
1.4. Option (Radio Buttons)
1.5. Check Boxes
1.6. Command Buttons
1.7. Drop Down List Boxes
1.8. Combo Boxes
1.9. List Boxes
Section 2 - Tester’s Screen Validation Checklist
2.1. Aesthetic Conditions
2.2. Validation Conditions
2.3. Navigation Conditions
2.4. Usability Conditions
2.5. Data Integrity Conditions
2.6. Modes (Editable Read-only) Conditions
2.7. General Conditions
2.8. Specific Field Tests
2.8.1. Date Field Checks
2.8.2. Numeric Fields
2.8.3. Alpha Field Checks
Section 3 - Other
3.1. On every Screen
3.2. Shortcut keys / Hot Keys
3.3. Control Shortcut Keys
GUI SCREEN VALIDATION CHECKLIST Page 2 of 19
1. Windows Compliance
When returning return to the first screen cleanly i.e. no other screens/applications should appear.
In general, double-clicking is not essential. In general, everything can be done using both the mouse
and the keyboard.
All tab buttons should have a distinct letter.
Text Boxes
Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert
Bar. If it doesn't then the text in the box should be grey or non-updateable. Refer to previous page.
Enter text into Box
Try to overflow the text by typing to many characters - should be stopped Check the field width with
capitals W.
Enter invalid characters - Letters in amount fields, try strange characters like + , - * etc. in All fields.
SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double
Click should select all text in box.
Check Boxes
Clicking with the mouse on the box, or on the text should SET/UNSET the box. SPACE should do
the same
Command Buttons
If Command Button leads to another Screen, and if the user can enter or change details on the other
screen then the Text on the button should be followed by three dots.
All Buttons except for OK and Cancel should have a letter Access to them. This is indicated by a
letter underlined in the button text. The button should be activated by pressing ALT+Letter. Make
sure there is no duplication.
Click each button once with the mouse - This should activate
Tab to each button - Press SPACE - This should activate
Tab to each button - Press RETURN - This should activate
The above are VERY IMPORTANT, and should be done for EVERY command Button.
Tab to another type of control (not a command button). One button on the screen should be default
(indicated by a thick black border). Pressing Return in ANY no command button control should
activate it.
If there is a Cancel Button on the screen , then pressing <Esc> should activate it.
If pressing the Command button results in uncorrectable data e.g. closing an action step, there should
be a message phrased positively with Yes/No answers where Yes results in the completion of the
action.
AESTHETIC CONDITIONS:
1. Is the general screen background the correct colour?.
2. Are the field prompts the correct colour?
3. Are the field backgrounds the correct colour?
4. In read-only mode, are the field prompts the correct colour?
5. In read-only mode, are the field backgrounds the correct colour?
6. Are all the screen prompts specified in the correct screen font?
7. Is the text in all fields specified in the correct screen font?
8. Are all the field prompts aligned perfectly on the screen?
9. Are all the field edit boxes aligned perfectly on the screen?
10. Are all groupboxes aligned correctly on the screen?
11. Should the screen be resizable?
12. Should the screen be minimisable?
13. Are all the field prompts spelt correctly?
14. Are all character or alpha-numeric fields left justified? This is the default
unless otherwise specified.
15. Are all numeric fields right justified? This is the default unless otherwise
specified.
16. Is all the microhelp text spelt correctly on this screen?
17. Is all the error message text spelt correctly on this screen?
18. Is all user input captured in UPPER case or lower case consistently?
19. Where the database requires a value (other than null) then this should be
defaulted into fields. The user must either enter an alternative valid value
or leave the default value intact.
20. Assure that all windows have a consistent look and feel.
21. Assure that all dialog boxes have a consistent look and feel.
VALIDATION CONDITIONS:
1. Does a failure of validation on every field cause a sensible user error
message?
2. Is the user required to fix entries which have failed validation tests?
3. Have any fields got multiple validation rules and if so are all rules being
applied?
4. If the user enters an invalid value and clicks on the OK button (i.e. does
not TAB off the field) is the invalid entry identified and highlighted
correctly with an error message.?
5. Is validation consistently applied at screen level unless specifically required
at field level?
6. For all numeric fields check whether negative numbers can and should be
able to be entered.
7. For all numeric fields check the minimum and maximum values and also
some mid-range values allowable?
8. For all character/alphanumeric fields check the field to ensure that there is
a character limit specified and that this limit is exactly correct for the
specified database size?
9. Do all mandatory fields require user input?
10. If any of the database columns don’t allow null values then the
corresponding screen fields must be mandatory. (If any field which initially
was mandatory has become optional then check whether null values are
allowed in this field.)
NAVIGATION CONDITIONS:
1. Can the screen be accessed correctly from the menu?
2. Can the screen be accessed correctly from the toolbar?
3. Can the screen be accessed correctly by double clicking on a list control on
the previous screen?
4. Can all screens accessible via buttons on this screen be accessed correctly?
5. Can all screens accessible by double clicking on a list control be accessed
correctly?
6. Is the screen modal. i.e. Is the user prevented from accessing other
functions when this screen is active and is this correct?
7. Can a number of instances of this screen be opened at the same time and is
this correct?
USABILITY CONDITIONS:
1. Are all the dropdowns on this screen sorted correctly? Alphabetic sorting
is the default unless otherwise specified.
2. Is all date entry required in the correct format?
3. Have all pushbuttons on the screen been given appropriate Shortcut keys?
4. Do the Shortcut keys work correctly?
5. Have the menu options which apply to your screen got fast keys associated
and should they have?
6. Does the Tab Order specified on the screen go in sequence from Top Left
to bottom right? This is the default unless otherwise specified.
7. Are all read-only fields avoided in the TAB sequence?
8. Are all disabled fields avoided in the TAB sequence?
9. Can the cursor be placed in the microhelp text box by clicking on the text
box with the mouse?
10. Can the cursor be placed in read-only fields by clicking in the field with the
mouse?
11. Is the cursor positioned in the first input field or control when the screen is
opened?
12. Is there a default button specified on the screen?
13. Does the default button work correctly?
14. When an error message occurs does the focus return to the field in error
when the user cancels it?
15. When the user Alt+Tab’s to another application does this have any impact
on the screen upon return to The application?
16. Do all the fields edit boxes indicate the number of characters they will hold
by there length? e.g. a 30 character field should be a lot longer
GENERAL CONDITIONS:
1. Assure the existence of the "Help" menu.
2. Assure that the proper commands and options are in each menu.
3. Assure that all buttons on all tool bars have a corresponding key commands.
4. Assure that each menu command has an alternative(hot-key) key sequence which
will invoke it where appropriate.
5. In drop down list boxes, ensure that the names are not abbreviations / cut short
6. In drop down list boxes, assure that the list and each entry in the list can be
accessed via appropriate key / hot key combinations.
7. Ensure that duplicate hot keys do not exist on each screen
8. Ensure the proper usage of the escape key (which is to undo any changes that have
been made) and generates a caution message “Changes will be lost - Continue
yes/no”
9. Assure that the cancel button functions the same as the escape key.
10. Assure that the Cancel button operates as a Close button when changes have be
made that cannot be undone.
11. Assure that only command buttons which are used by a particular window, or in a
particular dialog box, are present. - i.e make sure they don’t work on the screen
behind the current screen.
12. When a command button is used sometimes and not at other times, assure that it is
grayed out when it should not be used.
13. Assure that OK and Cancel buttons are grouped separately from other command
buttons.
14. Assure that command button names are not abbreviations.
15. Assure that all field labels/names are not technical labels, but rather are names
meaningful to system users.
16. Assure that command buttons are all of similar size and shape, and same font &
font size.
17. Assure that each command button can be accessed via a hot key combination.
18. Assure that command buttons in the same window/dialog box do not have
duplicate hot keys.
19. Assure that each window/dialog box has a clearly marked default value (command
button, or other object) which is invoked when the Enter key is pressed - and NOT
the Cancel or Close button
20. Assure that focus is set to an object/button which makes sense according to the
function of the window/dialog box.
21. Assure that all option buttons (and radio buttons) names are not abbreviations.
22. Assure that option button names are not technical labels, but rather are names
meaningful to system users.
23. If hot keys are used to access option buttons, assure that duplicate hot keys do not
exist in the same window/dialog box.
24. Assure that option box names are not abbreviations.
25. Assure that option boxes, option buttons, and command buttons are logically
grouped together in clearly demarcated areas “Group Box”
26. Assure that the Tab key sequence which traverses the screens does so in a logical
way.
27. Assure consistency of mouse actions across windows.
28. Assure that the color red is not used to highlight active objects (many individuals
are red-green color blind).
29. Assure that the user will have control of the desktop with respect to general color
and highlighting (the application should not dictate the desktop background
characteristics).
30. Assure that the screen/window does not have a cluttered appearance
31. Ctrl + F6 opens next tab within tabbed window
32. Shift + Ctrl + F6 opens previous tab within tabbed window
33. Tabbing will open next tab within tabbed window if on last field of current tab
34. Tabbing will go onto the 'Continue' button if on last field of last tab within tabbed
window
35. Tabbing will go onto the next editable field in the window
36. Banner style & size & display exact same as existing windows
37. If 8 or less options in a list box, display all options on open of list box - should be
no need to scroll
38. Errors on continue will cause user to be returned to the tab and the focus should
be on the field causing the error. (i.e the tab is opened, highlighting the field with
the error on it)
39. Pressing continue while on the first tab of a tabbed window (assuming all fields
filled correctly) will not open all the tabs.
40. On open of tab focus will be on first editable field
41. All fonts to be the same
42. Alt+F4 will close the tabbed window and return you to main screen or previous
screen (as appropriate), generating "changes will be lost" message if necessary.
43. Microhelp text for every enabled field & button
44. Ensure all fields are disabled in read-only mode
45. Progress messages on load of tabbed screens
46. Return operates continue
47. If retrieve on load of tabbed window fails window should not open
Numeric Fields
Assure that lowest and highest values are handled correctly
Assure that invalid values are logged and reported
Assure that valid values are handles by the correct procedure
Assure that numeric fields with a blank in position 1 are processed or reported as an
error
Assure that fields with a blank in the last position are processed or reported as an error
an error
Assure that both + and - values are correctly processed
Assure that division by zero does not occur
Include value zero in all calculations
Include at least one in-range value
Include maximum and minimum range values
Include out of range values above the maximum and below the minimum
Assure that upper and lower values in ranges are handled correctly
On every Screen
Add
View
Change
Delete
Continue
Add
View
Change
Delete
Cancel
Fill each field - Valid data
Fill each field - Invalid data
Scroll Lists
Help
Fill Lists and Scroll
Tab
Tab Order
Shift Tab
Shortcut keys - Alt + F
Copy character values or numeric values with keyboard(ctrl+c) or mouse and paste it in the textbox with k
be displayed.
ect them with
be displayed,
h the mouse
on the other
there should
d paste it in the textbox with keyboard or mouse.
Classification of Errors by Severity
Often the severity of a software defect can vary even though the software never changes. The reason being is
For example, the severity of the Pentium’s floating-point defect changes from system to system. On some sys
Another problem (which occurs regularly) is that the definitions of the severity levels (or categories) themselve
Therefore, the system itself determines the severity of a defect based on the context for which the defect appli
I have attached two sample classification methods – a 3 level classification method, and a more comprehensive
• Category A - Serious errors that prevent System test of a particular function continuing or serious
• Category B - Serious or missing data related errors that will not prevent implementation.
Explanation of Classifications
1. An "A" bug is a either a showstopper or of such importance as to radically affect the functionality of the
§ If, because of a consistent crash during processing of a new application, a user could not complete
§ Incorrect data is passed to system resulting in corruption or system crashes
2. Bugs would be classified as "B" where a less important element of functionality is affected, e.g.:
§ a value is not defaulting correctly and it is necessary to input the correct value
§ data is affected which does not have a major impact, for example - where an element of a custom
§ there is an alternative method of completing a particular process - e.g. a problem might occur whic
§ Serious cosmetic error on front-end.
E.g.)
critical
loss of
data,
critical
loss of
system
availabilit
y, critical
loss of
security,
critical
loss of
safety,
etc.
2. Defects
Severe: that
could (or
did)
cause
very
serious
conseque
nces for
the
system
in
question.
E.g.) A
function
is
severely
broken,
cannot
be used
and
there is
no
workarou
nd.
3. Defects
Major: that
could (or
did)
cause
significan
t
conseque
nces for
the
system
in
question
-A
defect
that
needs to
be fixed
but there
is a
workarou
nd.
E.g. 1.)
losing
data
from a
serial
device
during
heavy
loads.
E.g. 2.)
Function
badly
broken
but
workarou
nd exists
4. Defects
Minor: that
could (or
did)
cause
small or
negligibl
e
conseque
nces for
the
system
in
question.
Easy to
recover
or
workarou
nd.
E.g.1)
Error
message
s
misleadin
g.
E.g.2)
Displayin
g output
in a font
or format
other
than
what the
customer
desired.
5. No Trivial
Effect: defects
that can
cause no
negative
conseque
nces for
the
system
in
question.
Such
defects
normally
produce
no
erroneou
s
outputs.
E.g.1)
simple
typos in
documen
tation.
E.g.2)
bad
layout or
mis-
spelling
on
screen.
es. The reason being is that a software defect’s severity depends on the system in which it runs.
o system. On some systems, the severity is small; whereas on other systems, the severity is high.
or categories) themselves change depending on the type of system. For example, a catastrophic defect in a nuclear system
r which the defect applies. The context makes all the difference in how to classify a defect’s severity.
d a more comprehensive 5 level classification method, which I hope you may find useful.
mplementation.
is affected, e.g.:
Testing software is operating the software under controlled conditions, to (1) verify that it behaves “as specifie
1. Verification is the checking or testing of items, including software, for conformance and consistency by eva
2. Error Detection: Testing should intentionally attempt to make things go wrong to determine if things happ
3. Validation looks at the system correctness – i.e. is the process of checking that what has been specified is
In other words, validation checks to see if we are building what the customer wants/needs, and verification che
The definition of testing according to the ANSI/IEEE 1059 standard is that testing is the process of analysing a
Remember: The purpose of testing is verification, validation and error detection in order to find problems – and
Testing in itself cannot ensure the quality of software. All testing can do is give you a certain level of assurance
Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expe
However, quality is a subjective term. It will depend on who the ‘customer’ is and their overall influence in the
“Quality Assurance” measures the quality of processes used to create a quality product.
Software Quality Assurance (‘SQA’ or ‘QA’) is the process of monitoring and improving all activities associated w
It involves the entire software development process - monitoring and improving the process, making sure that
Organisations vary considerably in how they assign responsibility for QA and testing. Sometimes they’re the co
Quality Assurance and development of a product are parallel activities. Complete QA includes reviews of the de
A note about quality assurance: The role of quality assurance is a superset of testing. Its mission is to help min
Simply put:
In well-run projects, the mission of the test team is not merely to perform testing, but to help minimise the ris
t it behaves “as specified”; (2) to detect errors, and (3) to validate that what has been specified is what the user actually
e and consistency by evaluating the results against pre-specified requirements. [Verification: Are we building the system r
determine if things happen when they shouldn’t or things don’t happen when they should.
at has been specified is what the user actually wanted. [Validation: Are we building the right system?]
eds, and verification checks to see if we are building that system correctly. Both verification and validation are necessary,
e process of analysing a software item to detect the differences between existing and required conditions (that is defects/e
r to find problems – and the purpose of finding those problems is to get them fixed.
ertain level of assurance (confidence) in the software. On its own, the only thing that testing proves is that under specific
all activities associated with software development, from requirements gathering, design and reviews to coding, testing an
ocess, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found an
ometimes they’re the combined responsibility of one group or individual. Also common are project teams that include a mi
cludes reviews of the development methods and standards, reviews of all the documentation (not just for standardisation
ts mission is to help minimise the risk of project failure. QA people aim to understand the causes of project failure (which
to help minimise the risk of product failure. Testers look for manifest problems in the product, potential problems, and the
what the user actually wanted.
ditions (that is defects/errors/bugs) and to evaluate the features of the software item.
es is that under specific controlled conditions, the software functioned as expected by the test cases executed.
opment project might include end-users, customer acceptance testers, customer contract officers, customer management
at problems are found and dealt with, at the earliest possible stage. Unlike testing, which is mainly a ‘detection’ process, Q
teams that include a mix of testers and developers who work closely together, with overall QA processes monitored by pro
just for standardisation but for verification and clarity of the contents also). Overall Quality Assurance processes also includ
f project failure (which includes software errors as an aspect) and help the team prevent, detect, and correct the problem
ential problems, and the absence of problems. They explore, assess, track, and report product quality, so that others in th
s executed.
customer management, the development organisation’s management/accountants/testers/salespeople, future software m
a ‘detection’ process, QA is ‘preventative’ in that it aims to ensure quality in the methods & processes – and therefore red
and correct the problems. Often test teams are referred to as QA Teams, perhaps acknowledging that testers should consid
lity, so that others in the project can make informed decisions about product development. It's important to recognise tha
eople, future software maintenance engineers, stockholders, magazine reviewers, etc. Each type of ‘customer’ will have th
portant to recognise that testers are not out to "break the code." We are not out to embarrass or complain, just to inform.
f ‘customer’ will have their own view on ‘quality’ - the accounting department might define quality in terms of profits while
Table of Contents:
1.1. Introduction
1.3. Why Usability Testing should be included as an element of the testing cycle
2 How to Approach Usability Testing
1.1. Introduction
My first introduction to Usability Testing came when I was a new tester in the Lending department of a large fin
A post mortem was then carried out on the software, and I was involved, as a representative of the test team.
The lessons learnt from that excercise were then implemented into any further developments, and saw the add
'Usability Testing' is defined as: "In System Testing, testing which attempts to find any human-factor problems
1.3. Why Usability Testing should be included as an element of the testing cycle.
I believe that QA have a certain responsibility for usability testing. There are several factors involved, but the m
To demonstrate, assume a new application is developed, that is exactly, 100%, in accordance with the design s
I remember a diagram that vividly showed this - it showed the design of a swing, with sections on "what the cu
This is especially true where the business processes that drive the design of the new application are very comp
Secondly, when a totally new or custom application is being developed, how many of the coders themselves (1
Even if the testers are indeed experts in their area, they may miss the big picture, so I think that usability test
Thirdly, apart from the usual commercial considerations, the success of some new software will depend on how
The best way to implement usability testing is two fold - firstly from a design & development perspective, then
From a design viewpoint, usability can be tackled by (1) Including actual Users as early as possible in the de
(2) Following on from the screen reviews, standards should be documented i.e. Screen Layout, Labelling/Nami
Where an existing system or systems are being replaced or redesigned, usability issues can be avoided by usin
3). Including provisions for usability within the design specification will assist later usability testing. Usually for
An example of a usability consideration within the functional specification may be as simple as specifying a min
4). At the unit testing stage, there should be an official review of the system - where most of those issues can
5). All the previous actions could be performed at an early stage if Prototyping is used. This is probably the bes
6). From a testing viewpoint, usability testing should be added to the testing cycle by including a formal "Us
User Acceptance Testing (UAT) is an excellent exercise, because not only will it give you there initial impression
(7) Another option to consider is to include actual users as testers within the test team. One financial organizat
8). The final option that may be to include user testers who are eventually going to be (a) using it themselves;
The benefits of having had usability considerations included in the development of computer software are imme
Apart from discovering and preventing possible usability issues, the addition of 'Usability Testers' to the test te
Refocus the testers and increase their awareness to usability issues, by providing a fresh viewpoint
Provide and share their expert knowledge - training the testers to the background and purpose of the system
Provide a "realistic" element to the testing, so that test scenarios are not just "possible permutations".
3. Summary:
In my experience, the greater the involvement of key users, the more pleased they will be with the end produc
4. Sources of Reference:
4.1. Publications
"The Case for Independent Software Usability Testing: Lessons Learned from a Successful Intervention". Author: David W. Biers.
Originally published: Proceedings of the Human Factors Society 33rd Annual Meeting, 1989, pp. 1218-1222
Republished: G. Perlman, G. K. Green, & M. S. Wogalter (Eds.) Human Factors Perspectives on Human-Computer Interaction: Selections from Pr
Http://www.acm.org/~perlman/hfeshci/Abstracts/89:1218-1222.html
http://aaa.gsfc.nasa.gov/ViewPage.cfm?selectedPage=48&selectedType=Product
1. A
Practica
l Guide
to
Usabilit
y
Testing.
Joseph
S.
Dumas &
Janice C.
Redish.
Norwood
, NJ:
Ablex
Publishin
g, 1993.
ISBN 0-
89391-
991-8.
This
step-by-
step
guide
provides
checklist
s and
offers
insights
for every
stage of
usability
testing.
2 Usabilit
y
Enginee
ring.
2
Jakob
Nielsen.
Boston,
MA:
Academi
c Press,
1993.
ISBN 0-
12-
518405-
0. This
book
immediat
ely sold
out when
it was
first
publishe
d. It is
an
practical
handboo
k for
people
who
want to
evaluate
systems.
3 Usabilit
y
Inspecti
on
Method
s.
3
Jakob
Nielsen &
Robert L.
Mack
(Eds.)
New
York:
John
Wiley &
Sons,
1994.
ISBN 0-
471-
01877-5.
This
book
contains
chapters
contribut
ed by
experts
on
usability
inspectio
ns
methods
such as
heuristic
evaluatio
n,
cognitive
walkthro
ughs,
and
others.
4 Cost-
Justifyi
ng
Usabilit
y.
4
Randolph
G. Bias &
Deborah
J.
Mayhew
(Eds.)
Boston:
Academi
c Press,
1994.
ISBN 0-
12-
095810-
4. This
edited
collection
contains
14
chapters
devoted
to the
demonst
ration of
the
importan
ce of
usability
evaluatio
n to the
success
of
software
develop
ment.
5 Usabilit
y in
Practice
: How
Compan
ies
Develop
User-
Friendly
Product
s
Michael
E.
Wiklund
(Ed.)
Boston:
Academi
c Press,
1994.
ISBN 0-
12-
751250-
0. This
collection
of
contribut
ed
chapters
describes
usability
practices
of 17
compani
es:
American
Airlines,
Ameritec
h, Apple,
Bellcore,
Borland,
Compaq,
Digital,
Dun &
Bradstre
et,
Kodak,
GE
Informati
on
Services,
GTE
Labs, H-
P, Lotus,
Microsoft
, Silicon
Graphics,
Thompso
n
Consume
r
Electroni
cs, and
Ziff
Desktop
Informati
on. It
amounts
to the
broadest
usability
ending department of a large financial institution. They had developed the first of a set of loan management applications (
representative of the test team. The investigation discovered that the software was not "user-friendly". Yet I, as a tester, h
developments, and saw the addition of "usability testing" to the system test cycle. The software was re-worked, and was
find any human-factor problems". [1] A better description is "testing the software from a users point of view". Essentially i
ing cycle.
veral factors involved, but the main reason is the 'perspective differences' or different viewpoints of the various teams inv
in accordance with the design specifications - yet, unfortunately, it is not fit for use - because it may be so difficult/awkw
g, with sections on "what the customer ordered", "What the development team built", "What the engineers installed" etc.,
e new application are very complex (for example bespoke financial applications).
any of the coders themselves (1) have actual first hand experience of the business processes/rules that form the basis of t
ure, so I think that usability testing is a sub-specialty that often is not best left to the average tester. Only some specific p
ew software will depend on how well it is received by the public - whether they like the application . Obviously if the s
ers as early as possible in the design stage. If possible, a prototype should be developed - failing that, screen layouts and
Screen Layout, Labelling/Naming conventions etc. These should then be applied throughout the application.
y issues can be avoided by using similar screen layouts - if they are already familiar with the layout the implementation o
ter usability testing. Usually for new application developments, and nearly always for custom application developments, th
where most of those issues can more easily be dealt with. At this stage, with screen layout & design already reviewed, the
is used. This is probably the best way to identify any potential usability/operability problems. You can never lessen the im
g cycle by including a formal "User Acceptance Test". This is done by getting several actual users to sit down with the soft
give you there initial impression of the system and tell you how readily the users will take to it, but this way it will tell you
st team. One financial organization I was involved with reassigned actual users as "Business Experts" as members of the t
g to be (a) using it themselves; and/or (b) responsible for training and effectively "selling" it to the users.
of computer software are immense, but often unappreciated. The benefits are too numerous to list - I'd say it's similar to
'Usability Testers' to the test team can have a very positive effect on the team itself. Several times I have seen that teste
"possible permutations".
they will be with the end product. Getting management to commit their key people to this effort can be difficult, but it ma
-Computer Interaction: Selections from Proceedings of Human Factors and Ergonomics Society Annual Meetings, 1983-1994, Santa Monica, CA: HFES, 1995, pp. 1
nagement applications (and almost as an afterthought decided they'd better test it). The application was very good, and o
dly". Yet I, as a tester, had not considered usability or operability to be a problem. We then sat down with several of the u
as re-worked, and was re-released. The revamped version, although containing mostly cosmetic (non-functional) changes
nt of view". Essentially it means testing software to prove/ensure that it is 'user-friendly', as distinct from testing the func
may be so difficult/awkward to use, or it ends up so complicated that the users don't want it or won't use it. Yet, it is what
ngineers installed" etc., with the effect of illustrating the different perspectives of the various people involved.
that form the basis of the application being developed; and/or (2) how many of the coders will actually end up using the
er. Only some specific personnel should be responsible for doing Usability Testing.
tion . Obviously if the s/w is bug ridden then the popularity of the s/w will suffer; aside from that, if it is a high quality de
hat, screen layouts and designs should be reviewed on-screen and any problems highlighted.. The earlier that potential us
ut the implementation of the new system will present less of a challenge, as it will be more easily accepted (provided of co
cation developments, the design team should either have an excellent understanding of the business processes/rules/logic
n already reviewed, the focus should be on how a user navigates through the system. This should identify any potential is
can never lessen the importance of user-centered design, but you can solve usability problems before they get to the QA s
o sit down with the software and attempt to perform "normal" working tasks, when the software is near release quality. I s
ut this way it will tell you whether the end product is a closer match to their expectations and there are fewer surprises. (E
rts" as members of the test team. I found their input as actual "tester users" was invaluable.
st - I'd say it's similar to putting the coat of paint on a new car - the car itself will work without the paint, but it doesn't loo
s I have seen that testers become too familiar with the "quirks" of the software - and not report a possible error or usabilit
an be difficult, but it makes for a better product in the long run.
non-functional) changes proved to be a success; although the damage was done - there was a little more reluctance to acc
ct from testing the functionality of the software. In practical terms it includes ergonomic considerations, screen design, sta
't use it. Yet, it is what the design specified. This has happened, and will happen again.
le involved.
tually end up using the finished product ? Answer: Usually none. (3) How many of the test team do have first hand experi
if it is a high quality development the popularity of the s/w will still depend on the usability (albeit to a lesser degree). It w
earlier that potential usability issues are discovered the easier it is to fix them.
ccepted (provided of course, that that is not why the system is being replaced).
ss processes/rules/logic behind the system being developed; and include users with first hand knowledge of same. Howev
identify any potential issues such as having to open an additional window where one would suffice. More commonly thoug
ore they get to the QA stage (thereby cutting the cost of rebuilding the product to correct the problem) by using prototype
near release quality. I say "normal" working tasks because testers will have been testing the system from/using test case
are fewer surprises. (Even though usability testing at the later stages of development may not impact software changes,
paint, but it doesn't look good. To summarise the benefits I would just say that it makes the software more "user friendly
possible error or usability issue. Often this is due to the tester thinking either "It's always been like that" or "isn't that th
rd, away from paper forms and huge filing cabinets, to an online system which would manage and track all actions previo
This showed that testers have a different viewpoint than users. I was so familiar with the system that I didn't consider so
e more reluctance to accept the software because they had "heard that it wasn't much good".
o have first hand experience or the expert knowledge of the underlying business logic/processes ? Answer: Usually minima
to a lesser degree). It would be a pity (but it wouldn't be the first time) that an application was not a success because it w
wledge of same. However, although they design the system, they rarely specifically include usability provisions in the spec
. More commonly though, the issues that are usually identified at this stage relate to the default or most common actions.
lem) by using prototypes (even paper prototypes) and other "discount usability" testing methods.
em from/using test cases - i.e. not from a users viewpoint. User testers must always take the customer's point of view in t
pact software changes, it is useful to point out areas where training is needed to overcome deficiencies in the software.
e that" or "isn't that the way it's supposed to be ?". These types of problem can be allieviated by including user testers in
track all actions previously written by hand. When version 1.0 was ready, it went into one of the larger regional offices on
that I didn't consider some convoluted key strokes to be a problem, until I saw them from a new users perspective. It tur
ot a success because it wasn't readily accepted - because it was not user friendly, or because it was too complex or difficul
r most common actions. For example, where a system is designed to cope with multiple eventualities and thus there are 1
es and thus there are 15 fields on the main input screen - yet 7 or 8 of these fields are only required in rare instances. Th
the pilot implementation was a disaster, and the release was postponed. The intended users wouldn't use the application,
ducational for any tester or developer.
ed in rare instances. These fields could then be set as hidden unless triggered, or moved to another screen altogether.
dn't use the application, and went back to doing things by hand. It quickly became clear that the reason was not that the s
er screen altogether.
eason was not that the software didn't work, but that they couldn't work the software. At first it was assumed that this wa
as assumed that this was because it was such a technological leap forward - i.e. they were unfamiliar with computers as a
ar with computers as a whole, resistant to change and reluctant to accept new technology. However, this was not the main
er, this was not the main problem - the problem was with the software itself.
Microsoft Word Files - Table of Contents
Acceptance Form
Acceptance Test Plan
Action Item Log
Change Control Form
Change Control Log
Change Control Log - Detailed
Change Request Form
Data Access Control Form
Enhancement Request Form
Installation Completion Form
Issue Log
QA / Program Manager Checklist
Quality Log
Release Control Form
Requirements Testing Report
Risk Log
Risk Management Plan Form
Software Test Plan Template
System Final Release Sign-off Form
System Requirements Sign-off Form
System Test Cycle Sign-off Form
System Test Environment Sign-off Form
System Test Plan Sign-off Form
System Test Sign-off Form
Test Case Template
Test Case Validation Log
Test Plan Review Checklist
Test Plan Task Preparation
Test Record
Test Script Allocation Form
Test Script
Team Roles and Responsibilities Form
Team Training Requirements Form
Unit Test Plan
User Acceptance Test (UAT) Report
Version Control Log
Web Usability Test Report
Worksheet
Change Control
Log
Change History
Log
Data Access
Control
Log Status
Failed Scripts
Open Issues
Quality Log
Risk Log
Roles and
Responsibilities
Status Report
Test Script
Task Preparation
Test Case
Test Tracking
Report
Validation Log
Version Control
Log
Web Usability
Report
FAQs
Immediately after you pay online, you are sent to a page where you can download the templates
online.
FAQ: What is the End User License Agreement?
oft Word Files - Table of Contents
ptance Form
ptance Test Plan
n Item Log
ge Control Form
ge Control Log
ge Control Log - Detailed
ge Request Form
Access Control Form
ncement Request Form
lation Completion Form
Log
Program Manager Checklist
ty Log
se Control Form
rements Testing Report
Log
Management Plan Form
are Test Plan Template
m Final Release Sign-off Form
m Requirements Sign-off Form
m Test Cycle Sign-off Form
m Test Environment Sign-off Form
m Test Plan Sign-off Form
m Test Sign-off Form
Case Template
Case Validation Log
Plan Review Checklist
Plan Task Preparation
Record
Script Allocation Form
Script
Roles and Responsibilities Form
Training Requirements Form
Test Plan
Acceptance Test (UAT) Report
on Control Log
Usability Test Report
For each Person or Group, identify the individuals who have access to the test cases
and their status, e.g. all DEV has access to the Test Cases for Web Project 22B.
For each log, identify its Log ID, the nature of the risk/issue, and whether it is Open or
Closed.
Identify the Area where the script failed, and provide details on the Set, Date, with a
description of the error and its Severity, e.g. minor error, major error etc.
Identify all the open issues by number (#); list when they were created; who raised
them, provide a brief description with details of its Assigned/Target Date/Category,
Status (e.g. Open of Closed), Resolution and its Resolution Date.
When performing the checks, identify the Ref #, its Module, the Method of Checking,
name of the Tester, its Planned Date, Date Completed, details of the Result, the Action
Items (i.e. tasks) and the Sign-off Date.
Identify the Risk Number, its Date, Type (e.g Business/Project/Stage) a brief
description, Likelihood %, Severity (e.g. Low or Medium) Impact, Action Required, who
is was Assigned To and its Status.
Identify all the roles on the project, with details of their responsibilities. Include contact
names and email addresses.
Identify the function that is under test, enter its Business value on a scale of 1-5 with 1
the lowest value and 5 the highest (or whichever numbering system you wish to use);
details of the problem severity broken out by a factor of 1 to 5. The total number of
issues (a.k.a anomalies) is calculated in the final column.
Enter the Area under test, its Set, whether it has Passed or Failed, with a Description of
the Error and its Severity, e.g. L/M/H
Enter the Area under test, its Test Case ID, Bug ID, Bug Fixed Date, Bug Fixed By and
Fix verified By details.
Use this checklist to prepare for the Test Plan: Review Software Requirements
Specifications, Identify functions/modules for testing, Perform Risk Analysis. The
second checklist is for the Test Plan Population and helps to: Identify/Prioritize features
to be tested, Define Test Strategy; Identify Test Tools; Identify Resource Requirements
etc.
This Test Case template is used to capture the name of the Test Case; its Description;
Start Conditions; Pass Criteria; Tester Name; Build Number; identify the Test Data
Used; Steps, Action and Expected Result.
Use this to track the progress of the software tests each Week, capture which are
Planned, were Attempted and numbers that are Successful.
Use this to capture the Project’s Completion Date; Test Event; Test Case ID; Test
Date; Tester; Test Results and Status
Use this to track the Product’s Version No., its Date, and Approvals.
Use this to analyze the usability of a web project, such as the performance of its
Navigation, Graphics, Error Messages, and the quality of its Microcontent
What file formats are the templates?
iately after you pay online, you are sent to a page where you can download the templates
1. Module Overview
Briefly define the purpose of this module. This may require only a single phrase: i.e.: calculates overtime pay
amount, calculates equipment depreciation, performs date edit validation, or determines sick pay eligibility, etc.
[Provide a brief description of the outputs from the module under test.]
[Representative data samples should provide a spectrum of valid field and processing values including "Syntactic"
permutations that relate to any data or record format issues. Each test case should be numbered, indicate the
nature of the test to be performed and the expected proper outcome.]
[The invalid data selection contains all of the negative test conditions associated with the module. These include
numeric values outside thresholds, invalid Characters, invalid or missing header/trailer record, and invalid data
structures (missing required elements, unknown elements, etc.)
3. Interface Modules
[Identify the modules that interface with this module indicating the nature of the interface: outputs data to, receives
input data from, internal program interface, external program interface, etc. Identify sequencing required for
subsequent string tests or sub-component integration tests.]
4. Test Tools
[Identify any tools employed to conduct unit testing. Specify any stubs or utility programs developed or used to
invoke tests. Identify names and locations of these aids for future regression testing. If data supplied from unit test
of coupled module, specify module relationship.]
5. Archive Plan
[Specify how and where data is archived for use in subsequent unit tests. Define any procedures required to obtain
access to data or tools used in the testing effort. The unit test plans are normally archived with the corresponding
module specifications.]
6. Updates
[Define how updates to the plan will be identified. Updates may be required due to enhancements, requirements
changes, etc. The same unit test plan should be re-used with revised or appended test cases identified in the update
section.]
Unit Test Plan
Program ID: ___________
ew
urpose of this module. This may require only a single phrase: i.e.: calculates overtime pay
equipment depreciation, performs date edit validation, or determines sick pay eligibility, etc.
ule
Module
agram
Cases
a samples should provide a spectrum of valid field and processing values including "Syntactic"
elate to any data or record format issues. Each test case should be numbered, indicate the
be performed and the expected proper outcome.]
Cases
election contains all of the negative test conditions associated with the module. These include
side thresholds, invalid Characters, invalid or missing header/trailer record, and invalid data
required elements, unknown elements, etc.)
les
es that interface with this module indicating the nature of the interface: outputs data to, receives
ernal program interface, external program interface, etc. Identify sequencing required for
ests or sub-component integration tests.]
employed to conduct unit testing. Specify any stubs or utility programs developed or used to
fy names and locations of these aids for future regression testing. If data supplied from unit test
specify module relationship.]
here data is archived for use in subsequent unit tests. Define any procedures required to obtain
ols used in the testing effort. The unit test plans are normally archived with the corresponding
ns.]
s to the plan will be identified. Updates may be required due to enhancements, requirements
ame unit test plan should be re-used with revised or appended test cases identified in the update
Some suggested starting points for a reader-friendliness checklist include:
Clarity of Communication
Does it use language in a way that is familiar to and comfortable for its readers?
Accessibility
Does it make effective use of repeating visual themes to unify the site?
Navigation
Is there a convenient, obvious way to maneuver among related pages, and between
different sections?
Design & maintenance
Does the site make effective use of hyperlinks to tie related items together?
Visual Presentation
(for example, through the use of an easily recognizable ALINK color, or a "reply"
screen for forms-based pages)