Should testers execute their own test cases?

Ask this question and you will get a barrage of differing views all with their reasons for a “yes” or “no” answer.  It seems that this is an area that testers and test managers just can’t agree on.  

So maybe there is something we can agree on, or at least debate, without having the poles apart yes/no extreme to the question.

Can we agree that test cases should be created?  No, we can’t. James Bach would argue that test cases have no place in doing testing.  If I read him correctly, he believes that formally written test cases have limited value and can actually be counter-productive to good testing and their only use is if there are legal reasons to create them (apologies, James, if I have mis-represented your view and you ever read this).  I have a lot of sympathy with that view and like to reduce (note, not eliminate) the number of test cases that my team writes to a minimum level necessary.  Key phrase there is “minimum level necessary”.  I believe there are occasions when the most effective way of testing something is by writing a test case.

Ok, so we can’t agree on whether we should write test cases, hmm, where to go from here?

Perhaps we can agree that tests need to be designed?  If we take the definition of “designed” as meaning that the tests are thought about before actually executing, then I think we can agree.  Even if you are doing Exploratory testing you are designing tests, by jottings on pads of paper, frameworks in your head or bright ideas that just pop-up as you learn more about the system you are testing.  Ad hoc tests are not designed, but I would argue that Ad hoc testing isn’t testing, it is playing around and has no place in the professional tester’s thinking.

So, if we can agree that tests need to be designed, then what is the implementation of that design?  

Before we determine that, maybe we need to look at what is the purpose of the test.  The widest view of the purpose of any test is to find a bug.  OK, we can argue about risk, control, confidence level, etc. but at the end of the day we are trying to find bugs.  But, it isn’t quite as simple as that.  From a project perspective, yes you are trying to find bugs, but there are supplementary purposes which are valuable to the test team, the project and the company.  Some examples:

·        Teaching a tester how to test.  The only way I know of teaching someone how to test is to get them to test.  Training courses are all very well, but they only give pointers on how to test.

·        Teaching a tester about the product.  It would be nice if every tester knew everything about a product before they started to test it.  Some testers may, but some (maybe all) will not.

·        Improving a tester’s skill set.  This may be in terms of getting the tester to use a previously unknown/unused technique; it may be in terms of getting them to lead a test effort.

The implementation of the test design, therefore, should be dependent on the purposes of the test. 

But we still do not have a full answer on how to implement the test design, because now we should consider what is the approach taken to testing?  By this I mean are you a test case shop, an Exploratory shop, unstructured or a mixture of approaches.  Your implementation of the test design will depend on your approach and your approach may change depending on the product you are testing this week.

When you have implemented your test design, then you need to execute the implementation.  Part (a small part) of me argues that if your design is good, then your method of execution is irrelevant, because you have done all the hard work of thinking and the rest is mechanical.  The rest (and more dominant part) of me argues that all you have done is laid a framework, no matter how good your test design is, the system under test is going to surprise you and you will not have covered everything you find you need to cover.

If that is true, that your test design implementation is only a framework, how do you determine who executes the test?  That decision should be made on who is the most appropriate person to execute the test, based, again, on what is the purpose of the test and the method of test design implementation.

No doubt in twenty years time people will still be arguing about whether the test case author should also execute the test.  Me?  I’ll stick with saying that “it depends” and take each situation on its merits.