Cross browser testing Checklist

Crossbrowser Testing, Testing Checklists

Here is is quick checklist for conducting a Cross Browser Testing. A Tester need to take care of following areas (in each browser) while doing Cross Browser Testing:

  • Page Layout
  • Text Alignments
  • Font Sizes
  • Page Navigation
  • Mouse Hover / Tool Tops
  • CSS, HTML or XHTML validation (various tools available like w3s validator, etc)
  • Java Script
  • Client side Validations of fields – with and without javascript enabled
  • CSS validation
  • Header & Footer Layout
  • Usability Controls (Select options using tab & shift+tab )
  • SSL certificates
  • Image alignments
  • Upload File
  • Export File
  • Submit Functionality
  • Navigation Links & Page Links
  • Check Box functionality
  • Animations
  • Form saving functionality
  • Font Styles
  • Performance of application
  • Tool Tips
  • Grids / Tables in the page – If there are fields like dropdown then check their look and field.
  • Scroll Bar appearance
  • Space between fields:
    • Space between two sub-sections/fields
    • Space between labels & checkboxes/radio buttons
    • Space between two radio buttons/checkboxes
  • Modal/Popups
  • Flash work
  • Page Zoom / Increase Text size

– Happy Testing

Guest Article by Gaurav Dhiman

Requirement Specification document Review Guidelines and Checklists

Testing Basics, Testing Checklists | 1 comment


To prepare effective test cases, testers and QA engineers should review the software specs documents carefully and raise as much queries as they can.
The purpose of Software Requirement Specification Review is to uncover problems that are hidden within the specification document. This is a part of defect prevention. These problems always lead the software to incorrect implementation. So following guidelines for a detailed specification review is suggested:
1. Always review specification document with the entire testing team. Discuss each point with team members.
2. While reviewing specification document, look carefully for vague/fuzzy terms like – “ordinarily, most, mostly, some, sometimes, often, and usually” and ask for clarification.
3. Many times it happens that list values are given but not completed. Look for terms: “etc., and so forth, and so on, such as.” And be sure all the items/list values are understood.
4. When you are doing spec review, make sure stated ranges don’t contain unstated/implicit assumptions. For example: “The range of Number field is from 10 to 100.
But is it Decimal? Ask for Clarification.
5. Also take care of vague/fuzzy terms like – skipped, eliminated, handled, rejected, processed. These terms can be interpreted in many ways.
6. Take care of unclear pronouns like – “The ABC module communicates with the XYZ module and its value is changed to 1.” But whose value (of ABC Module or XYZ Module)?
7. Whenever a scenario/condition is defined in paragraph, then draw a picture of that in order to understand and try to find the expected result. If paragraph is too long, break it in multiple steps. It will be easy to understand.
8. In the specification document, if a scenario is described which hold calculations, then work on its calculations with minimum two examples.
9. If any point of the specs is not clear then get your queries resolved from the Business Analyst or Product Manager as soon as possible.
10. If any mentioned scenario is complex then try to break it into points.
11. If there is any open issue (under discussion) in the specs (sometimes to be resolved by client), then keep track of those issues.
12. Always go thru the revision history carefully.
13. After the specs are sign off and finalized, if any change come, then see the impacted areas.