How to write good TestCase?

Ministry of Testing

Case Study:

Some good docs that break apart the basic stuff, like how to write a good test case and how to organize and use them effectively?

-- Anonymous

Recommendation 1:

What are you trying to do? Is your company wedded to test cases? My experience is that test cases on their own tell you things you already know. That is 25% (at a maximum) of what could happen with your product. Who or what is investigating the other 75%? (Known Unknowns, Unknown knowns, Unknown Unknowns). Sure you could write test cases for things you expect. What about the things you don’t expect, once the product is built? No amount of test cases will tell you that. Personally I prefer high level acceptance criteria rather than all the detail of how to test it (which is great for a computer but boring as hell for anyone to execute) and then I supplement this with exploratory testing.

Are your developers using BDD (note I said “developers”, BDD is not a tester framework, it is BDD not BDT). In that case sure, assist them by helping define the requirements, not the testing, via Gherkin. That is a valuable action and part of 3 Amigos. So, if you’re talking about the Gherkin for BDD to help the developers deliver what was requested it’s... Given When Then. The Given should not contain many Ands, preferably none. For example, “Given I am on the checkout page with a populated basket” is cleaner than “given I am on the homepage and I log in with valid credentials and I place a product in the basket and...” endlessly. When is a simple action; “when I click X” (though you want to be generic like “when I click the submit button” not “when I click the Read More link” since the text may change or not always be in English). “Then” should be short too. “Then I am taken to the confirmation screen” or “then I am presented Y information”. You can have additional assertion criteria such as “and my card is charged for the transaction And the database records the transaction”. This can be asserted. If you have more “and when”s that gets messy. Try to make those a new test case. Never ever use OR. That should be a separate test case.

Now back to why test cases may not be the answer... test cases are great for computers but not if something unexpected happens, which is what you really should be looking at. Not expected stuff but the unexpected stuff. If you only do test cases you will miss loads. Please don’t wed yourself to test cases.

-- Mike Ruttenberg

Recommendation 2:

Normally my preferred way is to write for a feature/function one detailed "Master" test case (which I flag with "(M)" add the beginning, so I can also filter them easily, e.g. for a smoketest), there I write step by step the easy happy path in it, next to it I write then all special TC but then I only write the special thing to it, so I don't copy all the basic stuff all the time.

--Andreas