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

RE: XP what makes a good XP Test Plan?

Expand Messages
  • Travis Fremming
    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
    Message 1 of 6 , Dec 1 10:07 AM
      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
    • 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 2 of 6 , Dec 1 10:40 AM
        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 3 of 6 , Dec 1 10:45 AM
          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 4 of 6 , Dec 1 12:06 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? 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 5 of 6 , Dec 1 1:30 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? 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 6 of 6 , Dec 2 12:31 AM
                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.