This article looks how to test for bugs during web development, and whilst testing a website for bugs during the build process. I look at some of the things I’ve done in the places I’ve worked. This is primarily aimed at front end development, but I guess it could also apply to some back end development too.
Automation for the basics
When you work within a team, ideally you want to put your own personal opinions on formatting aside. If all your code looks consistent, then obviously whomever picks up the work will have an easier time working with it. This is transferable for existing developers, and those that have perhaps just joined the team. So in that sense, some sort of code standardisation is needed.
Keeping to some form of coding standard can be easier with some automation. Using a package manager like npm, you can automate linting scripts such as jshint or stylelint. They will format your code according to how it’s configured. Like placing spaces where they need to be and so on. You’re likely to find linting tools like this for whatever code you’re working on, and most of them are configurable to set any styling rules however you want.
Others are community based recommendations, such as psr-2 for PHP. With a little effort you can also configure most text editors to format your code according to some coding standard. Remember though, that these are guidelines rather than requirements. For example, there are coding standards for PHP in WordPress, which I find sometimes contradict with those set in psr-2. So it’s up to you how you want to apply your own coding standards.
If you’re using something like git to maintain your codebase, you can also run checks whenever the code gets committed. One such tool is Travis CI which can run tasks via npm, or any other script you can think of.
One thing worth noting is that if you work with two sets of code, you may need different formatting rules. For example Javascript and PHP. One uses tabs for spacing whereas the other doesn’t. You may upset either other front enders or back enders, depending on which way decide you go. One to watch out for!
QA team to the rescue
When I’ve worked in a team, we’ve tried to pick up and squash as many as we could before it was handed over to a QA department. Most of the things covered were browser display issues, checking site load speed and ensuring our code passed our own coding standards checks.
It’s up to a QA team to report further bugs back via a bug logging app called bugherd. This is an ideal platform to use within a team environment, as it allows tagging of bugs, assigning devs to particular bugs and so on. It also doubles as a handy tool for clients (and Designers!) to see work progress and log any issues of their own.
Having a QA team is an essential fresh pair of eyes for ensuring everything is working as expected. They’ll also test on a variety of real-world devices and browsers. When it comes to web development, it’s also an opportunity to make sure the page layouts match the designs as accurately as possible. The team has a varied range of technical ability, so it’s handy for them to pick up the type of bugs you might get from an everyday (non dev) user.
Some of the tools to use when testing for bugs
I’ve already mentioned some of the tools used with testing, but there are some others that are useful. Some might cross over into deployment, but it’s still handy to know what’s up with the code before it goes live.
Bugherd
When you know how to test for bugs, there’s a good chance you’ve already used this app. Touted as a ‘visual feedback tool’, this web app works kind of like a kanban board, where you can drag task cards from one column to the other, depending on it’s status. If you’ve used trello, it’s kind of like that but for bugs. You can set up an admin to set up user access to specific websites, all you need is add a few lines of js to the website you want to use.
Tagging a particular bug is as easy as clicking on a specific area of a page. Bugherd will mark that section of the page with a screenshot and information about the bug. Obviously this is helpful for team workflow and managing ongoing bugs within a project.
TeamCity
This is more of a deployment tool, that gives you feedback whenever you push code to live/test server environments. I’ve primarily used it with Umbraco (.NET), so the process of publishing a site is a bit different to, say, PHP. .NET requires compiling/building of the code before running. If anything goes wrong the build will fail and the changes won’t be seen on the site. Obviously those issues are usually logged, and you can fix accordingly. It also allows for a changelog trail to show who has submitted what code etc.
I’ve not tried this with PHP, but teamcity can theoretically be used for any project where you have to push code changes to a server.
Browserstack
You can test for bugs on a wide range of devices via the browser through this website. It’s handy because they supposedly use ‘real’ devices, rather than device emulation. Some of the devices also support a dev tools view, so you can debug directly in the website. It also has the ability to connect to a local network, although I’ve found this to be sometimes flakey and needs a browser extension of some sort to work. It may also be that local network firewalls might interfere with it a bit. Overall not a bad tool to use if you need to test on a particular device, and don’t have one to hand.
GT Metrix
This tool covers your web page load speed issues. It pulls data from google pagespeed and yslow, in a format that’s quick to scan over and fix issues. A go-to tool I use prior to passing a website over to a QA team.
W3C Validator
This is useful for ensuring your HTML markup is valid, and is also helpful for debugging any layout issues you might have due to unclosed HTML tags etc. There’s also an api for this, which allows for automation of checking your HTML files. This is what I use as part of my npm tasks.
Siteimprove accessibility checker
This should cover the basics in checking your website accessibility is okay. It’ll check for alt tags, form labels, colour contrast etc. There are also browser extensions for this, to speed up checking of your HTML pages. Don’t rely on tools to do all your accessibility, sometimes it’ll need a manual approach. In a related article I look at things to consider when making a HTML form accessible.