We are not Testers

Cirilo Wortel

In 2009 Steward Reid predicted that within 10 years 70% of all software development would be done with some form of Agile methodology.  Due to the growing need for ‘’hands’’ this would result in having to employ also the less qualified testers on these projects. The first point he made is absolutely valid, the second point is only valid looking at it as a commercial opportunity (you don’t need hands if you work with qualified people), maybe he only said it to comfort the people who fear loosing their jobs because of this shift. It’s obvious that now Agile is becoming main stream there is a growing demand for qualified testers.I believe there has always been a shortage of qualified testers and it’s hard to decide who’s good and who’s not through the forrest of mediocrity.
Compared to traditional approaches, agile software development just demands that bit extra from a tester. Not only does it require great testing skills, which in my honest opinion all testers should have regardless the methodology, but it also requires a tester to have above average technical skills.

Agile software development without test automation is something I do not believe in. Effectively this means that testers should be capable to automate their work, or are capable of letting the team to do it for them (which requires authority and persuasion if the team is not fully committed). Furthermore an agile tester should also be a good requirements engineer. An important part of his/her work consists of helping out the product owner or business analysts to deliver useful requirements that actually add business value, with valid examples of the expected (mis)behavior. All these skills require above average communication skills, domain knowledge and responsibility.

One of the observations I make is that in a sense Reid’s prediction will become reality, not so much caused by the demand for less qualified testers, but by the inability of companies to select the right people. Some consultancy firms eagerly jump into this hole by certifying their test consultants, thus giving them credibility on the market. Big corporates have no choice but to hire these now certified Agile Testers.

I don’t really have an answer to this movement, but I do think we should start to invest in training and coaching these people to get the most out of it. This way at least the people that have potential will float to the surface. Hopefully in the process the rotten apples will fall from the tree.

The whole idea is in a way discomforting.
Last night I was contemplating the subject with a colleague and it suddenly struck me... I AM NOT A TESTER!

The exact same thing has been said numerous times before, for instance during the keynote by Lisa Crispin and Janet Gregory at the 2011 Agile Testing Days. More recently the title of our last FAT-NL event (named after the presentation by the evenings speaker Jamie Dobson) was “None of you are testers”. Although I got the message behind it, the true essence just now revealed itself to me.

When trying to recruit new testers I hardly ever seem to find anyone matching the entry criteria. But it’s clear now, all this time we have been trying to fish in the wrong pond (as a Dutch saying goes). Let’s build a new honorable guild, call ourselves Executable Specification Craftsmen or Automated Requirements Engineers and have pride in whatever we achieve.

 

 

If coincidentally you happen to fit the above profile, please apply for a job at www.werkenbijxebia.nl.

Comments (10)

  1. Frank Vega - Reply

    April 16, 2012 at 1:22 am

    Hi Cirilo,

    Great post! Back in 2006-07 time frame (if not a bit earlier) the teams I worked on started using the term "executable requirements" exclusively in our shop (and quit calling them tests, as this is much more accurate). Automated/Executable Requirements Engineers is a more accurate description of the role you describe as well. I also think companies need to recognize that paying people with these skills and abilities significantly less than others on the cross-functional lean-agile teams doesn't help the situation. Then again, there are some out there too who insist on being called and identified as "testers." Agile software development demands a bit extra from all on the team, as we're all responsible for quality!

    Take care,
    Frank

  2. Vivek - Reply

    April 16, 2012 at 7:06 am

    I would say in Agile there is no role for a pure tester or a developer. I as a developer spend a lot of time writing automated acceptance tests and making them a part of the build so that we can test the BAU functionality again and again. My test team starts their automation from the day we start our development. We meet in the end of a sprint and their code tests our code.

    So to be a "Executable Specification Craftsmen" or "Automated Requirements Engineer" you need to be a developer 🙂 and a very smart one at that.

    • Cirilo Wortel - Reply

      April 16, 2012 at 4:05 pm

      Hi Vivek, thanks for your response. I don't think it's really necessary to have only developers testing, I do think the end result should be automated tests that run continuously. It doesn't really matter who does the automation, it's just a task that needs to be done.

      I do think there is something specific to the mindset of testers. In my experience developers are often limited in their thinking by technical constraints, where as testers are primarily focusing on logic and business value. People that match both skillsets are perfect, but even more rare than just good testers or good developers.

      • Simon - Reply

        April 17, 2012 at 8:05 am

        Agreed that it just needs to be done; but surely there is benefit of a second person writing tests from the spec who is note the first person who wrote the functionality. Even if that would mean developers double up and write the code for one story and the tests for a second story to test each others work meets the requirements.

        • Cirilo Wortel - Reply

          April 18, 2012 at 9:42 am

          Any effort to improve and retain quality is benificial. This means that not only the technical aspects are tested, but also functionality and business value is assessed.

  3. Stefan Hendriks - Reply

    April 16, 2012 at 8:03 am

    Perhaps the reason is that we want to divide up these responsibilities, while in essense we all want the same thing. We all want to automate (developers, testers alike). We all want to make the client/customer happy. And we want to deliver high quality products. Perhaps the term "Software Craftsmanship" would fitt the bill, and simply no-one is capable enough to do everything.

    Perhaps this should be sought in values, rather than skills?

    In contrary to Vivek, my experience with testers for now is that they write scripts, but they are not automated. They are not always created parralel to the code by Developers. And they do not write code. As he says, you need to be a tester with developer skills. I haven't worked with such testers yet.

    • Cirilo Wortel - Reply

      April 16, 2012 at 10:55 pm

      Hi Stefan, I see (saw) myself as a functional tester, I don't have a technical background. But in my opinion it's necessary to automate test and I see this is a team effort. This means that you need commitment from everyone involved. It takes time to do automation right and it might seem wasteful at times, but in the end it boosts quality. Besides it enables the team to retain speed, without having to fear refactoring.
      What I notice is that inexperienced teams are often not committed enough to help each other out when needed, often developers don't see the value of testing and leave leave it entirely up to the testers, that lack the technical skills. Testers are often not experienced enough to ask for efficient solutions. We should stop dividing the responsibility. Put automated test scripts in the DoD and don't qualify anything as Done if it's not properly tested.

  4. Ondrej Medek - Reply

    April 16, 2012 at 8:06 am

    I am a tester, say it laud,
    I am a tester, say it proud!

    I always fight against these "low" and "high" job titles? It's ridiculous, the job title does not matter, what matter is what you do and how you do it (and the salary, of course). In my point of view, a good tester must have a broad view of the problem, she must have insight in the problem analysis, user interface design. So a good tester is worth two average coders (aka developers).

    The title "tester" is a good title, period.

    • Cirilo Wortel - Reply

      April 16, 2012 at 3:49 pm

      Hi Ondrej, thank you for your reply. I totally agree it has nothing to do with a title, it's more as Stefan suggests, it's all about values and shared responsibility.

      I used the naming thing to illustrate that most testers don't fit the profile. I have always been proud of being a tester, what bothers me is that people that are not qualified pollute the market. This is actually something that has always been an issue, but now becomes painfully clear in agile development.

  5. Five Blogs – 18 April 2012 « 5blogs - Reply

    April 18, 2012 at 8:24 am

    [...] We are not Testers Written by: Cirilo Wortel [...]

Add a Comment