You have waited a long time for this and finally you get software to test from development. Energized and excited you install the program and fire it up. It all looks great, the new interface is stunning. You are ready to beat the crap out of this software. So you roll up you sleeves and hit the first soft button. The screen turns blue. Not that exited any more, a bit pissed off is a better word of how you feel right now. So you put on your friendly face and walk back to the developers, explaining what happened and kindly asking them to fix this problem.Now, back at your desk waiting and waiting and suddenly a new version of the software is released. Wohooo you shout, time to get busy. Installation works great and it fires up, now the shivering moment arrives, you hit the same soft button and it takes you just where you expected it, to the registration page. Great, the devs have done a fine job! Now I can type in my contacts to register. But there is alway a but, I can’t type anything into the input fields, WTF!!! Have you ever been into a similar situation? I sure have a couple of them in my pocket. Isn’t it frustrating when you just have to gently poke at a software and it falls apart? You never come to the point where you actually can practice your testing skills because the bugs just pop up in your face without you doing anything in particular. Why does this happen?
Most of the time it is because there is a lack of checking the software before you are expected to test it.
Michael Bolton wrote a series of wonderful posts about testing vs. checking.
I think this is an important distinction to make and it has served me very well rhetorically when discussing and describing its different purposes and how it brings different values.
However, I see tendencies that some look down on checking and it is not as “fancy” as testing, it is second class.
This however does not serve us good. There is no point in comparing which is “best” since it is not a competition. It is not that if you do testing you do not need checking or (as some agile folks seem to believe) that if you do checking you do not need testing. If you believe so then you have misunderstood the whole concept and I strongly recommend you to go back and read Michaels blog posts very carefully. So checking is an activity that is algorithmic and can be automated, the verdict is pass or fail. Its purpose is to confirm that what we already know about that specific part/function/scenario still is true. With checking we want to make sure that what previously worked in the product still works. Testing however, is a heuristic based sapient activity. It is exploration, learning and evaluation of a product and our motive for testing is to find new information. We ask new questions to the product to uncover the unknown. So what I mean by checking as an enabler for testing is that we need checks to inform us that our existing believes of the product are still intact. When we have that information we can start testing, that is go further then we did last time by starting at the point we previously stopped at. Checking provides us with a solid foundation to stand on that will give us confidence to start testing.
But we should put checking where it belongs, that is where it provides most value. Most often that is as close in time to the developed code as possible to provide fast feedback. It is developers who often can do this cheapest and at the same time benefit the most from having frequent and rapid checking of their code. There are some really good practices out there that includes checks, like TDD (Test Driven Development), BDD (Behavior Driven Development) and others. What bothers me is when I see testers being requested to do these checks instead of doing testing. These practices are not testing practices, they are development practices. Checking is only one of the benefit with them. When you put a tester to do this task then you tend to loose all the other good and valuable benefits of the practice. Benefits such as knowing when to start coding and when to stop coding, clean and simple design, fast feedback to developer about the code, confidence for the developer to continue coding, improved developer ownership of quality of the code, keeping short iterations with new code before running checks and many more values. Why would someone want to take all that away from the team by putting the tester to do the checks?
When developers do this I very seldom encounter the scenario I described at the beginning. This saves the whole project a lot of time and it keeps stability to ensure the development moving forward. It also keeps a lot of frustration away from the team.
To conclude this, don’t look down on checking. Checking is a very important activity but it is not necessarily most beneficial to put testers to perform this. Use checking as an enabler for testing!
