Convincing programmer about tester's values

[Markus Gärtner]

At a client appointment today, I talked to a tester who is part of a Scrum team. One of my colleagues coaches that team, and supported her on getting heard inside the team and raising her concerns during retrospectives, etc.

After four to five months she eventually gave up that fight. The situation seemed a bit desperate. The programmers are happy with "just coding" without that touchy stuff around retrospectives and the like.

Her story struck me, and I wonder now what can you actually do in order to conince programmers in your team about the value that a tester can bring.

Having fought this fight for almost three years in the past, I wonder about working stuff for this kind of problem.

What's your experience?

Best Markus
--
Dipl.-Inform. Markus Gärtner

it-agile GmbH
Paul-Stritter-Weg 5, D-22297 Hamburg

Geschäftsführer: Henning Wolf, Jens Coldewey
Handelsregister Hamburg, HRB: 92261
Umsatzsteuer-Identifikationsnummer: DE239483021

Fon: +49 40 88173-300
Fax: +49 40 88173-333
Mobile: +49 172 4297613
E-Mail: markus....@it-agile.de

http://www.it-agile.de

[eghm]

On Jan 27, 10:28 am, Markus Gärtner <mgaer...@googlemail.com> wrote:
>
> Her story struck me, and I wonder now what can you actually do in order to conince programmers in your team about the value that a tester can bring.
>
> Having fought this fight for almost three years in the past, I wonder about working stuff for this kind of problem.
>
> What's your experience?
>
> Best Markus

Largely same as yours. Though eventually one of my x-teams came to
the realization "We have to take (the time it will take to automate)
testing into account because we are all part of the team."

[Eric Willeke]

Yeah, I think it's similar for the ones I've seen lately. Generally seems to come down to some sort of goal-alignment that triggers change. (Goals as in "team delivery of functionality" not "different incentives")

E

[Tim Ottinger]

Marcus:

I'm not quite understanding the problem statement.
I get that there is a tester on the team.
I get that programmers don't want to do touchy-feely stuff.
I get that there has been work to get attention to testing.

I don't see the connection between touchy-feely stuff and testing, or
retrospectives and touchy-feely stuff.
As a result, the question seems non-sequitor to me.

Can you explain a little more and fill in these blanks?

--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------
http://www.industriallogic.com/
http://agileinaflash.com/
http://agileotter.blogspot.com/

[Markus Gärtner]

Hi Tim,

sure. The coach and the tester worked on the issues between programming and testing to large extents through the retrospectives. The problem was, that the tester was unfamiliar with programming, yet worked on her own on the test automation. She had to convince programmers to introduce ids into the GUI logic, so that automating the functional tests became a whole lot easier for her.

Another thing, When she faced problems with the environment, she asked the progammers to help her, but a programmer who should have known something about it, stated he couldn't help her. From what I got to know, there seems to be a team problem, and that team would largely benefit from exchanges like the daily standup or retrospectives.

Still, I am wondering what I could domdifferently as a tester on that team.

Best
Markus

--
Dipl.-Inform. Markus Gärtner

it-agile GmbH
Paul-Stritter-Weg 5, D-22297 Hamburg

Geschäftsführer: Henning Wolf, Jens Coldewey
Handelsregister Hamburg, HRB: 92261
Umsatzsteuer-Identifikationsnummer: DE239483021

Fon: +49 40 88173-300
Fax: +49 40 88173-333
Mobile: +49 172 4297613
E-Mail: markus....@it-agile.de

http://www.it-agile.de

[Jon Kern]

if the team culture and / or the "leaders" do not understand the value
of having testers involved up front versus only as a black box at the
end, your challenge will be great.

how would you express the team culture regarding testing?

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Markus Gärtner said the following on 1/27/12 2:25 PM:

[Lance Walton]

Yes, with the clarification (explicit or implicit) that "delivery of functionality" is not achieved unless the functionality actually works.

_________________

http://www.stateofflow.com

http://www.casualmiracles.com
http://www.twitter.com/lancewalton

+44 7779 026533

[Markus Gärtner]

Hi Jon,

the culture seemed a bit off on testing, but I just know one side of the story and might be biased.

Best Markus

--
Dipl.-Inform. Markus Gärtner

it-agile GmbH
Paul-Stritter-Weg 5, D-22297 Hamburg

