This action might not be possible to undo. Are you sure you want to continue?
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).the GUI does not have a cluttered appearance (GUIs should not be 46. Assure that designed to look like a mainframe character user interfaces (CUIs) when replacing such data entry/retrieval screens)
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 Low level - maps to a unit test stage. Application - maps to either a unit test or functional system test stage. Integration - maps to a functional system test stage. Non-functional - maps to non-functional system test stage.
Stage Low Level Application Test Types Checklist testing Navigation Equivalence Partitioning Boundary Values Decision Tables State Transition Testing Desktop Integration C/S Communications Synchronisation Soak testing Compatibility testing Platform/environment
Checklist Testing Programming/GUI standards covering standard features such as: window size, positioning, type (modal/non-modal) standard system commands/buttons (close, minimise, maximise etc.) Application standards or conventions such as: standard OK, cancel, continue buttons, appearance, colour, size, location consistent use of buttons or controls object/field labelling to use standard/consistent tex Navigation Testing To conduct meaningful navigation tests the following are required to be in place:
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
Technique Used to test Equivalence Partitions and Input validation Boundary Value Analysis Simple rule-based processing Decision Tables State-transition testing Complex logic or rule-based processing Applications with modes or states where processing behaviour is affected Windows where there are dependencies between objects in the window.
Desktop Integration Testing
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
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
Logging into the network, servers and server-based DBMS. Single and multiple responses to queries. Correct handling of errors (where the SQL syntax is incorrect, or the database server or network has Null and high volume responses (where no rows or a large number of rows are returned).
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
Test Types Checklist testing
Manual or Automated? Manual execution of tests of application conventions
Automated execution of tests of object states, menus and standard features Navigation Automated execution. Equivalence Partitioning, Automated execution of large numbers of Boundary Values, Decision simple tests of the same functionality or Tables, State Transition process e.g. the 256 combinations indicated by Testing a decision table. Manual execution of low volume or complex tests Automated execution of repeated tests of simple transactions
Desktop Integration, C/S Communications
Manual tests of complex interactions Synchronisation Manual execution. Soak testing, Compatibility Automated execution. testing, Platform/environment
p the four test stages to traditional test stages as follows:
, size, location
ed to be in place:
ons and call mechanisms to call the window under test.
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’ questions for each known interface:
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
, or the database server or network has failed) umber of rows are returned).
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
direct call made once only?
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
of responses a database server can make. For example:
atch, to obtain indicative measures of speed.
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
and doing this repeatedly over an extended period.
d-users may have a variety of hardware types such as 486 and Pentium machines, various video drivers, Microso
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
ed by the application code.
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
be some attention paid to testing for failure of server-based processes.
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.
causing the system under test or the other products to fail.
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.
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 Section 4 Right Click option 1. Windows Compliance WINDOWS COMPLIANCE TESTING For Each Application Start Application by Double Clicking on its ICON The Loading message should show the application name, version number, and a bigger pictorial representation of the icon. No Login is necessary The main window of the application should have the same caption as the caption of the icon in Program Manager. Closing the application should result in an "Are you Sure" message box Attempt to start application Twice This should not be allowed - you should be returned to main Window Try to start the application twice as it is loading. On each window, if the application is busy, then the hour glass should be displayed. If there is no hour glass (e.g. alpha access enquiries) then some enquiry in progress message should be displayed. All screens should have a Help button, F1 should work doing the same.
For Each Window in the Application If Window has a Minimise Button, click it. Window Should return to an icon on the bottom of the screen
This icon should correspond to the Original Icon under Program Manager. Double Click the Icon to return the Window to its original size. The window caption for every application should have the name of the application and the window name - especially the error messages. These should be checked for spelling, English and clarity , especially on the top of the screen. Check does the title of the window makes sense. If the screen has an Control menu, then use all ungreyed options. (see below) Check all text on window for Spelling/Tense and Grammar Use TAB to move focus around the Window. Use SHIFT+TAB to move focus backwards. Tab order should be left to right, and Up to Down within a group box on the screen. All controls should get focus - indicated by dotted box, or cursor. Tabbing to an entry field with text in it should highlight the entire text in the field. The text in the Micro Help line should change - Check for spelling, clarity and non-updateable etc. If a field is disabled (greyed) then it should not get focus. It should not be possible to select them with either the mouse or by using TAB. Try this for every greyed control. Never updateable fields should be displayed with black text on a grey background with a black label. All text should be left-justified, followed by a colon tight to it. In a field that may or may not be updateable, the label text and contents changes from black to grey depending on the current status. List boxes are always white background with black text whether they are disabled or not. All others are grey. In general, do not use goto screens, use gosub, i.e. if a button causes another screen to be displayed, the screen should not hide the first screen, with the exception of tab in 2.0
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.
Option (Radio Buttons) Left and Right arrows should move 'ON' Selection. So should Up and Down.. Select with mouse by clicking.
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.
Drop Down List Boxes Pressing the Arrow should give list of options. This List may be scrollable. You should not be able to type text in the box. Pressing a letter should bring you to the first item in the list with that start with that letter. Pressing ‘Ctrl - F4’ should open/drop down the list box. Spacing should be compatible with the existing windows spacing (word etc.). Items should be in alphabetical order with the exception of blank/none which is at the top or the bottom of the list box. Drop down with the item selected should be display the list with the selected item on the top. Make sure only one space appears, shouldn't have a blank line at the bottom. Combo Boxes Should allow text to be entered. Clicking Arrow should allow user to choose from list List Boxes Should allow a single selection to be chosen, by clicking with the mouse, or using the Up and Down Arrow keys. Pressing a letter should take you to the first item in the list starting with that letter. If there is a 'View' or 'Open' button beside the list box then double clicking on a line in the List Box, should act in the same way as selecting and item in the list box, then clicking the command button. Force the scroll bar to appear, make sure all the data can be seen in the box.
2. Screen Validation Checklist 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 DATA INTEGRITY CONDITIONS: 1. Is the data saved when the window is closed by double clicking on the close box? 2. Check the maximum field lengths to ensure that there are no truncated characters? 3. 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. 4. Check maximum and minimum field values for numeric fields? 5. If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers? 6. If a set of radio buttons represent a fixed set of values such as A, B and C then what happens if a blank value is retrieved from the database? (In some situations rows can be created on the database by other functions which are not screen based and thus the required initial values can be incorrect.) 7. If a particular set of data is saved to the database check that each value gets saved fully to the database. i.e. Beware of truncation (of strings) and rounding of numeric values. MODES (EDITABLE READ-ONLY) CONDITIONS: 1. Are the screen and field colours adjusted correctly for read-only mode? 2. Should a read-only mode be provided for this screen? 3. Are all fields and controls disabled in read-only mode? 4. Can the screen be accessed from the previous screen/menu/toolbar in readonly mode? 5. Can all screens available from this screen be accessed in read-only mode? 6. Check that no validation is performed in read-only mode. 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
Specific Field Tests
Date Field Checks Assure that leap years are validated correctly & do not cause errors/miscalculations Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations Assure that 00 and 13 are reported as errors Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations Assure that Feb. 30 is reported as an error Assure that century change is validated correctly & does not cause errors/ miscalculations Assure that out of cycle dates are validated correctly & do not cause errors/miscalculations 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 Alpha Field Checks Use blank and non-blank data Include lowest and highest values Include invalid characters & symbols Include valid characters Include data items with first position blank Include data items with last position blank VALIDATION TESTING - STANDARD ACTIONS On every Screen Add View Change
Delete Continue Add View Change Delete Cancel Fill each field - Valid data Fill each field - Invalid data Different Check Box combinations Scroll Lists Help Fill Lists and Scroll Tab Tab Order Shift Tab Shortcut keys - Alt + F
SHORTCUT KEYS / HOT KEYS
CONTROL SHORT KEYS Recommended CTRL+Letter Shortcuts
Section 4 Right Click option
Copy character values or numeric values with keyboard(ctrl+c) or mouse and paste it in the textbox with k
ect them with
h the mouse
on the other
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
3 Level Error Classification Method
Errors, which are agreed as valid, will be categorised as follows :• • •
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. Category C - Minor errors that do not prevent or hinder functionality.
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
Example of severally affected functionality: § Calculation of repayment term/amount are incorrect § Incorrect credit agreements produced
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.
"C" type bugs are mainly cosmetic bugs i.e.: § § Incorrect / misspelt text on screens drop down lists missing or repeating an option
5 Level Error Classification Method
1. Defects Catastr that ophic: could (or did) cause disastrou s conseque nces for the system in question. 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. Major: Defects 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
Defects 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 Effect:
Trivial 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 misspelling 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.
on continuing or serious data type error
t the functionality of the system i.e. :
user could not complete that application.
is affected, e.g.:
an element of a customer application was not propagated to the database roblem might occur which has a work-around.
efect in a nuclear system means that the fault can result in death or environmental harm; a catastrophic defect in a datab
rophic defect in a database system means that the fault can (or did) cause the loss of valuable data.
What is Software Testing...?
1. What is Software Testing 2. Why Testing CANNOT Ensure Quality 3. What is Software Quality? 4. What is Quality Assurance? 5. Software Development & Quality Assurance 6. The difference between QA & Testing 7. The Mission of Testing
1. What is Software Testing? Software testing is more than just error detection;
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
2. Why Testing CANNOT Ensure Quality
Testing in itself cannot ensure the quality of software. All testing can do is give you a certain level of assurance
3. What is Software “Quality”?
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 4. What is “Quality Assurance”? “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
5. Quality Assurance and Software Development
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
6. What’s the difference between QA and testing? Simply put: TESTING means “Quality Control”; and QUALITY CONTROL measures the quality of a product; while QUALITY ASSURANCE measures the quality of processes used to create a quality product.
7. The Mission of Testing
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
quirements and/or expectations, and is maintainable.
overall influence in the scheme of things. A wide-angle view of the ‘customers’ of a software development project might in
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.
we building the system right?]
alidation are necessary, but different components of any testing activity.
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
ws to coding, testing and implementation.
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
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
cesses monitored by project managers or quality managers.
nce processes also include code validation.
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
sses – and therefore reduce the prevalence of errors in the software.
hat testers should consider broader QA issues as well as testing.
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
omplain, just to inform. We are human meters of product quality.
in terms of profits while an end-user might define quality as user-friendly and bug-free.
Software Quality Assurance & Usability Testing
The role of User Testing in Software Quality Assurance.
Table of Contents: 1 1.1. The Role of User Testing in Software Quality Assurance Introduction
What is 'Usability Testing'
Why Usability Testing should be included as an element of the testing cycle How to Approach Usability Testing
How to Implement Usability Testing
The Benefits of Usability Testing
2.3. 3 4
The Role and benefits of "Usability Testers" Summary Sources of Reference & Internet Links
1. The role of User Testing in Software Quality Assurance.
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
1.2. What is 'Usability Testing'
'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
2. How to approach Usability Testing
2.1. How to Implement Usability Testing
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;
2.2. The Benefits of Usability Testing
The benefits of having had usability considerations included in the development of computer software are imme Better quality software. Software is easier to use. Software is more readily accepted by users. Shortens the learning curve for new users.
2.3. The Role and benefits of "Usability Testers"
Apart from discovering and preventing possible usability issues, the addition of 'Usability Testers' to the test te They can also help to: 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".
1 Usability evaluation should be incorporated earlier in the software development cycle to minimize resistance to changes in a hardened user interface; 2 Organizations should have an independent usability evaluation of software products to avoid the temptation to overlook problems to release the product;
3 Multiple categories of dependent measures should be employed in usability testing because subjective measurement is not always consonant with user performance; and 4 Even though usability testing at the later stages of development may not impact software changes, it is useful to point out areas where training is needed to overcome deficiencies in the software.
In my experience, the greater the involvement of key users, the more pleased they will be with the end produc
4. Sources of Reference:
"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
NASA Usability Testing Handbook
A Practica l Guide to Usabilit y Testing.
Joseph S. Dumas & Janice C. Redish. Norwood , NJ: Ablex Publishin g, 1993. ISBN 089391991-8. This step-bystep guide provides checklist s and offers insights for every stage of usability testing. 2 Usabilit y Enginee ring.
Jakob Nielsen. Boston, MA: Academi c Press, 1993. ISBN 0125184050. 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.
Jakob Nielsen & Robert L. Mack (Eds.) New York: John Wiley & Sons, 1994. ISBN 047101877-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 CostJustifyi ng Usabilit y.
Randolph G. Bias & Deborah J. Mayhew (Eds.) Boston: Academi c Press, 1994. ISBN 0120958104. 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 UserFriendly Product s
Michael E. Wiklund (Ed.) Boston: Academi c Press, 1994. ISBN 0127512500. 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, HP, 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".  A better description is "testing the software from a users point of view". Essentially i
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
development perspective, then from a testing perspective.
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
be as simple as specifying a minimum size for the 'Continue' button.
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
ding a fresh viewpoint
ound and purpose of the system "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
rvention". Author: David W. Biers.
-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
of the various teams involved in the development of the software.
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 und erstanding 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.
Monica, CA: HFES, 1995, pp. 191-195.
on was very good, and of high quality. Technologically speaking the software was a big step forward, away from paper for
wn with several of the users, and got them to go through the application with us screen by screen. This showed that teste
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.
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".
tions, screen design, standardisation etc.
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 would be the first time) that an application was not a success because it w n't
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.
ware more "user friendly". The end result will be:
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
Answer: Usually minimal.
ot a success because it wasn't readily accepted - because it was not user friendly, or because it was too complex or difficul
ty provisions in the specifications.
r most common actions. For example, where a system is designed to cope with multiple eventualities and thus there are 1
omer's point of view in their testing.
ncies in the software.
including user testers in the test team.
arger regional offices on pilot, the intention being to then gradually release it nationally. However, the pilot implementation
sers perspective. It turned out to be a very important lesson for me - and indeed would be very educational for any teste
s too complex or difficult to use.
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 technolog ical 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 Microsoft Excel Files - Table of Contents
Microsoft Excel - Table of Contents
Action Item Log
Change Control Log
Change History Log
Data Access Control
Roles and Responsibilities
Test Script List
Test Tracking Report
Version Control Log
Web Usability Report
FAQs FAQ: What file formats are the templates? All files are in Microsoft Word and are Anti-Virus free! FAQ: How soon can I download them? 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
oft Excel Files - Table of Contents
Microsoft Excel - Table of Contents
Use this template to:
Allocate an action item number, description, status (Low/Medium/High), date reported, resource it was assigned to, its due date, and other additional comments Identify the basis for the change; confirm whether it is disapproved or approved. Include the Software Change Request Number (SCR) #, Requirements (Rqmnt) #, date submitted, and whether it is approved/not approved, on hold, in progress, or cancelled.
Describe the date, author and history.
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? are in Microsoft Word and are Anti-Virus free!
ow soon can I download them?
iately after you pay online, you are sent to a page where you can download the templates
What is the End User License Agreement?
Unit Test Plan Module ID: _________
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.
1.1 Inputs to Module
[Provide a brief description of the inputs to the module under test.]
1.2 Outputs from Module
[Provide a brief description of the outputs from the module under test.]
1.3 Logic Flow Diagram
[Provide logic flow diagram if additional clarity is required.]
2. Test Data
(Provide a listing of test cases to be exercised to verify processing logic.)
2.1 Positive Test Cases
[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.]
2.2 Negative Test Cases [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: ___________
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.
scription of the inputs to the module under test.]
scription of the outputs from the module under test.]
diagram if additional clarity is required.]
f test cases to be exercised to verify processing logic.)
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.]
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.)
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 the site convey a clear sense of its intended audience? Does it use language in a way that is familiar to and comfortable for its readers? Is it conversational in its tone? Accessibility Is load time appropriate to content, even on a slow dial-in connection? Is it accessible to readers with physical impairments? Is there an easily discoverable means of communicating with the author or administrator? Consistency Does the site have a consistent, clearly recognizable "look-&-feel"? Does it make effective use of repeating visual themes to unify the site? Is it visually consistent even without graphics? Navigation Does the site use (approximately) standard link colors? Are the links obvious in their intent and destination? 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? Are there dead links? Broken CGI scripts? Functionless forms? Is page length appropriate to site content? Visual Presentation Is the site moderate in its use of color? Does it avoid juxtaposing text and animations? Does it provide feedback whenever possible? (for example, through the use of an easily recognizable ALINK color, or a "reply" screen for forms-based pages) When testing a web based program, I look at testing the following:
How doescontent for layout, spelling Check its the Web site look? mistakes, etc. or logic (Organised)? on How is the flow the pages
Overall presentation Link testing? Navigation testing Memory demands No needless big files, etc. How fast is the system? Are there any processes running? Any forms, reports, queries? Then test them accordingly Check HTML aspects
Time testing (meaning how fast it is) Load testing .. and other things in usability, system testing?
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.