Sirius: ice is broken

Pre-phrase

This is the new series of articles dedicated to the Sirius - the new test automation platform development. This is the work I've been doing for several years accumulating different pieces of code with different languages, for different technologies, for different testing types.

The goal of my work is to combine existing solutions under common architecture and represent some unified and extensible design which can be a basis for another brand-new test automation solution or even common platform for delivering test automation types. This is the not the first time I am getting back to this but the more results I get the more different solutions I can integrate under the same framework. I don't expect it to be another widely used platform (I am not even talking about replacement of any vendor tool) but that can be a good prototype. I doubt there were a lot of people who believed in Selenium eight years ago when only some draft version appeared. But take a look at the situation on test automation market now. Selenium became one of the most popular test automation tools and the popularity is growing. Even QTP loses its positions and now it's quite easy to find test automation specialists who are familiar with some popular programming language like Java, C#, Ruby, Python, PHP and many others which were traditionally used for development.

Mostly I'm doing this for the purpose of investigation to find out how the test automation works from inside (actually that was one of the reasons why I created that blog) as well as describe the steps I'm going to perform during development.it is done just for interest, there is no commercial background of it.It should be just accumulation of my experience and my existing solutions which in the future can be grown to something bigger.

Why so Sirius?

I decided to give the platform and name.it is Sirius. Why? No idea, I just like that. So in the future if I mention that name in my blog that would be definitely talk about the platform I am developing.

So, let's get started. Since it's something more that just another library I would give it not only the name but also it should have a logo. Here it is:

Sirius is the star of blue giant type. So, that's why I chose such colors. So, we've just started! It's time to go further.

Backgound.

At the moment there is huge variety of different test automation tools which simulate user interaction with various types of GUI.In addition to the big numbers of vendor tools there are a lot of open libraries with more restricted capabilities but at the same time they have part of the market which is growing.And there's a reason why. Most of vendor tools are usually heavy weight applications written long time ago and using outdated technologies.As the result, tests development experiences problems with inconvenient user interface, restricted library functionality and lack of materials in the network.that's especially true for the tools which use custom programming language. Of course, partially that was compensated with a record and playback capabilities but it's already known fact that record and playback is just a convenient way to to receive some prototype of the test. In order to make well formed test automation solution such feature is not enough. Even more, for large-scale projects it brings more damage than profit.

It has been a long time when it was stated that one of the good test automation practices he is treating test automation process as development. Naturally, test automation passes through the same stages starting from analysis and design to regular execution and maintenance. As the result, a lot of development practices can be involved in test automation as well. That's why more or less modern test automation solutions start using some more less popular programming language. Vendor tools have similar trend. For instance, Rational Functional Tester is Java-based from very beginning, Micro Focus SilkTest has dedicated extensions to develop tests using C# or Java, Test Complete initially had an ability to write tests using multiple different scripting languages with integration with different development environments like Visual Studio. But in the most cases it was just a partial solution because it's too hard to adopt existing heavyweight application to modern needs. At the same time the more and more new solutions appear which are actually some libraries rather than full-featured black box applications. They appear to be easy to use and easy to integrate into into entire test automation solution as they were just small libraries. Within the last five or ten years they became more or less complicated and widely used. Partially, that's because of zero price but anyway modern test automation tends to be more related to development rather than some separate activity. Also that's reflected in growing popularity of Agile methodology where the difference between development and testing activities is minimising and different people combined roles in the entire process.

All the above processes changed the shape of modern test automation and modern test automation solution is rather another software product than as set of scripting and configuration mess. At the same time a lot of solutions which interact with application GUI proved that there is no magic in simulating various clicks and mouse moves. At least it's not something surprising for web applications. Other application types are not yet ready for that but there are some solutions for them as well. But for now they are very fractional and it takes a while to join all those solution within single project. So, the next stage is for the test automation platforms which provide the interfaces for wide range of technologies to be tested. And some work is being done on it.

So, let's start work on something like that. We would see that there's no magic behind user actions simulation just a lot of hard work. But it's needed to be done.

Requirements.

Before starting doing anything we should identify what exactly do we want.So in this chapter we will enumerate all of these requirements to entire platform.

1. The system should be independent on platform (operating system).For now it is enough to restrict those requirements with the PC platforms. Later it can be extended with mobile platforms.
2. The system should support distributed execution. It means that the machine where we start tests is not necessarily the same as the target machine where they will be actually executed.even more, the testing solution should be able to run on several machines simultaneously.
3. The testing platform should support multiple programming languages and should be easy extensible to support any other new language.
4. The platform should be independent on any existing test engine. It means that the core engine shouldn't contain any references or any calls to any existing test engine.
5. The platform should support parallel execution in case tests are running on the same machine.

Technical solution description.

1. The platform consists of two parts: client and server.Server side is responsible for immediate application interaction which contain generic functions which are not bound to any application or system. It shouldn't contain any information about current state of processing.client side is just a library which wraps the calls to server and provides API to users.
2. Server side is represented as collection of SOAP endpoints divided by functional area.Each endpoint has its own web service definition and can be started/stopped/added/removed separately from others. Technological stack:
   1. Programming language: Java
   2. Communication protocol: HTTP/SOAP
3. Client side is represented as collection of classes which represent object model and represented abstraction layer above the service calls.It should be portable to any programming language supported.Each client library should have dedicated build, package, documentation.
4. At this moment all the functionality should be distributed between the following functional areas:
   1. System - groups of functionality responsible for system level operations including process handling, filesystem operations, system related information retrieval.
   2. Win32 - groups functionality responsible for interaction with Windows standard controls
   3. .Net - groups functionality responsible for interaction with any.net controls (Win forms, W PF and others)
   4. Java - groups functionality responsible for interaction with any controls of Java technology (AWT, G WT and others)
   5. web - groups any functionality responsible for interaction with different browsers webpages and controls on them.
   General architecture and overall structure can be represented with the following diagram:
   
5. each server side service should support the ability to call another service (either redirect or distribute execution between different nodes).

So all this leads to 2 ways of client server interaction.those interaction schemes can be represented with the following diagram:

First interaction scheme is commonly used for functional tests where we operate with one server instance at the same time.second scheme is rather used for this performance tests where some of the service nodes are used for tasks generation.

All right, we've identified high-level representation of what we're going to have. Now it's time to implement all this stuff.

Time to go

In the future posts I will describe every step I would go through during development. There would be some tricky cases I have to resolve and they would be interesting not only in the context of work I am doing but also can show you solutions for the problem you can encounter during your work. So, let's do this!