Stop being a NON-Technical Tester!

Editor’s note: This post was originally posted in Dec. 2011, and has been updated to take current testing trends into account.

With current QA trends reflecting an increased emphasis on agile and DevOps, as a means to cope with accelerated product releases, it would seem that it has also become increasingly important for testers to become more “technical” and even at times “code savvy” in their teams and work.

When I again (as in the original post from 2011) posted the open question:

“Do testers need to be as technical as programmers to be successful at their jobs?”

I got plenty of answers. Here are just a few representations of the main opinion threads:

Prashant HegdeNot necessarily, However they need to be technical enough to analyze the system under test and can carry out effective testing.

Tracy RichardsonNo, but they need to understand what a programmer has changed and linked to. I have always thought a good tester comes in from the user perspective, with a lot of tenacity and touch of “Right let’s break this!

Kobi HalperinNo – Testers must be MUCH MORE Technical than programmers !!!
While programmers mostly consider how the product should work, Testers must consider all the adjacent activities and features which might cause it to Fail.

To all the responders above and those I missed, thanks for the great feedback!

But as you surely guessed I have my own opinion on the subject and I want to share it with you, so here it goes…

My definition of a Technical Tester

Technical testerHere’s how do I differentiate a Technical Tester from a Non-Technical Tester. (If you read my previous blogs on “Why are some tester not really Professional Testers” then you should already have an idea…)

A Technical Tester is not afraid of doing most of the following stuff on a regular basis as part of his job (without any specific order):

-Understand the architecture of the product he is testing,

including the pros & cons of the specific design, as well as the risks linked to each of the components and interfaces in the product.

He then uses this information to plan his testing strategy, to execute his tests and find the hidden issues, and also to provide visibility to his team regarding the risks involved in developing a specific feature or making a given change to the system.

 -Review the code he needs to test.

He can do this on a number of levels, starting from going only over the names of the files that were changed, and all the way to reviewing the code itself. This information will provide valuable inputs to help decide what needs to be tested and how, as well as to find things about the changes that might have been missed by the developer or the documentation.

BTW, by code I mean SQL queries, scripts, configuration files, etc.

 -Work with scripts & tools to help his work.

A technical tester should be able to create (or at least “play”) with scripts to help him run repetitive tests such as sanity or smoke, and tasks such as configurations, installation, setups, etc.

He should also be able to work with free automation tools such as Selenium or WATIR (or any of the paid ones like QTP, SeeTest, TestComplete, etc) to create and run test scripts that will increase the stability of the product in development, and over time save time…

 -Be up to date with the technical aspects of his infrastructure

(e.g. browsers, databases, languages, etc)

He should read the latest updates on all aspects of his infrastructure that may have an effect on his work. For example new updates to his O/S matrix, known issues with the browsers supported by his product, updates to external products they integrate, etc.

With the help of Google alerts and by subscribing to a couple of newsletters anyone can do this by reading 5 to 10 email 2 or 3 times a week. The value gained from becoming an independent source of knowledge greatly exceeds the time invested in the efforts.

 -Is able to troubleshoot issues from Logs or other System Feeds.

He is aware of all the logs and feeds available in his system, and uses them to investigate more about any issue or strange behavior.

This information is helpful during testing to provide more information than simply writing “there is a bug with functionality X”. And it will be critical if he is called to work on a customer bug, where he needs to understand complex issues quickly and without access to all the information.

In addition to the above, a technical tester should also be able to:

– Provide feedback and run the unit tests created by his programmer peers.

– Run SQL Queries on the DB directly to help verify his testing results.

Install and configure the system he is testing.


Sounds like Superman or MacGyver?

Flying ManIt may sound like this, but actually it’s not!

As testers we work on projects that revolve around Software, Hardware, and/or Embedded products. The only way to do a good job in testing them is to have a deep understanding of both angles: technical and functional.

This doesn’t mean that you need replace or have the same technical dept as your developers, or surpass your Product Marketing’s knowledge of your users.

