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.

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!

(*Images by Twitter, Pixomar, digitalart and Teerapun)

, ,

  • 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!

  • Bj Rollison

    Outstanding post Joel.

  • Raja

    enjoyed it ūüôā¬†

  • Zvi

    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.

  • Jean Spector

    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.

    Regards,
    Jean Spector

  • Lubna Hosny

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

  • halperinko

    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)

    Kobi 

  • 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.

  • Anonymous

    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!

  • Anonymous

    Thanks Bj!

  • Anonymous

    Hey Raja,

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

    Cheers,

    -joel

  • Anonymous

    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.

  • Anonymous

    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 ūüôā

  • Anonymous

    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.

  • Anonymous

    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.

  • Anonymous

    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!

    -joel

  • RaghavendarreddyP

    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.

  • Anonymous

    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.

    Thanks!

    -joel

  • Hi all, I agree with this topic if the tester is not technical one, how he can determine if a process just hang or deadlocked or CPU hog is there? A technical tester must have strong automation skills but hard bug analysis too. How can he determine if the application crashed by out of memory or GDI leak for example? This is why top software companies hires very technical people.

  • Dmusil

    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) )

  • Jennifer Punitharaj

    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

  • Anonymous

    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!

  • Questioner

    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.

  • joelmonte

    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).

  • Chaitrali

    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.

  • 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”.

    Cheers,

    -joel

Shares