Please see the 'Links' section of this mailing list for helpful
articles and papers.

"Testing Extreme Programming" (Addison-Wesley 2002) by myself and Tip
House has chapters related to cultural changes of implementing XP
from a tester's point of view.  I think the information would apply
at least to some degree no matter what agile process you're
introducing.

-- Lisa
--- In agile-testing@yahoogroups.com, Roshini <roshini@i...> wrote:
> Dear All,
>
> My company has adopted agile culture recently. As a QA, what are
the
> things i need to know and what are the changes i need to bring as
part
> of testing. What cultural change if any, should be brought among
all the
> testers
>
> Hope i am clear.  pl get back to me if there is any clarifications.
>
> Thanks in advance
>
> Regards,
> Roshini.

In May, we started our first "agile" project here, using stories
rather than requirements (although requirements had already been
written) and doing 4-week iterations (which we called "sprints"
because everyone liked that term better).  The app is a web-based
order entry app.  We are not doing any other XP or agile practices on
this project.  I couldn't convince them to try daily standups, so we
just had weekly status meetings.

Some parts of stories had to be dropped for the first "sprint".
However, these and some of the second sprint were released to us a
week later, and we were able to do our "production" release more or
less on schedule (we did release to production, although nobody used
the app from there; our websites share much of the code so it was
important that they keep working!)  Note that we were not trying to
complete testing during the sprint, as you would with XP or Scrum.
Baby steps.

The second sprint is being delivered a week late - bad practice, but
it was the last sprint and we have a hard deadline to get into
production.  Delays were due to dependencies on work being done by
programmers outside the project, to under-estimating, and to time
being eaten up by unrelated production emergencies and vacation.

During both sprints, the programmers worked closely with the customer
when they realized that some features could never be done in time.
Some features were dropped, some were greatly modified.  The only
problem with this is that as the tester, I was not always in the loop
on these changes.  I would have liked to be included in those
meetings.  Now I have to play catch-up.  Of course, I'm working on
other projects so it's hard for them to include me in every meeting.

A couple of stories were not included in either sprint, so a third
sprint is needed to pick those up.  Other things in the schedule got
pushed back to allow this to happen.  The third sprint can only be 2
weeks long.

The bottom line is that the "customers" (our customer service
organization) will not get everything they wanted.  However, they
agree that if we hadn't taken the iterative approach, at this point
we would be in a giant panic with no code delivered to production or
even to test.  Meanwhile, another big project (fortunately, a less
critical one) which did not take the iterative approach has
degenerated into panic mode and is missing its launch date.

The VPs on both the customer and technical side are pleased that this
approach provided benefit.  The main benefit they saw is that we
started coding much earlier than we would have otherwise.  They'd
like to do a good retrospective of this project and see what other
agile processes/practices they could try in the future.  For
starters, I think they need standup meetings, tracking, less time
spent in up front planning meetings (they tried too hard to nail down
details which changed anyway), retrospectives after each sprint, and
better estimating.  But, it's not up to me to decide.

I'm going to try to sell them on the idea of trying Scrum.  Since it
provides a good agile framework for planning but doesn't prescribe
engineering practices, I think it may work better than trying to
introduce XP.  I'll continue to advocate XP practices (they are
still, slowly, adding to the pile of automated unit tests; my summer
intern helped in this effort!) but it has to be the developers'
decision what practices they think will add value.  Anyone have an
opinion on this idea?


We still have to test Sprint Two and get this into production... wish
me luck!
-- Lisa

There are a couple of thing which I'd like to know to have a correct idea
about project "largeness":
- how many programmer worked on each sprint?
- how big was the code? (number of class, or linecode)



