Watch Selenium Java Training videos and download Selenium Tests Framework step by step selenium test reporting framework today!

Monday, May 12, 2014

Manual Testing Checklist


This check list comprises of use cases which can be applied to any web application. Thought there are many areas covered but no checklist could cover all the possible checks under the sun. I am sure you would find that many more use cases can be added to this list. So here is the list I could think of -

General Validation:

·                               ·         Verify page focus on a field on page load. For example login page would have cursor blinking in user name field
·         Tabbing may let you bring control on fields and submit form which are supposed to be disabled and. Don’t rely if a field “looks” disabled as it may be exercised using tab key
·         Verify navigation of toolbar, menu items and fields using tab key. Tab order should be left to right and up to down
·         Using tab key should not bring control on read only and disabled fields
·         When brining control on a field then it should stand out by cursor blinking in text box or highlighted field
·         The colors, fonts, and font widths should be as per the specified standard for the field and also for the field prompts and display text
·         Application font should render uniform across targeted browsers
·         The vertical scroll bars or horizontal scroll bars should  not appear unless required or explicitly mentioned





·         All the controls in window should be aligned
·         The spellings of all the text displayed in the window, such as the window caption, status bar options, field prompts, pop-up text, and error messages should be checked
·         All the character or alphanumeric fields be left-justified and that the numeric fields should be right-justified (unless otherwise specified)
·         The cursor to be focused on the first input field when the window is opened.
·         Window name should correspond to its function. Look for consistency all through the application
·         Is it possible to abort the current operation (including the delete operation). For example what happens if user hits browsers back or refreshes application during payment processing
·         Do the sizes of edit boxes correspond to ranges of values that they take? An address box which accepts 50 characters should not have just 10 characters visible
·         Check for broken links in application. Link checker tool XENU does a good job for finding 404 links
·         Is there a confirmation message when user closes the windows after entering data in form fields?
·         No abbreviation should be used for label/field name. Name should be completely spelt out
·         If user is not supposed to interrupt load operation of page then corresponding screen should be greyed out. For example navigation from application page to payment gateway should not let user submit form twice
·         If fields are explained using tool tip then user should be able to open it in targeted browsers
·         Verify sorting feature for columns in table. For example: sorting on date would be in increasing or decreasing order, sorting on text label would be in alphanumeric order. The sort order may vary depending on application
·         Application should time out if user remains inactive for long. Time out period may be shorter for payment applications
·         Test for failure condition, if an operation fails then does application throw comprehensible error message?
·         If java script is disabled on user browser then does application prompt user to enable it?
·         Use W3C’s HTML and CSS validators to validate webpage markup
·         Verify there is useful information in error page 404
·         In case of search feature, verify search results are relevant with respect to search term
·         Validate meta tags (title, keyword, description) for SEO optimization
·         Verify functionality of application in different combinations of browser and operating system
·         Always tests on IE browser to find more bugs J


Field Level Validations:

Given that an application comprises many fields dropdown, textbox etc; there are few general validation which could almost universally be applied on these fields. A few of these validations are:

·         Dropdown:
o   Should be enabled/disabled on page load
o   Should be mandatory/non mandatory field
o   Default selection should be should be <default value>/<Select One>
o   Should list in <alphabetical order>/<any other sort order>
o   Should be able to select a value in drop down by pressing character key. For ex character ‘s’ should select “selenium” in drop down

A variation of drop down is multi-select list in which multiple values can be selected and not just one.Multi select list would allow selection of multiple value by holding down the control/shift key
All above mentioned validations of drop down list are applicable for multi-select list as well


·         Button:
o   Should be enabled/disabled on page load
o   What action should be carried out when button is clicked, if button submits form then validation checks should be carried out on form fields.


·         Textbox:
o   Should be enabled/disabled on page load
o   Should be mandatory/non mandatory field
o   Should be empty/<have default text> on page load. At times, text box have ghost images on page load should be validated for its presence
o   Maximum character limit on field
o   Test for <Valid data>/<Invalid data>

o   If text box is numeric field then additional checks have to be carried out –
§  Test for smallest and biggest numbers for numeric fields
§  Either numeric field should not allow leading and trailing spaces or should trim them while processing
§  Should handle positive and negative values correctly
§  Should handle division by zero error when applicable
§  If numeric field is currency then verify currency format
§  Currency field should not allow negative fields unless specified otherwise

o   If text box is calendar field which accepts dates then additional checks have to be carried out –
§  Date format should be mm/dd/yyyy/<other format>
§  In case of two date fields, “from” date should be behind “to” date
§  Validation should check for leap year/month ending with 30/31 days

o   If text box is email address for registration form then additional checks have to be carried out –
§  Valid Data: Alphabets, Numbers, -, _, @, Dot
§  Invalid Date: Special characters, Symbols, Leading and in-between white space
§  Email address should have @ symbol
§  At least one character should precede @ symbol
§  @ symbol should be followed by at least one character
§  Followed by at least one 'dot'
§  Dot should be followed by at least two characters
§  Basic format should be a@a.com
§  Application should not allow to use existing email address for registration

o   If text box is password field then additional checks have to be carried out –
§  Valid Data: Alphanumeric characters
§  Invalid Data: To make password secure applications restrict using only characters or only number
§  Should be masked when displayed in textbox
§  Should be Encrypted  while storing database
§  Should not allow password text same as email address

o   If text box is Zip code/Postal Code field then additional checks have to be carried out –
§  MAX char limit restriction should be driven by the country selection
§  Valid data should be driven by country selection. For example only number for USA and number and alphabets for UK


o   If text box is country code field for phone number then additional checks have to be carried out –
§  Max field length should be 3 digits
§  Valid Data: whole numbers
§  Invalid Data: Special characters, Symbols, Alphabets


Database validation:

                Database is integral part of any application. Operations carried out on front end usually result in generation of new data or update in existing data. Database validation is a cast field, few pointers to consider –
·         Columns should not allow null until unless specified
·         What happens if wrong parameters are passed to stored procedure? Does application handle such use cases?
·         Is data saved appropriately on form submit. Data should not be truncated when saved in database
·         Verify time taken to execute a procedure. An improperly written procedure may result in longer response time
·         All sensitive data i.e. password should be encrypted in data base

Security validations:

                Following security checks can be carried with sheer manual testing and without special expertise in the field of security testing –
·         All sensitive data (password, credit/debit card, security answer) should transport over https protocol
·         Once password is changed, then use should not be allowed to login using old password
·         No sensitive data should be displayed in URL of application
·         URL modification should not allow access privilege to under privileged users. For example a user should not be able to access admin pages by just launching the admin page URL
·         One user is logged out or session is expired then user should not be able to gain access to application using browser back. Application should force user to login
·         No sensitive data should be logged in application log files
·         Are multiple failed operations restricted by captcha to control denial of service (DOS) attack?


Want to add more check? Please post a comment with your check I missed J

2 comments:

  1. It's a pity I cannot copy/paste it to send it to my colleagues :)

    ReplyDelete
    Replies
    1. post it on FB or email it to you friend :)

      Delete

ShareThis