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 testplan 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 Tempate. For areas to test, you can consult the QA Test plans - Listing. If your testplan is covering an area not listed on the Test Plan Listing, fell free to add your testplan to that page. Also make sure you update that listing when creating/updating test plans.
Areas to test:
- 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.
- Does the page conform to XHTML 1.0 Strict DTD?
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)
Security (are there any security issues to consider)
- Is the code secure for injection attacks, etc.
- Get/post statements with passwords?
General QA Considerations for a page/functionality:
While these are not strict tests, It is good to keep the user experience in mind when looking at a page/functionality:
- Is there anything that could improve the experience for the user (eg. default focus on a specific field)?
- Is there a sensible relationship between the importance/normalcy of operations and their ease to do/efficiency?
- Documentation (ease, correctness, detail-level, wiki)
- Speed: page load (minify/gz), reaction to button push
- While writing the test plan, you are likely to be browsing CS at the same time. If anything bothers you (navigation problems, many steps for trivial tasks, etc.) it is likely to bother the user too. Either file a JIRA issue or write a mail to the work list.
Below are a list of relevant wiki pages. These should be useful when getting started on writing tests.