TDD - is there a role for a tester?

[seanalexaoife]

Hi,

Test Driven Development. Some articles I read describe it as testing. Some articles describe it as development.

Cem Kaner's blog says: I think that test-driven development is the most important advance in the craft of testing of the past 30 years.

Do people see a role for a 'traditional' tester in TDD?

thanks
Jim



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Matthew]

--- In agile-testing-***@public.gmane.org, "seanalexaoife" <***@...> wrote:
>
> Hi,
>
> Test Driven Development. Some articles I read describe it as testing. Some articles describe it as development.
>
> Cem Kaner's blog says: I think that test-driven development is the most important advance in the craft of testing of the past 30 years.
>
> Do people see a role for a 'traditional' tester in TDD?
>

It depends on what you mean by TDD. If you mean Kent-Beck Style, the kind he envisioned in his original paper ( http://www.xprogramming.com/testfram.htm) - well, I'd say the role of the tester is extremely limited.

A well trained traditional tester /might/ be able to pair with a dev when writing TDD-style checks for a very complex object - for example, finding boundaries equivalence classes, applying allpairs etc.

If, on the other hand, you mean the higher-level Acceptance Test Driven Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh post, then sure, I think testers have a role in that.

Does that come close to help answering the question? What more do you need?

all my best,


--matt heusser



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Peter Scheyen]

TDD is terrific for getting code right. However, you still need testing to ensure you got the right code.

In one medium-sized engineering organization (~150 team members and over 1MM LOC in a client-server system) that I was in we had a rather large traditional, manual testing organization with maybe 40 testers. As we transitioned to agile about half or more of these testers became developers (thankfully the QA VP had the foresight to hire computer science grads for testing roles). The additional software development bandwidth was used to enhance overall build, test and deploy automation. This included some TDD but certainly included overall unit testing and automated integration testing. The remaining testers set to work on improving our ability to define and implement systems integration tests and acceptance tests. These tests included scalability and longevity tests of the full system, automated deployment tests, configuration tests, live system tests (rather than using simulated telecommunications tools), etc.

Every tester that I spoke with expressed increased satisfaction with the new type of work they were doing. They moved from button pushers executing the test plans that their predecessors designed to actually using their knowledge and skills to develop software (either product or test software).

Peter Scheyen

Do you really need to print this email? Keep it on the screen.

On 2010-08-25, at 7:30 AM, Matthew wrote:

> --- In agile-testing-***@public.gmane.org, "seanalexaoife" <***@...> wrote:
> >
> > Hi,
> >
> > Test Driven Development. Some articles I read describe it as testing. Some articles describe it as development.
> >
> > Cem Kaner's blog says: I think that test-driven development is the most important advance in the craft of testing of the past 30 years.
> >
> > Do people see a role for a 'traditional' tester in TDD?
> >
>
> It depends on what you mean by TDD. If you mean Kent-Beck Style, the kind he envisioned in his original paper ( http://www.xprogramming.com/testfram.htm) - well, I'd say the role of the tester is extremely limited.
>
> A well trained traditional tester /might/ be able to pair with a dev when writing TDD-style checks for a very complex object - for example, finding boundaries equivalence classes, applying allpairs etc.
>
> If, on the other hand, you mean the higher-level Acceptance Test Driven Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh post, then sure, I think testers have a role in that.
>
> Does that come close to help answering the question? What more do you need?
>
> all my best,
>
> --matt heusser
>
>

[aidy lewis]

matt heusser wrote:

> If, on the other hand, you mean the higher-level Acceptance Test Driven
Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh
post, then sure, I think testers have a role in that.

BDD includes the testing\specify\implementing of a unit and system at around
the same time by the same people. BDD is 'TDD done right'.

1) Run a pending\failing scenario step
2) Write a unit test that constitutes some of that scenario step
3) Pass that test with implementation code
4) Refactor
5) Write another unit test that constitutes some of that scenario step
6) Pass that test with implementation code
7) Refactor
8) Write enough unit tests and code to pass that scenario step
9) Continue to all scenarios\features pass automatically

If a tester writes tests and production code with a developer he\she is a
developer. Do not see testing (i.e. specifying) and development
as separate activities.

Aidy





On 25 August 2010 12:30, Matthew <matt.heusser-***@public.gmane.org> wrote:

>
>
> --- In agile-testing-***@public.gmane.org <agile-testing%40yahoogroups.com>,
> "seanalexaoife" <***@...> wrote:
> >
> > Hi,
> >
> > Test Driven Development. Some articles I read describe it as testing.
> Some articles describe it as development.
> >
> > Cem Kaner's blog says: I think that test-driven development is the most
> important advance in the craft of testing of the past 30 years.
> >
> > Do people see a role for a 'traditional' tester in TDD?
> >
>
> It depends on what you mean by TDD. If you mean Kent-Beck Style, the kind
> he envisioned in his original paper (
> http://www.xprogramming.com/testfram.htm) - well, I'd say the role of the
> tester is extremely limited.
>
> A well trained traditional tester /might/ be able to pair with a dev when
> writing TDD-style checks for a very complex object - for example, finding
> boundaries equivalence classes, applying allpairs etc.
>
> If, on the other hand, you mean the higher-level Acceptance Test Driven
> Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh
> post, then sure, I think testers have a role in that.
>
> Does that come close to help answering the question? What more do you need?
>
> all my best,
>
> --matt heusser
>
>
>

[lunivore]

I hope you don't mind me stepping into a list I don't normally follow. I'd like to offer a slightly different perspective on BDD.

BDD is now full-stack, since Feature Injection takes it into the analysis space. Scenarios and class-level examples cover the areas you're talking about. Ideally, BDD's focus is on the discovery of stuff we didn't know about, particularly around the contexts in which scenarios or examples take place. This is where using words like "should" and "behaviour" come in, rather than "test" - because for most people "test" presupposes that we know what the behaviour ought to be. "Should" lets us ask, "Should it? Really? Is there a context which we're missing in which it behaves differently?"

With the best efforts in the world we still miss contexts sometimes, and there are still scenarios we haven't thought of. Exploratory testing often uncovers these and it's the most important thing that testers do for me.

I think of "Tester" as a role rather than a person, and the patience and thoroughness which comes with it means that it's a specialist skill or mindset which I'm less good at. So yes, I'd say there are roles for a tester both in and after BDD.

Where unit-level TDD is concerned, one of the most valuable things a tester does is to describe the context in which they're seeing the unexpected outcome. When I find the piece of code that's misbehaving, I can then translate that context into another example at the class level. They can also help me to stay on track with the business language used.

Sorry for the long post. There's a lot of misunderstandings around BDD at the moment, and I hope this helps and explains why it's a bit more than just "TDD done right".

Liz.

--- In agile-testing-***@public.gmane.org, aidy lewis <***@...> wrote:
>
> matt heusser wrote:
>
> > If, on the other hand, you mean the higher-level Acceptance Test Driven
> Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh
> post, then sure, I think testers have a role in that.
>
> BDD includes the testing\specify\implementing of a unit and system at around
> the same time by the same people. BDD is 'TDD done right'.
>
> 1) Run a pending\failing scenario step
> 2) Write a unit test that constitutes some of that scenario step
> 3) Pass that test with implementation code
> 4) Refactor
> 5) Write another unit test that constitutes some of that scenario step
> 6) Pass that test with implementation code
> 7) Refactor
> 8) Write enough unit tests and code to pass that scenario step
> 9) Continue to all scenarios\features pass automatically
>
> If a tester writes tests and production code with a developer he\she is a
> developer. Do not see testing (i.e. specifying) and development
> as separate activities.
>
> Aidy
>
>
>
>
>
> On 25 August 2010 12:30, Matthew <***@...> wrote:
>
> >
> >
> > --- In agile-testing-***@public.gmane.org <agile-testing%40yahoogroups.com>,
> > "seanalexaoife" <coyle.james@> wrote:
> > >
> > > Hi,
> > >
> > > Test Driven Development. Some articles I read describe it as testing.
> > Some articles describe it as development.
> > >
> > > Cem Kaner's blog says: I think that test-driven development is the most
> > important advance in the craft of testing of the past 30 years.
> > >
> > > Do people see a role for a 'traditional' tester in TDD?
> > >
> >
> > It depends on what you mean by TDD. If you mean Kent-Beck Style, the kind
> > he envisioned in his original paper (
> > http://www.xprogramming.com/testfram.htm) - well, I'd say the role of the
> > tester is extremely limited.
> >
> > A well trained traditional tester /might/ be able to pair with a dev when
> > writing TDD-style checks for a very complex object - for example, finding
> > boundaries equivalence classes, applying allpairs etc.
> >
> > If, on the other hand, you mean the higher-level Acceptance Test Driven
> > Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh
> > post, then sure, I think testers have a role in that.
> >
> > Does that come close to help answering the question? What more do you need?
> >
> > all my best,
> >
> > --matt heusser
> >
> >
> >
>




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Lisa Crispin]

Thanks, Liz, this is enlightening for me. My BDD experience is still
lacking. I'm not sure I really understand the term "feature injection". So
I'm glad to read more about it, and agree with what you wrote here.
-- Lisa

