--- In agile-testing@yahoogroups.com, "jonos79" <jonos@...> wrote:
>
> I am tasked with presenting to co-workers the ideas, methods and a
> summary of what Agile testing is? Any helpful sources out there? The
> co-workers are all new to agile testing and have a traditional
> waterfall etc approach background. All are new to agile, I have worked
> on one project and it was an agile mess....
>

Brian Marick's Agile Testing Directions is one of the earliest (2004)
and remains one of the best explanations of Agile Testing in general:
http://www.testing.com/cgi-bin/blog/2004/05/26#directions-toc

If you're working on an XP project, Lisa Crispin and Tip House's book
Testing Extreme Programming is helpful (and it's another early entrant
with a publication date in 2002):
http://www.amazon.com/exec/obidos/ASIN/0321113551

Jonathan Kohl has a wealth of great stuff at his blog,
http://www.kohl.ca/blog/

And I really liked Jonathan's article, Exploratory Testing on Agile
Teams: http://www.informit.com/articles/article.aspx?p=405514

I'll humbly recommend my own Google talk on Agile Testing:
http://video.google.com/videoplay?docid=-3054974855576235846

And my own blog: http://www.testobsessed.com

Particularly the Agile Testing slides:
http://testobsessed.com/wordpress/wp-content/uploads/2006/11/agiletesting-talk-n\
ov2006.pdf

And this overview: http://www.testobsessed.com/2005/01/19/agile-testing/

Hope that helps...

Elisabeth

-----------------------------
Elisabeth Hendrickson
Quality Tree Software, Inc.
http://www.qualitytree.com

jonos79 wrote:

> I am tasked with presenting to co-workers the ideas, methods and a summary
> of what Agile testing is? Any helpful sources out there? The co-workers
> are all new to agile testing and have a traditional waterfall etc approach
> background.

Here's a survey of good webpages on each bullet point of a tester's role in
an Agile project:

http://c2.com/cgi/wiki?AgileTesting

> All are new to agile, I have worked on one project and it was an agile
> mess....

If it was a mess, it wasn't "agile". Which agile practices did y'all skip?

--
   Phlip
   http://www.oreilly.com/catalog/9780596510657/
   "Test Driven Ajax (on Rails)"
   assert_xpath, assert_javascript, & assert_ajax

jonos79 wrote:

> I am tasked with presenting to co-workers the ideas, methods and a summary
> of what Agile testing is? Any helpful sources out there? The co-workers
> are all new to agile testing and have a traditional waterfall etc approach
> background.

Here's a survey of good webpages on each bullet point of a tester's role in
an Agile project:

http://c2.com/cgi/wiki?AgileTesting

> All are new to agile, I have worked on one project and it was an agile
> mess....

If it was a mess, it wasn't "agile". Which agile practices did y'all skip?

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax

Hi all,

I'm new to Agile and we're considering using Fit. I wanted to solicit both
good and bad feedback. I've found some good sites and the following book
but wondered what everyone thought of it. We're creating a Java
application that is not (at least starting out) web based.

Thanks for the insight.

Michelle

Jeffrey Fredrick and Paul Julius, on behalf of the Open Information
Foundation, are pleased to announce CITCON Europe 2007 will be held in
Brussels on October 19 & 20. CITCON is free to attend.

CITCON (Continuous Integration and Testing Conference) brings together
people from every corner of the software development industry to
discuss Continuous Integration and the type of Testing that goes along
with it.

CITCON follows an OpenSpace format which means there is no single
speaker, per se. Instead, it's an exchange of ideas based on an
initial topic and agenda. It works amazingly well and you'll learn a
ton, especially with the caliber of people that attend a CITCON.

If you would like to register for CITCON, please visit the website.
http://citconf.com/brussels2007
http://citconf.com/brussels2007/register.php

If you have any questions, please feel free to contact me. We hope to
see everyone at CITCON Brussels in October!

Register now! Space is limited to 100 registrants.

Sorry my brain wasn't working here's the book link:

http://www.amazon.com/exec/obidos/tg/detail/-/0321269349/qid=1120782273/


> Hi all,
>
> I'm new to Agile and we're considering using Fit. I wanted to solicit both
> good and bad feedback. I've found some good sites and the following book
> but wondered what everyone thought of it. We're creating a Java
> application that is not (at least starting out) web based.
>
> Thanks for the insight.
>
> Michelle
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Hi, Michelle...

Here's what I found in using Fitnesse (not FIT) on a couple of
moderately-sized projects in the financial sector.  Where there are problems
listed, some are due to my own mistakes; others are simply preferences;
still others are philosophical problems.

