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

57838Re: [SCRUMDEVELOPMENT] TDD effectiveness

Expand Messages
  • Sudipta Lahiri
    Jun 5, 2014
      My experience:

      Automating unit test cases that have been built traditionally (written in Excel by a developer) helps in terms of regression. However, it's efficiency is limited by the effectiveness of the manual test cases. We have always struggled with the question - are the number and quality of test cases good enough? We are back using checklists, doing peer reviews, etc. 

      What is really significantly more helpful is Test (First) Driven Development. However, that is a very difficult transition for many development teams. It's a change that takes 3-6 months of sustained and persistent effort to kill the old way of working and adopt a new one. The more experienced developers take more time!

      Unfortunately, most Dev teams pass off the first category as TDD. 


      On 03-Jun-2014, at 11:28, "Tim Wright tim@... [SCRUMDEVELOPMENT]" <SCRUMDEVELOPMENT@yahoogroups.com> wrote:


      Hi all,

      Given this discussion, I thought it sensible to point out that TDD isn't exactly a new idea...


      On 3 June 2014 13:41, Adam Sroka adam.sroka@... [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT@yahoogroups.com> wrote:

      Code coverage is a double-edged sword. You can show it to middle managers to prove that all that time you spent on testing you were actually doing something useful. However, once you test all the easy stuff the number is going to move slower and they're gonna want to know why. 

      At that point a lot of folks might start doing silly things to improve the number. That's a bad idea. The trick is to realize that this is all a game and it only buys you a small amount of time to improve things. After that you're going to have to try something else. 

      I use coverage to motivate teams to start automating tests and managers to leave them alone and let them do it. The truth is, however, that once you have at least one test running the number itself is kinda pointless. At the first sign of danger I will take it down and tell them that, on further analysis, we were finding the number didn't accurately reflect our testing effort... 

      On Wed, May 28, 2014 at 1:16 AM, 'Hiep Le' tronghieple258@... [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT@yahoogroups.com> wrote:

      In my view, the code coverage is a trap; developers will write some meaningless tests in order to reach to a certain ratio, which is stupid and a waste of time.


      What we should do is to write good tests (cover positive and negative cases) for appropriate context and TDD is a good way to go.


      Stay tuned,

      Hiep Le.


      From: SCRUMDEVELOPMENT@yahoogroups.com [mailto:SCRUMDEVELOPMENT@yahoogroups.com]
      Sent: Wednesday, May 28, 2014 2:28 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [SCRUMDEVELOPMENT] TDD effectiveness



      In short, my empirical evidence shows that TDD does not necessarily keep you from doing a poor job.




      Scaling Agile as if you meant it: http://www.scaledprinciples.org


      Dipl.-Inform. Markus Gaertner
      Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development


      On Wed, May 28, 2014 at 8:24 AM, poojawandile@... [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT@yahoogroups.com> wrote:



      In one of the recent projects, it was found that many of the defects were related to inadequate unit testing though the code coverage goal was getting met. As an improvement initiative the team is thinking of using TDD. But before making that decision, would like to know if there are any case studies that suggests TDD indeed helps in reducing UT defects. 






      021 251 5593

    • Show all 42 messages in this topic