Role of Tester int TDD Team ...

[James Ladd]

Hi All,

While helping a team transition to using TDD I was asked the question,
"What is the role of a tester in a Team that does TDD?"

I have my opinions but I very interested to hear yours.

Rgs, James.

[Adam Sroka-3]

On Fri, Oct 9, 2009 at 5:05 PM, jamescladd <james_ladd@...> wrote:

>
>
>
> Hi All,
>
> While helping a team transition to using TDD I was asked the question,
> "What is the role of a tester in a Team that does TDD?"
>
> I have my opinions but I very interested to hear yours.
>

Programmers aren't good at finding all of the corner and edge cases
that need to be tested, because programmers don't think in terms of
how to break things. A programmer who understands TDD will just write
the test cases he needs to elicit the behavior that he wants. A tester
will write as many test cases as he can think of for every little
contingency. Things you and I wouldn't consider.

Testers know how to write functional tests. Functional tests are slow.
Programmers know how to write unit tests. Unit tests are fast.

So, testers left to their own devices will create a comprehensive
suite of slow tests that covers every contingency. Programmers left to
their own devices will write a small suite of unit tests that cover
interesting behaviors.

What we really want is a comprehensive set of fast unit tests and a
small, representative set of functional acceptance tests that just
cover the important business cases. The only way we'll get there is to
help each other. Testers help programmers to make their unit tests
comprehensive. Programmers and testers help customers to create a set
of functional tests that cover the scenarios with important business
implications. The end product is a fast build with good coverage that
we can run all the time and that fails quickly whenever something is
broken.

[Chirag-7]

My recommendation is to read "Agile Testing: A Practical Guide for Testers and Agile Teams" by Lisa Crispin and Janet Gregory. This will answer all the questions.

I also came across a separate discussion thread on scrum development group. You an find the summary of the discussion and the link to the discussion here

http://www.infoq.com/news/2009/04/dedicated-tester-agile-team

Hope this helps.

Chirag.

--- In testdrivendevelopment@..., Adam Sroka <adam.sroka@...> wrote:

>
> On Fri, Oct 9, 2009 at 5:05 PM, jamescladd <james_ladd@...> wrote:
> >
> >
> >
> > Hi All,
> >
> > While helping a team transition to using TDD I was asked the question,
> > "What is the role of a tester in a Team that does TDD?"
> >
> > I have my opinions but I very interested to hear yours.
> >
>
> Programmers aren't good at finding all of the corner and edge cases
> that need to be tested, because programmers don't think in terms of
> how to break things. A programmer who understands TDD will just write
> the test cases he needs to elicit the behavior that he wants. A tester
> will write as many test cases as he can think of for every little
> contingency. Things you and I wouldn't consider.
>
> Testers know how to write functional tests. Functional tests are slow.
> Programmers know how to write unit tests. Unit tests are fast.
>
> So, testers left to their own devices will create a comprehensive
> suite of slow tests that covers every contingency. Programmers left to
> their own devices will write a small suite of unit tests that cover
> interesting behaviors.
>
> What we really want is a comprehensive set of fast unit tests and a
> small, representative set of functional acceptance tests that just
> cover the important business cases. The only way we'll get there is to
> help each other. Testers help programmers to make their unit tests
> comprehensive. Programmers and testers help customers to create a set
> of functional tests that cover the scenarios with important business
> implications. The end product is a fast build with good coverage that
> we can run all the time and that fails quickly whenever something is
> broken.
>

[Kaleb Pederson-2]

On Friday 09 October 2009 05:15:13 pm Adam Sroka wrote:

> On Fri, Oct 9, 2009 at 5:05 PM, jamescladd <james_ladd@...> wrote:
> >
> >
> >
> > Hi All,
> >
> > While helping a team transition to using TDD I was asked the question,
> > "What is the role of a tester in a Team that does TDD?"
> >
> > I have my opinions but I very interested to hear yours.
> >

Good question James.
 

> Programmers aren't good at finding all of the corner and edge cases
> that need to be tested, because programmers don't think in terms of
> how to break things. A programmer who understands TDD will just write
> the test cases he needs to elicit the behavior that he wants. A tester
> will write as many test cases as he can think of for every little
> contingency. Things you and I wouldn't consider.
>
> Testers know how to write functional tests. Functional tests are slow.
> Programmers know how to write unit tests. Unit tests are fast.
>
> So, testers left to their own devices will create a comprehensive
> suite of slow tests that covers every contingency. Programmers left to
> their own devices will write a small suite of unit tests that cover
> interesting behaviors.
>
> What we really want is a comprehensive set of fast unit tests and a
> small, representative set of functional acceptance tests that just
> cover the important business cases. The only way we'll get there is to
> help each other. Testers help programmers to make their unit tests
> comprehensive. Programmers and testers help customers to create a set
> of functional tests that cover the scenarios with important business
> implications. The end product is a fast build with good coverage that
> we can run all the time and that fails quickly whenever something is
> broken.

