Test First...... Why?

I'll get straight to the point, why should we think about a test first approach?

With my glass half full hat on I'll ask another question............ why shouldn't we consider a test first approach?

What do I actually mean by test first?

• A common team understanding of what is being asked for by the end user before we start development
• Reflection of what is being asked for by the end user in the form of acceptance tests
• Ensuring the acceptance tests are reflected in any development work completed (this could be unit tests, integration tests, behavioural tests or just developer testing his code manually)

There can be a lot more to test first but for simplicity I'll leave it at that.

I often hear some or all of the following questions/statements from people arguing against a test first approach.

It slows development down!
Does it really? If you consider rework and bug fixing as part of development, is elapsed time really longer or are we losing any time gained at the start by increasing the risk of a rework/bug fix tail?

It's BA's/Product Owners who are responsible for defining what is developed.
Actually it's the BA/Product Owners job to effectively interpret the customer wants or needs into product behaviour. But it's the whole team who are responsible for turning that behaviour into a product experience. If you are unable to represent the required behaviour in tests (Whether that is due to lack of clarity, lack of clarity or something else) how can you possibly know you are building the correct behaviour into the product? I actually believe that there is a lot of cross over between the BA/Product Owner role and the test role in terms of understanding of the system.

We need to know how it is going to be developed/what it looks like to be able to write tests.
Why do you need to know how something is going to be developed in order to write tests. This kind of question leads me to believe you are writing the wrong tests. Don't get me wrong I've worked in teams who get little to no requirements. I've written tests by clicking around the software. Let’s be honest, if as a tester you don't fully understand the expected behaviour before you see the software how can you possibly know whether the software fully reflects the expected behaviour?

So what benefit does test first really give us?
Hopefully I've already answered some points already but I'll give you what I believe to be the most important benefits

• A better quality product as a result of:
• Reduced rework, particularly rework resulting in misunderstanding of expected behaviour. If the developer understands what tests are going to be run against the behaviour of the product there is little excuse for getting it wrong (Human error may still happen but is less likely).
• Better post development testing, as a result of testers spending less time finding, raising and re-testing things that could have been avoided. This time can be invested into really analysing the software and challenging it's boundaries. A greater understanding of what the customer wants allows the tester to make more informed decisions around what testing they feel is most effective.
• More effective development. Developers spending less time trying to understand the requirements allows them to spend more time understanding the best way to develop the requirements.
• Support for the BA/Product Owner - Understanding how we can test behaviour drives out questions, questions drive out answers and answers to questions provide a more complete picture of a requirement/story/change. I prefer stories and requirements that are a little more lightweight and stick to what the customer wants. The questions driven out within the team will then flesh the detail out.
• Lower costs. It's well known that the cost of issues and changes to the product, as you get further through the product delivery, becomes higher. The more issues caught early before or during development, the less likelihood of finding issues later post development (in test, or by the customer) and therefore the lower the cost of the delivery.
• More effective team working. Getting people more involved earlier allows discussions within the team that might otherwise have happened to late or not at all. The inclusive approach that is driven out only helps a team dynamic.
• Behavioural Driven Development (BDD) techniques. Test first supports the aforementioned development approach. Identifying and understanding tests around the expected behaviour of the software allows testers or developers to write a test framework around the code they are developing which gives immediate feedback on where the software is not meeting expected behaviour. The result is greater confidence within the team that the correct product is being developed.

The important thing to remember in all of this is that test first is not supposed to be a rigid approach. It is simply about understanding the behaviours of the products that we want to test for before jumping head first into developing the product. How you go about implementing test first is entirely dependent on your situation and should work with you rather than against you.

I find myself reading this post and worrying that I am slowly losing my sense of humour (If you could call it that).

In light of this overtly direct post I will leave you with a reflective and thought provoking picture: