Generate Test From Work Item

Jun 24, 2010 at 10:09 AM

I'm considering writing a plugin for VS that can generate a test from the description field in a work item.

That way it could be possible to write the user stories directly into the work item (as many, including myself, already are used to doing), but in a format recognizable by the StoryQ Converter. Then, once you are assigned the task, you can very easily generate the test, and get coding.

This would require an API for the StoryQ Converter to be exposed though. Another approch would be to create a new converter that can convert the "As a <type of user> I want <some goal> so that <some reason>" template to StoryQ tests.

What do you think?

Jun 24, 2010 at 2:25 PM
I have been threatening to do this (and not following through) for a year. I would love to see this happen.

David Starr
guild3.com | pluralsight.com | elegantcode.com



On Thu, Jun 24, 2010 at 4:09 AM, jegholm <notifications@codeplex.com> wrote:

From: jegholm

I'm considering writing a plugin for VS that can generate a test from the description field in a work item.

That way it could be possible to write the user stories directly into the work item (as many, including myself, already are used to doing), but in a format recognizable by the StoryQ Converter. Then, once you are assigned the task, you can very easily generate the test, and get coding.

This would require an API for the StoryQ Converter to be exposed though. Another approch would be to create a new converter that can convert the "As a <type of user> I want <some goal> so that <some reason>" template to StoryQ tests.

What do you think?

Read the full discussion online.

To add a post to this discussion, reply to this email (storyq@discussions.codeplex.com)

To start a new discussion for this project, email storyq@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Jun 24, 2010 at 8:44 PM

My biggest concern with automating such a procedure is that you're taking away the human interaction, which is basically the essence of BDD (see the first paragraph at http://en.wikipedia.org/wiki/Behavior_Driven_Development)

When we start writing a story, we are sitting with our user/client/customer/BA. It's a conversation. As we go through each step, the developer's busy eliciting requirements, but also thinking about step reuse. They might figure out that two completely different sounding steps can actually be refactored/reworded into a single, parameterised, reusable step. At the same time, when they do that, they'll be checking with their subject matter expert (SME) as to whether or not it really does make sense. They might type a "$" into the StoryQ converter, to make a word into a parameter, and the SME might ask why there's currency in their sentence, but because they're working together, the conversation is totally productive.

If you are in fact collaborating as you enter your workitems into TFS, then I suppose it's ok to automate the creation of StoryQ tests from those, but I'd be very worried that you're missing opportunities to review the stories for reuse (which requires developer attention) or functional clarification / changing of mind (which requires SME attention).

I'd strongly enourage you to go and read these notes http://picasaweb.google.co.uk/chris.matts/FeatureInjection (I think the fact that it's photos of a notebook kinda charming), and then come back here and argue with me :D. I fully recognise that everyone's situation is different, so I'm not saying no!

 

P.S. why would the "as a/i want/so that" dialect help?

Jun 24, 2010 at 10:03 PM
I don't think anyone is proposing to take away the human interaction. The idea is simply to record that interaction in a way that may generate executable specifications. Stories tell us a conversation needs to take place and the Scenarios record that conversation. The fact that it gets recorded in a work item is almost irrelevant. It isn't different than using the StoryQ WPF tool.

David Starr
guild3.com | pluralsight.com | elegantcode.com



On Thu, Jun 24, 2010 at 2:44 PM, robfe <notifications@codeplex.com> wrote:

From: robfe

My biggest concern with automating such a procedure is that you're taking away the human interaction, which is basically the essence of BDD (see the first paragraph at http://en.wikipedia.org/wiki/Behavior_Driven_Development)

When we start writing a story, we are sitting with our user/client/customer/BA. It's a conversation. As we go through each step, the developer's busy eliciting requirements, but also thinking about step reuse. They might figure out that two completely different sounding steps can actually be refactored/reworded into a single, parameterised, reusable step. At the same time, when they do that, they'll be checking with their subject matter expert (SME) as to whether or not it really does make sense. They might type a "$" into the StoryQ converter, to make a word into a parameter, and the SME might ask why there's currency in their sentence, but because they're working together, the conversation is totally productive.

If you are in fact collaborating as you enter your workitems into TFS, then I suppose it's ok to automate the creation of StoryQ tests from those, but I'd be very worried that you're missing opportunities to review the stories for reuse (which requires developer attention) or functional clarification / changing of mind (which requires SME attention).

