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.