So, this is another one article abut cucumber, but I’ll try to describe SDLC methodology. If you skipped posts about correct Gherkin/Cucumber format , please have a look here: Cucumber — bridge or another one abyss between BA and QA
If you would like to try Java+Cucumber, please, have a look here: Create a Cucumber Project by Integrating maven-cucumber-selenium-eclipse
Feature File Naming Convention
But if you would like to get a overview on a process, please, continue reading. As every educated Analysts, as a result of our work, we got a list of requirements. We know that we could have functional and non-functional requirements. This is my typical workflow to deliver requirement to QAs:
- Usually I’m starting my IT Projects with Vision document where I got User Stories as a key entity,
- I’m doing idealization via Use Cases.
- QA adding extra details for my Use Case steps. In general – they are adding steps to add data like “qweqweqwe” in date and number fields and all that kind of negative testing.
If we would like to test particular requirement, then you are:
- Searching for a User Story
- Searching for a related Use Cases (via matrix, if I already spent some time to create and maintain it)
- Searching for a Test Cases, related to this Use Cases
- Open Eclipse, configure TestNG xml file to run required test.
- Run selected tests
So, it would be great to find one particular Use Case and run it from the one place, without tons of Word document (+ xls tables as an option). The problem is – Cucumber is not about User Stories, Use Cases, etc. Let’s answer couple important questions:
- What is the difference between Use Cases and Features? Features are descriptions of high-level product functionality. We then derive one or more use cases from each feature.
- What is the difference between Feature and User Story? A user story can be a specific justification for a feature, or a specific way to do it. Or it could be a totally different thing, like, for example: User story: as a customer, I want to pay with the most popular credits cards. While Feature: support the GOV-TAX-02 XML API of the government.
I would place User story and Feature at the same detail level, but the problem is: User Story is way too long for the Cucumber Feature. Why? Because Cucumber Feature is a simple text file, while Feature Name is a name of this file! This looks nice on the different demo, where teachers got “MyFeature1” and “MyFeature2”, but in fact, we should split feature files into groups via packaging, otherwise this will be a disaster.But anyway, we will not be able to put all these “As a User”, so, here is the key thing why they got features, because if we are using User Stories, we got space only for ” < some goal >” from “As a < type of user >, I want < some goal > so that < some reason >”.
There is also another one method we could use – add requirement number, this will extremely help us to support consistency and traceability. Continue reading