getting it right: quality assurance in web development
January 8, 2020
written by
Rex Vokey
why QA?
I know this sounds crazy, but not everything 300FeetOut does is 100% perfect from the get-go. I know, I know, crazy but true. In order to deliver the best possible result, we review things several times in our process. Whether it’s a whole site we’re building or part of a site we’re changing, we always double-check our work. But “double-checking our work” isn’t as simple as it appears on the surface, so let’s break it down.
Requirements Testing
From the very beginning of a client’s request—whether it’s a whole website or a new feature for an existing site—we’re listening to what requirements need to happen. Some of these requirements are things outright stated by the client. Some are things we recommend, based on our extensive experience over the years. Some of them are industry standards or just nice to have. So once the UX wireframes and design skin prototypes have been created, QA happens by all of our internal teams before a client even hears about it. We review these to make sure they’re in line with the requirements and get client approval to move forward with the build.
Design Testing
After that initial build of the code, we need to make sure the intended design looks as it should in the real world (i.e., in the web browser) so we review the coded designs in different web browsers and devices to make sure they work. At this stage, since we’re an integrated design and development team, we make tweaks to the design to align it with real-world presentation and use so they line up with the original intentions and requirements that the client approved.
Functionality Testing
This is where it all comes together; the marriage of requirements, the design (UX and UI), and the code. We go through the alpha site and make sure it all works as expected. Remember, a website isn’t just a bunch of flat pages like a book. It has links, buttons, integrations, images, videos and other functionality that make them work. For a basic site, we’ll make sure all the conversion points outlined in the business strategy objectives work, on multiple modern browsers and devices. We make any needed changes and then we’ll check it all again. Over and over and OVER again until we’re satisfied that we did a good job. For more complex sites, we go back and take the entire user flow created earlier and run through those against the site, making sure every step of the process works.
Beta Testing and Beyond
Then finally, we’ll hand the beta site over to the client for review. As you’ve learned, hours of QA have already gone into the project at this point. And because we’re an integrated agile team, everyone has reviewed it from SEO to UX to development so when the client does see it, the site is as close to perfect as we can get for the majority of people. However because the combination of browser versions, operating systems, extensions, corporate governance, and individual settings is nearly endless… it means we do more QA until launch. And because after a site launches browser and OS versions change, we continue to do QA on a monthly basis to keep search engines, security updates, and even our clients healthy and happy.