I loved the ability to intersperse descriptions and tables of examples; I
had been looking for something like that for years.  Tables of examples are
generally good points of departure for describing the happy-path behaviour
of functions somewhere above the unit level, and somewhere below the GUI
level.  They show certain kinds of relationships between input and output
very nicely, and projecting those tables on-screen in design meetings was
helpful.  At my organization, some people, especially developers, tended to
emphasize tables of examples over descriptions, as you might expect.  The
developers liked tables; others--especially me--didn't like the tables quite
as much.  I attribute this to different thinking and learning styles.  I
learned more about the product by writing descriptions between the tables,
by telling the story of what was going on in the various tranactions.  That
helped me to identify more risks and more problems more easily.  The
juxtaposition of stories and tables was cool, and I think left the product
more understandable as a result.

I was somewhat disappointed that we didn't make more use of other forms of
description--especially diagrams--when the diagram tells the story most
clearly and the tool affords the chance to do so.  Fitnesse didn't do that
very smoothly, though.  I absolutely hated the clunky editor-that-wasn't;
just an HTML control.  Even porting tables in and out of Excel was
irritating.  I left the organization before they put Fitnesse on hold to try
a development cycle using FIT with Word instead; that might have been
better.  The speed of running the tests was seductive, but the time and
energy to prepare them, at least in our case, was pretty intense, and the
cost vs. the value of preparing more elaborate tests was very high.  At
several points, I got sucked into doing less direct interaction with the
product, where that interaction would have revealed more important problems
more quickly, and would have enhanced learning.

One big trap in all this is that it's easy to make an example work; it's
harder to envision the many and varied ways that a function or a set of
integrated functions can fail.  I found that Fitnesse had a slightly
narcotic effect; one develops a sleepy addiction to seeing green bars.  This
can encourage shortcuts that distract from good testing.  As an example, we
had one high-level transaction that was composed of three lower-level
transactions.  The developers wrote a fixture that implemented the
high-level transaction by integrating the three lower-level transactions and
stringing them together.  If there were a problem in one of them, it would
be caught with the unit tests and higher-level examples, right?  Well... no,
and we got slightly scorched by that on at least one occasion in a somewhat
embarrassing way.

Our developers were pretty good about providing fixtures when asked, but it
was remained easier for them to place priority on production code, since
that's the way the culture and the informal reward systems tended to work.

When I arrived, Fitnesse had already been established for a while and the
organizational culture was to use it as a testing tool on a new version of a
legacy product.  I tried, with some success, to change the culture, because
although they guided development nicely, the tests weren't terribly valuable
/as tests/.  One prominent example:  the team had testers setting up a
significant number of bone-headedly simple GUI tests using HTMLFixture.  The
fixture was poorly documented and, even had it been well documented, was
just a dumb way of testing what they were testing.  Eventually, we replaced
all that kind of stuff with Ruby/Watir, which was vastly more efficient and
flexible.

I maintain that Fitnesse is not so useful as a testing tool.  It's much
better as a requirements and (up to a point) a design tool.  That the
examples are runnable is very nice, and the fast feedback is welcome, once
you've gotten over the investment of creating and filling out the tables.
But the setup for elaborate tests was often expensive, and tests were just
confirming that we had met some requirement to some degree.  That's not a
bad thing, but it's not looking for important problems, either.  Like unit
tests, Fitnesse is a useful way for developers to assert that the product
does /at least these things/, and it sometimes can detect poor refactoring.
That didn't happen very often in our case, since our developers unit tested
pretty well and were pretty careful.  As Joe Rainsberger nicely put it, when
the Fitnesse tests pass, it doesn't mean that you're done; it means that
it's time to get the testers to really kick the snot out of it.

So:  as a descriptive and confirmatory tool for low- to mid-level functional
tests, Fitnesse had some strong points.  As an investigative tool and for
higher-level stuff, my experience was that it was fairly weak.  But that's
okay; that's why we need a variety of tools, and that's why we need to
explore.  I'd like to work on a greenfield project where Fitnesse was used
more extensively for the first purpose.

I mostly liked the FIT book, but I didn't like the one-dimensional
characters that are used to exposit some of the development work.  This is a
problem for me with a certain kind of writing style:  "Andy came into my
office and slumped into my spare chair.  'What's wrong, Andy?' I asked.  'I
don't know,' he replied.  'Sometimes I feel like I'm just a cheap literary
device.'"  And yes, I've done it too, but I try to avoid it.)

---Michael B.

________________________________

From: agile-testing@yahoogroups.com [mailto:agile-testing@yahoogroups.com]
On Behalf Of michelle@...
Sent: September 5, 2007 9:09 AM
To: agile-testing@yahoogroups.com
Subject: Re: [agile-testing] Fit for agile?



Sorry my brain wasn't working here's the book link:

