How to Test

Take your testing seriously enough to make some simple test cases (a software design concept). You should also document them at least to some moderate degree. For example, you could list your expected results, save screenshots for every “browser and test subject” pair, and add a note stating what is problematic and what needs to be fixed. You should also indicate the date of the test and maybe the revision id of the version control system your tested design is residing on. By the way, I am strongly for using a version control system. It could be SVN, Git, or something else, but the little extra effort it might take to use it will save you tons of problems if you accidentally delete something, overwrite the wrong code, or when (not if) your work machine breaks down irreparably.

If your test concludes that something needs to be fixed, once you have made the modifications, you should perform a second test, exclusively for the parts which are affected by your changes. Remember to note the reason for the modification along with your documentation, and possibly also in the code. You should repeat this step until, hopefully, your design looks sufficiently well in all of your tested browsers, and no more changes are needed.

Lastly, you should also test for cases when a certain feature in your design, like Adobe Flash or JavaScript, is not available or not switched on in the viewer’s browser. This is another place to use the principles of graceful degradation and progressive enhancement.

But what if due to various factors you end up repeatedly making changes to fix a problem in one browser, just to find that your fixes cause another problem in the same browser or in a different one?

Problems While Testing

Sometimes a testing session gets stuck, or starts to go in circles. This could be due to the complexity of the design, the strictness of the requirements, the variety of browsers chosen to test against or a combination of all these. If the problematic browser is in the IE family, you could use conditional comments to load a custom style-sheet for the troublemaker. Otherwise, if your server software lets you sniff for different browsers and serve separate styles based on that, this could aid in solving your problem. You should also research the issue—someone may have already come up with a solution, or there may be a tool out there for the job. In some cases, you might need to use a different technology—like Adobe Flash or a JavaScript library, when something is not achievable across browsers. You may just use it as a fallback or decide to switch to it entirely.

If you cannot fix the problem with the above methods, you should make a compromise. In order to remedy it, you could either choose to revisit the design, use a different approach if possible, ease the requirements, or maybe as a last resort, pick out an unfortunate browser to take the fall. Of course, this is something the customer must agree to as well. If it is the case, there is no shame in admitting that something is not possible in the current circumstances.

Testing Additional Changes

The key is to estimate what the changes will affect and to concentrate your testing on these parts. This estimation should draw on your knowledge of HTML and CSS and on the previous history of changes you had with this project. If you know that a change is not supported well in a certain browser, or you know that it will appear differently, test it. If it involves a new technology, also test it. If it is in an area of the design which took a large amount of corrections in order to get it, then test it as well.

In general, the more structured and organized you are with your testing the less time you will waste hunting down issues during the initial implementation and further changes and maintenance. A real test case procedure might appear too tedious, but it is time well spent, as it increases the quality of your work. If you follow through with it properly, you will have a design that looks good across all your target browsers and to all your target audience, while future alterations will be easier to perform.

Posted in: Web Design and Applications

Related FAQ's

Marius Ion ANGEL HOT SOFT LLC (800) 316-7677