Published an intro-to-agile testing article

[Matthew-103]

I just published an article that is a gentle introduction to how a test team
might adapt it's behavior to enable Agile Software Development:

http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1371508,00.html

I tried to focus on hard practices; there are probably a half-dozen articles
in there about, say "whole team", self-organization, treating each other

I'd appreciate your comments, and yes, ratings.  A high rating, is,
essentially, a vote that I should get do more things like this ...

regards,

--
Matthew Heusser,
NEW Testing Blog: http://blogs.stpcollaborative.com/matt/

[Dave Liebreich-2]

Is there any way to get to the article without registering on the site?

On Mon, Oct 19, 2009 at 10:38 AM, Matt Heusser <matt.heusser@...>wrote:

>
>
> I just published an article that is a gentle introduction to how a test
> team might adapt it's behavior to enable Agile Software Development:
>
>
> http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1371508,00.html
>
> I tried to focus on hard practices; there are probably a half-dozen
> articles in there about, say "whole team", self-organization, treating each
> other
>
> I'd appreciate your comments, and yes, ratings.  A high rating, is,
> essentially, a vote that I should get do more things like this ...
>
> regards,
>
> --
> Matthew Heusser,
> NEW Testing Blog: http://blogs.stpcollaborative.com/matt/
>
>
>

[Steven Gordon-2]

Matt,

While other articles may discuss "whole team", I really think you are short
changing the topic by assuming/accepting that QA is a separate team that
cannot start testing a story until the "story is complete".

In agile software development, the story is not complete until it is
tested.  So, I can only assume you are not addressing testing under agile
software development, but under a common misinterpretation of agile where
the development team is separate from the test team.

A good step towards avoiding the time constraints is to integrate with the
development team so that:
- people with a testing mindset and experience can point out some gotchas to
be addressed even before implementation starts,
- testability problems can be addressed in story definition and architecture
design,
- the tests which are going to be automated are automated before the
implementation of stories are complete, shortening the feedback loops.

This leaves mostly exploratory tests for the time between implementation
completion and deployment instead of all the testing.

SteveG



On Mon, Oct 19, 2009 at 10:38 AM, Matt Heusser <matt.heusser@...>wrote:

>
>
> I just published an article that is a gentle introduction to how a test
> team might adapt it's behavior to enable Agile Software Development:
>
>
> http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1371508,00.html
>
> I tried to focus on hard practices; there are probably a half-dozen
> articles in there about, say "whole team", self-organization, treating each
> other
>
> I'd appreciate your comments, and yes, ratings.  A high rating, is,
> essentially, a vote that I should get do more things like this ...
>
> regards,
>
> --
> Matthew Heusser,
> NEW Testing Blog: http://blogs.stpcollaborative.com/matt/
>  
>

[Matthew-103]

--- In agile-testing@..., Steven Gordon <sgordonphd@...> wrote:
>
> Matt,
>
> While other articles may discuss "whole team", I really
> think you are short changing the topic by assuming/accepting
> that QA is a separate team that
> cannot start testing a story until the "story is complete".
>

The focus of the article was how to fit regression testing into a tight timebox.  I'd be happy to do another one where we talk about story-driven development.  That wasn't my focus.

> In agile software development, the story is not
> complete until it is tested.  So, I can only
> assume you are not addressing testing under agile
> software development, but under a common
> misinterpretation of agile where
> the development team is separate from the
> test team.
>

1) I know signatories of the Agile Manifesto who would disagree with your /definitional/ characterization of Agile Software Development, Steve.  Are you calling them 'wrong'?

2) It's a typo, Steve, it should be code complete, and sure, we could do follow-up articles that cover early tester involvement.  I did what I could in 800 words.    I do appreciate the gentle suggestion to choose my words more carefully, and that's what i'll take it as.  As that, it's solid advice.



regards,

--
Matthew Heusser
NEW Testing Blog: http://blogs.spcollaborative.com/matt/

[Matthew-103]

--- In agile-testing@..., Dave Liebreich <dave.liebreich@...> wrote:
>
> Is there any way to get to the article without
>registering on the site?
>

Well, it is a free registration, Dave ... :-)

The best way to get material from me is to volunteer for peer review.  I'll sign you up on the wiki and you can see the article evolve as I type.  And my blog, "Testing at the Edge of Chaos", remains free like water, free like air.

