This document outlines a presentation by Umang Nahata on testing enterprise software rewrites. The presentation discusses assessing risks, understanding goals and dependencies, utilizing legacy systems for testing, effective test automation strategies, and lessons learned. Key points emphasized are minimizing architectural changes, focusing on the minimum viable product, including people familiar with the legacy system, and establishing a supportive team environment.

1.
T24
Special
Topics
10/5/17
15:00
Testing
Enterprise
Software
Rewrites
Presented
by:
Umang
Nahata
Progressive
Insurance
Brought
to
you
by:
350
Corporate
Way,
Suite
400,
Orange
Park,
FL
32073
888-­‐-­‐-­‐268-­‐-­‐-­‐8770
·∙·∙
904-­‐-­‐-­‐278-­‐-­‐-­‐0524
-­‐
info@techwell.com
-­‐
http://www.starwest.techwell.com/

2. Umang
Nahata
Progressive
Insurance
Umang
Nahata
is
a
senior
system
test
engineer
with
Progressive
Insurance,
where
he
applies
architectural,
technical,
and
process
knowledge
to
deliver
software
assets
that
add
value
by
increasing
the
breadth,
coverage,
and
speed
of
testing.
He
has
an
inquisitive
spirit
and
researches
new
approaches,
tools,
and
techniques
to
solve
complex
testing
problems.
A
software
developer
at
heart
with
a
passion
for
building
quality
software,
Umang
has
a
talent
for
creating
effective
test
strategies.
He
has
been
in
the
IT
industry
for
more
than
ten
years
in
a
variety
of
roles
and
experiences.
Umang
is
passionate
about
software
testing,
test
automation,
and
advocating
better
collaboration
for
building
better
software.

3. 1
Tes$ng
Enterprise
So/ware
Rewrites
Umang
Nahata
Progressive
Insurance
Star
West
Tes$ng
Conference
2017
Page 1
• Senior Systems Test Engineer
§ Progressive Insurance – Ohio
§ Hybrid Developer / QA
§ Create tools and processes to solve testing
challenges
§ 10+ years in IT
§ Avid learner
Page 2
Hello!

4. 2
• Enterprise Software Rewrite
• Assessments, Strategies and Experiences
• Practices & Lessons Learned
Page 3
Session Goals
Enterprise Software Rewrite
• Software Modernization Effort
– Keep up with industry standards, technologies
and infrastructure
– Triggered by different drivers of change
• Rewrite Core Objective
– Ensure functional compatibility of the new
system before retiring legacy system
Page 4

5. 3
Enterprise Software Rewrite
• This effort is
– Risky
– Costly
– Challenging
– Rewarding
Page 5
Sometimes, for some enterprises,
software rewrite is the only option…
Page 6

6. 4
Break Poll
A quick show of hands…
Your exposure in testing enterprise software
rewrites?
Yes, No
If you were involved, what was the end result?
Delivered, Not Delivered
Page 7
• Enterprise Software Rewrite
• Assessments, Strategies and Experiences
• Practices & Lessons Learned
Page 8
Session Goals

7. 5
Know yourself and your customer
Page 9
“If you know the enemy and know yourself, you
need not fear the result of a hundred battles.”
- Sun Tzu, The Art of War
Know yourself and your customer
• 5 Why’s Technique ~ Understand dependency
and root cause
Why are we doing this? – To implement ‘xyz’
Why do we need to implement ‘xyz’? – To modify
feature ‘abc’
Why do we need to modify ‘abc’? – To avoid
maintenance costs
Why? – Vendor retiring support
Page 10

8. 6
Know yourself and your customer
5W1H Technique ~ Information gathering
– Who, What, Where, When, Why, How
• What happened?
• Who was involved?
• Where did it take place?
• When did it take place?
• Why did that happen?
• How did it happen?
Page 11
Know yourself and your customer
Additionally, try to understand
• Change Driving force
– Strategic, Financial, Infrastructure, Others
• Team Competency
– Right people, Right skills, Right Attitude, Right
time
• Legacy system (as best as you can)
Customer goals != Project goals != Individual goals
Page 12

9. 7
Risk Analysis and Management
• Worst Case Scenario
– What can go wrong?
– How bad can it go wrong?
Page 13
Risk Analysis and Management
• Helps plan, manage, allocate resources for
testing efforts
• Enterprise software rewrites are high-risk
– Never underestimate complexity (and hours)
– Careful of scope creep & feature change
requests (How would you test?)
Assess, Adjust and Learn
Page 14

10. 8
Experience and Strategies
• Minimize software architectural transformation
• Utilize legacy system as test oracles
• Effective Automation can make a difference
• Audit test data for internal systems
Page 15
Minimize software architectural
transformation
• For effective delivery, scoping and testing
– Keep it simple and incremental
– Focus on Minimum Viable Product (MVP)
– Isolate changes, dependencies (if possible)
– Resist over design/architect
– Scope creep could affect testing
Page 16

11. 9
If it (Software Rewrite) seems too
good to be true, it probably is…
Page 17
Utilize legacy system as test oracles
• Difficult to shoe-horn tests into legacy system
– Value, Time, Costs, Skills Trade-offs?
– Possible to write tests in new code base
• Please do (Your team will thank you later)
• Your testing needs to be strategic
– Expect lack of Documentation,
Requirements, Specifications and Support
– Baseline your tests on legacy system and
compare to new
Page 18

12. 10
Effective Automation Can Make a
Difference
• Determine
– Purpose & Value
– Feasibility
– Reusability
• Automation
– Hinder or Support?
– Right Team, Right Tools, Right Skills, Right Time?
Page 19
Audit test data for internal systems
• Optional or Adapt
– Production test data availability?
• Testing the test data
– Quantity Vs. Quality
– Repeating same tests?
– Sufficient test sets? Representation?
– Coverage gaps?
– Redundant/Unreachable code?
– Evaluate/Benchmark?
Page 20

13. 11
• Enterprise Software Rewrite
• Assessments, Strategies and Experiences
• Practices & Lessons Learned
Page 21
Session Goals
Teamwork makes the difference
• You may not get it right the first time. It’s okay…
• For your team
– Establish Goals
– Create environment
– Encourage mistakes
– Encourage learning
– Provide support
– And more…
Page 22

14. 12
Rewrite with specific purpose/target
• Can’t abandon legacy-code
– Don’t underestimate complexity
– Try to Reuse/Refactor
– Focus on building Minimum Viable Product
• Shows progress to stakeholders
• Easy to test as well
• Add unit tests when rewriting
• Document as you rewrite
Page 23
Include people familiar with the
legacy system
• Negotiate dedicated people and resources who
are familiar with old system and include them in
rewrite efforts
• Blend a team with old and new technology
experts
• Include them from the start and negotiate
response times (if needed)
Page 24

15. 13
Remember…this isn’t a silver
bullet
Page 25
Your Mileage May Vary…
Testing relies on feedback…
So do I…
Page 26

16. 14
Appendix – Resources
• Wikipedia – Rewrite, Software Modernization,
5_Whys, 5W1H
• Joel On Software – Things you should never do
• Michael Feathers –
Working Effectively with Legacy Code
• Richard Bender – Testing Software Rewrites
• YCombinator – Discussion Link
• James Shore – Surviving a software rewrite
• Stephen Haunts –
Is it a good idea to write tests for your legacy code
Page 27