great thread this one. I’m just curious about QA’s role in this scenario you depicted.

User stories changes the system, automated acceptance tests are written so that sprint progress could be monitored (cards move if acc tests go green, cards move back if acc tests go red). I suppose underlying code is crafted by TDD, so there is a suite of unit tests.

And then “(..) QA people accept a story to be tested they take ownership of the acceptance tests and merge them into their system tests.”

So, QA team is working along side with dev team, producing automated system tests? Or this system tests are manual (even if partially)?

Let’s suppose you are in 4th iteration. What’s run on build machine? Unit testing of entire code, acc tests written for this 4th iteration and *all system test ever written* (kind of a regression)?

Regards,

Camilo.

In his new blog post[1], Fowler exposes a scenario with this “new” approach to acceptance tests:

“Each time they play a new story, they decide how to update this suite to reflect the new behavior. This breaks the simple story-to-test relationship, but results in a much simpler and coherent suite of tests.”

The project he describes has a not so common set of characteristics, but maybe it is a nice approach for a broader range of project.

[1] http://martinfowler.com/bliki/NashvilleProject.html

By that I pretty much mean “what a system do”. As the text states that user stories are change on a system, I guess it is quite clear that they are *related* to what a system does but they do not *define* those by themselves. As the text says that’s one difference between use cases and stories -use cases define what a system does, user stories define a piece of change. I think that Dan’s comparison with code changes in the first comment make make my point clearer.

I couldn’t really understand the context of your second comment. Issue trackers are great tools but I don’t understand how they’d fit in this text.

But problems are different and has different priorities too, the login example was perfect to show how bug tracking systems can also be useful tools.

I like the idea of Use Cases DSL, shouldn’t be hard to implement but I don’t work with use cases for a long time now.

About the other suggestions, I still find use cases too technical and complex to be efficient. If experienced software developers after years studying the field can’t understand those properly let alone the poor business person.

Also, I’m not sure what you mean by “Forget about Acc. Test based on Stories”. If you have stories but don’t test them I can’t see how you would accept their implementation. I guess what you are describing is pretty much what Fabricio said some comments ago and I’d point out the same arguments against it as before.

cheers

Maybe we need a Use Case BDD runner based on scenarios. I guess that we still need to automate acceptance tests but stories aren’t whe best choice because stories are too small (BDD on stories, story runner). Just something for us to think about:

1. A DSL for Use Cases (pre-post conditions, valid scenarios, etc…)
2. A DSL for Data/Object representation
3. Merge (1) and (2) to turn (1) executable (scenario runner?)
4. Forget about Acc. Test based on Stories (stories are just change requests to executable Use Cases)
5. Use Case training for every “agilists” we know…

Too complex?

Cheeeers!

In my project when a bug is found by a test, we try to isolate that test so it does not compromise the whole functionality being tested. After the bug is corrected, the test is merged. It’s not the best scenario, I know, but I think that it is best then writing acceptance test in isolation and then merging them is system tests. In any case, we have only 6 developers on the project. If we had 20, maybe this strategy would not be valid.