Event for Test Driven Development in Scrum
Hi,
In Scrum, in what event test cases are written if TDD is being followed?
The recommended best practice of TDD states that new code should only be written if there a failed test case (a very generic summary). So, assuming QA resource being part of the development team (cross functional), is writing test case captured as one of the Sprint Backlog tasks and performed during the Sprint execution? This would also involve a learning curve with the development team getting versed with the test case creation tool. I would assume effort & estimation would include this effort of test case creation as well (seem like an overheard due to the short iteration cycle).
Any thoughts around it? Any real life experience and feedback using TDD would be appreciated.
Do you see more benefits with it and if any, what disadvantages have you experienced using it?
Thanks.
If you're using Test Driven Development with Scrum, you'd write your test cases within the Sprint. There's no particular event for this. Instead, it's the work that happens after the Sprint Planning and before the Sprint Review and Sprint Retrospective. If you're practicing Acceptance Test Driven Development, you may write some of the acceptance tests as part of Product Backlog Refinement, but I don't think I'd consider it a requirement to have all acceptance tests written (especially in the ATDD format) in order to consider the story refined.
Depending on the team's way of working, there may be pairing or mobbing used to write the test cases as well as the deliverable software. There are specific techniques where one or some of the team is focused on the test cases while one or a different part of the team is focused on the implementation to satisfy those test cases. However, these are details best left up to the team to experiment with and work out.
In my experiences, you'd build the effort to learn the tools and write the test cases in any kind of estimation that you apply to the Product Backlog Items. Until you learn the tools and the team becomes proficient at creating and managing test cases, you can't complete as much work in the timebox. A skilled team would give a smaller estimate for the same Product Backlog Item as an unskilled team.
I'd also suggest moving away from terms like "QA resource". They are people with individual backgrounds, experiences, skillsets, and knowledge. Treating them as resources can be dehumanizing. It makes people seem interchangeable, even though they are not.
Thanks Thomas. Have you experienced any disadvantages of using TDD over not using it?
is writing test case captured as one of the Sprint Backlog tasks and performed during the Sprint execution?
If work is "ready", it ought to be possible to write any necessary test cases without impediment. The elicitation of acceptance criteria for this purpose may therefore constitute a significant part of Product Backlog refinement.