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

Re: [agile-testing] Test Effort estimation in Agile projects

Expand Messages
  • Phlip
    ... Each week, developers testers and customer liaisons have a sit-down meeting. They demo the current version of the program, and declare which tasks are
    Message 1 of 5 , Jan 15, 2005
    • 0 Attachment
      Shrinvas Kulkarni wrote:
      >
      > How does tester in agile projects, estimate for stories? Are there
      > methods that are recommended or based on gut feel or SWAG (Scientific
      > Wild ass guess)?

      Each week, developers testers and customer liaisons have a sit-down
      meeting. They demo the current version of the program, and declare
      which tasks are finished. Then the customers compare the feature
      "backlog" to the implemented features, and develop a set of user
      stories for this week.

      Developers and testers pencil test plans on the back of each card.

      Then developers estimate how long each task will take, and customers
      commit to a stack of cards that will fit in a week.

      > While Effort estimation for test is in itself as big challenge that
      > test community is facing today - methods like Work break down
      > structure, or FP based techniques are in use. How does testers in
      > agile world handle estimation given that time for estimation is
      > relatively small.

      Developers and testers are responsible for the first tier of tests -
      the developer tests that TDD generates.

      Testers and customers are responsible for the second tier - the
      customer tests that represent each user story.

      Put together, and developers and customers are the ones writing the
      bulk of the tests. The testers' roles are to shepherd this process.
      They help convert text requirements into testable specifications, they
      add sick and twisted unit tests to probe boundaries, they bond and
      streamline the test rig to the build system and the version control
      system, and they broadcast test cases and results in web pages.

      All that effort is proactive and reactive, based on what the team is
      doing each day. I suspect the only estimation the system needs is
      developers estimating stories. As the testers help the team, these
      estimates will reflect the team's improved velocity.

      --
      Phlip
    • Ron Jeffries
      ... Recall that stories are generally quite narrow: just large enough for a few days programming. Customer tests are usually the ones addressed with testers
      Message 2 of 5 , Jan 16, 2005
      • 0 Attachment
        On Sunday, January 16, 2005, at 1:29:21 AM, Shrinvas Kulkarni wrote:

        > How does tester in agile projects, estimate for stories? Are there
        > methods that are recommended or based on gut feel or SWAG (Scientific
        > Wild ass guess)?

        > While Effort estimation for test is in itself as big challenge that
        > test community is facing today - methods like Work break down
        > structure, or FP based techniques are in use. How does testers in
        > agile world handle estimation given that time for estimation is
        > relatively small.

        Recall that stories are generally quite narrow: just large enough
        for a few days' programming. Customer tests are usually the ones
        addressed with testers' assistance, and the understanding about what
        should, and what should not work, is usually pretty clear. Most of
        the teams I observe know exactly what they are going to test and
        what they are not.

        There are many stories in every iteration. The result is that the
        combination of a known set of tests to write means that the tester
        gets good at estimating the testing effort, just as programmers get
        at estimating the programming effort.

        In short: practice, man, practice.

        I think that there is also a difference of outlook that comes with
        Agile testing. Often testers seem to think that their purpose is to
        break the software, and they aren't satisfied until they do. This
        can mean that it can take a long time to break.

        Aside:

        I can sense testers in the audience who want to say right now that
        [Moohahaha] it doesn't take long to break most software. [Laugh
        track.] Feel free to say that, but then I'm going to ask why it is
        so hard to estimate how long it'll take. Then they will say
        something about finding all the defects, and I will ask why. That
        might bring us back to Brian's recent notion which I'll rephrase
        as good testing being rapid testing.

        What would you do differently as a tester if you only had to find
        one defect in any given feature to send it back to the pool?

        In the Agile project, I think of the testing effort as more building
        fences, or markers on the ground: "Over here, the program works as
        advertised." The testing effort provides information, confidence,
        and direction for next steps.

        I've always felt that there is something different about what
        testing is in Agile projects compared to [the alternative]. My
        attempts to express this so far have been of varied, but never
        great, success. But they have gained me many fans and friends in the
        testing community, I'm sure. :)

        Ron Jeffries
        www.XProgramming.com
        There is economic value in manufacturing identical wheels. There is no
        economic value in reinventing the wheel. With manufacturing, variation is
        bad. With design activities such as software, variation (i.e. differences
        from previous systems) is what we're selling. -- Hubert Matthews
      • Lisa Crispin
        ... (Scientific ... As Ron said, the stories are pretty narrow, so it usually isn t that hard to estimate. I make my testing tasks as specific as possible,
        Message 3 of 5 , Jan 18, 2005
        • 0 Attachment
          --- In agile-testing@yahoogroups.com, "Shrinvas Kulkarni"
          <shrinik@m...> wrote:
          >
          > How does tester in agile projects, estimate for stories? Are there
          > methods that are recommended or based on gut feel or SWAG
          (Scientific
          > Wild ass guess)?
          As Ron said, the stories are pretty narrow, so it usually isn't that
          hard to estimate. I make my testing tasks as specific as possible,
          and I have a pretty good feel for how long they will take. The
          whole team has input into the estimates, so if I'm way off, someone
          will challenge it.
          > While Effort estimation for test is in itself as big challenge
          that
          > test community is facing today - methods like Work break down
          > structure, or FP based techniques are in use. How does testers in
          > agile world handle estimation given that time for estimation is
          > relatively small.
          It seems hard at first, but experience is a good teacher. Also,
          they are just estimates. Most will be wrong but hopefully they will
          average out.
          -- Lisa
        • Shrini Kulkarni
          ... doing each day. I suspect the only estimation the system needs is developers estimating stories. As the testers help the team, these estimates will reflect
          Message 4 of 5 , Jan 19, 2005
          • 0 Attachment
            >>> All that effort is proactive and reactive, based on what the team is
            doing each day. I suspect the only estimation the system needs is
            developers estimating stories. As the testers help the team, these
            estimates will reflect the team's improved velocity.

            In the agile project that I am currently working, for every story, team
            sits and creates dev and test tasks. Dev estimates for dev task and test
            does for his test tasks. A story typical at minimum has two tasks one
            for dev and one for test. Is this the way typically it works? So there
            is no separate dev task and dev task?

            Shrini

            -----Original Message-----
            From: Phlip [mailto:phlip2005@...]
            Sent: Sunday, January 16, 2005 12:22 PM
            To: agile-testing@yahoogroups.com
            Subject: Re: [agile-testing] Test Effort estimation in Agile projects


            Shrinvas Kulkarni wrote:
            >
            > How does tester in agile projects, estimate for stories? Are there
            > methods that are recommended or based on gut feel or SWAG (Scientific
            > Wild ass guess)?

            Each week, developers testers and customer liaisons have a sit-down
            meeting. They demo the current version of the program, and declare
            which tasks are finished. Then the customers compare the feature
            "backlog" to the implemented features, and develop a set of user
            stories for this week.

            Developers and testers pencil test plans on the back of each card.

            Then developers estimate how long each task will take, and customers
            commit to a stack of cards that will fit in a week.

            > While Effort estimation for test is in itself as big challenge that
            > test community is facing today - methods like Work break down
            > structure, or FP based techniques are in use. How does testers in
            > agile world handle estimation given that time for estimation is
            > relatively small.

            Developers and testers are responsible for the first tier of tests -
            the developer tests that TDD generates.

            Testers and customers are responsible for the second tier - the
            customer tests that represent each user story.

            Put together, and developers and customers are the ones writing the
            bulk of the tests. The testers' roles are to shepherd this process.
            They help convert text requirements into testable specifications, they
            add sick and twisted unit tests to probe boundaries, they bond and
            streamline the test rig to the build system and the version control
            system, and they broadcast test cases and results in web pages.

            All that effort is proactive and reactive, based on what the team is
            doing each day. I suspect the only estimation the system needs is
            developers estimating stories. As the testers help the team, these
            estimates will reflect the team's improved velocity.

            --
            Phlip



            Yahoo! Groups Links
          Your message has been successfully submitted and would be delivered to recipients shortly.