Friday, January 25, 2013

Fear-driven testing community?

I'm about to spend a weekend on writing a book with a crowd of about 20 people on Agile - in Finnish. Thus it seems appropriate that just today I've been watching long discussions about worries that some context-driven testing community members seem to be showing towards agile.

We're talking about our fears. Fear of dismissing testing narrowly as checking, fear of testing as something that will happen in the team without details or skills, and fear for losing our right to identify as testers - people who intentionally study testing and choose to invest so much time on that that it is not possible to invest as much on something else.

The fear for our identity may go as far as saying that programmers wouldn't study critical thinking or recognizing threats to value in the products they work on. Claiming that is the core of 'being a tester'. To me, they are just to examples of skills areas that help demystify testing in agile teams. I see development as process of transforming ideas to code. Ideas we build together with diversified skills are stronger. Code we evaluate together, seeking to check they are as we intended and to explore ways we never intended. And explain what we know and don't.

I realize agile can be scary. It can be scary that we're asked to stop owning things like critical thinking and recognizing threats to value, and allow everyone in the team do those. It can be scary that there just isn't as much of what we do now to do in the future. That we don't get to do all that by ourselves. And that we need to find rationales of what makes us special in depth of skills and concurrent actions instead of just labeling it all "testing".

To me, testing includes checking and exploring. Checking helps with being able to focus on other things than the ones we're capable of checking with automation. A lot of the stuff in rapid testing has had a twist of "emergency testing" to it. Agile may remove the emergency by making it continuous.

If an agile team does testing badly as a team effort and has their feedback loop of continuously delivering to real customers / end users in place, the team will learn to test the hard way. I've seen organizations retrain  a new generation of testers this way as their existing testers wouldn't fit in the teams, through a series of failed deliveries they could have avoided leveraging the existing tester's skills. This unfit was as much due to testers not making compromises on their role as it was on the idea of "everyone must code".

Some years back, in an organization transforming to agile, we were asked "would you go back". In groups that would, two stuck out: testers and project managers. The testers felt we were losing something. But instead of going back, we looked at what we feel we lost - respect for our skills, the feeling of being needed and important. And we addressed the fear instead of allowing that to drive us to something that wasn't right for the product business.




 




4 comments:

  1. Some interesting thoughts - some refreshing ideas.

    My comments

    >>> Fear of dismissing testing narrowly as checking, fear of testing as something that will happen in the team without details or skills, and fear for losing our right to identify as testers - people who intentionally study testing and choose to invest so much time on that that it is not possible to invest as much on something else.

    First of all, as a context driven testing community member - let me tell you. It's not about fear at all. Regardless of what view Agile community continues to keep about testing - testers who continue to invest time in becoming excellent testers will strive and succeed. We are not scared about how Agile folks deal with us. I am not sure what do you mean by "intentionally study testing" - it is like asking a lawyer "intentionally practice law". It is our profession and if we don't study and be good at it - who else will?

    >>>The fear for our identity may go as far as saying that programmers wouldn't study critical thinking or recognizing threats to value in the products they work on. Claiming that is the core of 'being a tester'.

    Would you object this? "critical thinking" is core of testing? Few programmers might be serious about "critical thinking" - but majority has many other things to worry about. Please point me to writings of such programmers/developers - I am yet see them - especially in Agile community.

    >>> To me, they are just to examples of skills areas that help demystify testing in agile teams. I see development as process of transforming ideas to code. Ideas we build together with diversified skills are stronger. Code we evaluate together, seeking to check they are as we intended and to explore ways we never intended. And explain what we know and don't.

    This is typical Agile community's response to testing. You folks somehow want to wrap testing as something that every one does and identify with. Then talk about some high level items like business value, continuous delivery, team work, diverse skills. Testing as a distinct skill is now spread too thin. Why there is a tendency to generalize testing and spread it around so that it is everywhere in some pockets - pretend as though it is no big deal.


    Shrini

    ReplyDelete
    Replies
    1. Shrini,

      this is not a typical Agile community response to testing. Should you know me at all, you'd know I've been connected with the context-driven ideals longer than I care to remember. I'm a tester. I don't only work as a tester, I also build most of my hobbies around testing. Skilled, exploratory testing is my thing. I've spent a great deal of my work life learning about the differences of contexts, and have come to value teams over individuals. I feel successful when removing me from a team does not make the team lose its capabilities in testing and delivering great software.

      Some agilists dismiss me for wanting to be a tester. You dismiss me for wanting to collaborate and demystify what I do when I test. Rethink this, please.

      I'm not "agile community". I'm a context-driven tester who has worked in many different contexts and finds that for businesses what agile brings makes sense. And instead of fighting for "this is my special skill, it's already spread too thin", we should continue to develop our special skills in testing, isolate and explain them and share as much as we can with every role - not just testers.

      While you argue for your importance and right to keep testing to yourself and your likes, I'm acting on my importance in a team where others are as capable as I am. And get better every day. Change the world from within instead of shouting from the bushes.

      Delete
  2. >>> Some agilists dismiss me for wanting to be a tester. You dismiss me for wanting to collaborate and demystify what I do when I test. Rethink this, please.

    If agilists dismiss you for wanting to be a tester - that is now a TYPICAL agilist's response. They want testing role to go away in the name of team work.

    Do not get me wrong - I am not dismissing you for collaborating in a team AT ALL. While I am for collaboration, what I am against is this wrapping testing as something that every one does and in the process spreading it too thin.

    You can demystify what you do as testing - but you should not be saying "look this is what I do as testing - you can do to. this is not any special thing". I am not suggesting you to do testing as doing magic (keeping method secret) but do it as though you have spent or willing to spend your life on it to learn and becoming good at it.

    Many in context driven - (James, Michael and others) do teach their methods of testing - in a sense they demystify testing. But they constantly take pride in learning about testing and investing time to be an excellent tester (not an excellent generalist). These folks probably will not say "guys here is the recipe for doing testing - I taught this to you folks now. You all can do testing, no big deal - make others as capable of doing testing as you. Problem solved. None needs to think about testing anymore - everyone can do it anyway"

    Are you getting my point of argument here?

    Shrini

    ReplyDelete
  3. One way I identify myself and other context driven testing folks is - our mission is to be a good tester and provide value to the project through our skills of providing information that is useful in a projects context.

    As a context driven TESTER - I do not chase making others of my team to be as better tester than myself (some of them might even hate testing). My goal is not to make myself a replaceable unit so that my absence does not hurt over all testing horse power required.

    I recognize that not everyone in the team would be interested to become an excellent tester, not everyone on team team has life long pursuit to learn skills required for a good tester. We would be fooling ourselves if we think we can make that happen by this "whole team" thinking.


    in your response - you did not comment on my view on "fear".

    We are not scared that what if developers catch up with us on critical thinking. There might be some developers who do. But that is not what they would pursue as professional goal. But we, testers do.

    Shrini

    ReplyDelete