Hey, if you're in Cambridge Mass, send me an email and drop by the Cambridge Hyatt Regency tomorrow.  There will be a reception, Free as in Beer - or drop by Thursday and check out the expo ...


regards,

--
Matthew Heusser,
NEW Testing Blog: http://blogs.stpcollaborative.com/matt/

[Steven Gordon-2]

I could not tell the limited focus from the title or the article.

Ideally, agile software development is holistic - all the phases of software
are tightly integrated into a iteration by working collaboratively on a
small set of stories.  A story is either not yet started, in-progress, or
done.  There are no phases; there are no gates; there are no handoffs.  As
such, code complete is not an agile concept.

If the premise of an article on any aspect of agile software development is
that the situation is not ideal, then those assumptions should be clearly
stated.  In most cases, I believe the right answer when the situation is not
ideal  is to move the situation closer to ideal rather than to just do the
best you can (e.g. live with handoffs).

On Tue, Oct 20, 2009 at 7:11 PM, Matthew <matt.heusser@...> wrote:

>
>
> --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> Steven Gordon <sgordonphd@...> wrote:
> >
> > Matt,
> >
> > While other articles may discuss "whole team", I really
> > think you are short changing the topic by assuming/accepting
> > that QA is a separate team that
> > cannot start testing a story until the "story is complete".
> >
>
> The focus of the article was how to fit regression testing into a tight
> timebox. I'd be happy to do another one where we talk about story-driven
> development. That wasn't my focus.
>
> > In agile software development, the story is not
> > complete until it is tested. So, I can only
> > assume you are not addressing testing under agile
> > software development, but under a common
> > misinterpretation of agile where
> > the development team is separate from the
> > test team.
> >
>
> 1) I know signatories of the Agile Manifesto who would disagree with your
> /definitional/ characterization of Agile Software Development, Steve. Are
> you calling them 'wrong'?
>
> 2) It's a typo, Steve, it should be code complete, and sure, we could do
> follow-up articles that cover early tester involvement. I did what I could
> in 800 words. I do appreciate the gentle suggestion to choose my words more
> carefully, and that's what i'll take it as. As that, it's solid advice.
>
> regards,
>
> --
> Matthew Heusser
> NEW Testing Blog: http://blogs.spcollaborative.com/matt/
>
>  
>
>

[basim_21]

--- In agile-testing@..., Steven Gordon <sgordonphd@...> wrote:
>
> I could not tell the limited focus from the title or the article.
>
> Ideally, agile software development is holistic - all the phases of software
> are tightly integrated into a iteration by working collaboratively on a
> small set of stories.  A story is either not yet started, in-progress, or
> done.  There are no phases; there are no gates; there are no handoffs.  As
> such, code complete is not an agile concept.


How do you describe then when a developer has reached a point whereby a piece a functionality (functionality in the sense that the end user can use) is complete and ready for testing? isn't that a 'hand off' to the next person?  isn't then the code is complete (i.e. is in a working state)

>
> If the premise of an article on any aspect of agile software development is
> that the situation is not ideal, then those assumptions should be clearly
> stated.  In most cases, I believe the right answer when the situation is not
> ideal  is to move the situation closer to ideal rather than to just do the
> best you can (e.g. live with handoffs).
>
> On Tue, Oct 20, 2009 at 7:11 PM, Matthew <matt.heusser@...> wrote:
>
> >
> >
> > --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> > Steven Gordon <sgordonphd@> wrote:
> > >
> > > Matt,
> > >
> > > While other articles may discuss "whole team", I really
> > > think you are short changing the topic by assuming/accepting
> > > that QA is a separate team that
> > > cannot start testing a story until the "story is complete".
> > >
> >
> > The focus of the article was how to fit regression testing into a tight
> > timebox. I'd be happy to do another one where we talk about story-driven
> > development. That wasn't my focus.
> >
> > > In agile software development, the story is not
> > > complete until it is tested. So, I can only
> > > assume you are not addressing testing under agile
> > > software development, but under a common
> > > misinterpretation of agile where
> > > the development team is separate from the
> > > test team.
> > >
> >
> > 1) I know signatories of the Agile Manifesto who would disagree with your
> > /definitional/ characterization of Agile Software Development, Steve. Are
> > you calling them 'wrong'?
> >
> > 2) It's a typo, Steve, it should be code complete, and sure, we could do
> > follow-up articles that cover early tester involvement. I did what I could
> > in 800 words. I do appreciate the gentle suggestion to choose my words more
> > carefully, and that's what i'll take it as. As that, it's solid advice.
> >
> > regards,
> >
> > --
> > Matthew Heusser
> > NEW Testing Blog: http://blogs.spcollaborative.com/matt/
> >
> >  
> >
> >
>

