A tool like Fit/Fitnesse ( http://fitnesse.org/
) offers the following
way to break things down:
- The tests themselves are just tables that specify sequences of
actions and expected results
- Test Fixtures execute those tabular tests against the system being tested
In this way the tests themselves can be specified by the customer as
tables. This means not only can the tests be defined before the system
interfaces are designed, but also customers can define tests without
having to know technical details about the system.
The test fixture to make any test table actually execute can be built
by developers or testers immediately after the requisite system
interfaces have been defined.
On 10/24/05, lawriegallardo <lawriegallardo@...> wrote:
> I am trying to get a handle on how testers and developers work
> together during a Sprint, and at what stage during a Sprint automated
> acceptance tests should be created.
> In the <a
> Practices in Scrum Project Management and XP Agile Software
> Development"</a> white paper, the authors write "Now the test teams
> are at the front of the process writing the tests that the programmers
> make work. The teams are defining their Sprints in terms of automated
> tests rather than written requirements."
> Is this suggesting that testers produce textual acceptance tests
> together with the Product Owner (or Business Analyst or Customer
> Rep?), and that the testers then sit down with the developers to turn
> these into automated (code) acceptance tests which, finally, the
> developers use to write their unit tests and code?
> But this puzzles me... How can you write complete automated acceptance
> tests before you know the interfaces into the system, database design,
> And what would the developers be doing at the start of a Sprint whilst
> they are waiting for the testers to write the textual acceptance tests?
> I am a bit confused around these areas, so any advice would be very