Agreed fallacy #2: Software Testing is not technical

After having talked about why I don’t agree that anybody can test, it’s time I explained why Software Testing is actually a highly technical discipline.

Let me start saying that, if you think that the only technical side of Software Testing (if any) is Test Automation, it’s probably because you lack knowledge of Software Testing.

The fact that, when speaking about requirements-based testing, for instance, a lot of techniques (equivalence partitioning, boundary values analysis, domain analysis, decision tables, cause-effect graphing, state transition testing, combinatorial testing, etc.) exist —even though many alleged testing professionals worryingly ignore them— should be enough to prove your point of view wrong.

It has also to be said that Software Testing and the corresponding techniques are not limited to Functional Testing.
By the way, have you ever heard about (and taken into account) Security Testing, Usability Testing, Accessibility Testing, Reliability Testing, Efficiency Testing, Portability Testing, Maintainability Testing, Exploratory Testing, for example?

It might also be worth mentioning that, by means of static analysis, a Technical Test Analyst can peruse your code and find interesting bugs even before your software is live.

Anyway, if all those arguments haven’t convinced you yet, please consider at least the technical expertise required to understand and work with different systems and business domains.

So, are you really sure that Software Testing is not technical?


"Elementary, my dear Watson" by luke.anto
“Elementary, my dear Watson” by luke.anto is licensed under CC BY-NC-ND 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.