← back to the section

A bug report saying "the catalogue opens very slowly" came back marked "cannot reproduce": the developer opened the catalogue on his machine, got the page in half a second and closed the ticket. Both sides were honest — the report had no number and no condition in it: how long the wait was, on which environment, how many items were in the catalogue and how many people were using the system in the same minute.

Checks that answer "how well" rather than "does it work at all" are called non-functional: the answer is always a number plus the conditions under which it was measured. Five of them come up every week — speed, security, usability, accessibility and compatibility. You don't have to run them all yourself, some need tooling; noticing the symptoms and describing them precisely is your job.

the same action: open the catalogue requirement threshold: 2 s 0.4 s1 person 0.7 s100 people 1.8 s500 people 5 sthreshold broken1000 people no answer2000 people 7 % of requests ended in an error — the average hides it

The action is the same one every time; the only thing that changed is how many people do it at once. First the response time grows unnoticed, then it hits the threshold, and past it part of the requests stops arriving at all.

"Slow" is not a verdict, it is a number

"Slow" means something different to everyone: on a developer's laptop with a warm cache and a database of twenty rows the catalogue opens instantly, for a shopper during the evening peak with a thousand people and two million items it takes twelve seconds. To turn "slow" into a finding you need three things: how long the wait was, how many people were using it at the same time, and which environment with which volume of data. Time is not measured by feel but in the browser's Network panel (more about it here); the same panel shows where the time was lost: if the server answered in 200 milliseconds and the page finished drawing six seconds later, the ticket does not belong to a server developer.

Next you need landmarks: a response under 0.1 second feels instant, under 1 second keeps the train of thought unbroken, and after about 10 seconds attention leaves. Those are rough frames: the real threshold belongs in the requirements, and if it isn't there, that is a finding about the requirements. And the last thing — the average: "on average the page opens in a second" can mean ninety-five people out of a hundred got it in 0.3 seconds while five waited nine seconds each. So requirements use a percentile: sort a hundred measurements from fast to slow and take the ninety-fifth — that is p95. The full requirement reads: "response time no more than 2 seconds for 95 % of requests at 500 concurrent users".

Load, stress, volume: one action at different numbers

"A load test" sounds like a procedure for the chosen few; in reality it is the same action you walk through by hand, only performed by hundreds of copies at once, by a program. The difference between the kinds is which number was plugged in.

  • Load testing — "do we hold what we promised": take the expected number from the requirements or from last peak day's statistics. The answer sounds like "at 500 concurrent orders p95 is 1.6 seconds, errors 0.02 %".
  • Stress testing — "how exactly do we break": the load is pushed above the projected level. Good is graceful degradation — slower, extra callers turned away, no orders lost. Bad is a collapse: accepted orders disappear, and after the load drops the system does not come back on its own.
  • Volume testing — changes the data, not the people: one user is enough, with a table of ten million rows or a basket of three hundred items. The symptom: it flies on a test environment and takes a minute at a customer with three years of history.
  • Endurance and scalability are recognised by their symptoms: the first holds the ordinary load for eight to twelve hours and catches memory leaks and growing queues ("by the evening it crawls, after a restart it is fine"), the second asks whether twice the servers will serve twice the people — often not, because everything funnels into a single database.

A manual tester rarely launches such runs; the job is to spot the symptom, attach a number and the conditions to it, and recognise the right kind in the wording of a requirement: "must sustain 500 concurrent orders" is a load check, "and what happens at 5000" is stress, "and with five years of history" is volume.

Security: what you can see without special tools

The deep part of security is a separate profession with its own tooling, but a noticeable share of real holes is not a clever attack — it is a forgotten permission check, visible in half an hour with nothing but a browser.

  • Someone else's data via a direct link. Open your own order at /orders/10234 as a different user: the expected answer is "no access". If someone else's order opens with their phone number and delivery address, that is a serious finding. Repeat it with a request to the service: the interface may not show the link, but the request still works.
  • A hidden button is not a ban. The "viewer" role has no Delete button, but the delete request is still there: copy it from the Network panel ("Copy as cURL") and repeat it under an account without permissions.
  • How long a session lives. After "Log out" the Back button must not show personal data; a session expires on a timer; changing the password in one browser throws the other one out — otherwise it does not protect a stolen account.
  • The address bar. A password, an access token or a card number inside a link is a finding by itself: links settle in browser history, in server logs and in forwarded messages.
  • What the product says in its errors. "Wrong password for user ivanov" confirms to a stranger that the user exists: one wording is needed for both cases. The same goes for the database name and file paths on an error page.
  • File uploads. An executable renamed to .jpg, and a hundred-megabyte image: the product should politely refuse rather than accept and fall over.

