As web masters, we all know that on occasion our "live" web pages get reported for a wide range of issues: failed log in attempt errors, buggy actions due to failed scripts, images that do not render properly, overlapping text, or content styling spilling over into other background divisions or sections. These are just a few of the things that can go wrong when visitors experience a buggy web page.
This list of several tips and tools can become prime candidates for incorporation into your debugging and testing routines for you and your team. Included in this short list are techniques for debugging code, several tools to look through offending code, services to test your designs, and cross-browser support, including earlier versions of IE.
On occasion, the offending code can be highlighted and commented out as a single section or several sections, and then the page tested again. Using troubleshooting techniques such as dividing and bi-sectioning the web pages, using a formatted, systematic checklist based on your systems and design, or isolating the specific cause or causes of the symptomatic code can result in a quick solution to the aberrant problem. One of the core principles of troubleshooting web pages is being able to reproduce the problem, and seeing if the issue occurs in all server environments, be they development, staging, or production (live). Singling out the issue may mean making a change on the server also.
Does the offending code only present an issue in one or just a few browsers or versions? You can test your web pages for cross-browser support at BrowserShots, selecting from comparison options between Linux, Windows, BSD, and Gecko, KHTML/WebKit, all, or none. While it might not always have perfect results, you do get a queued view of screenshots showing how your site might render across a range of browsers. This online tool could give you a clue as to pinpointing any problem code.
As web developers we all know about the issues with IE, especially earlier versions. And as much as we would like to sweep this one under the carpet, it cannot be ignored that many visitors still do use earlier versions of IE including going way back to IE5.5. If your web statistics show more than 1% of your traffic coming from IE6 or earlier versions, then it makes sense to test in IE. Good thing you don't have to keep all the versions of that aged product on your test beds, because you can use the IETester, in a virtual environment. IETester is a part of the DebugBar, and embeds multiple versions of the Internet Explorer rendering engine (called Trident) into a single process. Trident is an ActiveX control, thus a COM object, and can be embedded into any application.
Ryan has performed in a broad range of technology support roles for electric-generation utilities, including nuclear power plants, and for the telecommunications industry. He has worked in web development for the restaurant industry and the Federal government.