When I first started working in this industry and heard the definition of a test case, I got a weird feeling in my stomach and this thought in my head that I will never understand what these people are talking about.
What do you mean 'test case'? They were talking about test case ID, pre-conditions, test data, steps, expected vs actual results and all these words that were like a foreign language to me.
A little background on myself, I followed a linguistic path for my high-school and (partial) college degree. The world of Software Testing was not where I thought I would use my love of words and storytelling. Then I realized, a few months (like 10, almost a year) in, that test cases are just short stories written by someone who is pretending to be a user.
But if you break the definition down, that’s the essence of it. A sequence of steps a user takes and what’s the expected outcome of those steps.
“And what about those pre-conditions, test data, test ID, steps, expected results and other foreign languages you talked about earlier?” you might ask. Well, that’s the setting of your short story.
Just like a collection of short stories has a content table with numbers next to each story, so do test cases have IDs. So when you want to test a specific one, you can identify it by its ID number.
Pre-conditions are a way to describe what your character (or user) has to do before arriving at your specific scenario.
For example, our user wants to upload a picture of her cute dog to the social media platform we are testing. Our test case or short story is about the successful upload of a picture, so the things the user has to do before actually getting to upload that picture are pre-conditions. She takes a picture, she opens our platform, she signs in.
“But what in the world is test data?” you ask me baffled.
Well, our user has a folder on her computer with three files in it. One is cutedog.jpeg, one is cutedogs.txt and one is a listofcutedogs.csv. That’s the test data. That’s the data we’re using to drive our test cases with. And this data can change throughout our stories of the user uploading her file. In one story she could upload a picture, in another, she could upload a .csv, in one more she could select all three files.
But for now let’s focus on just one story, step by step:
1. The user accesses the platform.
2. The user clicks on the Upload button and a file explorer is opened.
3. The user selects the destination folder.
4. The user chooses the “cutedogs.txt” file.
5. The user clicks Save.
Short and simple, right?
Now, we’ve arrived at our “expected vs actual” part of the test case, where every scenario has an outcome. Every reader has a result in mind when reading a certain story.
Of course, in storytelling, the best authors change the expected result of stories so that you, as a reader, are left ever guessing. But this is not the case in test cases. You know what is about to happen because the whole story is already in your mind (or in the design of the product you are testing).
It’s not as thrilling as reading Stephen King, but I for one still get a kick out of it.
So, what is the expected result of our test case above?
You might think that our user has successfully uploaded her picture and she gets a message informing her of this marvellous success. She might even get a big round of applause in the form of little applause emoticons raining down on the page. I’m just throwing ideas around at this point, but you get the picture. Everything went well, right?
Well, not really. Here’s our actual result: the picture didn’t upload because the file was of the wrong format and the feature crashed because it was not prepared for this situation.
If you were paying attention to the test case, we made our user select a different file format. Why? Because clicking on a different file than the one you want is a mistake we all make, way too often.
Ah, aren’t actual results exciting?
These short stories don’t need to have different outcomes than what you expected, but I was using my creative freedom as a storyteller to see what happens when things don’t go as expected. And this is part of our job as Software Testers.
We are storytellers.
We get your designs and specifications and put them in the hands of characters that sometimes do stuff that was not as designed.
And we hope that by doing so, you, the product owner or the developer, get to see how your products will be used and where things might go really wrong. With these outcomes, you can develop the best products for your target users and give them the best experience one has to offer.
Feel free to challenge me on these ideas by dropping me an email here. Always eager to have a good talk about anything QA.