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

Re: [XP] RE: XP what makes a good XP Test Plan?

Expand Messages
  • Ron Jeffries
    ... I d want to see the plan. It seems odd to have a generic plan that can be taken from place to place. I d think something a bit more specific would be more
    Message 1 of 6 , Dec 1, 2003
    • 0 Attachment
      On Monday, December 1, 2003, at 1:07:02 PM, Travis Fremming wrote:

      > I have a test plan I have been using for about a year now. I brought
      > it with me to a new job that uses XP. Some of the comments I have
      > gotten is that it is too long and is a waste of time to read. As
      > a "customer" I want to detail out what is being tested, how it is
      > being tested and why it is being tested.

      > Does anyone have any feedback on this?

      I'd want to see the plan. It seems odd to have a generic plan that can be
      taken from place to place. I'd think something a bit more specific would be
      more useful. In general, I think we don't need a plan, we need tests. And a
      test plan for XP needs to address the strongly iterative nature of the
      process.

      Anyway, I'd like to look at the document.

      Regards,

      Ron Jeffries
      www.XProgramming.com
      It's easier to act your way into a new way of thinking
      than to think your way into a new way of acting. --Millard Fuller
    • yahoogroups@jhrothjr.com
      From: Travis Fremming Sent: Monday, December 01, 2003 1:07 PM Subject: [XP] RE: XP what makes a good XP
      Message 2 of 6 , Dec 1, 2003
      • 0 Attachment
        From: "Travis Fremming"
        <t_fremming.at.yahoo.com@...>
        Sent: Monday, December 01, 2003 1:07 PM
        Subject: [XP] RE: XP what makes a good XP Test Plan?


        > I have a test plan I have been using for about a year now. I brought
        > it with me to a new job that uses XP. Some of the comments I have
        > gotten is that it is too long and is a waste of time to read. As
        > a "customer" I want to detail out what is being tested, how it is
        > being tested and why it is being tested.
        >
        > Does anyone have any feedback on this? Thanks, Travis

        XP takes the position that all tests should be executable,
        should be readable by the customer, the developers and
        the testers, and should be created before work begins on
        implementing the feature in question. It also says that
        all tests for a given story *must* pass before the iteration
        is complete.

        A classical test plan does not satisfy the first point: it's
        simply a piece of paper that's probably way out of date
        by now anyway. It also does not satisfy the last point:
        you never quite know whether the tests have been
        run (manually) or whether they're being run, and in
        many cases, they won't be run until long after the
        iteration is supposed to be complete.

        An XP project should have a suite of tests, variously
        called customer tests, acceptance tests or functional
        tests, that satisfies all three criteria, and that provides
        essentially complete coverage of all requirements from
        the customer viewpoint.

        If they've got it, learn how it works and get comfortable
        with it. If they don't have it at all, that's the *first* thing
        that needs to change, or else take the XP label off of
        the project. (I'm serious about that: probably as many
        "XP" projects have failed because of not doing customer
        testing as any other single cause - I think.)

        If they have it, but it's implemented in the standard
        unit test framework (some flavor of xUnit, like JUnit,)
        then it's mostly up to you whether you want to learn
        to read it to verify that each set does what you want,
        or whether you want to push for a framework like
        FIT/Fitnesse (fit.c2.com, www.fitnesse.com) that
        lets you look at tests (and test results) in a browser,
        and lets you create them using tools like Word and
        Excell, or using a specialized Wiki like FitNesse.
        The key point here is that *you*, as the customer,
        own the customer tests.

        Which brings me to the last point: what to do with
        the classical test plan. Mark it up by story and use
        it either as input to the planning game (for stories that
        have not yet been started) or to check that the existing
        stories in fact meet your criteria. Also check to see
        whether it deals with things that are properly the
        domain of the development team, and simply ditch
        those.

        Once you've done that, you may find some points
        that can't be covered that way; we generally call
        them "motherhood stories" because they deal with
        the application as a whole rather than individual
        features. They are such things as security,
        performance, and throughput. The latter two,
        especially, may need tools that don't fit into the
        FIT/FitNesse mould. Also, GUI tests can be
        very difficult unless the development team is using
        a GUI toolset that allows testing individual screens,
        and the application is structured correctly (full MVC
        with ultra-thin View layer.) You don't need to know
        what this means: either the developers will, or you need
        to get a senior developer/designer on the project ASAP.

        John Roth
      • J. B. Rainsberger
        ... A question: why do you want those things? What purpose do they serve? It seems that whoever is being asked to read it doesn t need to know what s in there,
        Message 3 of 6 , Dec 1, 2003
        • 0 Attachment
          Travis Fremming wrote:

          > I have a test plan I have been using for about a year now. I brought
          > it with me to a new job that uses XP. Some of the comments I have
          > gotten is that it is too long and is a waste of time to read. As
          > a "customer" I want to detail out what is being tested, how it is
          > being tested and why it is being tested.
          >
          > Does anyone have any feedback on this? Thanks, Travis

          A question: why do you want those things? What purpose do they serve? It
          seems that whoever is being asked to read it doesn't need to know what's
          in there, so would it be OK if you just carried it around in your head,
          for example?
          --
          J. B. Rainsberger,
          Diaspar Software Services
          http://www.diasparsoftware.com :: +1 416 791-8603
          Let's write software that people understand
        • Pierre Boudreau
          ... It seems to me that if you can carry a test plan from one job to another, it is not a plan, it is a methodology. XP is also a methodology and its testing
          Message 4 of 6 , Dec 1, 2003
          • 0 Attachment
            Travis Fremming wrote:

            > I have a test plan I have been using for about a year now. I brought
            > it with me to a new job that uses XP. Some of the comments I have
            > gotten is that it is too long and is a waste of time to read. As
            > a "customer" I want to detail out what is being tested, how it is
            > being tested and why it is being tested.
            >
            > Does anyone have any feedback on this? Thanks, Travis

            It seems to me that if you can carry a test plan from one job to another, it is not a plan, it is a methodology. XP is also a
            methodology and its testing practices are fairly well documented in various books and web sites. I am guessing that the people who
            read your plan already have a pretty good idea of how they want their application to be tested.

            Personally, the kind of test plan I would like to see on an XP project is:
            -a brief description of the unit testing framework that will be used and pointers on FAQ's on how to use it.
            -a brief description of how customer tests will be executed (home grown tool, off the shelf tool, other...)

            Then again, these things can easily be discussed verbally in a stand up meeting... The details about the unit testing framework are
            communicated through pair programming...

            As others have answered, I would also like to see your plan...
          • Amir Kolsky
            Travis, are you a tester? Developer? What is your role in the organization? Amir
            Message 5 of 6 , Dec 2, 2003
            • 0 Attachment
              Travis,
              are you a tester? Developer? What is your role in the organization?

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