Saturday, September 28, 2013

I Am A Software Tester

What I Do

I test software.

I learn how the software behaves and report on it.

I do not break software.

I exercise software and look to address the questions of stakeholders around how the software works.

I consider formal "Requirements Documents" to be information points for my investigation, nothing more.

When the software is being developed or modified, I look to the reason why it is being developed or modified, not merely how.

I look for the need the software is intended to fill and the wish the software is intended to address.

I look for the value people wish and hope the software to bring.

When the value and business purpose, as stated by the stakeholders and sponsors of the effort, is not being achieved I stand up and say so.

When the "Documented Requirements" are not in alignment with the value and business purpose, as stated by the stakeholders and sponsors of the effort, I stand up and say so.

I say these things openly, in public, not in a closed room.

I look to see how I can contribute to the effort beyond exercising software.

I look to see how I can support the BAs in representing the wishes and desires of the stakeholders and sponsors of the effort,the customers on whose behalf we are working.

I evaluate and exercise stated requirements and search out those that are presumed.

I look to see how I can support the designers and developers in clarifying what is meant when documents are unclear.

I evaluate and exercise designs.

I try hard to smooth the effort and move work without sudden jerks, fits and starts.

I try to build consensus in the team over the behavior of the software and how it relates to the stated intention and purpose.

I try to speak for the customer when no one else does so.

I do not assure anything.

I challenge assurances.

I challenge assumptions.

I challenge presumptions.

I challenge the status quo.

I challenge my role on the project.

If I can not add value on a project in any way, I say so and withdraw when that is the best thing from the project, the group and the larger organization.

I help raise people up.

I help colleagues see what is possible, not merely what is now.

I help them be better at their craft when they express a desire to be better.

I strive to become better at my own craft and work to learn more.

I am not a master; I am an apprentice constantly learning my trade.

If people look to me for assistance, I will give it if it is in my power to assist them.

If people do not want assistance, I do not impose my assistance on them.
I try to make things better.

I try to make software better.

I try to make communication better.

I try to make myself better.

I think.

I am a software tester.


  1. I love how well you've encapsulated actions and mindsets, it's like having a camera right into a great tester's head. Definitely a post I'll get back to!

    Thanks Pete and well done!

    1. Thanks for the comment. Not sure about the "great tester's head" bit, more of a rant to say what I do in response to people's ill-informed and ill-intentioned comments.

  2. Only one thing I disagree on. You ARE a master, and I have tremendous respect for you Pete Walen! Keep speaking....I'm listening!

  3. The role of a tester is rilliantly articulated here.

  4. This is a perfect description of what testers should be. And it's unfortunate that this perspective is constantly challenged by project managers, developers and sometimes even the business owners themselves. Mike L is right, you are a master!

    1. Indeed - it is challenged all the time. It is our challenge to push forward on what good testing involves. Anyone notice there is no mention of "test cases"? Thanks for the comment.

  5. This is really the first approximation of the testing (or tester’s) manifesto, rather like the agile manifesto. You have something fundamental here.

    1. Thanks for that. It wasn't my intention to write a manifest. It is simply what I do. It seems to have struck a chord with some folks.

  6. Pete, great piece, I try to do most of what you say and I am truly inspired by your post. I look forward to meeting you at AgileTestingDays at the end of October, are you staying for the 4 days?
    I wrote about testers shapes and what i think is the ideal one, I would be very interested in knowing your opinion on it.

    1. Hi Augusto - Yes, I'll be at ATD for the duration. :) I'd love to talk with you. I'd be happy to check out your blog. Thanks for the kind words.

    2. Ok, so I'll track you down in Berlin and we can have a chat and maybe a beer or two (on me)

  7. I ask questions, I look for answers.

    I identify risks, I mitigate risks.

    I go to places where no one has gone before.

    Just a few of my thoughts, but the list you created is AWESOME

    1. Excellent! I had hoped people would find holes! Thanks!

  8. Great post.. Only one thing: I add to myself - Learn how it is developed.. Because, It can tell you features and dig more on it to get advantages and disadvantages which can help in testing.

    1. Yes! Extremely good point! Understanding how the software is developed gives us more areas to consider and explore. Thanks!

  9. quite a comprehensive list of tester activities

    1. I'm not sure about "comprehensive" - Simple fact is I was asked by a manager "What do you do?" Apparently people found value in it. Thanks for the comment!

  10. This comment has been removed by a blog administrator.