Types of testers in software industry.

Reading Time: 7 minutes

I was thinking recently about my career and how it evolved as well as what types of testers I met in the software domain. And I figured out that I can split them in several groups based on what their “philosophy of testing” is looking like. Now, I don’t want to label anyone, this are just my personal observations and to be honest I’ve walked through some of these roles in my experience. So, we could consider this as my personal categorization of types of testers in the software world.

The automation Iron Man.

Automating stuff during testing was always hot topic and was always the big thing in software testing. Everyone strives to learn automation and write automated tests, or more accurately “checks”, if we consider the definition of James Bach and Michael Bolton. The thing is many people tend to think, that once you’re automating stuff, there’s no going back to manual. What’s manual by definition anyway, what a dumb classification?! Should I always use my hands or something? What if I test a voice recognition module, is that called voice-ual testing?

So, many people fall into this manual vs. automation pitfall and once they start writing code or studying it, they switch off their brains just like they were put into this Iron Man’s suit and there’s nothing organic in them anymore, no thinking, no feelings , no hunch, NOTHING. Everything has to be algorithmic, has to be scripted and with the correct layer of abstraction, everything has to be in exact sequence. I will talk about the opposite behaviour, too, but this specific mindset might narrow testers analytical point of view, which will be fatal for any self-respecting testing person. In order to support my thoughts I would like to present to you this article by Alister Scott, where  I think he was making the same point. I have some reserves to his radical “should not” view-point, but I think his concerns were the same as mine.

So what are the pros and cons of being the robotester?

Pros:

• Deeper understanding of the code, mastering developer skills.
• Improve software domain knowledge(protocols, technologies, platforms).
• More attractive and trendy, improved salary rates.

Cons:

• Can easily lose the idea of testing and write shallow and simple checks.
• Lose the ability to explore and adapt the testing process to observations.

 The shy manual tester.

On the other hand we have this guy. The shy manual tester is a person that sticks with the manual nonsense and appears to think that nothing should be automated until you are “automated tester” or if the task is so painful, that you are obliged to cry for help. The shy manual tester believes he don’t have to write code, he either thinks it’s not his job or he doesn’t like it or is just too lazy for it. He thinks learning the inner workings of the application is far too complicated and he could handle it by just having a “high level” view on the product, system or whatever he’s testing. And this is wrong. Technical knowledge is essential in our craft and no you can’t do a good job without it. What this type testers do, is to hide behind the “test cases” routine and follow “the best practices” which isn’t really productive from testing perspective.

Pros:

• I don’t see any pros, in my opinion all the “manual thing” should be left in history.

Cons:

• Might easier learn that their task is dumb and exhaustive and move to more combined and contextual approaches to testing
• Might trapped in the circle of manual tester – not technical – don’t have to learn to code – can’t learn to code because not technical enough.
• It is generally counter-progressive approach to think that manual labour will overcome automated. Human intelligence will kick machines’ asses for much longer, but not brute force manual efforts.

The certification guru.

These guys are really amusing me with their overconfident talking about standards and certification,  SDLC, best practices and all the tons of documentation. In fact I love the way James Christie called their process of work – document driven testing. In other words – certification and ISTQB are “The Matrix” of software testing. And you need to unplug.

The saddest thing is, this is the typical picture in the software testing industry. Testers tend to think that certified means knowledgeable, that their certification gurus are know-it-alls and they in fact wish they could be like them. They don’t count, of course, that those certification are not based on nothing else but the opinion of a single corporation that aims to gain profit, rather than educating the community, or that those certificates are easily obtained by people who have no relative experience as testers by simply memorizing information.

One of the most annoying things about the certification guru is his confidence in processes, procedures and documentation. According to him, everything is documented, test plan should be based on design requirements, testing should split in a defined amount of phases and so on and so on. Now, this all sounds really cool, but it has nothing to do with reality. All this represents is an ideal vision of the software testing process. May be in a perfect world, that would work. In real life you don’t always get specifications or design requirements, sometimes you don’t get even get a documentation for the thing you are testing and you have to practically reverse engineer it. Having this said, the above faith in processes and documentation will only succeed in a perfectly sterile lab environment, which is exactly the opposite of what testing aims to recreate.

