Stop being a NON-Technical Tester!

A short while ago I posted an open question on twitter:

“Do tester need to be as technical as programmer
to be successful at their jobs?”

I got plenty of answers, so I will only post some of them representing the main opinions threads:
@TestAndAnalysis - Testing is a technical discipline that is different to programming and testers add a lot of value to projects
@huibschoots – No! It depends on the context they work in. But in general they need to have some basic technical skills (or the will to learn)
@datoon83 – I’d say that all people involved in the delivery need to talk 1 language – that of the domain and customers!
@klyr – Technical and non-technical testers have a different approach to testing, and will find different bugs.
@sgershon – Certainly do. Not sure about “more/less technical” as programmers, possibly they have to be “differently technical” than them.
@halperinko – @sgershon @joelmonte I normally look at it as in depth knowledge for devs, vs. System-wise knowledge for testers. (Some don’t follow rules)
There were also a couple of tweeps who replied with blog posts of their own sharing their opinion on the subject.
@diamontip – my answer – do tester need to be as technical as programmers to be successful at their jobs? bit.ly/v5vcX
and
@adampknight – I personally dislike calling testers “technical” wrote about it here bit.ly/tVHDOB
To all the tweeps 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 Technical

Specially after reading Adam’s post I feel the need to explain what do I mean by technical, or better yet 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.
etc.

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, or rephrasing the tweet from @halperinko – as testers we should achieve system-wide knowledge, as opposed to the in-dept knowledge required from the developers or the product marketing guys.

Is it black and white?

This time quoting “Cokolwiek” who commented on one of my latest posts, “Not everything is black and white”. Meaning there is no standard to define how technical should a tester be on every project and product.
Like in many other situations, the best answer to how technical do 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???

Definitely 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 (as @diamontip wrote on his blog) 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 been 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.

http://qablog.practitest.com/2011/12/stop-being-a-non-technical-tester/