Well stated Adam.

I disagree on a few fronts but agree that a capable tester brings strengths developers don't usually have.

To clarify a bit, a tester brings in not only a good understanding of edge cases and knowledge allowing the application to be well tested fairly quickly, but also maintains more of an overarching view and understanding.  That is, the tester is responsible not only for guaranteeing that the functionality developed matches the requirements, but also considers the application as a whole, how users will interact with it, and any deficiencies that may be present. A developer usually restricts himself to testing things pertinent to the code being written; a tester is not confined but rather, freely tackles the anything relevant to the story on hand.
 
--Kaleb

http://twitter.com/kalebpederson
http://kalebpederson.com

[Adam Sroka-3]

On Fri, Oct 9, 2009 at 9:01 PM, Kaleb Pederson <kaleb.pederson@...> wrote:

>
>
>
> On Friday 09 October 2009 05:15:13 pm Adam Sroka wrote:
> > On Fri, Oct 9, 2009 at 5:05 PM, jamescladd <james_ladd@...> wrote:
> > >
> > >
> > >
> > > Hi All,
> > >
> > > While helping a team transition to using TDD I was asked the question,
> > > "What is the role of a tester in a Team that does TDD?"
> > >
> > > I have my opinions but I very interested to hear yours.
> > >
>
> Good question James.
>
> > Programmers aren't good at finding all of the corner and edge cases
> > that need to be tested, because programmers don't think in terms of
> > how to break things. A programmer who understands TDD will just write
> > the test cases he needs to elicit the behavior that he wants. A tester
> > will write as many test cases as he can think of for every little
> > contingency. Things you and I wouldn't consider.
> >
> > Testers know how to write functional tests. Functional tests are slow.
> > Programmers know how to write unit tests. Unit tests are fast.
> >
> > So, testers left to their own devices will create a comprehensive
> > suite of slow tests that covers every contingency. Programmers left to
> > their own devices will write a small suite of unit tests that cover
> > interesting behaviors.
> >
> > What we really want is a comprehensive set of fast unit tests and a
> > small, representative set of functional acceptance tests that just
> > cover the important business cases. The only way we'll get there is to
> > help each other. Testers help programmers to make their unit tests
> > comprehensive. Programmers and testers help customers to create a set
> > of functional tests that cover the scenarios with important business
> > implications. The end product is a fast build with good coverage that
> > we can run all the time and that fails quickly whenever something is
> > broken.
>
> Well stated Adam.
>
> I disagree on a few fronts but agree that a capable tester brings strengths developers don't usually have.
>
> To clarify a bit, a tester brings in not only a good understanding of edge cases and knowledge allowing the application to be well tested fairly quickly, but also maintains more of an overarching view and understanding. That is, the tester is responsible not only for guaranteeing that the functionality developed matches the requirements, but also considers the application as a whole, how users will interact with it, and any deficiencies that may be present. A developer usually restricts himself to testing things pertinent to the code being written; a tester is not confined but rather, freely tackles the anything relevant to the story on hand.
>

I don't think that clarifies anything I said. I was deliberately
trying to offer a balanced perspective on how testers and programmers
could help each other to produce working software *in the context of
TDD*. I didn't claim that those were the only things testers brought
to the table. I don't agree that testers are relatively "unconfined."
Testers are kind of like managers - they can assess quality but they
can't create it.

[Kaleb Pederson-2]

On Friday 09 October 2009 09:34:46 pm Adam Sroka wrote:

> > Well stated Adam.
> >
> > I disagree on a few fronts but agree that a capable tester brings strengths developers don't usually have.
> >
> > To clarify a bit, a tester brings in not only a good understanding of edge cases and knowledge allowing the application to be well tested fairly quickly, but also maintains more of an overarching view and understanding. That is, the tester is responsible not only for guaranteeing that the functionality developed matches the requirements, but also considers the application as a whole, how users will interact with it, and any deficiencies that may be present. A developer usually restricts himself to testing things pertinent to the code being written; a tester is not confined but rather, freely tackles the anything relevant to the story on hand.
> >
>
> I don't think that clarifies anything I said. I was deliberately
> trying to offer a balanced perspective on how testers and programmers
> could help each other to produce working software *in the context of
> TDD*. I didn't claim that those were the only things testers brought
> to the table. I don't agree that testers are relatively "unconfined."
> Testers are kind of like managers - they can assess quality but they
> can't create it.

