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

Re: [XP] How do you handle defect resolution?

Expand Messages
  • George Dinwiddie
    ... Mike, leaving aside the question of regression test automation, it sounds like you may doing the QA testing post iteration. On teams I ve worked with,
    Message 1 of 18 , Jan 2, 2009
    • 0 Attachment
      Mike Coon wrote:
      > In our sprints I have a QA person manually testing bits of functionality as
      > they are delivered; This generates defects as we go and we've been adding a
      > task to the Sprint backlog for each defect. I'm not completely satisfied
      > with this approach, so I am asking what other, more experienced folks are
      > doing with defects.

      Mike, leaving aside the question of regression test automation, it
      sounds like you may doing the QA testing post iteration. On teams I've
      worked with, even when the test automation was weak, having the stories
      tested within the iteration has proved to be a big help. When a defect
      is found, it's just fixed--not added to the backlog. The story isn't
      done until the testers (and the PO) are satisfied with it.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • Mike Coon
      Ron, We are not doing XP though some folks use some practices. We do have a customer; after thinking about my situation here and considering many of the great
      Message 2 of 18 , Jan 5, 2009
      • 0 Attachment
        Ron,

        We are not doing XP though some folks use some practices. We do have a
        customer; after thinking about my situation here and considering many of the
        great responses I plan to focus more on the Product Owner and product
        backlog for the next quarter.

        As far as ignoring crappy defects - we tried that, and the consultant
        working for the dev director punished us with unending meetings and
        complaints - now we are bouncing them immediately asking for the steps,
        expected and actual results. This still yeilds complaints but immunizes my
        folks from much criticism as it's hard to actually say that you want us to
        waste time figuring out what you were trying to do and what you thought
        would happen.

        Lines of power - I am still doing agile adoption as a side gig to my day job
        of QA manager. The good news is that i have more influence every day and
        can usually get my way. The bad news is that I can usually get my way - so
        it helps to be right :-) While I am in my thirtieth year of IT work I'm
        still learning just like everybody...

        Thanks for the responses.

        Mike

        On Fri, Jan 2, 2009 at 5:06 PM, Ron Jeffries
        <ronjeffries@...>wrote:

        > Hello, Mike. On Friday, January 2, 2009, at 1:50:03 PM, you wrote:
        >
        > > One thing that happens now is we get defects from UAT folks that have not
        > > gotten used to the idea that their defect should include steps, expected,
        > > and actual results. So we spend a lot of time figuring out what they are
        > > reporting which often turns out to be a feature request, training issue,
        > or
        > > user configuration setting - all of which do need to be identified and
        > > resolved but currently take too long to understand, categorize, and
        > address.
        >
        > Are you doing XP? Do you have a customer? What happens if you simply
        > ignore alleged defects without info? What are the lines of power on
        > the project?
        >
        > Ron Jeffries
        > www.XProgramming.com
        > www.xprogramming.com/blog
        > Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
        > of his head. It is, as far as he knows, the only way of coming downstairs,
        > but sometimes he feels that there really is another way, if only he could
        > stop bumping for a moment and think of it. And then he feels that perhaps
        > there isn't. -- A. A. Milne
        >
        >
        >



        --
        http://mikeonitstuff.net/ New Blog
        http://mikeonitstuff.com/ Old Blog
        http://mikeonbikes.blogspot.com/


        [Non-text portions of this message have been removed]
      • Chet Hendrickson
        Hello Mike, The first step in an XP style defect resolution process is the creation of concrete acceptance criteria. What Brian Marick calls Examples. These
        Message 3 of 18 , Jan 5, 2009
        • 0 Attachment
          Hello Mike,

          The first step in an XP style defect resolution process is the creation of concrete acceptance criteria. What Brian Marick calls Examples. These must belong to the project's Customer, although exactly who creates them is subject to the skills and temperaments of those on the team.
          In any case, the developers working on a feature need to have unambiguous guidelines as to how the system will behave once the new feature is added. This works best if they are available early in the development of the feature, but must be in hand before the developers declare the feature done.

          Tools like FitNesse are often used for this purpose. We mostly use the one we hate the least at any given moment.

          Once the examples exists, any developer who does not make use of them is opening themselves to great ridicule. This goes a long way towards eliminating the 'I thought it was supposed to do this' sort of defect.

          This process is not perfect. Often the Customer will come back with 'Yes, that is was I asked for, but this is really what I want'. That case is resolved by the addition of a new sort and its corresponding set of examples.

          chet

          Monday, January 5, 2009, 8:08:46 AM, you wrote:


          Ron,

          We are not doing XP though some folks use some practices. We do have a
          customer; after thinking about my situation here and considering many of the
          great responses I plan to focus more on the Product Owner and product
          backlog for the next quarter.

          As far as ignoring crappy defects - we tried that, and the consultant
          working for the dev director punished us with unending meetings and
          complaints - now we are bouncing them immediately asking for the steps,
          expected and actual results. This still yeilds complaints but immunizes my
          folks from much criticism as it's hard to actually say that you want us to
          waste time figuring out what you were trying to do and what you thought
          would happen.

          Lines of power - I am still doing agile adoption as a side gig to my day job
          of QA manager. The good news is that i have more influence every day and
          can usually get my way. The bad news is that I can usually get my way - so
          it helps to be right :-) While I am in my thirtieth year of IT work I'm
          still learning just like everybody...

          Thanks for the responses.

          Mike

          On Fri, Jan 2, 2009 at 5:06 PM, Ron Jeffries
          <ronjeffries@...>wrote:

          > Hello, Mike. On Friday, January 2, 2009, at 1:50:03 PM, you wrote:
          >
          > > One thing that happens now is we get defects from UAT folks that have not
          > > gotten used to the idea that their defect should include steps, expected,
          > > and actual results. So we spend a lot of time figuring out what they are
          > > reporting which often turns out to be a feature request, training issue,
          > or
          > > user configuration setting - all of which do need to be identified and
          > > resolved but currently take too long to understand, categorize, and
          > address.
          >
          > Are you doing XP? Do you have a customer? What happens if you simply
          > ignore alleged defects without info? What are the lines of power on
          > the project?
          >
          > Ron Jeffries
          > www.XProgramming.com
          > www.xprogramming.com/blog
          > Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
          > of his head. It is, as far as he knows, the only way of coming downstairs,
          > but sometimes he feels that there really is another way, if only he could
          > stop bumping for a moment and think of it. And then he feels that perhaps
          > there isn't. -- A. A. Milne
          >
          >
          >

          --
          http://mikeonitstuff.net/ New Blog
          http://mikeonitstuff.com/ Old Blog
          http://mikeonbikes.blogspot.com/

          [Non-text portions of this message have been removed]







          --
          Best regards,
          Chet mailto:lists@...

          [Non-text portions of this message have been removed]
        • Tim Ottinger
          ... /me nods and weeps.
          Message 4 of 18 , Jan 6, 2009
          • 0 Attachment
            > From: Charlie Poole <charlie@...>
            > I have to share my own favorite funny/sad excuse for not
            > having acceptance tests...
            >
            > "We don't really know what's wanted, so we can't write a test"
            >
            > This was stated to me by a programmer who was busily writing
            > the code for the story he didn't understand.

            /me nods and weeps.
          Your message has been successfully submitted and would be delivered to recipients shortly.