Loading ...
Sorry, an error occurred while loading the content.
 

Re: How to plan Acceptance Test implementation (coding)?

Expand Messages
  • Oliver Kamps
    ... I m not quite sure that there s room for not my problem in the kind of relationships between customers and development that I m shooting for... ... In XP
    Message 1 of 7 , Jan 31, 2001
      --- In extremeprogramming@y..., Robert Sartin <sartin@a...> wrote:
      >
      > Since acceptance tests are the responsibility of the XP Customer,
      > that's not my problem.
      I'm not quite sure that there's room for "not my problem" in the kind
      of relationships between customers and development that I'm shooting
      for...

      > It's not something I need to address in my
      > iteration plan or release plan because it doesn't use development
      > resources. The stuff I've read on XP (my wife stole my copy of
      > Planning Extreme Programming before I finished it, maybe it's in
      > there) is mostly silent on this topic other than "acceptance tests
      > are critical" and "customer is responsible for acceptance tests".

      In XP explained, Kent states that "Customers write tests", but he
      also acknowledges that "Customers typically can't write functional
      tests by themselves." They need somebody to help implement/automate
      the tests according to the Customer's specification and build tools
      so they can specify or implement tests more directly in the
      future. "That's why an XP team of any size carries at least one
      dedicated tester."

      In XP installed, Customers have the responsibility of "specifying
      acceptance tests", but the "specific choice [of how acceptance tests
      are automated/implemented] is up to your programmers".

      > Perhaps it would be an interesting idea for the customer to write
      > the tests using some form of "XP Lite" (leaving out at least the
      > Acceptance Tests to avoid nasty recursion).

      > Anoter possible variation is that the developers write the
      > acceptance tests. This is dangerous because these are the same
      > developers (with the same assumptions) who are writing the code. I
      > really like having an independent group own the acceptance.

      I agree with your point (the dangerous bit), at least to some degree.
      However, I think that the production code and the acceptance tests
      are written from different perspectives. While code is implemented
      and unit-tested task by task, the acceptance tests are written to
      test whole stories. The quality of the acceptance tests depends very
      much on the specification on the customer. I assume that the
      acceptance test specification will be both more detailed and more
      concrete than the story description itself; I assume an acceptance
      test case to test a story by running a specific example through it.
      Input and output data will have to be specified by the customer.

      Also, having a dedicated tester might help to take care of this
      concern. For functionally complex systems, writing acceptance tests
      for a couple of iterations might also be a good way for new people to
      learn functionality.

      Thanks for your input.
      Regards,

      Oliver
    Your message has been successfully submitted and would be delivered to recipients shortly.