Monday, October 25, 2010

Testers Need Not Apply


The fault may be mine and the job description I have posted, but I am not seeing the candidates I would like to see for my agile testing team.  This is causing me to slow down and question what I want.

A few minutes of brainstorming and here is what I came up with (“up with which I came,” if you prefer):  
  • A question asker who makes no assumptions about requirements or how to test
  • A project manager who can herd developers
  • A negotiator adept at talking to gunmen in hostage situations and skilled at getting programmers to do his bidding
  • A questioner of authority
  • A nerd repelled by bureaucracy and unnecessary process
  • A get-it-done-no-matter-whose-job-it-is person who can own a project
  • A curious technician who knows how to build testing tools
  • A voracious reader and active learner who takes responsibility for professional skills and knowledge
  • A programmer and an automator (automation skill are not the same as programmer skills, but that is another story)
  • A lovable pain in the ass who looks for practical solutions, not the “process” that is always done
  • An optimist who has not been beaten down by bad experiences in conventional “QA” organizations

After reading a pile of resumes and talking with a number of candidates, I am not finding what I am looking for (or “that for which I am looking,” jerk).   I don’t think that my expectations are unreasonably high.  I want great, smart investigators who don’t know “no.”  Too many testers have been taught to limit themselves and to have low expectations.  Too many testers don’t take pride in professional knowledge and growth.

I am beginning to think that maybe I don’t want a “tester.”  Many testers have to unlearn what they know about testing before they can learn to be true agile testers.  They have to unlearn limits. That unlearning may not be worth the effort. 

Hopefully, I will find the right agile tester from the testing community, but I may look for a smart recent graduate – someone I can train and never let have low expectations.  

In testing, we often create our own limits. I hate that.

