Why do we test? There are many reasons for testing. But let’s look at it from a business perspective: Why are people paying us?
Well, as we know from our own experience, the things we build don’t work as well as we expect them to. In many ways For that also, there are many reasons, but we’ll tackle that in the future.
If our app doesn’t work, we’d rather know about it in advance, rather than later, and do something about it.
That means that we’re getting paid to find bugs, right? Well, that’s part of it. What about the things that do work?
Let’s take Google, for example. The main feature of Google is search. And that better keep working, even if the Daily Doodle has a bug in it. Otherwise, they’ll stop getting that sweet ad money which they love.
So testing is not just about finding bugs, we also test to make sure that features are working as they should. Right?
That’s another part of it. Here’s another thing.
How about we find out that everything is working perfectly, as it says in the spec. But it’s working very, very, VERY, slowly?
Couldn’t the developers build it to work fast? They could, but unfortunately, it didn’t say in the spec that creating a record in the system should take less than 3 hours. The definition of “working” (and I’m throwing in there also “still working”), is not limited to what we thought about in the past, but what currently exists and actually runs. We thought we’ll be able to just add records, turns out we need to pack lunch.
So we test to learn. What works, what doesn’t, what not completely. Right?
Not yet.
If all my testing of the system as single user, while the system should be serving millions users. Am I doing it right? What if I’m testing as administrator, while real users will have “read only” permissions?
Just going through the operations is not enough. I need to do all this, within the right context. The users, environment, and conditions that the system will work in. I may learn how the system works, but without the proper context, all that learning will not be as valuable.
What’s the common thread here?
We want to know. What works, what doesn’t, and what surprises us. Just like real users. That would be enough, if we kept all that acquired knowledge to ourselves, but for the money, we need to supply this information, because the stakeholders can do something with it: Release a version, delay it. Decide on fixing a bug, or going out with it. Or at a larger scale, make decisions on future features, processes and experiments.
We are paid to supply information to stakeholders. And we want to supply as much as we can, as accurately as possible, within context. That’s our goal. And we need to plan, design, prioritize, automate, explore – all these testing activities – to reach it.
That’s why we test.
Wanna test better? Check out my API automation testing workshop, and my Web testing workshop.
0 Comments