Role of Tester in Test Driven Development (TDD)

What is Test Driven Development

Test driven development (TDD) was developed by Kent Beck as part of Extreme Programming in late 1990’s. This technique to build software follows three quite simple steps “Repeatedly”–

1. Write a test for the next bit of functionality you want to add.
2. Write the functional code until the test passes.
3. Refactor both new and old code to make it well structured.

Now the question is, since TDD is primarily a Programmer’s tool to help create well-written unit of code, so what role Tester plays in this and what’s testers stand about it?

TDD - Tester’s Point of view

Sad to say but even in today’s agile software development environment most of the tester’s I met they don’t know what is TDD probably because their development team don’t practice this technique at first hand (Normal complain it eat lots of programmer’s time) And some defined it as a three step Process-

1. Write a failing test
2. Write enough code to make the test pass
3. Refactor

Nothing much other than this three bullet points and it’s OK. Because they don’t know how they can add value towards a technique which is predominantly programmer driven. That Mightier question still remains unanswered. A great tester answers it like - The funny thing with TDD is the unfortunate name itself which creates misconception that it’s attributed to testing. TDD is not testing but it provides us some great artefacts which are very useful and provide great support in testing. TDD is primarily about the design of the code. TDD cycle (red, green, refactor) helps Programmers to get faster feedback so that they can make informed decisions about the design of the code.

TDD cycle and Tester’s Focus

Now from above image (source- James Shore) at least one thing is clear that adding a failing test is NOT the first step in TDD cycle instead its start with thinking about what the failing test should looks like.

Now let’s talk about what Tester do and how he/she can add value in TDD cycle.

Write a failing test

So what is need of writing something at first place, which programmers know is going to fail? It’s because it’ll help programmers to look at the feedback of his/her unit tests. While doing so the programmer must clearly understand the feature's specification and requirements. Tester can start thinking about test ideas, identify the edge cases for that feature and start developing test scenarios for check automation purpose.

Write enough code to make the test pass

Here based on feedback programmer get while writing failed unit test, he/she going to add just enough code to make failing test pass. Run your tests again, and see if all the tests pass. At this phase Tester basically can try some of edge cases he/she developed earlier and mix it with Mutation testing (https://en.wikipedia.org/wiki/Mutation_testing).

Refactor

She Improve, I Explore.

So basically programmers are getting busy in improving code quality while tester continues his/her test exploration journey. Testers can paired up with programmer to identify already existing test, programmers pain area while he is refactoring the code and tests so that tester can visualize larger picture of his/her testing activity and identify impact on other areas as well. Based on pairing session tester can design his/her test chartering activities for ET sessions. Programmers and testers can also review testability, test coverage in refactoring stage to ensure that it’s still holds as effective and efficient as it was earlier to refactoring.   Sources- Martin Fowler Blog, James Shore Blog Blogger:- " style="display: inline-block; line-height: 1; vertical-align: bottom; padding: 0px; margin: 0px; text-indent: 0px;">