Quick Intro on how BDD can be used for legacy software product testing

1. Service Layer Testing Using
BDD For Legacy Products /
Applications

2. 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

3. 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

4. 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.

5. 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

6. 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

7. Testing at service layer – Options before us
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

8. 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.

9. 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.

10. Challenges & Limitation With Service Layer Testing
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.

11. THANK YOU