Geschäftsführer: Henning Wolf, Jens Coldewey
Handelsregister Hamburg, HRB: 92261
Umsatzsteuer-Identifikationsnummer: DE239483021

Fon: +49 40 88173-300
Fax: +49 40 88173-333
Mobile: +49 172 4297613
E-Mail: markus....@it-agile.de

http://www.it-agile.de

[Dale Emery]

Hi Markus,

> the culture seemed a bit off on testing, but I just know one side of the story and might be biased.

Are they interested in getting information about their work?

This week I'm bumping into developers who aren't interested in testing, but do seem interested in getting feedback about their work. So I'm nudging testers to talk more about the /product/ they produce (information) rather than the /activities/ they do (testing). Seems to help a little when talking to developers and business folks. Sometimes.

Dale

--
Dale Emery
Consultant to software teams and leaders
http://dhemery.com

[Markus Gaertner]

Hi Dale,

that sounds great. I coach another team right now, where some of the
developers seek this kind of feedback, and even appreciate critical
feedback from the testers. I think this is a great point.

Best
Markus

--
Dipl.-Inform. Markus Gärtner
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

[Jon Kern]

i have worked with the same QA guy sine ~2000...

i can't imagine developing product without someone like him on my side.

so maybe there are two kinds of developers: those who work with
testers/qa, and those who never tried.

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Markus Gaertner said the following on 1/27/12 4:48 PM:

[Morgan Ahlström]

One thing that has worked quite well for several teams I have worked with is a workshop around ATDD/BDD/Spec by Example or whatever you wish to call it.

I've come across a bunch of teams with strong role segregation and a "throw things over the wall" mentality and I've found that talking about requirements has worked better than talking about testing.

What I've done is given a short intro to the ideas behind techniques like Specification by Example etc and then I've asked them bring in a new requirement that's about to be brought into the next sprint. I've asked them to use PostIts and write down all the questions, thoughts, ideas whatever they can come up with, related to the req and put the notes on a wall. After that I've let them do an affinity mapping as a group to find patterns. Finally they get to go over the notes and try to answer questions, write examples in the Given When Then-format when appropriate or just log questions they don't have the answers for to be answered later on.

After the exercise I've asked them to see if they could keep doing something like this for pre-planning sessions (almost none the teams have had pre-planning as a part of their process).

This is not a unique workshop and I use similar techniques for pre-planning and planning for teams that I work in myself but it has been a very powerful way to get the teams to see the value of working together across role-borders. It's been a good way to ease into the kind of thinking necessary to start working with tests together as a team but since we don't talk about it as writing tests, it takes a lot of the edge away. We're just making sure that everyone have the same view of what should be done, but after a while they realize that what actually comes out are a bunch of functional test that helps everyone in the team. Automation of the tests often comes as a request from the developers when they've worked this way for a while.

BR

Morgan

--
__________________________________
Phone: +46 (0)72 726 33 03
Twitter: @Morgsterious
Blog: http://morgsterious.wordpress.com

[Jon Kern]

i try to convince teams that the following exercise can help during iteration kick-off:

• have enough players in the room/whole team:
• describe a new feature
  
• talk enough so that qa can write a cucumber-like acceptance test that client agrees to
• talk enough so that developers can estimate the story, or at least imagine they can code it up
  

there's a lot of nuance, but that is the basic gist.

if qa and devs understand enough about the story, you can move on to discussing the next story.

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Morgan Ahlström said the following on 1/28/12 9:53 AM:

[J. B. Rainsberger]

On Sat, Jan 28, 2012 at 03:21, Jon Kern <jonk...@gmail.com> wrote:

> i have worked with the same QA guy sine ~2000...
>
> i can't imagine developing product without someone like him on my side.
>
> so maybe there are two kinds of developers: those who work with testers/qa,
> and those who never tried.

I began to like testing at IBM in 1999 when I finally worked with a
caring, skilled, gentle tester. We collaborated. I loved it. I never
wanted to build anything without him.

I suspect caring, skilled, gentle testers are rare.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Author, JUnit Recipes
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com
Find out what others have to say about me at http://nta.gs/jbrains

[Jon Kern]

that is a great way to describe my friend (and QA guy) Max

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

