I've been training testers for 18 years by now. The thing I've dealt with, struggled with, whatever...is that everyone seems to have their own interpretation of what a test case is.
I guess this is on my mind today because I had to sort through it all again in a class. Don't get me wrong - I don't mind the exercise, but it makes me wonder about where we are in the testing profession when there isn't even anything close to a common definition of a test case.
Sure, there's IEEE Standard 829, but even that definition can be taken many different ways and does not prescribe a format (not that I think it should dictate a format).
So, here's my point. Don't get hung up on the format you use, just make sure you understand why you are using it and that it meets your needs.
I use the format I do because I feel it has some distinct advantages both in manual and in automated testing. However, I'm cool with the fact many people will take one of my classes and still create test documentation in their own ways. Hey, whatever works for you is fine with me. I do think, though, that having a common set of test terminology has tremendous value for a test project and organization.
(By the way, I take the view that test cases are small, distinct tests that can be specified as inputs, predicted results, and a set of execution for each item to be tested.)
However, I would suggest that you take a look at how other testers in other organizations define test cases, why they use the definition and format they use, and if it might be helpful to consider adopting a different approach. Of course, if it ain't broke you don't need to fix something just to be fixing it.
Will we ever have a unified view of test cases as a professsion? I doubt it. Don't even get me started on test scripts, test plans, test scenarios, QA, QC...
What do you think?
Till next time...
No comments:
Post a Comment