[Janet Gregory]

 
 

> --- In agile-testing@..., Steven Gordon
> <sgordonphd@...> wrote:
> >
> > I could not tell the limited focus from the title or the article.
> >
> > Ideally, agile software development is holistic - all the phases of software
> > are tightly integrated into a iteration by working collaboratively on a
> > small set of stories.  A story is either not yet started, in-progress, or
> > done.  There are no phases; there are no gates; there are no handoffs.  As
> > such, code complete is not an agile concept.
>

From: basim_21 basim@...
> How do you describe then when a developer has reached a point
> whereby a piece a functionality (functionality in the sense that
> the end user can use) is complete and ready for testing? isn't
> that a 'hand off' to the next person?  isn't then the code
> is complete (i.e. is in a working state)

 
The 'whole team' approach is absolutely needed for successful agile projects. There is much more collaboration than "a hand-off" from developer to tester. In a truly collaborative environment, the developers have all the tests early to help them code. Once the code is complete, they will demo to the tester &/or customer. As Steve says, what is left at that time, is the exploratory testing that cannot necessarily be defined up front. Developers don't "hand off" since they are still involved until the story is marked done (testing is complete).
 
Janet Gregory

[Steven Gordon-2]

Thank you, Janet.

There are 2 different kinds of agile testing.   One is how to be effective
at testing/QA when fully integrated into the whole-team agile approach.  The
other is how to still try to be as agile as possible when the organization
is not taking a whole-team approach (i.e., where testing is done by a
separate team after the development team has handed off its work).

Far be it from me to object to any discussion of the second kind of agile
testing.  I only object to discussions/postings/articles that do not make it
clear which kind of agile testing they are referring to, because the issues,
concerns and appropriate resolutions are different.

Steve

On Sun, Oct 25, 2009 at 5:56 AM, Janet Gregory <janet_gregory@...>wrote:

>
>
>
>
> > --- In agile-testing@..., Steven Gordon
> > <sgordonphd@...> wrote:
> > >
> > > I could not tell the limited focus from the title or the article.
> > >
> > > Ideally, agile software development is holistic - all the phases of
> software
> > > are tightly integrated into a iteration by working collaboratively on a
> > > small set of stories.  A story is either not yet started, in-progress,
> or
> > > done.  There are no phases; there are no gates; there are no handoffs.
> As
> > > such, code complete is not an agile concept.
> >
>
> From: basim_21 basim@...
>
> > How do you describe then when a developer has reached a point
> > whereby a piece a functionality (functionality in the sense that
> > the end user can use) is complete and ready for testing? isn't
> > that a 'hand off' to the next person?  isn't then the code
> > is complete (i.e. is in a working state)
>
>
> The 'whole team' approach is absolutely needed for successful agile
> projects. There is much more collaboration than "a hand-off" from developer
> to tester. In a truly collaborative environment, the developers have all the
> tests early to help them code. Once the code is complete, they will demo to
> the tester &/or customer. As Steve says, what is left at that time, is the
> exploratory testing that cannot necessarily be defined up front. Developers
> don't "hand off" since they are still involved until the story is marked
> done (testing is complete).
>
> Janet Gregory
>  
>
>

[Matthew-103]

--- In agile-testing@..., Janet Gregory <janet_gregory@...> wrote:

>  
> The 'whole team' approach is absolutely needed for
>successful agile projects. There is much more
>collaboration than "a hand-off" from developer to tester.
>In a truly collaborative environment, the developers have
>all the tests early to help them code.
>Once the code is complete, they will demo to the tester
>&/or customer. As Steve says, what is left at that time,
>is the exploratory testing that cannot necessarily be
>defined up front. Developers don't "hand off" since they
>are still involved until the story is marked done
>(testing is complete).  
>

Janet, I like you, and, at this point, I feel I've been substantially misrepresented.

I am not arguing against early QA involvement, nor am I suggesting that devs start with a blank slate an no story tests up front.