J. B. Rainsberger said the following on 2/18/12 11:17 AM:

[Dave Rooney]

On 2012-02-18, at 9:47 PM, J. B. Rainsberger wrote:

> I began to like testing at IBM in 1999 when I finally worked with a
> caring, skilled, gentle tester. We collaborated. I loved it. I never
> wanted to build anything without him.
>
> I suspect caring, skilled, gentle testers are rare.

I've had the privilege of working with a couple of them.

One in particular really opened my eyes to good testing... we actually paired together a for a number of sessions and it showed me how to think outside the typical programmer "works on my machine" box. That experience had a tremendously positive effect on me and had the single most positive effect on the quality of my work. That was about a year before I learned about XP, and I have no doubt that it smoothed the way for me to understand why testing and pairing were so important. Probably because of that person, I was never one of 'those' XP folks who said that we didn't need testers anymore.

Dave...

[Ted M. Young [@jitterted]]

This is a great topic and a serious problem in lots of teams. There's a lack of recognition and understand by developers about what good testers do! And by "good", I mean those who are thoughtful about how they test and use an exploratory testing approach to their work. Let me tell a little story:

For various reasons, in addition to being the manager of developers on the team, I became the manager of the QA folks. For the longest time there was a QA person who personified the "old-style" QA person: he would test things, find some bugs, but they'd never be the "oh my god, we never thought of that" types of bugs. And in fact, when customers found bugs, I was appalled that we didn't catch it in QA. I tried coaching him about being a more thoughtful tester, but he wasn't getting it. He didn't understand what "risk" meant, he didn't understand parts of the domain (even though he had been testing those features for years). Finally, I put him on a performance plan and worked closely with him to see if he could learn how to be more like the "good" tester model that I have. He failed pretty miserably and it was pretty depressing for me as well and, of course, we terminated his employment.

Fast forward 6 months when it's time for my review, and I get fairly significantly dinged for terminating him. Why? Because apparently most of the developers on the team thought he was a valuable QA person and complained about me firing him.

That is what we're fighting against.

I won't even talk about some of the developers not willing to verify other developers bug fixes because "I don't know how to do that, that's a QA job".

I've seen this time and time again in so-called "engineering-centered" cultures, where "engineering-centered" means "developer-centered".

;ted

[J. B. Rainsberger]

On Sun, Feb 19, 2012 at 03:27, Ted M. Young [@jitterted]
<tedy...@gmail.com> wrote:

> Fast forward 6 months when it's time for my review, and I get fairly
> significantly dinged for terminating him. Why? Because apparently most of
> the developers on the team thought he was a valuable QA person and
> complained about me firing him.
>
> That is what we're fighting against.

Not nice.

> I won't even talk about some of the developers not willing to verify other
> developers bug fixes because "I don't know how to do that, that's a QA job".

"Umm… if you don't know how to find out whether someone's code works,
then you also don't know how to find out whether YOUR code works. Are
you sure you want to go on record having said that? I'll give you a
few minutes to think about it."

[Ted M. Young [@jitterted]]

On Sun, Feb 19, 2012 at 8:14 AM, J. B. Rainsberger <m...@jbrains.ca> wrote:

On Sun, Feb 19, 2012 at 03:27, Ted M. Young [@jitterted]
<tedy...@gmail.com> wrote:

> I won't even talk about some of the developers not willing to verify other
> developers bug fixes because "I don't know how to do that, that's a QA job".

"Umm… if you don't know how to find out whether someone's code works,
then you also don't know how to find out whether YOUR code works. Are
you sure you want to go on record having said that? I'll give you a
few minutes to think about it."

