Performance Testing

Performance testing might seem like a separate topic but it really isn't. The point of any testing is to make sure a product works correctly, and a website that's frustrating to use because it's too slow to load or to interact with is one that dosn't work. There are more ways in which something can be broken than a visible error.

This does lead to some difficulty when it comes to defining what a test should do though; performance is largely a matter of perception rather than hard numbers. Your web application might take 15 seconds to load, but if there's a loading spinner for the first two seconds, then a paint to the screen for the layout, and content is loaded in asynchronous over the rest of the time it might actually feel like the page is loading moderately quickly. Where you draw the line in deciding what "too slow" means is a matter of judgement.

That only really affects what you use as a point where a test should fail though. There's plenty of scope in writing tests for getting data from a browser, from the page weight, the initial time to the first paint, the time to interactivity, and the time the entire page with all it's assets takes to load. Then there's timings to look at after the page has loaded, like how long it might take to validate a form, to add a row to a table, to perform an XMLHttpRequest to update a record. These are all important factors for your users, so they should all be covered by your tests.

There's much more content coming soon(ish). If you're interested in reading it as it's added, please subscribe to my email updates. You won't get many emails - it'll only be one a month at most, and your email address will never be shared with any third parties. I would recommend adding something like "+testtheweb" to your email name, eg onion2k+testtheweb@gmail.com, to make filtering easy, and to be sure that your address has not been shared. It's supported on gmail, hotmail and many other email providers.

Many thanks to Tinyletter for their awesome (and free) service.