I have a directory tree organised with stories, where stories are grouped by their functional responsibilities, e.g.
C:\specifications
|
+ myproject
|
|- admin stories
| |- account_management.story
| +- finance_management.story
|
+- customer stories
|- pay_bils.story
+- update_details.story
There are hundreds of features and stories, so it's difficult to get a high level view of the functionality.
Question: Does JBehave enable you to convert the text based stories into a more readable format, such as a HTML document that enables you to drill down into the detail, or zoom back up to just see the feature and story titles?
The jbehave-to-gherkin project can be used to export stories to gherkin format.
After that, the gherkin features can be processed with pickles to create some really nice html output.
Related
What is the best practice for verifying a REST response that contains multiple relevant fields in cucmber/Gherkin? We are using scenario outlines so things are parameterized with examples tables.
Here are some approaches I've considered:
Simplest approach would be to just add each field as a column in the examples table. But this quickly became very unreadable as the examples table overflowed the width of the screen and we ended up with a almost a dozen steps in each scenario of the form: And the <fieldName> should be <value>. This is very verbose and obviously departs from the spirit of Gherkin being intended to resemble natural language.
Next I considered putting the response body as a whole into a file in JSON format and verifying it in a single step like And the response matches <file containing expected response>(examples table would just contain the path to the file). However, this makes it very opaque exactly what I am verifying in the test as the actual fields and data values are hidden away in another file. Furthemore, I've read that test steps should not be concerned with the exact format of the data (JSON, XML, or whatever).
After that I read this article uses a vertical table after the step to specify multiple fields. Resulting in something like this:
And the response contains:
| field1 | value1 |
| field2 | value2 |
However, I was unsure of how to parameterize this. Individual atomic values go into a column in the examples table but what about a whole other table? I looked into whether nested tables are supported but it seems like some people believe that to be unreadable and bad practice as well.
So, what is the general best practice for this scenario? For a parameterized scenario, what approach strikes the best balance between natural-language readability and precisely conveying your expectations?
I am writing a feature that will have scenarios with a parameter in common.
The step would be something like this:
Given the user is viewing the book <bookIdAdress>
When ...
Then ...
Examples:
| bookIdAddress |
| ... |
| ... |
I will have many scenarios like the above in my feature. And I want to test this feature with many books.
This same parameter would repeat for all scenarios of a feature. As far as my current knowledge of BDD is concerned, the only way is to keep putting the same examples in every single scenario. I was wondering if there was an option to have the Examples written once for the entire feature, or if I am completely wrong in doing it this way, what approach should I take?
I know I can use the Background tab to write a set up for the entire feature, but I don't know an option to just put the examples in a feature context only.
You can not share example tables in SpecFlow. I tried by adding the table to the background as a way to hack it but it didn't work.
One option to consider is telling each Scenario to get data from the same excel file. Then you can share a data source as well as hide long tables of data.
http://www.specflow.org/plus/Excel/
I am relatively new to the area and I am trying to solve a classification problem using Rapidminer. I was given a dataset with visits to the doctor and I have to detect readmission cases however since It was originally in a table with some one-to-many relationships I have several lines relative to the same visit for each of the different medicament prescribed.
Example:
Consult_ID| Patient_ID | Medic_ID | MedicamentPrescribed |Readmission
133 | 9893 | 23 | Med_X |YES
133 | 9893 | 23 | Med_Y |YES
The format given is out of my hands unfortunately, so I have to work with it. I want to know if there is any standard solution (maybe contained in Rapidminer itself) to solve a problem like this?
The only way I can think of is creating a new table with the visits, add each possible medicament as a new feature and then indicate if it was prescribed or not but I am not happy with it since it would be an absurdly high number of features (518 distinct medicaments) with NULL fields.
I could also concatenate all the medicament in a single column (Med_X,Med_Y) but I would loose a lot of information in the process since it would consider this new string as it's own medicament.
I have many BDD stories/scenarios (450+ and rising) that I have inherited for an existing system: more info. The stories are organised using file system folders:
C:\specifications
|
+ myproject
|
|- admin stories
| |- account_management.story
| +- finance_management.story
|
+- customer stories
|- pay_bils.story
+- update_details.story
There are so many stories, that trying to understand the functionality from reading the story text files is like trying to understand a system's technical architecture from reading thousands of lines of source code.
I've tried using unix commands to summarise the stories, but this still doesn't help me to navigate the stories. For example, the following command prints out the story file name and the narrative even if the narrative spans multiple lines:
find . -name *.story -exec ls "{}" \; -exec sed -n '/^Narrative/,/^$/p' {} \;
Produces output similar to:
...
./stories/basket/basket.story
Narrative:
In order to buy goods
As a customer
I want to add items to my basket
...
This question is similar to this one, but there are some key differences:
The focus of this question is summarising and navigating stories, not pretty printing.
The need to zooming in and out, from high level to detailed and back.
The navigation will be by anyone needing to understand the stories - not just the business.
I would name each of the files according to the particular capability it provides, then just parse the filenames.
So for instance, you might have:
pay bills.story
update account details.story
add items to basket.story
If you want to be really clever, you can then sort them into folders by the people who can do those things. So when you parse them, you'll end up with:
Admins can:
create new accounts
ban accounts
Finance managers can:
issue reminders
override bills
reissue statements
Customers can:
pay bills
update details
put items into baskets
buy items
That gives you the capabilities without the particular examples that illustrate them, and is a lot less browsing than looking at full narrative text.
I used this project to export my stories to gherkin format, and then processed them using this project to create some really nice html output.
I created a gist to reformat my Gherkin tests. In it, I describe how we lay out our directory structures (which works well for me):
https://gist.github.com/drmikecrowe/a3f8a31f2c7f2de1d078
This set of questions tries to elicit a best practice answer on how to setup TFS 2012 Areas and Iterations with Scrum 2.
Context:
We've been using Team System since TFS 2005 and had initially created a Team Project for each product we have and then used MSF 4.2 process template which we eventually tweaked slightly (only added a few fields to some work item types).
Roll forward to present day and we now run TFS 2012 and VS 2012. Taking into account past experiences and community feedback we will move to a single Team Project and Scrum 2.1 and then use areas to separate products and teams. The following links make good reading for this approach:
http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/
TFS Areas, Optimal Definition and Configuration
Team Foundation Server - Area / Iteration
A typical layout we plan to applying for areas would be along these lines:
-> Team Project (Area root)
|--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
|---> Product A
| |---> Feature Area 1
| |---> Feature Area 2
| |---> Feature Area 3
|
|---> Product B
| |---> Feature Area 1
| |---> Feature Area 2
|
| (ETC)
|--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
|---> Product C
| |---> Feature Area 1
| |---> Feature Area 2
|
| (ETC)
Conceptually we are pretty happy with the above as it is logical to our environment. According to the above we would have teams as follows:
* "Client A Team"
* "Client B Team"
Question 1) We figured that because our teams aren't that big and to make administration more manageable, that we didn't want to define teams per product since we physically have teams per client and they oversee all the products for that client. Is this a mistake, or is this OK?
Question 2) Asuming that the above team configuration is OK, are we then correct to "map" each of the areas above to each team i.e. For team "Client A Team" specify area "Client A" (and all sub-areas) as the areas to be owned by that team. What about the default area, is it ok to set the root of the "Client A" area as the default for the team?
As for the iterations layout we plan for something similar, like this:
-> Team Project (iteration root)
|--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
|---> Product A
| |---> Release 1
| | |---> Sprint 1
| | |---> Sprint 2
| | |---> Sprint 3
| |
| |---> Release 2
| | |---> Sprint 1
| | |---> Sprint 2
| | |---> Sprint 3
| |
| |---> Release 3
|
|---> Product B
| |---> Release 1
| | |---> Sprint 1
| | |---> Sprint 2
| |
| |---> Release 2
| | |---> Sprint 1
| | |---> Sprint 2
|
| (ETC)
|--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
|---> Product C
| |---> Release 1
| | |---> Sprint 1
| | |---> Sprint 2
| |
| |---> Release 2
| | |---> Sprint 1
| | |---> Sprint 2
|
| (ETC)
Question 3) This seems to be trickier to get the iterations right, especially when it comes to TFS showing the backlog. Specifically, for the TFS Scrum 2 Iteration setup, it seems that I should be selecting (check box) only those leaf level iterations that are for planning and subsequent development. So extending the above example, we might have that the "Client A Team" will be available to start work on a new Product B for the next 4 weeks (assume 2 week sprints). Would we then only select (check box) "Sprint 1" and "Sprint 2" from Release 1? Am I understanding/using it correctly?
Question 4) Team Backlog Iteration selection - This might be problematic due to our concept of having teams per client and not teams per product, but maybe I just understand it wrong. In TFS Areas setup, you specify which iterationis the "Backlog iteration for the team". My problem is that our PBI (Product Backlog Items) will be product specific and do not wish to mix them with PBIs from another product. So what I'm unable to understand yet is what the impact will be if we select area "Client A" as the "Backlog iteration for the team" instead of perhaps "Product B". I think I'm confusing myself here - what would be a sensible choice?
The questions above stem my lack of understanding what the impact these selections for iterations, areas, team backlog iterations, and default areas will have for each TFS 2012 team defined. Some issues I'm having with this setup is for TFS to correctly identity the product backlog and sprint backlog for a team.
I don't know whether have one team project and multiple areas for products (as is generally recommended) is complicating the issue.
Question 5) TFS Web Access website - For any given team under "WORK | work items | Shared Queries" there is predefined queries under a folder called "Current Sprint" (Blocked Tasks; Sprint Backlog; etc), but it seems that these queries are hardcoded against "Root Project\Release 1\Sprint 1" - should these not automatically discover which is the current sprint given the dates defined against iterations? If not, then what is the best practice for maintaining these queries?
Do you know of some quality TFS 2012 and Scrum 2 specific training / tutorials that might help address these questions, or give some guidance for a successful Scrum 2 TFS setup?
I hope you found use of my post, and I would also recommend that you take a look at One Team Project to rule them all and TFS vNext: Configuring your project to have a master backlog and sub-teams.
Here is my best effort to answer your questions:
Question 1) We figured that because our teams aren't that big and to make administration more manageable, that we didn't want to define teams per product since we physically have teams per client and they oversee all the products for that client. Is this a mistake, or is this OK?
This is just fine and will allow you to grow as your teams do. If your team members work across multiple Clients you may run into prioritisation and context switching issues that you can minimise by pushing your team up a level, or having a single unified backlog and separate sub teams but still focusing on client work and not product work. I would indeed recommend this approach for the layout that you have.
Question 2) Assuming that the above team configuration is OK, are we then correct to "map" each of the areas above to each team i.e. For team "Client A Team" specify area "Client A" (and all sub-areas) as the areas to be owned by that team. What about the default area, is it ok to set the root of the "Client A" area as the default for the team?
That is indeed correct and should result in all of your work items being created when that team is selected with those defaults. Many organisations also create a parent or master backlog where misc items are created, ordered and then divided up into the appropriate team backlog as Greg Boer, Product Owner for the TFS Agile Planning Tools blogged about in his post TFS vNext: Configuring your project to have a master backlog and sub-teams.
You layout for iterations is indeed looking good as long as your Teams don’t cross the boundary between clients or you will start getting into difficultly mapping Areas and Iterations to Teams. If you think that you may need to have a single Team or group of teams map to more than one client then you may need something more like:
-> Team Project (Iteration root)
|—> Team Boundary (This could be one or more teams)
|--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
|---> Product A
| |---> Release 1
| |---> Release 2
| |---> Release 3
|
|---> Product B
| |---> Release 1
| |---> Release 2
|
| (ETC)
|--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
|---> Product C
| |---> Release 1
| |---> Release 2
|
| (ETC)
While still not dynamic this would enable that scenario. I would however still retain my $\TeamProject\Client A\ProductA source control structure and not filter this down. It is simply a compartmentalisation of the planning process and should not nessesarily spill over into the other parts of your ALM Solution.
Question 3) This seems to be trickier to get the iterations right, especially when it comes to TFS showing the backlog. Specifically, for the TFS Scrum 2 Iteration setup, it seems that I should be selecting (check box) only those leaf level iterations that are for planning and subsequent development. So extending the above example, we might have that the "Client A Team" will be available to start work on a new Product B for the next 4 weeks (assume 2 week sprints). Would we then only select (check box) "Sprint 1" and "Sprint 2" from Release 1? Am I understanding/using it correctly?
You are, but you are really looking at 3 Sprints out to have an actionable backlog as part of the Scrum process. I would recommend sequentially numbering your sprints consecutively so that in the UI you will not get confused on Sprint 2 when you also tick Sprint 4 if it is called Sprint 1. It is also nice to keep a tally of the experience level of the current team.
-> Team Project (Iteration root)
|—> Team Boundary (This could be one or more teams)
|--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
|---> Product A
| |---> Release 1
| | |---> Sprint 1
| | |---> Sprint 2
| | |---> Sprint 3
| |---> Release 2
| | |---> Sprint 4
| | |---> Sprint 5
| | |---> Sprint 6
| |---> Release 3
| | |---> Sprint 7
| | |---> Sprint 8
| | |---> Sprint 9
|
| (ETC)
But you are fundamentally correct on the technical process involved and the result it will achieve.
Question 4) Team Backlog Iteration selection - This might be problematic due to our concept of having teams per client and not teams per product, but maybe I just understand it wrong. In TFS Areas setup, you specify which iterations the "Backlog iteration for the team". My problem is that our PBI (Product Backlog Items) will be product specific and do not wish to mix them with PBIs from another product. So what I'm unable to understand yet is what the impact will be if we select area "Client A" as the "Backlog iteration for the team" instead of perhaps "Product B". I think I'm confusing myself here - what would be a sensible choice?
You are not confusing yourself and the person entering something into the backlog of the team will need to change the default to be the iteration/area of the product that they want the change in. At least by default you are getting the correct Team and this should be an easy thing for either the person entering the item, the Product Owner or a Team Member to categories this correctly.
Anything under the area that you specify as the Team Default is by default included in the items that you see. You can “right click” on your default Area for a team and de-select “Include sub-areas” so that you only see the top level and this is the technic that is used for Greg's Master Backlog. I would however suggest that you want to maintain a setting of “Include sub-areas” for visibility and transparency within your team.
I don't know whether have one team project and multiple areas for products (as is generally recommended) is complicating the issue.
It can. Some organisations prefer to add a drop-down list for “Team” to their work items (like the Conchango/EMC template) and use that as their team designation which can be configured in the Agile Planning Tools configuration as a default. That way you don’t need a Team designation in Area or Iteration if you are hitting up against that. I have no recommendation either way without more information of how your organisation is configured.
Question 5) TFS Web Access website - For any given team under "WORK | work items | Shared Queries" there is predefined queries under a folder called "Current Sprint" (Blocked Tasks; Sprint Backlog; etc), but it seems that these queries are hardcoded against "Root Project\Release 1\Sprint 1" - should these not automatically discover which is the current sprint given the dates defined against iterations? If not, then what is the best practice for maintaining these queries?
Option 1: Each Sprint spend the 2 minutes it takes to change the queries
Option 2: Create a tool to do that for you
Option 3: Have an additional “Current” iteration node within your Release and move the currently active iteration to below that node. Then set the queries to point to “Under” that “Client A\Product A \Release 1\Current”. Then it is quicker to change the nested iteration once and all the queries work. You then only need to change the Current but once per Release.
Do you know of some quality TFS 2012 and Scrum 2 specific training / tutorials that might help address these questions, or give some guidance for a successful Scrum 2 TFS setup?
I would recommend the Professional Scrum Developer training from Scrum.org or / and engaging with an ALM Consultant.
Related to this question and all things regarding TFS structuring, projects and teams, #MrHinsh has the following blog post on using TFS Teams without allocating them to an Area. It's not without caution though.
More over at his blog: http://nakedalm.com/team-foundation-server-2012-teams-without-areas/