• Prev
  • Next

Agile and Test-Driven Development: A Path to Improved Software Quality


Agile is growing in popularity - we all know this to be true. And honestly, we're happy about it. When implemented properly, Agile offers great benefits to organizations. However, even with those benefits, there is one major drawback to the framework: it does not offer a strict definition of testing. 

With no definition, it's up to the individual organization to decide how to proceed with testing. The problem with this is that most organizations tend not to prioritize testing the way that they should. Instead of early detection and prevention, they leave testing until the end of a project, or even the end of a sprint, so it's more time consuming and costly to address. 

The answer lies in Test-Driven Development (TDD). TDD naturally complements the Agile framework, and it directly leads to software that is higher in quality. It also increases communication between the developers and testers, and ultimately between IT and the business (who are writing the requirements). 

To learn more about what TDD is and how it can work in tandem with Agile, read our latest publication, "Test-Driven Development and Agile."

Questions? Comments? Let us know!



Written by Default at 05:00
Categories :

Test-Driven Development

James JandebeurTesting has always been a bit of a thorn in the side of software development, necessary as it is. It costs money and time, ties up resources, and does not result in easily tracked returns on investment. In a typical organization, the testing process beings after the development project is complete, in order to ferret out defects or make sure the software is fit for service. If there are problems, development needs to fix them, and then the testing process begins again. Do you see the problem with this cycle?

An alternative to the usual testing process is continuous testing, such as Test-Driven Development (TDD). TDD is not a new concept; it has been around since 2003, but it is still rarely used. The process is straightforward:

  1. Write a test for a single item under development.
  2. Run the test, which will fail.
  3. Write the code to enable the test to pass.
  4. Re-run the test.
  5. Improve the code and retest.

What is the point of this process? At first glance, it may appear that it would make the testing process more complicated, not less. However, it ensures that the testing process is continuous throughout the project. This means that testing is preventing defects rather than finding and repairing them after the fact, thus improving the quality of the final project. TDD provides a suite of tests for the software, almost as a side effect. The tests themselves, when well structured, can effectively provide documentation, as they show what a piece of code is intended to do. Finally, when combined with the user or product owner’s input, the process can be used to perform acceptance testing ahead of the coding, a process known as Acceptance Test-Driven Development, which can help to develop and refine requirements.

Each of these items will ultimately need to be done, regardless of whether they are a part of the traditional testing and re-coding process. TDD allows them to be done in a manner that reduces the number of times steps need to be repeated. Does your organization use TDD? Leave a comment and share your thoughts!

James Jandebeur

Written by James Jandebeur at 05:00

Test Driven Development: An Overview

TomTest Driven Development (TDD) is an approach to development in which you write a test that proves the piece of work you are working on, and then you write the code required to pass the test. You then refactor that code to eliminate any duplication and overlap, and then you repeat this process until all of the work is completed.

Philosophically, Agile practitioners see TDD as a tool either to improve requirements and design (specification) or to improve the quality of the code. This is similar to the distinction between verification (Are you doing the right thing?) and validation (Are you doing the thing right?).

Here's the basic TDD flow:

  1. The developer accepts a unit of work and immediately writes a set of tests that will prove that the unit of work actually functions correctly. In some organizations, the test cases that are written are unit and functional tests (focused on code quality), while in others, the test cases are acceptance test cases (focused on specifications/requirements). There are a few rare organizations that create both levels, and this might be a best practice. Think about using the Three Amigos Technique to develop robust test cases.
  2. Now, you run the tests. The tests should fail because the code to solve the business problem embedded in the unit of work has not been written. If the tests pass, rewrite them. (I would check to make sure that no one else has solved the problem and failed to tell you – this would be a communication and configuration problem.)
  3. Write the code needed to solve the problem - and write just enough code to solve the problem.
  4. Run the test suite again. This time, the test should pass based on the solution created in step three. If one or more tests don’t pass, return to step three and correct the code. Repeat steps three and four until all tests pass.
  5. Refactor the code and design to make the design as simple as possible and to remove any possible duplication.

Now, you repeat these steps until all of the work is complete for the iteration.

Test Driven Development is an extension of test-first development (TFD), in which developers will not write a single line of code until they have created the test cases needed to prove that that unit of work solves the business problem and is technically correct. TDD extends TFD by adding the final step to refactor the design and code to avoid duplication and to promote simplicity.

The concept of TDD turns classic software development concepts on its head. Classic approaches begin with the assumption of a known design that is, at the very least, sufficient, and that the developers will create code first and test afterwards. TDD assumes that the design will be refactored based on what is discovered during development and that development will not begin until the tests have been developed.

Make sense? If not, feel free to leave a question for me in the comments (or on Twitter, I'm @TCagley)!


Tom Cagley
Vice President of Consulting
Agile Practice Manager

Written by Tom Cagley at 05:00
Categories :

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!