I'd strongly enourage you to go and read these notes http://picasaweb.google.co.uk/chris.matts/FeatureInjection (I think the fact that it's photos of a notebook kinda charming), and then come back here and argue with me :D. I fully recognise that everyone's situation is different, so I'm not saying no!

 

P.S. why would the "as a/i want/so that" dialect help?

Read the full discussion online.

To add a post to this discussion, reply to this email (storyq@discussions.codeplex.com)

To start a new discussion for this project, email storyq@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Jun 25, 2010 at 7:26 AM
Edited Jun 25, 2010 at 7:32 AM

Instead of considering the scenarios of other developers, I will instead try to clarify how this functionality will help ME in MY development procedure.

When I gather requirements, I tend to write them down on a piece of paper, word document, mind map or whatever is appropriate at the time. This is all done while the customer is present, so we are able to discuss things back and forth. At the end of the meeting we make a rough ROI analysis of each feature. When back at the office the next day, I create user story work items in TFS using the MSF for Agile Software Development v5.0 template, whose user story defaults to ”As a <type of user> I want <some goal> so that <some reason>".

Then I assign the user stories with the highest ROI to iteration (or sprint) and implementation is commenced. When I open the first user story, I validate the user story (and make changes if needed), and manually convert it into a test (this is when the add-in will help me).

Because iterations are small 14 days, and the collaboration with the customer is very close, the developers come very close to being the SMEs, and if in doubt the customer will be contacted for verification, or the user story will be replaced by another and postponed to the next iteration.

Whether I will want use parameters in my user stories later on or not, I don't know, time will show. First off I would only like to be able to create a basic test from "As a <type of user> I want <some goal> so that <some reason>". This can easily be done without the StoryQ Converter, but it could be interesting to see if the converter could assist further in providing the possibility to define the full test in the work item.

Jun 25, 2010 at 11:28 AM

This is the point where I see that the grammar in "as a/i want/so that" doesn't cohere directly with "inorderto/asa/iwant", I prefer the latter dialect, so I'll give up the thinking about implementing anything regarding the first one.

I'm probably better off anyway, because it seems easier for me to formulate my stories much with StoryQ, I don't really know why :)

PS. Rob, as you mention, we might end up with writing user stories directly into TFS in the future as we are bringing workplace more and more online. I just have a thing for paper and whiteboards sometimes.

Coordinator
Jun 25, 2010 at 6:36 PM
DaddyStarr wrote:
I don't think anyone is proposing to take away the human interaction. The idea is simply to record that interaction in a way that may generate executable specifications. Stories tell us a conversation needs to take place and the Scenarios record that conversation. The fact that it gets recorded in a work item is almost irrelevant. It isn't different than using the StoryQ WPF tool.

Hmm - I guess my experience of using the WPF tool has been quite interactive. I do my introducing parameters and doing my developer-hat & user-hat thinking at that point.

 

Coordinator
Jun 25, 2010 at 6:45 PM
jegholm wrote:

This is the point where I see that the grammar in "as a/i want/so that" doesn't cohere directly with "inorderto/asa/iwant", I prefer the latter dialect, so I'll give up the thinking about implementing anything regarding the first one.

I'm probably better off anyway, because it seems easier for me to formulate my stories much with StoryQ, I don't really know why :)

PS. Rob, as you mention, we might end up with writing user stories directly into TFS in the future as we are bringing workplace more and more online. I just have a thing for paper and whiteboards sometimes.

I also prefer the "In order to/As a/I want" syntax. StoryQ has evolved to exclusively target "stakeholder stories" rather than "user stories" (http://codebetter.com/blogs/ian_cooper/archive/2010/06/15/bdd-feature-injection-and-the-whirlpool.aspx). David - that's the distinction that I think you were calling "gherkin"?

I noticed your tweet saying that your plugin was in beta - did you end up pulling in the storyq code to make the changes yourself? Looking forward to seeing it...

I didn't mean to suggest that you should enter stories directly into TFS - i thought that's what you were doing? 

 

Jun 26, 2010 at 9:52 AM

Now I understand why it's easier to use the "stakeholder" stories, it's because my meetings are usually with the stakeholders, not directly with the users. And sometimes, I am also the stakeholder, as we, in addition to provide services, also build products in-house.

No I didn't draw any generator code from StoryQ as of yet, but I might later on, if you don't mind.

The plugin is not published on CodePlex under StoryT, partially in tribute, but also because it currently only supports StoryQ, but I have prepared it for other story templates if the need should arise.

I would love to get feedback from anyone trying it out.