Checklist for website testing


Published on

Checklist for website testing - An approach to capturing issues.

Intro, basics, the importance of defining requirements, dimensions in testing

Published in: Self Improvement, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Checklist for website testing

  1. 1. Checklist for Testing An approach to capturing issues Tricode Professional Services Date: 09-10-2009 Author: Chris van Zeventer
  2. 2. Contents <ul><li>Intro </li></ul><ul><li>Basics </li></ul><ul><li>The importance of defining requirements </li></ul><ul><li>Dimensions in testing </li></ul>
  3. 3. Intro <ul><li>What this is about </li></ul><ul><li>Awareness </li></ul><ul><li>Accessible </li></ul><ul><li>Website related </li></ul><ul><li>What it’s not about </li></ul><ul><li>Revolutionary concepts </li></ul><ul><li>Standards </li></ul><ul><li>Complex theories </li></ul><ul><li>Automated testing </li></ul>
  4. 4. Basics <ul><li>Expected behaviour (specification) </li></ul><ul><li>Determine strategy in testing </li></ul><ul><li>Determine current behaviour (testing) </li></ul><ul><li>Process test results </li></ul>
  5. 5. The importance of defining requirements <ul><li>Expectation vs implementation(1): spotting a problem (FD & TD) </li></ul><ul><li>Expectation vs implementation(2): Example </li></ul><ul><li>The price of failure </li></ul>
  6. 6. Expectation vs impelementation(1): spotting a problem (FD & TD) <ul><li>Misunderstandings can lead to delays </li></ul><ul><li>Spot (and prevent) problems as early as possible or else.. </li></ul>Development time higher than expected due to misunderstanding about functional reqs. Time needs to be gained somewhere to meet the implementation deadline. At this point only test phase remains adjustable (and thus will suffer) Failing to pick up issues earlier on will lead to headaches after implementation. At this point the planning was still adjustable
  7. 7. Expectation vs impelementation(2): Example <ul><li>Assignment: </li></ul><ul><li>Describe a tricycle </li></ul>
  8. 8. The price of failure
  9. 9. Dimensions in testing <ul><li>Why dimensions in testing? </li></ul><ul><li>Scope / coverage area </li></ul><ul><li>Superficial / environmental </li></ul><ul><li>Object interaction </li></ul><ul><li>Functional behavior </li></ul><ul><li>Operational </li></ul><ul><li>Implicit testing </li></ul><ul><li>Note: An item may cover multiple dimensions </li></ul>
  10. 10. Why dimensions in testing?
  11. 11. Scope / coverage area <ul><li>Narrow area </li></ul><ul><li>Immediate area </li></ul><ul><li>Broad area </li></ul>A B C D E
  12. 12. Scope / coverage area <ul><li>Narrow area </li></ul><ul><li>Immediate area </li></ul><ul><li>Broad area </li></ul>A B C D E
  13. 13. Scope / coverage area <ul><li>Narrow area </li></ul><ul><li>Immediate area </li></ul><ul><li>Broad area </li></ul>A B C D E
  14. 14. Scope / coverage area <ul><li>Narrow area </li></ul><ul><li>Immediate area </li></ul><ul><li>Broad area </li></ul>A B C D E
  15. 15. Superficial / environmental <ul><li>Text contents </li></ul><ul><ul><li>Spelling </li></ul></ul><ul><ul><li>Text that doesn’t make sense </li></ul></ul><ul><li>Styling </li></ul><ul><ul><li>Green text on green background </li></ul></ul><ul><ul><li>Overlapping pieces content </li></ul></ul><ul><li>Cross browser compatibility </li></ul><ul><li>Cross resolution compatibility </li></ul>
  16. 16. Object interaction <ul><li>Input validation </li></ul><ul><ul><li>Postalcodes </li></ul></ul><ul><ul><li>Phone numbers </li></ul></ul><ul><ul><li>Date format </li></ul></ul><ul><li>Character encoding </li></ul><ul><li>Impact of client settings </li></ul><ul><ul><li>JavaScript </li></ul></ul><ul><ul><li>Flash </li></ul></ul>
  17. 17. Functional behavior <ul><li>Behavior should be consistent with functional design </li></ul><ul><li>Object behavior looks at a single object. functional behavior looks at the bigger picture. </li></ul>
  18. 18. Operational <ul><li>Performance </li></ul><ul><ul><li>Load times </li></ul></ul><ul><ul><ul><li>Stress testing </li></ul></ul></ul><ul><ul><ul><li>What is considered ‘slow’? </li></ul></ul></ul><ul><ul><li>Memory & disk space </li></ul></ul><ul><ul><li>Will it break if interrupted (corruption of data)? </li></ul></ul>
  19. 19. Implicit testing <ul><li>Gather information about other properties of the system for which you didn't design specific test cases (while testing you notice that the performance is poor, the user interface is bad, ect..) </li></ul>
  20. 20. Conclusions <ul><li>Try to capture all requirements early on (preferably long before testing) </li></ul><ul><li>There is more than one way/perspective to look at a test object </li></ul><ul><li>Don’t underestimate regression </li></ul><ul><li>If you didn’t define something as test object it doesn’t mean you can’t test it </li></ul>