XML2Selenium Technical Presentation

1. Why it is created Traditionally many companies doesn’t have enough investments into QA engineers level, but complexity and complication of software products, as well as amount of use cases to be covered grows. Companies meet a barrier, when overall auto-test architecture has the same engineering level as main application. The main problems here are: - how to support and test many installations of product at the side of customer - how to test and make regression of several versions of the same product (branches, releases) - reusability and absence of copy-paste. You always have the same components not only at one product, but at many products at the same company. We need a way to reuse common approaches and best practices - possibility to change test data quickly and effectively (e.g. to use the same code base of auto- tests for different installations of product). Data-driven testing. - availability of auto-testing platform to change values at many controls, and even logic of test cases - a way to control the coverage and make a mapping between automation test cases and real business use cases. Regression and test plan development. Management of automation.

2. Introduction Run of XML2Selenium tests through JUnit

3. How it looks like Use of imports, plugins, includes (frame) and even scripting

4. How it looks like Scripting and JVM parameters. Take a screenshot!

5. How it looks like Imports, tags and different actions

6. How it looks like Inheritance, overriding of attributes

7. How it looks like Inheritance

8. How it looks like Self-diagnosis

9. How it looks like

10. How it looks like Load variables from property file. Self-diagnosis.

11. Introduction Self-diagnosis example. This is how we check framework works.

12. Introduction

13. Introduction Auto-tests project structure

14. Jenkins screenshots Amount of builds, tests, plugins

15. Introduction

16. Introduction

17. Introduction Tree of events

18. Introduction

19. Introduction Building global tree of results for all test cases for further business reporting plugins processing

20. Introduction Making parsing trees Concrete test case name

21. Introduction Output folder for every test Self-diagnosis

22. Introduction Data-driven testing (for which test case which exceptions to have)

23. Business reporting Tag cloud, test cases, tests, description, tests status

24. Business reporting

25. Business reporting

26. Introduction Full mode for exceptions output

27. Introduction User-mode for exceptions

28. Now / User - Possibility for not-programmer to create good tests without copy pasting and which are easy-to-change Scripting inside attributes Contexts for container elements/tag and areas of visibility (the same approach as with programming) Data-driven testing through variables and support of resource bundles (property files) Inheritance, OOP style in XML Business reporting, easy to add new views (e.g. behavior driven testing view). Different from junit reports. No needs to use BDD framework – all is in! Intelligent logging system. Simple and easy-to-understand exception messages. Exception trace contains the full stack of includes Plugins. The base pack for testing web application. Possibility to create new packs of plugins for GUI etc. Screenshot. Snapshot. Video plugin. Test case intelligent validation. - - - - - - - -

29. Now / Technology - Possibility to have self-diagnosis. Tests for platform are written at the same language as UI tests. This means framework could be used for integration tests as well (expected exception/exception message for test cases and tests) Plugins. All is plugins – tags, reports, everything. Very close to eclipse plugin system. Extension points, simple plugin API. Tag-based separation. Repositories of plugins and xml reusable includes = maven + nexus = open source = for free! Selenium integration. But we do not have strict dependency from it, another UI running technology could be added. Junit + Jenkins integration. But again independence from them. Possibility to run framework in any type of runtime, even in web application SAAS/cloud support. Thread saved, you could run many instances of XML2Selenium in many threads. Output data is put to different directories. You could write a test where we run a core of XML2Selenium and then programatically analyze results of it (event based subscription) Busines reports in many formats – tags, bdd, a link to initial XML test case, to snapshots and screenshots, etc. Jaxb based Plugins could be just POJO For not SAAS products (needs installation at customer side) – you could change data input properties and apply them to the same code base of auto XML tests - - - - - - - - - - - - -

30. Future / All - - XML2Selenium platform - we have opportunity to use such tests for load testing We could make remote debug on server side not using java sources, but going through XML test case lines infrustructure - eclipse plugin - simple editor for creating new tests even without knowing xml Validation (including validation of XSD + POJO java beans) data driven testing. Custom randomizers. Plugins. If/For tags. Technical report plugin. Possibility to exchange variables between contexts of tests and scripts (java script and groovy are supported) - - - - - product company - For different releases and versions of product you could have 1 branch of the tests, just making different tests cases for different versions of products