- Version
- 4474 Download
- 233.42 KB File Size
- 1 File Count
- April 27, 2014 Create Date
- April 21, 2019 Last Updated
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.
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).