9

I'm getting into scrum and TDD and I think I have some confusion which I'd like to get your feedback about. Let's assume I have a user-story in my backlog, in order for me to start developing it as part of TDD I need to have requirements, right so far?

Is it true to say that the product manager and the QA should be responsible for taking the user-story and breaking it down to acceptance tests?

I think the above is true since the acceptance tests need to be formal, so they can be used as tests, but also human readable so that the product can approve they are the requirements, right?

Is it also true that I later take these acceptance tests and use them as my requirements, i.e. they are a set of use-cases which I implement (through TDD)? I hope I'm not making too much of a mess but that's the current flow I have in mind right now.

Update
I think my initial intentions were unclear so I'll try to rephrase. I want to know more details about the scrum flow of turning a user-story into code while using TDD.
The starting point is obvious, a user surfaces a need (or the user's representative as the product) which is a short 1-2 lines description in the known format and that is added to the product backlog.
When there is a spring planning meeting user-stories are taken from the backlog and assigned to developers.
In order for a developer to write code they need requirements (especially in TDD since the requirements are what the tests are derived from).
When, by whom and to which format are the requirements compiled?
What I had in mind was that the product and QA define the requirements via acceptance tests (I'm thinking of automatic using FitNesse or the sort but that's not the core I think) which help to serve 2 purposes at the same time:

  1. They define "Done" properly.
  2. They give a developer something to derive tests from.

I wasn't sure when these were written (before the sprint they're picked then that might be a waste since additional information will arrive or the story won't be picked, during the iteration then the developer might get stuck waiting for them...)

8
  • 1
    You write tests as you code, acceptance tests are not the tests you write during TDD.
    – CaffGeek
    Nov 23, 2011 at 20:18
  • I know, but I write TDD against some requirements, right? in what form should they come in?
    – Ittai
    Nov 23, 2011 at 20:34
  • 4
    I beg to differ--acceptance tests can certainly drive your development. You can define a series of tests (unit, integration, system, and acceptance) to indicate when an application works and is acceptable. You can then code the application until it passes the tests. That certainly is test-driven development. Nov 23, 2011 at 21:42
  • 1
    @Ittai: I think what Chad is trying to say, is that TDD starts with unit tests, which the developer defines him/herself. As the developer translates the use-case/requirements into lower level code design, s/he is working on one class at a time, and writing unit tests for that class. At that level, it is "ad hoc" because the developer is creating the tests as needed to prove the validity of the code. Nov 25, 2011 at 16:51
  • 1
    "where do I derive the requirements from"? Stories. It's not clear why this isn't sufficient as an answer. Can you explain why stories are magically different from these "requirements" you want to see?
    – S.Lott
    Nov 28, 2011 at 1:19

3 Answers 3

12

Is it true to say that the product manager and the QA should be responsible for taking the user-story and breaking it down to acceptance tests?

Mostly. They may not actually write the actual acceptance test. They may approve something you wrote. But they approve the acceptance tests. Yes.

the acceptance tests need to be formal, so they can be used as tests, but also human readable so that the product can approve they are the requirements, right?

Irrelevant. They may be formalized as automated tests. Or they may be informal and it may be your job to create automated tests from the informal acceptance test criteria.

Also. The "requirements" are the user story. There's no real need to create yet another version of the story called "requirements." Some folks to like to elaborate on the story before they code. You can call this requirements, but "design" is a better word. "Elaboration" is the best word.

Is it also true that I later take these acceptance tests and use them as my requirements, i.e. they are a set of use-cases which I implement (through TDD)?

Yes. The story leads to acceptance tests. The story is required behavior (i.e., "requirements"). The story leads to tests which drive software design and development.

that's the current flow I have in mind right now.

There isn't really a lot of "flow" to this.

Story -> acceptance tests.

Story -> elaboration ("design", "requirements") -> unit tests -> code.

Story -> User being able to do something of value.

Story -> Story points -> velocity calculation.

Note the pattern. The story largely drives everything.


When, by whom and to which format are the requirements compiled?

First. Define "requirements". How are the different from the story itself?

What I had in mind was that the product and QA define the requirements via acceptance tests

Not usually.

during the iteration then the developer might get stuck waiting for them.

Incorrect. The developer can (and often does) help write these. That's the point of "development": elaborate the story to a well-defined "done".

Again. When you have doubts or questions, you must actually read the Agile Manifesto. The Manifesto is quite clear: developers must talk with product owners, users, QA, and everyone else who is a stakeholder. The interaction is actually the most important thing that can happen.

5
  • Thanks, Can you elaborate, ;), a bit more about the Story->elaboration stage? I was under the impression that a story is more of the form of: "I, as user, want to login to the website in order to buy product" This does not include enough details for me to start TDDing against as I need more details, more use-cases. More paths, happy and unhappy.
    – Ittai
    Nov 23, 2011 at 21:45
  • "I need more details, more use-cases. More paths, happy and unhappy." Good. I don't understand what more you need to know about elaboration. You provided a complete description of what needs to happen. What more do you want to know? How to ask for information?
    – S.Lott
    Nov 23, 2011 at 21:53
  • Sort of, What I'm trying to understand is whether at the beginning of the sprint there is only the short user-story and then the developer needs to "dig" the info from the product? Because I was under the impression (maybe mistakenly) that when the sprint begins the developer has a set of requirements which are not done but are 80% (they are derived from a user-story). I'm trying to gather a flow. When does the transformation from a one-liner (of 2 liner) user-story go to a detailed set of specifications.
    – Ittai
    Nov 24, 2011 at 4:38
  • 1. There's no "flow"; no "steps". It's simpler than that. Write tests and code. 2. The source of information depends on your organization. Most organizations hand stories to developers to elaborate. Some will try to do some of the elaboration during grooming at the start of the sprint. 3. Read the Agile Manifesto. agilemanifesto.org. You're expected to interact with the product owner. Deeply. Frequently. The point is for you to gather the data you need so that you can build code to support the story.
    – S.Lott
    Nov 24, 2011 at 10:49
  • 1
    "When does the transformation from a one-liner (of 2 liner) user-story go to a detailed set of specifications". Constantly. If you want to do design, feel free to do design. Some folks write down their design. Some don't. If you like the idea of writing a lot of specifications, that's okay. Don't overdo it. The point is to write tests and code. If a design helps you focus, feel free. Many folks find that writing the tests helps them focus. If you find a need for a large, complex specification document, your story is too complex.
    – S.Lott
    Nov 24, 2011 at 10:53
