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

1. Generalization in Auto-Testing. How we put what we had into new Technological Platform Dzmitry Harachka, Founder, CEO at

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. 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. 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. First look at XML2Selenium

6. XML DSL Language: example1

7. XML DSL Language: example2

8. More complex test

9. Reporting: main table

10. Reporting: filtering area

11. Reporting: web view

12. Reporting: BDD

13. History: huge log files

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. History: configuration magic and cross-browser tests. Local and remote modes.

16. History: Java stuff applied

17. History: OOP and Page Context

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. 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. 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. 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. Context in XML2Selenium

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. Beginning 

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. DDT in XML2Selenium

27. JUnit as a running runtime Create your own runners Create your own annotations • •

28. CI for your QA framework

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. 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. XML2Selenium roles • Developers of core • Plugin developers • XML2Selenium test developers • XML2Selenium consultants

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. Questions? • Read further at XML2Selenium.com • zmicer@jazzteam.org