You need to achieve a balance, where you have “enough” knowledge and understanding of both these areas in order to do your job as a tester.

Is it black and white?

There is no standard to define how technical a tester should be on every project and product. Like in many other situations, the best answer to how technical you need to be is: “It Depends…”

You should be at least technical enough to do your job effectively and to talk the same language with the rest of your programming and testing peers.

What do I mean by that?

If you work on a software development firm then you should understand enough of the languages used by your developers to be able to read the code and understand their changes. If you work on a heavily DB-related project then you need to understand enough of SQL and database management. If you work on a Website development firm then you should know enough CSS, HTML and JS, and so it goes…

So if I am not Technical enough, should I quit testing???

Raise your handDefinitely not!

If you like testing and you are good at it, why should you quit? On the other hand, this is a great opportunity to improve your work and increase  your market value as a tester 😉

And the best part of it is… it’s not very hard to become a more technical tester! Just start by asking questions, searching the web, reading books, etc.

I’m also confident that if you show the potential to increase the value of your current work to your manager, he won’t mind you investing sometime during your day to learn these new trades (as long as you manage to explain why this is also good for him!).

So, stop making excuses for not being technical enough. Just make a decision (or a New Year’s resolution…) to start working on improving your technical skills!

Go ahead and get rid of the NON-Technical Tester in you!

It will be worth your time and make your job more interesting and satisfying.

What do you think?

– Are there any negative sides to being a more technical tester?

– Maybe there are advantages for testers who used to be developers in the past?

Come and share your opinion or experience on this subject!



About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.

, ,