I /am/ suggesting that many of the best test ideas occur after the code is demoable, and that stories reaches a point where they need aggressive testing, at, at the that point, it's best for the developer to involve a tester if the team has them.

Stephen Gordon has suggested that is not a "whole team" approach, and, here, in your words, your wrote:

"The 'whole team' approach is absolutely needed for successful agile projects"

Seeing as my team has shipped working software to production for 36 of the past 40 iterations, and "whole team" is "absolutely needed" for successful agile projects, I declare my team is doing "whole team" and end the discussion.

regards,

--matthew heusser
(*) - The speaker could, of course, argue that Heusser's team is successful but /not Agile/, the classic argument of the person who's run out of ideas.  Hey man, we ship working software, we respond to change, we focus on individuals and interactions.  Who's the one focusing on definitions and process? :-)

[Janet Gregory]

Matt,
   
Point taken - I may have taken words out of context. I'll reread the article again. There is definitely a need to do some kind of exploratory testing (as well as other types of testing) after the code has been written, and and testers are usually the best people to do it.
 
If you are delivering software successfully, I don't really care what process you use... though I might care what you name  it :-)
 
Janet

----- Original Message -----
From: Matthew <matt.heusser@...>
Date: Monday, October 26, 2009 6:43 am
Subject: [agile-testing] Re: Published an intro-to-agile testing article
To: agile-testing@...

>
>
> --- In agile-testing@..., Janet Gregory
> <janet_gregory@...> wrote:
> >  
> > The 'whole team' approach is absolutely needed for
> >successful agile projects. There is much more
> >collaboration than "a hand-off" from developer to tester.
> >In a truly collaborative environment, the developers have
> >all the tests early to help them code.
> >Once the code is complete, they will demo to the tester
> >&/or customer. As Steve says, what is left at that time,
> >is the exploratory testing that cannot necessarily be
> >defined up front. Developers don't "hand off" since they
> >are still involved until the story is marked done
> >(testing is complete).  
> >
>
> Janet, I like you, and, at this point, I feel I've been
> substantially misrepresented.
>
> I am not arguing against early QA involvement, nor am I
> suggesting that devs start with a blank slate an no story tests
> up front.
>
> I /am/ suggesting that many of the best test ideas occur after
> the code is demoable, and that stories reaches a point where
> they need aggressive testing, at, at the that point, it's best
> for the developer to involve a tester if the team has them.
>
> Stephen Gordon has suggested that is not a "whole team"
> approach, and, here, in your words, your wrote:
>
> "The 'whole team' approach is absolutely needed for successful
> agile projects"
>
> Seeing as my team has shipped working software to production for
> 36 of the past 40 iterations, and "whole team" is "absolutely
> needed" for successful agile projects, I declare my team is
> doing "whole team" and end the discussion.
>
> regards,
>
> --matthew heusser
> (*) - The speaker could, of course, argue that Heusser's team is
> successful but /not Agile/, the classic argument of the person
> who's run out of ideas.  Hey man, we ship working software,
> we respond to change, we focus on individuals and
> interactions.  Who's the one focusing on definitions and
> process? :-)
>
>

[Steven Gordon-2]

Matthew,

I do not understand why you go out of your way to misspell my name so often.

I believe I fully endorse how your team develops software.

However, I do not think that article reads like what you actually do,
especially to somebody who does not practice 'whole team'.   To somebody who
does not practice 'whole team', the article reads like how to proceed with
agile testing anyway.

Steve or Steven, but not Stephen.

On Mon, Oct 26, 2009 at 5:38 AM, Matthew <matt.heusser@...> wrote:

