Visual testing questions are becoming more common in SDET interviews. Interviewers want to know if you understand the tradeoffs, the flakiness problem, and how you would set it up in CI. Here are the most asked questions.
Q: What is visual regression testing and when would you use it?
A: Visual regression testing compares screenshots of an application against approved baselines to catch unintended visual changes. I use it when CSS changes affect multiple pages, when a design system component is updated, and before major releases. It catches layout shifts, font changes, color regressions, and broken responsive behavior that functional tests completely miss.
Q: How does Playwright handle visual testing?
A: Playwright has built-in visual testing with the toHaveScreenshot() assertion. On the first run, it saves a baseline screenshot. On subsequent runs, it compares the current page pixel by pixel against the baseline. If the difference exceeds the configured threshold (maxDiffPixels, maxDiffPixelRatio, or threshold), the test fails. It generates diff images showing exactly which pixels changed.
Q: Visual tests are known to be flaky. How do you make them stable?
A: Five strategies. First, mask dynamic content like timestamps, balances, and session IDs using the mask option. Second, set animations to disabled so CSS animations are frozen. Third, set caret to hide to remove the blinking cursor. Fourth, use threshold and maxDiffPixelRatio to tolerate minor anti-aliasing differences. Fifth, use Docker for consistent font rendering across local dev and CI. The biggest win is Docker -- it eliminates the cross-platform rendering differences that cause most false failures.
Q: How do you handle visual testing in CI/CD?
A: I run Playwright in the official Docker image both locally for generating baselines and in CI for running tests. Same image means same font rendering means matching screenshots. I store baselines in git so the whole team shares them. The CI pipeline runs visual tests in a separate job, uploads diff images as artifacts on failure, and has a manual workflow for updating baselines after intentional UI changes.
Q: What is the difference between element screenshots and full page screenshots? When do you use each?
A: Full page screenshots capture the entire page. Good for layout validation and smoke tests. Element screenshots capture a single component like a navbar or card. Good for testing shared components and different states (hover, active, disabled). Element screenshots are smaller, faster, and less flaky because they are not affected by changes in other parts of the page. In practice, I use 80% element screenshots and 20% full page screenshots.
Q: What is the --update-snapshots flag and when should you use it?
A: The --update-snapshots flag tells Playwright to overwrite existing baselines with the current screenshots. I use it only after an intentional UI change -- a designer changed a button color, a layout was redesigned. I never run it blindly. My workflow is: run tests, see the diff, confirm the change is intentional, then update only the specific test file with --update-snapshots. I review the updated PNGs before committing.
Q: Compare Playwright visual testing with Applitools or Percy.
A: Playwright uses pixel-by-pixel comparison and is free. Applitools uses AI Visual comparison that ignores anti-aliasing and font rendering noise, greatly reducing false positives. Percy sends DOM snapshots and renders them on their cloud servers for consistent cross-browser results. Playwright is great for small to medium projects. For large enterprise apps with many pages and a design team that needs a review dashboard, Applitools or Percy justify their cost with lower maintenance.
Q: How would you implement responsive visual testing?
A: Two approaches. First, use page.setViewportSize() in test loops to set widths like 375 (mobile), 768 (tablet), and 1440 (desktop). Second, configure viewport-specific projects in playwright.config.ts using devices like iPhone 13 and iPad. I focus on breakpoint boundaries -- testing at 767px and 768px where the layout switches. I screenshot shared components like navigation separately at each width since they change the most across breakpoints.
Key Point: In interviews, emphasize the flakiness problem and your solutions (Docker, masking, thresholds). Knowing the tradeoffs between Playwright built-in and third-party tools shows seniority.
Key Point: Know the flakiness problem and solutions. Explain Docker for CI, masking for dynamic content, and when to use third-party tools over Playwright built-in.
Answer all 5 questions, then submit to see your score.
1. What happens the FIRST time you run a test with toHaveScreenshot()?
2. Which option should you use to ignore dynamic content like timestamps in visual tests?
3. Why do visual tests often fail when baselines are generated on macOS but tests run on Linux CI?
4. What is the safest way to handle an intentional UI change in visual tests?
5. When would you choose Applitools or Percy over Playwright built-in visual testing?