Interesting tactic, I'll have to try that the next time I'm in that position. I think this developer's reaction came from fear of not knowing how to test, possibly mixed with old-style thinking that testing is somehow "beneath" the work of a developer. Either way, education around this is sorely needed. Which, actually, is one of the reasons I'm participating in the Test Coach Camp (http://www.associationforsoftwaretesting.org/conference/cast-2012/test-coach-camp/) alongside CAST 2012.

;ted
--
Ted M. Young
Renaissance Coder & Agile Practitioner
@jitterted
http://tedmyoung.tumblr.com

[Eric Willeke]

Observation from the peanut gallery:

The language I'm seeing in this thread is often around "convincing", while the success stories are mostly around "experiencing" 

How do we create more low-friction opportunities to experience, and thus come to value?

E

Please forgive if this came across short or poorly crafted, it was sent from my iPhone.  

[Ted M. Young [@jitterted]]

Agreed! What are some good ways to get devs to experience what _good_ testers do? Telling them to pair or collaborate is obviously insufficient. How do we design the environment to make it easy and natural for them to work together?

;ted
--
Ted M. Young
Renaissance Coder & Agile Practitioner
@jitterted
http://tedmyoung.tumblr.com

[Nigel Thorne]

I would get the testers involved when discussing the acceptance criteria at estimation time.

The devs will see the testers contributing to the list of scenarios.

Prompt with "what other scenarios would you test here?" if they feel uncomfortable initially.

Only stop when everyone agrees it is complete.

You have to involve the right personalities though. Some testers love trying "what if's" and given a test script will use it as a starting point to explore from... others will only do what's on the script, and power through the test cases. Both are necessary in a test team. In this case though I would involve an outspoken explorer type.

When the feature is complete, the devs will know what the testers are about to do as they were part of the definition of the test scenarios.

The testers can then give feedback in terms of "scenario X failed." Or I found a new scenario I think should work, do you agree?

It also reduces the false failure cases of testers interpreting the requirement differently to the dev, so the feedback is seen as more valuable.

How are developers experiencing tester feedback at the moment?

[Ted M. Young [@jitterted]]

On Sun, Feb 19, 2012 at 12:28 PM, Nigel Thorne <ni...@nigelthorne.com> wrote:

I would get the testers involved when discussing the acceptance criteria at estimation time.

The devs will see the testers contributing to the list of scenarios.

Only if those contributions are meaningful, but devs can't usually tell the difference between meaningful acceptance criteria and, well, the same old crap. 

 

You have to involve the right personalities though. Some testers love trying "what if's" and given a test script will use it as a starting point to explore from... others will only do what's on the script, and power through the test cases. Both are necessary in a test team. In this case though I would involve an outspoken explorer type.

Right and this is often the hard part: when 80% of the QA folks are script-oriented, the exporatory-test-oriented 20% may not feel comfortable or be outspoken enough to counterbalance things, or, even worse, they may be seen as the ones who aren't as effective.

How are developers experiencing tester feedback at the moment?

Once I was no longer on the team, acceptance criteria creation seems to have stopped and it's gone back to the usual "hey, I found this problem in your story". Not bad, because devs and QA do talk to each other, but for the most part a return to old habits.

Obviously, given my prior experience, I no longer try to change things because clearly that's not what gets rewarded. Especially when I see _good_ testers get terminated (not by me) because they're seen as inefficient.

;ted
 

[Nigel Thorne]

How is efficiency measured for testers?

[Eric Willeke]

Heh, collect those resumes and let me know ;)

Please forgive if this came across short or poorly crafted, it was sent from my iPhone.

[Ted M. Young [@jitterted]]

It's not quantified, but it appears to be that if you're not filing bugs, or stories are taking a long time to be tested, then there's something wrong. It seems to be all about perception rather than the reality that tester A may not be as "fast" as tester B, but tester A is the one who find the serious problems in requirements, but tester B never does. It's not just devs that don't know what _good_ testers look like, it's product and project managers who don't know either.

;ted

[Malcolm Anderson]

On Sun, Feb 19, 2012 at 12:44 PM, Ted M. Young [@jitterted] <tedy...@gmail.com> wrote:

Once I was no longer on the team, acceptance criteria creation seems to have stopped and it's gone back to the usual "hey, I found this problem in your story". Not bad, because devs and QA do talk to each other, but for the most part a return to old habits.

Obviously, given my prior experience, I no longer try to change things because clearly that's not what gets rewarded. Especially when I see _good_ testers get terminated (not by me) because they're seen as inefficient.

This is where Scrum comes in handy as it can spot light groups being rewarded for contradictory behaviors.

Things like devs only being rewarded for completing features with no bug feedback loop, combined with and testers being rewarded for quantity of bugs found rather than bugs prevented.
 

;ted
 

--

Malcolm Anderson
Scrum Coach & Agile Engineer
http://www.PragmaticAgility.com/blog

