The agile tester (ˈadʒʌɪl/ ˈtɛstə/) is a mammal member of the family “Exploratoris”. He lives in the wild in small groups named cross-functional agile teams.
Skills
Besides communication and technical skills, his main traits are curiosity and empathy[1].
Curiosity helps the agile tester in finding opportunities to improve the product. The agile tester questions everything.
Empathy allows the agile tester to interact and collaborate with the other members of the agile team smoothly.
Mission
The agile tester has an overwhelming interest in delighting customers.
His customers are the product owner and the final users.
He strives in balancing his efforts between making his company successful and delighting the final users by delivering a continuous flow of value to both.
Life
The agile tester spends most of his time having numerous conversations with other members of the team [2].
He will often speak to and question the product owner and the final user in the quest of real value. The agile tester knows that if he doesn’t understand perfectly what the value to be delivered is, he won’t be able to do his job. He builds a strong understanding of the business context he lives in, to be able to help the product owner identify more valuable solutions. This aspect is extremely important to the agile tester, he strives to contribute to building a better product.
Often he will be found having a conversation with the product owner and a developer. This group of animals also known as “The 3 Amigos” [3] feed off each other’s knowledge, different perspective and passion for value to resolve all sort of problems and design lean solutions.
Other times he will be seen pair testing while coaching his partner developer or supporting a developer writing checks, or even writing some checks himself.
Some agile testers have been seen speaking to final users to better understand their experience with the application.
He is also sometimes found alone at his desk testing, softly talking to the application under test.
During the night the agile tester studies and researches his craft, sometimes he blogs and if you watch attentively you might spot a lone agile tester engaging in passionate testing conversations on twitter or in a bar in front of a beer.
Social life
The agile tester’s’ life would not be possible without the team. He works and lives with the team and for the team, the team is an organism that functions with the agile tester[4].
The agile tester is a pragmatic animal and doesn’t like the company of moaners that do nothing to improve their condition. The moaner is the nemesis of the agile tester [13]
The agile tester believes in sustainable development and will not work overtime except for very special circumstances. He will push for process changes to remove other overtime occurrences.
The agile tester and waste
In general the agile tester refuses the concept of waste.
He will not under any circumstance do something “because that’s how we do things here” or “because the boss said so”. He will ask “why?”[5]. If he cannot get an answer that clearly explains what the value is, he won’t do it. He’d rather be fired than spend time doing things that don’t produce value.
On this subject he is known for using lean documentation, he generally enjoys documenting the application he is helping create through executable specifications[6].
He rejects the waste of bureaucracy and signoffs [7], in fact it is common seeing agile testers signing off by high five[8] in groups of Three Amigos rather than negotiate contracts.
The agile testers understands that producing, finding and fixing bugs is a wasteful activity and he will strive to help the agile team prevent them and do the thing right the first time as much as humanly possible[9]. The agile tester, not only understands this, but he coaches the developers members of the team on this concept and trains them in learning techniques that help them prevent bugs.
The agile tester believes that his skills are wasted performing regression checks, in fact he employs tools for this menial task[10].
The agile tester prefers cards and conversations to large documents. He plans his activity just in time and helps build the next parts of the product using discovery.
Some agile testers believe predicting the future is a waste of time and prefer building predictable process rather than estimating, they have been known for insistently using the tag #NoEstimates
Some extremist agile testers even got to the point to say that bug management is waste and have removed bug management tools from their organizations with a positive impact[11].
Education
The agile tester is a continuous learner.
He believes in agile principles and he studies the impacts of agile software development on his industry trying to learn new approaches to improve his own company and the whole agile community.
He believes that continuous improvement (as in kaizen) means everybody in the agile team is empowered to drive it. He helps other team members bring out their solutions and support them in convincing the team to try and measure results.
He does not believe in best practices but in good practices that can be improved[12]
NEW! Continue reading with Agile Tester part 2, questions and answers !
References:
[1] Get In Shape to become a better Agile Tester
[2] [6] [9] When Something Works Share it
[3] George Dinwiddie on the Three Amigos
[5] Be lean ask Why?
[7] The Cover your Ass manifesto
[10] Test Automation, Help or Hindrance?
[11] How I stopped logging bugs and started living happy
mysoftwarequality 
Got here to read what you wrote based on your comment on my blog (visible-quality.blogspot.fi). I’m not really disagreeing with you, but throughout reading this my head kept echoing “Testing is testing, agile is context” – I feel I was the same curious and empathetic animal pre-agile, and I’ve worked with some pretty unagile teams. Also, I feel that with agile teams and testers, there’s as many types of testers as there are combinations of people in the teams, what you work on is so much of an adaptation to what your colleagues are doing.
Also, as I read on this post, I realize that at some point you move from describing just the tester (as in role in the team) to testing (as in activity in the team), and it seems to be very hard to keep those things separate as things intertwine. For example, agile developer (programmer) is also a continuous learner and what I find that tends to separate me (a tester) from my lovely team mates (developers) is what we’re keen on learning about. Plus I have a lot more patience to push the software to break as I’m just a little ignorant on what the developers think they made work so far.
Nice post!
Maaret
Maaretp, thanks for your feedback.
you say “I feel that with agile teams and testers, there’s as many types of testers as there are combinations of people in the teams, what you work on is so much of an adaptation to what your colleagues are doing.”
What you see as an adaptation to what my colleagues are doing is instead in my opinion my effort to collaborate with my colleagues and help them succeed. I call it empathetic collaboration, it helps remove barriers between roles and improves of my colleagues’ output.
I am conscious my company won’t work with great testing only if the other members of my team are not great yet. I am not interested in doing great testing while other parts of my organisation need my help more than my testing. I am interest in delivering value. I take more of a holistic view.
On your other observation, yes, while describing the agile tester, I obviously mentioned testing activities. In my opinion every activity I described is a testing activity, which ones do you refer to in particular? I think that in this distinction, we might shed some light our fundamental misunderstanding.
I appreciate you believe “Testing is testing, agile is context”, it is a catchy phrase, sounds great, and it seems to be a bit of the mantra of the CDT community at the moment (nothing wrong with it BTW). I am not so sure it is 100% true, and I am going to express my opinion, no matter how influential might be the people that use it. In my opinion people and collaboration come before testing for an agile tester, so, my opinion is that agile is not only context.
Augusto,
In a recent LinkedIn discussion (http://lnkd.in/bQaGuHk), you mentioned this blog post. In the LinkedIn discussion, I made some comments regarding your blog post and am summarizing them here at your request. If there are any bits of the LinkedIn discussion that were not replicated below but would provide value here, feel free to add them.
—
In the LinkedIn discussion, folks were discussing the what constitutes a testers job. That is, “what do testers do?” One person suggested that the answer was context-dependent. That is, “what a tester does depends on the context they are in”. I followed this premise through to its logical conclusion: “testers do it all”. That is, testers “do anything and everything, as long as it helps deliver value”.
You then pointed towards this blog post as an example of “what at least one agile tester does”. To my understanding, one message of this post is “a tester does whatever it takes”, which supported my surprising conclusion.
If so, I argued that the blog post (and the conclusion) was actually describing a “team player” and not a “tester”. And, you agreed. Kind of. You said, “…the agile tester is firstly a team member then a tester. He will use his testing skills to help the team deliver value and to coach his team mates.”
So, I think the conclusion is “A *team member* will do anything and everything, as long as it helps deliver value. A *tester* will use their special set of knowledge and skills to further deliver value, as only they can.”
Yes?
I am still curious about a few things. In your blog post, you mention a testers “job” and “craft” and “different perspective”. Those things seem to be differentiators that help distinguish a “tester” from other roles. Can you clarify and expand on these?
As I said on LinkedIn, I really liked this post and thank you for writing it.
-Damian
Damian, you’ve done an amazing job at clearly reporting the Linkedin discussion here, thanks a million.
My answer to your question is YES, exactly as you said:
“A *team member* will do anything and everything, as long as it helps deliver value. A *tester* will use their special set of knowledge and skills to further deliver value, as only they can.”
Let me try to clarify your other doubts:
Job: agile tester can be a job, can be a role you play, can be a hat you wear.
Craft: I consider my craft(s) being: software engineering with core competency in testing and process improvement with core competency team dynamics. I like to believe that I can expand my craft to include anything that could help my team deliver customer value.
Different perspective: I also call this the tester’s hat. It is the perspective that for example while talking about a feature with my colleague developers, makes me think of “what could go wrong?” or “how could a malicious user try to exploit that?” or “will this have an impact on performance?” or “how can an internal user game this?” etc.
[…] The Agile Tester, a curious and empathetic animal – Augusto Evangelisti – https://mysoftwarequality.wordpress.com/2014/10/12/the-agile-tester-a-curious-and-empathic-animal/ […]
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.
—Michael B.
Michael, thanks for your feedback.
That’s a big question! I will address it in a separate blog post, stay tuned!
[…] 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 […]
Well written Augusto. I very much like the format you’ve chosen. Great work.
Thanks for sharing this. To me it sehds some light on a species I rarely encounter and that started to bother me just recently. As you know I’m a bit confused by the concept of an agile tester being around. To my honest opinion a tester as we knew it from the old days with big QA departments clearing out the mess developers made will not be required anymore. However, the skill set and unique character testers do have could be utilized within an agile team close to what has been developers (aka coders) in the old days (and too often still are) to support these former developers to learn how to test early, frequently and thoroughly while they themselves learn to contribute to the implementation of user stories besides testing them.
From what you desribed above I’d say an agile tester takes on too many responsibilities that have to be covered by other roles like product owner (prioritizing the backlog, making user stories clear to the team), product management (talk to customers, roll-out, roll-in of information).
What you expect an agile tester to do – truly understand what the customer wants and how the product should really look like – this would be something I would expect from every team member. How would a developer be able to code the right stuff if he does not understand the requirements to their full extend? Is the tester supposed to test this in afterwards? To my honest opinion this sound like a superfluous cycle. Why not coing it according to the requirements in the first place?
I’d like to be progressive here. Why not getting rid of this micro QA department inside the agile team to making these coders doing their work right in the first place?
Testers could bring their unique knowledge to make this happen. Depending on what aspect of their job they feel the most drawn to they could choose to join a development team to implement user stories or they move into a product owner role if they are more interested in transforming customer needs into user stories or they move into a product management role if talking to customers is what they would like to do.
Him Daniel, thanks for your feedback, I appreciate you accepted my invite to comment and respond with some very interesting points.
I believe that on a deeper ground we agree 100% but I am not sure we can express our agreement yet, a conversation like this can help.
You say “From what you described above I’d say an agile tester takes on too many responsibilities that have to be covered by other roles like product owner (prioritising the backlog, making user stories clear to the team), product management (talk to customers, roll-out, roll-in of information).”
I reflected on this sentence and I asked myself why am I doing this in my company? The answer is that when i joined my company that asked me to help them with product quality, I took their request literally and worked on identifying the gaps that needed to be covered to improve our product quality. In a way I acted as cement that is spread over bricks and penetrates all the gaps so that he can fulfil his goal: keeping the structure stable and solid. I didn’t care whether I needed to help product owners or developers or operations people. For my goal to be reached I could not be constrained within a specific area.
This is what I believe an agile tester can do in modern organisations.
You also say
“I’d like to be progressive here. Why not getting rid of this micro QA department inside the agile team to making these coders doing their work right in the first place?”
Do I believe that the agile tester will always exist? No. I believe that the skills that help me help my organisation today can be transferred to others. Developers can become great testers when they understand the real value of testing, and so can product owners and the other members of agile teams. I personally spend quite a lot of my time coaching and training developers on these subjects, and I am conscious that in my organisation this means talking myself out of a job, I have no problem with that.
Are all organisations test aware? I would doubt this very strongly. As long as there will be organisations that are not yet test aware, I see agile testers being an effective and precious role.
Great article. Really thought provoking. Thanks for sharing.
I am glad you enjoyed it Joshua, thanks for your feedback!