2

I'm going to answer you from the perspective of Extreme Programming (XP) regarding the acceptance tests.

When I was first getting into (and reading the books), I read that it's really the developer's role to work with the client/user to develop/document the acceptance tests. One of the goals of XP is to increase direct communication between the user/client and the developer. This is often ideal, because it reduces the possibility of coding errors due to miscommunication of the requirements.

I have been doing TDD for about 8 years, and have been following the above approach. I think it has improved the speed of development, and satisfaction with the system because client/users see how they are directly influencing development of the application.

The main difficulty I have run into (with smaller clients), is that it is very hard to get them to participate in specifying acceptance tests. (Usually I have to do it for them, and send it to them for review.) The larger clients I have worked with, have usually had this mindset, so they were prepared to provide specific acceptance tests.

From what I've read of scrum, I'm not sure it defines which role is responsible for defining/writing acceptance tests. I assume it can vary from team to team.

My advice is that, you as a developer, you should participate as much as possible in the test definition process. And the goal is to get the results of the sprint in front of the users as quickly as possible, so they can tell you everything they forgot to think of (or what they incorrectly told you) as quickly as possible.

1

User story is not "As a user I want XXX so that YYY"! User story is promise for future communication with PO. That solves your problem with more details. You must communicate with PO during sprint to get any information you need.

User story also has more features then the short sentence promising the communication. Necessary part of user story are acceptance criteria. Acceptance criteria must be known prior to committing to user story (they should be known prior to estimating user story). Acceptance criteria are the input for acceptance tests = acceptance tests should test acceptance criteria.

So when you start work on user story with TDD approach you (not QA) should first create automated acceptance test based on acceptance criteria to get failing test for it. You will continue with implementing necessary code using TDD before the acceptance test pass. You will continue with next acceptance test. I wrote about that also in another question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.