How to Write a Test Plan for the UI

Organization of Test Plans

The individual tests are organized in test plans. Each test plan covers either a specific page or some specific functionality, and each test in a test plan covers a limited area of (sub-)functionality.

When writing tests...

  • Be clear when writing the tests.
  • Remember that others should be able to read the test and do exactly what you had in mind.
  • It is important to pick a small, well-defined area for each test. It is preferable to have many small tests covering different functionality rather than a few large tests, each covering many different functionalities.
  • Make sure to not only write what the tester has to do (Actions) but also exactly what the tester should expect the program to do (Expected)

You can use the test plan template when writing new tests or test plans. The template can be found here: Test Plan Template

Areas to test:

Navigation (mouse/keyboard)

  • Mouse vs keyboard. Is everything doable with each (eg. date selection)?
  • Are all fields accessible via tab?
  • Does the Enter key behave as expected?
  • Browser back/forward buttons. Do they mess things up?

Functionality (does everything work)

  • What is this page/functionality supposed to do, and does it work?
  • Does the different subfunctionality on this page expected (eg. test select boxes, text fields, test areas, authority fields, buttons, different links)
  • User Stories: Are all the user stories possible to do?
  • Schemas: Does the page comply to schema?
  • Is user warned if attempting to navigate away from a modified page?
  • When saving, are all fields saved?
  • Check that everything works, both on creation of new and editing existing.
  • Are fields/tabs disabled/enabled correctly?
  • Test compatibility with all symbols (quotes, odd letters/symbols)
  • When doing stuff wrong, do you get correct/understandable error messages?
  • Make sure to not only test what is supposed to work, but also check that doing unexpected actions are handled well by the program.

Error handling (are errors handled gracefully)

  • How does it handle faulty inputs (letters in numeric fields, letters in dates, etc)
  • Clear error messages in general (do error messages tell you what went wrong)