Most webpages are written in languages (such as HTML) that allow contributors to structure the text, add multimedia content, and specify the style or appearance of a website. As with every language, these have their own grammar, vocabulary, and syntax, and every document written with these computer languages are supposed to follow these rules. These machine-readable grammars are called "Document Type Definition" or DTDs.

However, just as texts in a natural language can include spelling or grammar errors, documents using Markup languages may also have errors. The process of verifying whether a document actually follows the rules for the language(s) it uses is called validation, and the tool used for that is a validator. A document that passes this process with success is called valid. We can define "markup validation" as the process of checking a web document against the grammar it uses.

We use the W3C HTML Validation tool to validate our HTML and W3C Link Checker to check all links and anchors in a webpage.

Browser Testing

Our projects currently support Internet Explorer 11, Microsoft Edge, and the latest two versions of Chrome, Safari, and Firefox on OS X and Windows. We use BrowserStack to test our responsive designs in multiple browsers.

Automated Regression Testing

Regression testing is a set of automated tests to compare visual differences on websites. It’s an automated game of “Spot the Differences”, where your computer uses a web browser to render a page or portion of a page and highlights all the differences it finds between two sources.

We use BackstopJS that we run manually or through our build process to report on any unintended visual differences when we make design/development changes to websites.

Performance Testing

With more and more users accessing sites from a mobile device, website speed is critically important. We test our sites before and after launch using:

We aim to get a Google Page Speed score of 90+ and a YSlow score of 85+


Making a website inaccessible makes you lose opportunities and cuts off your audience from the browsing experience. We want to try and minimize this as much as possible.

Some key things to remember:

There are also sites out there to help test site accessibility: * Web Accessibility Checker * WAVE Web Accessibility Tool

Check out the Web Accessbility Initiative's website for a more in-depth overview!

Launch Checklist/Process

These are some of the high-level checks we make before launching and is not a complete list as each project is different.

Page Content

Optimize User Experience

Responsive and Mobile Friendly



301 Redirects


Functional Testing

Coming Soon

Bug reporting best practices

As developers and team members, it's our responsibility to establish a workflow for reporting, cataloguing, and describing the bugs that people are likely to encounter.

Having a system for bug reports in a team environment has a ton of benefits:

With a solid bug-fixing system in place, we're in a much better position to do great work, yet it's important to note that good bug-reporting skills are not only a requirement for developers. Everyone on the team should be capable of finding a bug and providing as much information as possible about it. This means that designers, developers, and project managers of all experience levels shouldn't be afraid to use the bug tool and get an overview of the project as a whole.

Here at Hypenotic, we use Github Issues as our preferred bug reporting tool.

Here are some best practices in bug reporting.

1. Be short and to the point

Ideally we want bullet points rather than long sentences so that a developer can find the issue as quickly as they can although that doesn't give us an excuse to be curt. It's best to describe the problem as accurately and with as few deterrents as possible. If there is someone who built that particular feature and knows the in-and-outs of it, perhaps you should assign it them first.

2. Make sure to add screenshots

For animation and complex interaction bugs in particular, animated GIFs are almost essential to highlighting the flaw's peculiarities. However, for the most part, a simple screenshot will help us find which view or template the bug can be found in.

3. Identify the browser version

It's very helpful to quote the name of the browser and version such as "Chrome 42" or "IE8". But, if you can also figure out whether the bug isn't present in other browsers then that's even better, something like: "I found this bug in iOS 8.3 but I can't replicate it in any other Webkit browser." With this sort of information you might save a developer a lot of time and they can more quickly identify what's going wrong.

If you want to make sure you send along all the possible information, you could use a tool like that snags a lot of stuff and allows you to email it or PDF it.

4. Make note of which template/page the bug is on

If it's on the /blog or the /contact-us page, or if it can be found in a specific partial such as the header or the footer, let the developer know that as quickly as possible.

A full URL is usually super helpful.

5. See if there are any console errors or notifications

Rather than copy/pasting the console error it's probably best to take a screenshot if there's any warnings. They might be unrelated to the particular bug you've found, but it might just be the thing that's messing everything up.

7. Double check if the bug has already been found

This task might also involve you going through and seeing which bugs are similar and tagging the problem in the app that you use. If the bug has been found then maybe it's worth adding more information or noting on the card as to where you found a new instance of the same problem.

8. Group tasks into specific categories

It's helpful to separate everyone's tasks into specific areas such as:

This gives us an overview of the project timeline and gives developers an opportunity to look at all the bugs with a single glance.