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

4854RE: [XP] Role of QA

Expand Messages
  • Bill Caputo
    May 2, 2000
    • 0 Attachment
      Hi Peter,

      I am responding to this, because I am genuinely confused. I don't have 10 years experience in anything, so you can look
      at my questions as the naive newbie if you wish:

      > However, it seems
      > that unit and even functional tests, whoever performs them, don't
      > necessarily ensure that the developed product meets the client requirements.

      I am curious what *would* if these things don't? My understanding is that Unit & Functional Tests (specifically XP
      style) are written to cover the code (UT) and to cover the User Stories that the *customer* has selected (FT) so if this
      doesn't do get us to meeting client requirements, what will?

      > There are valid and essential roles for project management, quality
      > assurance, and product acceptance - and you'll be hard-pressed to find an
      > organization willing to toss those out the window because some developers
      > want to "go extreme."

      In the case of my company, we either don't have these at all, or they are broken. I agree that perhaps an organization
      that is delivering good code on time, and under budget won't desire change, but if they aren't (like us) then what is
      the reason for keeping all this baggage? If XP works, who cares what *tried and true* techniques go the way of the dodo?

      > Truthfully, do you as developers want to walk through and test every
      > business process (with every possible variation)

      >From Code Complete (Steve McConnell):
      A simple program that takes Name, Address, and Phone Number and stores them in a file:
      Every Possible Variation =
      Number 26^20 (20 chars each with 26 possibles)
      Address 26^20 (20 chars each with 26 possibles)
      Phone 10^10 (10 digits each with 10 possibles)

      Total 26^20 * 26^20 * 10^10 = 10^66

      Your QA department can do that???

      I guess my bottom line is this: If you can get the benefits that XP seems to offer (good quality, good estimates, good
      customer satisfaction, and good developer morale, etc.) without it, then why do it?

      If not, then maybe you should find out more about XP before you dismiss it. At my company, we are slowly, but surely
      adding Process to our development work. Since I came to this company, I have seen improved team work, a move toward
      standards, Unit Tests have *improved* my productivity, and many of the other XP practices seem well suited to solving
      other problems. If they won't, we will look elsewhere, but the fact is, XP is light-weight, low risk to try, and seems
      to solve the problems of poor development, so I am being open minded. If it flys in the face of what is established,
      fine by me since what's established (here at least) is broken. We need something, the flexibility of XP makes it

    • Show all 20 messages in this topic