All of this is done on a test environment with your own accounts — not in the live product and not on real people's data.

Usability: "it works" and "it can be used" are different checks

A screen can be technically flawless and unbearable in substance: buttons click, forms submit, the layout holds, and getting to the end is still impossible. GUI testing answers "does it work", usability testing "will a person manage". Full-scale research means watching five people from outside the team work a task with no hints, but part of it is visible every day: how many steps reach the goal and how many are surplus; a twelve-field form that clears itself completely because of a wrong postcode; "Error 0x80070005", which tells a person nothing, against "Could not save: the file is larger than 10 MB". Such findings are written without the word "inconvenient", with steps and a consequence: not "the form is inconvenient" but "at step 4 of 6, after a postcode error the form clears completely — the person re-enters twelve fields" (how to shape it).

Accessibility: keyboard, contrast and labels

Accessibility is heard as "for blind people, and we don't have those users", yet almost everyone joins that group in turn: the person with a broken arm working a week on the keyboard alone, or a phone in bright sunlight where pale grey text disappears. In many countries it is also law: the world leans on the WCAG guidelines, and national standards exist alongside them. Four checks take fifteen minutes and need no tooling.

  • Put the mouse away and walk the scenario with Tab: can every element be reached, and is it visible where the focus currently is — if the outline was "removed because it looked ugly", a person without a mouse goes blind.
  • Measure the contrast of text against its background: the WCAG thresholds are 4.5:1 for regular text and 3:1 for large. Not by eye: the browser's developer tools show the ready-made ratio in the colour picker.
  • Check the labels. A label that lives only as a hint inside the field disappears the moment a person starts typing, and for a screen reader it never existed. The same section holds "meaning is never carried by colour alone": a red outline with no error text says nothing to someone who does not distinguish red.
  • Listen to the product. VoiceOver on macOS turns on with Cmd+F5, Windows users install the free NVDA, Android has TalkBack: if instead of "Name, edit field" the reader says "edit field, edit field, button", the product has no labels.

The trap here is not technical: accessibility gets remembered at release time, when the rework costs as much as half the screen. It becomes cheap only when these four points sit in the ordinary screen checklist from day one.

Compatibility: browsers, screens, versions — and installation

"It works for us" almost always means "it works in one browser on one laptop at one window size". You check by engine rather than by logo — Chrome and Edge are built on Chromium, Safari on WebKit, Firefox on Gecko, and on an iPhone every browser is Safari underneath — and by the edges: a window from 320 points, a phone turned sideways, the system zoom of 125 % or 150 %, a slow network, automatic page translation that changes the length of every label. How to pick that set from your own users' statistics and what to walk on it is in the article about cross-browser and mobile testing.

Next to it lives installation testing — install, update and removal: does the product install on a clean system, does it upgrade from an old version without losing data, what is left behind after removal. Upgrading across a version, from 1.0 straight to 3.0, is checked separately: that is where the basket or the saved settings disappear, because the data was migrated step by step and a step was skipped.

Alpha, beta and gamma: handing the product to strangers

After a month on one product the team stops seeing it: everyone walks the same route and no longer notices that the "Pay" button is visible only after scrolling. The cure is people from outside, and the stages are named by how much of an outsider those people are. Alpha happens inside the company: neighbouring departments and friendly users, the product still raw. Beta happens outside: real users take the almost-finished product and report problems. Gamma is the final polish from the last pieces of feedback. The value is in the strangers' hands: other devices, other connections, scenarios nobody inside would have invented. The tester's job here is not running the beta but working through the stream of messages: turning "everything broke for me" into reproducible findings and separating one-off cases from mass ones.

In short

  • A non-functional check answers with a number under recorded conditions: without a number, an environment and a data volume, a speed finding does not reproduce.
  • Time is read in the Network panel, which also shows whether the server was thinking or the browser drawing. The landmarks are 0.1 second as instant, 1 second as unbroken, 10 seconds as lost attention.
  • Requirements use a percentile, not a mean: p95 is the time the slowest one request in twenty fitted into.
  • Load testing asks "do we hold the expected", stress "how do we break and do we come back", volume changes the amount of data.
  • Six security checks need no special tools: someone else's data via a direct link, replaying a request under a role with no permissions, session life after logout and after a password change, secrets in the address bar, over-talkative errors, uploading the wrong kind of file — and all of it on a test environment only.
  • Usability findings are written with steps and a consequence, never with "inconvenient"; accessibility is checked in fifteen minutes (keyboard with a visible focus, 4.5:1 contrast, real labels, a screen reader); compatibility is counted by browser engines, and installation by upgrading across a version.