Evaluat is in private access. Demos open through July. Book a slot

Testing Types

Testing Types from the Evaluat team: articles on real-browser performance testing and Core Web Vitals.

A fast backend is not a fast page. On the page-load timeline, the server response is a tiny sliver of about 50 milliseconds, while the browser then spends seconds downloading, parsing, running JavaScript, and painting before the page is usable at around 8 seconds. API performance testing measures only the server sliver; browser performance testing measures the whole wait. Figures are illustrative, drawn from a 2025 Catchpoint benchmark.

API performance testing vs browser performance testing: which your QA strategy needs

Your API responds in fifty milliseconds. Your page still takes eight seconds to feel ready. API performance testing and browser performance testing measure different layers of that gap, and your QA strategy needs both. Here is what each one catches, what it misses, and how to decide which to run first.

Ahmad Farzan ·

A Core Web Vitals release gate: across pull requests, Largest Contentful Paint stays under a 2.3-second budget until one build regresses to 2.4 seconds and the gate blocks it, even though that is still within Google's 2.5-second good threshold.

Performance regression testing: making Core Web Vitals a CI/CD release gate

A green test suite proves your code is correct. It says nothing about whether the page got slower. Performance regression testing closes that gap: set Core Web Vitals budgets, measure every build against a baseline, and fail the pipeline when a change busts one. This guide wires that gate into CI/CD, from baselining main to the regressions only load reveals.

Ahmad Farzan ·

Three test types, three load shapes: load testing ramps to a steady plateau, stress testing climbs past the breaking point, and performance testing is the umbrella over both.

Load testing vs stress testing vs performance testing: how the three actually differ

Three terms, endless confusion. Performance testing is the umbrella; load testing checks whether you survive the traffic you expect; stress testing pushes past that to find where you break. This guide shows how the three actually differ, when to run each, and which one your team needs first.

Ahmad Farzan ·

A spike test load profile: virtual users jump from a flat baseline to a sudden peak, hold, then drop back, while server capacity rises too slowly to keep up, leaving a gap during the surge.

What is spike testing? Preparing for traffic surges and flash sales

A flash sale does not ramp up. Ten thousand people hit checkout in the same minute, and the autoscaler is still booting servers when the page falls over. Spike testing rehearses that surge on purpose, a sudden jump in traffic then a sudden drop, so you learn whether the site survives the moment before your customers find out for you.

Ahmad Farzan ·

A soak test watches memory over hours of steady load. Healthy memory rises and falls back to a stable baseline; a leak climbs in a rising sawtooth that never comes back down and approaches an out-of-memory ceiling.

Soak testing explained: catching slow degradation and memory leaks over time

Some failures never show up in a ten-minute test. A memory leak, a connection that never closes, a cache that only grows: these surface after hours of steady traffic, not minutes. Soak testing holds a realistic load for hours or days to expose the slow degradation short tests miss, before your users meet it as a 3 a.m. outage.

Ahmad Farzan ·

A stress test: virtual users climb steadily while response time stays flat, then spikes sharply at the breaking point where the system starts to fail.

Stress testing a website: how to find the breaking point before your users do

Every website has a breaking point. The only question is whether you find it in a test or your users find it during a sale. Stress testing pushes the site past its limit on purpose, so you learn where it fails, how it fails, and how fast it recovers, before real traffic does. Here is how to run one.

Ahmad Farzan ·

Smoke testing versus performance testing: a smoke test runs a quick pass-or-fail check that critical paths are not broken, while a performance test ramps many virtual users to measure how the system holds up under load.

Smoke testing vs performance testing: when a quick pre-release check is enough

Smoke testing and performance testing get treated as rivals, but they answer opposite questions. A smoke test asks whether a new build is broken. A performance test asks whether it stays fast and stable under load. This guide shows how the two differ, and when a quick pre-release check is genuinely enough.

Ahmad Farzan ·

Three load-testing models compared: HTTP-script sends requests with no browser, shared-browser puts many virtual users in one browser, and real-browser gives each virtual user its own isolated browser. Only the real-browser model captures what users actually see.

Real-browser load testing, explained

Most load testing tools fire HTTP requests at your server. A few share one browser across many simulated users. Real-browser load testing gives every virtual user its own isolated browser, so it measures what your customers' browsers actually do under load. Here is how the three models differ, what each one can and cannot see, and when each is the right call.

Ahmad Farzan ·

Functional testing versus performance testing: a functional test confirms that for a given input the software returns the correct output, pass or fail, while a performance test ramps many virtual users to measure whether the system holds up under load. Every release should answer both questions.

Functional testing vs performance testing: two questions every release should answer

A build can pass every functional test and still fall over the moment real traffic arrives. Functional testing answers one question: does your software do the right thing? Performance testing answers another: does it stay fast and stable under load? Every release has to answer both. This guide shows how the two differ, and where each one fits.

Ahmad Farzan ·