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

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

Expand Messages
  • Dominic Williams
    Hi Denis, ... Great. I m puzzled about how developers still exhibit push to QA behaviour... Can you tell us a story or two about that? What do they do or
    Message 1 of 31 , Dec 1, 2005
      Hi Denis,

      >> What sort of work does the tester do? Does he or she
      >> participate in defining user stories? Are there any
      >> automated acceptance tests, and who designs them?
      >
      > Defining user stories: yes (to the extent we're
      > moving in that direction)
      > Writing acceptane tests: yes
      > Automating acceptance tests: yes

      Great. I'm puzzled about how developers still exhibit
      "push to QA" behaviour... Can you tell us a story or
      two about that? What do they do or say?

      Here's another tack:

      - are developers responsible for a task or a story?
      - when do they consider stories finished?

      Regards,

      Dominic Williams
      http://www.dominicwilliams.net

      ----
    • 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.