31 Responses to Stop being a NON-Technical Tester!

  1. Simon Knight December 19, 2011 at 4:24 pm #

    Thanks for the Google tips alert – I’ll be making use of this.

    As an aspiring, reasonably “technical”-tester, I think the testers path to becoming developer-like in their skillset can be quite fraught. Although I appreciate that it can simply be a case of asking the right questions, it is more often (in my experience) actually a case of asking the right people, in the right way, at the right time. That is to say, there can be political issues at work that make it more difficult for the tester to gain access to the necessary people/knowledge/training etc for them to be able to progress technically.

    There’s also time issues to be considered. Certainly the tester will benefit from installing and configuring the system under test in their own environment, and running the unit tests, etc – but will this be considered a valuable use of their time? Particularly if/when they hit problems because (for example) they run Windows and the developers work on Linux. Will they get the necessary support to help them – possibly not… And where such activities conflict with more pressing demands, clearly deliverables are likely to take precedence over activities that can be left in the development domain.

    That said – I whole heatedly agree with the post. I just think it can be a difficult path to tread!

  2. Bj Rollison December 19, 2011 at 9:07 pm #

    Outstanding post Joel.

  3. Raja December 20, 2011 at 8:27 am #

    enjoyed it 🙂 

  4. Zvi December 26, 2011 at 6:27 am #

    i really enjoyed reading your article.
    This article also reflects my opinion that Testers must be professional.

    the sad story in the market is that most of QA people are feeling Inferior compare to developers and therefore the testers that we find in this job are less technical than what we want.

  5. Jean Spector December 26, 2011 at 9:17 pm #

    I agree with the “it depends” answer. Some projects require very technical testers and some – much less so. The more low-level the project is, the more distributed it is – the more technical the testers have to be. Some projects, like some standalone apps – even with a very rich feature set – can be handled by the less technical people while others, e.g. OS will require a mix of both types.

    Regarding the negatives of being a technical tester – yes, there are some. Some technical testers may be less inclined to handle the “trivial” bugs of UI, user experience, phrasing etc. even though these issues irritate the users just as much as the more “serious” bugs. Others may prefer to spend their time developing new scripts as it’s more “fun” as opposed to executing the tests. I say in most cases a good mix of both types is needed in order to get good coverage – some go deep, some go wide and some go into the softer skills of user interaction.

    Regarding testers who used to be developers – well, that’s a tough one…
    Let’s split their roles into two types: Type1 = near- or full time test automation development. Type2 = major part of their job comprises of executing manual tests.
    While Type1 is a great match, I would be very careful hiring a former developer for a Type2 position. While some dev experience can be useful, a lot of dev experience wouldn’t benefit the Type2 tester a whole lot – and developers’ mindset is different from the testers’ one. Even worse, some developers who concentrate on a single module development lack the system view – and while it may have been acceptable in their development days, it’s a very bad thing for a tester. Setting the expectations is also very important in this case.

    IMO MacGyver would be the all-in-one person and – while great – wouldn’t be required on bigger projects with enough testers to specialize in each area.

    Jean Spector

  6. Lubna Hosny December 27, 2011 at 12:28 pm #

    Its not that easy, but “It Depends ..” on who wants to be perfect and reaches the top level of awareness of his project . 

  7. halperinko December 27, 2011 at 4:31 pm #

    The wider the tester knowledge, the more issues he can find.
    A point neglected here (and widely in most parts of our profession), is that testers will also enjoy some knowledge of electronics and mainly computer structure – after all, though many call it SW testing, there is no SW running without HW.
    HW brings also an Analog state of mind – there is not only 0/1, there may also be 0.00001, and a SW might act differently when PC is running in -5 vs. +40 degrees Celsius.
    Another point is different infrastructure issues, such as knowledge of the Operating System structure, dedicated tools for monitoring and tweaking it etc.

    From the few testers with extensive Dev background I have met so far, I’d say it can surely help them become very good testers (though they do need to make some transformation)


  8. Gary Masnica December 28, 2011 at 1:34 am #

    Great post.  I agree with pretty much every aspect of it, but as @twitter-221842122:disqus said below that it can be a really difficult path to tread. All of what you mentioned I think is part of our value to the teams we support as testers. Especially with development cycles shifting shorter and shorter, the more we contribute the more our value increases as team members.

    Not to mention, with how fast the software/hardware game changes if you don’t want to keep learning and expanding your knowledge base you likely won’t have a long career in testing. And if you don’t want to keep expanding that base, then why are you in testing? I don’t know about everyone else, but if I’m not learning I get bored fast and that keeps me progressing.

  9. Anonymous December 28, 2011 at 8:12 am #

    Hey Simon,

    Good point about work-place politics, it is certainly an important aspect to take into account.  The same goes for timing, it wouldn’t be wise to start asking configuration-related issues when your team is heading towards the final stretch of the release cycle.

    That said, I think it is mostly a case of advancing step-by-step and not to try to become technical instead of doing your work but as part of it.  For example, installations and configurations (in my experience) are something that testers will need to do a lot more than developers because we work on multiple environments and perform a lot more diverse (and sometimes destructive) operations on the system.  With this in mind you can ask developers to show you how to get the latest build and how to install it and set it up by yourself, to avoid getting their help all the time.

    You can do the same for reading and understanding log files, for going over the build notes and understanding what is stated there, etc.

    You should also not try to do everything at once, improve step by step.  After all we have tests to run too!

  10. Anonymous December 28, 2011 at 8:12 am #

    Thanks Bj!

  11. Anonymous December 28, 2011 at 8:13 am #

    Hey Raja,

    How can I fail to mention you if you even gave me some ideas for it!



  12. Anonymous December 28, 2011 at 8:18 am #

    I agree.  And so as a Test Manager I make sure to give my testers both the initial push as well as the legitimacy to grow and expand.  

    For the right testers this will be enough to start moving forward, but there are some that feel threatened by this and prefer to stay in the comfort-zone of focusing only on the functional aspects of their work and not on the technical aspects of it.  For me this is like riding a 2-wheled tricycle – you can advance some how, but not fast enough or good enough.

  13. Anonymous December 28, 2011 at 8:24 am #

    I agree on the technical tester negative aspects you mention, and I have dismissed some pretty technical testers because they failed to see their work as the correct mix of technical and manual testing (what they may seem like more trivial) work.

    I would add a Type3 to your Developer-Tester groups, and that is for Developers who became testers on more Agile-oriented projects.  In these projects I have seen how a these individuals then to exceed since they are able to understand the technical aspects of the application and so define their testing risks and areas.

    In any case, I would hire MacGyver for most of my projects, if nothing else he always has a good Swiss-Army knife that may come handy in order to slice cold pizza during all-nighters 🙂

  14. Anonymous December 28, 2011 at 8:25 am #

    Not sure I agree with your comment about “perfect”, I don’t think I know any perfect testers, but yes a lot of testers that want to expand their knowledge and understanding of the projects they work in.

  15. Anonymous December 28, 2011 at 8:26 am #

    Guilty as charged Kobi!
    I focused mostly on Software here and you are right, the technical aspects of HW or embedded systems can be as challenging or even more.

  16. Anonymous December 28, 2011 at 8:28 am #

    Totally agree.  

    I think that the challenges of shorter and more intensive cycles are one of the catalysts making testing a more technical profession.

    Thanks for bringing this up!


  17. RaghavendarreddyP December 29, 2011 at 1:02 pm #

    I am with the topic, where Tester must be fully loaded with technical strong, then they can understand the application well, and they can give the value adding to the application or product, many people may think like just validate the things as the role, may be that fill there job profile, As test engineer he or she must be well with all area,update there skills days by day, If any issue find in the application, be report with the details information, that is also add value to the application.

  18. Anonymous December 30, 2011 at 4:34 pm #

    Yes, this is the point, we need to do our work with as much detail as possible in order to provide higher value to the process.



  19. Dmusil February 2, 2012 at 7:13 pm #

    Yes, as a QA professional you should understand a lot. Before i became a tester, I was a programmer and I should definitely say, it is helpful in my job.
    And someties we, testers, should write scripts for automated testing or load testing. Not everything can be tested by clicking the GUI.
    So, you are right: “get rid of non-technical tester in YOU!” (please, do not make it via crash test or stress test :c) )

  20. Jennifer Punitharaj February 16, 2012 at 6:47 pm #

    I find it pathetic when the testing community tries hard to prove they are adequately technical to rub shoulders with the development community…. I mean why have that inferiority complex at all. We are testers, and some of us will be domain experts, some plain automation experts, or performance or whatever else? Does it really matter if we are “Technical” or not so long as we are SMEs  in whatever we do. Take pride in being a tester, and do what you do damn well, and you’ll automatically have people envying you and vying to do what you do. They’ll be attracted to the passion you display. If it requires that you have technical expertise then go and acquire it. But it may not be the need for all testers

  21. Anonymous February 23, 2012 at 9:50 am #

    I am not sure I agree with you here.

    I think that many testers hide behind the fact they lack technical skills, and certainly use this as an excuse to be treated as second best.

    I also think that the trends in the industry are making the job of *most testers* to be a lot more technical than what we used to be, and we need to wake up to this fact.

    I will agree that we need to be SMEs (or subject matter experts, in case some people are not familiar with this therm) and that we need to be proud of what we do.  We don’t need to paint ourselves stripes and call ourselves Zebras, we are testers and we are here to do our work.

    But remember, if you are on a tunnel, and underneath your feet are train-tracks, if you see a light at the end that rapidly approaches you, you can either think that it is the exit that is running to you, or you can realize that it is a train and you better do something about it….  Testing is becoming more and more technical, the train is coming and you better make sure you do something about it too!

  22. Questioner January 9, 2014 at 3:18 am #

    I am currently Working in Production support Team in Unix,Sql,. But i seriously Lack Technical Skill. Though i am good in SQL and do understand the Shell scripts,but its difficult for me to write scripts coz i am nt good with programming. Can i go for Testing as i am really intersted in it and ready to work hard.. Please reply.

  23. joelmonte January 9, 2014 at 8:48 am #

    How can you know if you are good or bad at programming without having tried it?

    Let me give you another angle at this: My 6 year old was sure that he was bad at ridding bikes, and in the end it was all because he had not had enough time to gain the needed experience to ride confidently.

    There are 2 things to take into account in your question:

    (1) You cannot know if you are good or bad at something until you have invested some serious effort on it. There is always a learning a curve.

    **But maybe most importantly**

    (2) You do not need to be a good developer to be a good tester.
    You need to be technical enough in order to understand the reasons behind your developers decisions.
    You need to be able to read the code and understand the high-level ideas, logic, risks and constraints.
    You don’t actually need to know how to write the code itself.

    Bottom line: If you want to go into testing, GO INTO TESTING, it’s a pretty fun and cool place to be in. You will need to be somewhat technical and it sounds like you already are (or at least are in the way).

  24. Chaitrali January 13, 2014 at 7:23 am #

    Testers being the gate keepers for the product, I think have a huge responsibility on their shoulders. I think testers may or may not be technical that they can code, but it is extremely important to understand the code, it helps you write better test cases, because now you can identify the areas where the code can actually fail. But in addition to being technical I believe that they also need to have an understanding of their end users. Which means its important for them to understand the user perspective along with the domain knowledge to catch the domain specific bugs. Its important that the tester strikes a balance between both the technical and non technical world in order to achieve success in their profession.

  25. Joel Montvelisky January 14, 2014 at 9:01 pm #

    Hi Chaitrali,

    I totally agree with the need to understand the end-user, I even wrote about it on my last post here, but I cannot agree with the definition of testers being Gate Keepers for the product.

    I think that organizations that still believe in this approach fail to realize that as testers we cannot serve as effective gate-keepers and not even as “in charge of quality”, quality is the responsibility of everyone in the team and so is the responsibility for not releasing bugs to the field.

    Personally I believe more are more organizations are starting to understand that we are more information officers in charge of providing visibility and control over the project than simply or absurdly in charge of “catching all the bugs before the product is released”.



  26. Amit February 23, 2017 at 12:42 pm #

    It’s been 5 years, and people still use the term “technical tester”, it’s really annoying.
    Testing is a technical job – whether one recognizes it or not.
    There is no such thing as “non technical tester”, there’s “bad tester”.

  27. joelmonte February 27, 2017 at 5:54 am #

    Not sure I would go as far as that, but I see your point 🙂

  28. Cruddy-journalism February 27, 2017 at 4:26 pm #

    I agree with your article. I am convinced that learning to program has helped me with my testing in the past. I certainly improved my exploratory testing. Plus I’m not always happy about testing things I don’t understand. I can converse with a developer and understand what they are explaining to me, without the conversation resorting to a child’s level of understanding. The only detrimental side effect would be sticking an oar in and trying to solution things before a developer has a look.

  29. Pintu Kumar December 20, 2017 at 4:43 pm #

    I totally agree with your article. Tester must be technical. As a tester we must be aware about:

    How the application has been built?
    What is the structure of the backend database used?
    Which Web server is being used?
    What are the use of different configuration files? etc.

    Now a days when companies are also relying on cloud infrastructure to host their testing environment, tester should also be aware about basic concepts of cloud computing so they can work with the devops team closely.

    Being a technical tester helps a lot in isolating the bug.

    But at the same time tester should be aware, when to wear the different hats. While testing, the testers must think from end user perspective and not as a technical person.


  1. Testing Bits – 2/19/17 – 2/25/17 | Testing Curator Blog - February 26, 2017

    […] Stop being a NON-Technical Tester! – Joel Montvelisky – […]

  2. Five Blogs – 1 March 2017 – 5blogs - March 1, 2017

    […] Stop being a NON-Technical Tester! Written by: Joel Montvelisky […]

Leave a Reply

As of May 2022, the blog has moved to PractiTest's main website. To keep following our posts go there.