Test Driven Development (TDD) is not a Quality Control Strategy

Categories: Software Testing |

TDD (test driven development) is not a Quality Control Strategy. It is but a programming methodology that might be considered as a part of a Quality Control Strategy and in turn part of a Quality Management Strategy. Frequently projects with “Developers Driven Project Management” are likely to consider their software projects as having full quality control and quality assurance covered, just because they practice TDD.

We will describe the most important aspects of TDD and even without saying anything negative about TDD it will become clear that the TDD methodology was never intended to cover a complete QC strategy and in fact, it doesn’t.

Test First or Test Driven Development

Test first is the leading and most influential practice of XP methodology. The key characteristic of TF is that programmers write tests before writing business or feature logic, so failing tests must exist prior to the logic that makes them pass.

TDD is a programming methodology that can give you the following benefits:

  • Provides instant feedback on impacts to previously implemented and working functionality; in that sense provides built – in regression testing.
  • Avoid unnecessary code, stimulating the developers to code just enough code to make the tests pass.
  • Encourages developers to dissect the problem into small, manageable programming tasks to maintain focus.
  • Maintaining up-to-date tests gives courage to refactor mercilessly in order to keep the design simple and to avoid needless clutter and complexity.
  • Up-to-date and frequently run tests written for any piece of the production code that could possibly break help to ensure a certain level of quality and an acceptable level of test coverage as a side effect.
  • Tests provide the context for the making of low-level design decisions.
  • Tests are also perceived as another form of communication and documentation.

The obvious cost is that unit tests are automated tests and like any other testing automation will generate a dependency with the system, every change to the code requires changes to the tests or the other way around in the case of TDD; so complex changes might demand more time to make the tests remain valid and useful. Of course there is also a related increase of the code quality and consequently an increase of the product quality, but the quality of the code does not have a 1:1 relationship with the product quality. You can have a 100% of coverage of the code base with unit tests and still have defects in your product.

TDD can help you reduce the defect rate, but it increases development time. Depending on the project you may find that the balance of decreasing the defect finding time vs. increasing the developing time is positive or negative. I tend to think that it is more prone to be positive, because defect fixing is cheaper in early stages and the code is more likely to be simpler.

TDD covers just a part of quality control

Test Driven Development (TDD) is not a Quality Control Strategy

Software quality management manages the quality of software and it defines processes, process owners, and requirements for those processes, measurements of the process and its outputs, and feedback channels. Includes SQA (software quality assurance), SQC (software quality control).

Quality Assurance is a major activity that establishes and evaluates the processes that produce products.

Quality Control is related to product quality assurance, so testing is a QC activity.

Like it was previously said TDD influences the software product quality, but it only takes care of unit testing and this is just a part of a quality control strategy. Unit testing boundaries are the classes´ methods, as well as other rules like “Isolated from other code”. The rules and the boundaries keep the developer focused on the purpose of unit testing, but this is also the reason why TDD tends to only cover the lower abstraction level of the product. Of course within the context of this abstraction level the tests might have different purposes, like functional or performance, among others covering different purposes.

Basically a well-defined QC plan should guaranty testing coverage across the different software product abstraction levels and coverage of different types of testing, strategies and techniques.

Testing the higher integration levels is more effective finding defects because it includes all the system layers. As a counterpart early defect detection, like TDD, makes defect fixing cheaper and moreover the combination of both allows you to diagnose the problem faster, transforming the QC strategy into a more efficient one.

The cost of not having a QA team

Often the projects use their developers to perform QA tasks, we can agree that developers are the most appropriate persons to write unit test and even more when they are involved in TDD practice, but if you use your developers to perform the rest of the QA tasks like UI test automation, write manual test cases, manual functional testing, functional exploratory testing among others you’ll be losing money in at least two senses:

–        QA engineers and Testers are cheaper than Developers.

–        Developers are not focused in the task that gives more value to the business, product functional increments.

The perspective of the different roles

Development and quality assurance are fundamentally different disciplines.

The success of testers is finding defects and to take care about quality in general. Testers are focused in the client perspective as a user; they test the product not only with validation but also with verification.

Verification answers the question, “Did we build the right system?”

Validation answers the question, “Did we build the system right?”

Developers are focused in technical solutions and in the technical capabilities of the code they produce. I had situations where developers were assigned to automate UI tests and they were more interested in adding code to the tests that allowed the scripts to dynamically adapt to different configurations, and thus making the test pass, no matter what had changed, than testing the different scenarios.

Conclusions

TDD is nothing more than a programming practice and might help you improve the code quality, but a software quality strategy or even just a quality control strategy is much more than unit tests or test first practice.

Don’t try to find a unique and all powerful methodology or practice; it is a combination of good practices like TDD and methodologies what will give you success.

Ultimately a software project direction requires a wide vision and the methodology adaptations should be subjected to metric results based evaluations.

Leave a comment