Agreed fallacy #3: Testing is easier than programming

After having refuted the argument that anybody can test and that Software Testing is not technical, it shouldn’t be difficult to grasp why I don’t believe that testing is easier than programming either.

Firstly, because, as I stressed in a previous article, in order to work effectively as a tester, you need to have a testing mindset.
Which is not easy at all.

Secondly, because, as I already explained, you need technical (yes!) expertise to master different testing techniques, types of testing, systems, business domains, etc.
Which is anything but trivial.

Last but not least, because believing that testing is easier than programming means belittling testing, which, in turn, implies underrating quality.
Is this what you mean?

#ThisIsASeriousLackOfTestingMindset

"Piece of Cake" by EssjayNZ
“Piece of Cake” by EssjayNZ is licensed under CC BY-NC-SA 2.0
my profile picture

Thanks for reading this article.
Feel free to recommend it or to add a comment.

Should you have any doubts about Software Testing, please contact me: I will be glad to help you.

On the other hand, if you want to get notified about my blog posts, please sign up through the BLOG > SUBSCRIBE TO THE BLOG NEWSLETTER menu.
Thank you.

2 thoughts on “Agreed fallacy #3: Testing is easier than programming

  • September 16, 2019 at 18:37
    Permalink

    I think the heart of the matter is people measure skill in software by whether you write code or not, and then how well you write it. The glamour is in writing code. So that helps explain why so many people in software want to write ‘automated tests.’ That, plus the dopamine rush you get when your new automated test passes. You can look back on the thing you just created. But the skills in testing are in quickly determining what to test, how much to test, and with what methods… and then how to communicate what was tested and what was discovered. Answering those questions requires serious mental gymnastics, and often does not give a dopamine rush, at least in my case… In other words, it’s like taking the red pill or the blue pill. Feel good in the false reality that writing these limited static automated checks is the be-all-end-all, or constantly feel unsure in the real reality that testing is so much more than that and your work is never done. That’s not easy!

    • September 16, 2019 at 19:54
      Permalink

      Thanks for sharing your thoughts, Nicholas, and especially for mentioning the importance of “quickly determining what to test, how much to test, and with what methods… and then how to communicate what was tested and what was discovered”.
      In my case, the dopamine rush is mainly related to figuring out how/when/where a system might fail before a customer does.
      I wish more professionals and organizations saw the glamour in it! 😉

Comments are closed.