Process Spotlight — How We Do Quality Assurance Testing

If you've ever remodeled a room, you know how satisfying it is to watch macro level changes happen. Imagine that before and after moment — one day you have a drab couch atop faded carpeting, and the next day, "Tada!" a teal loveseat resting on a hardwood floor. ✨

But, you did remember to add felt pads to the feet of that new loveseat, right?

Macro changes get the attention, but micro changes make the beauty last.

One more example, then (I promise), we'll get to website testing.

During college, I worked on a construction crew that was converting the interior of a vacant library into a new private preschool. I mostly loved it, until the last few weeks.

The macro changes felt fast and looked dramatic: out went the heavy, gray laminated desks and in came the colorful toy bins. But, when all the big tasks were complete, there followed what felt like an endless string of tiny tasks.

An exit sign in the back hallway needed a battery.

A strip of vinyl baseboard needed to be installed in the janitor's closet.

The work continued, but the worksite was visibly unchanged. And there was the caulking. So much caulking.

At every point where a conduit travelled through a cinder block wall, we caulked around the conduit with a fire-proof material to seal up the gap. No casual observer could tell if we forgot to do this or used the wrong material. But overlooking that little detail would cause us to fail inspection; or worse, it would increase the risk of fire spreading unchecked in an emergency.

Micro tasks are not unimportant tasks.

Yes, you cannot open up a building for public occupancy without a major feature, like "walls." But neither could you open it without fire-proof caulk.

QA Testing — Because Details Matter

Quality Assurance (QA) Testing is the process we follow to verify that all features and functions of a new website are working correctly. Just like inspecting a new building, it's the final bit — a comprehensive, cross-departmental effort to track issues, squash bugs, and ensure that launch day is as error-free as a team of humans can make it.

Once we enter the QA period, we're no longer developing major features. Instead, we're looking for the small variables that could lead to out-of-proportion problems after launch. For example:

• A form with improper error handling that causes it not to submit
• A mobile implementation of a module that isn't usable
• A touch target that's too small
• Missing or ineffective keyboard navigation
• Insufficient color contrast on a button

These types of issues get discovered once a site is used heavily. QA Testing allows us to catch them early, before they are found by our clients or their users.

Our Process for QA Testing

Our process begins with a project's Lead Developer, expands outward to include the Project Team, and concludes with the client. Let's look at each stage in turn:

Developer Testing

The Lead Developer is responsible for testing their own code and any code other team members contribute to the site. To accomplish this, they'll use a combination of Chrome Extensions, Mac OS Apps, and scripts we've written in-house to conduct manual and automated reviews.

A Shoutout Moment for the Tools We Love 🧡

Chrome Extensions

• Microsoft Accessibility Insights
• axe DevTools
• Wave Evaluation Tool
• Responsive Viewer
• Webhint

Mac Apps

• Integrity link checker
• TGPI Color Contrast Checker

Empowered with an array of testing tools, the Lead Developer creates and completes a checklist generated from our Asana templates. It's comprehensive, covering categories from accessibility and author experience to security. Craft CMS makes it easy to provide a highly customizable author experience, so they leverage that to its full potential. And they pay special attention to the project's accessibility compliance target.

Some example checklist tasks include:

Author Experience

• Do all image fields in the CMS include recommended dimensions?
• Has help text been added where appropriate?

Accessibility (Target WCAG 2.0 AA)

• Have all color contrast errors been resolved?
• Can the user navigate with a keyboard?

Security

• Do all forms have CSRF tokens?
• Do all forms have a spam filtering mechanism in place?

SEO

• Do all pages have an H1?
• Are default metadata fields configured and are they outputting appropriately?

Once their checklist is complete, the vast majority of low-hanging fruit quality issues have been caught and addressed. Next, they're ready to engage the Project Team.

Pre-Client Testing with the Project Team

Once the Lead Developer's QA is complete, we expand our testing to include the full project team (Account Managers, Lead Designer, Creative Director, and the Director of Development) for a meticulous manual review.

• The account team checks for variances from the agreed upon scope of work
• The creative team checks for variances from the approved Figma UI Design (such as spacing inconsistencies or a button missing hover styling)
• And the Director of Development checks for any technical issues missed by the Lead Developer in their testing

