Outdated testing concepts #1

Reading Time: 3 minutes

End of the previous year and the beginning of the current one are normally the time we are determined to make new year’s resolutions, which most of the times turn to be big, fat lies, but anyway. I am not writing this to make resolutions, but to set goals. And we as a testing community have a lot of work to do in order to progress, since our craft was, as James Bach called it, “in perpetual childhood” for more than couple of decades. I believe the reason for this is there’s still a lot of misconceptions, myths or just outdated beliefs about testing that need to be declined, so we could progress in the right direction and leave the useless luggage of principles that never worked or were ineffective.

So here is our list:

Outdated concept # 1: Testing is easy. Everyone can do it.

This concept was around for far too long and I believe every one of us had to explain at least thousand of times how our job isn’t simply “play with the product” or “break something” or “find the bugs” in it. Testing craft is profound and complex as it possibly gets, and no, testers are not failed programmers, they just don’t mix with programmers. Anyway, this is useless info, since many readers of this are testers, this isn’t helpful at all.

The thing that really surprises me is that companies accepted that concept for granted and even adapted their processes to it. All the outsourcing companies try to make new testers believe that it’s isn’t up to tester’s specific skills and knowledge of the product, nor the experience he has, but the documentation of the processes itself. They will make you believe that testing could be performed by mindless morons and you should write your test plans and test cases as if they going to be read by mindless morons. This way, they assure once you are gone, next totally green and incompetent tester will take your spot doing just the same.

Their biggest fear is when you try to defend your value by explaining how complex a testing process is and that in fact IS scientific experiment with all it’s assets, therefore needs educated expert in order to be performed in the right way and effectively.

I had an interview once, the interviewer was only concerned if I could write test cases, just that. So, we had an argument, that testing shouldn’t be determined in a specific set of actions to be effective, that this is only one approach to do it, that testing documentation is not test cases in the best way and that testing process is far too complex and fluid to define it as a set of rules, it depends on observation, critical thinking, oracles, assumption, risk assessment, heuristics etc, etc … Poor guy was almost shocked. It was a cataclysm in his poor narrow view of what testing is, finally he got relieved by knowing I am able to write test cases, but I don’t like to, because it’s boring and doesn’t document the way that I perform testing. I finished with the statement that this is so-called “best practice” we tend to stay away from, because it’s not always relevant. The answer was: “Well, you see, these are best practices for a reason”.

So, how can we react against this and justify the importance of testing as an experimental process and not just scripted activity?

• In first place you don’t have to be afraid to stand for your beliefs, make sure you are able to explain the work you do, not just do it.
• On the opposite, make sure you could give clear examples “why” and actually apply what you believe in and not just brag about it. Demonstrated knowledge is one of the most valuable skills in any craft.
• Don’t expect anyone to know the specifics of testing, it is our job, but give the details carefully and in understandable manner for a person that has no background in software testing, as they could cause a lot of confusion if served at once.
• Knowing your craft and being able to answer the question “why” is vital for your development as a tester. As you see from the opponent’s view-point, in my interview, the answer to the question “Why follow best practices?”, varies from “Because we have to”, to “because everyone else does”. As you can see, it’s not an enormous effort to question such an explanation and we could definitely do better than that.

I wasn’t expecting this to get so long, but as it gets in testing, things are dynamic and we should adapt to them. I will write some more post on obsolete concepts later in my blog.

Important notice: Some important sources that provoked me to get to this point are the book “Lessons learned in software testing” by Kaner, Bach and Pettichord as well as the videos from Introduction to BBST by Cem Kaner.