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

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

Expand Messages
  • Rob Park
    A couple of keys for me on this topic are 1) no story is done unless it passes its acceptance tests (QA tests) and 2) strive for a very high level of
    Message 1 of 31 , Dec 2, 2005
      A couple of keys for me on this topic are 1) no story is done unless it
      passes its acceptance tests (QA tests) and 2) strive for a very high level
      of automation of tests.

      It depends on the skillset of your QA staff as to how much of this they do
      themselves, but it doesn't matter so much who does what. QA is in effect
      the customer advocate, which of course depends too on how available the
      actual customer is.

      QA can provide an excellent pair (or a 3rd wheel) and again depending on
      who's writing your Fit test fixtures (or other automation), this will get QA
      the required information to know what the coverage is, clarify assumptions
      in the stories, and get additional stories in before the next planning game
      (bugs or holes).

      I definitely consider a "release to qa" a stumbling block. Perhaps a
      necessary one, which to me really depends on your coverage. The more your
      testing is automated and the more your testing is done concurrently with
      developing new stories, the tighter the feedback loop and the truer the
      release plan. However if your coverage isn't so good or if your relatively
      dependent on a "release to qa", then you should still figure out how to
      accomplish that, but it will absolutely slow you down... not mention mess
      with the development rhythm (and not in a good way). Seems to me the real
      judge is how many new stories do you find that would hold up the release
      when you "release to qa".

      .rob.

      >From: Denis Haskin <Denis@...>
      >Reply-To: extremeprogramming@yahoogroups.com
      >To: extremeprogramming@yahoogroups.com
      >Subject: [XP] Struggling with how to fit QA in
      >Date: Wed, 30 Nov 2005 08:42:51 -0500
      >
      >Moving toward more incremental and iterative development, one of the
      >things that keeeps coming up is how to fit QA in.
      >
      >Our tester is most assuredly a full-fledged member of the development
      >team, but as we try to plan each iteration (we're only starting the 2nd)
      >the team still has this concept of making a 'release' to QA. I think
      >that's the stumbling block.
      >
      >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.
      >
      >It seems maybe the right thing is for QA to be testing on builds from
      >HEAD all the way through the iteration, and that maybe there's a little
      >slop of testing iteration n-1 into iteration n, but for the most part
      >the team will be working on the same iteration at the same time.
      >
      >[The challenge here is that the developers haven't really glommed onto
      >the idea of user stories which satisfy INVEST, so I get comments like
      >"well, we need a 6-week iteration because we're going to do a lot of
      >infrastructure work during that iteration... there won't be much for the
      >user to see" (but that's a separate post <grin>).]
      >
      >Thoughts? Suggestions?
      >
      >Thanks,
      >
      >dwh
      >
      >
      >
      >To Post a message, send it to: extremeprogramming@...
      >
      >To Unsubscribe, send a blank message to:
      >extremeprogramming-unsubscribe@...
      >
      >ad-free courtesy of objectmentor.com
      >Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
    • 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
        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.