Saturday, August 20, 2011

Tester to testing is NOT like surgeon to surgery

I wrote a post earlier (quite some time ago). Today I realized I had comments on that post and other ones that I did not know of.

The main point that I was trying to write about is that some people may be right in saying you don't need testers - as in full time test specialist team members - in scrum teams, you just need testing - the skills in team members that don't identify as testers.

James Bach made a good point in saying he has not met any / many people who would make serious commitments towards learning the skills needed in testing other than those who identify themselves as testers. I've met some, but too few.

However, this post is about arguing the point he made I placed in title
"It could also be said that you don't need surgeons -- only surgery"
or the milder version of the same that Ru Cindrea, a respected colleague within Finland made that you don't need developers either, only development.

I would argue that testing to development is not quite the same thing as surgery. I mean that in the sense that surgeons are not in the information providing industry as testers are to developers and stakeholders, but are more self-contained. Perhaps there would be a second surgeon in surgery, that looks out to provide a service to the other, but without knowing much of surgeons life, I would still guess that person is called a surgeon too.

If there was no development, there would be little testing related to the development that was never done.

We need people trained in the skills of testing. Well trained. Both those who identify as developers and those who identify as testers. The essential difference to me is that it is hard to keep up with the skills of testing with the limited amount of hours available, let alone having to use half - or more - of my time on development skills.

I just don't want to go with the assumption that developers can't do testing, when I've witnessed in numbers more testers who can't test than developers. It may not matter what you're called.


  1. Apparently I need to practice my writing skills (or take more time in writing when I do), as I got a comment that I don't get my point across. Trying to emphasize it in short.

    1) You don't don't need testers, just testing. If possible to have skilled testing as part-time job (and it is in my experience), you don't need testers

    2) If tester is not skilled or willing and able to become skilled, most likely a scrum team is better of without that one, and spend time on building the skills on developers.

    3) Saying that 1) is comparable to "you don't need surgeons, just surgery" sounds one off, since without development there is no testing. I don't see the equally dependent companion to surgery. The whole role division is different.

  2. 1) You don't need someone named tester; you only need someone doing testing. Well, okay.

    2) "If a tester is not skilled or willing and able to become skilled, most likely a scrum team is better of without that one, and spend time on building the skills on developers." The first half of the sentence applies to anyone doing any work, right? If a programmer or business analyst or scrum master or documentor or graphic artist is not skilled or willing and able to become skilled, then the team is probably better off without them too, right? That is, teams tend to be better off with skilled people than unskilled people. Probably true.

    The last part of the sentence is a non-sequitur. If the team needs testing skills, there are at least three ways to get it: a) train the programmers in testing; b) train business analysts (or other people on the team); c) outsource. I'm sure you can come up with more.

    3) To me, James' point is not about the role; it's about assimilation bias. It's like saying that you don't need pilots for an airline flight, because it's really all commercial aviation, isn't it? A pilot is capable of attending to the passengers on his own, or we can train flight attendants to fly the plane. All those roles are just part of commercial aviation. So you don't need aviators; you just need aviation. That's true, too... but depending on what you want to accomplish (like maintenance, piloting, loading the plane, in-flight attendance) and how much of it and how well you want to do it, you might want to have people with that specific assignment. Or not; either way is fine, but either way they'll need skill.

    In fact, I was on such a flight in February--an island-hopper in Hawaii. It was a small plane, just 10 passengers on a 40-minute flight. I would have liked a drink while I was on the plan, but the pilot was the only airline employee on the plane. On a later flight, there were two pilots, but still no flight attendants. The pilots again took care of us well, and they gave us a safety lecture like flight attendants do, but there were other matters that they didn't get to (I was thirsty).

    Think of testers as technicians in the pathology lab. You could quite easily say, "We don't need pathology lab technicians. The process of figuring out what something is so we can decide whether to hack it out or leave it be? That's just part of surgery. Oh, it's called lab work, but we could get the surgeons to do it, so we don't really need those lab technicians. We can focus on building lab skills in the surgeons." Thus you don't need lab workers, only someone to do lab work.

    The difficulty is that you don't find many doctors who want to do the lab work on their own, because that's not where their centre of gravity is, and they're typically not as well trained in path lab work as the lab workers. Sure the doctors could do it, but are they interested in it, could they do it well, and do they want to do it?

    ---Michael B.

  3. I get James' point, but his point added with Ru's point "you don't need developers, just development" is what I tried writing on.

    I should add the points another one
    4) Acquiring and maintaining the testing skill takes time, and I'd consider if part-time is enough of time for what we need in testing. But that was what I thought I was writing a year back.

    But I agree, you described the roles around the surgeon that could match to developer vs. tester scenario. The disagreement is still with "are they interested in it, could they do it well and do they want to do it?" - I still believe they are, could and would. It still may take more time to learn than most developers can invest in the complex world.

  4. "-- Are they interested in it--" Are they? If not and you don't have testers, who does the testing? If you don't have testing skills who does the testing? Is is it just ignored due to lack of skills?

    Sure you can teach people to do stuff but the question is do they use what they have been taught? I was *teached* to speak Swedish, but I still don't know exactly how to speak it. Some girls on my Swedish class got way better results on tests but we still had the same teaching. I could be a Swdish experts *if I wanted to*... So the words "could", "if", etc. don't solve your problem. They MIGHT, but propably they don't. (The conditional heuristic - be wary of it...)

  5. Pekka: Have you seen the results of any of the successful Finnish Agile shops that don't have testers? If you get that quality out of no testing skills, I'd be surprised. Knowing some of these teams, they may be more quality aware than most testers who claim to nurture their skills.

    Perhaps I should not worry for the community, those who don't know and can't will just wither away. Not everyone is so outspoken, thus I will continue to worry. But lifting all testers above others is not the way I want to go.

  6. From my point of view Maaret is bringing up the problem in testers' attitudes and motivation, thus being generally worried about the skill level of testers in Finland. I think what needs done is the good testers be more assertive with fellow testers and in the community, do more coaching on motivating testers around us to their work and train, train, train for making the skills better. IMO, any tester, and especially all "the dedicated" testers can do something about this.
    another tester Pekka

  7. I have two concerns:
    1) testers who are happy with "just executing what others planned" and getting them back to real life
    2) teams that refuse to include good testers because not knowing what they miss allows the illusion that the skill is in place in the team

    And I believe just about every place I've been (and that's quite many) are essentially different so that it is impossible to write anything general, the contextual differences coming essentially from people, beliefs and skills may turn the world upside down.

    For the issue 1 in this comment, it is more often than not the surroundings - need to address the managers to do a difference. Thus it may not be feasible for a dedicated tester to reach the audience needed.

  8. I generally agree with what you are saying and I definitely know that developers can and most of time are willing and interested in doing testing.

    I think my main problem with saying that "you don't need testers, only testing" is that it *somehow* implies that 'anyone' can do testing, while the minute you change it to "you don't need developers, only development", the argument that code doesn't just create itself immediately comes up.

  9. Certainly there are limitations what testers can do in this context within their normal tester role. It's most often like working beneath the surface and maybe sometimes noticing a situation where there actually is a possibility to influence managers.. And that's something which requires awareness and skills, in observation and most of all, in talking about testing.

    But after all, I believe there is a lot testers can do in their daily tester roles with developers and other testers to create more appreciation and understanding to testing. Testers who are "happy with executing what others have planned" may be easily brought "into testing". Of course easy is relative/contextual and depends greatly on things like the people's beliefs and backgrounds.