In the article about testing types we split checks into functional ("does it do what it should") and non-functional ("how well does it do it"). There are many non-functional types, and you'll hear their names on a project constantly: "run a usability smoke," "we need a load test," "check compatibility." This article is a map, so you understand what exactly is being asked and what stands behind each name.

The good news: a manual tester doesn't need to be able to conduct all these types — some require tooling and a separate specialization. But understanding what each type verifies is mandatory for any team member.

Usability ≠ a working interface

The most common confusion is between usability testing and GUI testing. They are different things:

  • GUI testing answers "does it work": the button clicks, the form submits, the layout isn't broken.
  • Usability testing answers "is it comfortable": does the user understand what to do, can they find what they need without hints, does the product annoy them.

A correctly working interface can be monstrously inconvenient — and vice versa: a beautiful, clear screen may not work. Full-scale usability testing means observing real users, but a tester contributes daily: noticing and filing as bugs the places where "it works, but it's impossible to use."

Next to it stands accessibility testing — the product's fitness for people with disabilities: screen reader support, sufficient contrast, keyboard-only navigation. In many countries this is a legal requirement, not a nice-to-have.

Security, compatibility, installation

Security testing checks the product's ability to resist attempts to access data or functions without the right to them. Deep security work is a separate profession, but basic checks are available to everyone: that someone else's order doesn't open by substituting an id in the address bar, that the "back" button after logout doesn't reveal personal data, that the password isn't visible in the URL.

Compatibility testing — the ability to work in different environments. You've already met its main subtypes: cross-browser and mobile (different browsers, devices, screen sizes) and configuration testing (different operating systems, versions, settings).

Installation testing verifies installing, updating, and removing the product: does it install on a clean system, does it upgrade from an old version without losing data, what's left behind after removal. For web products this sounds exotic, but for mobile and desktop applications it's the mandatory program (an app update that loses the user's data is a classic of unpleasant releases).

Performance and its subtypes

Performance testing studies how the product behaves under load. Within it, teams distinguish:

  • Load testing — does the product hold the expected load: "1000 concurrent users — response time no more than 2 seconds."
  • Stress testing — what happens beyond the projected load: does the product degrade gracefully (slower but alive) or collapse entirely? Does it recover from a spike on its own?
  • Volume testing — how the product handles large volumes of data: a table with ten million rows, a five-year report.
  • Scalability testing — does performance grow when resources are added: with twice the servers, can we handle twice the users?

These checks are run with tools and usually by dedicated specialists. The manual tester's role is to notice the symptoms ("search started answering in ten seconds after the catalog import") and to understand requirement wording: "the system must sustain 500 concurrent orders" is about load; "and what happens at 5000" is about stress.

Alpha, beta, gamma: bringing in real users

A separate axis is who does the testing. When the product is ready enough to show, people outside the team join the checks:

  • Alpha testing — inside the company: employees, "friendly" users. The product is still raw; feedback goes straight to the team.
  • Beta testing — outside: real users voluntarily try the almost-finished product and report problems. The "beta versions" of apps you know are exactly this.
  • Gamma testing — the final polish before release: the product is nearly done, and the last small issues are fixed based on feedback.

The value of these stages is that real users don't behave like the team: they have different devices, habits, and scenarios — and they find what would never have been found internally.

Where this applies

You need this map in two situations. First — understanding tasks: "check compatibility" or "look at the registration usability" should trigger a concrete plan of action, not a blank stare. Second — writing competent bug reports: "it's slow" is a poor report; "search over a 2M-item catalog answers in 12 seconds against a 2-second target" is a good one, and it clearly belongs to performance.

Where beginners stumble:

  • They mix up "works" and "usable" — missing usability problems because "functionally everything is correct."
  • They're intimidated by the names. Behind "configuration testing" hides a plain idea: check under different environment settings. Terms are labels on simple ideas.
  • They try to test performance by hand — refreshing the page twenty times in a row. There are tools and specialists for that; your job is to notice symptoms and describe them precisely.

What to learn next. The functional side of the picture is in the article about testing types; checking across browsers and devices — in the cross-browser article; how it all fits into a plan — in the test plan article.