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

37707RE: [scrumdevelopment] Re: Dedicate Tester in an Agile Team

Expand Messages
  • Jaideep Khanduja
    Apr 17, 2009
    • 0 Attachment

      Adam wrote:

      >People with a background in testing definitely bring something unique to the table. At the very least they: a) are familiar with methods and tools for testing that aren't strictly related to TDD. b) have spent a lot of time thinking about how to break things and where things might be likely to break. c) understand how to think about and communicate about quality.

       

      But who says in TDD: a) is devoid of methods and tools for testing (are there any standards about methods and tools that aren’t strictly related to TDD, atleast I am not aware of!), b) does it mean none of TDD team members spend time thinking about how to break things and where things might be likely to break, c) again does it mean TDD team members do not understand how to think about and communicate about quality.

       

      I think, TDD is at par all these qualities and above that. (I might be wrong!)

       

       

      Best Regards,

       

      Jaideep

       


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Adam Sroka
      Sent: Friday, April 17, 2009 12:15 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Re: Dedicate Tester in an Agile Team

       




      On Thu, Apr 16, 2009 at 11:37 PM , brian_bofu <brian_bofu@yahoo. com.cn> wrote:

      >
      >
      > The developers are practising TDD. My question is, is there a need for a
      > tester in the team if we have not had one yet? Can developers who are
      doing
      > TDD/AT ensure the quality without testers' invlovement?
      >

      People with a background in testing definitely bring something unique
      to the table. At the very least they: a) are familiar with methods and
      tools for testing that aren't strictly related to TDD. b) have spent a
      lot of time thinking about how to break things and where things might
      be likely to break. c) understand how to think about and communicate
      about quality.

      Are these things strictly necessary to do TDD effectively and ensure
      quality? No. Could they help to do it faster/better? Definitely.

      Confidentiality Notice:

      The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at admin@... immediately and destroy all the copies of this message and any attachments

    • Show all 24 messages in this topic