What “Tested” Should Mean: How We QA Every Drupal Component
Every component Vardot delivers passes quality assurance (QA) before the client sees it. QA reviews the design before development starts. It then tests the built component for function, user interface (UI) match, browser and device compatibility, accessibility, and performance where needed.
Once a component passes, automated tests recheck it in every release, so a fixed bug that comes back is caught before it ships.
This guide is for digital and technology leads at enterprises, public agencies, universities, and nonprofits who want to know what “tested” means before they sign off on a delivery.
Key Takeaways
- QA starts at the design, not after the build. Gaps found in a design cost far less to fix than gaps found in code.
- Each component goes through six testing types: functional, non-functional, UI, compatibility, accessibility, and performance when needed.
- UI testing compares the built component with the design the client approved, at every breakpoint.
- Compatibility testing covers the browsers, devices, and screen sizes your users have.
- Automated tests rerun key checks in every release, so a regression is caught before it reaches the live site.
Why Test Each Website Component Before It Reaches the Client?
Testing each component before delivery catches a bug once, before it spreads to every page that uses it. A component is a reusable part of a site, such as a header, a search form, a card, or a slider. One component can appear on hundreds of pages.
On a Drupal site, components are often built as blocks, paragraph types, or single directory components (SDC). Drupal Canvas, the visual page builder, has an AI assistant that builds pages from your existing components. Every page it builds inherits their quality.
Testing at the component level also means the client’s review time goes to business decisions, not bug reports. A component counts as delivered when it meets three tests:
- It does what the requirements say.
- It looks like the design the client approved.
- It works for every user, on every supported browser and device, including people who use assistive technology.
When Does QA Get Involved in a Website Project?
QA joins before development starts. The QA engineer reviews the design with the designer, while changes are still cheap.
In that review, QA checks that the design answers the questions the code will face:
- States: hover, focus, active, error, empty, and loading.
- Screen sizes: how the layout changes on desktop, tablet, and mobile, and at each breakpoint (the screen width where the layout shifts).
- Content limits: long titles, missing images, and translated or right-to-left text.
- Accessibility: color contrast, visible focus, form labels, and a logical reading order.
- Requirements: each business rule in the requirements has a place in the design.
Gaps go back to the designer or the client as questions. QA then writes the test cases, so developers know how the component will be tested before they build it.
Which Testing Types Does Each Component Go Through?
Each component goes through six testing types, each answering a different question. Automation then reruns the key checks in every release.
Table: Six component testing types plus release automation, what QA checks, and when each passes
Testing Type | The Question It Answers | What QA Checks | Passes When |
|---|---|---|---|
Functional | Does it do what the requirements say? | Every action, rule, input, and error message | Every test case from the requirements passes |
Non-functional | Does it work well, not just work? | Usability, security basics, behavior under real content | No blocking issues in use |
UI | Does it match the approved design? | Layout, spacing, fonts, colors, icons, and states | The build matches the design at every breakpoint |
Compatibility | Does it work everywhere users are? | Browsers, operating systems, devices, and screen sizes | Same behavior and layout on every supported platform |
Accessibility | Can everyone use it? | Keyboard, screen reader, contrast, labels, focus | Meets WCAG 2.1 Level AA |
Performance (when needed) | Is it fast enough? | Load time, image weight, scripts, behavior under load | Meets the project’s agreed targets |
Automation | Will it keep working? | Key flows rerun in every release | Tests pass before each release ships |
Read the table top to bottom: the first six rows show the component works on delivery day, and the last row checks that it keeps working.
How Do We Test That a Component Works?
Functional testing checks the component against its requirements, with one test case per rule. For a search form, that means results for a valid term and a clear message when nothing matches. It also means sensible handling of empty or very long input.
Non-functional testing checks how well the component works. Is it easy to use? Does it handle real content? Does it avoid basic security issues such as unsafe input?
How Do We Confirm the UI Matches the Approved Design?
UI testing compares the built component with the design the client approved, side by side. QA checks layout, spacing, typography, colors, icons, and every state, at each breakpoint.
The approved design is the reference, not the developer’s reading of it. Any difference is either fixed or agreed with the client.
How Do We Test Components Across Browsers and Devices?
Compatibility testing confirms the component behaves and looks the same on every supported platform. We test on desktop browsers such as Chrome, Firefox, Edge, and Safari, and on real phones running iOS and Android.
We also check different screen sizes and orientations, because a layout that works at one width can break at another.
How Do We Test Component Accessibility?
Accessibility testing confirms people can use the component with a keyboard, a screen reader, or zoom. We target Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. It is the standard the US Department of Justice adopted for state and local government websites under Title II of the Americans with Disabilities Act (ADA).
Automated checks catch issues such as missing labels and low contrast. Manual keyboard and screen reader testing catches what tools miss, such as a confusing reading order.
Our guide on building an accessibility remediation plan explains why fixing issues at the component level pays off. For the criteria WCAG 2.2 adds, see our WCAG 2.2 AA checklist for Drupal.
When Does a Component Need Performance Testing?
A component needs performance testing when it is heavy or busy. Examples include a large image gallery, a map, or a search that serves many users at once. QA measures load time and behavior under load against targets agreed with the client.
For simple components, standard page checks are enough.
How Does Automated Testing Prevent Regressions?
Automated tests rerun a component’s key flows in every release, so a regression is caught before it reaches the live site. A regression is a bug that returns after a fix, or a new change that breaks something that worked.
Once a component passes manual testing, QA adds automated tests for its key flows, built with Playwright, an open-source browser testing framework. These tests include automated accessibility checks and run in the release pipeline, so every change is tested before it ships.
Our view from QA: manual testing confirms a component works on delivery day. Automation shows it still works six releases later, after other teams have changed the code around it.
Release tests cover what each release changes. Between releases, a website governance platform such as Auditray, which Vardot built, keeps checking the live site against your standards.
How Does a Component Move From Design to Delivery?
Every component follows the same path, in this order:
- Review the design. QA and the designer check states, screen sizes, content limits, and accessibility before development starts.
- Write test cases. QA turns the requirements and the approved design into test cases the developers can see.
- Test the build. QA runs functional, non-functional, and UI testing against the approved design.
- Test everywhere. QA runs compatibility and accessibility testing, plus performance testing when needed.
- Fix and retest. Developers fix each reported bug, and QA retests it. A component that fails goes back to step 3.
- Automate. QA adds automated tests to the release pipeline, so the component is checked in every release.
Deliver. The client reviews a component that already meets the requirements and the design.
How Do You Know a Component Is Ready for Client Review?
A component is ready for client review when you can answer yes to all seven checks:
- QA reviewed the design before development started.
- Every requirement has a test case, and every test case passes.
- The build matches the approved design at every breakpoint.
- It works on every supported browser, device, and operating system.
- It meets WCAG 2.1 AA with a keyboard and a screen reader.
- Performance meets the agreed targets, where they apply.
Automated tests for it run in every release.
If any answer is no, the component isn’t ready for client review yet.
Where Should You Start if You Aren’t Sure How Your Components Are Tested?
Start with an audit. A Vardot Drupal audit reviews accessibility alongside security and performance. It rates every finding by risk, so you can see which gaps to close first.
Vardot is a Drupal Diamond Certified Partner. We build and support Drupal platforms with QA in every delivery, from design review to release automation.