Question 1

List the performance testing types and explain the differences.

Accepted Answer

Give each type as one question + one example — it sticks better than a dry list. Load — "do we hold the required speed at expected load?" (e.g. 500 concurrent users). Stress — "where do we break, and HOW?" — a clean error and no data corruption at the breaking point are what matter. Spike — "do we recover quickly after a sudden surge?" (e.g. an ad campaign or the year-end renewal peak). Endurance/soak — "is there a memory leak after hours of running?" Volume — "how long does a search take on a million-record database?" Scalability — "if we add a server, does the system get proportionally stronger?" An insurance example makes it live: the year-end renewal peak is a textbook spike-testing scenario.

Question 2

As a manual QA, what can you do about performance?

Accepted Answer

Split the answer in two — what I do and when I involve a specialist — that structure shows both capability and awareness of limits. What I do: measure single-user response times in DevTools Network and compare with the previous release (that's how performance regressions usually surface); test with large data — an account with 500 policies, not 5; use throttling to check loading states, timeouts and double-submit behaviour on slow networks; spot wasteful repeated calls in the Network tab (e.g. an API call per keystroke — no debounce). I involve specialists for: real concurrent load, verifying p95 targets, endurance testing — these need JMeter/k6, a dedicated environment and server monitoring. Close with: "Getting 'should be fast' turned into a number during refinement is also my job."

Question 3

A page opened in 1 second last release and takes 4 seconds now. What do you do?

Accepted Answer

I log it as a performance regression bug, not as "it feels slow". My steps: (1) confirm repeatability — measure several times with an empty cache, on the same environment with the same test account, and check on another device/network to rule out a local issue. (2) localise it — look in DevTools Network at which request costs the time: is one API call slow, or are 60 separate requests firing (N+1)? Is it frontend rendering or the backend response? (3) gather context — what changed in that area this release, has data volume grown, is something else running on the environment. (4) report it — the before and after numbers, a HAR file, which request is responsible, and the user impact. A bug filed with this structure is almost never returned as "cannot reproduce".

Question 4

The PO says: "We have no budget for load testing, just check it manually." How do you respond?

Accepted Answer

I don't say "fine" — that becomes a promise I can't keep, and when it surfaces in production the responsibility lands on me. But I don't just say "impossible" either. My answer has three parts. First, honesty: "Real load cannot be produced manually — opening 20 tabs is neither repeatable nor measurable. I can do it, but the result will prove nothing." Second, what I can do: single-user measurements, large-data testing, slow-network scenarios, comparison against the previous release — these catch a portion of the problems and cost nothing. Third, make the remaining risk visible: "Behaviour under concurrent load stays untested. The year-end renewal peak is our riskiest window. My proposal: record this risk in the test plan in writing, agree monitoring and alerting with ops, and schedule a load test for next quarter." The risk can be accepted — but it must be accepted knowingly, not by default.

Metric	What it means	What to watch for
Response time	Time from sending a request to receiving the response	The average misleads — p95 / p99 (95th and 99th percentile) give a truer picture
Throughput	Requests processed per unit of time (RPS/TPS)	If throughput stops growing as load rises, the system has hit saturation
Error rate	Percentage of failed requests	A rise in 500s and timeouts under load — the clearest sign of breaking
Concurrent users	Number of simultaneously active users	The number must come from analytics — real peak data, not a guess
Resource usage	CPU, memory, disk, DB connections	Steadily rising memory during an endurance test means a memory leak

Performance testing basics for manual QA

📚 Sources and documentation