I was trying to clarify where I disagreed, not trying to clarify anything you stated.

Your above statement "*in the context of TDD*" clarifies where you are coming from and, in that light, your statement makes more sense.  I must admit that I thought this message was posted to the agile-testing list rather than the TDD list, so I forgot about that context.

I really do think testers should not be confined in any way.  Rather the tester should be free to test anything relevant to the in-process story.

Personally, the statement "they can assess quality but they can't create it" really bothers me.  Admittedly, that may be true in some organizations, but it feels like a cop out or lazy excuse.   The tester inculcates quality as a fundamental desirable characteristic.  The tester, especially an agile tester, helps design and create that quality even from before a story starts, working to define requirements, and later by sitting developers, sharing thoughts, carefully considering the users' needs, and doing manual and automated testing.

The tester doesn't abdicate responsibility for quality but instead offers his complete opinion, even if the developers don't like it.  The tester should be able to raise a red flag in the middle of a story, when necessary, and tell everybody what's wrong.  It then becomes the teams responsibility and decision. If a tester doesn't do this when he knows he should, then he is just as responsible as everybody else for whatever quality, or lack thereof, may be present.

--Kaleb

http://twitter.com/kalebpederson
http://kalebpederson.com

[Adam Sroka-3]

On Fri, Oct 9, 2009 at 10:18 PM, Kaleb Pederson
<kaleb.pederson@...> wrote:

>
>
>
> On Friday 09 October 2009 09:34:46 pm Adam Sroka wrote:
> > > Well stated Adam.
> > >
> > > I disagree on a few fronts but agree that a capable tester brings strengths developers don't usually have.
> > >
> > > To clarify a bit, a tester brings in not only a good understanding of edge cases and knowledge allowing the application to be well tested fairly quickly, but also maintains more of an overarching view and understanding. That is, the tester is responsible not only for guaranteeing that the functionality developed matches the requirements, but also considers the application as a whole, how users will interact with it, and any deficiencies that may be present. A developer usually restricts himself to testing things pertinent to the code being written; a tester is not confined but rather, freely tackles the anything relevant to the story on hand.
> > >
> >
> > I don't think that clarifies anything I said. I was deliberately
> > trying to offer a balanced perspective on how testers and programmers
> > could help each other to produce working software *in the context of
> > TDD*. I didn't claim that those were the only things testers brought
> > to the table. I don't agree that testers are relatively "unconfined."
> > Testers are kind of like managers - they can assess quality but they
> > can't create it.
>
> I was trying to clarify where I disagreed, not trying to clarify anything you stated.
>

That makes sense.

> Your above statement "*in the context of TDD*" clarifies where you are coming from and, in that light, your statement makes more sense. I must admit that I thought this message was posted to the agile-testing list rather than the TDD list, so I forgot about that context.
>

Ok.

> I really do think testers should not be confined in any way. Rather the tester should be free to test anything relevant to the in-process story.
>

I misunderstood what you were trying to say, but now that I think I
understand it better I still don't really agree. I think that both
testers and programmers are responsible for the big picture. I think
that both testers and programmers should focus on the task at hand
when working together on that task.

> Personally, the statement "they can assess quality but they can't create it" really bothers me. Admittedly, that may be true in some organizations, but it feels like a cop out or lazy excuse. The tester inculcates quality as a fundamental desirable characteristic. The tester, especially an agile tester, helps design and create that quality even from before a story starts, working to define requirements, and later by sitting developers, sharing thoughts, carefully considering the users' needs, and doing manual and automated testing.
>

I don't see those as independent functions of a tester. I see those as
functions of the Whole Team. My point was that testers can't create
working software by themselves. Programmers can, they just aren't
likely to do a very good job without the additional insights.

> The tester doesn't abdicate responsibility for quality but instead offers his complete opinion, even if the developers don't like it. The tester should be able to raise a red flag in the middle of a story, when necessary, and tell everybody what's wrong. It then becomes the teams responsibility and decision. If a tester doesn't do this when he knows he should, then he is just as responsible as everybody else for whatever quality, or lack thereof, may be present.
>

Sure, because on an Agile team the whole team is responsible for
delivering or not. Individuals don't fail; the team fails when
individuals don't collaborate.

[Kaleb Pederson-2]

Adam,

