Blog

qa

Why you should have a solid QA process?

So you have a gig to build a site for a local or not so local business, great! But what about a QA process? A QA process can save you untold hassle further down the line once you get to launch stage and beyond.

 

What Is A QA Process?

Simply put a QA process is a quality assurance process that you have in place to ensure launches, updates and other aspects of whatever you're doing goes off without a hitch. Many one man bands don't often feel the need to have such a process in place. After all, they are the one that built the site in the first place so what can go wrong?

Not sure what Tickera is? Go here to find out!

A lot. That's what can go wrong. The majority of designers, developers, website builders and agencies these days build sites based off other peoples code, whether that be taking a snippet from Github and not understanding what it does, through to starting with one of the many and popular multi-purpose based themes. But what can go wrong when such a situation arises?

A third party theme may have an update that you built the site on. That theme may then conflict with a plugin you're using to power a contact form, online store or booking form. Then you might come across issues when adding caching plugins into the mix. This is before we even start getting into security, caching, server side issues and more. The sole purpose of the quality assurance process is to ensure none of the above happens.

A strong QA process should mean your project goes off without a hitch but this doesn't always mean there won't be bugs.

While in an ideal world there would be no bugs at all, this is often considered near impossible for most website builds. You should be able to get to a bug-free situation if you wrote the software and it's completely custom. But when dealing with so many variables a completely bug-free launch can seem just a dream.

 

Planning Your QA Process

The planning of your QA process is the most important aspect apart from actually executing it. Depending on what you or your company does you may need different methods for each element. For example, if you build custom themes and also websites, your website QA process will most likely look very different to the QA process of developing a theme.

Let's take the approach of a QA process for a website build using third party software (a multipurpose theme and some plugins). First of all, by taking this approach to the build we aren't able to use automated testing tools/unit tests as we didn't write the code, rather we're just building the site for someone else using someone else's software which has hopefully already used unit testing.

Our QA process would look something like this:

 

1. Once build is complete test across all major browsers

Testing across all the key browsers is extremely important when building any website. While Safari, Chrome and Firefox may all be WebKit based browsers, they aren't the same and vary how they handle the output often with Safari needing specific CSS when Chrome may not. Reminds you of the good 'ol IE days, right?

Talking of IE (Internet Explorer) while offices and corporate companies stuck in 2008 may still use it, many web developers no longer offer support for IE. It's simply too outdated and makes much of the progress achieved in the last five years redundant by nothing working with it.

 

2. Once build is complete test on mobile devices and responsiveness

This is extremely important. Many people skip testing properly on mobiles. Often a site can look perfect on a desktop based computer and complete trash on a mobile device. By testing this and fixing any issues before handing over to the client, you'll save your self a multitude of headaches at a later date. The bonus being that most mobile issues can often be solved with some simple CSS.

 

3. Test any functionality before hand over

This includes things like emails, does the install send all emails at is should? New user emails, password reset emails, transactional emails, etc. If it doesn't, this will need fixing before hand over. If the site has an online store or booking form make sure that you check the checkout process can be completed without a hitch, the order is received, and the order email received. If the client sells digital downloads, check that the downloads can be uploaded to the site with no size limitations and that the download correctly comes through for the person that purchased it.

 

4. Cleanup

Often when building a site you might make multiple revisions, install a couple of different plugins before you decide on one or create test pages. Before handing over to the client check that all test pages are deleted and that you've removed any plugins that aren't needed. It doesn't look very professional when a client gets their site and sees "test 1, test 2, checkout test" etc. in their pages.

 

5. Lock it up! (optional)

Depending on the deal you with the client and if you are handling the maintenance you may wish to lock various aspects of the site, i.e., give the client a custom user role that can't update plugins/themes so they can't break anything. This is a sticking point, and many developers including myself always believe that the client should have any access required, so they don't feel tied to one person.

 

Conclusion

This is by no means an exhaustive list or a complete QA process. What you need will depend on the personal circumstances of your business. Hopefully, though you now have a better idea of why you should have a QA process and what can be included in such a process.

Do you have already have a QA process in place? Perhaps adding a QA process allowed you to up your productivity? Let us know in the comments below.

Jack Kitterhing is a WordPress developer from England. His love of WordPress began at age 11 when he set up his first blog. After a stint as WPMU DEV's Project and Quality Assurance Manager, he's now a Software Developer at Themeco.