Project Practitioners > So Where Does Testing Fit in Test Driven Development?

So Where Does Testing Fit in Test Driven Development?

By Kent McDonald

A couple of days ago I had the opportunity to work with a team considering the use of agile for their application development project.  This organization currently follows a typical software development lifecycle with different phases containing a focus on a particular type of activity – analysis phase, design phase, development phase, testing phase, etc.  And like most organizations that follow this approach they had set up their organization based on those phases – there is a department of business analysts, a department of testers, a department of developers, etc.  As we talked about the iterative and incremental nature of agile methods, a common thread appeared in their line of questioning – where does testing fit into an agile approach?

As I described a particular agile method in detail, I pointed out that a common definition of done at the end of an iteration is the delivery of value to the organization.  Put in more concrete terms, running tested features (a phrase coined by Ron Jeffries).  I even described the technique of Test Driven Development where when creating new code, a developer first writes a test that they know will fail, but which verifies functionality that they are trying to create.  The developer then writes the code to make that test pass, and then tests it.  If the test now passes, they move on to the next story.  If the test fails, they keep working on the code until it passes.  So my only partially flippant answer was testing fits in everywhere.

The questions continued:

  • What test plans do we write?
  • What do test plans look like?
  • Who writes the test plans?
  • How is regression testing done?
  • Is user acceptance testing done in agile?

Teams used to the lifecycle based approach to software development have become accustomed to specialized testers (and frequently different organizations handling different types of testing) taking the product through its paces at the end of a software project.  Their job is to find bugs – to inspect quality into the product. 

The luminaries of the quality movement, especially W. Edwards Deming said over 20 years ago that you cannot hope to inspect quality into the system.  You instead need to build it into the beginning.  Teams using Agile approaches correctly adopt that viewpoint and take steps to build quality into the system.  They establish commonly agreed definitions of “done” through the joint establishment of acceptance tests during the initial discussions of a feature.  There is even a tool called FIT which allows teams to express their requirements in terms of tests and examples, which is a much more useful way to communicate what the feature should do to developers in a way that can be verified.  Developers follow the Test Driven Development approach I mentioned above to effectively perform unit testing.  All of these tests are incorporated into the build process, so that when new code is checked in, existing tests are run to make sure that no harm was done – this is your regression tests.

All of these techniques become part of the team’s rhythm.  Any test plans that are written are actually just agreements by the team on how they will do these various tests, and perhaps standards on how the various tests should be written.  This is where the folks from the various test organizations can add value.  They can provide the subject matter expertise when the team is establishing these standards.  They can help customers make sure they have appropriate coverage on their requirements (acceptance tests) and  developers make sure they have appropriate tests to test the functionality.  If they do this is a side by side type manner, actually working with these team members when those things are being created, they can become more familiar with the business, and more familiar with the technology.

The role of testing changes from an adversarial “Let me find all the mistakes you made” nature to a more collaborative “let me help you not make mistakes in the first place” approach.  This will have the nice effect of improving relations between testers and developers, and more importantly, it will lead to dramatic improvement for the entire team.

So where does testing fit in Test Driven Development, my increasingly less flippant answer is still everywhere, with the key point being is that you have to change your viewpoint of testing, and people that do testing, in order to make that change happen.



Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

Kent,

I am not 100% convinced that TDD is 'the' way to go for all class of problems. For one, there is still a humongous amount of code in C and other languages that can't effectively use concepts like refactoring and TDD and newer tools that support them. How do you fix that problem ? Seocndly, ideologically, how to do you develop bug-free software from test specs when we haven't yet figured out how to do that from requirements specs. I have explored some of these issues in my blog at http://managewell.net/?p=102.

regards,
Tathagat


Tathagat,
Thanks for your comments. Generally speaking, no tool or technique works for every problem (part of the reason why I try not to use the term “best practice”). I would agree that there is a lot of existing code in C and other languages that cannot effectively be refactored because they don’t have existing tests written to verify that the refactoring “did no harm”. Perhaps there aren’t tools that simplify unit testing for some languages, but I don’t buy that you can’t still establish your unit tests before developing your production code, unless of course you don’t unit test when developing with certain languages…

As to your second question: establishing your tests first without building a good understanding of the problem and desired solution is pure folly. In the same manner, building an understanding of what you need to without establishing a way to verify that you satisfied those needs is also pure folly. There are several practices that work best when done in conjunction with others (I hinted at the important connection between refactoring and the availability of unit tests above). The point of my post was not to indicate that Test Driven Development replaces building a good understanding of the problem, rather I was pointing out that perhaps we should reconsider when we think about testing. My comment about representing requirements in terms of tests was intended to imply a way to reduce time spent documenting so that more time can be spent on important discussions like “are we building the right things”, and “how do we know that we built the right thing right”.


The comments to this entry are closed.




©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy



Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds


Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.