http://www.amazon.com/exec/obidos/tg/detail/-/0321269349/qid=1120782273/
<http://www.amazon.com/exec/obidos/tg/detail/-/0321269349/qid=1120782273/>

> Hi all,
>
> I'm new to Agile and we're considering using Fit. I wanted to solicit both
> good and bad feedback. I've found some good sites and the following book
> but wondered what everyone thought of it. We're creating a Java
> application that is not (at least starting out) web based.
>
> Thanks for the insight.
>
> Michelle
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Just a suggestion, plz ignore if cannot apply in your situatuion
>
> "and have a centralized view of the results" like the build status in cruise
control.
>
You can pipe the output to mail command and set a email to related
users, or a file in a share drive.

> and I want it to run on windows and linux.
>
cygwin

On Wed, Sep 05, 2007 at 01:18:11PM -0300, Ricardo Fernandes wrote:
-> "and have a centralized view of the results" like the build status in cruise
-> control.
->
-> and I want it to run on windows and linux.

buildbot.

http://agiletesting.blogspot.com/2006/02/continuous-integration-with-buildbot.ht\
ml

http://agiletesting.blogspot.com/2006/03/running-buildbot-on-various-platforms.h\
tml

Your server can run on anything, although UNIX is probably best; clients
can run on anything (...that supports Python, yes, but that includes
your iPhone now...)

cheers,
--titus

---

From: agile-testing@yahoogroups.com [mailto:agile-testing@yahoogroups.com] On Behalf Of Simon Godfrey
Sent: Thursday, August 30, 2007 12:27 PM
To: agile-testing@yahoogroups.com
Subject: Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

I'd be very cautious of driving by dates rather than by functionality. The project I'm currently working on tried this initially and it failed miserably. We're now driving by functionality and things are moving forward at a much quicker rate. I think though, that largely this comes down to getting buy-in from those who're delivering the code and whether they feel they're having unrealistic targets imposed on them.

 

As for estimation, could a pert-chart not be a good way to tie up the many streams of work and their dependencies?
 

Si

----- Original Message ----
From: Steven Gordon <sgordonphd@...>
To: agile-testing@yahoogroups.com
Sent: Thursday, 30 August, 2007 3:16:24 PM
Subject: Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

Sometime it is more agile to drive the software development with release dates than drive the release dates with software development.

In other words, pick a date and use a method like George suggests to help the customer figure out what could be done by that date.  This drives more realistic priority decisions and puts greater controls on overrunning release dates.  The organization will learn to have something releasable by any given date. 

Even if for business reasons, the external release date must currently be driven by when a critical mass of functionality will be done, doing internal releases every 2-3 months will create the above discipline, establish a heartbeat, and give everybody valuable practice doing releases (in all likelihood, leading to a better release process).

Steve

On 8/30/07, George Dinwiddie <lists@...> wrote:

Lori,

The best thing I've found is to take the stack of estimated story cards,
divide them into piles where the sum of estimates is no larger than the
velocity, and then count the piles. That gives you the number of
iterations.

You can do the same estimations in software, but that won't make them any
more accurate.

This is still an estimate, of course, not a commitment. If the velocity
changes, you'll need to revisit it. If new stories get added, you'll need
to revisit it.

One phenomena I've noticed is that when using software, people put more
faith in the estimate and are less willing to adjust it to real-world
conditions. Your mileage may vary.

If you've got some long lead time activities depending on the answer, you
may want to add some padding. That padding can be used to accomplish some
"nice to have" stories if all the "must have" stories get completed. If
velocity drops, or important stories are discovered, then perhaps that
padding will provide space.

- George

On Wed, August 29, 2007 17:33, lori_oakley wrote:
> My company is moving the rest of development towards Agile. I have a
> very basic question that no one has given me a good answer to: How do
> you estimate the release date using Agile? I know that "Friends don't
> let other friends use Microsoft Project". I've plowed through hundreds
> of pages on Agile estimating but I've never gotten a definitive answer
> on a piece of software that can be used for estimating. Please don't
> give up, read on.
>
> A release date is actually a very complicated question for our company.
> We develop the software, while hardware engineering does prototypes
> then manufacturing must create their processes, develop new lines, get
> suppliers, etc. Sales has to be ramped up. ISO compliant procedures
> must be documented. All of these depend on when we produce the software.
>
> Microsoft Project Plan is awful for trying to use for estimating. It
> does a good job of keeping a list of everything that needs to get done
> if you don't let the dates drive you nutty. It's not good enough due to
> the large number of people who must depend on our end date to say,
> we'll get done, when we get done. Is there anything out there that
> you've used or seen in action? There's plenty of vaporware out there
> and blogs full of puffed up people stating Microsoft bad, my way best.
> I'd really appreciate some real life solutions where there are hundreds
> of other people that depend on your dates.
>
> Thanks,
>
> Lori Oakley
> Senior SQA
> BI, Inc.
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

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

