Why it is createdTraditionally 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.

IntroductionRun of XML2Selenium tests through JUnit

How it looks likeUse of imports, plugins, includes (frame) and even scripting

How it looks likeScripting and JVM parameters. Take a screenshot!

How it looks likeImports, tags and different actions

How it looks likeInheritance, overriding of attributes

How it looks likeInheritance

How it looks likeSelf-diagnosis

How it looks like

How it looks likeLoad variables from property file. Self-diagnosis.

IntroductionSelf-diagnosis example. This is how we check framework works.

Introduction

IntroductionAuto-tests project structure

Jenkins screenshots

Amount of builds, tests, plugins

Introduction

Introduction

IntroductionTree of events

Introduction

IntroductionBuilding global tree of results for all test cases for further business reporting

plugins processing

IntroductionMaking parsing trees

Concrete test case name

IntroductionOutput folder for every test

Self-diagnosis

IntroductionData-driven testing (for which test case which exceptions to have)

Business reportingTag cloud, test cases, tests, description,tests status

Business reporting

Business reporting

IntroductionFull mode for exceptions output

IntroductionUser-mode for exceptions

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.

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

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