Test Cases and Feature Files

When you are on the QA design phase of a project or you are documenting how your tests will be executed, you will come across two different options, test cases and feature files, they may have a common purpose, and this is to document the tests that testers or QAs involved in a project will execute, I have used both and I'm going to describe here my findings.

Test cases as the name implies, are cases that testers and QAs will test during the project, they are great for documenting the tests and the functionality of the project. Test cases include an ID, a precondition to start the test case, a series of steps and a expected result, the way I have done test cases in the past, is to add a expected result for each step, it has worked better for me than only having one result at the end, of course this is up to you, both ways work. Test cases are done in a really formal format and they are really structured. In my experience, test cases are shared internally with the development team (although they don't always read them) and other QAs to know what to do, they can also be shared with clients but that doesn't always happen because they are really robust or the client doesn't request this documentation.

Most of the companies I know in my country (Colombia) and around the world work with test cases and from my perspective most of the methodologies (especially waterfall) use them too, I have always thought that testing is priority than documenting test cases, talking in an agile perspective where you have to deliver stuff within two weeks or a month, and when a project doesn't have a correct planning I will always prefer to test than to do test cases. There are a lot of tools for test cases like TestLink, TestRail, Jira or even spreadsheets (please don't use spreadsheets for test cases).

This is a basic example of a test case about a valid login:

Test case ID: 001
Precondition: User must have a created account
Steps                                                                                  Expected result
1. The user goes to the page                                                1. The page is displayed
2. The user clicks on the login button on the header        2. The system displays the login form
3. The user enters a valid email and password                  3. The user is taken to his profile
and clicks on the login button                                                 

Now let's go to feature files, this simple text based files can be opened with any text editor and they have two different goals, one is to document what a user story or functionality will do and the second one they will become the starting point of automation testing using BDD and steps definitions. Feature files must be saved with the extension .feature like login.feature, they work with a cool syntax called Gherkin (https://github.com/cucumber/cucumber/wiki/Gherkin) which is the language that cucumber understands. I can talk about cucumber in another post. Gherkin helps a lot of in terms of documentation and understanding requirements and they are not only shared with the development team or QAs, but to all the stakeholders and team members to check, because it is written in a really easy way for all players to understand, basic word combinations like Given/And/But/When/Then helps a lot to understand and document requirements to test, this is an example of a feature file about a valid login:

Feature: User must be able to login to purchase items
In order to buy products
As an user
I must be able to login

Scenario: Login on the site
  Given  I go to the page
  And I go to the login page
  And I enter a valid email and password
  When I click on the login button
  Then The system logs me and takes me to my profile.

From my perspective, both ways work for documenting, I like feature files a lot because of the automation plus and because of the easy understanding using regular language you used day by day and not real formal format, with feature files, even your grandma or aunt that has no idea about the project may understand the requirements and the way they are written, provide a lot of background about what to test, and of course you don't need complex programs to view them, just simple plain text editors.

Both test cases and feature files can be traceable into any tool you like, the thing is the way they are read and the way they are understood by all people involved in the project.

The choice is yours!

Leave me your comments and don't forget to follow me on Twitter @LuchoAgileQA