>In May, we started our first "agile" project here, using stories
>rather than requirements (although requirements had already been
>written) and doing 4-week iterations (which we called "sprints"
>because everyone liked that term better).  The app is a web-based
>order entry app.  We are not doing any other XP or agile practices on
>this project.  I couldn't convince them to try daily standups, so we
>just had weekly status meetings.
>
>Some parts of stories had to be dropped for the first "sprint".
>However, these and some of the second sprint were released to us a
>week later, and we were able to do our "production" release more or
>less on schedule (we did release to production, although nobody used
>the app from there; our websites share much of the code so it was
>important that they keep working!)  Note that we were not trying to
>complete testing during the sprint, as you would with XP or Scrum.
>Baby steps.
>
>The second sprint is being delivered a week late - bad practice, but
>it was the last sprint and we have a hard deadline to get into
>production.  Delays were due to dependencies on work being done by
>programmers outside the project, to under-estimating, and to time
>being eaten up by unrelated production emergencies and vacation.
>
>During both sprints, the programmers worked closely with the customer
>when they realized that some features could never be done in time.
>Some features were dropped, some were greatly modified.  The only
>problem with this is that as the tester, I was not always in the loop
>on these changes.  I would have liked to be included in those
>meetings.  Now I have to play catch-up.  Of course, I'm working on
>other projects so it's hard for them to include me in every meeting.
>
>A couple of stories were not included in either sprint, so a third
>sprint is needed to pick those up.  Other things in the schedule got
>pushed back to allow this to happen.  The third sprint can only be 2
>weeks long.
>
>The bottom line is that the "customers" (our customer service
>organization) will not get everything they wanted.  However, they
>agree that if we hadn't taken the iterative approach, at this point
>we would be in a giant panic with no code delivered to production or
>even to test.  Meanwhile, another big project (fortunately, a less
>critical one) which did not take the iterative approach has
>degenerated into panic mode and is missing its launch date.
>
>The VPs on both the customer and technical side are pleased that this
>approach provided benefit.  The main benefit they saw is that we
>started coding much earlier than we would have otherwise.  They'd
>like to do a good retrospective of this project and see what other
>agile processes/practices they could try in the future.  For
>starters, I think they need standup meetings, tracking, less time
>spent in up front planning meetings (they tried too hard to nail down
>details which changed anyway), retrospectives after each sprint, and
>better estimating.  But, it's not up to me to decide.
>
>I'm going to try to sell them on the idea of trying Scrum.  Since it
>provides a good agile framework for planning but doesn't prescribe
>engineering practices, I think it may work better than trying to
>introduce XP.  I'll continue to advocate XP practices (they are
>still, slowly, adding to the pile of automated unit tests; my summer
>intern helped in this effort!) but it has to be the developers'
>decision what practices they think will add value.  Anyone have an
>opinion on this idea?
>
>
>We still have to test Sprint Two and get this into production... wish
>me luck!
>-- Lisa
>
>
>

_________________________________________________________________
Comunica in un ’altra dimensione con MSN Extra Storage!
http://www.msn.it/msnservizi/es/?xAPID=534&DI=1044&SU=http://hotmail.it/&HL=HMTA\
GTX_Comunica

Lisa Crispin wrote:
  >
   > I couldn't convince them to try daily standups, so we
   > just had weekly status meetings.

Are you at least allowed to use Scrum's pig/chicken and
do/did/impediment format for the weekly status meetings?

Curious,
--
Bil Kleb, NASA, Hampton, Virginia, USA

I definitely think that context is really important and XP isn't
right for everyone. That said, it really would be most beneficial if
you could commit to XP, as there is a synergy of the practices which
really gives the best result.

Anyway, I have introduced elements of XP in various contexts and had
some good results. I think there are groups of practices that need to
be done together.

Automated testing and refactoring go well together. You don't have to
commit to pair programming to gain significant benefits from
automated testing and refactoring, though it is very, very hard to
refactor if you don't have the automated tests to provide the
necessary change detection to confidently make improvements.

Simple, iterative design is a really good practice, but IMHO requires
automated tests / refactoring.

Collective code ownership and pair programming are a set. For
example, you can have fixed pairs, which would not necessarily result
in collective code ownership, but a lot of the value is swapping
partners. This almost always results in collective code ownership and
tends to also promote simple, iterative design. It is also easier to
enforce code standards with changing pairs/ collective ownership.

I think the planning game and morning standups are really useful,
though these are borrowed from scrum and you already indicated you
want to introduce scrum.

In the cases where I haven't used "pure" XP, I have presented the
elements of XP to the team and given my suggestions for what
practices go well together. I then let the team decide what they want
to start with.

I ask that they commit to the practice for at least some set period
of time, usually 2 to 4 weeks before re-evaluating and tweaking.
Hopefully, the team will find their appropriate comfort level.

Chris



-----Original Message-----
From: Lisa Crispin [mailto:lisa.crispin@...]
Sent: Monday, August 04, 2003 2:51 PM
To: agile-testing@yahoogroups.com
Subject: [agile-testing] Update on the "introducing agile" saga

I'm going to try to sell them on the idea of trying Scrum.  Since it
provides a good agile framework for planning but doesn't prescribe
engineering practices, I think it may work better than trying to
introduce XP.  I'll continue to advocate XP practices (they are
still, slowly, adding to the pile of automated unit tests; my summer
intern helped in this effort!) but it has to be the developers'
decision what practices they think will add value.  Anyone have an
opinion on this idea?


We still have to test Sprint Two and get this into production... wish
me luck!
-- Lisa

--- In agile-testing@yahoogroups.com, "Lisa Crispin"
<lisa.crispin@a...> wrote:
> I'm going to try to sell them on the idea of trying Scrum.  Since
it
> provides a good agile framework for planning but doesn't prescribe
> engineering practices, I think it may work better than trying to
> introduce XP.  I'll continue to advocate XP practices (they are
> still, slowly, adding to the pile of automated unit tests; my
summer
> intern helped in this effort!) but it has to be the developers'
> decision what practices they think will add value.  Anyone have an
> opinion on this idea?

I have the same experience, Lisa. Talking about XP somewhat
frightens people. By taking up SCRUM and talking about it, people
see more the advantages of it (or they don't feel threatened). Is it
because the practices of SCRUM sounds less developers-stuff???

To introduce the XP practices you really need one or two (highly
admired) developers who will join you in your 'agilism'.
Here in our most recent (large!) project the technical leader stood
up and said "In this project I will only allow code that has passed
the unittest framework". That is great!

Wishing you lots of succes,

Anko

--- In agile-testing@yahoogroups.com, "xp xp" <xpgdn@h...> wrote:
> There are a couple of thing which I'd like to know to have a
correct idea
> about project "largeness":
> - how many programmer worked on each sprint?
> - how big was the code? (number of class, or linecode)
>
>
There were only two full-time developers on the project and one was
on vacation for about half of Sprint One (that developer also had
vastly underestimated his tasks).  Three other developers worked part
time on Sprint Two.  I don't really know how to express the size of
it, it's a web-based order entry system with searching, a shopcart
and a buy process.  They didn't start from scratch, they used the
existing code for our website and changed it, plus added frames and
Javascript to adapt it to a framework that works for taking telephone
orders.

>In May, we started our first "agile" project here, using stories
>rather than requirements (although requirements had already been
>written) and doing 4-week iterations (which we called "sprints"
>because everyone liked that term better).

How do you deal with bugs? I try to explain better: a typical iteration is
4-week long, so there are no release before 4 weeks. What do you do if a
client discover a bug after a few days? Does he have to wait until next
release (4 weeks) or do you create a new release only to fix the bug?
The response of other people are welcome

_________________________________________________________________
Nuovo MSN Messenger 6.0 con sfondi e giochi! http://messenger.msn.it/
Provalo subito!

On Wednesday, August 6, 2003, at 5:15:37 AM, xp xp wrote:

>>In May, we started our first "agile" project here, using stories
>>rather than requirements (although requirements had already been
>>written) and doing 4-week iterations (which we called "sprints"
>>because everyone liked that term better).

> How do you deal with bugs? I try to explain better: a typical iteration is
> 4-week long, so there are no release before 4 weeks. What do you do if a
> client discover a bug after a few days? Does he have to wait until next
> release (4 weeks) or do you create a new release only to fix the bug?
> The response of other people are welcome

XP projects build the software multiple times per day. If the customer
wants to schedule a bug fix, he can do so by removing a feature of equal
weight from the mix.

XP projects have customer acceptance tests to run when they think a feature
is implemented. They rarely release bugs, because if the tests don't run,
the feature isn't done.

There are other ways. The above seem to be good ways.

Ron Jeffries
www.XProgramming.com
First they ignore you, then they laugh at you, then they fight you, then you
win.
   - Gandhi

dear Agilist, what is the feeling about XPrefactored by Stevens and Rosenberg

--- In agile-testing@yahoogroups.com, Bil Kleb <Bil.Kleb@N...> wrote:
> Lisa Crispin wrote:
>  >
>   > I couldn't convince them to try daily standups, so we
>   > just had weekly status meetings.
>
> Are you at least allowed to use Scrum's pig/chicken and
> do/did/impediment format for the weekly status meetings?
>
> Curious,
> --
> Bil Kleb, NASA, Hampton, Virginia, USA

No, the status meetings are long and drawn out and everyone talks too
much!  You can tell I'm not in a position of great influence.  ;->

--- In agile-testing@yahoogroups.com, "xp xp" <xpgdn@h...> wrote:

> How do you deal with bugs? I try to explain better: a typical
iteration is
> 4-week long, so there are no release before 4 weeks. What do you do
if a
> client discover a bug after a few days? Does he have to wait until
next
> release (4 weeks) or do you create a new release only to fix the
bug?
> The response of other people are welcome
Ron has already replied with the best way to deal with bugs.  Since
we aren't doing XP, we did a test cycle after the end of the sprint,
the bugs were found and fixed at that time, before release.  If any
bugs were found after release, critical ones would be fixed with
patches, otherwise releases would be done in our normal 2 week
release cycle (yes, that's confusing, we do production releases to
the websites every 2 weeks if there's something ready to go).

This particular project is being done in such a rush, that even the
hit or miss unit testing typical of our projects has not been done.
The developers feel bad about that, I wish they could have the
opportunity to feel they are doing their best work.

> dear Agilist, what is the feeling about XPrefactored by Stevens and
Rosenberg

There is already an XP Signature Series book, XP Questioned by Pete McBreen,
in this role.

I have never read XPR, and should not review it. The word about it seems to
be those two guys tried to invent a competing methodology, Iconix or
something, and they are losers. Their Web site is full of the same kind of
tired mud-slinging as used to afflict news:comp.object up until about a year
ago. Google for David Lightstone, Gerold Keefer, JRStern, Steve Perryman, or
Elliott Universe to read the effect.

--
   Phlip
         http://www.greencheese.org/PeaceAndCalm
   --  Programming without Tan Lines, LLC  --

How do I know when to update Acceptance Test scripts when there are changes
in Stories, but there is no Onsite Customer or tool to inform me of said
changes?

Cheers

Aidy

On Sunday, August 10, 2003, at 06:43  AM, Rutter, Adrian wrote:

> How do I know when to update Acceptance Test scripts when there are
> changes
> in Stories, but there is no Onsite Customer or tool to inform me of
> said
> changes?

I hope that when a new or changed story arrives, people talk about it.
One of the things they might say is, "Can we learn anything from the
existing tests?" They might be reminded of product features that have
to keep working just as they do now. Or they might realize they've
overlooked features that the story will make them change - because what
some test says about the product won't any longer make sense, given the
new story. And, along the way, they'll update relevant tests.

How do you find the relevant tests? One way is team memory. That might
be reliable enough. There might be written traceability to old stories,
but I wouldn't do that unless I were forced into it. Seems like a lot
of overhead.

Something I've done is to go find some code that I know will be
exercised by the new story and break it. Then I rerun the tests, see
which fail. Those are a set of relevant tests to think about. Seems to
work OK, but I don't have enough experience to be dogmatic about it.

But I think technical tricks like that only supplement the team
conversation. They shouldn't replace it. If you're not in on the
conversation, get in on it.

-----
Brian Marick
Consulting, training, contracting, and research
Focused on the intersection of testing, programming, and design
marick@..., marick@...
www.testing.com, www.visibleworkings.com

I'm program chair or cohost of these events:
PLoP: <http://jerry.cs.uiuc.edu/~plop/plop2003/>
FIT Fest: <http://fitnesse.org/XpFitFest.FrontPage>
Please join me.

Aidy:
>How do I know when to update Acceptance Test scripts when there are
changes
>in Stories, but there is no Onsite Customer or tool to inform me of said
>changes?

Umm, when you roll out the chicken bones, and flip the tarot cards, and
they show a shadow where you didn't expect one to be? :-)

In all seriousness, if you have no objective criteria, and/or no role that
is responsible for keeping these things in synch, what is left besides
intuition? How were the stories determined to have covered the stories
properly in the first place?

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
--------
A Plan is a list of things that don't happen

> > How do I know when to update Acceptance Test scripts when there are
> > changes
> > in Stories, but there is no Onsite Customer or tool to inform me of
> > said
> > changes?
>
> I hope that when a new or changed story arrives, people talk about it.
> One of the things they might say is, "Can we learn anything from the
> existing tests?" They might be reminded of product features that have
> to keep working just as they do now. Or they might realize they've
> overlooked features that the story will make them change - because what
> some test says about the product won't any longer make sense, given the
> new story. And, along the way, they'll update relevant tests.

Such tests spawn new categories. A category probably shares new fixtures.
Each fixture re-uses over a set of test resources.

> How do you find the relevant tests? One way is team memory. That might
> be reliable enough. There might be written traceability to old stories,
> but I wouldn't do that unless I were forced into it. Seems like a lot
> of overhead.

By shaking the whole box to see if any bug appears. Add a completely new
kind of test. See what happens.

> Something I've done is to go find some code that I know will be
> exercised by the new story and break it. Then I rerun the tests, see
> which fail. Those are a set of relevant tests to think about. Seems to
> work OK, but I don't have enough experience to be dogmatic about it.
> Brian Marick

I have added lots of assert statements by paste.

--
   Phlip
     http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

We are looking for an agile tester to join our team. Candidate should
have at least half a year experience in writing acceptance tests and
working with an agile process like XP. Experience with SCADA systems,
testing web based applications and automating tests would be
beneficial.

This is a full-time, salary position. We are located in Calgary, AB.
Local candidates are preferable. No telecommuting.

Please send your resumes to careers@..., subject: QA Position in
Calgary


About Wireless Matrix

Wireless Matrix is a leading developer and provider of wireless data
solutions for business operations involving mobile workforces and
remote assets. Wireless Matrix mobile and telemetry services are
deployed in major corporate industrial markets including oil and gas,
utilities, transportation and field service. The Company operates a
multi-network wireless gateway service that interfaces to proprietary
hosted or third party applications to provide end-to-end wireless
information services to key enterprise markets. Its products include
specially designed multi-mode mobile and telemetry modems that uniquely
satisfy its target market demands. Wireless Matrix is headquartered in
Calgary, Alberta, and has offices in Reston, Virginia and Burnaby,
British Columbia.

On Wednesday, August 6, 2003, at 9:53:25 AM, H.L.Hausen wrote:

> dear Agilist, what is the feeling about XPrefactored by Stevens and Rosenberg

Is it out yet? Rosenburgs earlier publications on the subject have been
amusing but ill-directed. He makes up things to say about XP that aren't
true, and then refutes them. Does it very cleverly though.

Ron Jeffries
www.XProgramming.com
The greatest mistake we make is living in constant fear that we will make one.
   --  John Maxwell

I've worked in a (somewhat) agile environment, and I really enjoy
the difference that this has made in my working life, in the
interaction between QA and development, and the improvement in
product quality.

Currently I'm unemployed and have been interviewing.  After having
worked in and managed an agile environment, its really hard to go
back to the QA orthodoxy.  You know, the software would be perfect
if only we (QA) could force the developers to follow our (overblown,
wasteful) process.  There are just so many QA zealots out there who
believe the SEI/CMM is the be all and end all -not to say that it
doesn't have its value in the right context- and will solve all the
worlds problems.

Has anyone been successful in introducing agile methods to QA in an
environment where the *developers* are still using a traditional
waterfall methodology?  Or in an environment where the developers
are agile, but QA is still wanting a big-design-up-front?

Has anyone developed an equivalent 12 practices for *QA*?  In my
last job, I was able to institute a small level of paired testing,
and saw how much that improved the testing process.  Of course, this
testing had to be conducted behind closed doors, as the powers that
be saw it as "goofing off" and "we could get more done if everyone
was working on a distinct task". ;-)

--- In agile-testing@yahoogroups.com, "Chris" <christelreeve@y...>
wrote:
> Has anyone been successful in introducing agile methods to QA in
> an environment where the *developers* are still using a
> traditional waterfall methodology?  Or in an environment where the
> developers are agile, but QA is still wanting a big-design-up-
> front?

[AT] Recently Lisa Crispin has written an article about it in
Methods&Tools. You can find it at:
http://www.methodsandtools.com/mt/download.html

Personally I have tried for the last 2 years here to apply agile
practices into our software development. Sometimes it feels like
you're alone in the dessert... It is very very hard to change people
the way they think, to ask the right questions, to get them to
listen.
The best way to start (if you still wanna...;-> )is to create
attention by focussing on the things that go wrong now. Maybe it
requirements management, maybe it's late delivery, maybe it's bad
quality slipping out the door. To each of these problems, agile
development has a proper solution. But first get people to
acknowledge the problem(s). But then again, you shouldn't give
people the idea that they do *everything* wrong - after all their
boss doesn't think so!
Find some real professionals in your organization, people who care
about quality. Let them read Extreme Programming Explained, or a
short article about XP. Most of the time the good developers are
willing to listen. Get them on your side!

Be prepared to have some resistance, but realize that resistance is
often caused by unknowingness, fear of losing control, and fear of
change. There's always something underneath resistance!
[\AT]

> Has anyone developed an equivalent 12 practices for *QA*?
[AT] Great question! Isn't that something worth a special thread on
this group!?!
[\AT]

Wishing you lots of luck!

Anko Tijman
***************************
`First they ignore you,
then they laugh at you,
then they fight you,
then you win' --- Mahatma Gandhi
***************************

On Wednesday, September 3, 2003, at 4:42:18 AM, Anko Tijman wrote:

> Sometimes it feels like
> you're alone in the dessert...

Or, in deep pudding, as we sometimes call it ...

Ron Jeffries
www.XProgramming.com
When all ideas of [XP] is and [XP] is not have been extinguished,
then [XP] reality will manifest itself.  -- Thich Nhat Hanh [Ron Jeffries]

On Wednesday, September 3, 2003, at 4:42:18 AM, Anko Tijman wrote:

>> Has anyone developed an equivalent 12 practices for *QA*?
> [AT] Great question! Isn't that something worth a special thread on
> this group!?!
> [\AT]

Sure is! Go for it!

Ron Jeffries
www.XProgramming.com
Steering is more important than speed,
in driving and in software development.

--- In agile-testing@yahoogroups.com, Ron Jeffries
<ronjeffries@X...> wrote:
> On Wednesday, September 3, 2003, at 4:42:18 AM, Anko Tijman wrote:
>
> >> Has anyone developed an equivalent 12 practices for *QA*?
> > [AT] Great question! Isn't that something worth a special thread
on
> > this group!?!
> > [\AT]
>
> Sure is! Go for it!
>
> Ron Jeffries
> www.XProgramming.com
> Steering is more important than speed,
> in driving and in software development.

Yes, I will.... be thinking for a while!


Anko
*********************************************************************
There is only one thing more painful than learning from experience
and that is not learning from experience. Archibald McLeish
*********************************************************************

In Lisa's book, she talks about the 4 values, and lists some of the
tester activities. Maybe these could be a start for creating the
practices. The activities she lists are:
1 Help negotiate quality with the customer
2 Help clarify stories
3 Help with estimates during planning
4 Advocate customer's rights
5 Guard the programmer's rights
6 Work with the customer to write effective and thorough acceptance
tests
7 Make sure acceptance tests ...verfity the quality specified by the
custoemr
8 Help automate maintainable acceptance tests
9 Make sure test results are reported in a timely maner, forming a
continuous feedback loop
10 Make sure acceptance testing keeps pace with development
11 Help the programmers design more testable code
12 Keep the team honest

So, maybe a start to the practices could be

Pair Testing - using point #11 and expanding. Pair testing helps the
developer to understand the tester point of view. It also a whole
lot more which I won't get into here.

Continuous feedback - using point #9.

Those are the first 2 to come to my mind. Anyone else have any ideas?

Janet Gregory

--- In agile-testing@yahoogroups.com, Ron Jeffries
<ronjeffries@X...> wrote:
> On Wednesday, September 3, 2003, at 4:42:18 AM, Anko Tijman wrote:
>
> >> Has anyone developed an equivalent 12 practices for *QA*?
> > [AT] Great question! Isn't that something worth a special thread
on
> > this group!?!
> > [\AT]
>
> Sure is! Go for it!
>
> Ron Jeffries
> www.XProgramming.com
> Steering is more important than speed,
> in driving and in software development.

----- Original Message -----

From: Janet Gregory

To: agile-testing@yahoogroups.com

Sent: Wednesday, September 03, 2003 12:25 PM

Subject: [agile-testing] Agile Testing Practices

In Lisa's book, she talks about the 4 values, and lists some of the
tester activities. Maybe these could be a start for creating the
practices. The activities she lists are:
1 Help negotiate quality with the customer
2 Help clarify stories
3 Help with estimates during planning
4 Advocate customer's rights
5 Guard the programmer's rights
6 Work with the customer to write effective and thorough acceptance
tests
7 Make sure acceptance tests ...verfity the quality specified by the
custoemr
8 Help automate maintainable acceptance tests
9 Make sure test results are reported in a timely maner, forming a
continuous feedback loop
10 Make sure acceptance testing keeps pace with development
11 Help the programmers design more testable code
12 Keep the team honest

So, maybe a start to the practices could be

Pair Testing - using point #11 and expanding. Pair testing helps the
developer to understand the tester point of view. It also a whole
lot more which I won't get into here.

Continuous feedback - using point #9.

Those are the first 2 to come to my mind. Anyone else have any ideas?

Janet Gregory

--- In agile-testing@yahoogroups.com, Ron Jeffries
<ronjeffries@X...> wrote:
> On Wednesday, September 3, 2003, at 4:42:18 AM, Anko Tijman wrote:
>
> >> Has anyone developed an equivalent 12 practices for *QA*?
> > [AT] Great question! Isn't that something worth a special thread
on
> > this group!?!
> > [\AT]
>
> Sure is! Go for it!
>
> Ron Jeffries
> www.XProgramming.com
> Steering is more important than speed,
> in driving and in software development.



To unsubscribe from this group, send an email to:
agile-testing-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Sorry Tiago

I took for granted everyone knew what Lisa's book was. It is:

"Testing Extreme Progamming" by Lisa Crispin and Tip House,
published by Addison Wesley. It is one the XP Series.



--- In agile-testing@yahoogroups.com, Tiago Soldá <tsolda@t...>
wrote:
>     Hello! I am a student from Brazil, and need a
information: "Lisa's Book", well, what is the name os this book? The
complete name of the writer. I'm interested about it. If anyone can
give me this information, I'll be thankfull! :-)
>     For all, bye!! See Ya!
>   ----- Original Message -----
>   From: Janet Gregory
>   To: agile-testing@yahoogroups.com
>   Sent: Wednesday, September 03, 2003 12:25 PM
>   Subject: [agile-testing] Agile Testing Practices
>
>
>   In Lisa's book, she talks about the 4 values, and lists some of
the
>   tester activities. Maybe these could be a start for creating the
>   practices. The activities she lists are:
>   1 Help negotiate quality with the customer
>   2 Help clarify stories
>   3 Help with estimates during planning
>   4 Advocate customer's rights
>   5 Guard the programmer's rights
>   6 Work with the customer to write effective and thorough
acceptance
>   tests
>   7 Make sure acceptance tests ...verfity the quality specified by
the
>   custoemr
>   8 Help automate maintainable acceptance tests
>   9 Make sure test results are reported in a timely maner, forming
a
>   continuous feedback loop
>   10 Make sure acceptance testing keeps pace with development
>   11 Help the programmers design more testable code
>   12 Keep the team honest
>
>   So, maybe a start to the practices could be
>
>   Pair Testing - using point #11 and expanding. Pair testing helps
the
>   developer to understand the tester point of view. It also a
whole
>   lot more which I won't get into here.
>
>   Continuous feedback - using point #9.
>
>   Those are the first 2 to come to my mind. Anyone else have any
ideas?
>
>   Janet Gregory
>
>   --- In agile-testing@yahoogroups.com, Ron Jeffries
>   <ronjeffries@X...> wrote:
>   > On Wednesday, September 3, 2003, at 4:42:18 AM, Anko Tijman
wrote:
>   >
>   > >> Has anyone developed an equivalent 12 practices for *QA*?
>   > > [AT] Great question! Isn't that something worth a special
thread
>   on
>   > > this group!?!
>   > > [\AT]
>   >
>   > Sure is! Go for it!
>   >
>   > Ron Jeffries
>   > www.XProgramming.com
>   > Steering is more important than speed,
>   > in driving and in software development.
>
>
>         Yahoo! Groups Sponsor
>               ADVERTISEMENT
>
>
>
>
>   To unsubscribe from this group, send an email to:
>   agile-testing-unsubscribe@yahoogroups.com
>
>
>
>   Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.

From: Janet Gregory

To: agile-testing@yahoogroups.com

Sent: Wednesday, September 03, 2003 7:34 PM

Subject: [agile-testing] Re: Agile Testing Practices

Sorry Tiago

I took for granted everyone knew what Lisa's book was. It is:

"Testing Extreme Progamming" by Lisa Crispin and Tip House,
published by Addison Wesley. It is one the XP Series.



--- In agile-testing@yahoogroups.com, Tiago Soldá <tsolda@t...>
wrote:
>     Hello! I am a student from Brazil, and need a
information: "Lisa's Book", well, what is the name os this book? The
complete name of the writer. I'm interested about it. If anyone can
give me this information, I'll be thankfull! :-)
>     For all, bye!! See Ya!
>   ----- Original Message -----
>   From: Janet Gregory
>   To: agile-testing@yahoogroups.com
>   Sent: Wednesday, September 03, 2003 12:25 PM
>   Subject: [agile-testing] Agile Testing Practices
>
>
>   In Lisa's book, she talks about the 4 values, and lists some of
the
>   tester activities. Maybe these could be a start for creating the
>   practices. The activities she lists are:
>   1 Help negotiate quality with the customer
>   2 Help clarify stories
>   3 Help with estimates during planning
>   4 Advocate customer's rights
>   5 Guard the programmer's rights
>   6 Work with the customer to write effective and thorough
acceptance
>   tests
>   7 Make sure acceptance tests ...verfity the quality specified by
the
>   custoemr
>   8 Help automate maintainable acceptance tests
>   9 Make sure test results are reported in a timely maner, forming
a
>   continuous feedback loop
>   10 Make sure acceptance testing keeps pace with development
>   11 Help the programmers design more testable code
>   12 Keep the team honest
>
>   So, maybe a start to the practices could be
>
>   Pair Testing - using point #11 and expanding. Pair testing helps
the
>   developer to understand the tester point of view. It also a
whole
>   lot more which I won't get into here.
>
>   Continuous feedback - using point #9.
>
>   Those are the first 2 to come to my mind. Anyone else have any
ideas?
>
>   Janet Gregory
>
>   --- In agile-testing@yahoogroups.com, Ron Jeffries
>   <ronjeffries@X...> wrote:
>   > On Wednesday, September 3, 2003, at 4:42:18 AM, Anko Tijman
wrote:
>   >
>   > >> Has anyone developed an equivalent 12 practices for *QA*?
>   > > [AT] Great question! Isn't that something worth a special
thread
>   on
>   > > this group!?!
>   > > [\AT]
>   >
>   > Sure is! Go for it!
>   >
>   > Ron Jeffries
>   > www.XProgramming.com
>   > Steering is more important than speed,
>   > in driving and in software development.
>
>
>         Yahoo! Groups Sponsor
>               ADVERTISEMENT
>             
>       
>       
>
>   To unsubscribe from this group, send an email to:
>   agile-testing-unsubscribe@yahoogroups.com
>
>
>
>   Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.



To unsubscribe from this group, send an email to:
agile-testing-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

If you gather 4&5 together, and realise that still the QA role in XP
is not really figured out yet, you would get the practice:

Advocate Rights - the rights of the programmer, of the customer and
of QA.

QA: Why is QA in XP/agile? Because they can play a role in every of
the 4 values:
Feedback: passing acceptance tests
Communication: making the acceptance criteria explicit, bringing the
customer & developer together, explaining technical stuff to the
customer
Courage: by raising possible problems, asking questions, and
encouraging courage when it's necessary (better quality!)
Simplicity: has a lot to do with communication, by making explicit
what needs to be done you know better what is the simplest thing
possible.

Points 1, 6 & 7:
Accept the Acceptance tests - make sure it's exactly what the
customer wants (no more, no less) in ways of delivering business
value, quality, performance, usability, etc (you know, all the
quality criteria you learned while you were still 'in the dark' :-> )
Most of the time the customer doesn't realise that that is part of
the acceptance tests too, and the programmer is not focused at these
items (no offense!).

Anko
****
"None of us is as smart as all of us" - Gerald Weinberg
****


--- In agile-testing@yahoogroups.com, "Janet Gregory"
<janet_gregory@s...> wrote:
> In Lisa's book, she talks about the 4 values, and lists some of
the tester activities. Maybe these could be a start for creating the
> practices. The activities she lists are:
> 1 Help negotiate quality with the customer
> 2 Help clarify stories
> 3 Help with estimates during planning
> 4 Advocate customer's rights
> 5 Guard the programmer's rights
> 6 Work with the customer to write effective and thorough
acceptance
> tests
> 7 Make sure acceptance tests ...verfity the quality specified by
the
> custoemr
> 8 Help automate maintainable acceptance tests
> 9 Make sure test results are reported in a timely maner, forming a
> continuous feedback loop
> 10 Make sure acceptance testing keeps pace with development
> 11 Help the programmers design more testable code
> 12 Keep the team honest
>
> So, maybe a start to the practices could be
>
> Pair Testing - using point #11 and expanding. Pair testing helps
the
> developer to understand the tester point of view. It also a whole
> lot more which I won't get into here.
>
> Continuous feedback - using point #9.
>
> Those are the first 2 to come to my mind. Anyone else have any
ideas?
>
> Janet Gregory