Do you “check if it works”?

In some software development teams, the Quality Engineers are asked to check if it works. Does it match the acceptance criteria? Does it do what it’s supposed to be doing? This is a common perception. And if you think this is quality assurance, you have got it wrong!

At IKEA they conduct durability testing on their chairs. Right there, in the middle of the store inside a glass box, you would see the pressure is applied to the iconic POÄNG chair 20 times per minute to simulate a 250 lb person sitting in the chair 20 times per minute. Amazing right?

Now, this is “quality assurance”!

If I tried testing this from the initial idea of “check if it works”, I would sit on the chair a couple of times and then declare my test successful.

Would it be enough to assure the quality? Definitely not.

Testing is not equal to quality assurance

How about representing the users who want to jump, rock, stand on the chair? How about the varying sizes of human beings who would want to use the chair for years? Have I represented them in my tests?

I have noticed that in software teams, Quality engineers get caught in the trap of testing what should be working in the first place. The application should be doing what it was supposed to be doing; it must meet the acceptance criteria before Test Analysts start their testing.

“Check if it’s working” should be the exit test criteria for development activities. This allows quality engineers to focus on identifying how to break the system before the users do. They can focus on making the product more resilient. This ultimately leads to quality assurance.

Break it before the Users break it.

Users will come in different shapes and sizes. They will do things to test your application. They would try random workflows because they don’t know your system very well. Then there will be people who come with malicious intent.

Therefore, instead of our typical progression from coding to validation, we need to move into a cycle of building the application, breaking it, fixing it, and breaking again.

We should continue this cycle until the product becomes resilient.

To break it like a User, you must think like a User.

You have to be creative. Look at the system from different perspectives. Feed it invalid or unexpected input. This goes a long way in getting information on what the system will do when a user feeds intentional or unintentional data. Trying to act as different personas and putting the system under stress might lead to unexpected findings.

By continuously doing this, is how we ensure that the product is actually ready for the end-user. This is how we know that the application is resilient enough to face the world.

So next time make sure that “checking if it works” is an entry criterion to testing and not a Test Analyst core task.