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

QA pileup

Expand Messages
  • entretriens
    Hello Scrum Group, For QA, I wonder if anyone had any recommendations for handling final QA (just prior to UAT) for large scale projects with many
    Message 1 of 3 , Dec 1, 2006
    • 0 Attachment
      Hello Scrum Group,
      For QA, I wonder if anyone had any recommendations for handling final
      QA (just prior to UAT) for large scale projects with many
      interdependencies? Developers use TDD and cruise control for unit
      testing, QA people are involved from the beginning of the iteration to
      oversee/advise test writing (this helps immensely), but the challenge
      comes in the end when we do the full integration tests.

      I tried to think of ways to stagger the effort, but all the code has
      to be tested together at one time, which leads to that typical QA rush
      at the end.

      It's not that bad as the number and degree of breaks are few, but the
      QA test process is lenghty in itself. Is there something obvious that
      I don't see. Much appreciation for any advice or reference to noteable
      resources.
    • dnicolet99
      One thing I ve seen some teams do is to allow time for the final QA in the project plan, possibly by devoting a whole sprint to it if that s what it takes.
      Message 2 of 3 , Dec 6, 2006
      • 0 Attachment
        One thing I've seen some teams do is to allow time for the final QA in
        the project plan, possibly by devoting a whole sprint to it if that's
        what it takes.

        Another thing that might help is for the QA people on the project to
        get their testing infrastructure all set up in advance. They don't
        need all the code to be finnished before they can do that. It's things
        like creating test data (can be based on requirements, not necessarily
        dependent on finished code), configuring servers, defining
        system-level test procedures, writing scripts, etc. That might help
        them get started with testing as quickly as possible once the code is
        delivered.


        --- In scrumdevelopment@yahoogroups.com, "entretriens"
        <entretriens@...> wrote:
        >
        > Hello Scrum Group,
        > For QA, I wonder if anyone had any recommendations for handling final
        > QA (just prior to UAT) for large scale projects with many
        > interdependencies? Developers use TDD and cruise control for unit
        > testing, QA people are involved from the beginning of the iteration to
        > oversee/advise test writing (this helps immensely), but the challenge
        > comes in the end when we do the full integration tests.
        >
        > I tried to think of ways to stagger the effort, but all the code has
        > to be tested together at one time, which leads to that typical QA rush
        > at the end.
        >
        > It's not that bad as the number and degree of breaks are few, but the
        > QA test process is lenghty in itself. Is there something obvious that
        > I don't see. Much appreciation for any advice or reference to noteable
        > resources.
        >
      • Sarath Kummamuru
        Even with a complete testing infrastructure set up in advance, decent amount of automation and continuous integration in place, I have experienced that there
        Message 3 of 3 , Dec 6, 2006
        • 0 Attachment
          Even with a complete testing infrastructure set up in advance, decent amount of automation and continuous integration in place, I have experienced that there is not enough time for the QA to do a complete testing of the product that has been built over a few sprints.


          Although Scrum itself doesnot suggest it I believe that a Release Sprint or a few Release sprints can help during the final stages of the project.

          The release sprint can be a place where the QA can do final integration testing, testing on various platforms that the product is expected to be delivered, etc. But all this should have been some thing that has already been tested in various prior sprints. The presence of a Release sprint is no reason for the teams to work towards a partially completed story or not completely done story at the end of a sprint.

          Ideally we donot need this release sprint. But with some teams that i worked it helped to have a release sprint at the end.

          Having the release sprint is no reason for the team to compromise on quality of the stories or testability of stories at the end of each sprint. !!!!


          Sarath.

          On 12/6/06, dnicolet99 <dnicolet@...> wrote:

          One thing I've seen some teams do is to allow time for the final QA in
          the project plan, possibly by devoting a whole sprint to it if that's
          what it takes.

          Another thing that might help is for the QA people on the project to
          get their testing infrastructure all set up in advance. They don't
          need all the code to be finnished before they can do that. It's things
          like creating test data (can be based on requirements, not necessarily
          dependent on finished code), configuring servers, defining
          system-level test procedures, writing scripts, etc. That might help
          them get started with testing as quickly as possible once the code is
          delivered.

          --- In scrumdevelopment@yahoogroups.com, "entretriens"
          <entretriens@...> wrote:
          >
          > Hello Scrum Group,
          > For QA, I wonder if anyone had any recommendations for handling final
          > QA (just prior to UAT) for large scale projects with many
          > interdependencies? Developers use TDD and cruise control for unit
          > testing, QA people are involved from the beginning of the iteration to
          > oversee/advise test writing (this helps immensely), but the challenge
          > comes in the end when we do the full integration tests.
          >
          > I tried to think of ways to stagger the effort, but all the code has
          > to be tested together at one time, which leads to that typical QA rush
          > at the end.
          >
          > It's not that bad as the number and degree of breaks are few, but the
          > QA test process is lenghty in itself. Is there something obvious that
          > I don't see. Much appreciation for any advice or reference to noteable
          > resources.
          >


        Your message has been successfully submitted and would be delivered to recipients shortly.