Web software front-end test cases

Recently I was working on a website which was developed in PHP without a web framework. A lot of things were programmed manually which would normally be taken care of by a web framework (for example things like: in case of an error, the HTML fields on the form are re-populated on the response page).

So I came up with an extensive set of test cases, and made sure I used them all on every field on every page.

These are the tests, in no particular order.

1. On a form with radio buttons and text fields next to the radio buttons, clicking on the radio button should position the text cursor in the text field (as typing there is the next thing you're always going to want to do).
2. Clicking on the text field by a radio button should select the radio button.
3. Checkboxes and radio buttons which have text beside them must have the text in a <label> so that clicking the text selects the checkbox or radio button.
4. On a <form>, pressing return must do the same as clicking "OK".
5. Pressing the TAB key on the keyboard should progress from one field to the next in a reasonable order.
6. If you go to a page with a form, is the text cursor already in the first field? Or do you have to reach for the mouse and click on the first field in order to use the form on the page?
7. Every action where something is done (e.g. delete an FTP account) should have a confirmation text on the result page like "ftp account XYZ deleted". I think it's important to include the name of the object being acted upon in the message.
8. All forms should use "post" and "get" appropriately. I mean various people have various strong views about when to use one and when to use the other. But for me the difference is the browser's "are you sure you want to repost?" message when you click refresh. Do you want it? If so use "post", otherwise use "get". Also bookmarkability.
9. Is there a reasonably small amount of HTML generated? E.g. in uboot to display the address book page requires about 1MB of HTML to be downloaded to the browser (not including any external CSS, graphics etc.) That's too much.
10. The back button should work everywhere. (E.g. Uboot multimedia gallery: click on a picture, click back, you're at page 1 of the gallery rather than the page you were on.)
11. Strings to long? Then "..." should be displayed, to avoid breaking the layout.
12. If breadcrumbs are used, (i.e. main page > hosting > ftp accounts > ftp account 'x') then they must work. Ideally they should contain data such "ftp account 'x'".
13. While loading a page on a slow connection, is the text readable before the background image loads? E.g. white text on a black background image may not be readable before the image loads. There should be an alternative flat-colour background of a similar colour. (Thanks Helge for pointing this out a few years ago!)
14. While loading the page, does the page move around a lot due to width=x height=x attributes missing on an <img> tag? It's annoying when you start to read the text on the page and then it moves a few seconds later just because some logo has finally loaded.
15. Every time there is an error in the form and the page is reloaded with the error: is the original data still in the form?
16. In all places where the user may enter free text: Do weird non-Latin1 characters work correctly, both entering them and displaying them? Do " ' work correctly? Are < > & displayed correctly? Is all of this written to the database correctly? (Sometimes the browser sends { style code to the server. If this isn't escaped on the display code then the character may appear to have been processed correctly. But you don't want { strings in your database data.)
17. Type in long values into text fields. Values should be neither truncated nor should an internal error be produced (default behaviour if you're using MySQL or Oracle respectively)
18. If there are any id=nn type parameters in the URL, then adding or subtracting 1 from the URL should not allow you to view other people's content.
19. Is the <title> tag set usefully? This is necessary when you use the down-arrow by the "back" button on the browser, to determine how far back you want to go. A whole lot of options such as "MyWebsite", "MyWebsite", "MyWebsite" is not very helpful.
20. Test in a high-latency environment. Such as over a UMTS connection. If there are a lot of redirects, or images referenced from CSS referenced from HTML, or Javascript making AJAX calls, processing the result then making more calls, then the page will be slow, but work fine over a LAN connection.
21. Test in an unreliable environment, e.g. where packets get lost. Google Spreadsheets, when you type in a value, lets you continue editing the page while it's sending the value to the server. But if there's an error or timeout with the sending you see an error, and the cell is reverted to its previous value. You simply have to type in the same data all over again. Instead of that it should remember your data, and display an warning "can't connect to server right now; retrying..."
22. If you type in URLs in capitals or mixed case: do they still work? (Thanks again Helge!)
23. AJAX progress indicators: Is it the case that you've written an AJAX site, and when the user clicks an action, absolutely no visual feedback is given to the user that he's clicked? You need to have some kind of feedback, e.g. the "loading..." of gmail.
24. Are the buttons large enough to be easily clicked on? E.g. confirmation page with "Yes", "No" options displayed as links in a tiny font. They're hard to click!
25. Do the colours work even if you view your laptop at a weird angle? A site I was using recently used a white background (what a surprise..) and to highlight the tool you had selected used a light-grey background. Worked fine on their monitors I'm sure, but at the airport with your laptop on your lap, they're difficult to see.
26. Does the site work, or at least fail gracefully on old browsers? An error message immediately is preferable to allowing the user to type in lots of text then lose it when the user presses "OK", due to some browser incompatibility issue (e.g. MediaWiki on Safari 3 beta for Windows)
27. Does the site look good on both LCD monitors and conventional monitors? Some colour combinations (e.g. dark green on a light green background) are perfectly readable and look nice on LCDs, but are completely unreadable on conventional monitors.
28. What about small screens? My parents computer uses 800×600 and I use my Laptop in 1064×600 normally. In Google Reader I can hardly see any feeds at that size. The whole screen is taken up with toolbars, menus, etc.
29. Is the session timeout compatible with the company's policy? E.g. do you really need the user to log in again after 10 minutes, i.e. when he just had to nip off for a meeting?
30. If the session expires, what happens to the user's data? Composing a long email and clicking "send" only to receive the response page "please log in again!", and losing the email, is wrong.
31. If there is a possibility to log in on every screen (e.g. "logged out" at the top-right of the screen, or like on uboot), then logging in should take you back to the screen where you were. Because that's what the user would want.
32. If you are logged out and go to a particular screen e.g. via URL or bookmark sent while a user was logged in, do you get useful information? A redirect to the homepage is also OK, but "general error" is not.
33. If a browser window is open, and a user is logged in, and from another browser (or directly in the database) that user's password is changed, the user deleted, or disabled, is the first browser immediately logged out?