This document discusses specification by example (SBD) and behavior driven development (BDD). It provides an example of using BDD to specify requirements for a 3D secure payment system through examples. The document outlines features and scenarios to describe how a 3D secure transaction should be processed depending on whether a card is enrolled or not and what response is received from the 3D secure gateway. It also lists some automation tools that can be used to validate specifications.

1. Specification by Example
(BDD)

2. Agenda
• Software Development Challenges
• BDD to the Rescue
• Spec Examples
• Automation Tools

3. Creating software products
is challenging…

4. requirements code
S P
Cliqz
Cost of translation
years
weeks

6. Behaviour Driven Development
BDD is about eliminating Translation cost
from business to developers
using the language of examples

7. business goals
specifying

8. deriving scope

9. collaboratively specify
examples

10. refining specification

11. automated
validation of specifications

12. building
living documentation

13. requirements code
S P
years
weeks
Cost of translation
examples
BDD
${ } { }
DDD

14. Spec examples

15. What makes a good test
• In domain language
• Easy to understand
• Precise and testable
• Self-explanatory
• Consistent

16. evaluation scenarios

17. 3D-secure v1
Feature: 3d Secure
In order to reduce chargeback costs
As a system owner
I want players to go through 3D secure enrollment and verification
Background
Given the card number 4236754 is enrolled
And the card number 2341238 is not enrolled
Scenario: Enrolled card
Given the player has a card with number 4236754
And expiry date 12 11
And address line 1 Max Weber Platz 23
And address line 2 1st floor
And post code 12300
And city Viena
And country Austria
When the player starts a transaction for 10 EUR
Then the system will send a message “””
<message type=“ENROLMENT_CHK_MSG”>
<CARD> 4236754</CARD>
</message>
“””
And the system will receive a response “””
<response>
<ENROLEMENT_CHK>enrolled</ENROLEMENT_CHK>
</response>
“””

18. 3D-secure v1
Then the system will send a message “””
<message type=“3D_AUTHORIZE”>
<CARD>4236754</CARD>
<EXPIRY>1211</EXPIRY>
<ADDRESS_LINE1>Max Weber Platz 23</ADDRESS_LINE_1>
<ADDRESS_LINE2>1st floor</ADDRESS_LINE_1>
<POST_CODE>12300</POST_CODE>
<CITY>VIENNA</CITY>
<COUNTRY>AUSTRIA</COUNTRY>
</message>
“””
And the system will receive a response “””
<response>
<AUTHORIZE>
<3D_SECURE_URL>http://hsbc.co.uk</3D_SECURE_URL>
<PA_REQ>232325454-444444232323232</PA_REQ>
</AUTHORIZE>
</response>
“””
And the system will redirect the user to http://hsbc.co.uk
And the PA-REQ code in the form will be 232325454-444444232323232

19. 3D-secure v2
Feature: Card enrollment with 3d Secure
In order to reduce chargeback costs
As a system owner
I want players to go through 3D secure enrollment and verification
before proceeding with actual authorization
Scenario Outline: 3d transaction processing
Given the card was <enrolled>
And 3D Secure gateway response was <response>
Then the transaction status is <status>
Examples: Response arrived
Examples: still waiting for response
Examples: card not enrolled, so not going through 3D at all
enrolled response status
YES cancel CANCELLED
YES authorize
PENDING_AUTHORIZATION
enrolled response status
YES not received yet PENDING 3D SECURE
enrolled response status
NO not received yet PENDING AUTHORIZATION

20. Automation tools
• Cucumber: http://cucumber.io
• JBehave: http://jbehave.org
• SpecFlow: http://www.specflow.org
• Appium: http://appium.io/