Relation between feature file and user stories:

It’s simple, but complex:

It’s really as simple as – feature files describes feature of an application without duplication, and each related user stories are tagged with the corresponding feature files.

Refer to "Terminology" section for better understanding, end of this page.

However, if we deep dive, there are certain challenges:

  1. Challenge #1: Dividing application into feature: HOW do you divide a web-application into features? Well its not easy, for example, user management (search, add, update, deactivate an user) is a feature in facebook. Now a general question: WHAT are features? User management is a feature OR searching an user is a feature OR searching a user by city/town is a feature…! Complex right.
  2. Challenge #2: Identifying correct feature file for user stories: Before discussing this problem, we have to understand that teams are continuously changing (change in vendor, change in team member, ramping up and ramp down etc). Mainly due to this, it becomes difficult for the entire team to know all the features of an application. Even though they know the features of the application, they are not aware of feature file related to the features and how the application is divided into feature (challenge #1). Most of the BDD(Behavior Driven Development) projects, do not document this properly.
  3. Challenge #3: User Stories, impacting multiple user stories: Let’s start with an example, user story says implement auto-complete in search user page and update user page in application-X. Now, this stories impacts both search and update user feature files. Hence, identifying all the impacted feature files due to an user stories is an complex job.

Common mistakes, due to these challenges:

Mistake#1: Associating each a user stories with a new feature file:

  1. User stories are planning tool. They exist until they are implemented and rolled out.
  2. Feature are communication tool. They depict how system works.

Example:Suppose user stories is: Search a customer.Scenario: User should be able to search a customer based on Name, Address and A/C number.

Now with this type design, I have to create three feature files. Search_by_name.feature, Search_by_address.feature & Search_by_ac_number.feature

This approach can get your team going but soon it will run into problems:

  • Problem-1:Feature file will increase in number, which will obviously make the framework complex. The feature folder will be like history log of development. 😊
  • Problem-2: Linking. Now suppose, customer want to enhance the search feature, then we need to update all the feature file related to it.

Point to be Noted: the feature files were linked with previous user stories which have been completed. Now, there will be no relation between new user stories and feature file. Either you have to define new feature file and deleting the older one OR search for the feature file manually which covers current enhancement (user stories).

Mistake#2: Associating each user stories with an Epic:

This should be the ideal way as it is describing the product. But again “challenge# 1” will block your way.

  • Problems-1: this will create issue in delivery, as one epic can’t be developed in a sprint or two.
  • Problem-2: one feature file will be too long, and can create complexity. This will decrease the modularity.

Solution and best practices:

  • Creating a feature map: it is very important to overcome “challenge #1”. Note: that feature map should include the feature file names for each sub-feature in the feature map. Below is an good example of feature map [referred from google]:080a0dd
  • Divide the product into logical sections each with a feature file. These files should be easily understood by business as one of the feature of the product.
    • Point to be noted: as product undergoes changes/update /enhancements similarly feature file and step definitions should also under go updates as required. (add/update/delete).
    • Even if there are One Epic, and three user stories it might have two feature.file. In other words, there should be no relation between Epic/user stories and feature files.
  • In the above example, all the search scenario should go in to one feature file. Similarly, all scenarios related to customer maintenance go into the another feature file.
  • If the feature files are changing from due to change in business requirements then there should be version. Version control is important.
    • Benefits – These versions are also helpful in tracking the changes of requirement, from where we started and where we are now.
    • Benefits – Efforts can be tracked and everything is well documented.
  • Scenarios in the feature file should be independent and focused with one combination of data. Scenario should be cover unhappy (negative) path as well.
  • Test Execution perspective: We should also keep in mind that we can execute each scenario separately by using scenario level tag. Tagging of scenarios and definition of runner file is to be taken care properly.
  • Defining feature file: we should use the terminology and common domain language to define the feature file, so that it can be easy for business to relate.

Conclusion:

The user story is absorbed into our features and becomes invisible, leaving the feature as a live document of what the software does now. Not as a record of how it was constructed.

Feature file should be independent of each other. Feature files should be categorised into scenario based on set of test data.


Terminology:

  • Epic:

High level requirement that includes multiple user stories. This is what business need in the application. At this stage, deep analysis of the requirement is not done.

  • Feature file (living Spec):

As the name suggest feature files are files which describes a feature uniquely.

The Feature file should be organised in a way that usefully describes the evolving product. This file can be used in multiple areas long after the product development is over. Also, helping the developers to maintenance of the framework smoothly.

  • User stories:

User stories are requirements, but they are basically small developing unit. These will help us to develop the product in the agile project planning (scrum methodology).

Life span of user stories are over once the it is completed. In case there are new enhancement in the same requirement then new user stories are created. Hence linking a feature file in cucumber with user stories will create problem in long run.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s