Agile tester part 2, questions and answers

Warning: The opinions expressed in this post are mine only, please do not use them against any other group of people, but only against me, that is Augusto Evangelisti a.k.a. Gus.

After writing my most recent blog post “The Agile Tester, a Curious and Empathetic Animal” I received quite a lot of feedback for which I am very grateful. Feedback in the form of a conversation is the true fuel for learning and improvement.

To all of you that have mailed me, tweeted about my post, responded using the comments in my blog and talked to me face to face about it, thank you so much for helping me learn!

When i looked at the feedback I received, I saw 2 quite different trends. Looking closer I saw that the different feedback types came from different schools of thought.

Let me give you 2 examples for some context

This one from twitter

This one from one comment to my blog post

Michael Bolton: Something about this post troubles me, Gus. In order to test what was troubling me, I took the content and replaced each instance of “tester” with “programmer”. The result made perfect sense, of course, but it left me wondering: if I can replace “tester” with “programmer”, what distinguishes the tester from anyone else on the project? What is the special role, the particular set of activities, that the tester performs? Is there a difference between the programmer’s mindset and the tester’s mindset? What is the mission, the distinctive reason for having a tester on the team—whether that person has the title “tester” or something else? What is it that distinguishes testing work from all the other work? What testing-specific skills do testers bring to the table? What is testing?

I have answers of my own, of course. But I’m wondering what your answers might be.

I am using Lisa’s and Michael’s as examples of the feedback received because the former is a recognisable exponent of the agile testing community and the latter is a recognisable exponent of the context driven testing community. The other feedback that i received from people close to each of the 2 communities is extremely similar to theirs.

If a group of people finds troubling what the other group finds great, I smell something interesting and an opportunity for learning.

I’ll try answering Michael questions and look forward to his very own answers to learn something:

Question#1:  Something about this post troubles me, Gus. In order to test what was troubling me, I took the content and replaced each instance of “tester” with “programmer”. The result made perfect sense, of course, but it left me wondering: if I can replace “tester” with “programmer”, what distinguishes the tester from anyone else on the project? What is the special role, the particular set of activities, that the tester performs?

Michael, the distinction between different roles in agile teams is becoming more and more blurry. Agile teams value competencies more than roles. As an agile tester in my team I have core competencies that i use to support my team. These include but are not limited  to the ability to evaluate a product by learning about it through experimentation. I also use such competencies to coach and lead other members of my team that are not that strong in that area and help them grow towards an ideal form of generalising specialist. Finally I also perform tasks outside my main competency to support the team. In some cases I will need guidance from another member of the team whose core competency includes the ability of performing such task. I believe that this blurring of the roles increases agile team members accountability, in fact nobody in an agile team (developer, tester, business analyst, operations specialist, UX expert, et cetera) should ever say, “I’m X, doing Y is not my job” but they should instead ask their colleagues “how can I help you?”. Shared activities are key to learning and gaining competencies.

The main goal for any agile team member, regardless of his role is delivering customer value.

Question#2Is there a difference between the programmer’s mindset and the tester’s mindset?

Yes, there is a difference, I don’t think it constitutes an insurmountable obstacle. One of the teams I have worked with, knowing that I wouldn’t be available for a period of time, suggested they needed the tester’s mindset for certain activities and decided that to make sure they were focusing on the right things, they would wear a big red hat. This simple change helped them keep their focus and their mindset in the right place. It might not be prefect but it worked. It works also because I speak to them about the testers mindset when we work together, I give them examples of what I am thinking at specific times and why it is important to think about such things. Developers are very smart people, once they understand a practice has value and receive sufficient amount of coaching, they can learn to do almost anything.

Just to avoid misunderstandings, our developers wear the testers hat when performing testing activities with other developers, i.e. they don’t use the hat for their own code as maybe this could be asking too much.

 Question#3: What is the mission, the distinctive reason for having a tester on the team—whether that person has the title “tester” or something else?

The mission is to provide the team with the testing competencies it needs so that customer value can be delivered. The secondary purpose is to train and coach the team so that they can gain some of the competencies to support test activities. Coaching and training can be also formal but it is mainly delivered by working in pairs.

 Question#4: What is it that distinguishes testing work from all the other work?

Every activity the team engages in, is performed to deliver customer value, including test activities, but I am not sure I understood your question completely, could you please rephrase?

Question#5: What testing-specific skills do testers bring to the table?

See answer to question#1 re. competencies. My main competencies are exploration and learning.

Question#6: What is testing?

Testing to me is exploration and learning.

I test ideas to prevent defects, software to detect them and product owners assumptions to reduce waste.


I hope I have clarified some of your doubts and I am curious to hear your answers to your own questions.



