Testing = Exploration + Checking

When I say that testing is not just checking something is supposed to work, or doesn’t have a bug, what does it mean?

Look at this API:

Without even thinking, we already have assumptions on how it works. We assume there’ll be a new user created at the end. We assume that the API will return a 201 code – CREATED.

If it works.

If it won’t for some reason, we expect some other error code. And that this “so-called-user” data, won’t infiltrate our system.

Either we know it, or feel it, or have a premonition – we can translate the expectation into an assertion in code.

Any automated test ends with at least one of those. We have an expectation, and we want to check that we’re right. If we’re surprised, well, the real production caller will also be surprised, right?

So this is when we expect something. But have you ever went into testing a system, without any idea of how it works?

Exploratory Testing FTW

I’m sure you’ve downloaded an app, and started using it without reading the docs first. At least once in your life. But you used the app anyway. Who reads documentation?

In testing, we call that exploration. We find out ourselves. Sometimes we’ll feel ok, sometimes weird, sometimes surprised. And yes, sometimes angry. We learn how it works.

If we’re exploring, we can’t write an assertion, because there’s no expected result. That means we can’t automate exploration. We can automate part of it, just not the “testing” part, the part where compare are expectations to the results.

That’s the difference between exploration and checking. Both help us test the system, and report on its behavior. Both are needed.

Testing = exploration + checking.

Want more API testing? Sure you do. Check out the workshops. “API Automation Testing” for developers and the “API Testing with Postman” for testers.