On Sun, Aug 29, 2010 at 8:14 AM, lunivore <liz-feaWr++ZiaVWk0Htik3J/***@public.gmane.org> wrote:

>
>
> I hope you don't mind me stepping into a list I don't normally follow. I'd
> like to offer a slightly different perspective on BDD.
>
> BDD is now full-stack, since Feature Injection takes it into the analysis
> space. Scenarios and class-level examples cover the areas you're talking
> about. Ideally, BDD's focus is on the discovery of stuff we didn't know
> about, particularly around the contexts in which scenarios or examples take
> place. This is where using words like "should" and "behaviour" come in,
> rather than "test" - because for most people "test" presupposes that we know
> what the behaviour ought to be. "Should" lets us ask, "Should it? Really? Is
> there a context which we're missing in which it behaves differently?"
>
> With the best efforts in the world we still miss contexts sometimes, and
> there are still scenarios we haven't thought of. Exploratory testing often
> uncovers these and it's the most important thing that testers do for me.
>
> I think of "Tester" as a role rather than a person, and the patience and
> thoroughness which comes with it means that it's a specialist skill or
> mindset which I'm less good at. So yes, I'd say there are roles for a tester
> both in and after BDD.
>
> Where unit-level TDD is concerned, one of the most valuable things a tester
> does is to describe the context in which they're seeing the unexpected
> outcome. When I find the piece of code that's misbehaving, I can then
> translate that context into another example at the class level. They can
> also help me to stay on track with the business language used.
>
> Sorry for the long post. There's a lot of misunderstandings around BDD at
> the moment, and I hope this helps and explains why it's a bit more than just
> "TDD done right".
>
> Liz.
>
>
> --- In agile-testing-***@public.gmane.org <agile-testing%40yahoogroups.com>,
> aidy lewis <***@...> wrote:
> >
> > matt heusser wrote:
> >
> > > If, on the other hand, you mean the higher-level Acceptance Test Driven
> > Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh
> > post, then sure, I think testers have a role in that.
> >
> > BDD includes the testing\specify\implementing of a unit and system at
> around
> > the same time by the same people. BDD is 'TDD done right'.
> >
> > 1) Run a pending\failing scenario step
> > 2) Write a unit test that constitutes some of that scenario step
> > 3) Pass that test with implementation code
> > 4) Refactor
> > 5) Write another unit test that constitutes some of that scenario step
> > 6) Pass that test with implementation code
> > 7) Refactor
> > 8) Write enough unit tests and code to pass that scenario step
> > 9) Continue to all scenarios\features pass automatically
> >
> > If a tester writes tests and production code with a developer he\she is a
> > developer. Do not see testing (i.e. specifying) and development
> > as separate activities.
> >
> > Aidy
> >
> >
> >
> >
> >
> > On 25 August 2010 12:30, Matthew <***@...> wrote:
> >
> > >
> > >
> > > --- In agile-testing-***@public.gmane.org <agile-testing%40yahoogroups.com><agile-testing%
> 40yahoogroups.com>,
>
> > > "seanalexaoife" <coyle.james@> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Test Driven Development. Some articles I read describe it as testing.
> > > Some articles describe it as development.
> > > >
> > > > Cem Kaner's blog says: I think that test-driven development is the
> most
> > > important advance in the craft of testing of the past 30 years.
> > > >
> > > > Do people see a role for a 'traditional' tester in TDD?
> > > >
> > >
> > > It depends on what you mean by TDD. If you mean Kent-Beck Style, the
> kind
> > > he envisioned in his original paper (
> > > http://www.xprogramming.com/testfram.htm) - well, I'd say the role of
> the
> > > tester is extremely limited.
> > >
> > > A well trained traditional tester /might/ be able to pair with a dev
> when
> > > writing TDD-style checks for a very complex object - for example,
> finding
> > > boundaries equivalence classes, applying allpairs etc.
> > >
> > > If, on the other hand, you mean the higher-level Acceptance Test Driven
> > > Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh
> > > post, then sure, I think testers have a role in that.
> > >
> > > Does that come close to help answering the question? What more do you
> need?
> > >
> > > all my best,
> > >
> > > --matt heusser
> > >
> > >
> > >
> >
>
>
>



--
Lisa Crispin
Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
and Agile Teams_ (Addison-Wesley 2009)
Contributor to _Beautiful Testing_ (O'Reilly 2009)
http://lisacrispin.com
@lisacrispin on Twitter

[Elizabeth Keogh]

Chris Matts came up with the term and it got anchored before he could change
it. It's related to Dependency Injection, in which we pull in dependencies
for a class because we need them. It makes sense to developers!

You could read this for more info:
http://www.infoq.com/articles/pulling-power - or get hold of a copy of
Chris's amazing comic book.

>From a testing perspective, checking that the application allows us to
achieve the vision we set out to achieve in the first place would be great.
My challenge to the testers is: help us change the way things are now so
that extra work, beyond that necessary to the core vision, is also perceived
as a lack in quality. (I know that you might see it that way; I want the
message to be more pervasive!)

Cheers,
Liz.

On Mon, Aug 30, 2010 at 12:11 PM, Lisa Crispin <lisa.crispin-***@public.gmane.org>wrote:

>
>
> Thanks, Liz, this is enlightening for me. My BDD experience is still
> lacking. I'm not sure I really understand the term "feature injection". So
> I'm glad to read more about it, and agree with what you wrote here.
> -- Lisa
>
> On Sun, Aug 29, 2010 at 8:14 AM, lunivore <liz-feaWr++ZiaVWk0Htik3J/***@public.gmane.org> wrote:
>
>>
>>
>> I hope you don't mind me stepping into a list I don't normally follow. I'd
>> like to offer a slightly different perspective on BDD.
>>
>> BDD is now full-stack, since Feature Injection takes it into the analysis
>> space. Scenarios and class-level examples cover the areas you're talking
>> about. Ideally, BDD's focus is on the discovery of stuff we didn't know
>> about, particularly around the contexts in which scenarios or examples take
>> place. This is where using words like "should" and "behaviour" come in,
>> rather than "test" - because for most people "test" presupposes that we know
>> what the behaviour ought to be. "Should" lets us ask, "Should it? Really? Is
>> there a context which we're missing in which it behaves differently?"
>>
>> With the best efforts in the world we still miss contexts sometimes, and
>> there are still scenarios we haven't thought of. Exploratory testing often
>> uncovers these and it's the most important thing that testers do for me.
>>
>> I think of "Tester" as a role rather than a person, and the patience and
>> thoroughness which comes with it means that it's a specialist skill or
>> mindset which I'm less good at. So yes, I'd say there are roles for a tester
>> both in and after BDD.
>>
>> Where unit-level TDD is concerned, one of the most valuable things a
>> tester does is to describe the context in which they're seeing the
>> unexpected outcome. When I find the piece of code that's misbehaving, I can
>> then translate that context into another example at the class level. They
>> can also help me to stay on track with the business language used.
>>
>> Sorry for the long post. There's a lot of misunderstandings around BDD at
>> the moment, and I hope this helps and explains why it's a bit more than just
>> "TDD done right".
>>
>> Liz.
>>
>>
>> --- In agile-testing-***@public.gmane.org <agile-testing%40yahoogroups.com>,
>> aidy lewis <***@...> wrote:
>> >
>> > matt heusser wrote:
>> >
>> > > If, on the other hand, you mean the higher-level Acceptance Test
>> Driven
>> > Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh
>> > post, then sure, I think testers have a role in that.
>> >
>> > BDD includes the testing\specify\implementing of a unit and system at
>> around
>> > the same time by the same people. BDD is 'TDD done right'.
>> >
>> > 1) Run a pending\failing scenario step
>> > 2) Write a unit test that constitutes some of that scenario step
>> > 3) Pass that test with implementation code
>> > 4) Refactor
>> > 5) Write another unit test that constitutes some of that scenario step
>> > 6) Pass that test with implementation code
>> > 7) Refactor
>> > 8) Write enough unit tests and code to pass that scenario step
>> > 9) Continue to all scenarios\features pass automatically
>> >
>> > If a tester writes tests and production code with a developer he\she is
>> a
>> > developer. Do not see testing (i.e. specifying) and development
>> > as separate activities.
>> >
>> > Aidy
>> >
>> >
>> >
>> >
>> >
>> > On 25 August 2010 12:30, Matthew <***@...> wrote:
>> >
>> > >
>> > >
>> > > --- In agile-testing-***@public.gmane.org<agile-testing%40yahoogroups.com><agile-testing%
>> 40yahoogroups.com>,
>>
>> > > "seanalexaoife" <coyle.james@> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > Test Driven Development. Some articles I read describe it as
>> testing.
>> > > Some articles describe it as development.
>> > > >
>> > > > Cem Kaner's blog says: I think that test-driven development is the
>> most
>> > > important advance in the craft of testing of the past 30 years.
>> > > >
>> > > > Do people see a role for a 'traditional' tester in TDD?
>> > > >
>> > >
>> > > It depends on what you mean by TDD. If you mean Kent-Beck Style, the
>> kind
>> > > he envisioned in his original paper (
>> > > http://www.xprogramming.com/testfram.htm) - well, I'd say the role of
>> the
>> > > tester is extremely limited.
>> > >
>> > > A well trained traditional tester /might/ be able to pair with a dev
>> when
>> > > writing TDD-style checks for a very complex object - for example,
>> finding
>> > > boundaries equivalence classes, applying allpairs etc.
>> > >
>> > > If, on the other hand, you mean the higher-level Acceptance Test
>> Driven
>> > > Development, or the BDD as implied by the recent SkillsMatter/Liz
>> Keogh
>> > > post, then sure, I think testers have a role in that.
>> > >
>> > > Does that come close to help answering the question? What more do you
>> need?
>> > >
>> > > all my best,
>> > >
>> > > --matt heusser
>> > >
>> > >
>> > >
>> >
>>
>>
>
>
> --
> Lisa Crispin
> Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
> and Agile Teams_ (Addison-Wesley 2009)
> Contributor to _Beautiful Testing_ (O'Reilly 2009)
> http://lisacrispin.com
> @lisacrispin on Twitter
>
>
>



--
--
Elizabeth Keogh
liz-feaWr++ZiaVWk0Htik3J/***@public.gmane.org
http://lizkeogh.com
http://lunivore.com

[Lisa Crispin]

Thanks, that is an awesome post. I have just sent it to some of my teammates
and our PO, I would really like to try that story format, focusing more on
value, and a more BDD approach. We want to convert our FitNesse fixtures to
Slim so we could use Scenario tables and be able to use a BDD style in our
FitNesse tests. Unfortunately we have a lot of fixtures so it will take
awhile. But sometimes I write up test cases in text with a BDD style just to
try to get people thinking that way.
-- Lisa

On Mon, Aug 30, 2010 at 11:23 AM, Elizabeth Keogh <liz-feaWr++ZiaVWk0Htik3J/***@public.gmane.org> wrote:

>
>
> Chris Matts came up with the term and it got anchored before he could
> change it. It's related to Dependency Injection, in which we pull in
> dependencies for a class because we need them. It makes sense to developers!
>
> You could read this for more info:
> http://www.infoq.com/articles/pulling-power - or get hold of a copy of
> Chris's amazing comic book.
>
> From a testing perspective, checking that the application allows us to
> achieve the vision we set out to achieve in the first place would be great.
> My challenge to the testers is: help us change the way things are now so
> that extra work, beyond that necessary to the core vision, is also perceived
> as a lack in quality. (I know that you might see it that way; I want the
> message to be more pervasive!)
>
> Cheers,
> Liz.
>
> On Mon, Aug 30, 2010 at 12:11 PM, Lisa Crispin <lisa.crispin-***@public.gmane.org>wrote:
>
>>
>>
>> Thanks, Liz, this is enlightening for me. My BDD experience is still
>> lacking. I'm not sure I really understand the term "feature injection". So
>> I'm glad to read more about it, and agree with what you wrote here.
>> -- Lisa
>>
>> On Sun, Aug 29, 2010 at 8:14 AM, lunivore <liz-feaWr++ZiaVWk0Htik3J/***@public.gmane.org> wrote:
>>
>>>
>>>
>>> I hope you don't mind me stepping into a list I don't normally follow.
>>> I'd like to offer a slightly different perspective on BDD.
>>>
>>> BDD is now full-stack, since Feature Injection takes it into the analysis
>>> space. Scenarios and class-level examples cover the areas you're talking
>>> about. Ideally, BDD's focus is on the discovery of stuff we didn't know
>>> about, particularly around the contexts in which scenarios or examples take
>>> place. This is where using words like "should" and "behaviour" come in,
>>> rather than "test" - because for most people "test" presupposes that we know
>>> what the behaviour ought to be. "Should" lets us ask, "Should it? Really? Is
>>> there a context which we're missing in which it behaves differently?"
>>>
>>> With the best efforts in the world we still miss contexts sometimes, and
>>> there are still scenarios we haven't thought of. Exploratory testing often
>>> uncovers these and it's the most important thing that testers do for me.
>>>
>>> I think of "Tester" as a role rather than a person, and the patience and
>>> thoroughness which comes with it means that it's a specialist skill or
>>> mindset which I'm less good at. So yes, I'd say there are roles for a tester
>>> both in and after BDD.
>>>
>>> Where unit-level TDD is concerned, one of the most valuable things a
>>> tester does is to describe the context in which they're seeing the
>>> unexpected outcome. When I find the piece of code that's misbehaving, I can
>>> then translate that context into another example at the class level. They
>>> can also help me to stay on track with the business language used.
>>>
>>> Sorry for the long post. There's a lot of misunderstandings around BDD at
>>> the moment, and I hope this helps and explains why it's a bit more than just
>>> "TDD done right".
>>>
>>> Liz.
>>>
>>>
>>> --- In agile-testing-***@public.gmane.org <agile-testing%40yahoogroups.com>,
>>> aidy lewis <***@...> wrote:
>>> >
>>> > matt heusser wrote:
>>> >
>>> > > If, on the other hand, you mean the higher-level Acceptance Test
>>> Driven
>>> > Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh
>>> > post, then sure, I think testers have a role in that.
>>> >
>>> > BDD includes the testing\specify\implementing of a unit and system at
>>> around
>>> > the same time by the same people. BDD is 'TDD done right'.
>>> >
>>> > 1) Run a pending\failing scenario step
>>> > 2) Write a unit test that constitutes some of that scenario step
>>> > 3) Pass that test with implementation code
>>> > 4) Refactor
>>> > 5) Write another unit test that constitutes some of that scenario step
>>> > 6) Pass that test with implementation code
>>> > 7) Refactor
>>> > 8) Write enough unit tests and code to pass that scenario step
>>> > 9) Continue to all scenarios\features pass automatically
>>> >
>>> > If a tester writes tests and production code with a developer he\she is
>>> a
>>> > developer. Do not see testing (i.e. specifying) and development
>>> > as separate activities.
>>> >
>>> > Aidy
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On 25 August 2010 12:30, Matthew <***@...> wrote:
>>> >
>>> > >
>>> > >
>>> > > --- In agile-testing-***@public.gmane.org<agile-testing%40yahoogroups.com><agile-testing%
>>> 40yahoogroups.com>,
>>>
>>> > > "seanalexaoife" <coyle.james@> wrote:
>>> > > >
>>> > > > Hi,
>>> > > >
>>> > > > Test Driven Development. Some articles I read describe it as
>>> testing.
>>> > > Some articles describe it as development.
>>> > > >
>>> > > > Cem Kaner's blog says: I think that test-driven development is the
>>> most
>>> > > important advance in the craft of testing of the past 30 years.
>>> > > >
>>> > > > Do people see a role for a 'traditional' tester in TDD?
>>> > > >
>>> > >
>>> > > It depends on what you mean by TDD. If you mean Kent-Beck Style, the
>>> kind
>>> > > he envisioned in his original paper (
>>> > > http://www.xprogramming.com/testfram.htm) - well, I'd say the role
>>> of the
>>> > > tester is extremely limited.
>>> > >
>>> > > A well trained traditional tester /might/ be able to pair with a dev
>>> when
>>> > > writing TDD-style checks for a very complex object - for example,
>>> finding
>>> > > boundaries equivalence classes, applying allpairs etc.
>>> > >
>>> > > If, on the other hand, you mean the higher-level Acceptance Test
>>> Driven
>>> > > Development, or the BDD as implied by the recent SkillsMatter/Liz
>>> Keogh
>>> > > post, then sure, I think testers have a role in that.
>>> > >
>>> > > Does that come close to help answering the question? What more do you
>>> need?
>>> > >
>>> > > all my best,
>>> > >
>>> > > --matt heusser
>>> > >
>>> > >
>>> > >
>>> >
>>>
>>>
>>
>>
>> --
>> Lisa Crispin
>> Co-author with Janet Gregory, _Agile Testing: A Practical Guide for
>> Testers and Agile Teams_ (Addison-Wesley 2009)
>> Contributor to _Beautiful Testing_ (O'Reilly 2009)
>> http://lisacrispin.com
>> @lisacrispin on Twitter
>>
>>
>
>
> --
> --
> Elizabeth Keogh
> liz-feaWr++ZiaVWk0Htik3J/***@public.gmane.org
> http://lizkeogh.com
> http://lunivore.com
>
>



--
Lisa Crispin
Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
and Agile Teams_ (Addison-Wesley 2009)
Contributor to _Beautiful Testing_ (O'Reilly 2009)
http://lisacrispin.com
@lisacrispin on Twitter

[Coyle, Jim]

Thanks Matt. I must read up on the Acceptance Test Driven Development. I hadn't heard of that one before ...
- Jim

From: agile-testing-***@public.gmane.org [mailto:agile-testing-***@public.gmane.org] On Behalf Of Matthew
Sent: 25 August 2010 12:31
To: agile-testing-***@public.gmane.org
Subject: [agile-testing] Re: TDD - is there a role for a tester?



--- In agile-testing-***@public.gmane.org<mailto:agile-testing%40yahoogroups.com>, "seanalexaoife" <***@...<mailto:***@...>> wrote:
>
> Hi,
>
> Test Driven Development. Some articles I read describe it as testing. Some articles describe it as development.
>
> Cem Kaner's blog says: I think that test-driven development is the most important advance in the craft of testing of the past 30 years.
>
> Do people see a role for a 'traditional' tester in TDD?
>

It depends on what you mean by TDD. If you mean Kent-Beck Style, the kind he envisioned in his original paper ( http://www.xprogramming.com/testfram.htm) - well, I'd say the role of the tester is extremely limited.

A well trained traditional tester /might/ be able to pair with a dev when writing TDD-style checks for a very complex object - for example, finding boundaries equivalence classes, applying allpairs etc.

If, on the other hand, you mean the higher-level Acceptance Test Driven Development, or the BDD as implied by the recent SkillsMatter/Liz Keogh post, then sure, I think testers have a role in that.

Does that come close to help answering the question? What more do you need?

all my best,

--matt heusser


If you've received this email by mistake, we're sorry for bothering you. It may contain information that's confidential, so please delete it without sharing it. And if you let us know, we can try to stop it from happening again. Thank you.

We may monitor any emails sent or received by us, or on our behalf. If we do, this will be in line with relevant law and our own policies.

Sage Ireland, trading name of Sage Hibernia Limited. Registered in Ireland at 3096 Lake Drive, City West Business Park, Dublin 24. Registered number 300549.

[Matthew]

--- In agile-testing-***@public.gmane.org, "Coyle, Jim" <***@...> wrote:
>
> Thanks Matt. I must read up on the Acceptance Test Driven Development. I hadn't heard of that one before ...
> - Jim
>

Hey Jim. You can google around for it. It kind of makes sense:

"Hey, if TDD works so well at the developer-level, what if we did TDD at the customer level - write the specification as examples, turn them into test case, and automate them before the developers write code."

We called this higher-level TDD Acceptance Test Driven Development. Antony Marcano and Elisabeth Hendrickson have done a fair bit of writing on it.

We've been having this sort of ongoing dialogue for years. Brian Marick covers a lot of the discussion relatively quickly in this video:

http://vimeo.com/2504828

The ATDD stuff comes about nine minutes in, to about seventeen minutes in. Brian does a good job of discussing the /dialogue/, although there is not a great deal consensus about where he ends up. Neither is he; he proposes an experiment! :-)

all my best,


--
Matthew Heusser
Twitter: mheusser
My Blog: http://xndev.blogspot.com
Community Blogging: http://www.stpcollaborative.com/blog




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[aidy lewis]

Hi Jim,

In an environment that operates true Behaviour Driven Development (BDD)
there is little role for an independent tester.

1) BDD includes TDD in the large (that is BDD involves the testing of unit,
integration and system externalities.
2) TDD has been one of the most important contributors to software quality.
The test is written first for various reasons. It is highly difficult for
the tester to implement a test before the developer codes production, and
pretty much useless as one of the reasons of TDD is to force design.
3) If the developer creates the system, why leave it up to the tester to
pair with the customer to specify acceptance criteria?

There are minor roles of exploratory and presentation testing for
the independent tester, but nothing much of value.

Aidy



On 25 August 2010 11:15, seanalexaoife <coyle.james-***@public.gmane.org> wrote:

>
>
> Hi,
>
> Test Driven Development. Some articles I read describe it as testing. Some
> articles describe it as development.
>
> Cem Kaner's blog says: I think that test-driven development is the most
> important advance in the craft of testing of the past 30 years.
>
> Do people see a role for a 'traditional' tester in TDD?
>
> thanks
> Jim
>
>
>

[Hubert Matthews]

aidy lewis wrote:
> In an environment that operates true Behaviour Driven Development (BDD)
> there is little role for an independent tester.

I would strongly disagree with this. By definition, BDD tests functional
behaviour and that is probably 1/3 to 1/2 of your overall system
requirements. What about performance, interoperability, stress, load,
volume, security and all the other forms of testing? I worked as a tester
on a waterfall project a while back where all of the functional tests
passed and the developers said it was ready for release but I could
deadlock the product within seconds. I could also show significant
performance issues. Fixing these issues wasn't trivial and nearly
involved throwing away a major library.

Independent testing is critical. BDD and TDD just mean that the tester
doesn't have to deal with silly functional errors, which is good, and can
concentrate on being a customer champion instead.

--
Hubert Matthews http://www.oxyware.com/
Software Consultant hubert-***@public.gmane.org




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Matthew]

aidy lewis wrote:
> In an environment that operates true
> Behaviour Driven Development (BDD)
> there is little role for an independent tester.
>

Hi Aidy!

As a context-driven tester ( http://www.context-driven-testing.com/ ) I'm willing to grant that there are /some/ environments, problems, and contexts where independent testers are not needed.

If you'd say all, where, there's always project Mercury in 1958, where not only the lives of the astronauts, but also the reputation of the 'free world' rests on the software working. (At the time, we americans were convinced in a domino effect in developing nations. If project mercury had failed, went the logic, we might lose the 'cold war.')

So I'd say that no matter how awesomz is your BDD amazing-ness, there will be some contexts where independent testers make sense.

Please tell us about the environments you've worked in doing BDD with no independent testers and how long you worked in them.

Let's reason together.

All my best,

--
Matthew Heusser
Twitter: mheusser
Blog: http://xndev.blogspot.com
Community Blog: http://www.softwaretestpro.com/blog




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[aidy lewis]

Hubert Matthews wrote,

> I would strongly disagree with this. By definition, BDD tests functional
> behaviour and that is probably 1/3 to 1/2 of your overall system
> requirements. What about performance, interoperability, stress, load,
> volume, security and all the other forms of testing?

Good-point, however I believe that non-functional requirements are indeed
expected behaviours of a system and I have previously and currently include
them in my Story Acceptance Criteria.


> I worked as a tester
> on a waterfall project a while back where all of the functional tests
> passed and the developers said it was ready for release but I could
> deadlock the product within seconds. I could also show significant
> performance issues. Fixing these issues wasn't trivial and nearly
> involved throwing away a major library.

I am sure you could Hubert. Did your developers use TDD? Were automated
functional tests a part of the operation?
There is a still a role for an exploratory tester, but I doubt that is a
full-time job.

> Independent testing is critical.

If the developers are covering the unit and acceptance tests in true BDD
style, I cannot see why?


> BDD and TDD just mean that the tester
> doesn't have to deal with silly functional errors,

The automation of the behaviour of a component, group of components and the
system is a little more then covering silly functional errors, don't you
think?


> which is good, and can concentrate on being a customer champion instead.

I personally think the customer can champion him\herself.

These are not radical ideas, Hubert, but the way I perceive things to be
moving. As a independent tester myself, I will be certainly looking at
moving roles as I cannot see a future for a tester with modern development
techniques.

Aidy

On 26 August 2010 08:47, Hubert Matthews <hubert-***@public.gmane.org> wrote:

>
>
> aidy lewis wrote:
> > In an environment that operates true Behaviour Driven Development (BDD)
> > there is little role for an independent tester.
>
> I would strongly disagree with this. By definition, BDD tests functional
> behaviour and that is probably 1/3 to 1/2 of your overall system
> requirements. What about performance, interoperability, stress, load,
> volume, security and all the other forms of testing? I worked as a tester
> on a waterfall project a while back where all of the functional tests
> passed and the developers said it was ready for release but I could
> deadlock the product within seconds. I could also show significant
> performance issues. Fixing these issues wasn't trivial and nearly
> involved throwing away a major library.
>
> Independent testing is critical. BDD and TDD just mean that the tester
> doesn't have to deal with silly functional errors, which is good, and can
> concentrate on being a customer champion instead.
>
> --
> Hubert Matthews http://www.oxyware.com/
> Software Consultant hubert-***@public.gmane.org <hubert%40oxyware.com>
>
>
>

[Hubert Matthews]

aidy lewis wrote:
> Hubert Matthews wrote,
>
>> I would strongly disagree with this. By definition, BDD tests functional
>> behaviour and that is probably 1/3 to 1/2 of your overall system
>> requirements. What about performance, interoperability, stress, load,
>> volume, security and all the other forms of testing?
>
> Good-point, however I believe that non-functional requirements are indeed
> expected behaviours of a system and I have previously and currently
> include them in my Story Acceptance Criteria.

Which of the ATDD/BDD frameworks support these requirements? All of the
ones that I know are "given/when/then" or similar. How many people in the
agile world do you know that automate these non-functional tests? How
many people get clear non-functional requirements? How many story cards
are there for them? My point is that these things are often forgotten or
they get short measure. A product is way more than the sum of its user
stories.

> Did your developers use TDD?

As I said, it was a waterfall project so no TDD. I have managed to get
them to start doing some unit tests but they are still post facto, not
TDD. When I pointed out a bug the developers ran their internal tests and
found that they were broken and had been so for about a month.

> Were automated functional tests a part of the operation?

Yes and they all passed. However, from my point of view the product was
badly broken and deadlocked often. The performance was also bad in
certain cases not covered by the functional tests. I also found bugs in
maximal configurations and potential overflow problems.

> There is a still a role for an exploratory tester, but I doubt that is a
> full-time job.

If I hadn't put in the time the company would have had very big piles of
egg on their faces. I wasn't full time but there was a full-time tester
and he was dealing with the functional tests whilst I did exploratory
testing and more obscure automated testing. Since the product was an
infrastructure product all of my testing was automated and I wrote
programs to break it.

>> Independent testing is critical.
>
> If the developers are covering the unit and acceptance tests in true BDD
> style, I cannot see why?

Automated tests show that the application conforms to some mental model of
desirable behaviour. What happens if the model is wrong or incomplete?
What happens if the "real" requirements are different from the stated
requirements? What about the implicit requirements that customers have
that they never mention?

>> BDD and TDD just mean that the tester
>> doesn't have to deal with silly functional errors,
>
> The automation of the behaviour of a component, group of components and
> the
> system is a little more then covering silly functional errors, don't you
> think?

I wrote a number of sophisticated automated tests that broke the product
in important ways, ways that weren't explicitly stated but were important
to customers.

>> which is good, and can concentrate on being a customer champion instead.
>
> I personally think the customer can champion him\herself.

So what do you do when you are producing a shrink-wrap product for
customers that you will never meet? Customers in different countries?

> These are not radical ideas, Hubert, but the way I perceive things to be
> moving. As a independent tester myself, I will be certainly looking at
> moving roles as I cannot see a future for a tester with modern development
> techniques.

I'm sorry that you think that way. It sounds like you're used to fixing
silly bugs and not doing value-based testing. Perhaps you might like to
investigate the ideas behind the context-driven school of testing. You
might just conclude that testing is way more important and challenging
than you do now.

--
Hubert Matthews http://www.oxyware.com/
Software Consultant hubert-***@public.gmane.org




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[aidy lewis]

Hubert Matthews wrote,

> Which of the ATDD/BDD frameworks support these requirements? All of the
> ones that I know are "given/when/then" or similar.

I have no reason to believe G\W\T cannot be used for non-functional
requirements and driven with Cucumber and threads or JMeter or the like.


> How many people get clear non-functional requirements? How many story
cards
> are there for them? My point is that these things are often forgotten or
> they get short measure. A product is way more than the sum of its user
> stories.

It is imperative that performance criteria is specified before
implementation so the developer can include this into his\her design. I
would suggest this, which would hopefully then be included into the
developer's routine.


> As I said, it was a waterfall project so no TDD. I have managed to get
> them to start doing some unit tests but they are still post facto, not
> TDD. When I pointed out a bug the developers ran their internal tests and
> found that they were broken and had been so for about a month.

Without TDD testers face an almost inpossible task. TDD includes CI. These
tests should run automatically upon check-in (at least).


> Yes and they all passed. However, from my point of view the product was
> badly broken and deadlocked often. The performance was also bad in
> certain cases not covered by the functional tests. I also found bugs in
> maximal configurations and potential overflow problems.

These problems may occur when tests are not written before production code.


> Automated tests show that the application conforms to some mental model of
> desirable behaviour. What happens if the model is wrong or incomplete?
> What happens if the "real" requirements are different from the stated
> requirements? What about the implicit requirements that customers have
> that they never mention?

I would expect the customer to view working sofware after each iteration.
Language itself is a near miss when constructing reality.


> I wrote a number of sophisticated automated tests that broke the product
> in important ways, ways that weren't explicitly stated but were important
> to customers.

Acceptance tests specify and test just enough for the customer to be happy.
Nothing more. These limits I believe allow short iterative development.


> So what do you do when you are producing a shrink-wrap product for
> customers that you will never meet? Customers in different countries?

You create personas to represent specific customers.


Aidy

[Janet Gregory]

I've been watching this discussion before I jumped in. I do believe testers
have a place on agile teams and more than only exploratory testing (though
that is a huge part). I have worked only with one team who thought they
could get by without a tester, and at the end of a year, one of the
developers wrote an experience paper stating why a tester was so important
to have as part of the team.



Even in BDD, they use analysts to help create the scenarios and flush out
the tests. If a team doesn't have a BA, testers fill that role. Testers may
not even need to be 'technical', though it does help. It is the critical
thinking and the big picture outlook that they provide which is invaluable.
On a large system, all performance and security, interoperability, etc...,
(quadrant 4 tests), cannot be done on a story level only.



I would suggest being very careful about making sweeping statements. Testers
have lots to offer on agile teams and I'm sure they will be around for a
very long time.



Janet Gregory

Co-author with Lisa Crispin, Agile Testing: A Practical Guide for Testers
and Agile Teams (Addison-Wesley 2009)



www.janetgregory.ca







From: agile-testing-***@public.gmane.org [mailto:agile-testing-***@public.gmane.org]
On Behalf Of aidy lewis
Sent: Thursday, August 26, 2010 11:35 AM
To: agile-testing-***@public.gmane.org
Subject: Re: [agile-testing] TDD - is there a role for a tester?





Hubert Matthews wrote,



> Which of the ATDD/BDD frameworks support these requirements? All of the

> ones that I know are "given/when/then" or similar.



I have no reason to believe G\W\T cannot be used for non-functional
requirements and driven with Cucumber and threads or JMeter or the like.





> How many people get clear non-functional requirements? How many story
cards

> are there for them? My point is that these things are often forgotten or

> they get short measure. A product is way more than the sum of its user

> stories.



It is imperative that performance criteria is specified before
implementation so the developer can include this into his\her design. I
would suggest this, which would hopefully then be included into the
developer's routine.





> As I said, it was a waterfall project so no TDD. I have managed to get

> them to start doing some unit tests but they are still post facto, not

> TDD. When I pointed out a bug the developers ran their internal tests and

> found that they were broken and had been so for about a month.



Without TDD testers face an almost inpossible task. TDD includes CI. These
tests should run automatically upon check-in (at least).





> Yes and they all passed. However, from my point of view the product was

> badly broken and deadlocked often. The performance was also bad in

> certain cases not covered by the functional tests. I also found bugs in

> maximal configurations and potential overflow problems.



These problems may occur when tests are not written before production code.





> Automated tests show that the application conforms to some mental model of

> desirable behaviour. What happens if the model is wrong or incomplete?

> What happens if the "real" requirements are different from the stated

> requirements? What about the implicit requirements that customers have

> that they never mention?



I would expect the customer to view working sofware after each iteration.
Language itself is a near miss when constructing reality.





> I wrote a number of sophisticated automated tests that broke the product

> in important ways, ways that weren't explicitly stated but were important

> to customers.



Acceptance tests specify and test just enough for the customer to be happy.
Nothing more. These limits I believe allow short iterative development.





> So what do you do when you are producing a shrink-wrap product for

> customers that you will never meet? Customers in different countries?



You create personas to represent specific customers.





Aidy

[aidy lewis]

As testers we have a material interest in the continuing existence of
independent testers; though this I believe to be counter Agile.

The term Agile however is now amorphous with one fork being Project
Managment Scrum\Kanban\Certification based, and another attempting to return
focus back to correct development practices and craftsmanship.

Agile Tester seems contradictory to me in that it confers the 'Tester' with
'Agility'. Agility is a software development process.

In substitution of a Business Analyst there is the tester. I have used the
'roles' interchangeably. In modern software development there is no role for
the Business Analyst. I witness developers quite adequately specifying
requirements with users.

An extrapolation of working practices is not a sweeping statement. There is
likely to be conservative resistance, as there was for example to TDD and
dynamic languages.

Aidy



On 26 August 2010 20:03, Janet Gregory <janet_gregory-***@public.gmane.org> wrote:

>
>
> I’ve been watching this discussion before I jumped in. I do believe
> testers have a place on agile teams and more than only exploratory testing
> (though that is a huge part). I have worked only with one team who thought
> they could get by without a tester, and at the end of a year, one of the
> developers wrote an experience paper stating why a tester was so important
> to have as part of the team.
>
>
>
> Even in BDD, they use analysts to help create the scenarios and flush out
> the tests. If a team doesn’t have a BA, testers fill that role. Testers may
> not even need to be ‘technical’, though it does help. It is the critical
> thinking and the big picture outlook that they provide which is invaluable.
> On a large system, all performance and security, interoperability, etc...,
> (quadrant 4 tests), cannot be done on a story level only.
>
>
>
> I would suggest being very careful about making sweeping statements.
> Testers have lots to offer on agile teams and I’m sure they will be around
> for a very long time.
>
>
>
> Janet Gregory
>
> Co-author with Lisa Crispin, Agile Testing: A Practical Guide for Testers
> and Agile Teams (Addison-Wesley 2009)
>
>
>
> www.janetgregory.ca
>
>
>
>
>
>
>
> *From:* agile-testing-***@public.gmane.org [mailto:
> agile-testing-***@public.gmane.org] *On Behalf Of *aidy lewis
> *Sent:* Thursday, August 26, 2010 11:35 AM
>
> *To:* agile-testing-***@public.gmane.org
> *Subject:* Re: [agile-testing] TDD - is there a role for a tester?
>
>
>
>
>
> Hubert Matthews wrote,
>
>
>
> > Which of the ATDD/BDD frameworks support these requirements? All of the
>
> > ones that I know are "given/when/then" or similar.
>
>
>
> I have no reason to believe G\W\T cannot be used for non-functional
> requirements and driven with Cucumber and threads or JMeter or the like.
>
>
>
>
>
> > How many people get clear non-functional requirements? How many story
> cards
>
> > are there for them? My point is that these things are often forgotten or
>
> > they get short measure. A product is way more than the sum of its user
>
> > stories.
>
>
>
> It is imperative that performance criteria is specified before
> implementation so the developer can include this into his\her design. I
> would suggest this, which would hopefully then be included into the
> developer's routine.
>
>
>
>
>
> > As I said, it was a waterfall project so no TDD. I have managed to get
>
> > them to start doing some unit tests but they are still post facto, not
>
> > TDD. When I pointed out a bug the developers ran their internal tests and
>
> > found that they were broken and had been so for about a month.
>
>
>
> Without TDD testers face an almost inpossible task. TDD includes CI. These
> tests should run automatically upon check-in (at least).
>
>
>
>
>
> > Yes and they all passed. However, from my point of view the product was
>
> > badly broken and deadlocked often. The performance was also bad in
>
> > certain cases not covered by the functional tests. I also found bugs in
>
> > maximal configurations and potential overflow problems.
>
>
>
> These problems may occur when tests are not written before production code.
>
>
>
>
>
> > Automated tests show that the application conforms to some mental model
> of
>
> > desirable behaviour. What happens if the model is wrong or incomplete?
>
> > What happens if the "real" requirements are different from the stated
>
> > requirements? What about the implicit requirements that customers have
>
> > that they never mention?
>
>
>
> I would expect the customer to view working sofware after each iteration.
> Language itself is a near miss when constructing reality.
>
>
>
>
>
> > I wrote a number of sophisticated automated tests that broke the product
>
> > in important ways, ways that weren't explicitly stated but were important
>
> > to customers.
>
>
>
> Acceptance tests specify and test just enough for the customer to be happy.
> Nothing more. These limits I believe allow short iterative development.
>
>
>
>
>
> > So what do you do when you are producing a shrink-wrap product for
>
> > customers that you will never meet? Customers in different countries?
>
>
>
> You create personas to represent specific customers.
>
>
>
>
>
> Aidy
>
>
>

[Lisa Crispin]

It's interesting to hear everyone's experiences, and I would like to remind
everyone that this is a list for sharing experiences and concrete examples
around testing on agile teams, and not for predictions of the future or
philosophical discussions.

We definitely need to work on all of our terminology. Perhaps we should
expand Gojko's efforts for coming up with common terminology
http://gojko.net/2010/08/04/lets-change-the-tune/ to include what we call
people performing different activities on a team.

Perhaps we can all agree that everyone involved in producing software is a
'developer'. "Agile Testing" and "Agile Tester" are only meant to refer to
testing activities on an agile team and the people who help perform them.
For me, more and more, I see testing and coding as two components of one
process - software development. On our team, we all get outside of what
others might think our 'roles' are. I think it's a good thing.
-- Lisa

On Thu, Aug 26, 2010 at 2:41 PM, aidy lewis <aidy.lewis-***@public.gmane.org> wrote:

>
>
> As testers we have a material interest in the continuing existence of
> independent testers; though this I believe to be counter Agile.
>
> The term Agile however is now amorphous with one fork being Project
> Managment Scrum\Kanban\Certification based, and another attempting to return
> focus back to correct development practices and craftsmanship.
>
> Agile Tester seems contradictory to me in that it confers the 'Tester' with
> 'Agility'. Agility is a software development process.
>
> In substitution of a Business Analyst there is the tester. I have used the
> 'roles' interchangeably. In modern software development there is no role for
> the Business Analyst. I witness developers quite adequately specifying
> requirements with users.
>
> An extrapolation of working practices is not a sweeping statement. There is
> likely to be conservative resistance, as there was for example to TDD and
> dynamic languages.
>
> Aidy
>
>
>
> On 26 August 2010 20:03, Janet Gregory <janet_gregory-***@public.gmane.org> wrote:
>
>>
>>
>> I’ve been watching this discussion before I jumped in. I do believe
>> testers have a place on agile teams and more than only exploratory testing
>> (though that is a huge part). I have worked only with one team who thought
>> they could get by without a tester, and at the end of a year, one of the
>> developers wrote an experience paper stating why a tester was so important
>> to have as part of the team.
>>
>>
>>
>> Even in BDD, they use analysts to help create the scenarios and flush out
>> the tests. If a team doesn’t have a BA, testers fill that role. Testers may
>> not even need to be ‘technical’, though it does help. It is the critical
>> thinking and the big picture outlook that they provide which is invaluable.
>> On a large system, all performance and security, interoperability, etc...,
>> (quadrant 4 tests), cannot be done on a story level only.
>>
>>
>>
>> I would suggest being very careful about making sweeping statements.
>> Testers have lots to offer on agile teams and I’m sure they will be around
>> for a very long time.
>>
>>
>>
>> Janet Gregory
>>
>> Co-author with Lisa Crispin, Agile Testing: A Practical Guide for Testers
>> and Agile Teams (Addison-Wesley 2009)
>>
>>
>>
>> www.janetgregory.ca
>>
>>
>>
>>
>>
>>
>>
>> *From:* agile-testing-***@public.gmane.org [mailto:
>> agile-testing-***@public.gmane.org] *On Behalf Of *aidy lewis
>> *Sent:* Thursday, August 26, 2010 11:35 AM
>>
>> *To:* agile-testing-***@public.gmane.org
>> *Subject:* Re: [agile-testing] TDD - is there a role for a tester?
>>
>>
>>
>>
>>
>> Hubert Matthews wrote,
>>
>>
>>
>> > Which of the ATDD/BDD frameworks support these requirements? All of the
>>
>> > ones that I know are "given/when/then" or similar.
>>
>>
>>
>> I have no reason to believe G\W\T cannot be used for non-functional
>> requirements and driven with Cucumber and threads or JMeter or the like.
>>
>>
>>
>>
>>
>> > How many people get clear non-functional requirements? How many story
>> cards
>>
>> > are there for them? My point is that these things are often forgotten or
>>
>> > they get short measure. A product is way more than the sum of its user
>>
>> > stories.
>>
>>
>>
>> It is imperative that performance criteria is specified before
>> implementation so the developer can include this into his\her design. I
>> would suggest this, which would hopefully then be included into the
>> developer's routine.
>>
>>
>>
>>
>>
>> > As I said, it was a waterfall project so no TDD. I have managed to get
>>
>> > them to start doing some unit tests but they are still post facto, not
>>
>> > TDD. When I pointed out a bug the developers ran their internal tests
>> and
>>
>> > found that they were broken and had been so for about a month.
>>
>>
>>
>> Without TDD testers face an almost inpossible task. TDD includes CI. These
>> tests should run automatically upon check-in (at least).
>>
>>
>>
>>
>>
>> > Yes and they all passed. However, from my point of view the product was
>>
>> > badly broken and deadlocked often. The performance was also bad in
>>
>> > certain cases not covered by the functional tests. I also found bugs in
>>
>> > maximal configurations and potential overflow problems.
>>
>>
>>
>> These problems may occur when tests are not written before production
>> code.
>>
>>
>>
>>
>>
>> > Automated tests show that the application conforms to some mental model
>> of
>>
>> > desirable behaviour. What happens if the model is wrong or incomplete?
>>
>> > What happens if the "real" requirements are different from the stated
>>
>> > requirements? What about the implicit requirements that customers have
>>
>> > that they never mention?
>>
>>
>>
>> I would expect the customer to view working sofware after each iteration.
>> Language itself is a near miss when constructing reality.
>>
>>
>>
>>
>>
>> > I wrote a number of sophisticated automated tests that broke the product
>>
>> > in important ways, ways that weren't explicitly stated but were
>> important
>>
>> > to customers.
>>
>>
>>
>> Acceptance tests specify and test just enough for the customer to be
>> happy. Nothing more. These limits I believe allow short iterative
>> development.
>>
>>
>>
>>
>>
>> > So what do you do when you are producing a shrink-wrap product for
>>
>> > customers that you will never meet? Customers in different countries?
>>
>>
>>
>> You create personas to represent specific customers.
>>
>>
>>
>>
>>
>> Aidy
>>
>>
>
>



--
Lisa Crispin
Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
and Agile Teams_ (Addison-Wesley 2009)
Contributor to _Beautiful Testing_ (O'Reilly 2009)
http://lisacrispin.com
@lisacrispin on Twitter

[Janet Gregory]

Well said Lisa,

I stand corrected. There will always be testing activities, even on agile projects. However, I find that as I am dealing with larger and larger companies who are transitioning to agile, it is very hard very hard for them to lose the terminology and titles since their organization is set up that way.

It is much simpler with smaller organizations and smaller teams to keep more 'generic' roles. When you have 5 teams all working on one product code base and an integration team trying to run full regression, performance, etc. tests across the that product, and then integrate it with several other products, there seems to be a greater need to keep some level of specific roles. Each organization is context specific, so it is hard to generalize across all.

Janet

----- Original Message -----
From: Lisa Crispin <lisa.crispin-***@public.gmane.org>
Date: Thursday, August 26, 2010 2:49 pm
Subject: Re: [agile-testing] TDD - is there a role for a tester?
To: agile-testing-***@public.gmane.org

> It's interesting to hear everyone's experiences, and I would
> like to remind
> everyone that this is a list for sharing experiences and
> concrete examples
> around testing on agile teams, and not for predictions of the
> future or
> philosophical discussions.
>
> We definitely need to work on all of our terminology. Perhaps we
> shouldexpand Gojko's efforts for coming up with common terminology
> http://gojko.net/2010/08/04/lets-change-the-tune/ to include
> what we call
> people performing different activities on a team.
>
> Perhaps we can all agree that everyone involved in producing
> software is a
> 'developer'. "Agile Testing" and "Agile Tester" are only meant
> to refer to
> testing activities on an agile team and the people who help
> perform them.
> For me, more and more, I see testing and coding as two
> components of one
> process - software development. On our team, we all get outside
> of what
> others might think our 'roles' are. I think it's a good thing.
> -- Lisa
>
> On Thu, Aug 26, 2010 at 2:41 PM, aidy lewis
> <aidy.lewis-***@public.gmane.org> wrote:
>
> >
> >
> > As testers we have a material interest in the continuing
> existence of
> > independent testers; though this I believe to be counter Agile.
> >
> > The term Agile however is now amorphous with one fork being Project
> > Managment Scrum\Kanban\Certification based, and another
> attempting to return
> > focus back to correct development practices and craftsmanship.
> >
> > Agile Tester seems contradictory to me in that it confers the
> 'Tester' with
> > 'Agility'. Agility is a software development process.
> >
> > In substitution of a Business Analyst there is the tester. I
> have used the
> > 'roles' interchangeably. In modern software development there
> is no role for
> > the Business Analyst. I witness developers quite adequately
> specifying> requirements with users.
> >
> > An extrapolation of working practices is not a sweeping
> statement. There is
> > likely to be conservative resistance, as there was for example
> to TDD and
> > dynamic languages.
> >
> > Aidy
> >
> >
> >
> > On 26 August 2010 20:03, Janet Gregory
> <janet_gregory-***@public.gmane.org> wrote:
> >
> >>
> >>
> >> I’ve been watching this discussion before I jumped in.
> I do believe
> >> testers have a place on agile teams and more than only
> exploratory testing
> >> (though that is a huge part). I have worked only with one
> team who thought
> >> they could get by without a tester, and at the end of a year,
> one of the
> >> developers wrote an experience paper stating why a tester was
> so important
> >> to have as part of the team.
> >>
> >>
> >>
> >> Even in BDD, they use analysts to help create the scenarios
> and flush out
> >> the tests. If a team doesn’t have a BA, testers fill that
> role. Testers may
> >> not even need to be ‘technical’, though it does help. It is
> the critical
> >> thinking and the big picture outlook that they provide which
> is invaluable.
> >> On a large system, all performance and security,
> interoperability, etc...,
> >> (quadrant 4 tests), cannot be done on a story level only.
> >>
> >>
> >>
> >> I would suggest being very careful about making sweeping
> statements.>> Testers have lots to offer on agile teams and I’m
> sure they will be around
> >> for a very long time.
> >>
> >>
> >>
> >> Janet Gregory
> >>
> >> Co-author with Lisa Crispin, Agile Testing: A Practical Guide
> for Testers
> >> and Agile Teams (Addison-Wesley 2009)
> >>
> >>
> >>
> >> www.janetgregory.ca
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> *From:* agile-testing-***@public.gmane.org [mailto:
> >> agile-testing-***@public.gmane.org] *On Behalf Of *aidy lewis
> >> *Sent:* Thursday, August 26, 2010 11:35 AM
> >>
> >> *To:* agile-testing-***@public.gmane.org
> >> *Subject:* Re: [agile-testing] TDD - is there a role for a tester?
> >>
> >>
> >>
> >>
> >>
> >> Hubert Matthews wrote,
> >>
> >>
> >>
> >> > Which of the ATDD/BDD frameworks support these
> requirements? All of the
> >>
> >> > ones that I know are "given/when/then" or similar.
> >>
> >>
> >>
> >> I have no reason to believe G\W\T cannot be used for non-functional
> >> requirements and driven with Cucumber and threads or JMeter
> or the like.
> >>
> >>
> >>
> >>
> >>
> >> > How many people get clear non-functional requirements? How
> many story
> >> cards
> >>
> >> > are there for them? My point is that these things are often
> forgotten or
> >>
> >> > they get short measure. A product is way more than the sum
> of its user
> >>
> >> > stories.
> >>
> >>
> >>
> >> It is imperative that performance criteria is specified before
> >> implementation so the developer can include this into his\her
> design. I
> >> would suggest this, which would hopefully then be included
> into the
> >> developer's routine.
> >>
> >>
> >>
> >>
> >>
> >> > As I said, it was a waterfall project so no TDD. I have
> managed to get
> >>
> >> > them to start doing some unit tests but they are still post
> facto, not
> >>
> >> > TDD. When I pointed out a bug the developers ran their
> internal tests
> >> and
> >>
> >> > found that they were broken and had been so for about a month.
> >>
> >>
> >>
> >> Without TDD testers face an almost inpossible task. TDD
> includes CI. These
> >> tests should run automatically upon check-in (at least).
> >>
> >>
> >>
> >>
> >>
> >> > Yes and they all passed. However, from my point of view the
> product was
> >>
> >> > badly broken and deadlocked often. The performance was also
> bad in
> >>
> >> > certain cases not covered by the functional tests. I also
> found bugs in
> >>
> >> > maximal configurations and potential overflow problems.
> >>
> >>
> >>
> >> These problems may occur when tests are not written before
> production>> code.
> >>
> >>
> >>
> >>
> >>
> >> > Automated tests show that the application conforms to some
> mental model
> >> of
> >>
> >> > desirable behaviour. What happens if the model is wrong or
> incomplete?>>
> >> > What happens if the "real" requirements are different from
> the stated
> >>
> >> > requirements? What about the implicit requirements that
> customers have
> >>
> >> > that they never mention?
> >>
> >>
> >>
> >> I would expect the customer to view working sofware after
> each iteration.
> >> Language itself is a near miss when constructing reality.
> >>
> >>
> >>
> >>
> >>
> >> > I wrote a number of sophisticated automated tests that
> broke the product
> >>
> >> > in important ways, ways that weren't explicitly stated but were
> >> important
> >>
> >> > to customers.
> >>
> >>
> >>
> >> Acceptance tests specify and test just enough for the
> customer to be
> >> happy. Nothing more. These limits I believe allow short iterative
> >> development.
> >>
> >>
> >>
> >>
> >>
> >> > So what do you do when you are producing a shrink-wrap
> product for
> >>
> >> > customers that you will never meet? Customers in different
> countries?>>
> >>
> >>
> >> You create personas to represent specific customers.
> >>
> >>
> >>
> >>
> >>
> >> Aidy
> >>
> >>
> >
> >
>
>
>
> --
> Lisa Crispin
> Co-author with Janet Gregory, _Agile Testing: A Practical Guide
> for Testers
> and Agile Teams_ (Addison-Wesley 2009)
> Contributor to _Beautiful Testing_ (O'Reilly 2009)
> http://lisacrispin.com
> @lisacrispin on Twitter
>

[Hubert Matthews]

aidy lewis wrote:
> As testers we have a material interest in the continuing existence of
> independent testers; though this I believe to be counter Agile.

I am a consultant from a development background and not a tester.
However, I understand the business value of good independent testers.

> The term Agile however is now amorphous with one fork being Project
> Managment Scrum\Kanban\Certification based, and another attempting to
> return
> focus back to correct development practices and craftsmanship.
>
> Agile Tester seems contradictory to me in that it confers the 'Tester'
> with
> 'Agility'. Agility is a software development process.

Agility is a characteristic of a business. Software development is only
part of the overall business. The word "agile" has been purloined and no
longer means what it used to mean.

> In substitution of a Business Analyst there is the tester. I have used the
> 'roles' interchangeably. In modern software development there is no role
> for
> the Business Analyst. I witness developers quite adequately specifying
> requirements with users.

Have you ever worked in a large organisation with a customer base measured
in millions of people? Have you worked on large-scale systems where no
one person actually knows the end-to-end business processes? Where there
are entire business units set up to understand users and what they want
and say they want?

> An extrapolation of working practices is not a sweeping statement. There
> is
> likely to be conservative resistance, as there was for example to TDD and
> dynamic languages.

My guess is that you are working at a much smaller scale than I am. That
is why you believe that you can do it all with skilled developers. If you
work on multi-million dollar/euro projects with multiple contracted
parties then things are different, very different.

--
Hubert Matthews http://www.oxyware.com/
Software Consultant hubert-***@public.gmane.org



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Matthew]

> aidy lewis wrote:
>As testers we have a material interest in the
>continuing existence of independent testers;
>though this I believe to be counter Agile.
>

Lisa has allready politely pointed out that this discussion is going off-charter for the list.

For small projects, say for an IT shop, where you can do things like lock down the browser, or tell the customer to ignore the error, click back on the browser, and re-submit, there might not be an independent tester role.

But that's always been the case, back when cutting edge was CMM or RUP or DOD-Standard-1976 or Waterfall or "Mythical Man Month."

But for large and complex projects that require viral adoption by mass-market customers, I don't see testers going away.

And to be perfectly frank, I had this conversation before. Ten years went by. My original detractors basically agree on a role for an independent tester on certain kinds of projects. In most cases, they yield that the idea that all MTS's are "generalists" that seecritly means "specialist/programmers first, everything else second" was ... misguided.

Let's get together again in five or six years and see where we stand.

I am serious.

--heusser




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Dave Rooney]

Earlier this year at an Agile Ottawa event about Kanban, the speaker
had a slide with something that really caught my attention. In
describing Kanban, he talked about "traditional Agile methods". I
realized at that point that I had been doing this "agile thing" for a
pretty long time, coming up on a full decade in a month or two.

I learned about Extreme Programming back in the fall of 2000, after
working on a horrendous waterfall project
(http://practicalagility.blogspot.com/2006/01/last-straw.html). After
reading about XP and practising it for the 1st time, I absolutely loved
the collaboration and focus on building quality into systems right from
even before the first line of code was written. What I found odd about
the XP community back then was that there were some people who believed
that all you needed was a business person (the Customer) and developers.

I'm a reasonably good programmer, and TDD made me even better. I've
always been as collaborative as the situation allowed, with some of my
best pre-XP work happening when I was within 100 feet of the business
owner of the system on which I was working. A recurring theme, though,
was that my programming and testing skills alone were nowhere near
enough. I had worked with some really good testers prior to learning
XP, and I knew that those people thought differently from me. There
were occasions when I actually paired with them while writing code, very
much to my benefit!

In the fall of 2001, I was able to have a team use full XP, perhaps with
the exception of the System Metaphor practice since it was an existing
system on which we were working. I didn't have any say about the team
structure, which included not only programmers but business analysts
(who doubled as testers), a technical writer, a BI/reports person and
project managers for both the IT and business. What I learned from that
experience was that the business analysts functioned very, very well as
day to day Customers/Product Owners when the actual person from the
business wasn't available. Their in-depth knowledge of the business
also served them well when testing the system. The technical writer
helped point out inconsistencies in the UI while she was working on the
documentation. The report person effectively acted as a tester for the
ETL process we had, since he could reconcile report data from the data
warehouse with data in the OLTP database.

In the end, the success of that team using XP wasn't just because the
programmers and Customer used XP. It was because XP helped enable the
collaboration between people of varying skills and experience,
effectively maximizing the individual contributions of a
cross-functional team.

My experience since then has not differed - to maximize the
effectiveness of the team, you need a broad range of skills and
experience. Testing is one of those skills, and I have met relatively
few programmers (myself included) who have an adequate level of
expertise to "go it alone" without someone more specialized. I don't
see that changing during my career.
--
Dave Rooney
Westboro Systems
Web: http://www.WestboroSystems.com
Blog: http://practicalagility.blogspot.com
Twitter: daverooneyca


On 27/08/2010 8:36 AM, Matthew wrote:
>> aidy lewis wrote:
>> As testers we have a material interest in the
>> continuing existence of independent testers;
>> though this I believe to be counter Agile
> Lisa has allready politely pointed out that this discussion is going off-charter for the list.
>
> For small projects, say for an IT shop, where you can do things like lock down the browser, or tell the customer to ignore the error, click back on the browser, and re-submit, there might not be an independent tester role.
>
> But that's always been the case, back when cutting edge was CMM or RUP or DOD-Standard-1976 or Waterfall or "Mythical Man Month."
>
> But for large and complex projects that require viral adoption by mass-market customers, I don't see testers going away.
>
> And to be perfectly frank, I had this conversation before. Ten years went by. My original detractors basically agree on a role for an independent tester on certain kinds of projects. In most cases, they yield that the idea that all MTS's are "generalists" that seecritly means "specialist/programmers first, everything else second" was ... misguided.
>
> Let's get together again in five or six years and see where we stand.
>
> I am serious.
>
> --heusser
>



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Steven Gordon]

Would the following be a fair summarization of your position?

Agile software development teams need members with testing skills, but not
necessarily the role of a dedicated tester.

On Fri, Aug 27, 2010 at 6:41 AM, Dave Rooney <dave.rooney-JZ+f107kGBmw5LPnMra/***@public.gmane.org> wrote:

>
>
> Earlier this year at an Agile Ottawa event about Kanban, the speaker
> had a slide with something that really caught my attention. In
> describing Kanban, he talked about "traditional Agile methods". I
> realized at that point that I had been doing this "agile thing" for a
> pretty long time, coming up on a full decade in a month or two.
>
> I learned about Extreme Programming back in the fall of 2000, after
> working on a horrendous waterfall project
> (http://practicalagility.blogspot.com/2006/01/last-straw.html). After
> reading about XP and practising it for the 1st time, I absolutely loved
> the collaboration and focus on building quality into systems right from
> even before the first line of code was written. What I found odd about
> the XP community back then was that there were some people who believed
> that all you needed was a business person (the Customer) and developers.
>
> I'm a reasonably good programmer, and TDD made me even better. I've
> always been as collaborative as the situation allowed, with some of my
> best pre-XP work happening when I was within 100 feet of the business
> owner of the system on which I was working. A recurring theme, though,
> was that my programming and testing skills alone were nowhere near
> enough. I had worked with some really good testers prior to learning
> XP, and I knew that those people thought differently from me. There
> were occasions when I actually paired with them while writing code, very
> much to my benefit!
>
> In the fall of 2001, I was able to have a team use full XP, perhaps with
> the exception of the System Metaphor practice since it was an existing
> system on which we were working. I didn't have any say about the team
> structure, which included not only programmers but business analysts
> (who doubled as testers), a technical writer, a BI/reports person and
> project managers for both the IT and business. What I learned from that
> experience was that the business analysts functioned very, very well as
> day to day Customers/Product Owners when the actual person from the
> business wasn't available. Their in-depth knowledge of the business
> also served them well when testing the system. The technical writer
> helped point out inconsistencies in the UI while she was working on the
> documentation. The report person effectively acted as a tester for the
> ETL process we had, since he could reconcile report data from the data
> warehouse with data in the OLTP database.
>
> In the end, the success of that team using XP wasn't just because the
> programmers and Customer used XP. It was because XP helped enable the
> collaboration between people of varying skills and experience,
> effectively maximizing the individual contributions of a
> cross-functional team.
>
> My experience since then has not differed - to maximize the
> effectiveness of the team, you need a broad range of skills and
> experience. Testing is one of those skills, and I have met relatively
> few programmers (myself included) who have an adequate level of
> expertise to "go it alone" without someone more specialized. I don't
> see that changing during my career.
> --
> Dave Rooney
> Westboro Systems
> Web: http://www.WestboroSystems.com
> Blog: http://practicalagility.blogspot.com
> Twitter: daverooneyca
>
>
> On 27/08/2010 8:36 AM, Matthew wrote:
> >> aidy lewis wrote:
> >> As testers we have a material interest in the
> >> continuing existence of independent testers;
> >> though this I believe to be counter Agile
> > Lisa has allready politely pointed out that this discussion is going
> off-charter for the list.
> >
> > For small projects, say for an IT shop, where you can do things like lock
> down the browser, or tell the customer to ignore the error, click back on
> the browser, and re-submit, there might not be an independent tester role.
> >
> > But that's always been the case, back when cutting edge was CMM or RUP or
> DOD-Standard-1976 or Waterfall or "Mythical Man Month."
> >
> > But for large and complex projects that require viral adoption by
> mass-market customers, I don't see testers going away.
> >
> > And to be perfectly frank, I had this conversation before. Ten years went
> by. My original detractors basically agree on a role for an independent
> tester on certain kinds of projects. In most cases, they yield that the idea
> that all MTS's are "generalists" that seecritly means
> "specialist/programmers first, everything else second" was ... misguided.
> >
> > Let's get together again in five or six years and see where we stand.
> >
> > I am serious.
> >
> > --heusser
> >
>
>
>

[Dave Rooney]

Hi Steven,

My position would be that any effective development team requires a
broad range of skills, of which testing is just one.

The best testers with whom I've worked were dedicated testers. One of
the best business analysts was also an accountant. Another BA was also
a BI reporting expert. One of the best technical managers was a
political science grad. Some of the best programmers did not come from
CS programs.

I don't like absolutes such as, "You don't need dedicated testers", or,
"You do need dedicated testers". Such statements or attitudes
effectively close to door to learning, and building software systems is
an ongoing learning process.
--
Dave Rooney
Westboro Systems
Web: http://www.WestboroSystems.com
Blog: http://practicalagility.blogspot.com
Twitter: daverooneyca


On 27/08/2010 11:31 AM, Steven Gordon wrote:
>
>
> Would the following be a fair summarization of your position?
>
> Agile software development teams need members with testing skills, but
> not necessarily the role of a dedicated tester.
>
> On Fri, Aug 27, 2010 at 6:41 AM, Dave Rooney <dave.rooney-JZ+f107kGBmw5LPnMra/***@public.gmane.org
> <mailto:dave.rooney-JZ+f107kGBmw5LPnMra/***@public.gmane.org>> wrote:
>
> Earlier this year at an Agile Ottawa event about Kanban, the speaker
> had a slide with something that really caught my attention. In
> describing Kanban, he talked about "traditional Agile methods". I
> realized at that point that I had been doing this "agile thing" for a
> pretty long time, coming up on a full decade in a month or two.
>
> I learned about Extreme Programming back in the fall of 2000, after
> working on a horrendous waterfall project
> (http://practicalagility.blogspot.com/2006/01/last-straw.html). After
> reading about XP and practising it for the 1st time, I absolutely
> loved
> the collaboration and focus on building quality into systems right
> from
> even before the first line of code was written. What I found odd
> about
> the XP community back then was that there were some people who
> believed
> that all you needed was a business person (the Customer) and
> developers.
>
> I'm a reasonably good programmer, and TDD made me even better. I've
> always been as collaborative as the situation allowed, with some
> of my
> best pre-XP work happening when I was within 100 feet of the business
> owner of the system on which I was working. A recurring theme,
> though,
> was that my programming and testing skills alone were nowhere near
> enough. I had worked with some really good testers prior to learning
> XP, and I knew that those people thought differently from me. There
> were occasions when I actually paired with them while writing
> code, very
> much to my benefit!
>
> In the fall of 2001, I was able to have a team use full XP,
> perhaps with
> the exception of the System Metaphor practice since it was an
> existing
> system on which we were working. I didn't have any say about the team
> structure, which included not only programmers but business analysts
> (who doubled as testers), a technical writer, a BI/reports person and
> project managers for both the IT and business. What I learned from
> that
> experience was that the business analysts functioned very, very
> well as
> day to day Customers/Product Owners when the actual person from the
> business wasn't available. Their in-depth knowledge of the business
> also served them well when testing the system. The technical writer
> helped point out inconsistencies in the UI while she was working
> on the
> documentation. The report person effectively acted as a tester for
> the
> ETL process we had, since he could reconcile report data from the
> data
> warehouse with data in the OLTP database.
>
> In the end, the success of that team using XP wasn't just because the
> programmers and Customer used XP. It was because XP helped enable the
> collaboration between people of varying skills and experience,
> effectively maximizing the individual contributions of a
> cross-functional team.
>
> My experience since then has not differed - to maximize the
> effectiveness of the team, you need a broad range of skills and
> experience. Testing is one of those skills, and I have met relatively
> few programmers (myself included) who have an adequate level of
> expertise to "go it alone" without someone more specialized. I don't
> see that changing during my career.
> --
> Dave Rooney
> Westboro Systems
> Web: http://www.WestboroSystems.com
> Blog: http://practicalagility.blogspot.com
> Twitter: daverooneyca
>
>
>
> On 27/08/2010 8:36 AM, Matthew wrote:
> >> aidy lewis wrote:
> >> As testers we have a material interest in the
> >> continuing existence of independent testers;
> >> though this I believe to be counter Agile
> > Lisa has allready politely pointed out that this discussion is
> going off-charter for the list.
> >
> > For small projects, say for an IT shop, where you can do things
> like lock down the browser, or tell the customer to ignore the
> error, click back on the browser, and re-submit, there might not
> be an independent tester role.
> >
> > But that's always been the case, back when cutting edge was CMM
> or RUP or DOD-Standard-1976 or Waterfall or "Mythical Man Month."
> >
> > But for large and complex projects that require viral adoption
> by mass-market customers, I don't see testers going away.
> >
> > And to be perfectly frank, I had this conversation before. Ten
> years went by. My original detractors basically agree on a role
> for an independent tester on certain kinds of projects. In most
> cases, they yield that the idea that all MTS's are "generalists"
> that seecritly means "specialist/programmers first, everything
> else second" was ... misguided.
> >
> > Let's get together again in five or six years and see where we
> stand.
> >
> > I am serious.
> >
> > --heusser
> >
>

[Steven Gordon]

So, agile teams need various skills. How those skills get allocated into
specific roles is up to the team and the organization? A team can be agile
and still have people who only test, only write server-side code, only write
javascript, only write html, only do database code, only do documentation,
... ?

On Fri, Aug 27, 2010 at 8:39 AM, Dave Rooney <dave.rooney-JZ+f107kGBmw5LPnMra/***@public.gmane.org> wrote:

>
>
> Hi Steven,
>
> My position would be that any effective development team requires a broad
> range of skills, of which testing is just one.
>
> The best testers with whom I've worked were dedicated testers. One of the
> best business analysts was also an accountant. Another BA was also a BI
> reporting expert. One of the best technical managers was a political
> science grad. Some of the best programmers did not come from CS programs.
>
> I don't like absolutes such as, "You don't need dedicated testers", or,
> "You do need dedicated testers". Such statements or attitudes effectively
> close to door to learning, and building software systems is an ongoing
> learning process.
>
> --
> Dave Rooney
> Westboro Systems
> Web: http://www.WestboroSystems.com
> Blog: http://practicalagility.blogspot.com
> Twitter: daverooneyca
>
>
> On 27/08/2010 11:31 AM, Steven Gordon wrote:
>
> Would the following be a fair summarization of your position?
>
> Agile software development teams need members with testing skills, but
> not necessarily the role of a dedicated tester.
>
> On Fri, Aug 27, 2010 at 6:41 AM, Dave Rooney <dave.rooney-JZ+f107kGBmw5LPnMra/***@public.gmane.org>wrote:
>
>>
>>
>> Earlier this year at an Agile Ottawa event about Kanban, the speaker
>> had a slide with something that really caught my attention. In
>> describing Kanban, he talked about "traditional Agile methods". I
>> realized at that point that I had been doing this "agile thing" for a
>> pretty long time, coming up on a full decade in a month or two.
>>
>> I learned about Extreme Programming back in the fall of 2000, after
>> working on a horrendous waterfall project
>> (http://practicalagility.blogspot.com/2006/01/last-straw.html). After
>> reading about XP and practising it for the 1st time, I absolutely loved
>> the collaboration and focus on building quality into systems right from
>> even before the first line of code was written. What I found odd about
>> the XP community back then was that there were some people who believed
>> that all you needed was a business person (the Customer) and developers.
>>
>> I'm a reasonably good programmer, and TDD made me even better. I've
>> always been as collaborative as the situation allowed, with some of my
>> best pre-XP work happening when I was within 100 feet of the business
>> owner of the system on which I was working. A recurring theme, though,
>> was that my programming and testing skills alone were nowhere near
>> enough. I had worked with some really good testers prior to learning
>> XP, and I knew that those people thought differently from me. There
>> were occasions when I actually paired with them while writing code, very
>> much to my benefit!
>>
>> In the fall of 2001, I was able to have a team use full XP, perhaps with
>> the exception of the System Metaphor practice since it was an existing
>> system on which we were working. I didn't have any say about the team
>> structure, which included not only programmers but business analysts
>> (who doubled as testers), a technical writer, a BI/reports person and
>> project managers for both the IT and business. What I learned from that
>> experience was that the business analysts functioned very, very well as
>> day to day Customers/Product Owners when the actual person from the
>> business wasn't available. Their in-depth knowledge of the business
>> also served them well when testing the system. The technical writer
>> helped point out inconsistencies in the UI while she was working on the
>> documentation. The report person effectively acted as a tester for the
>> ETL process we had, since he could reconcile report data from the data
>> warehouse with data in the OLTP database.
>>
>> In the end, the success of that team using XP wasn't just because the
>> programmers and Customer used XP. It was because XP helped enable the
>> collaboration between people of varying skills and experience,
>> effectively maximizing the individual contributions of a
>> cross-functional team.
>>
>> My experience since then has not differed - to maximize the
>> effectiveness of the team, you need a broad range of skills and
>> experience. Testing is one of those skills, and I have met relatively
>> few programmers (myself included) who have an adequate level of
>> expertise to "go it alone" without someone more specialized. I don't
>> see that changing during my career.
>> --
>> Dave Rooney
>> Westboro Systems
>> Web: http://www.WestboroSystems.com
>> Blog: http://practicalagility.blogspot.com
>> Twitter: daverooneyca
>>
>>
>> On 27/08/2010 8:36 AM, Matthew wrote:
>> >> aidy lewis wrote:
>> >> As testers we have a material interest in the
>> >> continuing existence of independent testers;
>> >> though this I believe to be counter Agile
>> > Lisa has allready politely pointed out that this discussion is going
>> off-charter for the list.
>> >
>> > For small projects, say for an IT shop, where you can do things like
>> lock down the browser, or tell the customer to ignore the error, click back
>> on the browser, and re-submit, there might not be an independent tester
>> role.
>> >
>> > But that's always been the case, back when cutting edge was CMM or RUP
>> or DOD-Standard-1976 or Waterfall or "Mythical Man Month."
>> >
>> > But for large and complex projects that require viral adoption by
>> mass-market customers, I don't see testers going away.
>> >
>> > And to be perfectly frank, I had this conversation before. Ten years
>> went by. My original detractors basically agree on a role for an independent
>> tester on certain kinds of projects. In most cases, they yield that the idea
>> that all MTS's are "generalists" that seecritly means
>> "specialist/programmers first, everything else second" was ... misguided.
>> >
>> > Let's get together again in five or six years and see where we stand.
>> >
>> > I am serious.
>> >
>> > --heusser
>> >
>>
>
>
>

[Matthew]

--- In agile-testing-***@public.gmane.org, Dave Rooney <***@...> wrote:
>I don't like absolutes such as, "You don't need
>dedicated testers", or, "You do need dedicated
>testers". Such statements or attitudes
>effectively close to door to learning, and building
>software systems is an ongoing learning process.
>

Agreed. I'd say there are some contexts where you can be successful without dedicated testers, and others where it would be extremely challenging to do so.

I'm interested in helping teams figure out what is the best fit for them, for their projects, for their culture ... and what that answer might be tomorrow.


regards,


--
Matthew Heusser
Twitter: mheusser
My Blog: http://xndev.blogspot.com/
Community Blog: http://www.softwaretestpro.com/blog



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Lisa Crispin]

My experience over the past 10 years is, if agile teams don't need testers
(I've worked on teams from 8 to 30 programmers in size; I've worked for
companies with development organizations 10 - 200 in size) then I wonder why
I and the other testers on my teams have been so darned busy all the time!
My current team has 4 programmers and 2 testers, and the programmers also
pitch in on testing activities - if they didn't, we could never get stories
finished in a timely manner. I suppose some people might read that and say
"Well, Lisa and her fellow testers must not be very good", but that's not
the case. We need a lot of time to work together with our customers,
understand what needs to be delivered, code and test in small increments,
automate regression tests, do extensive exploratory testing, keep our
feedback loop short, document our application adequately, demo to users and
pair test with users, do performance testing, do security testing, the list
goes on and on.

I think at this point (after 6.5 years), the programmers I work with could
do many of the testing activities without any help from testers. But I know
for sure they wouldn't want to automate GUI tests (we only do this at a
smoke test level, but it's important for our app), spend as much time as we
do with the customers going over the requirements and test cases, or do
manual exploratory testing. They could do these things, and maybe even do
them well, but they don't want to - they want to be programmers. They're
happy to automate FitNesse fixtures, even write FitNesse tests, and they do
a great job of TDD at the unit level. If a test fails in the CI, they jump
on it and fix the problem. But they don't enjoy the same things that I enjoy
doing.

Agile seems to work best with generalists, but diversity is good too. Some
of us prefer particular testing activities that others do not.
-- Lisa

On Fri, Aug 27, 2010 at 10:14 AM, Matthew <matt.heusser-***@public.gmane.org> wrote:

>
>
>
>
> --- In agile-testing-***@public.gmane.org <agile-testing%40yahoogroups.com>,
> Dave Rooney <***@...> wrote:
> >I don't like absolutes such as, "You don't need
> >dedicated testers", or, "You do need dedicated
> >testers". Such statements or attitudes
> >effectively close to door to learning, and building
> >software systems is an ongoing learning process.
> >
>
> Agreed. I'd say there are some contexts where you can be successful without
> dedicated testers, and others where it would be extremely challenging to do
> so.
>
> I'm interested in helping teams figure out what is the best fit for them,
> for their projects, for their culture ... and what that answer might be
> tomorrow.
>
> regards,
>
>
> --
> Matthew Heusser
> Twitter: mheusser
> My Blog: http://xndev.blogspot.com/
> Community Blog: http://www.softwaretestpro.com/blog
>
>
>



--
Lisa Crispin
Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
and Agile Teams_ (Addison-Wesley 2009)
Contributor to _Beautiful Testing_ (O'Reilly 2009)
http://lisacrispin.com
@lisacrispin on Twitter

[Lisa Crispin]

I love what Declan Whelan just tweeted:
I get weary of the 'testers do ... this or that' comments. Smart people on
good teams do great things. Functional tags destroy value flow.

+1 on that!
-- Lisa

On Fri, Aug 27, 2010 at 4:14 PM, Lisa Crispin <lisa.crispin-***@public.gmane.org>wrote:

> My experience over the past 10 years is, if agile teams don't need testers
> (I've worked on teams from 8 to 30 programmers in size; I've worked for
> companies with development organizations 10 - 200 in size) then I wonder why
> I and the other testers on my teams have been so darned busy all the time!
> My current team has 4 programmers and 2 testers, and the programmers also
> pitch in on testing activities - if they didn't, we could never get stories
> finished in a timely manner. I suppose some people might read that and say
> "Well, Lisa and her fellow testers must not be very good", but that's not
> the case. We need a lot of time to work together with our customers,
> understand what needs to be delivered, code and test in small increments,
> automate regression tests, do extensive exploratory testing, keep our
> feedback loop short, document our application adequately, demo to users and
> pair test with users, do performance testing, do security testing, the list
> goes on and on.
>
> I think at this point (after 6.5 years), the programmers I work with could
> do many of the testing activities without any help from testers. But I know
> for sure they wouldn't want to automate GUI tests (we only do this at a
> smoke test level, but it's important for our app), spend as much time as we
> do with the customers going over the requirements and test cases, or do
> manual exploratory testing. They could do these things, and maybe even do
> them well, but they don't want to - they want to be programmers. They're
> happy to automate FitNesse fixtures, even write FitNesse tests, and they do
> a great job of TDD at the unit level. If a test fails in the CI, they jump
> on it and fix the problem. But they don't enjoy the same things that I enjoy
> doing.
>
> Agile seems to work best with generalists, but diversity is good too. Some
> of us prefer particular testing activities that others do not.
> -- Lisa
>
>
> On Fri, Aug 27, 2010 at 10:14 AM, Matthew <matt.heusser-***@public.gmane.org> wrote:
>
>>
>>
>>
>>
>> --- In agile-testing-***@public.gmane.org <agile-testing%40yahoogroups.com>,
>> Dave Rooney <***@...> wrote:
>> >I don't like absolutes such as, "You don't need
>> >dedicated testers", or, "You do need dedicated
>> >testers". Such statements or attitudes
>> >effectively close to door to learning, and building
>> >software systems is an ongoing learning process.
>> >
>>
>> Agreed. I'd say there are some contexts where you can be successful
>> without dedicated testers, and others where it would be extremely
>> challenging to do so.
>>
>> I'm interested in helping teams figure out what is the best fit for them,
>> for their projects, for their culture ... and what that answer might be
>> tomorrow.
>>
>> regards,
>>
>>
>> --
>> Matthew Heusser
>> Twitter: mheusser
>> My Blog: http://xndev.blogspot.com/
>> Community Blog: http://www.softwaretestpro.com/blog
>>
>>
>>
>
>
>
> --
> Lisa Crispin
> Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
> and Agile Teams_ (Addison-Wesley 2009)
> Contributor to _Beautiful Testing_ (O'Reilly 2009)
> http://lisacrispin.com
> @lisacrispin on Twitter
>
>


--
Lisa Crispin
Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
and Agile Teams_ (Addison-Wesley 2009)
Contributor to _Beautiful Testing_ (O'Reilly 2009)
http://lisacrispin.com
@lisacrispin on Twitter

[George Dinwiddie]

Hi, all,

I fear that this thread is treading on the edge of a philosophical
discussion, and I am therefore wary of stepping into it. Let me see if
I can walk that tightrope and inject some of my personal experience.

On 8/28/10 12:14 AM, Matthew wrote:
>
>
> --- In agile-testing-***@public.gmane.org, Dave Rooney<***@...> wrote:
>> I don't like absolutes such as, "You don't need
>> dedicated testers", or, "You do need dedicated
>> testers". Such statements or attitudes
>> effectively close to door to learning, and building
>> software systems is an ongoing learning process.
>>
>
> Agreed. I'd say there are some contexts where you can be successful
> without dedicated testers, and others where it would be extremely
> challenging to do so.

I'm not sure why you would ever need /dedicated testers/ (or /dedicated
programmers/), but I am sure that you generally need to bring both a
programming and a testing /mindset/ to the work. I think of the
programming mindset as thinking about how to make things happen and the
testing mindset as thinking about what can go wrong. One seems to be
forward thinking and the other backward thinking, but that may be
oversimplifying. Unlike Dave Rooney, I find that I /can/ do both
(though my career has been programming, before coaching). I do find it
difficult to do both at the same time, or to bounce quickly between the two.

My experience is that contexts vary so widely that any blanket statement
is likely to have exceptions and counter-examples. Sometimes the
software doesn't even have to work.

> I'm interested in helping teams figure out what is the best fit for
> them, for their projects, for their culture ... and what that answer
> might be tomorrow.

Yes, I wholeheartedly agree with this. I usually deal with an existing
team--not choosing people to make up a team. I help teams make the most
of the skills they currently have, and to learn skills that will be
helpful. If a team is short on a skill that they need, it might
generally be prudent to look for someone who has that skill to join or
supplement the team.

But, to answer the subject line, there is definitely a role for someone
good at the testing mindset, even if the developers are doing TDD (which
is not really a testing technique). Most of those people self-identify
themselves as a tester.

- George

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



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Lisa Crispin]

Well said, George. I wish you'd blog about this so I could point people to
your blog post!
-- Lisa

On Sat, Aug 28, 2010 at 6:44 AM, George Dinwiddie
<lists-HLNzD44B1AikJOqCEYON2AC/***@public.gmane.org>wrote:

>
>
> Hi, all,
>
> I fear that this thread is treading on the edge of a philosophical
> discussion, and I am therefore wary of stepping into it. Let me see if
> I can walk that tightrope and inject some of my personal experience.
>
>
> On 8/28/10 12:14 AM, Matthew wrote:
> >
> >
> > --- In agile-testing-***@public.gmane.org <agile-testing%40yahoogroups.com>,
> Dave Rooney<***@...> wrote:
> >> I don't like absolutes such as, "You don't need
> >> dedicated testers", or, "You do need dedicated
> >> testers". Such statements or attitudes
> >> effectively close to door to learning, and building
> >> software systems is an ongoing learning process.
> >>
> >
> > Agreed. I'd say there are some contexts where you can be successful
> > without dedicated testers, and others where it would be extremely
> > challenging to do so.
>
> I'm not sure why you would ever need /dedicated testers/ (or /dedicated
> programmers/), but I am sure that you generally need to bring both a
> programming and a testing /mindset/ to the work. I think of the
> programming mindset as thinking about how to make things happen and the
> testing mindset as thinking about what can go wrong. One seems to be
> forward thinking and the other backward thinking, but that may be
> oversimplifying. Unlike Dave Rooney, I find that I /can/ do both
> (though my career has been programming, before coaching). I do find it
> difficult to do both at the same time, or to bounce quickly between the
> two.
>
> My experience is that contexts vary so widely that any blanket statement
> is likely to have exceptions and counter-examples. Sometimes the
> software doesn't even have to work.
>
>
> > I'm interested in helping teams figure out what is the best fit for
> > them, for their projects, for their culture ... and what that answer
> > might be tomorrow.
>
> Yes, I wholeheartedly agree with this. I usually deal with an existing
> team--not choosing people to make up a team. I help teams make the most
> of the skills they currently have, and to learn skills that will be
> helpful. If a team is short on a skill that they need, it might
> generally be prudent to look for someone who has that skill to join or
> supplement the team.
>
> But, to answer the subject line, there is definitely a role for someone
> good at the testing mindset, even if the developers are doing TDD (which
> is not really a testing technique). Most of those people self-identify
> themselves as a tester.
>
> - George
>
> --
> ----------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------
>
>
>



--
Lisa Crispin
Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
and Agile Teams_ (Addison-Wesley 2009)
Contributor to _Beautiful Testing_ (O'Reilly 2009)
http://lisacrispin.com
@lisacrispin on Twitter

[rfagen]

The following stuff resonated with me and with something I'd just posted
on my company's blog
<http://www.heyitsopower.com/culture/just-what-is-a-software-engineer-in\
-test/> :

--- In agile-testing-***@public.gmane.org, George Dinwiddie <***@...>
wrote:
>
> Hi, all,
>
> I fear that this thread is treading on the edge of a philosophical
> discussion, and I am therefore wary of stepping into it. Let me see
if
> I can walk that tightrope and inject some of my personal experience.
>
... a bunch of context and discussion ...
> I think of the programming mindset as thinking about how to make
things happen and the
> testing mindset as thinking about what can go wrong.
... yet more context and discussion ...

The relevant excerpt from my thoughts was:
The useful work a developer creates is to render a web page, or process
messages, or update a database, all with an end goal of satisfying the
end consumer of the application being worked on. When developing test
systems, all those same elements are required, but the end goal is
providing actionable insight about the quality of the customer facing
system. This actionable insight is consumed by the developer and the
engineering and product managers. They use this insight to answer
questions. Those questions include: is it done, does it work, will it
scale, and many others.
I like the use of the phrase 'mindset' to describe that state where
you're all engaged on a common task, just from different perspectives
and with a slightly different toolbelt strapped to your waist.

[bclancy84]

Dave, your post here was great (for me) because you were specific about a context in which others jumped into testing roles and added VALUE because they had valuable DOMAIN EXPERIENCE. Thanks for pointing out the way the BAs were able to step in and improve the test cases. (This is coming from someone who (like Lisa) really likes to test!) :D

--
Bob



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[mark ferguson]

On 26 August 2010 18:34, aidy lewis <aidy.lewis-***@public.gmane.org> wrote:

>
>
> Hubert Matthews wrote,
>
> > Which of the ATDD/BDD frameworks support these requirements? All of the
> > ones that I know are "given/when/then" or similar.
>
> I have no reason to believe G\W\T cannot be used for non-functional
> requirements and driven with Cucumber and threads or JMeter or the like.
>

I would have to assume that you haven't done much performance testing in
production staging environments, as it's really a bit more complex than
that.

> How many people get clear non-functional requirements? How many story
> cards
> > are there for them? My point is that these things are often forgotten or
> > they get short measure. A product is way more than the sum of its user
> > stories.
>
> It is imperative that performance criteria is specified before
> implementation so the developer can include this into his\her design. I
> would suggest this, which would hopefully then be included into the
> developer's routine.
>

That would be nice. It's getting better but they are rarely specified to an
extent that can be used as is. 'hopefully' is the key word here. Hope for
the best, plan for less.


> > As I said, it was a waterfall project so no TDD. I have managed to get
> > them to start doing some unit tests but they are still post facto, not
> > TDD. When I pointed out a bug the developers ran their internal tests and
> > found that they were broken and had been so for about a month.
>
> Without TDD testers face an almost inpossible task. TDD includes CI. These
> tests should run automatically upon check-in (at least).
>

Nice to know I've been succeeding at an almost impossible task for the last
20 years. You don't need TDD, you need best practice. If you insist on
formalised rules to assure best practice then that is a good thing, but it
is not essential. TDD is a 'good idea', one of many good ideas. Pick and
choose as best suits the situation.


> > Yes and they all passed. However, from my point of view the product was
> > badly broken and deadlocked often. The performance was also bad in
> > certain cases not covered by the functional tests. I also found bugs in
> > maximal configurations and potential overflow problems.
>
> These problems may occur when tests are not written before production code.
>

And they may also occur if they are. It depends on the tests, not the
methodology.


> > Automated tests show that the application conforms to some mental model
> of
> > desirable behaviour. What happens if the model is wrong or incomplete?
> > What happens if the "real" requirements are different from the stated
> > requirements? What about the implicit requirements that customers have
> > that they never mention?
>
> I would expect the customer to view working sofware after each iteration.
> Language itself is a near miss when constructing reality.
>

I think that you expect a lot from your customers! Perhaps too much?

>
>
> > I wrote a number of sophisticated automated tests that broke the product
> > in important ways, ways that weren't explicitly stated but were important
> > to customers.
>
> Acceptance tests specify and test just enough for the customer to be happy.
> Nothing more. These limits I believe allow short iterative development.
>

Happy today maybe, not happy tomorrow. If the cutomers didn't expect you to
do more testing than they will do, then the customer would be at least
equally capable at software development as you. In which case, they probably
wouldn't be a customer they'd be a competitor!

>
>
> > So what do you do when you are producing a shrink-wrap product for
> > customers that you will never meet? Customers in different countries?
>
> You create personas to represent specific customers.
>

I think the point was that you don't always know the customers. You can
create an imagined persona, but you will probably be wrong. Creating a
persona per se is not a solution, it is a step within the process of
creating a solution. Actually, I'll backtrack on that a bit. 'You' (Hubert)
might have problems with the range of customer requirements but 'you' (Aidy)
might not. Generally the smaller the company, the more difficult (expensive,
relatively speaking) it is to segment and analyse your customer base, so it
is a problem at that scale. Bigger companies have other problems, but
getting a torrent of marketing input about actual and potential customer
profiles is usually not one of them!

Mark

[Adrian Stokes]

When asking our question about TDD, it depends on what you really mean
by traditional tester? A person with test experience who waits for
software to be delivered to them and then gets to work, i.e. waterfall
(as mentioned before)? If this is your definition then no. There is no
isolated role like that. If your using agile principles, by whatever
name, the tester should be involved in defining the tests working along
side whichever designated roles your company has assigned. BAs, PMs,
Developers, Architects etc etc... Having a tester involved from
requirements gathering to integration is a value adding practice.
Having one that understands acceptance tests, user roles and stories etc
as well as traditional test practice is highly desirable. A team where
the focus is less on the individual role and more on the common goal
will get better results.
cheers, Ady


Adrian Stokes
BI QA Analyst
Business Intelligence
BISD
Gateway House, Skipton
Ext: 2452
Direct Dial: 0844 892 2596
www.hml.co.uk

---------------------------------------
The ability in financial outsourcing



________________________________

From: agile-testing-***@public.gmane.org
[mailto:agile-testing-***@public.gmane.org] On Behalf Of Hubert Matthews
Sent: 26 August 2010 08:48
To: agile-testing-***@public.gmane.org
Subject: Re: [agile-testing] TDD - is there a role for a tester?




aidy lewis wrote:
> In an environment that operates true Behaviour Driven
Development (BDD)
> there is little role for an independent tester.

I would strongly disagree with this. By definition, BDD tests
functional
behaviour and that is probably 1/3 to 1/2 of your overall system
requirements. What about performance, interoperability, stress,
load,
volume, security and all the other forms of testing? I worked as
a tester
on a waterfall project a while back where all of the functional
tests
passed and the developers said it was ready for release but I
could
deadlock the product within seconds. I could also show
significant
performance issues. Fixing these issues wasn't trivial and
nearly
involved throwing away a major library.

Independent testing is critical. BDD and TDD just mean that the
tester
doesn't have to deal with silly functional errors, which is
good, and can
concentrate on being a customer champion instead.

--
Hubert Matthews http://www.oxyware.com/
Software Consultant hubert-***@public.gmane.org
<mailto:hubert%40oxyware.com>






*******************************************************************
This email is intended only for the addressee named above. As this email may contain confidential or privileged information, if you are not the named addressee or receive this message in error, please notify us immediately, delete it and do not make use of or copy it.

This message is protected by copyright. HML accepts no responsibility for viruses found in this message or any file attachment.

Homeloan Management Limited
Registered in England No. 2214839
The Bailey, Skipton, North Yorkshire, BD23 1DN

********************************************************************

[Janet Gregory]

Adrian,

Apologies from the moderators (I'm using the royal we here). Your message below was tagged as spam so didn't go into the right folder so was 'stuck' in the system. I found it by accident. that is why it was just put through.

Janet

----- Original Message -----
From: Adrian Stokes <adrian.stokes-yT2CZ1CE1Odaa/***@public.gmane.org>
Date: Wednesday, September 8, 2010 7:07 pm
Subject: RE: [agile-testing] TDD - is there a role for a tester?
To: agile-testing-***@public.gmane.org

> When asking our question about TDD, it depends on what you
> really mean
> by traditional tester? A person with test experience who
> waits for
> software to be delivered to them and then gets to work, i.e. waterfall
> (as mentioned before)? If this is your definition then
> no. There is no
> isolated role like that. If your using agile principles,
> by whatever
> name, the tester should be involved in defining the tests
> working along
> side whichever designated roles your company has assigned.
> BAs, PMs,
> Developers, Architects etc etc... Having a tester involved from
> requirements gathering to integration is a value adding practice.
> Having one that understands acceptance tests, user roles and
> stories etc
> as well as traditional test practice is highly desirable.
> A team where
> the focus is less on the individual role and more on the common goal
> will get better results.
> cheers, Ady
>
>
> Adrian Stokes
> BI QA Analyst
> Business Intelligence
> BISD
> Gateway House, Skipton
> Ext: 2452
> Direct Dial: 0844 892 2596
> www.hml.co.uk
>
> ---------------------------------------
> The ability in financial outsourcing
>
>
>
> ________________________________
>
> From: agile-testing-***@public.gmane.org
> [mailto:agile-testing-***@public.gmane.org] On Behalf Of Hubert Matthews
> Sent: 26 August 2010 08:48
> To: agile-testing-***@public.gmane.org
> Subject: Re: [agile-testing] TDD - is there a role for a tester?
>
>
>
>
> aidy lewis wrote:
> > In an environment that operates true Behaviour Driven
> Development (BDD)
> > there is little role for an independent tester.
>
> I would strongly disagree with this. By definition, BDD tests
> functional
> behaviour and that is probably 1/3 to 1/2 of your overall system
> requirements. What about performance, interoperability, stress,
> load,
> volume, security and all the other forms of testing? I worked as
> a tester
> on a waterfall project a while back where all of the functional
> tests
> passed and the developers said it was ready for release but I
> could
> deadlock the product within seconds. I could also show
> significant
> performance issues. Fixing these issues wasn't trivial and
> nearly
> involved throwing away a major library.
>
> Independent testing is critical. BDD and TDD just mean that the
> tester
> doesn't have to deal with silly functional errors, which is
> good, and can
> concentrate on being a customer champion instead.
>
> --
> Hubert Matthews http://www.oxyware.com/
> Software Consultant hubert-***@public.gmane.org
> <mailto:hubert%40oxyware.com>
>
>
>
>
>
>
> *******************************************************************
> This email is intended only for the addressee named above.
> As this email may contain confidential or privileged
> information, if you are not the named addressee or receive this
> message in error, please notify us immediately, delete it and do
> not make use of or copy it.
>
> This message is protected by copyright. HML accepts no
> responsibility for viruses found in this message or any file
> attachment.
> Homeloan Management Limited
> Registered in England No. 2214839
> The Bailey, Skipton, North Yorkshire, BD23 1DN
>
> ********************************************************************
>
>

[Adrian Stokes]

No problem Janet. Hopefully sorted now.



________________________________

From: agile-testing-***@public.gmane.org
[mailto:agile-testing-***@public.gmane.org] On Behalf Of Janet Gregory
Sent: 09 September 2010 02:11
To: agile-testing-***@public.gmane.org
Subject: Re: RE: [agile-testing] TDD - is there a role for a
tester?





Adrian,

Apologies from the moderators (I'm using the royal we here).
Your message below was tagged as spam so didn't go into the right folder
so was 'stuck' in the system. I found it by accident. that is why it was
just put through.

Janet

----- Original Message -----
From: Adrian Stokes <adrian.stokes-yT2CZ1CE1Odaa/***@public.gmane.org>
Date: Wednesday, September 8, 2010 7:07 pm
Subject: RE: [agile-testing] TDD - is there a role for a tester?
To: agile-testing-***@public.gmane.org

> When asking our question about TDD, it depends on what you
> really mean
> by traditional tester? A person with test experience who
> waits for
> software to be delivered to them and then gets to work, i.e.
waterfall
> (as mentioned before)? If this is your definition then
> no. There is no
> isolated role like that. If your using agile principles,
> by whatever
> name, the tester should be involved in defining the tests
> working along
> side whichever designated roles your company has assigned.
> BAs, PMs,
> Developers, Architects etc etc... Having a tester involved
from
> requirements gathering to integration is a value adding
practice.
> Having one that understands acceptance tests, user roles and
> stories etc
> as well as traditional test practice is highly desirable.
> A team where
> the focus is less on the individual role and more on the
common goal
> will get better results.
> cheers, Ady
>
>
> Adrian Stokes
> BI QA Analyst
> Business Intelligence
> BISD
> Gateway House, Skipton
> Ext: 2452
> Direct Dial: 0844 892 2596
> www.hml.co.uk
>
> ---------------------------------------
> The ability in financial outsourcing
>
>
>
> ________________________________
>
> From: agile-testing-***@public.gmane.org
> [mailto:agile-testing-***@public.gmane.org] On Behalf Of Hubert
Matthews
> Sent: 26 August 2010 08:48
> To: agile-testing-***@public.gmane.org
> ; Subject: Re: [agile-testing] TDD - is there a role for a
tester?
Janet

----- Original Message -----
From: Adrian Stokes <adrian.stokes-yT2CZ1CE1Odaa/***@public.gmane.org>
Date: Wednesday, September 8, 2010 7:07 pm
Subject: RE: [agile-testing] TDD - is there a role for a tester?
To: agile-testing-***@public.gmane.org

> When asking our question about TDD, it depends on what you
> really mean
> by traditional tester? A person with test experience who
> waits for
> software to be delivered to them and then gets to work, i.e.
waterfall
> (as mentioned before)? If this is your definition then
> no. There is no
> isolated role like that. If your using agile principles,
> by whatever
> name, the tester should be involved in defining the tests
> working along
> side whichever designated roles your company has assigned.
> BAs, PMs,
> Developers, Architects etc etc... Having a tester involved
from
> requirements gathering to integration is a value adding
practice.
> Having one that understands acceptance tests, user roles and
> stories etc
> as well as traditional test practice is highly desirable.
> A team where
> the focus is less on the individual role and more on the
common goal
> will get better results.
> cheers, Ady
>
>
> Adrian Stokes
> BI QA Analyst
> Business Intelligence
> BISD
> Gateway House, Skipton
> Ext: 2452
> Direct Dial: 0844 892 2596
> www.hml.co.uk
>
> ---------------------------------------
> The ability in financial outsourcing
>
>
>
> ________________________________
>
> From: agile-testing-***@public.gmane.org
> [mailto:agile -testing-***@public.gmane.org] On Behalf Of Hubert
Matthews
> Sent: 26 August 2010 08:48
> To: agile-testing-***@public.gmane.org
> Subject: Re: [agile-testing] TDD - is there a role for a
tester?
>
>
>
>
> aidy lewis wrote:
> > In an environment that






*******************************************************************
This email is intended only for the addressee named above. As this email may contain confidential or privileged information, if you are not the named addressee or receive this message in error, please notify us immediately, delete it and do not make use of or copy it.

This message is protected by copyright. HML accepts no responsibility for viruses found in this message or any file attachment.

Homeloan Management Limited
Registered in England No. 2214839
The Bailey, Skipton, North Yorkshire, BD23 1DN

********************************************************************

[Rohan Sarker]

Personally I am not confident on TDD. I worked once in TDD as a QA. I
had limited role. The main power was in the hands of Vice-President
and Business Analysts.





Regards
Rohan Sarker
IBM Kolkata & IBM Bangalore
Tel:[phone]


On 9/9/10, Janet Gregory <janet_gregory-***@public.gmane.org> wrote:
> Adrian,
>
> Apologies from the moderators (I'm using the royal we here). Your message
> below was tagged as spam so didn't go into the right folder so was 'stuck'
> in the system. I found it by accident. that is why it was just put through.
>
> Janet
>
> ----- Original Message -----
> From: Adrian Stokes <adrian.stokes-yT2CZ1CE1Odaa/***@public.gmane.org>
> Date: Wednesday, September 8, 2010 7:07 pm
> Subject: RE: [agile-testing] TDD - is there a role for a tester?
> To: agile-testing-***@public.gmane.org
>
>> When asking our question about TDD, it depends on what you
>> really mean
>> by traditional tester? A person with test experience who
>> waits for
>> software to be delivered to them and then gets to work, i.e. waterfall
>> (as mentioned before)? If this is your definition then
>> no. There is no
>> isolated role like that. If your using agile principles,
>> by whatever
>> name, the tester should be involved in defining the tests
>> working along
>> side whichever designated roles your company has assigned.
>> BAs, PMs,
>> Developers, Architects etc etc... Having a tester involved from
>> requirements gathering to integration is a value adding practice.
>> Having one that understands acceptance tests, user roles and
>> stories etc
>> as well as traditional test practice is highly desirable.
>> A team where
>> the focus is less on the individual role and more on the common goal
>> will get better results.
>> cheers, Ady
>>
>>
>> Adrian Stokes
>> BI QA Analyst
>> Business Intelligence
>> BISD
>> Gateway House, Skipton
>> Ext: 2452
>> Direct Dial: 0844 892 2596
>> www.hml.co.uk
>>
>> ---------------------------------------
>> The ability in financial outsourcing
>>
>>
>>
>> ________________________________
>>
>> From: agile-testing-***@public.gmane.org
>> [mailto:agile-testing-***@public.gmane.org] On Behalf Of Hubert Matthews
>> Sent: 26 August 2010 08:48
>> To: agile-testing-***@public.gmane.org
>> Subject: Re: [agile-testing] TDD - is there a role for a tester?
>>
>>
>>
>>
>> aidy lewis wrote:
>> > In an environment that operates true Behaviour Driven
>> Development (BDD)
>> > there is little role for an independent tester.
>>
>> I would strongly disagree with this. By definition, BDD tests
>> functional
>> behaviour and that is probably 1/3 to 1/2 of your overall system
>> requirements. What about performance, interoperability, stress,
>> load,
>> volume, security and all the other forms of testing? I worked as
>> a tester
>> on a waterfall project a while back where all of the functional
>> tests
>> passed and the developers said it was ready for release but I
>> could
>> deadlock the product within seconds. I could also show
>> significant
>> performance issues. Fixing these issues wasn't trivial and
>> nearly
>> involved throwing away a major library.
>>
>> Independent testing is critical. BDD and TDD just mean that the
>> tester
>> doesn't have to deal with silly functional errors, which is
>> good, and can
>> concentrate on being a customer champion instead.
>>
>> --
>> Hubert Matthews http://www.oxyware.com/
>> Software Consultant hubert-***@public.gmane.org
>> <mailto:hubert%40oxyware.com>
>>
>>
>>
>>
>>
>>
>> *******************************************************************
>> This email is intended only for the addressee named above.
>> As this email may contain confidential or privileged
>> information, if you are not the named addressee or receive this
>> message in error, please notify us immediately, delete it and do
>> not make use of or copy it.
>>
>> This message is protected by copyright. HML accepts no
>> responsibility for viruses found in this message or any file
>> attachment.
>> Homeloan Management Limited
>> Registered in England No. 2214839
>> The Bailey, Skipton, North Yorkshire, BD23 1DN
>>
>> ********************************************************************
>>
>>
>


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Matthew]

--- In agile-testing-***@public.gmane.org, "Adrian Stokes" <***@...> wrote:
>If your using agile principles, by whatever
>name, the tester should be involved in
>defining the tests working along
>side whichever designated roles your company
>has assigned. BAs, PMs,
>Developers, Architects etc etc...

I'm of a divided mind on this. On the one hand yes, just about every high-functioning 'Agile' team I've worked with does something like this.

On the other ... I can't find justification for that statement in the manifesto.

For that matter, what if a high-functioning self-organized team said "no, we're really gonna let bob focus on testing 'cuz that is what bob is good at and what he wants to do."

Is that "wrong?" is it "bad?" Is it "Not Agile (R) (TM) (C)?"

If it is "Not Agile", that strikes me as an awful process-and-tools oriented approach.

You can probably figure out what I think of a Process-And-Tools Oriented approach to Agile, right?


--heusser



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-testing/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-testing/join
(Yahoo! ID required)

<*> To change settings via email:
agile-testing-digest-***@public.gmane.org
agile-testing-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
agile-testing-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Adrian Stokes]

I'm certainly not knowledgeable enough to tell anyone that they are or
aren't 'doing' agile. I think we put too much emphasis on labels. Only
my personal opinion but 'Agile' the brand name is just an umbrella to
separate some principles and practices from other principles and
practices. I think intellectually we want to fully understand things,
including what is and isn't agile. In the real world I believe that
there is very rarely a perfect fit method for every situation. I see
the manifesto as a bunch of ideas, not an instruction manual. Maybe the
next big brand name will be Adaptive or Flexible or simply Sensible?

I don't believe there is only one way of doing most things so why should
there only be one way of producing software? Human interaction creates
so many intangibles you can't cover them all simply. Someone, and I beg
their forgiveness for not crediting them, said they think of agile as a
tool box with things in to use as appropriate (or very similar). I try
to think of life like that. If Bob is good at something and he wants to
do just that, then great. If it fits what the team are doing and more
importantly, want to do. Where I am, getting involved at the start
helps me do my job and imho, adds value to the tasks at hand. Things
may change and I would like to think I could adapt and find other ways
to add value by my knowledge of lots of tools, principles, methods etc,
etc.


________________________________

From: agile-testing-***@public.gmane.org
[mailto:agile-testing-***@public.gmane.org] On Behalf Of Matthew
Sent: 09 September 2010 13:29
To: agile-testing-***@public.gmane.org
Subject: [agile-testing] Re: TDD - is there a role for a tester?






--- In agile-testing-***@public.gmane.org
<mailto:agile-testing%40yahoogroups.com> , "Adrian Stokes"
<***@...> wrote:
>If your using agile principles, by whatever
>name, the tester should be involved in
>defining the tests working along
>side whichever designated roles your company
>has assigned. BAs, PMs,
>Developers, Architects etc etc...

I'm of a divided mind on this. On the one hand yes, just about
every high-functioning 'Agile' team I've worked with does something like
this.

On the other ... I can't find justification for that statement
in the manifesto.

For that matter, what if a high-functioning self-organized team
said "no, we're really gonna let bob focus on testing 'cuz that is what
bob is good at and what he wants to do."

Is that "wrong?" is it "bad?" Is it "Not Agile (R) (TM) (C)?"

If it is "Not Agile", that strikes me as an awful
process-and-tools oriented approach.

You can probably figure out what I think of a Process-And-Tools
Oriented approach to Agile, right?

--heusser






*******************************************************************
This email is intended only for the addressee named above. As this email may contain confidential or privileged information, if you are not the named addressee or receive this message in error, please notify us immediately, delete it and do not make use of or copy it.

This message is protected by copyright. HML accepts no responsibility for viruses found in this message or any file attachment.

Homeloan Management Limited
Registered in England No. 2214839
The Bailey, Skipton, North Yorkshire, BD23 1DN

********************************************************************

[b***@public.gmane.org]

Depends a lot on how narrow a role you can assign to someone you might call
a 'tester'. As a QA professional, I would say there is as much role for a
traditional tester as there is for a traditional developer.

My perspective on Agile methodologies is trying to have a convergence of
roles, more communication and shorter feedback loops since you are working
together. To me, 'traditional' is about waterfall which is inherently about
divergence, having specialists in one particular area whom pass off the
product from one stage to the next (Sales/Marketing, BA, Dev, QA,
Deployment, CSRs).

I have studied software engineering because it makes me a better QA
professional, some developers have studied testing/quality because it makes
them better developers. Have I studied software engineering as much as good
developer? Have most developers studied testing/quality as much as me?
Probably not. Will working together makes us both better and more
productive? That's the idea.

Barring being required by contract (and possibly outsourced then), I see
less of a need for a tester who has minimal technical abilities and can
only follow a test script written by someone else. Much like I would see
less of a need for a developer who doesn't test, follow standards or
understand the domain. These testers could be good candidates to grow since
they likely have a good understanding of the domain.

+Brian


On Aug 25, 2010 5:15am, seanalexaoife <coyle.james-***@public.gmane.org> wrote:
> Hi,
> Test Driven Development. Some articles I read describe it as testing.
> Some articles describe it as development.
> Cem Kaner's blog says: I think that test-driven development is the most
> important advance in the craft of testing of the past 30 years.
> Do people see a role for a 'traditional' tester in TDD?
> thanks
> Jim