We use a Kanban Board Asana template here, paired with a widget from Marker.io. The Marker.io widget allows us to add a convenient reporting tool to both the frontend (UI) and the backend (Craft CMS). The team reports issues found in both locations. Marker integrates easily with Asana to automatically create new tasks when testers report an issue.

If you use Marker.io, our free Craft Plugin makes it easy to add and configure it from within the Control Panel.

Enter the QA Master

The Lead Account Manager on the project also serves as the QA Master. They are the on-the-ground leader responsible for prioritizing, categorizing, and assigning incoming tasks to the appropriate team member.

Kanban boards are again ideal here, because they offer a convenient drag-and-drop sorting interface for the QA Master, and they give real-time visibility into bottlenecks in the testing process.

On a daily basis, the QA Master will be:

• Watching for and escalating critical issues (anything that prevents us or the client from adding content)
• Setting due dates on tasks assigned to the Lead Developer or Lead Writer
• Confirming the bug fixes made by the Lead Developers were successful
• Consolidating duplicate tasks
• And minimizing back-and-forth communication

Client Testing

Once the Project Team has resolved any of their outstanding tasks, the client is invited to join the QA process in a few defined testing windows:

• Content Population
• Post-Content
• Pre Launch Last Look
• and Post Launch

The time allotted for each window varies with the scope and length of each project. It could be a week, or two weeks with the aim of providing clients ample time to do hands-on testing and ask questions.

The QA Master proves even more vital to the process at this stage.

• They translate our team's tech speak to the client (web development comes with a lot of jargon)
• They watch for spiraling tasks that could impact the launch date
• They establish what is a true bug report vs. a non-bug request

All requests can be addressed, but only true bug reports are fixed within the scope of QA. Examples of a non-bug request are:

• Client changed their mind and would like to modify the look of a page or module
• Client would like to add new modules or page types
• A new need arises that the client didn't bring up before launch

The Post Launch Window

The last opportunity to submit a bug report is the Post Launch Window. After their new website is up and running, our team remains on hand to rapidly address any potential bugs discovered by the client or their users. While this window is rarely utilized, it provides a good deal of peace of mind to our clients.

What Could Go Wrong: The Perilous Path of Not QA Testing

It may be tempting when budgets are tight and timelines are short to abbreviate or skip QA. But, the risk of show-stopping bugs or potential loss of revenue is too great to ignore.

We include QA as a line item on each of our estimates and have always found the investment of time to be worth the return. It has enabled us to maintain high standards and provide positive, seamless experiences for clients and visitors alike.

Read More: Process Spotlight — How We Create Engineering Estimates

FAQs: Website QA Process & Cross-Functional Workflow

1. What is the goal of a website QA process?

QA ensures your site works flawlessly before and after launch, catching small but critical issues—like accessibility gaps or broken links—that could hurt user experience or brand credibility.

2. What are the main stages of your QA workflow?

We start with developer testing using accessibility, security, and SEO tools, then move to collaborative team testing with Marker.io and Asana. Finally, we open a structured testing window for client feedback.

3. Why is QA included in every project estimate?

Skipping QA risks bugs, security flaws, and brand damage—problems that cost far more to fix post-launch. Including it upfront ensures quality is built in, not bolted on.

4. Who is involved in the QA process?

Developers, project managers, designers, and content strategists all contribute to QA. This cross-functional approach ensures we check technical, visual, and content accuracy from every angle.

5. How do you track and resolve QA issues?

We log findings in Marker.io, which integrates directly with Asana for clear assignment and status tracking. This keeps fixes organized and nothing overlooked.

6. How does client testing fit into QA?

After internal checks, we give clients a dedicated window to test and provide feedback. Their input ensures the site meets both functional needs and brand expectations.

7. What tools do you use during QA?

Accessibility scanners, security checkers, SEO auditing tools, Marker.io for issue reporting, and Asana for project management. Each tool plays a role in ensuring a thorough review.

8. What's the biggest risk of skipping structured QA?

Even a small glitch—like a broken form or slow-loading page—can cost leads, damage trust, or hurt search rankings. QA is how we prevent those headaches before they happen.