On Sep 5, 2007, at 10:46 AM, Michael Bolton wrote:

> The developers wrote a fixture that implemented the
> high-level transaction by integrating the three lower-level
> transactions and
> stringing them together.  If there were a problem in one of them,
> it would
> be caught with the unit tests and higher-level examples, right?
> Well... no,
> and we got slightly scorched by that on at least one occasion in a
> somewhat
> embarrassing way.

I'd like to hear more about that. There are so few descriptions of
interaction/integration bugs.

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog

I am using Fit currently on agile project. I also read this book and
found it very helpful. Specifically, some suggestions to improve
FitNesse pages were something I could use straight away.. If you are
using Java/Eclipse/FitNesse you might find it interesting to explore
plugin from BandX, this allows you to launch and work with FitNesse
from inside your eclipse shell.. Hope it helps.

Regards,
Geek
WWW.TestingGeek.Com

--- In agile-testing@yahoogroups.com, michelle@... wrote:
>
> Sorry my brain wasn't working here's the book link:
>
> http://www.amazon.com/exec/obidos/tg/detail/-/0321269349/qid=1120782273/
>
>
> > Hi all,
> >
> > I'm new to Agile and we're considering using Fit. I wanted to
solicit both
> > good and bad feedback. I've found some good sites and the
following book
> > but wondered what everyone thought of it. We're creating a Java
> > application that is not (at least starting out) web based.
> >
> > Thanks for the insight.
> >
> > Michelle
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

---

From: agile-testing@yahoogroups.com [mailto:agile-testing@yahoogroups.com] On Behalf Of Simon Godfrey
Sent: Wednesday, September 05, 2007 10:45 AM
To: agile-testing@yahoogroups.com
Subject: Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

Exactly what's happening on this project now. The closer we get to validation the more I understand about what's actually in this product. This very afternoon I've been through the requirements with the project manager and we've removed tens of requirements, that's 1.5 years into the project and 5 weeks before the first validation run. *sigh*

 

Thanks,

 

Simon

----- Original Message ----
From: "Bradley, Todd" <todd.bradley@...>
To: agile-testing@yahoogroups.com
Sent: Wednesday, 5 September, 2007 5:37:54 PM
Subject: RE: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

In most every project I've worked on since the 1980's, it usually comes down to date.  We get to some time before the somewhat artificially-conceived release date, and someone says, "Well, we've just realized you can't have all the functionality you want by this date."  And then the negotation begins of "So, what can I have?"  Usually the business person accepts less than 100% functionality in order to get the product out on time, contrary to the mantra they've been repeating the past N months of "I need all functionality AND it's got to be on time."

 

Coming to the realization that the date nearly always wins - and that there are software management methods that accept that rather than fight it - was one of my most enlightening experiences of the past 5 years.

 

 

Todd.

 

 

 

---

From: agile-testing@yahoogroups.com [mailto:agile-testing@yahoogroups.com] On Behalf Of Simon Godfrey
Sent: Thursday, August 30, 2007 12:27 PM
To: agile-testing@yahoogroups.com
Subject: Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

I'd be very cautious of driving by dates rather than by functionality. The project I'm currently working on tried this initially and it failed miserably. We're now driving by functionality and things are moving forward at a much quicker rate. I think though, that largely this comes down to getting buy-in from those who're delivering the code and whether they feel they're having unrealistic targets imposed on them.

 

As for estimation, could a pert-chart not be a good way to tie up the many streams of work and their dependencies?
 

Si

----- Original Message ----
From: Steven Gordon <sgordonphd@...>
To: agile-testing@yahoogroups.com
Sent: Thursday, 30 August, 2007 3:16:24 PM
Subject: Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

Sometime it is more agile to drive the software development with release dates than drive the release dates with software development.

In other words, pick a date and use a method like George suggests to help the customer figure out what could be done by that date.  This drives more realistic priority decisions and puts greater controls on overrunning release dates.  The organization will learn to have something releasable by any given date. 

Even if for business reasons, the external release date must currently be driven by when a critical mass of functionality will be done, doing internal releases every 2-3 months will create the above discipline, establish a heartbeat, and give everybody valuable practice doing releases (in all likelihood, leading to a better release process).

Steve

On 8/30/07, George Dinwiddie <lists@...> wrote:

Lori,

The best thing I've found is to take the stack of estimated story cards,
divide them into piles where the sum of estimates is no larger than the
velocity, and then count the piles. That gives you the number of
iterations.

You can do the same estimations in software, but that won't make them any
more accurate.

This is still an estimate, of course, not a commitment. If the velocity
changes, you'll need to revisit it. If new stories get added, you'll need
to revisit it.

