Skip to main content

I want to ask a question that is both simple and complex to answer: How do you write your test cases?

Why do I say it is simple?

Well I mean according to some definitions testers write test cases and since they do it often it should be easy. Also there is a ton of information online on how to write a test case, what should it contain, so again, easy and simple.

Why do I say it is complex?
Well, a PM once told me that the tests should be written in such a way that a person coming from the street should be able to run them. I mean that is not impossible to do but it will take time, a lot of time. One has to find a way to explain concepts that are not really in the day to day dictionary ( API for example).

I think that they want somenthing like this When tests steps are really clear - YouTube 16

What do you think? How do you do it?

In the days of old, before I worked in any agile project (showing my age here, I know :cP), we used to take requirements, understand them & discuss them the best we could, create a technical specification document (file that says this is a draft screen layout you’re going to get + what each option might do), then the stakeholders might not get to play with the app before an alpha/beta/UAT testing phase almost at the end of the development… in those days there were no frequent sprint demos. 

 

When later working in a test manager, tester or UAT co-ordinator role, I tend to build test cases based on the same background… that the users would be “off the street”, never perhaps having seen the application and whether they are 5 years old, or 95 years old, could be able to follow the steps through to completion.

 

One “anti-pattern” approach I tried was to detail these in such a narrow way like “click the blue login button in the top right of the screen”. I stopped doing that from experiencing the GUI changing so often + needing to update the steps, so 1 caveat I could advise on would be there is a fine line adding detail enough for anyone new to be able to follow the step, or going overboard to screw up test case maintenance… “click the login button” is probably a lot better than the former example in my opinion now...


Almost 36 years ago, on May21st 1987, I wrote my first ever test cases as a paid tester. On that day I wrote 12 of them. But for the most part, as a tester, I don’t “write test cases.” It’s more accurate to say that I design and perform tests. Sometimes I do that in a way that results in something you would point at and say “hey, that looks like a test case” and many other times it does not. Mostly not.

My favorite thing is to write tools that generate a lot of data, and then I sample that data to drive highly exploratory investigations of the product. 

For my current client, I’ve been helping to reproduce an elusive data loss bug. This has involved performing thousands of repetitive actions with certain random and non-random variations. Is that one test case? Is it thousands? Well, I call it a test activity.

When I teach testing, I barely talk about test cases. I’m not saying it’s a bad or useless concept, mind you. I’m just saying I don’t get why it’s such a popular idea among testers… unless irs just because they don’t know what else to talk about.


Reply