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

4864RE: [XP] Role of QA

Expand Messages
  • Bill Caputo
    May 2, 2000
      > Thanks, Bill.

      Sure, I am just trying to understand this too, and I think you bring formidable arguments to the table. OTOH I have seen
      them answered here to my satisfaction before, so I am trying to explain my insights to you. Thanks for the feedback! :)

      > I don't consider myself to know everything, and you certainly don't sound
      > like a newbie. I don't want to come off as "old school" or controlling...
      > I've just worked very hard to make sure that the software we develop is of
      > use and does what it's supposed to... and doesn't break too easily.

      I wasn't being sarcastic. I have about 2 years in as a full time programmer, and I am from non-traditional background
      (Philosphy!!) I have worked hard to fill in the blanks, and I had a good grounding (great H.S. Comp Sci Dept), but I
      won't pretend to be an authority. But, I *have* been successful these past 2 years, and I spend a *Lot* of time with
      these types of issues, and with programming in general. So I spout off from time to time. If you want more Hubris, read

      > "Function tests" as I read them in XP take the developer's intent for design
      > and verify that the code does what it should. That's valuable, and a great
      > start.

      There has been a strong push for changing the term from Functional to Acceptance Tests, because of this very thing. I
      think the key here is that XP FT's do not represent the the developer's intent, but the customers.

      However, the role of QA *should* be a bit more comprehensive than
      > that. We have to consider not only the "expected" course of action (the
      > "happy path"), but variations from that. What could go wrong? What could a
      > user do wrong? What will cause the system to break? What is the effect of
      > multiple users on the system? At what load does the system fail? Are all
      > of the business questions satisfied by the design? Particularly if there
      > are multiple developers or multiple development teams working on a large
      > project - did they step on each other's toes, and does a new process "break"
      > an existing one?

      Some of these would qualify as user stories, IMHO. If the customer feels that load limits, and other such are valuable,
      then they will move them up the list. No one here, I think is expecting them to discover the need themselves, and as
      stated here before, some encouragement is to be expected, but in the end, *they* choose what goes in and what doesn't.

      > Also, client "stories" and even use cases provide answers to everything that
      > the client/business analyst/whoever has thought out... but what did they
      > miss?

      If the customer is part of the team, this missage will be noticed immediately, then the User Story/Iteration/Refactoring
      triumverate will make this manageable too.

      > What questions about a system weren't answered up front?

      None, but the most immediate, and valuable/risky.

      I am going to summarize from here, because others (see the archives) have addressed most of this better than I can, but
      let me just say that it seems that the more experienced/entrenched people have been the biggest skeptics. Now it could
      be argued, and may very well be, that this is because you all know more than us who have not been involved in real
      Process much, but maybe too its because of the investment that you feel you may lose (you made allusions to this in the
      part I snipped). All I can say to that is that its the results that matter. If heavy weight methods work, keep using
      them, if not, this one seems easy to implement, and Kent Beck et. al. seem to have a lot of experience with this stuff.

      As for Project Managers, Analysts, QA people, Architects, Data Designers, etc. They have a very real place in an XP
      shop--they just might have to come down into the trenches more. Or, they may act as consultants to the team. Personally,
      I like Architecture, and Data Design, and think I would be good at those jobs, XP says I won't get those titles, but if
      I get to do the work, what difference does it make?

      Finally, the strength of XP is in its flexibility. No one here, (or anywhere) can or should (or is?) trying to tell you
      what you must and must not do. They are simply stating that taken together, the XP practices lead to a successful,
      lightweight, comprehensive process that covers the concerns you mention, and that these other, heavier structures are
      meant to address.

      I will finish with something that has echoed across this list since I joined it. Take the time to learn, and then try
      *all* of XP before you dismiss it as *impossible*, maybe its just what the doctor ordered. If not, or you run into
      problems, then posting here is a great way to find out if its the process, your (my) lack of understanding, or other
      factors that are causing the problem.

      Remember the only reason to have an explicit methodolgy is that you have one regardless, and having one is supposed to
      improve the chances of success over the default one. If it doesn't ditch it.

    • Show all 20 messages in this topic