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

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

Expand Messages
  • Ron Jeffries
    ... Well, Meade, I notice that you didn t ask a question, so let me ask one instead. Wouldn t things go faster if you just had the developers ship releasable
    Message 1 of 31 , Nov 30, 2005
    • 0 Attachment
      On Wednesday, November 30, 2005, at 9:10:35 AM, MeadeR_NJ wrote:

      > In groups I managed I've always had a 'release to QA' - this is
      > especially important when the system is in some level of production
      > (people are actually using it). The 'release to QA' ensures that
      > there are no significant issues with the release. If there are issues
      > you need to decide to let them into production, skip the release,
      > correct prior to production or include in the n+1 release (or some
      > combination).

      Well, Meade, I notice that you didn't ask a question, so let me ask
      one instead.

      Wouldn't things go faster if you just had the developers ship
      releasable code? Then you could skip that whole QA phase, and you
      wouldn't have to worry about their time testing things every day. Or
      any day.

      Ha ha, only serious. I know that sounds like a really dumb idea, and
      maybe you'll never get rid of QA. But let's think about what would
      have to happen if the developers committed, to you or to themselves,
      that QA should never again find an error.

      They might develop better coding standards; they might do code
      inspections; they might even do pair programming. But they still
      wouldn't be sure. So they'd have to do one more thing: they'd have
      to test the code before giving it to QA.

      Because they have to do their releases quickly, though, development
      would figure out ways to test the code with automated tests rather
      than manual, and they'd have to figure out ways to make the tests
      run quickly enough.

      Even that wouldn't be enough, at least at first. So every time a bug
      came back from QA, the developers would look at it, write a test to
      show that it was a bug, fix the bug, run the test to show that the
      bug was gone. And they would reflect, each time this happened, on
      what they had just learned about testing.

      After a while, QA might get so lonely that they'd come over and play
      with us. That would be nice.

      Ron Jeffries
      www.XProgramming.com
      Assume that anything you didn't like was the funny stuff.
      -- Jim Shore
    • 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.