In reading through your comments, I agree completely.

Thanks for clarifying.

--Kaleb

http://twitter.com/kalebpederson
http://kalebpederson.com

On Friday 09 October 2009 10:34:23 pm Adam Sroka wrote:

> On Fri, Oct 9, 2009 at 10:18 PM, Kaleb Pederson
> <kaleb.pederson@...> wrote:
> >
> >
> >
> > On Friday 09 October 2009 09:34:46 pm Adam Sroka wrote:
> > > > Well stated Adam.
> > > >
> > > > I disagree on a few fronts but agree that a capable tester brings strengths developers don't usually have.
> > > >
> > > > To clarify a bit, a tester brings in not only a good understanding of edge cases and knowledge allowing the application to be well tested fairly quickly, but also maintains more of an overarching view and understanding. That is, the tester is responsible not only for guaranteeing that the functionality developed matches the requirements, but also considers the application as a whole, how users will interact with it, and any deficiencies that may be present. A developer usually restricts himself to testing things pertinent to the code being written; a tester is not confined but rather, freely tackles the anything relevant to the story on hand.
> > > >
> > >
> > > I don't think that clarifies anything I said. I was deliberately
> > > trying to offer a balanced perspective on how testers and programmers
> > > could help each other to produce working software *in the context of
> > > TDD*. I didn't claim that those were the only things testers brought
> > > to the table. I don't agree that testers are relatively "unconfined."
> > > Testers are kind of like managers - they can assess quality but they
> > > can't create it.
> >
> > I was trying to clarify where I disagreed, not trying to clarify anything you stated.
> >
>
> That makes sense.
>
> > Your above statement "*in the context of TDD*" clarifies where you are coming from and, in that light, your statement makes more sense. I must admit that I thought this message was posted to the agile-testing list rather than the TDD list, so I forgot about that context.
> >
>
> Ok.
>
> > I really do think testers should not be confined in any way. Rather the tester should be free to test anything relevant to the in-process story.
> >
>
> I misunderstood what you were trying to say, but now that I think I
> understand it better I still don't really agree. I think that both
> testers and programmers are responsible for the big picture. I think
> that both testers and programmers should focus on the task at hand
> when working together on that task.
>
> > Personally, the statement "they can assess quality but they can't create it" really bothers me. Admittedly, that may be true in some organizations, but it feels like a cop out or lazy excuse. The tester inculcates quality as a fundamental desirable characteristic. The tester, especially an agile tester, helps design and create that quality even from before a story starts, working to define requirements, and later by sitting developers, sharing thoughts, carefully considering the users' needs, and doing manual and automated testing.
> >
>
> I don't see those as independent functions of a tester. I see those as
> functions of the Whole Team. My point was that testers can't create
> working software by themselves. Programmers can, they just aren't
> likely to do a very good job without the additional insights.
>
> > The tester doesn't abdicate responsibility for quality but instead offers his complete opinion, even if the developers don't like it. The tester should be able to raise a red flag in the middle of a story, when necessary, and tell everybody what's wrong. It then becomes the teams responsibility and decision. If a tester doesn't do this when he knows he should, then he is just as responsible as everybody else for whatever quality, or lack thereof, may be present.
> >
>
> Sure, because on an Agile team the whole team is responsible for
> delivering or not. Individuals don't fail; the team fails when
> individuals don't collaborate.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Adam Sroka-3]

On Fri, Oct 9, 2009 at 10:34 PM, Adam Sroka <adam.sroka@...> wrote:

> On Fri, Oct 9, 2009 at 10:18 PM, Kaleb Pederson
> <kaleb.pederson@...> wrote:
>>
>> I really do think testers should not be confined in any way. Rather the tester should be free to test anything relevant to the in-process story.
>>
>
> I misunderstood what you were trying to say, but now that I think I
> understand it better I still don't really agree. I think that both
> testers and programmers are responsible for the big picture. I think
> that both testers and programmers should focus on the task at hand
> when working together on that task.
>

P.S. except in the context of exploratory testing. When you get to the
point in a development task where you bring a running app up to see it
work then testers can and should do whatever they want to try to break
it. Whereas, programmers are likely just interested in seeing if the
thing they just changed came out the way they expected. So, in that
specific context I agree with your statement, but I'm not thrilled
with it as a general rule.

Of course, the hope is that some of that mentality is viral.
Programmers will start to think about how things could break when they
are writing them and they will get better at TDD as a result.
Likewise, testers will start to see how things work when they are
implemented and will gain additional insights as a result (Their
"black-boxes" will get a little paler ;-)