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

4847RE: [XP] Role of QA

Expand Messages
  • Merk, John
    May 2, 2000
    • 0 Attachment
      It's disconcerting that the concepts of testing are so foreign to many
      developers, myself included. To help introduce testing into the development
      process we've set aside an open work area into which we're going to move 4
      developers and 2 QA. Sounds a bit like the premise of a show on MTV...
      Anyway, the idea is to have the QA people pair with the developers when
      we're writing unit tests. Also, they will be working on the functional
      testing. I'll post our experiences from time to time. I'd like to hear
      from other folks who have tried something similar.

      John
      john.merk@...
      -----Original Message-----
      From: Malte Kroeger [mailto:kroeger@...]
      Sent: Tuesday, May 02, 2000 5:22 AM
      To: extremeprogramming@egroups.com
      Subject: Re: [XP] Role of QA


      What XP sais (as I understand it):

      XP doesn't officially have a QA-Team. In XP the developers do all the
      tests. They write their own unit tests, of course, and they support the
      customer in working out the functional tests.

      The question is: Is this a good way to do it? Is this enough testing?

      In many development teams now there is a lot less testing than this, so
      doing it the XP way would be an advantage already.

      What people most often object is: How can programmers write tests for
      their own code? They will not find any bugs!
      I think this is leveraged by the customers who specify the functional
      tests, but the concern is justified.
      The effect is also leaveraged by collective code ownership and pair
      programming, since there are several developers writing tests for
      everyones code.

      As I see it, XP is a lightweigt process with a somewhat minimalistic
      approach. But it's also flexible, so if you notice, that it's not
      sufficient, then add the parts you need. But like with all changes to your
      development process, you should keep track of the effects and if the
      change was really worth it.

      For me it's quite possible to have a 'seperate' QA-Team that develops the
      functional tests from the customer specifications.

      But what I think is most important about a QA-Team is, that it stays in
      very close contact with the develpment team. This is often not the case.

      QA-Team members often know much better what to test. What problems usually
      occur. How the tests should look like to find the most likely bugs. etc.
      With this knowledge they need to support the developers and they need to
      be transfered this knowledge to the developers.

      What is really needed is, that QA-Team members pair with developers for
      writing tests. That they review the tests done so far. That they make
      suggestions on how to improve the tests and do the improvements pairing
      with developers.

      In big systems it might be helpfull to have some people of the QA-Team do
      some adhoc-manual testing of the integrated system as well, since not all
      the tests can be fully automated in a resonable amount of time.

      So from my point of view the QA-Team should do less testing themselves,
      but should give more support to the developers in doing the tests and in
      developing a high quality product in the first place.

      So it's more of a QA-Coaching role.

      just my two cents...

      Malte



      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...

      Ad-free courtesy of objectmentor.com
    • Show all 20 messages in this topic