Good Morning, and Welcome back if you’ve read Part 1!
In this part we’re gonna flesh out our Quality Control Process we started in Part 1. I’m thinking that when we’re done today, we’ll have a pretty solid checklist and set of steps to follow
to ensure our product – namely our pages and sites – not only work as intended, but also leave a good impression with our customers and their users. Last time we hit up this article, so we’re going to build off of what we learned from it:
What we have so far:
1. Checking for breakpoints & errors
2. viewing at different resolutions and on different devices. For me this will mean covering about three breakpoints. It’s important to use different device types, as a typical phone screen resolution may not look the same on a phone as it does on a monitor.
3. Testing for speed. Does it take a long time to load? Why?
4. Solicit input from a test group. What is their feedback like?
Now that we’ve spend way too much time reviewing, let’s find some industry standards!
A quick google search yielded the following results:
(Yes, I clicked on the wiki page. It’s ok to read wikipedia; just don’t take it as gospel. Always always ALWAYS verify sources!)
That search did lead to this article from smashingmagazine.com: https://www.smashingmagazine.com/2019/01/web-standards-guide/
*43 minutes go by*
OK, so this article help us know what standards are out there, which helps. My preference is toward W3C when it comes to standards – primarily because I’m most familiar with it, and it’s pretty efficient to check. You just run your file(s) through their validator tool: https://validator.w3.org/
From here I think we have a pretty good quality control model. We have the things we need to look for and the standards we need to align our content with. From here, it’s pretty easy to stitch these things together in a process:
Given a product that is ready for testing, we do the following:
1. Check for breakpoints, logical and grammatical errors (ex.: unit testing, integration testing, etc.)
2. View the product at different resolutions (testing for responsiveness).
3. View the product on different browsers – Chrome, Safari, Edge and IE at a minimum.
4. Review page load times – making sure to clear the browser cache before each load, and to do this for each browser.
5. Run the file(s) through the W3C validator.
6. Write a report noting any issues found, and send back. If no issues found, approve for release.
Now, as processes go, this is pretty simple. Luckily, we can employ a continuous improvement mindset, and build on this as we run into different issues that expose flaws in the process. It’s also important to note that there will always be flaws in any process; while you want to close as many quality gaps as you can early on, it’s equally important to stay vigilant and watch for issues.
With that, I invite you to share your quality control ideas and experiences below; I would love to hear your perspectives! Until next time!