- Version
- Download 11871
- File Size 233.42 KB
- File Count 1
- Create Date April 27, 2014
- Last Updated July 7, 2021
Test Cases Are Not Testing
This is an article by me and Aaron Hodder for the debut issue of Testing Trapeze.
In this article, we explain why creating and performing test cases is not the same thing as doing testing. In fact, test cases are a poor basis for organizing a test process and no basis at all for measuring testing progress. Our industry's obsession with test cases must come to an end or testing as a field will be never be worthy of respect.
Attached Files
| File | Action |
|---|---|
| test-cases-are-not-testing.pdf | Download |
That was a very interesting read! I’m brand new to Software Testing and found your article while looking through r/SoftwareTesting on Reddit. I’m currently reading the textbook, A Friendly Guide to Software Testing, and just made it to the section on writing Test Cases and I’ve been considering the inherent problem of having two or more people read a test case in a different way.
Do you feel the way to combat that would be to have a clearer understanding of what the product is supposed to do and behave like? The chances of a test case being misread are lowered then, or is this misreading unavoidable?
I really enjoyed reading your thoughts on Test Cases and look forward to reading more articles on this site. Thank you for sharing.
[James’ Reply: The most important question is do you know how to test? After that, do you understand and accept the test strategy? After that, we can consider whether you understand a test case. But I don’t think misreading, as such, is much of an issue, unless you see a test case as a blind order sent to a blind tester. My advice is: don’t work that way. Testers should not routinely test from a position of ignorance and should not be dictated to by mysterious procedures written by shadowy people.]
Hi, this is an interesting read. You mentioned testing is an activity of knowing the performance of the product. By not writing test cases. Then how would you validate it? Are you indicating to go for more exploratory testing rather than taking a structured approach? I did not really get what solution you are providing and how to achieve that.
[James’ Reply: The answer to that question is in the article you are commenting upon. But to reiterate: validation is not a helpful word. What we do is test a product. We are looking for bugs in it. Testing is learning via experimentation. Of course this process is exploratory. If you aren’t exploring then you also aren’t testing. This is a structured process, by any reasonable definition of structured, so I don’t understand your point, there.]
All the arguments in this paper apply to test automation? Doesn’t it also apply to the best developers who don’t understand testing? (rhetorical question – answer is not needed).
Hi. I completely agree with the content of this article. However, on the software projects that I’ve worked on test cases were used to provide some metric of requirement coverage and (perhaps more importantly) to document the tester’s thoughts about a requirement (or the system) during testing (our test case documents mostly contained thoughts and ideas, the test cases were a minor part of the documents). I think of testing as everything that leads up to the writing of a ‘final’ set of the test cases.
[James’ Reply: You can use anything as a metric. For instance, you can save all the contents of the system logs that Windows keeps and track the rate at which they grow. You can keep track of every change to every file on the test system. You can count the number of HTTP requests you make to the back end. You CAN do these things, but I bet you don’t– because they are nearly useless as indicators of testing effort or value (although not completely useless). Similarly using test cases as a metric is also, at best, nearly useless, and at worst utterly misleading. That’s why I don’t use them as metrics and why no one else should, either.
Instead of discussing what desperate and clueless people might do, let’s discuss what is helpful and reasonable. Instead of using test cases as a unit of testing, use attention over time (i.e. chartered and timed test sessions). By mapping what you have been testing, how you have been testing, and how long you have been doing so, you can tell a compelling testing story that isn’t just numbers for the sake of it.]
Without writing test cases (or something similar to record what has been tested) I don’t know the project can be confident that the tester has at least made a good stab at testing the software. Do you know of alternative ways to record test progress?
[James’ Reply: Yes. Activity-based test management. One such method is Session-Based Test Management, which I developed for that purpose 20 years ago.]
Thanks James, Totally agree for all mentioned on your article, however I think that Test cases is a basic task for Testing work but the matter of discussion is how to write these test cases, one can see it is important to write a very detailed test cases, another one can see that it is enough to write high level test conditions, a third one say for my case it will be time consuming to write test case as it is very clear and only I can write an outline of testing work like only a titles for test cases, so for the freshers and new joiners, detailed test cases is required after that, after gaining the experience, I think it should be according to the situation you are facing, like if it is a common testing task thus you only need to write high level detailed test cases like test conditions only and on this case writing detailed test cases is only wasting time , and for a new or complicated testing task, you have to do testing analysis and write down very detailed test cases, otherwise it is a kind of lack of proper care and attention.
[James’ Reply: I’m not sure I understand what you are saying. If you are saying that test cases are an essential part of testing, I disagree. They are definitely not. The idea of test cases is completely invented. It’s optional. It’s not a natural truth about testing. I don’t agree that new testers must write test cases or even think about them. I do think any particular form of test documentation may be useful in some situation, and it helps to practice the various forms if you want to consider yourself to be an expert.]
This article reinforces my long held view that expecting a programmer to write his own unit tests is a waste of his programming skills. As you rightly say, programmers write programs while testers write tests. I have heard some programmers say that by writing their own unit tests they feel that they have become better programmers. This to me is a complete fallacy. As a programmer I am paid to write working code. Any time I spend writing unit tests is time NOT spent writing code and this must surely be a waste of my programming skills. Writing code and writing tests are different responsibilities, so expecting one person to carry out both responsibilities must surely be breaking the Single Responsibility Principle.
Hi James,
I like your articles and your way of thinking however my whole work experience in QA – no matter the project, industry, etc… – clearly says that in projects where there were no test cases were most ‘broken’ and without any quality control. I strongly believe – and this is based on own experience – that no written test cases is wrong and too many written test cases is equally wrong.
[James’ Reply: If you were a cook or a food critic and you wanted to talk about the quality of food, would you say “there aren’t enough written recipes?” I don’t think so. I think you would talk about the cooking technique or the quality of the ingredients or the look of the food. No one would simply say “the problem with this restaurant is there aren’t enough rules to follow!” Similarly, if I felt that a project would be improved by creating some written test cases, I wouldn’t express that by saying that the project “needed more test cases.” I would express that by talking about testing that needed to be done.
Testing doesn’t need test cases. Testing needs good testing. If that comes along with some test cases, fine. But test cases are NOT testing.]
In first case you easily forget to cover lots of important functionality (new and especially existing – regression testing). If you get sick – no other can substitute you. If you got well written test cases – at least basic package – other may test when you are not available – of course – it will not be as good as if you tested it – but it is something – and that makes a huge difference.
[James’ Reply: It sounds like you are not aware of any way to encourage or preserve the quality of a test process except by formalizing it. It also sounds like you don’t know of any other way to formalize testing other than to “write test cases.”]
I see written test cases as something of check list – so I do not write them too detailed, but I try to mention everything what I have in mind when analysing user story and communicating with the customer. Very often I work on more projects in parallel so I get back to testing once the development is finished and if I had not written down some test cases I would have to remember lots of things and that would be lots of time wasted again.
[James’ Reply: So, then you would be comfortable if I just use a checklist to aid my testing? Is that all you mean by test cases?]
Trust me – I tried both – and at least for me – some amount of test cases written down works like a charm. Every time I tried to test just based on story description or requirement I forgot on something what proves important since I did not remember everything.
[James Reply: The first problem I have with trusting you is that I don’t know what you are talking about. Formal procedures? checklists? I don’t know. The second problem is that I also am a tester with quite a lot of experience and study to inform what I am writing. How can I account for the difference between our two opinions on this matter? Perhaps, instead of trust, we would test each other’s ideas.]
By your logic we could abandon books and start just thinking about everything instead not to get indoctrinated or swayed by someone else’s ideas :-).
[James’ Reply: Clearly you haven’t understood my logic. I will repeat my thesis: “In this article, we explain why creating and performing test cases is not the same thing as doing testing. In fact, test cases are a poor basis for organizing a test process and no basis at all for measuring testing progress. Our industry’s obsession with test cases must come to an end or testing as a field will be never be worthy of respect.”
I am not claiming that test cases are worthless. I’m telling you to stop being obsessed with them. Talk to me about testing, not test cases.]