All jobs / Automation developer

Performance Testing interview questions

Performance Testing questions a Automation developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.

1. What is the difference between a load test and a stress test?

   The strongest answer: A load test runs the traffic you expect and asks whether the system still meets its targets; a stress test pushes past that until something gives, to find the breaking point and see how it fails and recovers

   Why it works: Exactly — two different questions: does it hold at target, and where and how does it break.

   • Load: does it hold at target.
   • Stress: where does it break.
   • Watch how it fails and recovers.
   • Different questions, different runs.

2. A load run finishes, the tool prints an average response time of 180 ms, and the team declares it a pass.

   What do you report instead?

   The strongest answer: Percentiles against the agreed target — p95 and p99 — with throughput and the error rate beside them, because an average hides the slow tail users feel, and a fast average with failed requests is not a pass

   Why it works: Right — tail latency, throughput and errors together, each against a number agreed in advance.

   • Report percentiles, not averages.
   • p95 and p99 against a target.
   • Throughput and error rate beside them.
   • Agree the target before the run.

3. A load script fires the next request the instant the previous one returns, with no pause anywhere in the journey.

   What does that change about the result?

   The strongest answer: With no think time each virtual user sends far more requests than a person would, so the run hammers the system at a rate that does not match the traffic you claimed to model; add pauses, and report the arrival rate you actually tested

   Why it works: Right — the honest statement is requests per second, not “we tested 500 users”.

   • No think time is not real traffic.
   • Add pauses between steps.
   • Report arrival rate, not user count.
   • Do not tune a test to its answer.

4. Your k6 script runs nightly and produces a dashboard nobody has opened in a month.

   How do you turn it into something that can fail?

   The strongest answer: Put thresholds in the script — a ceiling on the p95 duration and on the failed-request rate — so k6 exits non-zero when they are breached and the pipeline goes red like any other test

   Why it works: Exactly — a performance run with no pass condition is a picture; thresholds make it a check.

   • A run with no pass condition is a picture.
   • Threshold the tail and the error rate.
   • A non-zero exit turns the build red.
   • Take the target from the requirement.

5. A recorded JMeter script replays fine for one user and fails for everyone else with authorisation errors.

   What is wrong, and what do you do about it?

   The strongest answer: The recording baked in one session’s dynamic values — token, session id, CSRF field. Extract them from the earlier response with a post-processor into variables and reference those, so every thread carries its own

   Why it works: Right — correlation is what turns a recording into a script, and it is where most JMeter work goes.

   • A recording is not a script.
   • Extract dynamic values per thread.
   • Post-processors into variables.
   • Each virtual user gets its own session.

6. The only environment you can load-test is a quarter of production: fewer app instances, a smaller database, no CDN in front of it.

   What can you honestly say at go/no-go?

   The strongest answer: That the relative findings hold — which endpoint is slowest, which query degrades first, whether we regressed against the last run — and that no absolute capacity number comes out of it. Then name the missing CDN as an untested risk

   Why it works: Right — comparisons survive scaling down, absolute capacity does not, and the gaps get named out loud.

   • Relative findings survive a small env.
   • Absolute capacity does not.
   • Name every missing component.
   • Say what you did not test.

7. Where does performance testing belong in a pipeline that ships several times a day?

   The strongest answer: A short thresholded run on the critical endpoints in the pipeline, so a regression is caught in the change that caused it, and a full load run on a slower cadence against a stable environment — the short one blocks, the long one is owned and reviewed

   Why it works: Right — catch the regression while the diff is small, and keep the expensive run honest and owned.

   • Small thresholded run per change.
   • Full load run on a cadence.
   • Only one of them blocks.
   • Monitoring is not a substitute.