Manual Testing

Why is Testing important?

Testing is required to detect the defects, to improve the quality of product, to make the system more reliable and stable

•  People make mistakes or errors.
•  Errors made can cause faults or defects.
•  Defects can cause failures.
• Product or deliverable can end up to be defective.

As any errors created within the system development life cycle can lead to so many faults within the software, which will eventually lead to the failure of the software.

Error – Mistake made by human.

Fault – The result of an error also known as bugs or defects.

Failure – The result of the fault. This leads to the deviation of the software from its expected results.

If a system has been well tested to the agreed specification, the result should be a reliable system that does what the user requires it to do.

Shortcut Keys/Hot Keys

Key	No Modifier	SHIFT	CRTL	ALT
F1	Help	Enter Help Mode	N\A	N\A
F2	N\A	N\A	N\A	N\A
F3	N\A	N\A	N\A	N\A
F4	N\A	N\A
F5	N\A	N\A	N\A	N\A
F6	Move Clockwise to next pane of active window	Move Counterclockwise to next pane of active window	Move to next document window; top window moves to bottom of stack (adding SHIFT reverses action : previous window moves to top.	Move to application's next open nondocument window (Adding SHIFT reverses order of movement)
F7	N\A	N\A	N\A	N\A
F8	Toggle extend mode, if supported	Toggle Add mode, if supported	N\A	N\A
F9	N\A	N\A	N\A	N\A
F10	Toggle menu Bar activation	N\A	N\A	N\A
F11, F12	N\A	N\A	N\A	N\A

CONTROL SHORT KEYS

Recommended CTRL+Letter Shortcuts

Key Function

CTRL+Z Undo

CTRL+X Cut

CTRL+C Copy

CTRL+V Paste

Suggested CTRL+Letter Shortcuts

Key Function

CTRL+N New

CTRL+O Open

CTRL+P Print

CTRL+S Save

CTRL+B Bold*

CTRL+I Italic*

CTRL+U Underline*

Tester’s Screen Validation Checklist

1.1. Validation Conditions

1.2. Aesthetic Conditions

1.3. Usability Conditions

1.4. Navigation Conditions

1.5. Modes (Editable Read-only) Conditions

1.6. Data Integrity Conditions

1.7. General Conditions

1.8. Specific Field Tests

1.8.1. Date Field Checks

1.8.2. Numeric Fields

1.8.3. Alpha Field Checks

VALIDATION CONDITIONS:

1. Have any fields got multiple validation rules and if this the case then all the rules properly applied?

2. Is the user required to fix entries which have failed validation tests?

3. Does a failure of validation on every field cause a sensible user error

message?

4. Is validation consistently applied at screen level unless specifically required at field level?

5. If the user enters an invalid value in field and clicks OK button, is the invalid entry identified and proper error message is shown.?

6. For all character/alphanumeric fields check the field to ensure that there is

a character limit specified.

7. For all numeric fields check the minimum and maximum boundary values and also

some mid-range values allowable?

8. For all numeric fields check whether user able to input negative numbers or not

9. If any field which initially was mandatory has become optional then check whether null values are allowed in this field

10. Do all mandatory fields require user input?

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. Field prompts aligned perfectly on the screen or not?

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 UI is proper and text is 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 micro help links are working correctly  and text spelling is correct on this screen

17. Is all the error message text is user friendly and spelling is correct on this screen?

18. Is all user input captured in UPPER case or lower case consistently?

19. Cases where the database requires a value (other than null) then this should be

defaulted into fields.

20. Ensure that all windows have a consistent UI and feel.

21. Ensure that all dialog boxes have a uniform and consistent look and feel.

USABILITY CONDITIONS:

1. Have all pushbuttons on the screen been given appropriate Shortcut keys?

2. Is all date entry required in the correct format?

3. Are all the dropdowns on this screen sorted correctly? Alphabetic sorting

is the default unless otherwise specified

4. Do the Shortcut keys work correctly?

5. Are all read-only fields avoided in the TAB sequence?

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. Can the cursor be placed in read-only fields by clicking in the field with the mouse?

8. Are all disabled fields avoided in the TAB sequence?

9. Can the cursor be placed in the micro help text box by clicking on the text

box with the mouse?

10. Have the menu options which apply to your screen got fast keys associated

and should they have?

11. When an error message occurs does the focus return to the field in error

when the user cancels it?

12. Is there a default button specified on the screen?

13. Does the default button work correctly?

14. Is the cursor positioned in the first input field or control when the screen is

opened?

15. Do all the fields edit boxes indicate the number of characters they will hold by there length?

16. When the user Alt+Tab’s to another application does this have any impact

on the screen upon return to The application?

NAVIGATION CONDITIONS:

1. Can a number of instances of this screen be opened at the same time and is

this correct?

2. Can the screen be accessed correctly from the toolbar?

3. Is the screen modal. i.e. Is the user prevented from accessing other

functions when this screen is active and is this correct?

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. Can the screen be accessed correctly by double clicking on a list control on

the previous screen?

7. Can the screen be accessed correctly from the menu?

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.

DATA INTEGRITY CONDITIONS:

1. Is the data saved when the window is closed by double clicking on the

close box?

2. Check maximum and minimum field values for numeric fields?

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 the maximum field lengths to ensure that there are no truncated

characters?

5. If numeric fields accept negative values can these be stored correctly on

the database.

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?

7. If a particular set of data is saved to the database check that each value

gets saved fully to the database.

  

GENERAL CONDITIONS:

1. Ensure that "Help" menu is present

2. Ensure that the proper commands and options are shown in each menu.

3. Ensure 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 / short cuts

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.

GUI SCREEN VALIDATION CHECKLIST Page 14 of 19

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

Valid email format case

email@domain.com (Username char max 64) and (domain suffix min 4)

email@domain.com (Username char max 64) and (domain suffix max 255)

firstname.lastname@domain.com

email@subdomain.domain.com

firstname+lastname@domain.com

email@Domain IP address

email@Domain IP address(in square brackets)

Numeric@domain.com

Alphanumeric@domain.com

email@domain-one.com(Dash in domain name)

a_b@domain.com(underscore in username)

email@Domain IP address.com (ip's as domain but followed by the .com/co.uk/co.in/co.au/')

Invalid email format cases

email@domain,com

@domain.com

<spaces>@domain.com

Email@domain.com (minimum characters less than 6)

@ and . Missing

email@domain.com (Ascii chars other than 33 to 47)

email<@domain.com> (encoded html)

email.domain.com (Missing @)

email@domain@domain.com (Two @ sign)

.email@domain.com (Leading dot in address)

email.@domain.com (Trailing dot in address)

email@domain.com(text) (Text followed email)

Test  Problem  Report  or  Fault  Report  or Bug Report

TPR  Id	A  unique  identifier  across  the  company
TPR  Description	A  brief  description  of  the  problem
Date	The  date  on  which  the  TPR  is  raised
Author	The  tester  who  raised  the  TPR
Test  Case  Id	The  test  case  that  caused  this  TPR  to  be  raised
Software  Version/Build	The  version  number  of  the  software  that  was  tested  and found  faulty
Problem  Severity	Show stopper/High/Medium/Low.   This will be agreed by the lead tester and  the  development  project  manager.
Priority	High/Medium/Low. How soon to fix?
Problem  Detailed Description	A  description  of  what  was  tested  and  what  happened This  will  be  filled  by  the  tester.
Problem  Resolution	After  fixing  the  problem,  the  developer  fills  this  section, with  details  about  the  fix. Developer gives this
Assigned  to	To  whom  the  TPR  is  assigned  to  be  fixed
Expected  Closure	When  the  problem  to  be  closed Data
Actual  closure  data TPR  status	When  the  problem  is  actually  rectified  and  closed This  is  a  changing  field  to  reflect  the  status  of  the  TPR.

Test  Records 

When  multiple  testers  execute  test  cases  each  tester  fills  up  the  actual results  section  in  the  test  case  sheets  and  determines  whether  the  test  has passed  or  failed. 

These  test  cases  along  with  the  results  will  be  reviewed (in  peer  reviews  by  fellow  testers  or  by  individual  testers)  and  approved  by the  lead  tester. 

The  number  of  such  test  cases  executed  will  increase  day by  day,  when  the  test  cycle  progress. 

Each  of  these  test  case  sheets  will be maintained in a central location for the team members to know the progress. 

The  collection  of  such  executed  test  case  sheets  along  with  TPRs  is  called test  records. 

Test  Environment  Set-up

There  must  be  no  development  tools  installed  in  a  test  bed.

Ensure  the  right  OS  and  service  pack/patch  installed.

Ensure  the  disks  have  enough  space  for  the  application

Carry  out  a  virus  check  if  needed.

Ensure  the  integrity  of  the  web  server.

Ensure  the  integrity  of  the  database  serves.