Hello everyone, and welcome back to Front End Center!

Time flies, work gets done, and we all keep on learning. In keeping with the end-of-the-year theme, I wanted to touch on a topic that involves wrapping up projects. This week, both for the sake of my architecture planning and just in general, let’s talk about Quality Assurance from a front end perspective.

Quality Assurance means different processes for different development roles. For back-enders, QA is focused on making sure that the end result of their functions and processes comes out as intended.

Forms, databases, algorithms, and more must communicate and process together correctly to reach the desired goal, given the correct inputs. Thorough Quality Assurance should also consider edge cases of what might happen if incorrect inputs happen to make it into the system. In addition to the system as a whole performing as expected, each of the parts should be able to handle its own, smaller task to provable quality.

Front-end QA often focuses on the user interface of a website or application, and the related user experience. Exact Quality Assurance processes are going to vary depending on what your front-end workflow is, and how that workflow plugs into other teams within a given project. User experience, graphic design, and back-end’s own building and QA can greatly impact what tools we can use.

The biggest picture for proper Quality Assurance is the simple question of “Does it match the intended design?” Often you’ll have design files or in-browser mockups to reference for a starting point. These artifacts from the start of your front-end development process provide an easy comparison for QA testing across multiple browsers. If the project in question doesn’t immediately look like the image reference, there’s a problem.

Whether explicitly written out or not, a QA tester should compare and confirm similarity of a number of design elements. Font and element sizes, font families, margins, padding, borders, accurate colors, list formatting, and more. If there is an issue with the comparisons, it’s far more valuable to pinpoint where that discrepancy is.

Sometimes a given page may look catastrophically incorrect, but all the differences cascade back to a single error in element size or position. Fix that and everything else clicks back into place! Experience with front-end development (or even just prior front-end QA) can be invaluable, making the difference between a succinct fix and a multi-page report on endless problems that are actually non-issues.

Years ago, testing multiple browsers was the pinnacle of careful attention and good Quality Assurance. Now? It’s just the start. Responsive designs mean we have substantially more testing to do, in multiple layers.

First, we need to ensure that the page actually responds appropriately at the intended breakpoint sizes. Then we need to see if those responses match up to their own intended design. Finally, does the content flow and work appropriately in transitionary stages. Between each of the pre-designed breakpoints, there’s a chance an extra-long sentence or specifically sized image will cause unexpected issues. More than just working at three or four specific screen sizes, we need to make sure that our pages are usable at all scales.

If you’re working on a dynamic website or application, the content itself can require QA testing to make sure it’s usable in many different capacities. Variable content lengths, form options, and navigation in particular can put proper Quality Assurance through its paces. When planning for these challenges, how do you address “failure” cases? To prevent navigation from overflowing, do you wrap the items into multiple rows? How about shrinking down the text? Maybe it would be better to be proactive and head the problem off entirely by limiting how many items can be in the navigation at all.

However you handle your dynamic challenges, the QA tests need to ensure that the implementation and end results both function as expected.

While a lot of functional testing is the realm of back-end, there are plenty of moving parts in front-end development that need adequate testing. Form layouts and handling is a major element that must not be overlooked. Until a user’s data is already on the server and being handled, we need to ensure that the input and transfer is a smooth experience. Label placement, mobile usability, and error handling are major focuses.

When these (and many more) tests have been run, there’s still a significant component of front-end development to consider: how does your page perform?

Whether you’ve been following a strict set of expectations for your project’s performance, or are just working to a “good enough” goal post, quantifying performance fits in perfectly with the Quality Assurance process.

Like other elements, we can consider the overall performance of a given page, and then further break down its elements. Rigidly optimized projects might consider every portion of their HTML, CSS, and JavaScript. Most will only need to dig into their JavaScript, and enough CSS to make sure nothing is heinously wrong.

JavaScript performance testing should focus on animations, DOM rendering, data exchange, or other intensive tasks. Anywhere a library or framework is used, effort should be put in to ensure that wasted resources aren’t weighing a page down or causing excessive loading times. While the effects are much less pronounced today than ever before, there are still different JavaScript engines powering various browsers. Make sure and see if any particular JS is causing a unique incident in a browser due to engine quirks.

Digging into the specifics of applying these processes is often down to a very per-project basis. As I’m able to leverage my architecture plans in the future, I’ll be doing my best to track each stage of a project to use as reference of these ideas. Discussing lofty goals is one thing, but providing concrete examples is something else entirely!

Thank you for listening. This has been Chris Landtiser and Front End Center.