[Ted M. Young [@jitterted]]

On Sun, Feb 19, 2012 at 2:41 PM, Malcolm Anderson <malcolm.b...@pragmaticagility.com> wrote:

On Sun, Feb 19, 2012 at 12:44 PM, Ted M. Young [@jitterted] <tedy...@gmail.com> wrote:

Once I was no longer on the team, acceptance criteria creation seems to have stopped and it's gone back to the usual "hey, I found this problem in your story". Not bad, because devs and QA do talk to each other, but for the most part a return to old habits.

Obviously, given my prior experience, I no longer try to change things because clearly that's not what gets rewarded. Especially when I see _good_ testers get terminated (not by me) because they're seen as inefficient.

This is where Scrum comes in handy as it can spot light groups being rewarded for contradictory behaviors.

Only if those doing the rewarding see them as contradictory. There's a widespread lack of recognition that we have a wicked problem (too much tech debt) and that we are nowhere near fixing it. Why? Because in spite of that, we are very successful, but I digress...

It'd be much easier to spot if the devs didn't, for the most part, do a really good job. It feels very similar to those devs who believe testers aren't necessary because the devs already do lots of unit testing.
 

Things like devs only being rewarded for completing features with no bug feedback loop, combined with and testers being rewarded for quantity of bugs found rather than bugs prevented.

It's not that straightforward, the links between the behaviors and the rewards/consequences are much less obvious than perhaps I'm making it seem.

;ted
 

[George Dinwiddie]

Eric,

On 2/19/12 2:16 PM, Eric Willeke wrote:
> Observation from the peanut gallery:
> The language I'm seeing in this thread is often around "convincing",
> while the success stories are mostly around "experiencing"
>
> How do we create more low-friction opportunities to experience, and thus
> come to value?

My strategy is to move the discussion and identification of concrete
scenarios up to the requirements definition or "backlog grooming."

Like this: http://manage.techwell.com/articles/weekly/three-amigos for
example.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Ted M. Young [@jitterted]]

George,

On Mon, Feb 20, 2012 at 7:06 PM, George Dinwiddie <li...@idiacomputing.com> wrote:

Eric,

On 2/19/12 2:16 PM, Eric Willeke wrote:

Observation from the peanut gallery:
The language I'm seeing in this thread is often around "convincing",
while the success stories are mostly around "experiencing"

How do we create more low-friction opportunities to experience, and thus
come to value?

My strategy is to move the discussion and identification of concrete scenarios up to the requirements definition or "backlog grooming."

Like this: http://manage.techwell.com/articles/weekly/three-amigos for example.

 

That definitely helps, but still does not solve what I see as the core problem: getting devs (and PMs) to understand what _good_ testers do and how it helps the entire process. 3 Amigos is a great way to improve collaboration, though.

[RonJeffries]

Hi Ted,

On Feb 21, 2012, at 12:28 PM, Ted M. Young [@jitterted] wrote:

That definitely helps, but still does not solve what I see as the core problem: getting devs (and PMs) to understand what _good_ testers do and how it helps the entire process. 3 Amigos is a great way to improve collaboration, though.

I think the only way to "get devs and PMs to understand" is to give them a good tester and let them discover for themselves.

Ron Jeffries

www.XProgramming.com

I know we always like to say it'll be easier to do it now than it

will be to do it later. Not likely. I plan to be smarter later than

I am now, so I think it'll be just as easy later, maybe even easier.

Why pay now when we can pay later?

[J. B. Rainsberger]

On Sun, Feb 19, 2012 at 21:16, Eric Willeke <eric.w...@gmail.com> wrote:

> Observation from the peanut gallery:
> The language I'm seeing in this thread is often around "convincing", while
> the success stories are mostly around "experiencing"
>
> How do we create more low-friction opportunities to experience, and thus
> come to value?

Absolutely. I don't convince anymore. I expose. I create safe
artificial learning environments. I guide. It works for me. I get my
point across well and often. People try. They say good things.

[J. B. Rainsberger]

On Sun, Feb 19, 2012 at 21:54, Ted M. Young [@jitterted]
<tedy...@gmail.com> wrote:

> Agreed! What are some good ways to get devs to experience what _good_
> testers do? Telling them to pair or collaborate is obviously insufficient.
> How do we design the environment to make it easy and natural for them to
> work together?

