2

We have sprints of 4 weeks duration. What I have been doing is 3 weeks dev time and 1 week of pure manual/automated testing, stabilization and shipment assurance testing.

How to manage TDD within dev time? In my previous experience writing tests and getting 80% coverage requires round about 50% of the development time. Following the same we would get only 1 and a half week of development which is not enough.

My actual problem is how to allocate time for TDD? I want to make TDD a mandatory but with these it becomes really difficult for me. Do you think this is correct approach we are using or are we missing something and alter our approach to Scrum?

gnat
  • 21,442
  • 29
  • 112
  • 288
Haris
  • 137
  • 1

5 Answers5

10

The idea behind TDD is that creating the tests is part of the development. You shouldn't really calculate it as development + unit test, the better way to view it is development = functionality + unit tests, where creating the unit tests is not a separate activity. While your developers are working on the functionality, they are also creating the unit tests.

Likewise your task board shouldn't have a separate task for "Create Unit Tests" - the unit tests should be implemented alongside the functionality, there really shouldn't be any separation.

It shouldn't be like 1.5 weeks of development and then 1.5 weeks of unit tests. Instead, you want to have 3 weeks of development and end up with the functionality in a fully tested state. If your Definition of Done specifies that every piece of functionality is unit tested, then there really shouldn't be any separation between getting the functionality implemented and the unit tests done.

As for your other question regarding the integration of QA: We have QA resources as part of the team, testing each feature as it becomes available, with a daily (or nightly) full regression test. If a feature's implementation is done on day 3 of the Sprint, our QA will start testing it on this day - ideally they have developed the test scripts at the same time as the developer implemented the feature.

Both need to work hand in hand and with a lot of collaboration. There's lots of communication between the developers and QA in the team. "Hey, feature A is now ready, you can start testing it." and "I found the following issue in my test for feature B, can you please fix this?" We have this back and forth all the time during the Sprint, with the goal that everything is tested and working at the end.

Combine that with a full regression test run every night, where the results are published, and you can pretty much develop up to the last day of the Sprint. Testing should happen at all stages of the Sprint, not just the last couple of days.

nwinkler
  • 211
  • 1
  • 4
6

First I need to mention that 3 weeks of development and 1 week of testing is not Scrum, but instead time-boxed waterfall. As the core philosophy in scrum is continual inspection and adaptation, I would strongly recommend looking at the interaction between programmers and testers and coaching them to work incrementally.

The correct Scrum answer will be "Ask the team" as this is what self organization, inspection and adaptation is about. The problem they need to solve is how a programmer can write a small bit of code with a maximum of 1/2 day and give something to a tester to test. This does not mean the feature has to be complete, but just incrementally added to source control and testable by a tester.

TDD is a good approach to look at as this will encourage programmers to think of how it is going to be tested, before coding and then doing the minimum to get the tests to pass.

Brett Maytom PST
  • 191
  • 2
2

The idea behind TDD is that, while it consumes time itself, it reduces time required in other areas. You should be writing your code faster, and not spending as much time on bug-fixing and manual testing, so you can reduce these aspects accordingly.

Therefore, your statement (emphasis mine):

Following the same we would get only [x time for] development which is not enough.

is not necessarily true.

Whether this is what you acheive in practice is up to you to determine, but that's the theory :)

RB.
  • 121
  • 3
1
  • If you are just beginning working in Scrum, 4 weeks is quite a long duration for your sprints. Shorter sprints allow you to fail early and often (not a bad thing) and so by inspection and adapting you can improve your processes a lot quicker. It also allows you to be more reactive to change.

In my previous experience writing tests and getting 80% coverage requires round about 50% of the development time

  • In TDD, development time IS development + unit testing time. You're not getting 2 weeks development + 1 weeks testing, you're getting 3 weeks high quality development. Since such a large percentage of the cost of developing software is maintenance, quality should be of high importance and should be built into both your definition of done, and acceptance criteria for stories.

1 week of pure manual/automated testing, stabilization and shipment assurance testing

  • nwinkler answered this well above, so I won't re-iterate what he's said. What you're doing is essentially mini-waterfall in every sprint! Create stabilization / shipment assurance tasks (or whatever) in your sprint backlog for each story you're testing if necessary. Obviously, if you have tester roles in your organisation, they should be on your scrum team if they are not already
1

I see a couple of problems and improvements here.

  • TDD is not only about coverage and ensuring tests are written, it is actually a design paradigm. Also, if you're TDDing correctly, you're automatically getting 100% coverage. Its a programming methodology. So you should consider it to be part of your coding activity.
  • Slicing your backlogs to optimal sizes is key to getting the right amount of work done in a sprint. If you notice too much work it probably means a big backlog. If the backlog is correctly sized then you are probably estimating more work than can be done in a sprint.
Krishter
  • 111
  • 1