Outdated testing concepts #1

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.

Stereo cassette
Image source: https://s-media-cache-ak0.pinimg.com/736x/68/cb/c3/68cbc3afe76b87fb9963e88a416f2a6a.jpg

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.

9 thoughts on “Outdated testing concepts #1

  1. Joe DeMeyer January 14, 2016 at 3:52 pm

    Greetings Mr Slavchev!
    Thanks for a great post – I’m looking forward to more additions to this list!
    May I suggest that “…don’t mix with programmers” is also an outdated concept? Since quality is more of a team sport, it becomes important to collaborate with developers on business intent, business outcome, and their tests (low level, unit, etc). With that in mind, I encourage testers to build rapport with developers and other team members so that the team aligns with a quality mindset. Your thoughts?

    • Mr.Slavchev
      Mr.Slavchev January 14, 2016 at 4:17 pm

      Hey, Joe. Thanks for the kind words. Yes, actually! That’s why more testing professionals don’t feel comfortable using the term “Quality assurance”. I have it on my list, follow the thread and you will see in details.

  2. AdrianS January 18, 2016 at 12:20 pm

    Have heard many many testers talk about those things, but few that can express them. Have met enough testers that can tell a good story about their work (but then again, good differs from one organisation to the other and their expectations). And they’re appreciated for this. But most of these people are not that good at explaining themselves in writing as they are at telling a compelling story. So it all comes down to this inability to express our work. A test case document is a good & easy way out of this predicament. It can also show if certain product areas are neglected or functionalities misunderstood.

    So this outdated concept only comes to show our own limitations, specifically to our ability to communicate the fruits of our labour. Is it then an outdated concept when we haven’t manage to deal with this issue properly?

    • Mr.Slavchev
      Mr.Slavchev January 18, 2016 at 10:37 pm

      Hello, Adrian and thanks for the comment!
      Yes, good point! It is our problem we didn’t manage to deal with this properly, but we are dealing with it somehow, baby steps in the beggining. To shift the whole development world’s view on what testing profession really is, isn’t an easy job and they won’t just let you speak without any resistance. Furthermore, let’s not forget most of these people don’t really care what we do, so they feel completely comfortable to believe the stereotypes.
      And yes, I do believe this is an outdated testing concept, even when we didn’t actually manage to win the fight, for couple of reasons:
      the possitive response to this post shows the community is mature enough to look for changes in methodological and practical level – the context driven school is a good example for that.
      And yes, it is a matter of being able to express the importance of your job in the best light possible and I see more and more people that are really good at it, so we have the potential, we just need time to master.
      Appreciate your comment, Adran.
      Good luck!

Comments are closed.