I know that this question will more than likely cause more of this ever ongoing debate and that the question itself is full of holes (stemming answers such as: “enough to who”, or “it depends”), but this is a thought that I wanted to get out there…
One of my previous blogs was about the “amalgamated role of the modern tester“, which was about how testers need to perform multiple diverse tasks in their role, such as Manual testing, Automated testing, Security testing, Performance testing and other various tasks. For each of these tasks, there is an element of technical knowledge required. Especially for performing Automation, Security and Performance testing. But is there a level of suitability for the technical knowledge that’s required? I believe that the answer for the “enough” part of the question does depend on each individual and how interested they are in the subject, but I also believe that there is a level of knowledge that can be reached that allows you to be competent to do the tasks that require specific technical knowledge.
Using myself as an example: My own, current role requires me to primarily perform manual system testing. One of my secondary roles is to write automated scripts using Watir/Ruby. I self-tought myself how to write the Watir scripts by reading books, using online material and through trial and error (a great free e-book for learning ruby is “Why’s Poignant Guide to Ruby” for anyone interested!). I found a method that works for me and fits in well with the organisation, but I do not consider myself to be a programmer in any way at all – I barely understand developer talk, so my technical knowledge in scripting is definitely not the highest level – I still have a long way to go, which I will continue on my path of learning, but I’m currently at a level where it’s comfortable for me to be able to write decent automated test scripts…
But, should our technical knowledge be as proficient as developers to be able to write automation scripts? I don’t think we need to be as technical as developers, but we need to be at a level where we are confident in writing and debugging the scripts on our own. That’s not to say that we shouldn’t be striving to achieve the same level of technical knowledge as a developer! There would be definite benefits at being at that level, such as being able to know of easier and more efficient ways to write your code…
Personally, I’ve always liked the motto: “Every day you learn something new is not a day wasted” (although I cannot remember where I heard that saying and who actually said it), and I think it’s important that we do invest our spare time learning new skills. Reaching an acceptable level to be able to do the job in hand shouldn’t stop us from continuing to strengthen our technical knowledge on the subject.
So we know being technical is required for certain testing tasks (Automation, Security, etc), but what if we look at it from a different angle… If a tester’s role is purely Manual testing, is there any need to be technically minded? If your main focus is to plan and perform system testing from a user’s perspective, this involves testing the system’s UI and performing actions which represent how the user plans to use the system. So in a sense, technical knowledge is not really required for this… Or is it??
When we are investigating bugs, it can be very useful knowing how to read source code to find out further information about the defect which can be supplied to the developers in the bug logs. You can discover more useful information from the source code too, such as page load times… It’s also helpful if we are able to browse the servers to view any “back-end” log files for information too. And if we think about databases, there might be a situation when you need to query the database for more information, or set up test data, so it’d be useful to be proficient in writing basic SQL statements, for example.
What do you think? Is it essential for a tester to know how to read code or know the depths of the back-end infrastructure? Does it really matter if we are “technical” or not? Is it a case where we are trying to overload ourselves? After all, if we were as technical as developers, would we just all be developers?
Dan Ashby 
I think you are pretty much on the mark. A manual tester primarily is a domain expert first and foremost. If they can find bugs (technical or not) then that is their job forfilled. However there are some cases where being technical can make a testers job much easier to do. Every tester should at least know how to query a Database and get stack traces to save developers time. Anything else is probably a bonus.
As for automation engineering, IMO a tester should be aiming to be highly proficient in the language and tools to the point of being 90% of the understanding of a developer. The missing 10% is about writing performant code, which we don’t really care about as a tester but high flexibility is very very important as well as design. Without that as the automation effort scales up things will become incredibly difficult to extend and maintain to the point that it might be abandoned.
LikeLike
Hey Roland!
I’m curious as to why you say 90%? and why not just get to the 100% level or why is 80% not suitable? 🙂
I’m thinking in terms of the developers that I know, where they have studied programming at uni (but were coding even before that), are knowledgeable in multiple programming languages, etc… Should testers need to know how to code using C++, VB, Java, Ruby, etc? And if that IS the case, then would that not push testers into developer roles?
Could it be the case that if testers were even 80-90% of the technical level of a developer, then the company that they work for might be tempted to utilise that person as a developer primarily?
LikeLike
Nice post. I am an automation engineer myself and my responsibility is only to prepare and execute automation scripts. Manual testing is not my responsibility. For this reason I don’t have the domain knowledge of my Product. I just automate the given manual test cases. Do you think this approach helps me to progress in the field of testing? or I can only be an automation engineer in the future too?
LikeLike
Thanks for the comment Joinsaad!
I think the discussion applies to your situation also, where if you move into a role that does require domain knowledge, or if you simply want to get more involved in the manual testing side of things in your current role, then it would be essential that you expand your skills into this area. But again, How much knowledge is enough? do you learn enough that gets you by in that domain, or should you become as complient in that domain as the experts of that domain? 🙂
LikeLike
Well I think it depends (sorry, I couldn’t resist). If you are capable of performing your job without needing technical skills, and if you’re happy in that place then no, you probably don’t need to learn more.
However, if you want to improve as a tester, and if you want to have the freedom to move around a bit. Maybe increase your job security or make it just a little easier to find a new job then yes you probably do want to learn some technical skills.
Even before writing automated scripts and tests I find the biggest gain is being able to speak to developers in their own language (or at least understand what they are telling you). You can discover an awful lot about the system, and about risks just by talking to developers. So for that reason alone I’ll be doing everything I can to keep learning.
LikeLike
One of the reasons talk about “technical” testing tends to go pear-shaped is that “technical” doesn’t have a meaning outside of a particular context.
Let’s go outside the field for a moment. In mountaineering, “technical climbing” refers to “Climbing involving a rope and some means of protection, as opposed to scrambling or glacier travel.” In the stock market, “technical analysis” refers to looking at trends in pricing and volume of trades without particular reference to information about the company itself. In theatre, a “technical rehearsal” is one that involves the lighting, sound, and stage machinery. In software testing, “technical” means… what?
Familiarity with the workings of computers?
Familiarity with programming?
The ability to program?
The ability to use tools?
LikeLike
(continued; it’s apparently all too easy to hit Send)
The ability to use statistical analysis?
The technical knowledge associated with the domain in which the program works?
The ability to use a computer?
My point is that it’s pretty fruitless to discuss the importance “technical knowledge” without reference to a particular kind of technical knowledge, and its value in a particular context.
There’s the same class of issue with “manual” testing. “Manual” means “by hand”. I use my brain—not my hands—to test so “manual” testing is, for me, an empty concept. Do programmers do manual programming? Do managers do manual managing? Do documentation people do manual documenting?
Finally, to Joinsaad above, I have something very, very important to say. I understood this intuitively for a long time, but Jerry Weinberg put it into succinct words for me: “Never try to automate a process you don’t understand.”
LikeLike
You make a good point. Many people have different definitions and meanings as to what “technical” means in relation to being a “technical” tester. This is a very similar situation to most terminology in the software testing industry – I once spoke to a customer who was adamant that he wanted to be at the forefront of “stress” testing, but what he really meant was being involved in the user acceptance testing phase…
Terminology can be difficult. Especially when communication is key in our line of work!
But in terms of what I mean when I talk about being a “technical” tester – I would define “technical” as the ability to be able to look at the back end of the product, such as the code, the database, detailed log files that have lots of technical jargon, etc. Or even being able to write code in order to help you better your testing!
When I initially began my career as a tester (at junior level), I had no exposure to this at all. My job was to simply use/play/manipulate the products from their front ends, specifically to use it from a user’s perspective, so I didnt look at source code at all, or query any databases. I didnt have these skills at the time.
Through time though, as I moved into roles where I have been the sole tester, I’ve picked up these skills through being exposed to them by working so closely with developers (although I know I still have a lot more to learn), and I’ve come to realise how useful they are in aiding me with performing my testing.
This is what I mean by “technical” – having the ability to do these various “behind the scene” tasks that do require some knowledge of coding or scripting.
LikeLike
Additionally, I also dont like the term “manual testing”. The first time I heard someone say that they performed “manual testing”, I thought they meant that they tested user manuals… 🙂
All types of software testing techniques requires the tester to perform actions at a computer, or on a device manually…
LikeLike
Another aspect is why this focus on how testers should have all these skills? There’s not enough time in the world to become an expert in them all. Focus on what you enjoy doing and be good at that.
In addition to this, isn’t it important to understand what can be achieved to help you do your job faster and better?
Instead of going through a head banging exercise of writing up a script to analyse log files, why not ask a developer to help you out? I’d guess they could do it tons quicker than you. They learn about testing and what you need, you probably learn something along the way too.
LikeLike
Hey Rosie! Thanks for the comment.
You make a good point! I guess in my own experience, the majority of my time as a tester has been as the sole tester in the organisation, so I’ve had to kind of be a “jack of all testing trades” by performing testing as well as writing automated scripts, doing performance testing and other non functional testing methods.
I guess I have actually opted on many occasions to get help from the developers to perform tasks that need to be carried out quickly as it is more convenient, but I don’t see it as being feasible to always ask them to perform the technical tasks, especially if these tasks are frequent and necessary, such as writing a SQL statement to query a database. I’d imagine that the developers would quickly get annoyed as being side tracked from their own work.
I guess learning skills that are relevant to the requirements of the tasks involved in the job is key. If you dont need to know how to write SQL statements, then there isn’t a need to study SQL…
LikeLike
I don’t think it needs to be a case of getting others to do the work and becoming annoyed with you, perhaps it’s more of developing a culture of sharing ideas and knowledge.
Imagine posting something out to an internal emailing list, saying: “I’m thinking of doing this, like this, using this and that. What do you think?” Sounds funny when I say it like that, but you might be surprised at what you get back. What’s the worst that could happen?
This also is starting to remind me of a current discussion on STC – when is a tester really a tester? http://www.softwaretestingclub.com/forum/topics/when-is-a-tester-really-a-tester
LikeLike
Thats a good point Rosie!
It is very important to utilise other people’s skills and seeking their knowledge through some sort of knowledge sharing scheme (be it emails or a fortnightly discussion group, or anything else along those lines) would be a great idea!
Thanks for the link! The discussion is really interesting. The role of a tester is definitely evolving to include other tasks. I dont think this is a bad thing though, as most of the other tasks that are being taken on are actually very helpful for us testers, be it: taking on some BA tasks which help us to get involved in the processes earlier, knowing how to read/write code to be able to test efficiently and even throw together some useful testing tools to make things easier, etc.
LikeLike
I agree. That’s how I get work done. You need to be able to work with the tools, resources, and people around you. We have to jump from project to project so quickly and do such varied tasks that I think some of the most important skills are analytical and communication. That sounds soft, but I think it’s actually a surprisingly rare and valuable skill set to have.
LikeLike
I totally agree with you. Communication is an vitally important skill that any tester needs to have!
It’s so important to be able to communicate effectively with other project members, and to build up a good relationship with them so that they will be happy to help you.
LikeLike
Thanks for the great post, Dan. Being a automated tester, I was always confused with the same question. I found some of the answers in your post. In my case, we work in ‘out-side in’ developemt (Behaviour Driven Development) envirnoment which is something different than general role of Agile Tester. With my experience, I have written one post here http://www.eurostarconferences.com/blog/2012/11/19/top-tips-for-the-bdd-tester
Now I am much confortable with setting up test framework, installing/writtng utilities to help testing and also comfortable with Unix/Linux but I still need to find some times from developer to help me make my tests better. I always need to make some changes and re-work on the tests I written before as per developers suggestions. Do you thing tester-developer collaboration time should be in the estimation? some devs thinks it’s waste of time to spend with testers? Have you came across such situation where developers are too busy and you stuck or waiting for them hours and hours ?
LikeLike
Hey Shashikant!
I dont think its a waste of time for developers to spend some time with testers. I think its very useful and both sides will learn from it!
I’m not sure about including that time in a cost estimation for a customer though… should the client or customer be payin g for the time for you to learn from a developer?
One way that I’ve tackled the problem in getting a developer to help me, is to build up a good rapport with the developers that I work with. Build a friendship. Help them with any challanges that they have and do small things that makes their day a bit easier. If your making yourself a coffee, ask the developers if they would like one too.
Little things like this work – you’ll find that the developers will take the time to help you better your work and processes too!
LikeLike
As systems become more complex, I find that testers are expected to increasingly know and understand the underlying architecture and databases. Unfortunately, I can’t remember the last time anyone thought to provide training to testers for this. Sadly, the prevailing underlying assumption is that “anyone can test.” leaving those of us who work as testers and want to excel to self-train as Dan has chosen to do.
LikeLike
Hi Crispyfriedsoftwaretester!
That’s a great point! There aren’t any training courses for learning technical skills relating to testing. It seems like there would be a market for this…
Fortunately, there is a lot of useful material out there does enable us to self learn. One such document is the “SQL for Testers” document, which was created by the Bearded Tester (which can be found here: http://beardedtester.wordpress.com/2012/11/13/sql-for-testers/ ).
LikeLike
Thanks for having this discussion.
It’s something I’ve thought about a lot myself. I come from a non-technical background, I’m not a developer and don’t have formal training in any technical field. Everything I’ve learned is on the job, and I don’t feel like that’s ever been a liability. I’ve done varied training since then in testing (ISTQB, Just In Time, etc) and it’s largely been helpful, but none of it is “developer” or very domain specific.
I do a lot of work through the UI and understanding the user world. I thrive with context driven, exploratory style testing, and I think that it gives me the flexibility I need to do my job really well. I feel like, as you suggested, testers are expected to know a little bit about everything. Each project I switch to has its own unique set of technologies, requirements, and so forth, and I could never master them all. We have to be able to learn on our feet, we can’t be expected to know every programming language.
I feel like a lot of the pressure for testers to have development experience is coming from job ads. I do feel like, looking at job ads, I’d want some serious technical chops before shopping the job market anymore… it seems like just about every ad is asking for development or coding experience. On a day to day basis though, I never find I’m required to do much more than some selenium or sql scripts.
Maybe I’m totally off base, but it feels like my job as a tester requires a very general and flexible tool set, yet a lot of jobs are advertising for testers with very specific development and technical backgrounds. Most test training seems to focus on flexible and effective, not the nitty gritty of development work.
LikeLike
Thanks for the comment Gloken!
I come from the same situation, where I have never really had a technical background. I always thought of myself as having no technical skills at all, but I’ve realised that I do have a little bit of technical knowledge (I know how to write SQL statements to query a database and check or update data, I know how to write Watir automated scripts, I read log files, I read the source code regularly for extra information (such as page load times, etc). These might be minimal “technical” skills, but they certainly help make my testing more effective and are enough for what’s required.
It looks like you have some technical skills too, as you mentioned that you can write Selenium scripts and SQL statements too, and thats “enough” to do the role that your in right now!
Roles within different organisations will require different skills for sure – I’ve worked in roles that didnt want me writing SQL scripts – they purely wanted me to test from the systems front end, and other roles that had a complete seperate team that wrote the automated scripts, so those skills werent needed. So there is definitely a level of “enough-ness” that you can reach to effectively do the job in the role that you are in.
I also agree with what you mentioned about job postings. I think there are too many recruiters that simply like to add buzz words like “dev skills” and “ISEB” to their posting to juice it up a bit, without them fully understanding the role that they are advertising for. Thats a pain…
LikeLike