Quality assurance in web development is about testing systems — checking whether the things we've built stand up to the use cases they were designed to solve. But this makes the assumption that use cases are systematic; sometimes, the issues we face are not systematic. Sometimes, the issues are humans.
When we talk about QA, we talk about finding problems. Sometimes those problems are found in the system itself, such as a broken link or an error page. These can be fixed by the developer who built it. Sometimes, the problem is systemic, and the CMS vendors themselves need to dive in and make a change. And sometimes, after a bug is reported, you can only mutter one thing: "Why would they do that?" Welcome to the biggest challenge in testing websites: people.
People Are the Pivot Point
Before testing websites, I came from software testing. The rules were clear, and the systems, however complex, were logical. Software testing is rigid and structured, because it is difficult to push changes to everyone who’s already installed that software.
On the web, though, things are different. When I started testing content management systems (CMS) at Blend, I was surprised by how challenging the work is — not because the systems were harder to understand, but because of the people using them.
In software testing, QA leans heavily on analytical and logical reasoning, built around data. That kind of testing brings its own challenges: massive and often messy data sets, complicated system integrations, a working understanding of complex code, unexpected regression issues, and intricate test scripts — whether manual or automated.
Web testing has some of this as well — regardless of the medium, the core principles, methodologies, and lifecycle stay the same. But when you break down website testing — specifically CMS testing — against software or data-heavy application testing, a clear split emerges: data-oriented vs. process-oriented thinking, all the way through planning, design, and execution.
This makes CMS testing a different animal entirely. And it’s all about people.
People Are Hard. They're the Wild Card.
No matter the size of your organization, your website has to meet the needs of its users. But "users" means something very different today than it did even five years ago. As structured data, schema, and automated processing (the behind-the-scenes formatting that helps machines and search engines read your content) become central to how businesses operate, it's easy to lose sight of the human on the other end of the screen.
Sometimes that human is frustrating. It’s easy to roll your eyes when a bug comes in from the business or a client on something you built or tested and it turns out to be what you might call “user error.” Your gut reaction is likely to be "why would they do this?" or "It wasn't built to do that."
But it’s a good reminder that all of this is a balancing act. What feels frustrating — what looks minor to a developer or tester — might be a critical step in a user’s daily workflow, worth hours of time day-to-day. This kind of situation has led to a personal motto:
"Data's easy — it's predictable. People are hard. They're the wild card."
Unpredictability multiplies in CMS testing, because you're not testing for one user — you're testing for several, each with a completely different agenda:
- The editor. Editors configure, manage, and publish massive volumes of content. Their decisions — what to publish, when, and how it's organized — are deliberate and strategic. And they may be completely different. You must anticipate scenarios you'd never think to write into a test case.
- The consumer. Depending on the type of site — a financial institution, a children's hospital, a government agency — your consumer's actions will vary wildly: what they're looking for, what device or browser they're on, their technical comfort level, and their accessibility needs. All of this shapes how you test.
- The browser. Every editor and consumer experiences your site through a browser, and browsers don’t all tell the same story. Each browser interprets HTML, CSS, and JavaScript a little differently, which means a test that passes in one browser isn’t guaranteed to produce the same result in another.
- Machines as users. It's not just people anymore. Increasingly, you're testing for machines too — AI-assisted search tools, crawlers, and bots that read your site directly, with no human ever clicking through.
From Who to What: Testing for People
Beyond the unpredictable human element, CMS and website testing bring a few challenges that are easy to underestimate:
- Content testing. CMS platforms are built to give editors a wide range of elements to choose from. It's not just about whether components are positioned and functioning correctly — you also need to test a wide range of actual published content to confirm it holds up to the client's needs.
- Design testing. This goes well beyond checking colors and styles. Does the design work intuitively? Does it give the client the flexibility they actually need? And most importantly — is it accessible to all users, no matter how they're experiencing the site?
- Functionality testing. Basic feature testing is a given, but multiple end users add real complexity. Testing a single button, for example, means testing once through the editor's lens, and then once through the consumer's. CMS platforms are built to give businesses the freedom to publish quickly and often, but it's hard to build and test guardrails when the whole system is designed to remove them.
- Performance testing. Performance testing is the unsung hero on this list. Your content and design can pass every check, the site can technically function during review, and you still won't know how it holds up until you replicate real user behavior and volume.
Data Taught Me to Expect the Complex. People Taught me to Expect the Unexpected.
There are a lot of skills that go into testing, but overall it can be split into two areas: expecting and confirming complexity, and expecting the unexpected. Both skill sets matter, but only one requires you to think like an editor, a first-time visitor, an accessibility user, and a search algorithm — all at once, all in the same test cycle.
That's the real shift I've gone through: moving from predicting what a system will do, to anticipating what a person might do.
If you're making a similar move in your own QA career, my advice is simple — the fundamentals still apply, but bring your empathy along with your test cases.
People really are the wild card. Test accordingly.
