Find out what our apprentice Jess has to say about website testing
Find out what our apprentice, Jess, has to say about testing websites
Today I’m going to be writing about wesbsite testing, specifically, a little about my experience with testing, how to test effectively, tester morale and how we’re going to start using testing at HeX.
Introduction
Here’s a little info about me and more importantly why the team have decided I’m qualified to write about website testing.
I feel it’s important to stress before anything else, that there is no right way to do testing. But there’s definitely a wrong way and it’s only through months of constant testing that I was able to distinguish between the two.
My first experience of testing was in my previous job, an apprenticeship with a small development company in Guildford. It was exciting, we had a nice new office, shiny Macs to play with and even a water cooler (we were “very” professional like that). Being the apprentice I was given all the extra fun, low skilled jobs that the other team members didn’t have time to do. This usually boiled down to one of three things: minor bug fixing, running server checks and more common of all, testing. It was these tasks which eventually led me to be put in charge of totally remodelling the way we tested our site and operated.
Right and Wrong?
Like I said before, there’s no right way to test a website, but there are objectively bad methods which can cause lasting problems for any website that potentially never gets found.
When writing a test suite there’s some key factors which you need to consider in order to get the most efficient tests possible while not missing anything. Another crucial factor to keep in mind is the minimum required knowledge level and potentially most importantly, tester morale.
An example I always go back to when I’m writing a test suite, is my very first-time testing, because it was horrific. If I had to sum it up a one phrase it would be “soul-crushing”, and consisted of days of trawling through Excel spreadsheets and following exact, specific tests detailing exactly what should happen in every situation. This was often multiple times over.
This was a horrible way to work both for the person and in terms of getting results. Though this kind of exhaustive testing is in theory the best way of catching any issues, it does have some key flaws which result in it taking far longer than it needs to, as well as being incredibly straining for a person to do over long periods of time. It is an issue which can severely damage the testers morale and in turn the quality of their work. The causes of these problems are repeated steps and a small testing force, though in a small company it’s not always viable to have larger teams running tests. It’s in everybody’s best interest to keep the tests as efficient as possible.
There are a few ways you can work to make your tests more time efficient to run through, but first you need to understand a few things about what the tests themselves are going to be for. The first thing that you should think about when you start planning your tests is the structure of the site, an excellent way to boost tester moral is to show progress and split your tests up by page or area if possible. Perhaps going down as far as testing individual functions like logging in and out, this kind of break down helps the tester feel like they’re making progress.
You should also write tests with the person who’s going to be running them in mind, by this I mean you can vary how exact steps are based on the persons experience with the website. Though it’s often good to work from the point of view that anybody could pick up the tests and run them, it can be incredibly frustrating to read through unnecessary steps. Finally invest in a professional testing tool, don’t just use Excel or some other generic spreadsheet, it’s not professional. It’s difficult to use and it makes gathering results difficult, I’d recommend instead using a free tool like Jenkins which is built with testing and usability in mind.
Future Testing!
We all need to test more, a lot more, and now that our team is growing we have the resource to pick up our game. Testing is one of those things that feels like a waste of time when you’re doing it, but it saves a lot of time in the long run. Almost every company can benefit hugely from running even a simple test suite before releasing a product, it’s quality assurance for the customer and helps with the image of the company as well (since we put out more consistent products).
My big plan for the future of testing at HeX is to make a suite of generic, all round tests which we perform on every site before making it live. This is not to say that we don’t test, we do, but it’s unstructured, ad hoc testing which we do as we go (as I’m sure many do). I encourage you to make this change, for two reasons.
One of these is structure. Part of the nature of testing is that it’s dull, that much is almost unavoidable and one of the biggest problems with that is losing focus on what you’ve done and where you’ve tested. That’s why we need a structured system for storing and logging our tests rather than just working on them as we go. This doesn’t mean ad hoc testing is bad, testing features as you go is actually a great way to work. However, it can’t be the only QA you have, especially for larger sites where interacting with one element can change how everything else on the site works.
The second, if possible, do. not. test. your. own. website. Though it might seem counter intuitive not to test your own work it’s for a good reason, in fact it’s for several good reasons.
Firstly, as a developer you’ll spend hours building and learning how a site works, you’ll be used to any kinks and quirks it has and it’s very likely you’ll miss them when it comes to testing. Next comes tester morale, as previously mentioned a developer can spend hours on a site, maybe even just on a small section of that site and having to then go back through the entire thing can feel like a waste of time and a daunting task depending on how complex the site is. It can also lead to self-doubt in the developers own ability which can lead to a negative office environment. It’s much better for everybody to have tests and fixes performed by different people to the original developer.
Finally, pride, after all you’re confident, you spent hours working on a website, there no way a professional web-developer like you could have forgotten to link a button properly so why would you need to test your invariably perfect work? It’s times like this that having somebody unbiased look over your work is crucial to making sure it’s thoroughly tested.
