Functional testing checks whether things work. Visual QA checks whether they look right.
Lorem ipsum dolor sit amet, consectetur adipiscing elit tincidunt iaculis eget interdum pretium ullamcorper est dui, donec feugiat at etiam aliquam ornare parturient ut convallis gravida malesuada netus commodo hendrerit lorem sed imperdiet praesent consectetur fermentum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit quis ultricies sed non sodales morbi ornare non ullamcorper nulla aliquet viverra non est nulla bibendum nunc ac egestas habitant.
Lorem ipsum dolor sit amet, consectetur adipiscing elit asit ornare odio mauris egestas tincidunt cras tincidunt adipiscing vivamus iaculis ullamcorper turpis eros, congue pellentesque pharetra, eu tempor facilisis magna sed consectetur feugiat tempus quis vestibulum praesent.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Id odio duis est, et aliquet lectus nunc eu est ut enim tristique nunc quis pellentesque sit leo volutpat in quam cursus sit euismod feugiat.
“Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque velit in pellentesque”
Eget lorem dolor sed viverra ipsum nunc aliquet bibendum felis donec et odio pellentesque diam volutpat commodo sed egestas aliquam sem fringilla ut morbi tincidunt augue interdum velit euismod eu tincidunt tortor aliquam nulla facilisi aenean sed adipiscing diam donec adipiscing.
Visual QA is the process of checking whether a web page looks the way it was designed to look. It compares the rendered implementation against the original Figma design and surfaces differences in spacing, typography, colour, layout, and component dimensions. Functional testing checks whether things work. Visual QA checks whether they look right. The two are complementary and neither substitutes for the other.
Functional tests verify behaviour. A button does what it should when clicked. A form validates input correctly. A page loads within an acceptable time. None of that tells you whether the button is the right size, the form has the right spacing, or the page looks like what the designer intended.
Visual differences that functional tests miss include things like:
None of these break anything. Users can still complete their tasks. But they accumulate across a page, and a page with many small visual deviations from the design does not reflect what was intended, even if it is impossible to pinpoint any single thing that looks wrong.
Visual QA typically happens after implementation and before release. In practice it can happen at several points:
During development. A developer checks their own work against the design before marking something ready for review. This catches the cheapest problems at the moment when context is freshest and fixing something is quickest.
During design or QA review. A designer or QA engineer checks the implementation against the Figma design. This is where most visual issues are caught in teams that do not check during development. By this point the code has usually been reviewed and merged, so fixes require reopening work that was considered done.
After release. Stakeholders or users notice that something looks off. This is the most expensive point to catch a visual issue, both in terms of the effort to fix it and the time it has been visible to people outside the team.
The earlier visual QA happens in the cycle, the lower the cost of acting on what it finds.
The most common form of visual QA is manual: a person opens the design and the implementation side by side and looks for differences. This works for obvious deviations. It struggles with anything subtle.
The human eye is not a measuring instrument. A spacing value that is 14px instead of 16px is not something most people notice without a reference. A font weight of 400 instead of 500 looks nearly identical at small sizes. Colour differences within the same family are easy to accept as correct without comparing hex values directly.
Manual review is also inconsistent. Different reviewers have different tolerances and different amounts of time. The same implementation might pass review on one day and get flagged on another, depending on who is looking and how carefully.
Automated visual QA compares rendered output against a design reference geometrically rather than perceptually. Instead of asking whether something looks right, it measures whether it is right.
A spacing value is either 16px or it is not. A font weight is either 500 or it is not. These comparisons do not depend on the reviewer’s eye or their tolerance threshold on a given day. The result is the same regardless of who runs the check or when.
This makes visual QA a repeatable process rather than a variable one, which matters particularly as implementations grow more complex and teams grow larger.