6 comments:

  1. Over on Twitter, I opined that I had some problems with some of the items in this post. Let's go through them one by one.

    The title is "Testers Need Not Apply". I think most of your complaints are rooted in the fact that testers, real testers, haven't been applying—or that some of the attributes that you've listed are at odds with each other, and with what testing really means—to me, at least.

    "A question asker who makes no assumptions about requirements or how to test."

    Makes no assumptions? How do you do that? Human beings, it seems to me, are incapable of avoiding assumptions. I think you're more likely seeking someone who, to the best of his or her ability, tries to be aware of assumptions—his own, or others'—, and who tries to question or falsify them in order to expose the risk associated with the unwarranted or dangerous ones.

    A project manager who can herd developers.

    Here, I'd argue that you're confusing testing with project management, and project management with herding. Testers are, like anyone else, managers of their own work, and they provide valuable information to those who manage other work—programmers, managers, and the rest of the team. But there's a profound difference between providing information and managing. If you want someone to be the overall manager of a project, there's a role for that: it's called "project manager". And it comes with real authority, and a real project manager's salary.

    A negotiator adept at talking to gunmen in hostage situations and skilled at getting programmers to do his bidding.

    Yes, I know you're only joking. Ha ha. But as McLuhan (among many others) pointed out, every joke contains a seed of truth and a complaint. When testers and programmers disagree, I would argue that it's not really a good idea to turn it into a hostage-taking or negotiating session. Instead, it's a signal that there are different priorities and different perspectives in play. A tester who is not a product owner should not be trying (yes, even as a joke) to get the programmer to do his bidding.

    I would argue that it IS the role of a skilled tester to identify and contextualize whose values matter, what those values are, what aspects of the product threaten those value, and why those threats are plausible. But the skilled tester must also recognize that when it comes to product features or scope or design he or she is not the decision-maker any more than the programmer is. It's not our role as testers to insist on the product we want; it's to help the team achieve a comprehensive understanding of the product we're producing, so that the team and the product owner can make an informed decision on whether they're getting or they've got the product they want to deliver to their customers.

    More to come...

    ReplyDelete
  2. A programmer and an automator (automation skill are not the same as programmer skills, but that is another story)

    You're darned tootin'. And automation skills are not the same thing as testing skills. To me, core testing skills include critical thinking, scientific thinking, modeling, systems thinking. To me, automation skill would be one of those desired-not-required things for a tester, unless you have specific, critical shortcomings in that area. It's fabulous to have at least one testing toolsmith on a project, but a project that's dominated by them will often tend to focus on the tools, rather than the testing. I perceive that much of the fascination with tester-as-programmer stems from Agile's heritage; many of the loudest advocates of this extreme automation focus to testing are programmers or programmers-manqué. Usually, there are more than enough programmers on a project, and therefore more than enough people who think like programmers. A more common problem is a lack of diversity of people and thinking styles. In addition, being able to use tools is not the same thing as being a programmer; I'm glad you made that distinction.

    I'd like to point out that many of the other things you've listed are things that I agree with. I appreciate your intolerance for waste; your impatience with "process" (you, and all those who talk about "process" really mean "process models", I'd say—and much harm comes from confusing process and process models, which often compromises the former in favour of the latter); your endorsement of curiosity and reading and questioning of authority. Those things are terrific, in my view. That's one of the reasons I'm perplexed by the points I've mentioned earlier above, which to me are inconsistent with the later ones.

    And I agree about this too. You don't want a "tester"; you want a tester. That is, you don't want someone who fakes it. But be careful: there's as much testing fakery involved in "Agile Testing" as there is in "testing".

    Some references that you might like to peruse:

    http://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/

    http://www.developsense.com/blog/2009/08/testing-vs-checking/

    http://www.developsense.com/blog/2009/11/merely-checking-or-merely-testing/

    http://www.satisfice.com/blog/archives/99

    http://www.satisfice.com/blog/archives/638

    Finally, thank you for the post and the opportunity to comment.

    Cheers,

    ---Michael B.

    ReplyDelete
    Replies
    1. Hi Michael,

      Thanks for feedback. I admit was a bit perplexed when I saw your Tweets this morning. I expected a negative reaction from a traditional QA (at least those that did not get accepted into our recruiting process), so I was caught off guard.

      After reading your comments (thanks, by the way, for sharing), I have a better understanding of your response. I categorize some of your comments (“question asker” and “negotiator” in particular) under “picking nits.” That’s okay. Not everything I write is elegant, and this post was the product of a few minutes of brainstorming.

      Your comments on tester as project manager don’t’ match up with what we do here. We typically don’t use project managers in conventional roles at the scrum level. Rather, our project teams are self organizing, and the project management is usually done by a programmer or tester, whoever has gained the most influence. We pride ourselves in adhering closely to the principles of agile development, and this is one of the areas where I think we shine. I think it is fair to expect that a good agile tester on self-organizing team would be expected to be a great project manager.

      Your comment that a “project that's dominated by [toolsmiths] will often tend to focus on the tools, rather than the testing” is interesting. There are times when we run that risk. Working hard to find the right people who want to work in the test space is important. It helps to keep them focused on what is important as a tester and still enables them to be technically challenged.

      I am still working through the post and comments on Sapient processes (http://www.satisfice.com/blog/archives/99). Interesting reading. Good stuff. As I think about agile testing from a technical perspective, I think about two things: 1) tool building (including automated tests and that sort of thing) and 2) identifying and acting on all the reasonable ways that a good software tester can be leveraged.

      Thanks for keeping me on my toes.

      Delete
  3. Thank you for continuing the conversation.

    Want someone to pick nits? I can help with that. :)

    I'm not "a QA" (I don't know what QA stands for). I am a tester. But in any case calling someone a QA rings badly for me, probably because QA usually stands for "quality assurance" and the macro expansion results in "a quality assurance". (On the other hand, if QA DOES stand for Question Asker, I could actually go for that; see just below. :) )

    You seem to believe I objected to "question asker". Not so; that's good, in my view. It's the "no assumptions" part that I'm concerned with, just as I wrote in that passage. Making assumptions is as natural and necessary as breathing. I don't think this is nit-picking. To me, it's an important aspect of the way we frame our thinking about testing work.

    In a similar way, it's not "negotiator" that I object to; it's characterizing the negotiations in terms of hostage-taking, rather than, say, knowledge-crunching sessions, as Eric Evans puts it in his book Domain Driven Design. Another model is the kind of negotiation that happens in theatre rehearsals, as Austin and Devin talk about in Artful Making.

    With respect to giving your testers technical challenges, again I agree. My concern is with a narrow notion of technical work such that it refers only to programming or tool use. There are other technical domains, too: statistics, user interaction and human factors, data modeling, visualization, and so forth. Test design itself involves the application of techniques, some of which focus on programming and tools, and some of which don't. That doesn't make them any less technical.

    Apropos of your remarks on who gets de facto project management authority, I've just finished reading a book by Bent Flyvberg (Making Social Science Matter, which is about the role of power in social organizations and institutions. He had some very interesting things to say about issues entwined with your "depending who has the most influence". As a tester and an extrovert (and as a pedant, but for all the right reasons in my mind (and yes, that's a jibe at myself)), I want to be very careful about how I cultivate and achieve and exercise influence.

    Politics and emotions are hugely important in so-called "technical" development projects. There's nothing in your response or your about those politics, and that's not a big deal. What's a much bigger deal, it seems to me, is that very little talk about power and politics from Agilists. I think that's a prominent elephant in the room. People don't like to acknowledge it much, because it's a discomfiting kind of topic. But relutance to talk about it doesn't make it go away. My post linked above (http://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/) is an attempt to start an instance of discussion. Meanwhile, to me, it's very hard to be a tester and a project manager simultaneously. When I was a project manager, I found it easy to let my testing perspective falter; it was easy to fool myself. My point is not that a tester can't be a good project manager, but that it's hard to be the manager and be self-critical in a tester-ish way about yourself at the same time. When I'm a project manager, I am not a tester, and I need testers.

    Cheers,

    ---Michael B.

    ReplyDelete
    Replies
    1. Hi Michael, I work with Bob Jones. Before I write anything about this topic, can I tell you how truly appreciative I am about that fact that you took some time away from your busy schedule to give us some food for thought? We work in a small suburb called Kennett Square in PA and it's not often that we get to hear folks question us or debate with us about our implementation of Agile testing. Thank you very much, Michael!

      If I may point out, I think while writing this comment, if I am not mistaken, you made the assumption that Bob is calling you a traditional QA whereas he was just doing the opposite. This is a perfect example of what we mean by "question-asker". You made an assumption (as is human) but at least you made it obvious what your assumptions are. This entire discussion on this blog post has been captured for posterity but in our case, our discussions on the projects are very verbal and not captured so it would not work for us if we made assumptions and internalized them.

      Talking about assumptions, my own assumption, after reading your comments is we may have come across to you as somebody that wants to bully the rest of the project team. Our teams are very self organized and self regulating, our testers would not stand a chance to gain influence if we tried to be overly aggressive or attempted to lord over our agile project teams.

      Again, thank you very much for providing feedback. Like I said on twitter, Would love to buy you a drink when you are in Philly.

      Delete
  4. This comment has been removed by the author.

    ReplyDelete