Service Layer Testing Using BDD For Legacy Products /

Applications

Service Layer Testing & Automation – Approach Document

• Service Layer Testing – What is in for Legacy Products.

• What can we do

• How can we do

• Testing at service layer – Options before us.

• Strategy & Approach for Legacy Products.

• Challenges & Limitation

• Estimates for piloting

Service Layer Testing with BDD – What is in for Legacy Products.

• Key testing challenges to improve product quality

• Zero Test Automation

• No effective integration test. Regression testing is the only place where integration testing is executed.

• Test case coverage for System and Regression testing - Testers are not aware of many logic in the code - Time/effort constraints from executing as many test cases we want to execute for any test cycle

• Enhanced Test scenarios through Service Layer Testing or Developer Integration testing - Improves the overall Legacy Product Quality by enhancing test scenario coverage which in turn will reduce defect leakage.

• Automated nightly runs – Reduction of duration / effort / cost - As the service layer test suite grows, we can introduce automated nightly runs which allow to execute as much test scenarios/case as possible without effort and time constraint

What can we do

4

•Write service layer testing (Developer Integration Testing) using BDD (SpecFlow) test framework.

•Develop Java/>net based ‘Test Framework Classes’ to enable testing like batch framework.

•As part of service layer testing we will deliberately ignore unit test and favor developer integration testing (details are in the next couple of slides).

•Automated (hourly/nightly) /Triggered (code check in) runs of the test suite. •Configurable test framework would enable wider test coverage. Also the execution would take a fraction of time needed for manual testing.

How can we do

5

Spec Flow

process :

Creation of

Feature Files

based on BA’s

Spec / Scenarios

in the code.

Spec Flow

process :

Creation of test

stubs

Spec Flow

process :

Writing of c# test

code

Java/>Net

Wrapper :

Write wrapper to

call Legacy

functions through

available interface.

Below steps highlight the tasks involved

Sample Feature file

• Feature: Validate Campaign

Validate the user inputs while creation/amendment of Some Data and determine whether the Data can be saved or not

• Scenario: Valid Type I Data in Additional 2 tab

Given user entered Type I Data

And Necessary flag is ON

When ‘Users' of Type I Data is same as ‘User' of Type I Data

Then I should get "Valid Type I Data "

• Scenario: Invalid Type I Data in Additional 2 tab

Given user entered Type I Data

And Necessary flag is ON

When ‘Users' of Type I Data is different from ‘Users' of Type I Data

Then I should get error message

• And so on…

6

Testing at service layer – Options before us

7

BDD without refactoring

Each behavior in the feature file can be mapped to test case with data manipulation.

Cons: • Even though we were checking single behavior we need to execute whole validate procedure • Test procedures will be ugly as in all the cases we were calling single procedure but doing data manipulation to execute targeted scenario

Execute

‘ValidateSomeData’

test case

------------------

Assert the results

for Makegood

validation.

Execution Work Flow

1. Parameter object injection

2. Manipulate parameter object to

check behavior of makegood

campaign

3. Call ‘ValidateSomeData’

Function in the wrapper

Call ‘ValidateSomeData’

function in Legacy Code

through available interface

Advantages with writing test framework

8

• Test end to end flow covering all the relevant paths/scenarios in a single test. • With configurable inputs tests can cover multiple scenarios in single run. • Enhances the quality of the overall regression suite while bring down the execution time of manual regression. • As developers are writing he/she can go through the code and cover all the logic/scenarios as part of the end

to end flow • Scenarios documented in the feature files can be ported to WIKI as it changes and used as living document • The Acceptance criteria’s from the BA would not only act as the Behavior of the application for the

Development team, the specFlow report derived from the scenarios would be the test cases for the QA team, which would help them in reducing the effort of writing the test cases.

Strategy & Approach for Legacy Products.

9

Strategy for Framework Classes

We see two different strategies for service layer testing possible in Legacy Products. Below are the details, Pros & cons associated with it.

Module level strategy: •Pick up a complete module or sub module and write a complete integration test suite with the help of dedicated developers. Parallel development of WCF & framework classes is must to make the testing feasible and allow better test/scenario coverage. •With this strategy we can reduce/ eliminate the effort for functional testing & regression testing for that module/sub module like campaign module.

Enhancement level strategy: •Start writing test cases for new enhancements but this has to be supplemented with additional test cases which covers all the impacted scenarios. •Developers need to focus on writing the test cases for impacted scenarios which would elongate timeline of that feature. •Such strategy would limit the test coverage limited to new enhancements. This strategy would create test suite with unrelated test cases from one release to another release. Based on the analysis our suggestion is to pilot either of this approach in phased manner. Piloting would help to evaluate the gains early on, while phasing will allow us to amortize framework related investment if any. For example batch testing can be differed to future phases as it needs lot more framework classes than a testing a function like Validate Data.

Challenges & Limitation With Service Layer Testing

10

Challenges: • High reliance on developers to unearth the scenarios from legacy code in absence of living specs.

• Absence of agile development, user stories, code refactoring could complicate development and maintenance of BDD test cases.

• Testing of batch jobs is a challenge, either we need to identify tools or need to write WCF wrapper & framework classes which need to compare inputs with outputs like DB data or flat files.

• Data cleanup / tear down could be an issue unless framework classes include auto increment features to avoid referential integrity issues.

• Standards & guidelines for writing feature file and BDD test cases.

THANK YOU