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

how does scrum make test concurrent with development

Expand Messages
  • xtremenilanjan
    In some descriptions of scrum it is mentioned that test is concurrent with development and not something done after development. However, scrum does not
    Message 1 of 14 , Jun 9, 2010
    • 0 Attachment
      In some descriptions of scrum it is mentioned that test is concurrent with development and not something done after development.

      However, scrum does not mention a specific engineering practice.

      Unless you use some form of test driven development or test first, I assume test can't start unless development is done.

      I know that some activities can be done by test early:
      - writing acceptance tests (description)
      - clarifying user stories
      - creating test infrastructure

      How does scrum ensure that test can start early and is concurrent with development?
    • Stephan Huez
      Hi xtremenilanjan, I ll try to explain how I experienced this situation. In Agile in general, the idea is that each sprint delivers shippable software. This
      Message 2 of 14 , Jun 9, 2010
      • 0 Attachment
        Hi xtremenilanjan,

        I'll try to explain how I experienced this situation.

        In Agile in general, the idea is that each sprint delivers shippable software. This means that any story planned in a sprint is developed AND tested within that sprint. As a sprint is rather short, one cannot afford to wait until a feature is ready to be tested. 

        On the other hand, the definition of done for a story defines the tests that must pass to say it's done.

        In practice, what does that mean?

        1/ Writing automated tests and writing software can start at the same time because they feed on the same food: the story, its associated acceptance criteria and discussions with the product owner. Developing and testing concurrently ensures that any question and discussion between the PO, developers and testers benefit all three at the same time and can be harnessed immediately.

        2/ If a tester automates tests while developers implement the code to be tested, they will communicate more and make the software more testable. Indeed, writing the test when the code is not there yet does not force you to "make do" with the existing design. The tester can influence the design so that the system be easier to test from the outside. This is along the same lines as TDD where the developer writes/designs the software so that it is easy to test and understand.

        3/ As soon as a bit of the story is developed and worth testing, the tester can start testing it so that the feedback loop be as short as possible. Testers and developers can organise the work so that there be intermediate milestones within the sprint to maximise the feedback.

        4/ It requires quite a shift of mindset to automate end-to-end tests without the software as much as in switching to TDD. What is different from TDD is that in TDD, developers write a test, just enough of the software to make the test pass, refactor and repeat these steps until done, through baby steps. In the case of end-to-end tests, the tester writes a test, in baby steps but he depends on the developer who writes the code. The steps are usually larger than in TDD.

        5/ Based on test descriptions, it is already possible to automate quite a lot without having any software to see. Discussions with the developers about how screens will be laid out, what name conventions will be followed as to html element names, etc. already help automate. If you need to test a web interface for instance, as soon as the developer as generated the page, he can hand it over to the tester who will be able to run its scripts against a static page.

        6/ The farther you are in a project, the easier you can test concurrently because much more is already available and the habit is well installed.

        7/ The concurrency between development and testing is very positive because it fosters communication and collaboration instead of the usual competition between developers and testers. Additionally, as Agile developers strive for delivering quality code, testers are not debuggers any more.

        8/ To see it working, there's only one way: try it.

        There is much more to say and I hope this already helps.

        Cheers,

        Stephan

        On 10 June 2010 05:04, xtremenilanjan <xtremenilanjan@...> wrote:
         

        In some descriptions of scrum it is mentioned that test is concurrent with development and not something done after development.

        However, scrum does not mention a specific engineering practice.

        Unless you use some form of test driven development or test first, I assume test can't start unless development is done.

        I know that some activities can be done by test early:
        - writing acceptance tests (description)
        - clarifying user stories
        - creating test infrastructure

        How does scrum ensure that test can start early and is concurrent with development?


      • Roy Morien
        Scrum, like most methods / methodologies, does not ensure anything, and doesn t prescribe specific actions. The fact that you are asking about testing shows
        Message 3 of 14 , Jun 10, 2010
        • 0 Attachment
          Scrum, like most methods / methodologies, does not 'ensure' anything, and doesn't prescribe specific actions.
           
          The fact that you are asking about testing shows that you are aware of the need for it, so you don't need Scrum to tell you that.
           
          So your attention should be turned to the study of testing methods, testing software, concepts and practices of 'test-first' and 'continuous integration' etc..
           
          Testing is indeed done concurrently with development. It is the responsibility of the developer to test the software that they are developing. and not leave it to some QA functionary at the end of the project, or at some other time.
           
          Regards,
          Roy Morien
           

          To: scrumdevelopment@yahoogroups.com
          From: xtremenilanjan@...
          Date: Thu, 10 Jun 2010 03:04:08 +0000
          Subject: [scrumdevelopment] how does scrum make test concurrent with development

           
          In some descriptions of scrum it is mentioned that test is concurrent with development and not something done after development.

          However, scrum does not mention a specific engineering practice.

          Unless you use some form of test driven development or test first, I assume test can't start unless development is done.

          I know that some activities can be done by test early:
          - writing acceptance tests (description)
          - clarifying user stories
          - creating test infrastructure

          How does scrum ensure that test can start early and is concurrent with development?




          Australia's #1 job site If It Exists, You'll Find it on SEEK
        • Ron Jeffries
          Hello, xtremenilanjan. On Wednesday, June 9, 2010, at 11:04:08 ... It doesn t. The team should notice that this is needed, and do it. Ron Jeffries
          Message 4 of 14 , Jun 10, 2010
          • 0 Attachment
            Hello, xtremenilanjan. On Wednesday, June 9, 2010, at 11:04:08
            PM, you wrote:

            > How does scrum ensure that test can start early and is concurrent
            > with development?

            It doesn't. The team should notice that this is needed, and do it.

            Ron Jeffries
            www.XProgramming.com
            www.xprogramming.com/blog
            I know we always like to say it'll be easier to do it now than it
            will be to do it later. Not likely. I plan to be smarter later than
            I am now, so I think it'll be just as easy later, maybe even easier.
            Why pay now when we can pay later?
          • Victor Hugo de Oliveira
            Scrum is a framework that promotes transparency, communication and focus. It does not go into the Software Engineering practices or the Baking practices or the
            Message 5 of 14 , Jun 10, 2010
            • 0 Attachment
              Scrum is a framework that promotes transparency, communication and focus.
              It does not go into the Software Engineering practices or the Baking practices or the Building caps to stop oil leak practices.
              That part is up to you, so to do the testing you will have to study about that, and figure out how to meet your definition of done at the end of the Sprint.

              My two cents,
              Victor


              On Thu, Jun 10, 2010 at 8:25 AM, Ron Jeffries <ronjeffries@...> wrote:
               

              Hello, xtremenilanjan. On Wednesday, June 9, 2010, at 11:04:08


              PM, you wrote:

              > How does scrum ensure that test can start early and is concurrent
              > with development?

              It doesn't. The team should notice that this is needed, and do it.

              Ron Jeffries
              www.XProgramming.com
              www.xprogramming.com/blog
              I know we always like to say it'll be easier to do it now than it
              will be to do it later. Not likely. I plan to be smarter later than
              I am now, so I think it'll be just as easy later, maybe even easier.
              Why pay now when we can pay later?




              --
              Victor Hugo de Oliveira

              Scrum & Agile Blog
              http://csvo.wordpress.com

              Concrete Solutions
              new edition: http://www.concretesolutions.com.br/index_eng/

              +55 21 2240 2030
              +55 11 4119 0449
              R. São José 90, 2121
              20010-020
              Rio de Janeiro, RJ, Brasil
            • xtremenilanjan
              Thanks for the detailed post. It s very helpful. Wouldn t it be better for you to use TDD? I realize that TDD is more rigorous/difficult/involved. I am
              Message 6 of 14 , Jun 11, 2010
              • 0 Attachment
                Thanks for the detailed post. It's very helpful.

                Wouldn't it be better for you to use TDD? I realize that TDD is more rigorous/difficult/involved. I am thinking that it may be difficult to implement your process/if you run out of time, might not do as much as you want.

                --- In scrumdevelopment@yahoogroups.com, Stephan Huez <stephan.huez@...> wrote:
                >
                > Hi xtremenilanjan,
                >
                > I'll try to explain how I experienced this situation.
                >
                > In Agile in general, the idea is that each sprint delivers shippable
                > software. This means that any story planned in a sprint is developed AND
                > tested within that sprint. As a sprint is rather short, one cannot afford to
                > wait until a feature is ready to be tested.
                >
                > On the other hand, the definition of done for a story defines the tests that
                > must pass to say it's done.
                >
                > In practice, what does that mean?
                >
                > 1/ Writing automated tests and writing software can start at the same time
                > because they feed on the same food: the story, its associated acceptance
                > criteria and discussions with the product owner. Developing and testing
                > concurrently ensures that any question and discussion between the PO,
                > developers and testers benefit all three at the same time and can be
                > harnessed immediately.
                >
                > 2/ If a tester automates tests while developers implement the code to be
                > tested, they will communicate more and make the software more testable.
                > Indeed, writing the test when the code is not there yet does not force you
                > to "make do" with the existing design. The tester can influence the design
                > so that the system be easier to test from the outside. This is along the
                > same lines as TDD where the developer writes/designs the software so that it
                > is easy to test and understand.
                >
                > 3/ As soon as a bit of the story is developed and worth testing, the tester
                > can start testing it so that the feedback loop be as short as possible.
                > Testers and developers can organise the work so that there be intermediate
                > milestones within the sprint to maximise the feedback.
                >
                > 4/ It requires quite a shift of mindset to automate end-to-end tests without
                > the software as much as in switching to TDD. What is different from TDD is
                > that in TDD, developers write a test, just enough of the software to make
                > the test pass, refactor and repeat these steps until done, through baby
                > steps. In the case of end-to-end tests, the tester writes a test, in baby
                > steps but he depends on the developer who writes the code. The steps are
                > usually larger than in TDD.
                >
                > 5/ Based on test descriptions, it is already possible to automate quite a
                > lot without having any software to see. Discussions with the developers
                > about how screens will be laid out, what name conventions will be followed
                > as to html element names, etc. already help automate. If you need to test a
                > web interface for instance, as soon as the developer as generated the page,
                > he can hand it over to the tester who will be able to run its scripts
                > against a static page.
                >
                > 6/ The farther you are in a project, the easier you can test concurrently
                > because much more is already available and the habit is well installed.
                >
                > 7/ The concurrency between development and testing is very positive because
                > it fosters communication and collaboration instead of the usual competition
                > between developers and testers. Additionally, as Agile developers strive for
                > delivering quality code, testers are not debuggers any more.
                >
                > 8/ To see it working, there's only one way: try it.
                >
                > There is much more to say and I hope this already helps.
                >
                > Cheers,
                >
                > Stephan
                >
                > On 10 June 2010 05:04, xtremenilanjan <xtremenilanjan@...> wrote:
                >
                > >
                > >
                > > In some descriptions of scrum it is mentioned that test is concurrent with
                > > development and not something done after development.
                > >
                > > However, scrum does not mention a specific engineering practice.
                > >
                > > Unless you use some form of test driven development or test first, I assume
                > > test can't start unless development is done.
                > >
                > > I know that some activities can be done by test early:
                > > - writing acceptance tests (description)
                > > - clarifying user stories
                > > - creating test infrastructure
                > >
                > > How does scrum ensure that test can start early and is concurrent with
                > > development?
                > >
                > >
                > >
                >
              • xtremenilanjan
                I should have explained a bit more.... I have seen teams: - test 1 sprint later than dev - develop for a week and then test for a week etc. In some cases, this
                Message 7 of 14 , Jun 11, 2010
                • 0 Attachment
                  I should have explained a bit more....

                  I have seen teams:
                  - test 1 sprint later than dev
                  - develop for a week and then test for a week

                  etc.

                  In some cases, this can cause a lot of confusion

                  Since scrum doesn't get into these details, it leaves open room for negative (?) interpretation.

                  Contrast with XP which defines practices in detail.

                  P.S.: I am not trying to start a xp vs. scrum war. just trying to understand scrum (and agile and xp)

                  --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
                  >
                  >
                  > Scrum, like most methods / methodologies, does not 'ensure' anything, and doesn't prescribe specific actions.
                  >
                  >
                  >
                  > The fact that you are asking about testing shows that you are aware of the need for it, so you don't need Scrum to tell you that.
                  >
                  >
                  >
                  > So your attention should be turned to the study of testing methods, testing software, concepts and practices of 'test-first' and 'continuous integration' etc..
                  >
                  >
                  >
                  > Testing is indeed done concurrently with development. It is the responsibility of the developer to test the software that they are developing. and not leave it to some QA functionary at the end of the project, or at some other time.
                  >
                  >
                  >
                  > Regards,
                  >
                  > Roy Morien
                  >
                  >
                  >
                  > To: scrumdevelopment@yahoogroups.com
                  > From: xtremenilanjan@...
                  > Date: Thu, 10 Jun 2010 03:04:08 +0000
                  > Subject: [scrumdevelopment] how does scrum make test concurrent with development
                  >
                  >
                  >
                  >
                  >
                  > In some descriptions of scrum it is mentioned that test is concurrent with development and not something done after development.
                  >
                  > However, scrum does not mention a specific engineering practice.
                  >
                  > Unless you use some form of test driven development or test first, I assume test can't start unless development is done.
                  >
                  > I know that some activities can be done by test early:
                  > - writing acceptance tests (description)
                  > - clarifying user stories
                  > - creating test infrastructure
                  >
                  > How does scrum ensure that test can start early and is concurrent with development?
                  >
                  >
                  >
                  >
                  >
                  > _________________________________________________________________
                  > If It Exists, You'll Find it on SEEK. Australia's #1 job site
                  > http://clk.atdmt.com/NMN/go/157639755/direct/01/
                  >
                • xtremenilanjan
                  I would be interested in your response to my post: http://groups.yahoo.com/group/scrumdevelopment/message/47188
                  Message 8 of 14 , Jun 11, 2010
                  • 0 Attachment
                    I would be interested in your response to my post:
                    http://groups.yahoo.com/group/scrumdevelopment/message/47188

                    --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                    >
                    > Hello, xtremenilanjan. On Wednesday, June 9, 2010, at 11:04:08
                    > PM, you wrote:
                    >
                    > > How does scrum ensure that test can start early and is concurrent
                    > > with development?
                    >
                    > It doesn't. The team should notice that this is needed, and do it.
                    >
                    > Ron Jeffries
                    > www.XProgramming.com
                    > www.xprogramming.com/blog
                    > I know we always like to say it'll be easier to do it now than it
                    > will be to do it later. Not likely. I plan to be smarter later than
                    > I am now, so I think it'll be just as easy later, maybe even easier.
                    > Why pay now when we can pay later?
                    >
                  • Stephan Huez
                    As Kent Beck and Martin Fowler wrote in Planning Extreme Programming: you shall not say I don t have enough time but instead I have too much to do See
                    Message 9 of 14 , Jun 11, 2010
                    • 0 Attachment
                      As Kent Beck and Martin Fowler wrote in Planning Extreme Programming: you shall not say " I don't have enough time" but instead "I have too much to do"


                      Cheers,

                      Steph

                      On 11 June 2010 11:16, xtremenilanjan <xtremenilanjan@...> wrote:
                       

                      Thanks for the detailed post. It's very helpful.

                      Wouldn't it be better for you to use TDD? I realize that TDD is more rigorous/difficult/involved. I am thinking that it may be difficult to implement your process/if you run out of time, might not do as much as you want.


                      --- In scrumdevelopment@yahoogroups.com, Stephan Huez <stephan.huez@...> wrote:
                      >
                      > Hi xtremenilanjan,
                      >
                      > I'll try to explain how I experienced this situation.
                      >
                      > In Agile in general, the idea is that each sprint delivers shippable
                      > software. This means that any story planned in a sprint is developed AND
                      > tested within that sprint. As a sprint is rather short, one cannot afford to
                      > wait until a feature is ready to be tested.
                      >
                      > On the other hand, the definition of done for a story defines the tests that
                      > must pass to say it's done.
                      >
                      > In practice, what does that mean?
                      >
                      > 1/ Writing automated tests and writing software can start at the same time
                      > because they feed on the same food: the story, its associated acceptance
                      > criteria and discussions with the product owner. Developing and testing
                      > concurrently ensures that any question and discussion between the PO,
                      > developers and testers benefit all three at the same time and can be
                      > harnessed immediately.
                      >
                      > 2/ If a tester automates tests while developers implement the code to be
                      > tested, they will communicate more and make the software more testable.
                      > Indeed, writing the test when the code is not there yet does not force you
                      > to "make do" with the existing design. The tester can influence the design
                      > so that the system be easier to test from the outside. This is along the
                      > same lines as TDD where the developer writes/designs the software so that it
                      > is easy to test and understand.
                      >
                      > 3/ As soon as a bit of the story is developed and worth testing, the tester
                      > can start testing it so that the feedback loop be as short as possible.
                      > Testers and developers can organise the work so that there be intermediate
                      > milestones within the sprint to maximise the feedback.
                      >
                      > 4/ It requires quite a shift of mindset to automate end-to-end tests without
                      > the software as much as in switching to TDD. What is different from TDD is
                      > that in TDD, developers write a test, just enough of the software to make
                      > the test pass, refactor and repeat these steps until done, through baby
                      > steps. In the case of end-to-end tests, the tester writes a test, in baby
                      > steps but he depends on the developer who writes the code. The steps are
                      > usually larger than in TDD.
                      >
                      > 5/ Based on test descriptions, it is already possible to automate quite a
                      > lot without having any software to see. Discussions with the developers
                      > about how screens will be laid out, what name conventions will be followed
                      > as to html element names, etc. already help automate. If you need to test a
                      > web interface for instance, as soon as the developer as generated the page,
                      > he can hand it over to the tester who will be able to run its scripts
                      > against a static page.
                      >
                      > 6/ The farther you are in a project, the easier you can test concurrently
                      > because much more is already available and the habit is well installed.
                      >
                      > 7/ The concurrency between development and testing is very positive because
                      > it fosters communication and collaboration instead of the usual competition
                      > between developers and testers. Additionally, as Agile developers strive for
                      > delivering quality code, testers are not debuggers any more.
                      >
                      > 8/ To see it working, there's only one way: try it.
                      >
                      > There is much more to say and I hope this already helps.
                      >
                      > Cheers,
                      >
                      > Stephan
                      >
                      > On 10 June 2010 05:04, xtremenilanjan <xtremenilanjan@...> wrote:
                      >
                      > >
                      > >
                      > > In some descriptions of scrum it is mentioned that test is concurrent with
                      > > development and not something done after development.
                      > >
                      > > However, scrum does not mention a specific engineering practice.
                      > >
                      > > Unless you use some form of test driven development or test first, I assume
                      > > test can't start unless development is done.
                      > >
                      > > I know that some activities can be done by test early:
                      > > - writing acceptance tests (description)
                      > > - clarifying user stories
                      > > - creating test infrastructure
                      > >
                      > > How does scrum ensure that test can start early and is concurrent with
                      > > development?
                      > >
                      > >
                      > >
                      >


                    • Steve Ropa
                      I would go as far as to say in all cases those two practices cause a lot of confusion at best. You are absolutely right that Scrum does not define those
                      Message 10 of 14 , Jun 11, 2010
                      • 0 Attachment
                        I would go as far as to say in all cases those two practices cause a lot of confusion at best.  You are absolutely right that Scrum does not define those practices such as TDD, or Automated Acceptance Tests.  If they are good ideas, which I fervently believe they are, then why not do them anyway.  It isn't about which label you use for your methodology, its about developing good software at a sustainable pace.  I'm sure the majority of Scrum teams adopt many if not all of the XP practices.  Conversely, I'm sure many XP teams are using many if not all of the Scrum practices.  They fit together quite nicely most of the time.
                         
                        Steve

                        Sent: Friday, June 11, 2010 3:21 AM
                        Subject: [scrumdevelopment] Re: how does scrum make test concurrent with development

                         

                        I should have explained a bit more....

                        I have seen teams:
                        - test 1 sprint later than dev
                        - develop for a week and then test for a week

                        etc.

                        In some cases, this can cause a lot of confusion

                        Since scrum doesn't get into these details, it leaves open room for negative (?) interpretation.

                        Contrast with XP which defines practices in detail.

                        P.S.: I am not trying to start a xp vs. scrum war. just trying to understand scrum (and agile and xp)

                        --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:

                        >
                        >
                        > Scrum, like
                        most methods / methodologies, does not 'ensure' anything, and doesn't prescribe specific actions.
                        >
                        >
                        >
                        > The fact that you are
                        asking about testing shows that you are aware of the need for it, so you don't need Scrum to tell you that.
                        >
                        >
                        >
                        > So your
                        attention should be turned to the study of testing methods, testing software, concepts and practices of 'test-first' and 'continuous integration' etc..
                        >
                        >
                        >
                        > Testing is indeed done concurrently
                        with development. It is the responsibility of the developer to test the software that they are developing. and not leave it to some QA functionary at the end of the project, or at some other time.
                        >
                        >
                        >
                        >
                        Regards,
                        >
                        > Roy Morien
                        >
                        >
                        >
                        > To:
                        href="mailto:scrumdevelopment%40yahoogroups.com">scrumdevelopment@yahoogroups.com
                        >
                        From: xtremenilanjan@...
                        > Date: Thu, 10 Jun 2010 03:04:08 +0000
                        >
                        Subject: [scrumdevelopment] how does scrum make test concurrent with development
                        >
                        >
                        >
                        >
                        >
                        > In some
                        descriptions of scrum it is mentioned that test is concurrent with development and not something done after development.
                        >
                        > However, scrum does
                        not mention a specific engineering practice.
                        >
                        > Unless you use
                        some form of test driven development or test first, I assume test can't start unless development is done.
                        >
                        > I know that some activities can be
                        done by test early:
                        > - writing acceptance tests (description)
                        > -
                        clarifying user stories
                        > - creating test infrastructure
                        >
                        >
                        How does scrum ensure that test can start early and is concurrent with development?
                        >
                        >
                        >
                        >
                        >
                        >
                        __________________________________________________________
                        > If It Exists,
                        You'll Find it on SEEK. Australia's #1 job site
                        >
                        href="http://clk.atdmt.com/NMN/go/157639755/direct/01/">http://clk.atdmt.com/NMN/go/157639755/direct/01/
                        >

                      • Adam Sroka
                        ... The majority of Scrum teams do not adopt XP practices, but the majority of the ones who are effective do -- as observed by Jeff Sutherland among others.
                        Message 11 of 14 , Jun 11, 2010
                        • 0 Attachment
                          On Fri, Jun 11, 2010 at 12:19 PM, Steve Ropa <theropas@...> wrote:
                          >
                          >
                          >
                          > I'm sure the majority of Scrum teams adopt many if not all of the XP practices.  Conversely, I'm sure many XP teams are using many if not all of the Scrum practices.  They fit together quite nicely most of the time.
                          >

                          The majority of Scrum teams do not adopt XP practices, but the
                          majority of the ones who are effective do -- as observed by Jeff
                          Sutherland among others.

                          Many XP teams do use much of Scrum, because the original XP practices
                          included ideas that were taken directly from Scrum. However, many XP
                          teams have removed superfluous ideas from Scrum as part of the process
                          of continuous improvement

                          There are some differences. For example, many XP teams now eschew task
                          estimation or estimation in general. XP teams do not have the roles of
                          Scrum. The Product Owner role in Scrum is analogous to the XP
                          Customer, but you sometimes have to squint a bit to make them look the
                          same. There is no such thing as a Scrum Master on an XP team.

                          Most XP teams that I am aware of have thrown out the idea of release
                          planning in favor of releasing every iteration. Some have even
                          eliminated iterations in favor of a more Kanban like (continuous flow)
                          approach.

                          ...

                          There is a synergism between these ideas. The key thing to realize is
                          that one of the goals of Agile is to release working software more
                          frequently. There are technical implications to that, and the tighter
                          you squeeze your releases the more painful and less feasible it
                          becomes to do things in a waterfallish way.

                          So, you can adopt Scrum an continue to do things pretty much the way
                          you did before, but when you try to add value continuously and drive
                          you cycles smaller and smaller you inevitably have to do some of the
                          technical things XP recommends.
                        • George Dinwiddie
                          Hi, X, ... You assume wrong. ... Creating infrastructure? Bah! Create the automated acceptance test. When doing so, create just as much infrastructure as you
                          Message 12 of 14 , Jun 11, 2010
                          • 0 Attachment
                            Hi, X,

                            xtremenilanjan wrote:
                            > In some descriptions of scrum it is mentioned that test is concurrent
                            > with development and not something done after development.
                            >
                            > However, scrum does not mention a specific engineering practice.
                            >
                            > Unless you use some form of test driven development or test first, I
                            > assume test can't start unless development is done.

                            You assume wrong.

                            > I know that some activities can be done by test early:
                            > - writing acceptance tests (description)
                            > - clarifying user stories
                            > - creating test infrastructure

                            Creating infrastructure? Bah! Create the automated acceptance test. When
                            doing so, create just as much infrastructure as you need, and no more.

                            > How does scrum ensure that test can start early and is concurrent
                            > with development?

                            Scrum doesn't. The team does.

                            Some of these might help:
                            http://blog.gdinwiddie.com/2010/02/16/the-testers-get-behind-at-the-end/
                            http://blog.gdinwiddie.com/2010/02/25/a-lingua-franca-between-the-three-or-more-amigos/
                            http://blog.gdinwiddie.com/2010/03/05/testing-in-depth/

                            - George

                            --
                            ----------------------------------------------------------------------
                            * George Dinwiddie * http://blog.gdinwiddie.com
                            Software Development http://www.idiacomputing.com
                            Consultant and Coach http://www.agilemaryland.org
                            ----------------------------------------------------------------------
                          • George Dinwiddie
                            X, ... It s not nearly as hard as you imagine. - George -- ... * George Dinwiddie * http://blog.gdinwiddie.com Software Development
                            Message 13 of 14 , Jun 11, 2010
                            • 0 Attachment
                              X,

                              xtremenilanjan wrote:
                              > I realize that TDD is more rigorous/difficult/involved.

                              It's not nearly as hard as you imagine.

                              - George

                              --
                              ----------------------------------------------------------------------
                              * George Dinwiddie * http://blog.gdinwiddie.com
                              Software Development http://www.idiacomputing.com
                              Consultant and Coach http://www.agilemaryland.org
                              ----------------------------------------------------------------------
                            • George Dinwiddie
                              X, ... In all cases, in my experience. http://blog.gdinwiddie.com/2010/02/16/the-testers-get-behind-at-the-end/ ... Scrum doesn t tell them how to tie their
                              Message 14 of 14 , Jun 11, 2010
                              • 0 Attachment
                                X,

                                xtremenilanjan wrote:
                                > I should have explained a bit more....
                                >
                                > I have seen teams:
                                > - test 1 sprint later than dev
                                > - develop for a week and then test for a week
                                >
                                > etc.
                                >
                                > In some cases, this can cause a lot of confusion

                                In all cases, in my experience.
                                http://blog.gdinwiddie.com/2010/02/16/the-testers-get-behind-at-the-end/

                                > Since scrum doesn't get into these details, it leaves open room for
                                > negative (?) interpretation.
                                >
                                > Contrast with XP which defines practices in detail.
                                >
                                > P.S.: I am not trying to start a xp vs. scrum war. just trying to
                                > understand scrum (and agile and xp)

                                Scrum doesn't tell them how to tie their shoes, either. Yet most teams
                                manage to do so.

                                Scrum expects the teams to behave competently, and to "inspect and
                                adapt" to get better.

                                - George

                                --
                                ----------------------------------------------------------------------
                                * George Dinwiddie * http://blog.gdinwiddie.com
                                Software Development http://www.idiacomputing.com
                                Consultant and Coach http://www.agilemaryland.org
                                ----------------------------------------------------------------------
                              Your message has been successfully submitted and would be delivered to recipients shortly.