Writing feature files for your automation tests

Feature files allow BAs to write stories in a way similar to how developers write solutions. The aim of feature files is to document the various possible scenarios and outcomes for an application and help give an indication of how much work is involved in delivering the feature. Feature files are also the drivers for the automated tests and also serve as a definition of done (DoD).

First ensure you have ALL the requirements of the feature to be implemented (i.e. there can be no loose ends regarding the actions and results the a user will make and the expected behaviour of the feature, example: I as a user want to use a fingerprint scanner to unlock my phone. I should be able to put my finger on the scanner and after the phone scans my fingerprint it should unlock the phone if I am identified as the owner of the phone. Otherwise the phone should remain locked)

• Once you have the requirements, separate your steps into "Given, When, Then" steps.
• A "Given" step is your context (in this case you have a user who has a fingerprint who has a phone that has a scanner)
• A "When" step is an action the user will take (in this case it is when they put their finger on the scanner
• A "Then" step is the result of the actions you take i.e. the expected response (in this case either the phone unlocks or stays locked depending on if they are the owner of the phone or not)

An example of what this would look like in terms of "code":

Feature: Unlocking a phone using your fingerprint   

Scenario: The owner of the phone wants to unlock their phone
	
    Given a user has a phone with a fingerprint scanner
    And the phone is locked
    And the user has a finger with a specific fingerprint pattern
    When the user places their finger on the phones scanner
    Then the phone should unlock   

Scenario: The non-owner of the phone wants to unlock the phone
	
    Given a user has a phone with a fingerprint scanner
    And the phone is locked
    And the user has a finger with a specific fingerprint pattern
    When the user places their finger on the phones scanner
    Then the phone should not unlock

Now sometimes we have multiple scenarios that only differ in the given options as above so we can simply collate these into "examples" and use one Scenario Outline to write the feature files like so:

Feature: Unlocking a phone using your fingerprint

Scenario Outline: Unlocking a phone using a fingerprint scanner

	Given a user has a phone with a fingerprint scanner
	And the phone is locked
	And the user has a finger with a specific finger print <pattern>
	When the user places their finger on the phones scanner
	Then the phone should <status>
    
Examples:

	| pattern      | status     |
	| fingerprint1 | unlock     |
	| fingerprint2 | not unlock |

What is always important with the above is that both the developer, the tester, the client and the product owner all agree on what the inputs will be (in this case the fingerprint), what the output will be (the phone locking/unlocking) as well as the actions the user will take to affect the output (putting a finger on the fingerprint scanner)

Michael Matusowsky