One phenomena I've noticed is that when using software, people put more
faith in the estimate and are less willing to adjust it to real-world
conditions. Your mileage may vary.

If you've got some long lead time activities depending on the answer, you
may want to add some padding. That padding can be used to accomplish some
"nice to have" stories if all the "must have" stories get completed. If
velocity drops, or important stories are discovered, then perhaps that
padding will provide space.

- George

On Wed, August 29, 2007 17:33, lori_oakley wrote:
> My company is moving the rest of development towards Agile. I have a
> very basic question that no one has given me a good answer to: How do
> you estimate the release date using Agile? I know that "Friends don't
> let other friends use Microsoft Project". I've plowed through hundreds
> of pages on Agile estimating but I've never gotten a definitive answer
> on a piece of software that can be used for estimating. Please don't
> give up, read on.
>
> A release date is actually a very complicated question for our company.
> We develop the software, while hardware engineering does prototypes
> then manufacturing must create their processes, develop new lines, get
> suppliers, etc. Sales has to be ramped up. ISO compliant procedures
> must be documented. All of these depend on when we produce the software.
>
> Microsoft Project Plan is awful for trying to use for estimating. It
> does a good job of keeping a list of everything that needs to get done
> if you don't let the dates drive you nutty. It's not good enough due to
> the large number of people who must depend on our end date to say,
> we'll get done, when we get done. Is there anything out there that
> you've used or seen in action? There's plenty of vaporware out there
> and blogs full of puffed up people stating Microsoft bad, my way best.
> I'd really appreciate some real life solutions where there are hundreds
> of other people that depend on your dates.
>
> Thanks,
>
> Lori Oakley
> Senior SQA
> BI, Inc.
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

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

Hello,

I am doing my Masters thesis in Engineering Management at Northeastern
University, Boston, MA.  My thesis examines how software outsourcing
and global software development projects operate.  In turn, I am
conducting a brief survey related to this.

http://www.surveymonkey.com/s.aspx?sm=TPmVEY3RvZ%2bXggSwUPE37A%3d%3d

I would very much appreciate if you could help me by taking my survey,
which will take less than 5 minutes of your time to complete.  Also,
if you can forward the survey to anyone you know who is working on
software development in any role, such as engineering, QA, consulting,
management, etc that would be greatly appreciated.

Many thanks,

Rajko Ilincic

---

From: agile-testing@yahoogroups.com [mailto:agile-testing@yahoogroups.com] On Behalf Of Simon Godfrey
Sent: Thursday, September 06, 2007 5:55 AM
To: agile-testing@yahoogroups.com
Subject: Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

I'm not really sure I agree with your definition of funny Todd. I know that I'm looking at a product which has been designed with the designers taking any notice of the requirements and that this highlights a huge issu in our software development process. I'm also aware that changes have been made to this requirements document which haven't been circulated to those who originally signed said requirements off.

 

Thanks,

 

Simon
http://testingdiary.blogspot.com/

----- Original Message ----
From: "Bradley, Todd" <todd.bradley@...>
To: agile-testing@yahoogroups.com
Sent: Wednesday, 5 September, 2007 8:34:16 PM
Subject: RE: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

Yeah, it's kind of funny to learn just how optional some "requirements" turn out to be when the project's behind schedule...

 

 

Todd.

 

---

From: agile-testing@yahoogroups.com [mailto:agile-testing@yahoogroups.com] On Behalf Of Simon Godfrey
Sent: Wednesday, September 05, 2007 10:45 AM
To: agile-testing@yahoogroups.com
Subject: Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

Exactly what's happening on this project now. The closer we get to validation the more I understand about what's actually in this product. This very afternoon I've been through the requirements with the project manager and we've removed tens of requirements, that's 1.5 years into the project and 5 weeks before the first validation run. *sigh*

 

Thanks,

 

Simon

----- Original Message ----
From: "Bradley, Todd" <todd.bradley@...>
To: agile-testing@yahoogroups.com
Sent: Wednesday, 5 September, 2007 5:37:54 PM
Subject: RE: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

In most every project I've worked on since the 1980's, it usually comes down to date.  We get to some time before the somewhat artificially-conceived release date, and someone says, "Well, we've just realized you can't have all the functionality you want by this date."  And then the negotation begins of "So, what can I have?"  Usually the business person accepts less than 100% functionality in order to get the product out on time, contrary to the mantra they've been repeating the past N months of "I need all functionality AND it's got to be on time."

 

Coming to the realization that the date nearly always wins - and that there are software management methods that accept that rather than fight it - was one of my most enlightening experiences of the past 5 years.

 

 

Todd.

 

 

 

---

From: agile-testing@yahoogroups.com [mailto:agile-testing@yahoogroups.com] On Behalf Of Simon Godfrey
Sent: Thursday, August 30, 2007 12:27 PM
To: agile-testing@yahoogroups.com
Subject: Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