9 thoughts on “Agile tester part 2, questions and answers

  1. It’s so interesting that you got such varied feedback – I guess it shows the importance of context and experiences! It is indeed my experience as a member of teams who identify themselves as “agile” that the lines continue to blur. Programmers on my current team routinely engage in exploratory testing, they pair with us testers to learn more about doing that, and pair with each other now that they feel more confident. They are often amazed at how many problems they find, even though they do a great job (IMO) of TDD. And they often say how much they value having expert testers on the team, that we contribute so much with our exploratory testing and our questioning.

    And though I don’t have a lot of time to work on my coding skills, I do spend some time pairing with another tester currently on a spike of iOS UI test automation, with occasional help from programmers. I’ve had to learn to build our web app and our iOS app and use the same tools and frameworks as the programmers do.

    In the past few years I have learned more BA skills and practiced those. I’ve worked on my own ET skills. Nobody will mistake me for anything other than a tester, but I suspect a lot of testers who are in a different type of environment might look at some activity I do and say “Hey, that’s not the job of a tester”.

    • Thanks for your feedback Lisa. I think that the main reason why agile team members don’t have problems switching to tasks that are not specifically related to their title is because they understand that the goal of their job is to deliver customer value and not analysis, coding or testing, at least that’s how I feel.

  2. Hiya Gus, Great post! Some of the reading associated with this post, made me think about what I am noticing in my local market (perhaps this is prevalent in other regions as well). There is a wave of (what I call it) “title-ism”. In other words, some people drive strongly to collect titles (Test Analyst, Senior Test Analyst, Test Manager, etc.).

    If I look what Lisa and yourself have written so far, and what I can observe in Agile teams, the drive there is about collecting skills and developing competencies that can be valuable for teams. Valuable “testers” are those that have a wide base of pragmatic skills instead of titles. Scott Ambler has identified this type of behavior as that of a Generalizing Specialist (See

    Personally, I must admit that I was stuck in the “title-ism” mindset for a long time, and have been fortunate to have been exposed to the thinking and attitudes that you and Lisa speak about. And I must say that I enjoy this new way of thinking; Much of modern strategic management theory is busy evolving into this direction as well – moving away from lumbering silo based command and control structures to more (dare I say it?) agile, simpler and/or organic structures built around multi-skilled teams delivering value (See Child, J., 2008, “Organization: Contemporary Principles and Practice”, Blackwell Publishing, Malden, USA, Chapter 2). But that is a whole discussion on its own.

    • Aldo, thanks for your feedback.
      We’ve all had some sort of title-ism at some stage, i think it is part of the natural professional growth of an individual, for me it is call me anything you like as long as I can work in an environment that respects me as a human being and empowers me.

      Scott’s work on Generalizing Specialists is very good and I am completely bought into it. I believe in growing my skills in areas that are not my principal competency to be able to better help my team and give back by coaching and training my team mates.

      Thanks for the book reference, at the moment I am swamped with books to read but I will add it to the queue. I absolutely love the no silo self organizing team concept, a while back I wrote something on cross-functional anti patterns I have encountered during the years, you might like it

  3. I’ve read thru this multiple times, along with many other related articles. I’ve seen so many questions asking: what do testers do?, what differentiates a tester from any other role?, is testing dead? do we need testers?, etc.

    IMO and IME, even though competencies and roles are affected and play a part, it really boils down to focus. The focus of a tester is what really sets them apart and is why there is value in testing and testers.

    Allow me to elaborate.
    Programmer/programming focus includes – creating, implementing, fixing, building, integrating
    Tester/testing focus includes – questioning, exploring, validating, testing, proving
    Product Manager/Owner/managing focus includes – defining, planning, negotiating, guiding, prototyping

    I’ve defined some primary focuses for these roles above. Of course, there are secondary focuses for each role as well. It’s obvious I think that primary focuses for one role are likely secondary focuses for another role. Although I’ve worn many hats over the years within IT (i.e. Tester, Test Manager, Report Writer, Project Manager, Product Manager, Technical Sales, DBA, Programmer, Customer Service, etc.), my primary focus has always been as a Tester.

    I think we all can and should have secondary, and even tertiary focuses so that we can improve our understanding of the roles of others, have more empathy for them, provide and receive mentoring (continued improvement) and better contribute to the success of the team. However, I also believe that we can and should have different primary focuses because that’s where we add the most value. In other words, my primary expertise and ambition is in testing focused activities, while a programmer’s primary expertise and ambition is in programming focused activities. Those activities are all needed and we add the most value to that role thru primary focuses, so that’s where we can and should provide the most value.

    Anyone who follows the NBA can see parallels. Here are a few examples of questions being asked recently:
    – Lebron James can do it all, so why do we need anybody else?
    – Are big men still needed?
    – Can we replace traditional point guards with 6’8″ power forwards that are trained to handle the ball?

    Since I was 14, I’ve always been pegged as the center in basketball in part because of my size. I pushed myself to develop point guard skills and shooting guard skills and I play those positions well, but I dominate as a center, in part because of my size, but also because of my focus. I love the blocked shots, the rebounds, fighting for space on the block, scoring at the basket.

    The same is true of IT for me. I pushed myself to do many other activities and develop many other skills, but I dominate as a tester, in part because of my experience, but also because of my focus. I love the questioning, the exploring, the validating, the testing, and the proving.

    I believe that to succeed we need everyone on the team to be multi-talented and to contribute to secondary focuses as needed, but that we should focus primarily on what we do best because that’s where we provide the most value.

    Although many people don’t seem to understand what testing does for them, don’t want to pay for it, or take for granted its benefits to them, they sure notice when it’s absence is manifest in the products they use.

    All roles on the team are necessary, provide value, and are sorely missed when absent (even when we don’t want to admit it).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s