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 Hegde: Not necessarily, However they need to be technical enough to analyze the system under test and can carry out effective testing.
Tracy Richardson: No, 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 Halperin: No – 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
Here’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?
It 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???
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!
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.