I'd be very cautious of driving by dates rather than by functionality. The project I'm currently working on tried this initially and it failed miserably. We're now driving by functionality and things are moving forward at a much quicker rate. I think though, that largely this comes down to getting buy-in from those who're delivering the code and whether they feel they're having unrealistic targets imposed on them.

 

As for estimation, could a pert-chart not be a good way to tie up the many streams of work and their dependencies?
 

Si

----- Original Message ----
From: Steven Gordon <sgordonphd@...>
To: agile-testing@yahoogroups.com
Sent: Thursday, 30 August, 2007 3:16:24 PM
Subject: Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

Sometime it is more agile to drive the software development with release dates than drive the release dates with software development.

In other words, pick a date and use a method like George suggests to help the customer figure out what could be done by that date.  This drives more realistic priority decisions and puts greater controls on overrunning release dates.  The organization will learn to have something releasable by any given date. 

Even if for business reasons, the external release date must currently be driven by when a critical mass of functionality will be done, doing internal releases every 2-3 months will create the above discipline, establish a heartbeat, and give everybody valuable practice doing releases (in all likelihood, leading to a better release process).

Steve

On 8/30/07, George Dinwiddie <lists@...> wrote:

Lori,

The best thing I've found is to take the stack of estimated story cards,
divide them into piles where the sum of estimates is no larger than the
velocity, and then count the piles. That gives you the number of
iterations.

You can do the same estimations in software, but that won't make them any
more accurate.

This is still an estimate, of course, not a commitment. If the velocity
changes, you'll need to revisit it. If new stories get added, you'll need
to revisit it.

One phenomena I've noticed is that when using software, people put more
faith in the estimate and are less willing to adjust it to real-world
conditions. Your mileage may vary.

If you've got some long lead time activities depending on the answer, you
may want to add some padding. That padding can be used to accomplish some
"nice to have" stories if all the "must have" stories get completed. If
velocity drops, or important stories are discovered, then perhaps that
padding will provide space.

- George

On Wed, August 29, 2007 17:33, lori_oakley wrote:
> My company is moving the rest of development towards Agile. I have a
> very basic question that no one has given me a good answer to: How do
> you estimate the release date using Agile? I know that "Friends don't
> let other friends use Microsoft Project". I've plowed through hundreds
> of pages on Agile estimating but I've never gotten a definitive answer
> on a piece of software that can be used for estimating. Please don't
> give up, read on.
>
> A release date is actually a very complicated question for our company.
> We develop the software, while hardware engineering does prototypes
> then manufacturing must create their processes, develop new lines, get
> suppliers, etc. Sales has to be ramped up. ISO compliant procedures
> must be documented. All of these depend on when we produce the software.
>
> Microsoft Project Plan is awful for trying to use for estimating. It
> does a good job of keeping a list of everything that needs to get done
> if you don't let the dates drive you nutty. It's not good enough due to
> the large number of people who must depend on our end date to say,
> we'll get done, when we get done. Is there anything out there that
> you've used or seen in action? There's plenty of vaporware out there
> and blogs full of puffed up people stating Microsoft bad, my way best.
> I'd really appreciate some real life solutions where there are hundreds
> of other people that depend on your dates.
>
> Thanks,
>
> Lori Oakley
> Senior SQA
> BI, Inc.
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

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

Dear Candidate,

We wanted to drop you a line in regards to an
excellent opportunity as Software Developer - Asp.net
we have here at Radixweb.

If you or someone you know have interest in the same
position, please send your updated CV to us
immediately or you may call us for further process.
Please go through the company profile and job profile
in the attachment.

Background - Radixweb

Radix is a technology obsessed company always on the
look-out for challenging projects, improvement to its
project management techniques, providing and
facilitating multi-diversified services and solutions
and with an un-paralleled aggression to complete and
deliver any project undertaking with utmost quality,
punctuality and in cost effective manner.

The approach of Radix has by far made it one of the
fastest growing entities in India. A registered unit
of "Software Trade Park of India" the company rose
from just three staff to over eighty and growing team
of dedicated and skilled professionals within a span
of six years since its launch.

The company has been evolving through out the years
and during its course of evolution the offering
capabilities of Radix as Offshore development center,
Business Process Outsourcing partner kept increasing.
Today Radix can boast of successfully executing 250+
and above projects in a range of complexities an
enviable market reach and concise strategy to serve.
Radix as whole unit possess an distilled sense of
commitment, dedication and team sprit, team work and
has adopted a no-compromise mode of approach when it
delivering high quality solutions for its clients,
project sponsors.

Perhaps the very approach of Radix should be credited
Radix for being listed among the top 10-20 of the list
in service, solution providers of our kind in India

