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

Re: [XP] Re: Struggling with how to fit QA in

Expand Messages
  • Michael Feathers
    ... The best thing is to try to get everything to happen in one iteration: http://blogs.objectmentor.com/ArticleS.MichaelFeathers.IterationSlop Michael
    Message 1 of 31 , Dec 3, 2005
    • 0 Attachment
      villemurevillemure wrote:

      >>The issue is... if the 'release' to QA is at the end of the iteration,
      >>then she is testing the n-1 iteration while the developers are working
      >>on the nth iteration, and bugs she finds won't get scheduled in until
      >>the n+1 iteration. That seems to me to break the feedback loop pretty
      >>badly.
      >>
      >>
      >>
      >
      >To take care of that, you put in place a SWATT team. This way, you
      >still have new stories being implemented, and your SWATT team keeps
      >the feedback loop a live with the QA team.
      >
      >http://www.martinfowler.com/articles/planningXpIteration.html
      >
      >
      >
      The best thing is to try to get everything to happen in one iteration:
      http://blogs.objectmentor.com/ArticleS.MichaelFeathers.IterationSlop



      Michael Feathers
      author, Working Effectively with Legacy Code (Prentice Hall 2005)
      www.objectmentor.com
    • Steven Gordon
      On the other hand, if you are in an organization where the real customer can only use a new feature in production after a long, tedious, bureaucratic
      Message 31 of 31 , Dec 5, 2005
      • 0 Attachment
        On the other hand, if you are in an organization where the real customer can
        only use a new feature in production after a long, tedious, bureaucratic
        deployment process, then the QA delay probably has no affect on value flow
        except in the last iteration of a release.

        In such a case, Kent's argument needs to be applied to the deployment
        process before being applied to the QA process. The argument for
        leaning/integrating the QA process then comes down to shortening feedback
        loops instead of value flows.

        Steven Gordon

        On 12/5/05, Kent Beck <kentb@...> wrote:
        >
        > Denis,
        >
        > I wonder if the programmers' perspectives would change if you worked
        > backwards from "real customer successfully uses new feature" instead of
        > forwards from "programmer writes line of code". I use a process called
        > value
        > stream mapping borrowed from lean manufacturing to visualize such
        > situations. What are all the activities that take time before the real
        > customer successfully uses a new features, and what are the points in the
        > process where the code is simply waiting? You can draw the current picture
        > and then draw a desired future picture. From the example below, I would
        > have
        > a box labelled "programmer writes code" followed by a wait of up to an
        > iteration followed by "tester tries code, reports defect" followed by some
        > wait time followed by "programmer fixes code" followed by more waiting
        > followed by "tester verifies fix" followed by a bunch more waiting (the
        > rest
        > of the release) followed by "real customer successfully uses new feature".
        > From there you can figure out for yourselves if that is the picture you
        > want
        > or if it would be more efficient to somehow bring the tester into the
        > iteration (for example, by writing story tests in advance). Maybe testing
        > N-1 is so much better than waiting and testing a whole release at once
        > that
        > the current situation is fine for everyone but you.
        >
        > Sincerely yours,
        >
        > Kent Beck
        > Three Rivers Institute
        >


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.