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

Re: [scrumdevelopment] SCRUM and QA testing (sanity, aggression, regression and performance testing)

Expand Messages
  • Faisal Javeed
    Thanks a bunch for the reply. I got sick so couldnt reply back :(. Now the product we our developing is related to Industrial Automation and is basically a
    Message 1 of 5 , Nov 21, 2008
    • 0 Attachment
      Thanks a bunch for the reply. I got sick so couldnt reply back :(.

      Now the product we our developing is related to Industrial Automation and is basically a plant control / automation software which is supposed to run on the plant 24 hours a day without a down time of even a second. It has a client server architecture and the client is web based. Due to the criticality of the environment in which is has to run we have to do Extensive testing that covers all aspects of the products.
      For this reason other than all the aggression and regression testing there are 2 long term test in which the product must run in plant environment for 30 days continously without any major issues before we can roll it out to the market.

      I gathered that we can make this a sprint as well in which the product runs for 30 days and any feedback from it will be incorporated in parallel shorter sprints say 5 to 6 days length. This sprint will be the last sprint of the project.


      As far as MS PROJECT or some other tool is concerned so this need is because the management including the CEO needs to know the delivery dates, when alpha, beta and commercial will be released. This requires the development and validation (QA) times to be taken care of and the final release date is published. Now any one sitting in some other office branch (geographically apart) can have a look at the schedule and see how things are going.

      > Some other questions I can think of:

      > - How big is your organization, and more importantly how big is the
      group that is considering moving the Scrum?.

      The development team is around 30 and QA size is around 12. As this is a single product we are working on, (we have commercalized it, now working on future enhancments) so i guess the whole of development team will have to move to SCRUM.

      > - Why do you want to use Scrum? What would you call you current
      development approach? (chaotic, waterfall, RUP, etc).

      Well its more close to spiral.


      > - How are projects currently structured?

      As i said that it is a product, it is commercalized and now we are working on further versions called service builds. At a time one to 2 service builds can be in progress, also there is a hardware drivers suite and at a time one driver development may also be in progress.


      > - What support is there from upper-management for this change?

      Currently management has asked to checkout SCRUM and see if we can improve quality and time with its use, so right now we were exploring it to see if it can fit it.


      > - Do you currently have anyone in your project management with Scrum
      experience or with Scrum training?

      No, we do not have anyone with SCRUM experience or training.






      "Oliver Seiler" <oseiler@...>
      Sent by: scrumdevelopment@yahoogroups.com

      11/18/2008 12:55 AM

      Please respond to
      scrumdevelopment@yahoogroups.com

      To
      scrumdevelopment@yahoogroups.com
      cc
      Subject
      Re: [scrumdevelopment] SCRUM and QA testing (sanity, aggression, regression and performance testing)






      Scrum doesn't really talk about QA or testers as a separate group, so
      that will be something you'll have to come to terms with in your
      organization; expect difficulty.

      Having said that, on to specifics:

      On Sun, Nov 16, 2008 at 8:34 PM, lazers378 <
      faisal.javeed@...> wrote:

      > [...]
      > Currently we have separate QA
      > department and every release we ship must pass through the following
      > tests, sanity, regression testing, aggression testing, laod /
      > scalability testing, Performance testing and a long term test in
      > which the product must run for 30 days without any issues.

      What are you expecting to set as your sprint length? 30 days is a long
      time to get feedback on whether new defects have been introduced, so
      is it possible to have shorter, more frequent runs going concurrently
      with these long term tests, so that you can get feedback within an
      individual sprint? Say on the 1-2 day level...

      If you can do that, you could make passing these shorter tests part of
      your definition of what being "done-done" a story means.

      > 1.In the scrum the team is cross-functional and the developer is
      > also performing the testing as well, in this case can we be
      > confident about the test results because the developer has a
      > different mind set as compared to a QA tester and hence both will
      > have different result in verification and validation. So how can we
      > manage this issue?

      Scrum doesn't really define development processes, so it doesn't
      really say *anything* about what the developers are doing to ensure
      quality. That said, this comes back to what the product owner has
      determined the acceptance criteria for a story are, plus whatever the
      team itself has to say about what it means for a story to be
      "done-done". Since you can't test quality into a product, it is really
      up to the Scrum team to be using development practices that ensure the
      quality of the produced software, which may include unit-tests,
      automated acceptance tests, etc; that's up to the team, though.

      > 2. Since it is an incremental model so its means when we move
      > to say sprint 3 we are saying that all the features &
      > functionalities of sprint 2 and sprint 1 are included in it and any
      > other issues associated with previous sprints has been already
      > resolved OR put forward for next sprint. So what about the
      > integration testing, suppose any feature of previous sprint(s) is
      > not working now. In this sprint all the testing related to the
      > features of previous sprints will have to be done again? Meaning
      > increase in testing time as we move from sprint to sprint, forward.
      > How to ensure no ripple bugs?.

      Automated regression testing is the most obvious, at whatever levels
      you can manage (unit-tests, components, system, acceptance, etc).
      Running through an ever-growing set of acceptance tests manually,
      while it is possible, and is probably great job security, doesn't
      scale very well, and deadens the soul...

      But again, not something defined in Scrum; look at XP and TDD for
      development practices that might help.

      > 3. What about the RnD, domain understanding, any competitor
      > product study for understanding (RnD). Where the time of these will
      > fit ?. It will be done before the sprint or during the sprint?

      Hopefully your product owner has a clear understanding of the market,
      the role of your product in it, a road-map, strategic plan, etc,
      either directly or indirectly by delegating some of this stuff.
      Without this, you're probably not going to make good decisions when
      they are needed. This sort of thing is part of product owner role, and
      isn't limited by the sprints; the sprints are simply the way the work
      to be done (the backlog) is processed in some sensible way (hopefully
      by value delivered to paying customers).

      > 4. In case we are not using any scheduling tools like MS
      > project and Pert Chart or Gant charts then as the project get
      > complex how to schedule and track things?

      Now it sounds like you don't have a clear understanding of Scrum as a
      process. Backlog feeds estimated work (stories) into sprints
      (committed to and broken down into tasks at sprint planning), which is
      worked on by the scrum team and completed within the sprint (if all
      goes well). The backlog is where the planning takes place; you might
      have a release plan (driven by business decisions), the prioritization
      of stories in the backlog might be based on a variety of things
      (business value, a release "theme", trade-show dates, etc), but that
      is outside of the Scrum process itself. Could you come up with some
      examples where you might want to use more traditional
      project-management artifacts?

      > In case we are in the
      > maintenance phase how to manage things like team changes then how
      we
      > can track all these things happened in the past? Just by excel??.

      Not sure what you mean by this. Maintenance can be handled in the same
      way, just the backlog might have fewer feature requests and more bugs
      fixes, or perhaps the other way around depending on the software; you
      might not have enough work for a single team for a single product.
      What do you mean by "how we can track all these things happened in the
      past?"; what exactly do you feel you need to track?

      > How will we estimate the final delivery date of the complete
      > Project / Product. ?.

      Many ways exist: burn-down charts, burn-up charts; typically a chart
      that tracks the work to be done (stories) against time, factoring in
      the team velocity. This can typically done by hand, but whatever is
      most convenient I guess.

      > 5. Similarly like point 5, how to depict tasks interdependency,
      > I know if i am using MS project then there are dependency diagrams
      > etc How to manage similar things using SCRUM.

      If it is at the level of tasks, then presumably its happening within
      the sprint and these interdependencies were already accounted for in
      sprint planning. Or do you mean interdependencies between stories? One
      can estimate stories as if there were no interdependencies. One could
      also estimate stories assuming parent stories have been completed. Or
      both. In the latter case, the dependency should be tracked with the
      child story so that the product owner doesn't put the child before the
      parent; this makes prioritization more onerous. Personally I prefer
      trying not to add dependencies between stories. If this means that the
      size of story is bigger than it otherwise would be, then so be it; at
      least the can be prioritized independently.

      If you are thinking that you'll need a tool like MS Project for Scrum,
      then either you don't quite understand the point of Scrum, or maybe
      you need to provide such documentation for organizational reasons
      (budgeting, accounting, whatever). Either way, you shouldn't need to
      be using such tools to actually use Scrum effectively; in fact, they
      will either get in the way or change how you implement Scrum such that
      it becomes less effective, or perhaps even counter-productive.

      Some other questions I can think of:
      - How big is your organization, and more importantly how big is the
      group that is considering moving the Scrum?
      - Why do you want to use Scrum? What would you call you current
      development approach? (chaotic, waterfall, RUP, etc).
      - How are projects currently structured?
      - What support is there from upper-management for this change?
      - Do you currently have anyone in your project management with Scrum
      experience or with Scrum training?

      Obviously some of the answers could be considered private, but the
      answers should be considered in your approach.

      Sorry for the long-winded response. I can't claim to be an expert at
      any of this. My own organization, though trying to use Scrum, is far
      behind on actually doing everything, and even some of the most
      important things, and can't really call what it does "Scrum". Maybe
      someone else will chime in, contradict me, and add to your confusion.


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