Dot Net Developer:

Candidate would be responsible for following
activities:

1) Responsible for successful planning and follow
through aimed at profitable, high quality and timely
completion of projects.

2) Responsible to interact with the US/UK clients for
necessary amendments / changes in the projects as per
need arises. Capable to understand & analyzing the
client"s requirements.

3) Should be ready to on tight project delivery
schedules and deadlines as required.

The person should have atleast 1-2 years sound
experience in programming expereince using .Net,
Asp.net,C#,OOPS, ADO.Net. Strong SQL Server Skills
(SQL Query, Stored Procedure, Triggers and Views). The
person should have sound communication skills.

Please send your resume to hr@...


Regards,
Vaishali Sharma
Resource Recruitment Executive

M.Krishnan
Asst.Mgr-HR
Radixweb
B-30, Adarsh Society, B/h-Bhagwati Chambers,
Next to Kashi parekh COmplex, Nr.Swastick Cross Road,
CG Road, Ahmedabad-380009.
Email: hr@...
www.rndinfo.com
09377608642


Send instant messages to your online friends http://uk.messenger.yahoo.com

Company: SPi, http://www.spi-bpo.com

Location: Austin, Texas

Job: Test Automation Specialist

Our agile development teams are writing more code than we can test in
time! We're looking for an experienced test automation specialist who
enjoys scripting tests, which will free the rest of us up to do
different tests. We have some scripting tools on hand, but if the
right candidate needs a tool we don't have, we'll get it. Must be very
comfortable with relational databases; SQL skills are required.

More details available upon request.

Please contact:
Tanya Martin-McClellan, CSTE
QA Manager, SPi Legal
t.mcclellan@...

"Nobody should care if the developers didn't read the requirements or
if the requirements document hasn't been circulated or signed, as long
as the customer is happy with the software."

Which is the biggest load of tosh I have ever seen, the reason Agile
Development will never be seen as anything other than a means by which
lazy developers don't have to follow any procedures.

The next time you want a minor change to the system you have to go back
and redesign things from scratch, what a complete load of rubbish.

Oh and if the end User's Accounts Department wants a way of backing out
of paying the bill you just handed it to them on a silver platter.

It depends on the project, to what extent you should use FitNesse.
Problems that Michael stated are all valid.. FitNesse is good for low
to mid level functional test cases and I completely agree with that..
I will share my example on how we are using it currently. In our
project, we transform from one file format (XML kind) to another file
format (XML kind) and than use some mature tool to produce content.
Majority of work involved in our project is related to the
transformation from one format to another.. If done properly, it can
be assumed that close to eighty percent functionality is working
fine.. Also last step or final content is not available to the tester,
until most of the transformation is working properly ( Because of
infrastructure and project specific issues).. In this situation,
testers were not used effectively.. but that was before FitNesse.

We created FitNesse tables to represent input XML files and asked
development team to give us interface to query the generated output
file.. We even wrote the fixtures to generate XML kind input from the
FitNesse tables and developers were responsible for giving us
interface that we need. We also made sure that for every sprint, we
add story for developing these interfaces as well. As a result of
that, now testers can test application much before.. So far this
approach is giving us very good results.. And yes, we are not relying
on only this , we will test application once it is available.. but
FitNesse has become instrumental in making sure that testers can test
application much earlier (low to mid level)..

Regards,
Geek
WWW.TestingGeek.Com


--- In agile-testing@yahoogroups.com, Michael Bolton <mb@...> wrote:
>
> Hi, Michelle...
>
> Here's what I found in using Fitnesse (not FIT) on a couple of
> moderately-sized projects in the financial sector.  Where there are
problems
> listed, some are due to my own mistakes; others are simply preferences;
> still others are philosophical problems.
>
> I loved the ability to intersperse descriptions and tables of
examples; I
> had been looking for something like that for years.  Tables of
examples are
> generally good points of departure for describing the happy-path
behaviour
> of functions somewhere above the unit level, and somewhere below the GUI
> level.  They show certain kinds of relationships between input and
output
> very nicely, and projecting those tables on-screen in design
meetings was
> helpful.  At my organization, some people, especially developers,
tended to
> emphasize tables of examples over descriptions, as you might expect.
  The
