–Edit–
This would have been better had it been called something towards “Where are the technically curious testers” as Anna Baik pointed out. The wording is not perfect.
//Edit//
Over the years I have worked with a whole range of testers, both functional and technical, who have shown different levels of comfort with the technology under test. Some were good, some were great and others I simply never want to work with ever again. The latter ones, to me, are a problem we are currently facing in software testing. There seem to be too many software testers with a lack of understanding how software is actually built, how the internals of a program work.
I have never understood how one can be working in technology, or to be more specific in information technology and not have at least a base grip on how things you are supposed to test work? Even when you are purely focussed on functional testing, I really do not understand how you can not grasp the basics this entire industry is based on.
How come that even now, when it is becoming more and more clear that software testing is an important specialisation within the IT industry we still see a lot of testers with no technical knowledge what so ever in this industry? I realize that historically there was the idea that “anyone can be a software tester”. I am just not convinced that statement still holds true.
Take for example a building inspector, that is also a tester of sorts, no? He verifies whether all the rules have been followed of proper architecture, the design has been implemented as promised etc. Imagine you are having your own house constructed and this building inspector comes by. You put your hopes on this person to validate that your house is what you want it to be: warm, safe and as you requested.
This building inspector, upon arriving, grabs his excel sheet with the requirements for the house and checks the ones he can verify, without needing any knowledge of architecture or constructing a house for that matter. He then gives you this checklist and tells you he has functionally covered all things of your house.
Considering that you live in an area with lots of snowfall in winter you ask this person whether the roof can manage with a load of snow on it in winter and the heating will not collapse under the strain of having to heat the entire house in a snow-storm.
He says: I don’t know, I am not an architect nor a construction worker, I am merely the building inspector. I just go through this list of things I need to check, why would I know anything about building a roof for a house or what the heating can take? You should probably ask the construction workers what they think.
Would this give you faith in his verdict that the house is indeed what you wanted?
I believe not, yet this is a practice that i see happening fairly often in software testing. So where does it still go wrong in software testing? How come there is still this tendency to believe there is no need for understanding software when you test it?
How often do you see the same bug coming by when testing an application, once you see a bug more than once, in a very similar form, you should be able to come up with the idea that there might be an underlying issue going on. Instead what I often see is that for every occurrence a new bug is created in the bugtracker. To understand that there quite likely is one underlying problem, the tester doesn’t need to know how to program, you should however have a basic idea of how a program is (or should be) built up and if you are not certain whether it indeed might be one and the same issue in the code, how about talking to the developer?
When exchanging ideas and thoughts with other testers on twitter and forums etc I quite often see an amazing lack of knowledge in this area. To make things even worse, a fair share of testers seems to have a degree (bachelor or master) in computer science yet have no clue what, for example, a regular expression is. Is it just me, or is this indeed a worrying thing? When reading through the Computer Science curriculum of an average university here in the Netherlands, I do see all kinds of interesting subjects and descriptions that would lead me to believe basic programming is part of what you get taught, however when talking to the graduates that end up in software testing I see nothing of that knowledge.
Where are the technically strong testers? The ones that can have a discussion with developers about how the structure of a program was setup, who can tell a developer that the SQL query he wrote is extremely inefficient? I know I see some of them online, these are the testers I enjoy following on twitter and on blogs, but there must be more than these happy and noisy few. Where are they hiding? In my experience there are not enough of them, at least not in the Netherlands.
— Edit–
There is a nice article dealing with similar questions and frustrations on testnieuws.nl: http://www.testnieuws.nl/2011/06/06/tester-praat-ook-eens-met-een-ontwikkelaar/ (sorry, it is in Dutch, if you do want to attempt have a look at the google-translated version)
–Edit 03/11/2011 —
Really nice to read Elisabeth Hendrikson’s article on a similar subject, but from a different point of view: http://testobsessed.com/blog/2010/10/20/testers-code/
I am sad to see though that there are people commenting on her article and are calling QTP and especially Selenium basically record/playback tools. If you have ever used either you know that QTP is a hell of a lot more than just record playback and Selenium is clearly NOT a record playback tool (unless you mean the Selenium IDE rather than the entire toolset of Selenium.
20 thoughts on “Where are the technically inclined testers?”
Leave a comment
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Technical Software Testing 
Cynical Answer #1: They are all working at MS or Google as SDETs
( which leads to the other flavour of blog post – ‘where are all the non-coding testers?’ )
Cynical Answer #2: If the industry doesn’t value them then technical testers go off and become devs and get more money
You might also like to define what you mean by ‘technical’ – see Adam Knights blog post
http://www.a-sisyphean-task.com/2010/11/dont-call-me-technical.html
It’s discussed a lot – see this big post on the STC ( one of several )
http://www.softwaretestingclub.com/forum/topics/751045:Topic:34704
Fair enough point. I indeed did not define what I mean by technical.
I do hope that between the lines it is somewhat visible what i meant though: technically inclined to me, in this context would be to have some feeling with how software is built up, what an inheritance model might look like. Basically the things I expect someone to know when having studied some form of Computer Sciences.
In the context of Adam’s post technical might be the wrong wording indeed. I do not necessarily mean the coding testers, I mean testers with a feeling for software. Indeed like Adam’s example: who understand at least part of what goes around in the software industry. I regularly see (have seen) testers who come in the IT industry with little or no knowledge of software and merely based on the fact that they managed to pass some certification test can call themselves a tester.
A tester should, in my opinion at least, be capable of maintaining a discussion with a developer about how an issue might be a problem not just for the end user, but also for the software itself. A tester should be able to come up with some (pseudo) code explaining things to a developer.
This is the type of tester I miss.
Hi Martin,
Nice post. As you can tell from Phil’s kind link I dislike the concept of the “technical” tester, when we do not try to label other IT fields with such a generic label (whoever heard of a technical programmer?). I would refer to the capabilities that you describe here as simply testing skills. Irrespective of the background I believe that testers should work to gain an understanding of how software fits together and develop skills appropriately. A tester does not necessarily need to understand the static design of a piece of software in terms of code, however I do feel that any professional tester should be able to examine how that software interacts with its environment. This necessitates an understanding of how software operates and ways to measure this. Given that I consider these to be fundamental testing skills, rather than the preserve of the technical tester, I would personally ask not where the technical testers are, but rather where the skilled testers are.
Adam, I indeed read your post (after I posted mine) and in general I agree with you. The term technical tester to me seems indeed as alien as a technical software engineer or a technical system administrator.
Testers indeed should work to gain an understanding of how software fits together, however quite a large group of testers I have worked with and even work with now, not only lack this knowledge, they also seem to lack the curiousity and flexibility of mind to pick up even the rudimentary ideas of how software might work behind the user interface.
My question is not where are the technical testers, my question (and frustration) is that I currently am missing testers who have even a bit of an inclination towards technical stuff. In fact they are close to being proud that they lack technical skills.
This creates a problem in interacting with software developers (or, to be careful with terminology, those who write the code), and thus drives quite some testers in my current environment to simply not talk to developers, but rather send in a bug report.
In short, I believe we are in total agreement of what a tester, in our view, should have as a base skill set. Challange for me as a test consultant right now, is to work with testers with a (huge) gap in their skill set, and to make things worse, quite some of them do not seem to have the capacity to build up this fundamental skill set.
Thanks, this clarification makes more sense to me. If you’d originally written “where are the technically curious testers?”, I would have understood your point sooner – testers who just aren’t fundamentally curious don’t strike me as worthy of the name “tester”.
I’ve worked with many testers who did not have a technical background at all, but were insatiably curious about all aspects, technical and non-technical, of the product we were working on. I’ve also worked with testers who had an extremely impressive technical background but were entirely lacking in that crucial curiosity – unsurprisingly, the former type were way likelier to be found deep in discussion with a developer, and far likelier to raise issues due to what they’d learned from their discussions.
Given a choice between a mum of three with no technical background and no higher academic qualifications, and a guy with a BSc and MSc in Computing – I’ve seen developers give WAY more credibility to the mum’s bug reports – because she was far smarter, far more curious, picked up technical explanations quickly, and was unafraid to challenge developers and stand her ground in a discussion (one dev told me “I LOVE arguing with her, and please don’t tell her this, but half the time she’s right and I’m wrong”). The other guy – got eyerolls from the devs.
What concerns me when we frame lack of fundamental testing ability as lack of technical ability, is that if you filter for a degree in Comp Sci, you filter her out, and him in.
Anna,
thanks for the proper wording! When I was writing this post I was ranting somewhat and had an issue coming up with a proper title, so it turned out to be the somewhat wrongly chosen one that you see here now. I am actually half tempted to change the title, but I won’t. 🙂
I have exactly similar experiences as you describe, where a person with a wonderfully big degree shows no aptitude or indeed curiosity for the technical side and where the non-educated person I ran into by accident indeed showed a lot more interest and more understanding for the basics.
When hiring in the past I have generally not taken the original education into consideration for anything other than learning capabilities and I do hope other hiring managers have experienced that indeed is the only thing you should use it for.
For my next post I will try to be a bit less emotional and annoyed and a bit more rational in the way I use the words 🙂
Thanks!
I can ensure you that we have the same situation with front-end developers. So it’s pretty common problem for super-speed growing area which software (web) development is. 80/20 you know. That’s why from my point of view education program is the solution, but it’s hard to keep people, who grows fast. Anyway that’s another topic.
Martijn,
Your statement of “I realize that historically there was the idea that “anyone can be a software tester”. I am just not convinced that statement still holds true.” is close, but not close enough. That statement has never been true in my book. I’ve always considered myself a ‘technical’ tester type. I have some background in software development (classes in college and outside of it, started off as a programmer (C on PC) doing maintenance work) and switched over to testing because I saw it as a niche specialty I was good at.
I’ve been doing testing for over 20 years and I too at times just shake my head at people both inside and outside of the testing realm who think you don’t have to have any technical knowledge (basic programming and technology) to do testing. Having the ability to ‘talk’ in the same ‘language’ as the developer is a key skill to have. It would be the same as me trying to hold a discussion with you in Dutch (which I don’t speak and I assume you do). If we both speak in English then we have a common language, thus we can communicate effectively. I did a presentation at STPCon 2010 regarding this. Drop me a message if you would like a copy of the PowerPoint.
Regards,
Jim Hazen
Jim, the way my statement about history is meant is mainly about the way a lot of people in technology have perceived it and unfortunately I still see.
Please do point me to the deck, I am always eager to read new things, especially from conferences I wish I’d been at.
Martijn,
What is your email address? I’ll send it to you.
Jim
Normally people go to QA because they did not succeed as developers(cruel reality), which should not happen. QA folks should be devs that enjoy testing software, creating test tools, exercise systems to find bugs, load issues, performance issues etcetera etcetera.
So, find yourself a bunch of good developers, give them good salary and show the the testing world. That’s when you can expect miracles 😉
Unfortunate use of the term normally in my opinion. It indeed happens, but in my experience is far from normal. I do agree with your description of things testers should be busy with.
I came into testing more or less straight out of university having completed a Forensic Computing degree (Computer science with a forensic bias) with a sandwich year in industry. Like many testers, I fell into QA kind of accidentally but upon discovering it, realised I had a passion for testing and have developed a career accordingly. Unfortunately, beyond basic Java and C, have no development/coding experience to draw upon.
I don’t shy away from technical testing however – I’ve recently completed a functional project with a large Oracle11g/SQL element to the testing, and am currently engaged in web-performance/load and ReST api testing using JMeter amongst other tools. What I do recognise however, is that the QA role typically requires many more “soft”, than “technical” skills. For example, a “typical” tester might find themselves engaged in the activities below:
[1] gathers requirements
[2] examine design documentation
[3] talk to users, analysts, architects, developers about the system under production
[4] document concerns/bugs from design
[5] design tests to prove product does[n’t] work*
[6] implements test framework*
[7] executes tests*
[8] logs & manages issues
[9] reports on test metrics
I would assert that only 1/3rd of the above activities require a “technical” skillset {5, 6, 7} and that, at a stretch – ALL of the activities could be accomplished by a “non-technical” person with a good degree of “Curiosity” and/or the tenacity to ask questions and push for answers/results in respect of e.g. building a suitable framework to implement the kind of testing required for the system under test.
I believe that it is because the tester typically spends more of their time on analytical tasks, rather than technical ones that less of their time is devoted to building a technical skillset.
And with good reason – why would I choose to spend time building skills that may/may not be utilised on a regular basis? Surely if I know that 2/3rds of my skills are definitely going to be utilised on 100% of test projects, it makes more sense to develop those?
In addition – if as a tester I want to develop my technical skills – which ones do I develop – since most likely most projects will employ various languages, architectures, test tools, frameworks etc?
Simon,
The issue I have with some testers is their lack of curiosity about the technology under test. Or even the technology being used to test things (e.g. some general knowledge about how a tool exactly does what it does).
For example, we have used Visual Studio Webtester in my current assignment for a few things. At some point neither me nor my co-worker, understood what it was Webtester was trying to do and how it was trying to do that. The results somehow were not logical. The approach taken here was: oh, let’s make sure we do not see these results anymore, hide them by just de-selecting the reporting for this part. When we asked what on earth he then thought he was testing he said: well, the same thing, but now the results are green and make sense. There was no curiosity why VS came back with weird results. We decided to dig into the results a bit more anyway, and figured out that VS makes some assumptions and based on that does it’s own magic. That led us to try the same tests in JMeter, which gave logical results.
The curiosity that drove us to just dig into it and figure out what was going on in the test-framework should be a second nature to a tester. If a result is not logical, do not trust the result, but rather trust your instincts as a tester and dig into it and make sure that the results start making sense to you.
For this you do not need to learn any specific skills, you need to have a very healthy interest in what you are doing for a living.
I agree with you that if you want to develop your technical skills, it is close to impossible to decide which ones to develop. Thus far the best skill development I have done is just on the job learning. Being curious about what I am doing, wanting to understand the systems I have to work with and most importantly (for me at least) never be afraid to ask questions if you are not sure about something.
Which is almost exactly my point – by following this path of “curiosity” rather than technical-specialisation, one is unlikely to be considered “technical”, at least not in any meaningful sense.
This reminded me of another discussion on the STC – not just about testers being ‘technical’ but being curious/passive. Worth a re-read as there were some good points made
http://www.softwaretestingclub.com/forum/topics/are-some-testers-passive-and
The fact here in China is the tester job is treated as the stepping-stone to get a decent job in software industry for the people who is disqualified as a developer, they think testing is just simply playing with the application to test strictly according to the requirement document.
However, the existence of this phenomenon is due to the company would rather to pay less money on those non-technical testers to play like test machine. As the result, the importance of the testing is getting lower and lower, because they’re merely document interrupter (from requirement to test cases), case executor, bug re-tester.