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 autotests 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