Q: The product owner says: "the page is slow, write a test." What do you do?

"Slow" isn't measurable, so my first job is to sharpen the requirement — and the best answer to this question is, in fact, asking questions. What I'd ask: (1) Slow for whom? Which users are complaining — mobile, a particular region, a specific page? (2) When is it slow? Always, or at peak hours (that's a load problem, not a frontend one)? (3) How slow is acceptable? What's the target number? (4) What changed? If it started after the last release, it's a regression and we have a comparison point. Then I classify the problem, because the fix depends entirely on it: a frontend problem (large bundle, unoptimised images, render-blocking scripts) → Lighthouse CI, budgets, RUM data; a backend problem (a slow query, N+1, a missing index) → APM, measuring API response times directly; a load problem (only at peak) → a k6 load test. I close with an honest framing: "writing a test" doesn't solve the problem — measurement and diagnosis do. I can set up the measurement and add a budget so the regression can't return; the optimisation itself is teamwork. This answer structure — question → classify → matching tool — works here and in similar questions.

Q: What performance signals can you extract from functional automated tests?

The functional suite isn't a measuring instrument, but it is very valuable as an early warning system — and it matters to keep that distinction while answering. The signals I extract: (1) The suite duration trend — if the tests haven't changed but the suite went from 12 to 18 minutes, either the infrastructure or the product got slower; both deserve investigation. I track that trend on a dashboard. (2) Per-test duration — the Playwright report sorts tests by duration; one test suddenly doubling usually means a specific page or request slowed down. (3) Assertions hitting timeouts — a check that used to pass in 2 seconds now scraping a 5-second timeout looks like flakiness but may actually be a performance regression. This is the most commonly misclassified case. (4) Network timings in the trace — you see exactly which request stretched, which is a fact you can hand straight to the backend team. I always state the limitation: these numbers depend on the CI environment, parallelism and the network, so they cannot be used as absolute values — only as trends and ratios. Official measurement needs Lighthouse or a load tool on a controlled machine. This answer works well because it shows extracting extra value from an existing tool — while not overclaiming.

Q: If you had to choose between k6 and JMeter, what would you base it on?

For tool-choice questions the right reflex is to start from context — "k6 is better" is a weak answer. What I'd ask: what skills does the team already have? Will the tests run in CI or by hand? Where will results be stored? Are there existing load tests? Then my comparison: k6 — scripts are JS, so the learning cost for our team is close to zero; scripts live in git like normal code and get reviewed; being CLI-first it plugs into CI naturally; result thresholds (thresholds) are part of the config, turning the SLA into a machine-checked rule. JMeter — the GUI makes it approachable for non-programmers; the plugin ecosystem is very broad (exotic protocols: JDBC, JMS, LDAP); enterprises often already have the infrastructure and expertise; but its XML configs are awkward to review in git. My default would be k6 — on a JS/TS stack the scripts are in the same language, stored as code and easy to run in CI. But where JMeter is already established and the team knows it, I wouldn't propose migrating just because something is "more modern" — replacing working infrastructure has its own cost. That last sentence makes the answer pragmatic, and pragmatism is exactly what's being scored.

Question 1

Do you have performance testing experience? What is QA's role here?

Accepted Answer

This calls for an honest, structured answer — overstating experience here is dangerous, because one follow-up question exposes it. My framing: "I'm not a performance engineer, but I understand the field and as a QA I do four concrete things." (1) I make the requirement measurable — I don't accept "make it fast"; I turn it into "search results at p95 < 1.5s with 500 concurrent users". This is often the most valuable contribution, because an unmeasured requirement is never verified. (2) I wire the frontend side into the pipeline — Lighthouse CI with budgets for LCP/CLS/INP; exceed the threshold and the PR is blocked. That catches performance regressions like functional bugs. (3) I read signals from the functional suite — a sudden increase in suite duration is often an early sign the product got slower, and I investigate it. (4) I participate in load testing — I can write a simple k6 scenario (convenient, since it's JS), but for serious load modelling, infrastructure profiling and deep result analysis I work with a performance specialist. Stating the boundary openly isn't weakness — knowing the limits of your own competence is a strong signal.

