BDD Framework Feasibility Report

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 4

BDD Framework Feasibility report

Project overview
Introduction
Behavior-driven development (BDD) is an Agile software development process that
encourages collaboration between developers, QA and non-technical or business
participants in a software project. It encourages teams to use conversation and concrete
examples to formalize a shared understanding of how the application should behave. It
emerged from test-driven development(TDD) .

Behaviour-Driven Development (BDD) is a set of practices that aim to reduce some


common wasteful activities in software development:

• Rework caused by misunderstood or vague requirements


• Technical debt caused by reluctance to refactor code
• Slow feedback cycles caused by silos and hand-overs

BDD aims to narrow the communication gaps between team members, foster better
understanding of the customer and promote continuous communication with real world
examples.

The purpose of this project


This Framework was adopted from A team on the the insistence from the senior management.
The following are the high level requirements from this new framework.
• Test automation with REST and SOAP, so that we don't have a tight coupling of test
code with product code.
• Running our tests against different product environments.
• Should be dynamic to work with other frameworks seamlessly.
• Preference for Java based framework because of our teams familiarity with Java.

Scope planned with this framework


Initially we were planning to automate BPM customer bugs only, which can be run
against FA environment as well.
Design
What was available .
The initial Framework provided to us with basic functional features implemented, eg., function to
execute a shell script , connecting to a database and executing a Select statement.

What was not available


The Framework code contains lot of hard codings, There are a limitations like not returning the
value of database execution . Logging not implemented properly ., Feature to process a JSON
file not available ., So many features require enhancement and re-coding.

High Level Design

The framework comprises of 2 major blocks , BddCore and BddService. The core support
features like Database connection and execution , Web Service innovation , Web Driver
integration etc are provided under BddCore. Test Specific code and other test resources are
listed under BddService .
Integration points to other framework like Jenkins are TestNG are also provided under
BddCore.
.

Detailed Design

The framework is developed based on Cucumber and Gherkin open source automation
testing framework.
The tests are written in Gherkin language (which is a keyword driver test development
model ) , which got a very basic syntax. This is easy to understand and learning time is fast .
Any developer can understand this on the job.

A Basic Testcase will look like the following (feature file)

In the above
Each scenario is an individual test.
Scenarios are grouped into features, which is comparable to a test suite.
Scenarios must be written in the Gherkin syntax
The scenarios are tied to the step definitions in your code through the Cucumber framework.

‘Given’ step will configure the system to be in a well-defined state, such as creating and
configuring objects or adding data to a test database. Given’s would be your preconditions.
Eg., Given deploy the application .
‘When’ steps are used to describe an event, or an action.
Eg., When its confirmed the application is deployed.
‘Then’ steps are used to describe an expected outcome, or result.
Eg., Then create a new user session and login

The ‘Step Definition’ is implemented in Java (there is flexibility to implement in other


languages like python) . So for any given , When or Then , a corresponding function is
implemented in the Step Definition java file.
The glue between the feature file and step definition is provided by cucumber .

Other supporting artifacts for the test like properties file , data inputs and test specific
artifacts are provided under a Resources folder along with the feature files.

Gradle is used for build . Any reporting tool can be integrated to collect the test result output

Major benefits for BPM QA team

By utilizing this framework the following major benefits are seen for BPM QA team in automation
FA Customer bugs.

• An independent run time functional test implementation for FA Customer bugs. This does
not involve UI , so tests are stable and no maintenance required w.r.t UI changes.
• Since all the functionalities are executed based on REST and SOAP , these tests can be
executed from any environment . No strings attached to product code.
• The same test framework tests are executed against legacy shiphome based
environments as well as FA environments .
• The same is enabled as part of CI / CD pipeline as well .
• Test development time is very less compared to other functional and UI test
development frameworks in use currently .

Major blockers for other teams to adopt this framework.

The following are the blocker identified in other teams adopting this framework.

• The benefits are seen minimal to migrate from an existing working framework to a new
framework
• Quite a few generalization required in the framework in this current form. So more effort
needed to make adoptable or suitable for other teams.
• General hesitation by teams to adopt a new framework unless there is a very pressing
need to do so.
Conclusion.

This framework is suitable for any team which is looking towards developing a
automation framework from scratch . With minimal effor this framework can be adopted to meet
most of their automation requirements .
Not suitable for teams which already have automation frameworks which supports /
provides their current requirements.

References
https://cucumber.io/docs/guides/bdd-tutorial/
https://cucumber.io/

You might also like