Non-Functional Testing interview questions
Non-Functional Testing questions a QA / manual tester can be asked, from first job to senior. Open one to see the strongest answer and why it works.
How do you start accessibility testing as QA, without being a designer?
The strongest answer: I try the money path with a keyboard and a screen reader, and I check names, order, and contrast — I do not only zoom the page and call it done
Why it works: Exactly. You can walk a path. Tools help; they do not replace a keyboard and a reader.
- Walk the money path without a mouse.
- Listen to the names and order.
- Use a scanner as a helper.
- Do not outsource the whole bar.
A user says “the app is slow.” What do you establish before filing it?
The strongest answer: Which action, how long it takes, on what device and connection, and whether it repeats — “the orders list takes eight seconds on Wi-Fi, every time” is something someone can act on
Why it works: Exactly — one action, a measured time, the conditions and repeatability turn a feeling into an observation.
- Turn “slow” into a measurement.
- Name the one action.
- Measure how long it takes.
- Record device, network, repeatability.
There is no UX researcher on the team, and the flow matches the specification exactly.
How do you raise a usability problem?
The strongest answer: With evidence rather than taste: where a first-time user hesitated or went back, how many steps the task took, what the error message told them to do next — filed as a usability finding with its cost
Why it works: Right — one or two people struggling, with the steps and the recovery path recorded, is evidence a team can argue with.
- Make usability observable.
- Watch a first-time user.
- Count steps and backtracks.
- Report the cost, not your taste.
Design says they “checked contrast.” What do you still do as QA?
The strongest answer: I walk the path with a reader and a keyboard, I check names and order, and I file what fails a task — contrast is one bar, not the bar
Why it works: Exactly. Contrast is necessary and not sufficient. Tasks still fail on names and order.
- Test the task, not the swatch.
- Keyboard + reader.
- File task failures.
- Do not bug-spam decoration.
You have 30 minutes on a new form. What is a responsible a11y smoke?
The strongest answer: Tab the form, submit with the reader on, check the error is announced, check the label is bound — I do not claim WCAG AAA
Why it works: Exactly. A task-level smoke you can stand behind. AAA in 30 minutes is a lie.
- Tab, labels, announced errors.
- Reader on the submit path.
- Do not claim a level you did not audit.
- Do not hotfix ARIA in prod as QA.
A designer says the contrast is “on brand.” The ratio fails the bar you published. What is the oracle?
The strongest answer: The published bar (and the law / store rule you cited) — brand can ask for an exception, it does not silently beat the gate
Why it works: Exactly. A written bar is the oracle. Exceptions are explicit.
- Publish the bar.
- Use it as the oracle.
- Exceptions in writing.
- Do not abdicate to brand.
A primary task cannot be completed with a screen reader. The release is tomorrow. What do you do?
The strongest answer: I treat it as a release-blocking defect on that task, I offer a cut or a delay, and I do not file it as “enhancement / a11y backlog”
Why it works: Exactly. An impossible task is a blocker. Backlogs are how it stays impossible.
- Impossible task = blocker.
- Offer cut or delay.
- Do not bury it in a backlog.
- Do not wait for harm.
A well-meaning engineer committed “realistic” national-id numbers. What do you do?
The strongest answer: Treat it as a leak: purge the git history if policy says so, rotate anything that could be real, and replace with obviously fake numbers that still validate
Why it works: Exactly. History is a copy. Fake-but-valid is the fixture pattern.
- Purge / rotate per policy.
- Use fake-but-valid ids.
- Do not rely on a comment.
- Teach the fixture pattern.
A campaign will send far more traffic than usual at a known hour, and nobody on the team has run a load test before.
What do you do with the two weeks you have?
The strongest answer: Agree the expected load shape and the journeys that matter, run them against a prod-like environment with a tool the team can keep, and report where it starts to degrade and what was not covered
Why it works: Exactly — an agreed profile, a prod-like target, the degradation point and honest gaps are what a launch decision can use.
- Test the shape, not one number.
- Agree the load profile and journeys.
- Use a prod-like environment.
- Report where it degrades, and gaps.
What does an a11y programme look like when QA owns the gate, not the whole company?
The strongest answer: A published bar, a smoke on money paths, a specialist loop for audits, and a ticket type that cannot be “won’t fix / visual” by default
Why it works: Exactly. Bar, smoke, specialist, a ticket type with teeth. PDFs and plugins are souvenirs.
- Publish the bar.
- Smoke the money paths.
- Bring specialists for audits.
- Do not let “visual” eat the tickets.
Who is accountable when a “test” export of prod lands in a contractor’s laptop?
The strongest answer: The quality and engineering leads who allowed prod-shaped dumps as a habit — I install masked pipelines and I do not call it “just QA data”
Why it works: Exactly. Habits are leadership. Masked pipelines are the control. “Just QA” is not an exemption.
- Leaders own the habit.
- Mask at the source.
- No souvenir dumps.
- Do not hide behind “test.”
You find a way to see another user’s orders in staging. What do you do first?
The strongest answer: Stop, limit the blast, tell security / the owner in the planned channel, and I do not keep going “to write a better bug” or post a screenshot in public Slack
Why it works: Exactly. Safety, then the planned channel. Trophy hunting and public posts are incidents.
- Stop and limit blast.
- Use the disclosure path.
- Do not trophy-hunt PII.
- Do not silent-fix a security hole.
A suite logs in as real customers “because staging is empty.” What do you do?
The strongest answer: Stop the suite, treat credentials as a leak, and fund fixtures — I do not call it “read-only so it is fine”
Why it works: Exactly. Real customers are not fixtures. Read-only is still access.
- Stop using real customers.
- Treat the creds as leaked.
- Fund fixtures.
- Do not hide behind read-only.