Pros:

• Really easy to find a job, the more papers he gains the more “knowledgeable” he seems to be.
• He will have a fancy title in front of his name, something like Super Uber Ninja Guru Rock star Oracle Testing engineer.
• He doesn’t have to ever think about anything, because he will have ready document, instruction or procedure for it.

Cons:

• Once he is out of certificates, you are out of development.
• He is totally irrelevant to the testing process in general, not to mention he has no practical value.
• Certificates wont keep his job, yes he might find job easily, but he will be just like any other – replaceable.

The developer wannabe.

This guy might sometimes mix with the automation Iron Man or move between the two. It is a typical case – a guy wants to code, doesn’t succeed as a developer and decides to become a tester. He believes if he spends a couple of years testing, he will do some automation, learn some processes, make some networking and will be able to conquer the dev position again. Why I think like that? I used to be that guy. When I first got a job as a tester I looked at it as s trampoline to a developer position. Later I discovered it’s just not for me. I mean there is guys who are successful doing it and probably they are right, but from testing perspective a person like that is just harmful for the team. My personal decision was to stick with testing, because I find it much more exciting and challenging than the development.

The two things simply don’t mix. Experience in the testing position doesn’t mean experience in software development, nor the opposite. And in fact, if you fail to be a dev it doesn’t automatically mean you are good for a tester. It simply means you have to work harder. It’s a comparison of attitude, specific skill sets, specific knowledge etc. So my advice is, if you want to be a developer, go for it, don’t fool yourself with getting another job “just to stick around” dev people. Software testing isn’t a second quality of job in IT, it’s just different and there’s a mass delusion that it’s easy and everyone could  do it.

Pros:

• Pretty much the same as robotester – improved knowledge over technology, tools, protocols, etc.
• Definitely more technical view-point on testing – something that’s often missing in testers.
• If he succeeds in his pursuit of dev position, he will definitely benefit from this.

Cons:

• He will add no value to the testing team if he’s only looking how to switch positions.
• Won’t learn anything from testing, even how to write better unit tests. As I said, the two don’t mix.
• This sort of attitude might harm his credibility, making him look like opportunist.

The rebellion.

I see more often people fighting against the status quo, arguing with the habits, looking for progress. And we don’t talk about just being stubborn and be anti-everything, but it is in the essence of our job to at least question everything. And when we find something wrong with it, to ask for a change. This is the rebellion. I probably could categorize myself inhere. It’s just because I hate standardization, I hate being part of the mass or being considered replaceable. My creed is – you either stand out of the crowd or you don’t exist.

I am far from considering that this is the best philosophy in testing, but I am sure it’s the right direction to go right now, because our community really needs to build resistance against old methodologies and rusty terminology. We need to create our “punk rock” of software testing and present rational alternative of the factory testing school.

Pros:

• He’s emphasizing on the human element in testing, rather than depending on dogma and process or tools.
• He’s the new type of tester, that I see emerging.
• To have that attitude towards testing is more useful for his career as tester, making him valuable is a professional, rather than just another “clicking monkey”.

Cons:

• Starting from the last above – business doesn’t like irreplaceable people, that’s why factory approach is so popular.
• He will have issues when speaking his mind freely in front of non-testers or in front of factory driven testers. Nobody likes revolutionary changes, unless he they gain direct benefits out of it.
• All that knowledge is hard to channel, he might pretty easily get lost in all the information or have a hard time to decide what’s right vs. what’s wrong.

What are your types of testers.

As stated above, I am not trying to stereotype anyone or anything, but these are my observations on the testing industry. I would very mush like to see what your thoughts are, or if I miss something.

Thanks for reading. Don’t forget to share like and comment. 😉

Honourable mentions:

I’ve red similar topic once before, but I don’t remember which one, so here’s a list of similar topics:

Seven kinds of testers – James Bach

Tester types – Rob Lambert

Software test professionals – Five tester personality types – Catherine Powell