Fix a thorny bug together.

[Charlie Poole]

This is an instance of the more general problem: How to get <role1> to
understand the values and needs of <role2>, where each role can be
can be programmers, testers, business people, etc.

Usually, as you say, the solution starts with getting them together. Once
you have done that you can confront the problem that worries you directly,
but often you no longer have to.

Charlie

[Lance Walton]

On 21 Feb 2012, at 17:28, Ted M. Young [@jitterted] wrote:

>
> That definitely helps, but still does not solve what I see as the core problem: getting devs (and PMs) to understand what _good_ testers do and how it helps the entire process. 3 Amigos is a great way to improve collaboration, though.
>

I think there's a general problem with people understanding what _good_ <insert favourite role>s do and how it helps the entire process.

[RonJeffries]

Hi Lance, Ted, all ...

I think there is a more general problem. It seems that when Ted says "tester", he's thinking about a person. When we say "roles", we often still think about a person.

Looking at a given team, they probably need more skill in certain kinds of testing (or other skill areas of course). They may or may not need a "good tester". 

In general, I think a team does not often need a "good tester" or "good documenter" or "good designer" or "good coder". I think the team needs more skill. 

There are many ways to get more skill. One of the ways, and often not the best way, is to recruit some person.

Ron Jeffries

www.XProgramming.com

I try to Zen through it and keep my voice very mellow and low.

Inside I am screaming and have a machine gun.

Yin and Yang I figure.

  -- Tom Jeffries

[Lance Walton]

On 21 Feb 2012, at 18:20, RonJeffries wrote:

Hi Lance, Ted, all ...

On Feb 21, 2012, at 1:11 PM, Lance Walton wrote:

On 21 Feb 2012, at 17:28, Ted M. Young [@jitterted] wrote:

That definitely helps, but still does not solve what I see as the core problem: getting devs (and PMs) to understand what _good_ testers do and how it helps the entire process. 3 Amigos is a great way to improve collaboration, though.

I think there's a general problem with people understanding what _good_ <insert favourite role>s do and how it helps the entire process.

I think there is a more general problem. It seems that when Ted says "tester", he's thinking about a person. When we say "roles", we often still think about a person.

Looking at a given team, they probably need more skill in certain kinds of testing (or other skill areas of course). They may or may not need a "good tester". 

In general, I think a team does not often need a "good tester" or "good documenter" or "good designer" or "good coder". I think the team needs more skill. 

There are many ways to get more skill. One of the ways, and often not the best way, is to recruit some person.

I concur.

[John Goodsen]

Two things that can help testing dramatically, in my experience.

First, make sure there is a swimlane for cards that represents "Definition of Done" - and make sure that the triad (Dev, PO/Customer and Developer) all collaborate and agree/understand what "DONE" is on a card.  Do not let team members skip cards past that column without going through the activity of defining done with the PO and testers.  It's a discipline thing - way too often, developers will just say "yeah, I know what I need to do" without communicating with testers on what that is.

Second, get the team to implement and adhere to WIP Limits.  Specifically, when the "developer lane" fills up and no more development can happen, then devs have to help out testing.  

jg

[Markus Gaertner]

May I quote you in an article on the differences between some testers
that help the team, and others that don't know how to do that?

Best
Markus

--
Dipl.-Inform. Markus Gärtner
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

[Malcolm Anderson]

Markus

Here's an article that is aimed at developers and business people on the value that a great tester brings to the table.
http://www.developerfusion.com/article/136381/testing-in-an-agile-world-the-heart-of-a-developer/

Simply put, developers thoughts cycle on creation ("how can I make this work?")
Tester's thoughts cycle on destruction ("How can I bring this down with the least amount of force?")

There are some testers who are not happy with how I boil down their value to one word, but I've found that manager types (my prejudice) are so busy that anything you tell them has to be short and sticky in order for them to retain it.  I have yet to find 2 more powerful words to sum up what the different roles bring to the table.

I hope this helps.

Malcolm

--

Malcolm Anderson
Scrum Coach & Agile Engineer
http://www.PragmaticAgility.com/blog

On Fri, Jan 27, 2012 at 10:28 AM, Markus Gärtner <mgae...@googlemail.com> wrote:

