Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Dzmitry Harachka At SQA Days. Generalization in Auto-Testing. How we put what we had into new Technological Platform XML2Selenium.


Published on

We answer a question why to generalize things and approaches in development, as well as in test automation. OOP is good way to achieve good tests, but you do not have always experts or just good enough programmers who could then support your OOP and some complicated approaches introduced during that. Also in a company you need a way to share achievements/common components. I will share how we started to develop XML2Selenium, which objections we had, how it transformed into a platform not depending even on Selenium, will show architectural aspects/paradigms inside XML2Selenium, what allows you to make your own frameworks if you need that.

I won't just advertise a product, but concentrate on real business cases and examples from a practice, which pushed us to create something new. I believe some ideas from what we achieved provides you another look at how test automation could be organized. E.g. in XML2Selenium all artifacts, logs, screenshots, video is put on the server into separate folder, and you are able to access that just through web interface. Another good thing is integration of some approaches from Test Management into XML2Selenium reports, which allows managers do not check a status in spreadsheets, but just use the same report.

I will show you how manual QA engineer without special programming experience could create complicated tests, handling complicated things in the app.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Dzmitry Harachka At SQA Days. Generalization in Auto-Testing. How we put what we had into new Technological Platform XML2Selenium.

  1. 1. Generalization in Auto-Testing. How we put what we had into new Technological Platform Dzmitry Harachka, Founder, CEO at
  2. 2. Who is on the phone • • • • • • • 10 years of Java Development Eclipse Committer Founder and CEO at JazzTeam Worked in different roles from Junior to CEO Always was close to Test Automation and Processes Master' Degree in Computer Science, SCJP/SCWCD Product Owner of XML2Selenium Test Automation Platform
  3. 3. Agile Java Development • Java and world of Test Automation • Java ideally fits TDD and DDT • Agile/XP promotes Test Automation and Continuous Integration • We earn from Test Automation • Have good experience in Generalization Programming, including OOP, patterns, frameworks, finishing with plugin based systems e.g. Eclipse
  4. 4. Generalization • I would like share ideas behind XML2Selenium architecture. • That allows you to apply them in your everyday life. • This does not mean you need own platform or framework. • This talk is not an advert. It reflects our way to make generalization and allows us to talk to that.
  5. 5. First look at XML2Selenium
  6. 6. XML DSL Language: example1
  7. 7. XML DSL Language: example2
  8. 8. More complex test
  9. 9. Reporting: main table
  10. 10. Reporting: filtering area
  11. 11. Reporting: web view
  12. 12. Reporting: BDD
  13. 13. History: huge log files
  14. 14. History: complicated utilities Blur applied through NDA, that method for typing in edit control includes try/catch, clipboard and mouse over support, wait for object Synchronization, DDT values, logging etc.
  15. 15. History: configuration magic and cross-browser tests. Local and remote modes.
  16. 16. History: Java stuff applied
  17. 17. History: OOP and Page Context
  18. 18. Evolution • Utils • Many • Tricky thing to support • Still need something for storing states • E.g. singleton containers • OOP (Page Object etc.) • We need context • We need some workflows • We need reporting/advanced logs/video/dynamic flows
  19. 19. Evolution: DSL XML • DSL XML • Context hidden. Applied to Test Case/Test/Frame. Support hierarchy • Variables are just simple • Reusability • Reporting • Plugin based • Artifacts • Good for TDD/DDT/BDD
  20. 20. Generalization: polymorphism • Main thing in OOP is polymorphism • You have a list of different objects • You would like to make some actions at these objects • You would like to add new types of object • You do not want to change something in algorithm • Plugins = OOP/polymorphism + reflection • When you are developer always think in Polymorphic way • Even factories for test/dummy/mock implementations • Almost all the patterns • Block schemes are not cancelled in OOP! Please run your algorithm in mind to find bugs in your generalized algorithm
  21. 21. Contexts • • • • • • • • • Great for de-coupling entities Rights to write and read from contexts What could and should be stored in context Good way to expose API of core functionality You could introduce tree of contexts, one inside another We could have several existed contexts Context could have interceptors Context could have rich nature e.g. sending events/invoke listeners if some settings set Nice to organize in flows and apply some rules. E.g. one component would like to have in a context certain variable. Another component would expose some variables to context and if doesn’t do that it is mistake.
  22. 22. Context in XML2Selenium
  23. 23. Plugin development • • • • • • • • OOP Reflexion Configuration Extension points Core API for plugins Events subscription Permissions Dependencies • I need full basis then I am happy! • It pushes you to make algorithm of a system really generic • Practice would evolve your system • The same block scheme. Try to run different combination through you system
  24. 24. Beginning 
  25. 25. Vertical movements of projects • • • • Copy pasting Utility Class Library • Share it • Framework • Share it • Good thing when different teams in a company have a way to share projects • Maven + Nexus work in Java
  26. 26. DDT in XML2Selenium
  27. 27. JUnit as a running runtime • • Create your own runners Create your own annotations
  28. 28. CI for your QA framework
  29. 29. Use it for testing itself • Master build • Always green, contains all possible XML combinations • Smoke Test build • Not green, allows to have different statuses • Self Testing build • Uses XML2Selenium tests to test Smoke Test. Out manual tester like this build a lot and motivated to create new tests • Best Practices build
  30. 30. Sharing ideas • • • • Maven and Nexus are good for sharing dependencies, and for dynamical building of class path Go for early adoption. Ask you colleagues, customers, friends to check new thing. Do not say to programmers it is trial check. Introduce real customers and real processes Apply processes with 100% of seniority • Product owner • Backlog • Iterations • Demos • Manual testers • Scrum board Think about open source
  31. 31. XML2Selenium roles • • • • Developers of core Plugin developers XML2Selenium test developers XML2Selenium consultants
  32. 32. Future • • • • Going into Cloud and SAAS wrapping Integration with CloudBees Eclipse Studio to work without XML XML based debug mode. In WebView to see the contexts for every line
  33. 33. Questions? • Read further at •