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

Re: [scrumdevelopment] Re: Writing Unit, Integration and Automated tests during development

Expand Messages
  • Rodney Wynn
    Andy Do not worry about complete test code coverage in the legacy applications. Just insert the testing into the modlets that are changed /enhanced by the
    Message 1 of 7 , Mar 8, 2008

      Do not worry about complete test code coverage in the legacy applications.  Just insert the testing into the modlets that are changed /enhanced by the teams at that time.  You will find the longer the legacy application hang around the more coverage you will achieve during repairs and rework.
      Integration testing will simply have to applied during each production drop.  Not easy but less costly for the company and developers  (money for the company and time for the developers).

      It is just something you will have to note in the release documents until complete test coverage is achieved.


      andywadhwa <andywadhwa@...> wrote:
      Thanks everyone for your helpful responses so far. I would like to add
      that our development team does have a 'definition of done' which
      includes a requirement for test coverage in the code. There is also a
      general understanding amongst the engineers that these tests increase
      the quality of their code and produce long term cost savings.

      Nevertheless, the issue is two-fold. The first problem lies in the
      fact that there already exist a large number of legacy applications
      with zero unit/integration test coverage. The cost/time required to
      build complete unit or integration test coverage on this code during
      small maintenance/ minor enhancement stories is cost prohibitive to the

      The other issue resides in the different interpretation of 'Done' Vs
      'Business Accepted'. While engineering work might not be considered
      done until there is sufficient test coverage, the functionalities can
      still be demoed and accepted by the business resulting in the
      engineering team omitting the unit/integration tests when they are in
      a time crunch to get a 'Pass' on a story.


      --- In scrumdevelopment@ yahoogroups. com, "Wolfgang Schulze Zachau"
      <wolfgang@.. .> wrote:
      > The question of test coverage should really be part of the definition of
      > DONE. However, I (scrum master) have also had to overcome resistance
      > the team and the PO in order to get acceptance for this, and to this
      > our test coverage is not brilliant (and now it will never get better,
      > because the whole team has been made redundant and I am the only one
      > One way to get acceptance for the idea of automated unit/integration
      > is to actually do a little demonstration.
      > Write a small module, say a database connection class. Then set up a
      > of acceptance criteria for the class. Now show to the team how long
      it takes
      > to test each of the criteria manually. Then show them how long it
      takes to
      > run a set of pre-defined unit tests. That should convince anybody. Now
      > multiply the figures by the ratio between the number of code lines
      in your
      > main project and the number of code lines in the little demo project
      and you
      > have your time savings.
      > In essence, if you want to develop what Ron Jeffries calls "running,
      > features" (hope I quoted that correctly), there is no way around
      > tests. OTOH, this is not, strictly speaking, a part of SCRUM, it is a
      > consequence of making a commitment of delivering an increment in
      > functionality (which you will eventually be unable to do unless you use
      > automated testing).
      > Hope this makes sense.
      > Regards,
      > Wolfgang
      > _____
      > From: scrumdevelopment@ yahoogroups. com
      > [mailto:scrumdevelopment@ yahoogroups. com] On Behalf Of andywadhwa
      > Sent: 07 March 2008 07:37
      > To: scrumdevelopment@ yahoogroups. com
      > Subject: [scrumdevelopment] Writing Unit, Integration and Automated
      > during development
      > Scrum Group:
      > I work as a Product Owner with an engineering team (5 engineers and 2
      > QA). We have adapted well to Scrum development over the past year,
      > however we still barely have any unit, integration and automated tests
      > built into our applications.
      > As a Product Owner interested in software with low long term
      > maintenance costs, I would like some suggestions on how I can embark
      > on the process of ensuring that our delivery team always builds
      > quality software with the right amount of unit, integration and
      > automated testing. Have any of you managed to bake this requirement
      > into the acceptance criteria on any of your user stories? In addition,
      > how can one ensure optimal coverage of these tests to avoid
      > overengineering?
      > Thanks for your responses.
      > Andy

      Never miss a thing. Make Yahoo your homepage.

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