Subscribe to our blog by signing up for the naked Agility newsletter, or by subscribing to the RSS feed.

You are doing it wrong if you are not using test first

Many teams are struggling with delivering modern software because they are not building with Test First Principals. Test First gives us the assurance that we have built the correct thing, that what we built is what the customer asked for and that when we change things we don’t break anything inadvertently.


While it takes time, effort, dedication and discipline to achieve Test First the return on investment is enormous. A common form of Test First is Test Driven Development (TDD) and we can use it to meet more of our customer’s expectations, minimise our maintenance costs, and get fewer regressions and bugs in production. Ultimately without working in a test first culture, you will be unable to do continuous delivery with any confidence.

The only question for a Professional Development Team is how to get started.

You are doing it wrong if you are not using test first

If you look up Test First on Wikipedia you will be redirected to the Test Driven Development (TDD) page and I believe this to be incorrect. While TDD is one, arguably the most effective, form of Test First it is by no means the whole thing. Can I achieve Test First with no automation at all: Yes. Can I do TDD with no automation at all: No. Do you see my conflict…

If you are building applications without writing your tests first then you are doing it wrong. Your process will result in significant rework, be less maintainable and be less likely to meet the customers needs.Scottish Software Proverb (just made it up, and I am Scottish)

Unfortunately, while the proverb above is absolutely true there are many fanatics that will not accept that you can do test-first without automation. Just like the Process Wars, the Practice Wars are being waged around us, and while we want to endeavour to be agnostic it is not possible to be an atheist.

You will hear a lot of different terms banded about in relations to test first:

  • Test-Driven Development (TDD) – Automated tests created before the code is written to validate that we need that code.
  • Acceptance Test Driven Development (ATDD) – Tests, either automated or manual, that validate business functionality
  • Behaviour Driven Development (BDD) – An automated test that validates a particular behaviour that you want your application to have.
  • etc…

All of these topics, and more, are covered in the Professional Scrum Developer (PSD) training that was build in combination with and Microsoft as the only official team training for Scrum & DevOps.

These terms all fulfil a specific niche and the evolution of modern software development will sprout many more. Find that which solves your specific problem and adapt until you have something that works for you, your team and your organisation.

The essence of test first

Test First has two main goals, both of which are as important as each other.

The first is about professionally validating that which you have built. Software Development is complicated and one can easily create unintended results when that code is executed. This is not a quotient of poor programming but of the complexity of the task. In the eighteen hundreds, plumbers pumped smoke through the pipes to make sure that there were no leaks on the grounds that if it is good enough for the smoke it is good enough for water. This mentality has resulted in what we now call the ‘smoke test’ in software development and the result of its implementation is bugs in production. When compared to software development plumbing is simple; modern software is many times more complex than Software was even 10 years ago. We have accepted poor quality deliverables and expensive maintenance for far too long.

The second goal is to shorten your feedback loops. The closer our engineers are to when the problem was created the quicker they can find it and the cheaper it is to fix. Unfortunately, it is impossible to tell in most software what ‘right’ looks like and developers just take a guess. The attitude that a problem, if it exists, will be caught by Quality Assurance (QA) or User Acceptance Testing (UAT) is unprofessional at best and incompetence at worst. We want to know that what we have just written not only meets our customer’s expectations but also does exactly what we intended for it to do under as many circumstances as we can think of.

Test First allows us to mature from simply testing quality in towards building that quality in from the startJeff Levinson, Architect at Boeing

Fundamentally it is far cheaper to fix an issue closest to its source. The longer we leave the finding of that defect the more expensive it becomes. A bug found in production is 10 times more costly to fix than the same bug found in development.

The three virtues of Test First:

  1. Validation of building what was asked for
  2. Validation that what we have built works as we intended
  3. Validation that changes have not broken original intent

Ideally, we want our tests to be as close to the code as possible, but also as easily understood by the customer as possible. Ideally, all of our code is automated and we have an executable specification. It’s a balancing act…

Business Validation – We have built what was asked for

Getting validation that we are building the right thing is key to actually being able to build the right thing. This sounds like a no-brainer but what do we usually do?

Well, we usually take our requirements, in whatever form we generally make them, and give them to our coders to turn into working software. Quite separately we give the same requirements to our testers and they create a bunch of tests to validate what we have built.

Did you notice the problem with this workflow?

The worst that can happen is that we built exactly what the customer asked for!

How can we ever build to meet the measure if we don’t build to what is to be measured? We need to flip that on its head and instead have the tests created first (the measure) and then Code to make the tests pass. Now that we have removed the inevitable time-consuming rework we can take that time and use it to create even more value for our customers.

In addition, we are far more likely to be able to meet our customers expectations now we have an additional level of focus provided by those tests.

Developer Validation – What we have built works as we intended

Its now 2017 and gone are the cowboy days of the late nineties and early naughties. Along with using modern source control, software engineers can no longer hide behind their management as “not giving the approval to do Unit Testing”, or changing what “unit testing” means to allow them to bypass the requirement. This is about professionalism and all developers, no matter what they are working on, should be validating the work that they do.

You are not a professional if you do not do the due diligence necessary to validate what you have created works as intended and continuous to do so.
Professional Scrum teams build software that works

There are two main value-adds here. The first is that when a coder creates functionality it does exactly what he intended and we have a record, and executable specification, of what that intent was. The second comes later. When we go to add functionality later we know when we have broken existing functionality and that is one of the most valuable parts of this endeavour.

Can you imagine how amazing it would be if you could use this executable specification to validate all future changes don’t break your application?



These resources should help you start down a journey to building better applications:

Who is naked Agility Limited – Martin Hinshelwood

Martin Hinshelwood is the Founder/CEO of naked Agility Limited and has been their Principal Consultant and Trainer on DevOps & Agility for four years. Martin is a Professional Scrum Trainer, Microsoft MVP: Visual Studio and Development Technologies, and has been Consulting, Coaching, and Training in DevOps & Agility with Visual Studio, Azure, Team Services, and Scrum since 2010 and has been delivering software since 2000.
Martin is available for private consulting and training worldwide and has many public classes across the globe.

  • Pingback: You are doing it wrong if you are not using tes...()

  • Well thought out blog post. You missed one key reason it’s wrong to not develop software test first. There is no way to deliver software faster than test first, other than to never execute the code you write. Once you accept you need to execute the code you write, this means every usage interaction, every form submission that is done manually is effort that has become lost the moment it’s over. With test first, all work that is spent in arranging and validating test scenarios is continuously carried forward instead of lost with every push of F5.

    • Zephan Schroeder

      Along the same lines, once you develop a solution in code you have a natural bias to accept it as correct (even if there are differences or omissions in the solution vs. requirement). By writing tests first you clarify the understanding of the requirements before you invest any effort or ego into the solution.

  • Pingback: You are doing it wrong if you are not using test first | PowerStory Blog()

  • Pingback: A better way than staggered iterations for delivery()

  • Pingback: Igor Abade (T-Shooter) | Porque você definitivamente precisa de testes de unidade()

  • 4johnny

    In general, I agree with your posts. And I am certainly glad to see another vocal champion of executable specifications.

    “Validation that what we have built works as we intended…. Developer Validation – What we have built works as we intended”… Etc

    Nitpick (orthogonal to Test First): For that, I use “verification” to distinguish from “validation”. Verification is “building things right”; validation is “building right things”. To me, verification is to validation as precision is to accuracy.

    • I did an update of this post and I included the distinction that you mentioned. I just missed that on the original pass 🙂 thanks.

  • Pingback: A better way than staggered iterations for delivery()

  • Pingback: The fallacy of the rejected backlog item()