I sort of like the wording you used here, in that the best use of test cases is for onboarding. I don’t think that onboarding is best done with test cases, but I can imagine a scenario where you’d use them for that. I wrote an article about in-context onboarding so I might as well plug it: New Tester, New Product: How To Get New Testers | Ministry of Testing
Documenting things about testing and documenting testing I think are worth considering separately. I think that writing down notes can be distracting and time consuming, although I have a poor memory and sometimes I like to go to the bathroom so I do use personal notes. I think that storing information for future reference is very important, so I use things like risk catalogues or make process flow diagrams for future use.
When I was onboarded with ‘test cases’ in my first job it was awful - the worst I’ve ever had.
A lot of time I spent on understanding the idea, the meaning, the steps, the thought process, doing exactly as the steps through the product, not knowing why and how I should not look at anything else, not learning almost anything about the product but only about the tester and his case, questioning the tester on what was written, questioning why the dozens of other things around it were not considered, correcting the case language grammar precision of description of meaning, re-reading the case, asking for help from testers where they were saying that’s not used or old or irrelevant anymore or misses details.
I felt like a fool and I wasn’t sure what testing was anymore(as I had my own idea that a tester is a detective, an investigative journalist).
It took me two months of struggling as a human, as an inquisitor, as a curious person, as a fast learner to get out of the cage of test-cases, not having learned anything and wanting to do things in a different way.
I’m going to throw something in here and see what you and @kinofrost maybe think. Everything is context dependant.
Say you’re working on systems/processes which are more data processing operations, would you say that “test cases” or procedures are more important?
For example on one side of the spectrum you’d have - use the ecommerce platform and create an order (absolutely no need for specific steps from the UI perspective It should be intuitive) ).
Now let’s say we have an invoicing process. It takes all orders of a certain status and age and creates and generates invoices. If this doesn’t work exactly right then the company is potentially losing money/cash flow. The latter needs a lot more detail and specifics because if any aspect of that is wrong then we’re in trouble.
Yes. The value of anything we do is defined by the context in which we do it.
Say you’re working on systems/processes which are more data processing operations, would you say that “test cases” or procedures are more important?
Depends a little on what you mean by those terms. If you could help me understand what the difference is I can answer this more directly.
Your invoice example has a lot of sides to it. These are the things you seem to bring up about it:
Complexity: The status and age are perhaps a convoluted part of the process
Oracle problems: lack of previous experience or other knowledge about it. It’s not obvious like creating an order. Not “intuitive”.
Strategic functionality: Importance to the business. It deals with money.
Precision: The need for it to meet strict requirements
Downstream dependency: Relies on the correctness of other things, like orders and probably a search algorithm.
I could add more based on what I think of the example, but this seems to be what you’re thinking of when you provide it. These things are all risk factors. They influence how we go about finding and testing risks.
So you’re talking about testing the functional capability of high risk functions that deal with stored data.
So firstly am I right so far and secondly what’s the nature of your question about that?
I’m a bit late to the party but my intial thought on reading the question, which is largely backed up in the numerous and very interesting replies, is that it is very important for testers to be able to think of ‘test cases’ - ie understand and break down requirements logically, have an experimental mindset and take into account models of behaviour, in order to figure out how they are going to test something - but the process of writing down the detailed steps of each test case is usually a waste of time.
It’s similar to my approach to learning maths - it’s more important to understand how/why something works than to memorise formula or methods. That way you can reconstruct the formula if you need to, and also be more flexible and creative.
That is an excellent point put wonderfully. You made it look both simple and elegantly complete with a better and more approachable way to think about it.