>
>
>
>
> --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> Janet Gregory <janet_gregory@...> wrote:
> >
> > The 'whole team' approach is absolutely needed for
> >successful agile projects. There is much more
> >collaboration than "a hand-off" from developer to tester.
> >In a truly collaborative environment, the developers have
> >all the tests early to help them code.
> >Once the code is complete, they will demo to the tester
> >&/or customer. As Steve says, what is left at that time,
> >is the exploratory testing that cannot necessarily be
> >defined up front. Developers don't "hand off" since they
> >are still involved until the story is marked done
> >(testing is complete).
> >
>
> Janet, I like you, and, at this point, I feel I've been substantially
> misrepresented.
>
> I am not arguing against early QA involvement, nor am I suggesting that
> devs start with a blank slate an no story tests up front.
>
> I /am/ suggesting that many of the best test ideas occur after the code is
> demoable, and that stories reaches a point where they need aggressive
> testing, at, at the that point, it's best for the developer to involve a
> tester if the team has them.
>
>
> Stephen Gordon has suggested that is not a "whole team" approach, and,
> here, in your words, your wrote:
>
> "The 'whole team' approach is absolutely needed for successful agile
> projects"
>
> Seeing as my team has shipped working software to production for 36 of the
> past 40 iterations, and "whole team" is "absolutely needed" for successful
> agile projects, I declare my team is doing "whole team" and end the
> discussion.
>
> regards,
>
> --matthew heusser
> (*) - The speaker could, of course, argue that Heusser's team is successful
> but /not Agile/, the classic argument of the person who's run out of ideas.
> Hey man, we ship working software, we respond to change, we focus on
> individuals and interactions. Who's the one focusing on definitions and
> process? :-)
>
>  
>

[Matthew-103]

--- In agile-testing@..., Steven Gordon <sgordonphd@...> wrote:
>
> Matthew,
>
> I do not understand why you go out of your way to misspell
>my name so often.
>

I can remember to make it Steve.  I honestly apologize.

Also, Steve, I accept your point that the article could be misunderstood.

It took me about 10,000 words to write my chapter for beautiful testing, because anything less would miss something important.  Perhaps a 'scope statement' at the top would help?

--heusser

[Steven Gordon-2]

Instead of saying 'whole team' is covered by other articles, perhaps saying
that this article covers what to do /after/ achieving 'whole team' to the
extent that is practical, as covered in other articles.

On Mon, Oct 26, 2009 at 7:09 AM, Matthew <matt.heusser@...> wrote:

>
>
> --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> Steven Gordon <sgordonphd@...> wrote:
> >
> > Matthew,
> >
> > I do not understand why you go out of your way to misspell
> >my name so often.
> >
>
> I can remember to make it Steve. I honestly apologize.
>
> Also, Steve, I accept your point that the article could be misunderstood.
>
> It took me about 10,000 words to write my chapter for beautiful testing,
> because anything less would miss something important. Perhaps a 'scope
> statement' at the top would help?
>
> --heusser
>
>  
>
>

[andrew_prentice_os]

> If you are delivering software successfully, I don't really care what process you use... though I might care what you name  it :-)

Really? Why? If someone is delivering software successfully, I really do care about the process they use, but couldn't care less about what they name it.

Andrew

--- In agile-testing@..., Janet Gregory <janet_gregory@...> wrote:
>
> Matt,
>    
> Point taken - I may have taken words out of context. I'll reread the article again. There is definitely a need to do some kind of exploratory testing (as well as other types of testing) after the code has been written, and and testers are usually the best people to do it.
>  
> If you are delivering software successfully, I don't really care what process you use... though I might care what you name  it :-)
>  
> Janet
>

[Smith, John H]

Andrew,

 

Sorry to chip in.

 

I believe test should at all times be aware what software is called if
what you are referring to is Versioning.

 

Secondly, we are just attempting to start running in a more Agile mode
and was wondering if anyone is aware what course is the best for Test
managers in order to have all basic concepts and detail of what to look
out for as well as what his/her team should be aware of.

 

Thanks

John

 

 

From: agile-testing@...
[mailto:agile-testing@...] On Behalf Of Andrew
Sent: 26 October 2009 23:26
To: agile-testing@...
Subject: [agile-testing] Re: Published an intro-to-agile testing article

 

 

> If you are delivering software successfully, I don't really care what
process you use... though I might care what you name it :-)

Really? Why? If someone is delivering software successfully, I really do
care about the process they use, but couldn't care less about what they
name it.

Andrew

--- In agile-testing@...
<mailto:agile-testing%40yahoogroups.com> , Janet Gregory
<janet_gregory@...> wrote:
>
> Matt,
>
> Point taken - I may have taken words out of context. I'll reread the
article again. There is definitely a need to do some kind of exploratory
testing (as well as other types of testing) after the code has been
written, and and testers are usually the best people to do it.
>
> If you are delivering software successfully, I don't really care what
process you use... though I might care what you name it :-)
>
> Janet
>