On Always Being Right Or Doing the Right Thing the Wrong Way

They can always count on me to do the right thing.

That statement was made to me by another tester while we were sitting having a coffee a while ago.  It came as while discussing problems encountered in his shop in test planning and design - and of course by the testers trying to follow the steps and struggling with them and getting confused and not able to follow the detailed steps and getting dragged farther down and... ok - whew.

Let me see if I can sort it out a little.

The testing load is getting heavier - sounds a bit like much heavier.  The number of testers is constant.  The number of projects are going up.  The number of demands for documenting what the tests do is increasing and more people are looking for answers.

Massively frustrating for him.  His approach was to aggressively test the entire application.  No matter how little or how much the impact of the project was, the application needed to be tested.  Updating one version of a third party app with a newer version of the same app, both would be need to be aggressively tested.

The thing is, I can relate to the problem.

When you are looking at what software testing "is" you may want to look it up in wikipedia or use your favorite search engine to see what you can learn.  Then you may come up with a whole pile of contradictory statements and definitions.

Then there is what these things mean.  Testing validates requirements are met.  Testing validates that the functional aspects of the software are correct.  Testing ensures the correctness of the software.

The Catch is that doing these things boils down to "Test Everything."

We can't Test Everything.  We can sort out some things that need to be tested.  To do that, we must consider something else.

We must consider the context of the project.  We must consider the mission the project team needs.  We must consider what it is that we can do to provide meaningful information.  We must consider how we can support the decision making process around the needs of the project.

To do this, we must not take the same approach to every project.  We must not take the same rules in to every project.

We must, instead, consider what we can do to provide meaningful information to the project.  We must consider the scope of the project.  What is it that is needed?  What is it that people want to learn?

Then he said it again, with more emphasis: They can always count on me to do the right thing.

I asked if the right thing ever varied.  Is it possible that the right thing can be different from one project to the other?

He glared at me and informed me that I clearly do not understand what testing is.  He left.

Clearly, by the model he is using, I do not.

I also had to pay the bill for the coffee.