In the world of construction, it doesn’t technically take a whole lot of effort to build a website or a house. A young designer or programmer could download some applications, find a few WordPress templates and go to town on a fan fiction website about My Little Pony just as quickly as someone without carpentry skills could pick up a hammer, some nails and lumber, and build a house.

I’m not saying either of these projects is bound for failure; they just might be lacking some incredibly helpful planning, experienced talent and – an incredibly essential ingredient to any project (that you care about) – Quality Assurance.

Ideally, someone should be planning each of those projects, and they should be handled by skilled professionals. But even with those two important ingredients, they need to be tested and tested and tested until neither of them falls apart when someone kicks it around.

“Failing to plan is planning to fail.” – Alan Lakein

Quality Assurance (QA) is one of the most important elements of any digital team’s process. Planned during early stages of a project and enacted at certain stages of the build properly, this piece of the puzzle helps to ensure that deliverables work and hold up to a great deal of elements and abuse.

I would like to think that every project an agency works on, and certainly each of those we work on at Switch, deserves the same effort in testing. For example, we recently planned, designed, built and activated a “Mad-Libs”-inspired kiosk engagement/interactive game that runs at multiple trade shows, delivering product benefits to attendees and customers. And yes, it also serves as a vehicle for giving away coffee gift cards and smart watches (after all, everything is better with a dangled carrot).

This project involves front-end interaction on two input displays, a large screen pulling in creative pairings/responses, an admin area, a customizable prizing mechanism and a few other moving parts. During the same month, we planned, designed and programmed a retail client’s 30+page website, which had many other types of moving parts. Both went through a very similar QA process.

Basically, we sift through a big “list” that guides testers on our team through a gauntlet of tests to ensure that the links, content, forms, scripting/functionality, alt tags and expected interactions play out correctly. Then, producer/UX/programming folks recommend and make fixes, run through it again and repeat as necessary. After this gets the project to an approved state in the primary browser, we run these through all of the browsers we’ve scoped in the requirements of the project to be supported.

An integral element here: The key programmer should not be involved in testing. QA is most effective when the testers have not been involved in the development. It’s similar to how writers typically require a second or third set of eyes to edit what they’ve written; sometimes eyes glaze over errors that they are too close to see.

“After you’ve worked on a site for even a few weeks, you can’t see it freshly anymore. You know too much. The only way to find out if it really works is to test it.” These are the words of Steve Krug from his popular book on web usability, Don’t Make Me Think.

If you have the budget and time, test it externally as well – especially if you care about a quality user experience. Test it against a few segments of your core audience. If you can’t do this, at least plan to look at analytics and adjust/optimize after launch or through periodically scheduled “check-ups.”

Benefits of QA

In one sense, QA could be thought of as The Art of Breaking Things. Besides the most obvious benefit of, I don’t know, not delivering obviously terrible work, QA is absolutely valuable to you as a team member and company. Clients like looking good, and a smart, effective digital experience helps make them happy. Happy clients come back to work with you again and again.

And from a budgeting standpoint, it is a steal. The amount of a project budget required to QA something well is far smaller than the amount to fix something that has been released to the wild, beaten up and labeled as broken in public. Healthcare.gov was a pretty good example of how to not do QA.

Let’s dig into some of the things Switch tries to build into our QA process:

Adherence to Web Standards

Without boring you with acronyms … complying with some fairly simple-to-implement standards allows a website to be indexed accurately in search engines, broadens the accessibility of a website and makes it available to visitors from different browsers, which is particularly important for visitors who have a disability or anyone that needs to rely on a specific browser or device for support. This one’s pretty easy, as there are a ton of tools to help you find issues.

Content QA

Quite simply: Is the creative good? Is it accurate? Does it match approved comps and copy documents?

• Copy is accurate and proofread: Routing sheets are checked off by numerous stakeholders.
• Design: Find missing elements, crop issues, styling issues? Fix them.
• Note: A digital project manager should be reviewing this before it gets to a programmer. This helps prevent the cycle of sometimes unnecessary pixel pushing and groaning from happening.

UX / Functional QA

Testing site functionality can overlap with web standards, but it is important to test a site against the technical requirements and functional specifications you have communicated to the client via good documentation (you have done that, haven’t you?). This should test a list of things that are supposed to happen when you do something (tap, swipe, view, click, scroll, etc.) Some examples:

• If a user hovers over navigation element A, B should happen. If it doesn’t, fix it.
• Test forms and database transfers to/from.
• Make sure form validation works correctly and provides EASY visual cues to the user to fix whatever they are not entering correctly.

QA is good. Maintenance is better.

We all want to ensure that a digital project is activated after proper testing so users don’t discover the flaws themselves, but QA doesn’t guarantee that a site is completely flawless; some issues aren’t immediately evident, and are only realized after the site or app has been in use for some time, and things change daily with browser, device and other web application updates.

Proper maintenance is again quite crucial after all of this happens. Keep site standards up, make updates based upon analytics to improve the user experience and update CMS-based elements and databases. The list goes on.

If you took the time to read through all of this blog post about the thrilling topic of QA, I want to extend to you a hearty congratulations. Now shoot me an email to say hi. Perhaps I’ll get you a drink next time I see you and apologize in person for the verbosity. Cheers! Brad