I spent a very pleasant day today at the Agile Testing and BDD Exchange at SkillsMatter in London today. In general the day was a good one, slightly more focus on tools this year, I have to admit to preferring the more structure and approach based talks that were involved last year.
One of the subjects that caused some twitter discussion after the event came about through one of the presenters questioning whether testers were 'technical' enough to be comfortable with working with the programming syntaxes being presented.
To highlight the issue I'll rewind to an earlier talk in the day when Dave Evans of SQS and Erik Stenman presented an experience report on agile testing at Klarna. Erik discussed the fact that Klarna's online retail transaction processing software was written in Erlang. Erik and asked the audience how many were programmers, and how many of those were familiar with Erlang. There was no sense of condescension, it was simply a show of hands of those familiar with that language.
Compare this to the later talk in which a similar question was asked of testers, yet it was framed not in the context of familiarity with the programming language in question, but in more general terms of how 'technical' the testing contingent were (i'm not sure if this was the exact term used but it was the implication, and was the term carried into the subsequent twitter discussions)
As Mike Scott of SQS put it:-
Why do people assume testers are not technical. Lets stop this now. Please don't patronise us.
Mike makes a valid point, but still (probably for brevity in a tweet) uses the 'technical' categorisation. Lanette Creamer provided an excellent response:-
I agree. Also, what is "technical"? It means different things to different people.
This couldn't be more true. The chap sat next to me was Jim, a tester from my team at RainStor. He did not put his hand up. Now I've seen this guy read and understand SQL queries longer than some novels and find faults with them through visual static analysis. Of course he is a technical tester. In fact the 'developers' in our team, all competent C/C++ programmers, treat Jim's SQL knowledge with something approaching reverence. He is an invaluable member of our team as his "technical" database skills are fundamental to the database domain in which we operate. His lack of familiarity with object oriented programming language syntaxes, however, was sufficient for him to not show his hand to be counted as one of the 'technical' testers in the room.
Given the accepted wisdom of having a multi-skilled team, isn't it about time we also accepted the value of multi-skilled testers, and that 'technical' is a categorisation that falls significantly short in that context. When discussing the skills of developers we do not try to impose such broad labels, we talk in a positive sense about the specific skills that individual developers possess. When discussing the various programming, scripting, analysis, database, operating system and other skills that testers may possess, it would be nice if the same courtesy was extended.
Copyright (c) Adam Knight 2009-2010
about me
Adam Knight
A Sisyphean Task is one that involves solving the same problem repeatedly - which is a familiar feeling to anyone involved in creating software. I write about Software Product Management, Innovation, User and Customer Experience, Software Quality and generally tackling the Sisyphean Tasks we all face in trying to create great software products.
Blog Archive
Popular Posts
-
Software Product management isn’t about creating products... For any product folks reading this who have just spat out their coffee, allo... -
I’ve worked in a couple of organisations that were coming from a background of a services based delivery model and trying to move to being... -
I have recently found myself with an interesting insight into the software product talent market, both from the position of an employer loo...
Creative Commons
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
I've had developers who couldn't envision any tests outside of the "Happy Path" who I've had to explain grouping things by halves to narrow down a problem to who considered testers who didn't code every day to be "non-technical". I consider any coder without basic troubleshooting skills to be lacking basic skills required to do their job. Coding skill is one aspect of technical ability, but in the absence of experience, common sense, and higher level thinking skills, it is useless to be technical. Another skill that is vital is the ability to explain complex ideas in a concise and understandable way. How often does someone refuse to do so and instead mock others and say they aren't "technical enough" to understand. If you can't explain it to a child, perhaps you don't understand it well enough yourself.
Another thing that worries me about the word "technical" is that I took a 360 degree evaluation. The closer the person was to my work, the higher they rated my technical ability. Because I'm silly and don't appear visually technical, people who don't know better assume I'm not technical. When I hear the term technical used, it is often to dismiss people, and not to include them in discussions. I'd like to see it used with a bit more care.
Yep, it's just patronising - should I call devs "non-technical" if they just don't happen to know about the performance benefits of the link register on an ARM processor? Or is it meant to work like this xkcd cartoon: http://xkcd.com/385/
There used to be a plan to categorize the testers where i worked -- all would be testers, AND there'd be another group for the "technical testers". While I distinguish the skill sets that the latter group have over the former, the labeling implies the former aren't "technical". Which wasn't and shouldn't be the case.
Lanette, cracking point on coding being just one aspect of technical ability. I am lucky enough to work with some great coders at present. In the past, however, I have suffered working with individuals who could code well, but lacked the interpersonal skills to work well with others, resulting in an adversarial relationship with testing and management alike.
For a team to be successful they need a matrix of skills. In my experience the testers can make up the shortfall in areas such as domain knowledge, analytical skills and other non-programmatical skills, which may or may not be 'technical', but are certainly essential to a successful project.
Post a Comment