If test levels answer the question "at what scale are we checking", then types of testing answer the question "what exactly are we checking". And here there is a big split into two groups: functional — "does the program do what it should", and non-functional — "how well does it do it".

A beginner usually lives in the first group and forgets about the second. That is a mistake: "it works, but it takes 30 seconds to open" is also a problem that will drive users away.

Functional testing: does it do what it should

This is the testing of features — the specific actions the product must be able to perform. Each check comes down to "I clicked — I got the expected result".

Examples for an online shop:

  • Can you register with correct details?
  • Does an error appear for an email address that is already taken?
  • Is the cart total calculated correctly?
  • Does a confirmation email arrive after placing an order?

Functional testing is the foundation of a manual tester's work and the starting point for everyone. This is what test cases are written for: "given these steps, the result should be such-and-such". Most of the rest of the training program revolves around it.

Non-functional testing: how well

Here a feature may work correctly and there may still be a problem — in speed, convenience, or reliability. The main areas:

  • Performance (speed). Do pages load fast enough; can the system handle a surge of shoppers on Black Friday? Checking under load is called load testing — and it is usually automated, because you cannot simulate a thousand users by hand.
  • Usability. Is it understandable to use; will the user get confused; are error messages visible? This is something a real person picks up well and an automated test misses entirely.
  • Security. Can someone view another user's order, guess a password, or access something they shouldn't?
  • Compatibility. Does it work the same way in different browsers and on different phones — there is a separate article on cross-browser testing.
  • Reliability and recovery. What happens if the internet drops in the middle of payment; will data be lost?

A beginner usually does not go deep into non-functional testing, but keeping it in mind is essential: often "slow" or "confusing" frustrates a user more than an occasional bug.

Positive and negative testing

Another important division that runs through all functional testing.

  • Positive testing: we check that when correct actions are taken, everything works. Enter the right username and password — you are logged in.
  • Negative testing: we check that when incorrect actions are taken, the program handles it gracefully — it does not crash; it gives a clear error message. Enter a one-character password, leave a field empty, type text where a number is expected, upload a 2-gigabyte file.

Remember the key rule for beginners: most bugs live in negative scenarios. The "happy path", where everything is entered correctly, the developer usually checks themselves. But what happens when a user makes a mistake — that is often not thought through. That is exactly where you will find the most problems.

Where this applies

In practice you rarely say "I am now running non-functional testing". You simply keep a few questions in mind while checking a feature: does it work (functional), does it handle errors gracefully (negative), is it fast, is it usable, is it secure. The more of these angles you hold, the less you will miss.

Where beginners stumble:

  • Only testing the positive path. "Entered everything correctly — it works" — and calling it done. Bugs are waiting in the negative scenarios.
  • Forgetting about usability and speed. A feature technically works but is impossible to use — that is worth filing as a problem too.
  • Trying to do load and security testing by hand without understanding the field. These are separate specializations; at the start it is enough to know how to talk about them and spot the obvious.

What to learn next. Get familiar with black box, white box, and grey box and with run terms (smoke, regression, sanity), then move to practice — how to write test cases.