At a client appointment today, I talked to a tester who is part of a Scrum team. One of my colleagues coaches that team, and supported her on getting heard inside the team and raising her concerns during retrospectives, etc.

After four to five months she eventually gave up that fight. The situation seemed a bit desperate. The programmers are happy with "just coding" without that touchy stuff around retrospectives and the like.

Her story struck me, and I wonder now what can you actually do in order to conince programmers in your team about the value that a tester can bring.

Having fought this fight for almost three years in the past, I wonder about working stuff for this kind of problem.

What's your experience?

Best Markus
--
Dipl.-Inform. Markus Gärtner

it-agile GmbH
Paul-Stritter-Weg 5, D-22297 Hamburg

Geschäftsführer: Henning Wolf, Jens Coldewey
Handelsregister Hamburg, HRB: 92261
Umsatzsteuer-Identifikationsnummer: DE239483021

Fon:    +49 40 88173-300
Fax:    +49 40 88173-333
Mobile: +49 172 4297613
E-Mail: markus....@it-agile.de

http://www.it-agile.de

[John Goodsen]

In my current coaching gig, I've managed to acquire a dedicated room with a projector to host coding katas and gang programming.  Every day from 10-11 we have a kata session on some topic - either doing some TDD or a refactoring Kata on some of their nasty code.  I have testers, developers and even some PO's stopping in - it's an open door policy.

In the last week, we've had testers, developers and business people stay in the room all day afterwards, working on a single story from the jBehave acceptance test through TDD.  Everyone is learning and I think appreciating the value that the other 2 specializations bring to the triad.  I can see a marked improvement in some of their culture already.

Getting everyone into the same room so we can all take part in the same conversation and work package is HUGE.  ... just sharing with you guys -- maybe not so relevant to this thread....

jg

[George Dinwiddie]

Ted,

On 2/21/12 12:28 PM, Ted M. Young [@jitterted] wrote:
> George,
>
> On Mon, Feb 20, 2012 at 7:06 PM, George Dinwiddie

> Like this: http://manage.techwell.com/articles/weekly/three-amigos
> for example.
>
> That definitely helps, but still does not solve what I see as the core
> problem: getting devs (and PMs) to understand what _good_ testers do and
> how it helps the entire process. 3 Amigos is a great way to improve
> collaboration, though.

Depending on the tester, the conversations among the 3 Amigos should
help others understand what good testers do.

[Malcolm Anderson]

George

Love the 3 amigos article

Malcolm

[John Goodsen]

"Well we really dont have a plan B. We didn't expect for the first plan to work. Sometimes you can overplan these things."

 - Dusty Bottoms, Three Amigos

[George Dinwiddie]

On 2/22/12 6:55 AM, Malcolm Anderson wrote:
> George
>
> Love the 3 amigos article

Thanks, Malcolm. I had a good editor (Johanna Rothman) pushing me to
make it better than what I first wrote.

- George

>
> Malcolm
>
>
>
> On Tue, Feb 21, 2012 at 11:12 PM, George Dinwiddie
> <li...@idiacomputing.com <mailto:li...@idiacomputing.com>> wrote:
>
> Ted,
>
>
> On 2/21/12 12:28 PM, Ted M. Young [@jitterted] wrote:
>
> George,
>
> On Mon, Feb 20, 2012 at 7:06 PM, George Dinwiddie
> Like this:

> http://manage.techwell.com/__articles/weekly/three-amigos

> <http://manage.techwell.com/articles/weekly/three-amigos>
> for example.
>
> That definitely helps, but still does not solve what I see as
> the core
> problem: getting devs (and PMs) to understand what _good_
> testers do and
> how it helps the entire process. 3 Amigos is a great way to improve
> collaboration, though.
>
>
> Depending on the tester, the conversations among the 3 Amigos should
> help others understand what good testers do.

--

[Malcolm Anderson]

A good editor makes a lot of difference.
The editor that I had basically said, "this sucks" and that was as good as it got.
My end result was still much better than my original version.

Back to your article:
I absolutely loved the story snippits that you put at the beginning of the article, they were so painfully real. 
"I don't know if this is physically possible, so I'll put it in the spec and let the developers push back"
Brilliant

Malcolm

--

Malcolm Anderson
http://MoreTimeWithYourKids.com