Why everyone on the team needs to have a TDD mindset

A software product is ever-evolving, ever-changing, and fluid. Features are continually being added, modified, or removed.

Developers are always adding new libraries and refactoring code as well.

More importantly, the members of the team are constantly changing, including developers, QAs, business analysts, product owners, etc.

Test-driven development(TDD) is used to create code that is verified and self-documented. Anyone who looks at the test suite of a particular feature should be able to understand how the feature is supposed to work, what are the edge case scenarios, and who is the end consumer of this feature.

TDD as a part of the team lingo

Tests are a universal language between team members to communicate ideas.

Notice I said team members and not just developers. I believe that all team members of a software team need to be thinking about the test suite always.

Any decision that the team makes, regarding any changes in code should be verified by questions like 'Will this test pass?' or 'Does this test make sense now? Do we understand it?' or 'Do we need to change existing tests?'.

TDD mindset while story writing

Thinking about tests is not something that should be thought of by developers when they start writing code for a new story.

Tests should be something that should be considered by a BA while writing a story.

Would this particular acceptance criteria break a test? Would we need to make changes to this test?

What is the test data we would need to create to make this acceptance criterion pass? These are questions that the BA needs to ask while writing a story.

This means that a BA should be comfortable with, and know their way around the test suite. I have seen teams where BAs write the acceptance criteria as functional tests in Selenium. This way, all the developers have to do is run the tests to ensure that the story is done.

This method might not work for all teams, of course, but the point here is awareness of test scenarios, and ownership of the test suite by everyone in the team is essential. It makes everyone think about the long term strategy and effects of the changes made by the team today.

Story kickoffs and test data

Developers need to understand the test data that they will be using to test the acceptance criteria for the story.

This not only ensures that the developers use appropriate data while testing their own story, but it also makes sure that they think about and discuss edge case scenarios.

I also do recommend that before starting a user story, the team has a story kickoff where the BA, developers and the QA come together to discuss the acceptance criteria, and test data to be used as well.

The QA can help with this, and also go through existing tests with the developers to make sure that everyone is on the same page.

Test metrics

In addition to team velocity, burn down rate, cycle time, and other essential parameters, the test metrics are something that the entire team should be aware of and talk about often during team retrospectives, sprint planning meetings, and stand-ups.

Test coverage rate and test gap analytics are important sprint metrics that tell us how well tested the code is, and are there any gaps in testing that the team needs to take care of in the upcoming weeks.

This should not be something that the QA or developers track, but is something that they stakeholders, PMs and BAs should talk about during sprint demos and retrospectives as well.

I hope you have found this post useful.

I would love to hear from you, examples of how your team has embraced the TDD mindset, and how it has impacted your daily life.