Question 2

The product owner says: "the page is slow, write a test." What do you do?

Accepted Answer

"Slow" isn't measurable, so my first job is to sharpen the requirement — and the best answer to this question is, in fact, asking questions. What I'd ask: (1) Slow for whom? Which users are complaining — mobile, a particular region, a specific page? (2) When is it slow? Always, or at peak hours (that's a load problem, not a frontend one)? (3) How slow is acceptable? What's the target number? (4) What changed? If it started after the last release, it's a regression and we have a comparison point. Then I classify the problem, because the fix depends entirely on it: a frontend problem (large bundle, unoptimised images, render-blocking scripts) → Lighthouse CI, budgets, RUM data; a backend problem (a slow query, N+1, a missing index) → APM, measuring API response times directly; a load problem (only at peak) → a k6 load test. I close with an honest framing: "writing a test" doesn't solve the problem — measurement and diagnosis do. I can set up the measurement and add a budget so the regression can't return; the optimisation itself is teamwork. This answer structure — question → classify → matching tool — works here and in similar questions.

Question 3

What performance signals can you extract from functional automated tests?

Accepted Answer

The functional suite isn't a measuring instrument, but it is very valuable as an early warning system — and it matters to keep that distinction while answering. The signals I extract: (1) The suite duration trend — if the tests haven't changed but the suite went from 12 to 18 minutes, either the infrastructure or the product got slower; both deserve investigation. I track that trend on a dashboard. (2) Per-test duration — the Playwright report sorts tests by duration; one test suddenly doubling usually means a specific page or request slowed down. (3) Assertions hitting timeouts — a check that used to pass in 2 seconds now scraping a 5-second timeout looks like flakiness but may actually be a performance regression. This is the most commonly misclassified case. (4) Network timings in the trace — you see exactly which request stretched, which is a fact you can hand straight to the backend team. I always state the limitation: these numbers depend on the CI environment, parallelism and the network, so they cannot be used as absolute values — only as trends and ratios. Official measurement needs Lighthouse or a load tool on a controlled machine. This answer works well because it shows extracting extra value from an existing tool — while not overclaiming.

Question 4

If you had to choose between k6 and JMeter, what would you base it on?

Accepted Answer

For tool-choice questions the right reflex is to start from context — "k6 is better" is a weak answer. What I'd ask: what skills does the team already have? Will the tests run in CI or by hand? Where will results be stored? Are there existing load tests? Then my comparison: k6 — scripts are JS, so the learning cost for our team is close to zero; scripts live in git like normal code and get reviewed; being CLI-first it plugs into CI naturally; result thresholds (thresholds) are part of the config, turning the SLA into a machine-checked rule. JMeter — the GUI makes it approachable for non-programmers; the plugin ecosystem is very broad (exotic protocols: JDBC, JMS, LDAP); enterprises often already have the infrastructure and expertise; but its XML configs are awkward to review in git. My default would be k6 — on a JS/TS stack the scripts are in the same language, stored as code and easy to run in CI. But where JMeter is already established and the team knows it, I wouldn't propose migrating just because something is "more modern" — replacing working infrastructure has its own cost. That last sentence makes the answer pragmatic, and pragmatism is exactly what's being scored.

Question	Can a UI test answer it?	The right tool
How fast does the page load for a single user?	Partially — as an indicative measure	Lighthouse CI (more precise and comparable)
Does the system hold at 500 concurrent users?	No	k6 / JMeter — protocol-level load
Did LCP regress after the last release?	Partially	Lighthouse CI + a performance budget
Is there a memory leak under 24 hours of load?	No	A soak test + server monitoring (APM)
Does the UI freeze after a button press?	Yes — a functional test catches this	Playwright (the assertion timeout signals it)

Performance testing basics

📚 Sources and documentation