Role of Tester in Test Driven Development (TDD)

Role of Tester in Test Driven Development (TDD)

Many people consider Test-Driven Development (TDD) as a method for programmers to write code that is easy to read and maintain. 

But is that all there is to it? And where do testers come in in this cycle?

This blog is for testers who believe TDD is not relevant to them. 

We'll explore what TDD means, how testers can help, and why understanding TDD can help you test better, collaborate better with developers, and grow in your test development job responsibilities.

What is Test Driven Development?

Kent Beck developed test-driven development (TDD) as part of Extreme Programming in the late 1990s. This technique to build software follows three relatively 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 units of code, what agile tester roles and responsibilities are involved in this, and what do testers stand for?

Tester Roles And Responsibilities In Agile

In Agile, testers are involved from the very beginning, not just at the end when the product is "ready to test." 

Tester Roles and Responsibilities in Agile is more about working together all the time. Testers help ensure high quality by working closely with developers, product owners, and the rest of the team during the sprint cycle.

1. Understanding requirements early

Testers help plan sprints and improve the backlog. By asking the right questions, they help clarify user stories and acceptance criteria. This ensures that the team doesn't miss any important information or misinterpret the user's needs.

2. Thinking from a user’s perspective

When developers think about how something works, testers think about how it might not work. They consider how real people will use the product, identify edge cases, and raise usability issues that may not be immediately apparent.

3. Designing test scenarios before development starts

Agile testers don't wait for the code to be done. They start making test cases and getting test data ready early on. This method helps the team find holes in their logic and get ready for both expected and unexpected behaviors.

4. Supporting test automation

Testers and developers work together to create and keep up with automated tests. They help figure out which tests should be automated and which should stay manual, especially when there are a lot of regressions or complicated workflows.

5. Collaborating continuously

Agile testing is a practice that everyone on the team participates in. As developers build new features, testers often work with them to test these features. They provide feedback in real-time and help resolve issues before they escalate.

6. Testing throughout the sprint

Agile testers don't wait until the end of the project to test; they do it all the time. They do bug verification, functional testing, regression testing, and exploratory testing all in the same sprint.

TDD from a Tester's Perspective

Sad to say, but even in today’s agile software development environment, most of the testers I've met don’t know what TDD is, probably because their development team doesn’t practice this technique firsthand (a common complaint is that it consumes a lot of programmers’ 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 these three bullet points, and it’s OK because they don’t know how they can add value towards a technique that is predominantly programmer-driven. 

That Mightier question remains unanswered. 

A great tester answers it like - The funny thing with TDD is the unfortunate name itself, which creates a misconception that it’s attributed to testing. 

TDD is not testing, but it provides us with some incredible artefacts that are very useful and provide excellent support in testing. 

TDD is primarily about the design of the code. The TDD cycle (red, green, refactor) helps programmers get faster feedback, allowing them to make informed decisions about the code's design.

Understanding how these artifacts evolve can significantly improve a tester’s ability to contribute effectively and grow in their tester responsibilities in Scrum team environments.

TDD Cycle and Tester’s Focus

Now, from the above image (source- James Shore), at least one thing is clear: adding a failing test is NOT the first step in the TDD cycle; instead, it starts with thinking about what the failing test should look like.

Tester’s Role in Every Phase of TDD

In TDD, the tester's role extends beyond traditional testing to active participation in requirements definition and collaborative test design before coding begins. 

Testers collaborate with developers to identify edge cases, define acceptance criteria, and create tests that serve as a guide and documentation for the code. 

Test-Driven Development (TDD) may seem like a practice reserved for developers, but testers can play a crucial role at every stage. 

When you hire test-driven development experts, you're not just hiring coders; you're hiring collaborators in quality. 

Let's examine how testers can contribute to each step of the TDD cycle.

Phase 1: Write a failing test

So what is the need to write something in the 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. 

Testers can start thinking about test ideas, identify the edge cases for that feature, and start developing test scenarios for check automation purposes.

Phase 2: Write enough code to make the test pass

Here, based on the feedback programmers get while writing failed unit tests, he/she is going to add just enough code to make the failing test pass. 

Run your tests again, and see if all the tests pass. At this phase Tester basically can try some of the edge cases he/she developed earlier and mix it with Mutation testing 

Phase 3: Refactor

“She Improves, I Explore”

So, programmers are busy improving code quality, while testers continue their test exploration journey. 

Testers can pair up with a programmer to identify already existing tests, the programmer's pain area while he is refactoring the code and tests, so that the tester can visualize a larger picture of his/her testing activity and identify the impact on other areas as well. 

Based on the pairing session, the tester can design their test chartering activities for ET sessions. 

Programmers and testers can also review testability, test coverage in the refactoring stage to ensure that it still holds as effective and efficient as it was earlier to refactoring.

Test Driven Development vs Agile

Many teams ask, "Is TDD the same as Agile?"

No, Agile is a general approach to managing projects, while Test-Driven Development (TDD) is a specific coding technique that supports Agile delivery.

Agile helps teams make software that works in short, repeating cycles with constant feedback. 

TDD, on the other hand, is all about writing tests before writing code. This ensures that every feature is built with code that is clean, testable, and reliable from the outset.

In short, Agile is the "how" of getting things done. TDD is the way to write good code.

They make each other stronger when used together. Agile makes things faster and more flexible. TDD gives you faith in every line of code.

Learning both doesn’t just make you a better tester, it broadens your test development job responsibilities and adds long-term value to your career.

Final Thoughts

TDD isn't just for developers. People who care about quality all do it, and it helps everyone. 

Testers who know how TDD works and how to make a real difference during its phases are very helpful to Agile teams.

Instead of waiting for the code to come to you, join the conversation earlier, even before the test is written. That's where real teamwork begins.