Slides about aggressive automated testing that were presented on selenium camp 2015: http://seleniumcamp.com/

1. Architecture of
automated test cases
for legacy applications
MYKHAYLO VASYLCHENKO

2. Agenda
●
Projects
●
Problems
●
Test cases architecture
●
Outcome
●
Questions

3. Projects

4. ●
Java
●
Linux remote servers
●
JBOSS
●
Oracle Weblogic
●
Oracle Coherence
●
DB
●
Web UI
●
SOAP/http
●
REST/http
Technologies

5. •Legacy applications in
diverse ecosystem
•Complex pipelines
Legacy Apps

6. Testing tool - CA LISA

7. ●
Started with 6 people
in early 2014
●
11 people in the end
of 2014
The Team

8. 21 projects during 2014
Around 3 test cases/man/day
Our Commitment

9. Covered only 3 projects
(from 21)
4 Month Later...

10. Problems

11. Duplicates
Appending
Dependence
3 Major Problems

12. Big automation team
●
Code duplication
●
Support issues
Duplicates

13. Duplicates

14. Extending for reuse...
●
Huge methods
●
Hard to maintain
Appending

15. Beginning
Appending

16. Beginning
Appending

17. The team is dependent on:
- quality of manual test cases
- environment
- developers
Manual QA – USA, Vietnam, India
Environment - USA
Developers – USA
Deployment and Automation – Ukraine
●
Hard troubleshooting
●
Communication takes ~80% of time
Dependence

18. Test case: Search for “User Name” and “all of these”
1. Set valid “user name” to “find” field
2. Select “all of these” condition
3. Select “User Name” field
4. Click “Search” button
Expected result:
Grid with correct data is appeared
Dependence

19. Test is failed.
WHY???
Dependence

20. Test is failed.
Because of SQL query should be another:
Dependence

21. Legacy Apps

22. Legacy Apps
Missing relevant documentation

23. Legacy Apps
Missing relevant documentation
Missing key developers

24. Legacy Apps
Missing relevant documentation
Missing key developers
Missing momentum

25. Test cases
architecture

26. Start from test cases
False Start

27. Start from test cases
Start from analysis
False Start

28. Analysis
Test ID Test Name
001 Verify search for “User Name” field and “all of these” condition
002 Verify search for “User Name” field and “starts from” condition
003 Verify search for “User Name” field and “ends with” condition
004 Verify search for “City” field and “all of these” condition
005 Verify search for “City” field and “starts from” condition
…. ……
n Verify search for “State” field and “equals” condition

29. • We know functionality
• We know different scenarios
• We know common actions
parameters it should take and
what actions it should perform
Encapsulation

30. 
Create mock-ups
Encapsulation

31. ●
Get input and call method
●
Actions are "hidden" in methods
Methods
Test 1
Test 2
…
Test N
Test Cases

32. Test Cases

33. Real test cases + mocked
methods = 80% done
TDD Style
Results
PASSED
FAILED

34. Fill mock-ups with real code
Coding

35. Coding
Mock up

36. Automation
Real

37. •Run tests
•Review results
Ready

38. Outcome

39. No Duplicates when applying architectural approach
Duplicates

40. BEFORE
Duplicates
AFTER

41. ●
Know your features
●
Implement optimal methods from scratch
Appending

42. Appending
BEFORE

43. Appending
AFTER

44. •Test case is failed but automated
Dependence

45. •Test case is failed but automated
•The reason is documented
Dependence

46. •Test case is failed but automated
•The reason is documented
•Resolved when feedback is provided
Dependence

47. Postponed Troubleshooting
Never stop and never closely investigate the problem

48. Aggressive Automation

49. 21 projects are covered by automation
5300 test cases automated
65% test cases – passed
35% - failed due to reasons not dependent on
automation team
Outcome

50. Questions?
Mykhaylo Vasylchenko
mvasylchenko@intropro.com