(Once again, I’ll start in English, as this is a response to something originating by a non-hebrew speaking writer. Specifically, a short discussion in the comments to this post)
Up until now, I had twice commented on James Bach’s blog, and in both cases I had a short but very interesting discussion.or at least, interesting for me.
Putting aside the admirable amount of time and effort he invests in reviewing comments and responding to them quickly, I really like his care for using terms in a precise manner and trying to define them so they will be useful. One of the most important things I have learned in my university was that words are a thinking tool. Without having the proper word for something, it is harder to think about it, or even to see it. This way, when Roman Jakobson defined his six “functions of language” he has enabled a refined discussion about the interactions of these functions (for instance – can a “speech instance” have more than one functions? can it be phatic and referential at the same time? What would be a pure manifestation of the poetic function? A whole new set of questions that can now be discussed concisely and with everyone knowing more or less what everybody else are talking about.
Following the discussion I found two terms that I don’t really like, one should be used is a slightly different meaning then the one used By Bach, and the other should just be abolished and never heard again.
The first is the term “Toolsmith”. The second is “Technical tester”.
The notion that some testers are good at creating tools is a really important one, since it gives visibility to yet one other type of activity done by a tester. However, when talking about a toolsmith, something sounds to me a bit off-key. When I hear the word “toolsmith” my understanding is that this is someone whose profession is to create tools. And you know what? Even though I spend some of my time writing code, creating tools is not my profession. Let’s take an example from the movies, where we have two examples of people who make swords. The first one is Hatori Hanzo from kill bill, a master swordsmith with legendary skills, the other is Connor Macloed, the expert swordsmith who forges his sword (In the 3rd highlander movie). What was that? Connor Macloed isn’t a smith?But he creates a sword! He’s really knows stuff about sword making! At best, he’s a warrior who knows quite a bit of swordsmithing, and this is where I have a problem with “toolsmith”. Sure, as a tester who can code, I write tools that will help me – a script to do automatically and quickly what would otherwise take me a day of work, some automated regression checks, improvements to my test framework – you name it. But, even when I do all of that, I do it to improve my testing, since I’m a tester.
A toolsmith, on the other hand, is not a tester. A person whose main goal at work is to create tools is not a tester, even if these are test tools, even if this person does also some testing now and then.
During the discussion I used the term “artisan” as a replacement to toolsmith, and while I think it’s slightly better due to specialized manner attached to this term, in retrospect I think it suffers from the same problem of focusing on the product instead of the end goal. If someone feels they are benefiting from being called a toolsmith – let them have it, me? I’m sticking with tester.
The second term, on the other hand, is outright damaging. Calling coding testers “technical testers” implies that non-coding testers are not technical, and apart from being insulting to testers that don’t code, it is both incorrect and creating harmful misconceptions. Let’s start with why is this incorrect:
First, while we are used to think of coders as “technical people”, the two terms are not the same, and there can be someone who’s technical despite not knowing how to code. Business analysts should be technical even if they can’t code, since they will be those transforming the business requirements to technical requirements (I’m using business analysts, but I’ve heard this task being done by a wide array of roles – from product managers to architects), and if the business analysts are technical, what about the testers reviewing their work? or checking the design against their requirements? aren’t they technical as well?
Second – investigating bugs requires technical skills. Sure, not all bugs require deep investigation, but providing useful information in a bug report often requires digging into logs, minimizing a “how to reproduce” scenario, DB checks – all of these are technical skills.
Third – When retesting a fix, only poor testers would repeat the same scenario mindlessly and be done with it. Better testers understand the nature of the fix and do a quick analysis of what could if affect. Again – technical skills.
I can go on with this list of “things testers are doing and are technical” for at least a couple more points (translating between developers and business people and ask good questions at design meetings and to that you can add security testing and code-reviews as well), but I think you see where I’m going.
Now, to the damage part –
I claim that this damages the following areas:
– Reputation of the testing profession.
– Non-coding testers ability to perform their job.
– Basic skill-set and development of testers.
– Inappropriate compensation to non-coding testers.
The first point is clear to me, but I’ll try to explain it nevertheless: Testers work closely with developers. Most developers I know tend to appreciate “being technical” above many other traits when judging someone professionally. Why? Because they have a hard time talking with the non technical folks about what they do. When testers are by default “non-technical” (because all technical testers code), they will value less the non-coding testers, even without meaning it.
This, in turn, leads to the next point – Please raise a hand if someone ever told you “Don’t busy your pretty head with this” (or anything similar). I had this response several times (not from my developers), and it’s annoying as hell, and it hinders the tester ability to do their work. How can a tester perform better, when presented with “I’ve added an LRU cache”, or “I tweaked the infrastructure a bit and stuff should now work faster”? Sure, you can always ask for more details, but the person that can give it to you won’t do that if they are under the impression you won’t understand it.
Now, for the basic skill set and improvement path – I have no idea how is it in other places, but around me, there’s an assumption that anyone can do a non-technical job. Sure, not all of us are great at sales, but I can sure try and get a job at sales without having to prove anything – I might need experience for the high-level positions, but for entry level I need mainly to try. The same applies to testing – when someone asks “I want to get into high-tech, but don’t want \ can’t invest in learning, what should I try?” Probably the first answer will be “You can try QA”. Meaning – we get a lot of skill-less people trying to get in the profession, and with some of them being persistent enough – they find their way in.
Next thing you know – you have a bunch of under-skilled testers. But they will get better, won’t they? No, they will probably not. The same culture that has let them in, is letting them stay without developing their skills very much. The lack of widespread concepts to improve in is not creating enough pressure on them to invest much effort. So they stay dormant. If testing was considered a technical skill, it would help because people believe technical skills easy to measure and important to advance in. By blocking the way for unskilled juniors, the paradigm will change to push people to hone the skills differentiating them from all those that were left out.
And the last point is, again, obvious.
As a coding tester, my salary is comparable with developers that have the same level of experience. My initial salary was close to double of non-coding junior testers’ salary, and higher than that of some test managers. The value I brought to the company in my first year wasn’t anywhere near that of my colleagues that can’t code, but when one of them got fired due to personal issues, we couldn’t replace him since we were not hiring non-coders any more, and his salary wasn’t comparable to what was needed.
Sure, all of that isn’t only because testers are considered non-technical, and there are sure some not good enough testers out there that justify being called “non-technical”, but I believe testing is a technical profession (based on the skills required to perform tasks well), or at least, an “also technical” profession. And I also believe that the impression that it is not is contributing to the ill effects I mentioned above.
Oh, and while we’re at it – stop using “manual testers” as well, it’s almost as bad as non-technical, and it’s defining a tester by the one skill they don’t posses.