> developers liked tables; others--especially me--didn't like the
tables quite
> as much.  I attribute this to different thinking and learning styles.  I
> learned more about the product by writing descriptions between the
tables,
> by telling the story of what was going on in the various
tranactions.  That
> helped me to identify more risks and more problems more easily.  The
> juxtaposition of stories and tables was cool, and I think left the
product
> more understandable as a result.
>
> I was somewhat disappointed that we didn't make more use of other
forms of
> description--especially diagrams--when the diagram tells the story most
> clearly and the tool affords the chance to do so.  Fitnesse didn't
do that
> very smoothly, though.  I absolutely hated the clunky
editor-that-wasn't;
> just an HTML control.  Even porting tables in and out of Excel was
> irritating.  I left the organization before they put Fitnesse on
hold to try
> a development cycle using FIT with Word instead; that might have been
> better.  The speed of running the tests was seductive, but the time and
> energy to prepare them, at least in our case, was pretty intense,
and the
> cost vs. the value of preparing more elaborate tests was very high.  At
> several points, I got sucked into doing less direct interaction with the
> product, where that interaction would have revealed more important
problems
> more quickly, and would have enhanced learning.
>
> One big trap in all this is that it's easy to make an example work; it's
> harder to envision the many and varied ways that a function or a set of
> integrated functions can fail.  I found that Fitnesse had a slightly
> narcotic effect; one develops a sleepy addiction to seeing green
bars.  This
> can encourage shortcuts that distract from good testing.  As an
example, we
> had one high-level transaction that was composed of three lower-level
> transactions.  The developers wrote a fixture that implemented the
> high-level transaction by integrating the three lower-level
transactions and
> stringing them together.  If there were a problem in one of them, it
would
> be caught with the unit tests and higher-level examples, right?
Well... no,
> and we got slightly scorched by that on at least one occasion in a
somewhat
> embarrassing way.
>
> Our developers were pretty good about providing fixtures when asked,
but it
> was remained easier for them to place priority on production code, since
> that's the way the culture and the informal reward systems tended to
work.
>
> When I arrived, Fitnesse had already been established for a while
and the
> organizational culture was to use it as a testing tool on a new
version of a
> legacy product.  I tried, with some success, to change the culture,
because
> although they guided development nicely, the tests weren't terribly
valuable
> /as tests/.  One prominent example:  the team had testers setting up a
> significant number of bone-headedly simple GUI tests using
HTMLFixture.  The
> fixture was poorly documented and, even had it been well documented, was
> just a dumb way of testing what they were testing.  Eventually, we
replaced
> all that kind of stuff with Ruby/Watir, which was vastly more
efficient and
> flexible.
>
> I maintain that Fitnesse is not so useful as a testing tool.  It's much
> better as a requirements and (up to a point) a design tool.  That the
> examples are runnable is very nice, and the fast feedback is
welcome, once
> you've gotten over the investment of creating and filling out the
tables.
> But the setup for elaborate tests was often expensive, and tests
were just
> confirming that we had met some requirement to some degree.  That's
not a
> bad thing, but it's not looking for important problems, either.
Like unit
> tests, Fitnesse is a useful way for developers to assert that the
product
> does /at least these things/, and it sometimes can detect poor
refactoring.
> That didn't happen very often in our case, since our developers unit
tested
> pretty well and were pretty careful.  As Joe Rainsberger nicely put
it, when
> the Fitnesse tests pass, it doesn't mean that you're done; it means that
> it's time to get the testers to really kick the snot out of it.
>
> So:  as a descriptive and confirmatory tool for low- to mid-level
functional
> tests, Fitnesse had some strong points.  As an investigative tool
and for
> higher-level stuff, my experience was that it was fairly weak.  But
that's
> okay; that's why we need a variety of tools, and that's why we need to
> explore.  I'd like to work on a greenfield project where Fitnesse
was used
> more extensively for the first purpose.
>
> I mostly liked the FIT book, but I didn't like the one-dimensional
> characters that are used to exposit some of the development work.
This is a
> problem for me with a certain kind of writing style:  "Andy came into my
> office and slumped into my spare chair.  'What's wrong, Andy?' I
asked.  'I
> don't know,' he replied.  'Sometimes I feel like I'm just a cheap
literary
> device.'"  And yes, I've done it too, but I try to avoid it.)
>
> ---Michael B.
>
> ________________________________
>
> From: agile-testing@yahoogroups.com
[mailto:agile-testing@yahoogroups.com]
> On Behalf Of michelle@...
> Sent: September 5, 2007 9:09 AM
> To: agile-testing@yahoogroups.com
> Subject: Re: [agile-testing] Fit for agile?
>
>
>
> Sorry my brain wasn't working here's the book link:
>
> http://www.amazon.com/exec/obidos/tg/detail/-/0321269349/qid=1120782273/
>
<http://www.amazon.com/exec/obidos/tg/detail/-/0321269349/qid=1120782273/>

>
> > Hi all,
> >
> > I'm new to Agile and we're considering using Fit. I wanted to
solicit both
> > good and bad feedback. I've found some good sites and the
following book
> > but wondered what everyone thought of it. We're creating a Java
> > application that is not (at least starting out) web based.
> >
> > Thanks for the insight.
> >
> > Michelle
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>