Test Automation

Distributed Test Automation Infrastructure Plan #1

ballsThis post is mainly for those who know how much good can give us the tests automation, trying to apply and increase the quality of its software. However, from the group of potential readers, I does not exclude those who have not implemented this type of solution because they lack a coherent approach to a more complexity infrastructure of such tests. There are two ways of reaching the need to include automated testing in a larger, structuralized process enables extension of the test cases on multiple machines, multiple systems and multiple environments. The first is that resulting from the need to increase the quality of existing, good tests, but still running on the same machine, usually by hand. But once it comes time to another system, another type of processor, more hosts then starts to complicate. The second road leads from the planning phase of the implementation of the tests and thought “Can this be achieved in this particular way, under the 30 different systems, preferably in parallel – but then how to report it all?”
As the first of roads is usually carried out on the type of desktop application, second starts from the network solutions with increased performance requirements.

I do not want to write here about the specific tools that exist, costing tens of thousands of dollars, are very extensive, probably we will use only several percent of their capacity and are usually attached to a test robot.

Generally speaking, we would like to have the “something” with the following characteristics:

  • Architecture of the client – server
  • Works on multiple system platforms: Windows, Linux, Mac, Xbox, etc..
  • Does the testing distribution (mostly scripts), not their implementation
  • Allow the transfer of the implementation of feedback reports
  • Can, using the virtualization run computer (or several) of the desired parameters and then run tests on it
  • Simple API
  • Provide information on whether the machine can still be something to start – CPU and memory load

In my opinion the most important item on above list is talking about the test distribution, not their execution. It is very important that such a tool should elide both from the last chain link in the start-up testing, which is a robot that performs the test as well as from the first: base scenarios, test cases and steps. If we have a separate transport layer that is that the connector, which has a simple API, we can focus on improving the test process (scenarios, coverage etc) than improving test scripts for test robot.

Distribited Test automation diagram
Now we take a look at the list of currently available tools implementing these requirements.

Software Testing Automation Framework STAF / STAX
Framework is developed by IBM but opensource with very fine architecture design based on components called services. Second great stuff is STAX which is an XML, Python based execution engine for STAF. Visit http://staf.sourceforge.net/ for additional info. Eclipse plugin is available.

SmartFrog
HP child, is closer to testing solutions than STAF but require more programing in JAVA. Also based on components which must be written for our testing tasks.
Visit http://smartfrog.org/ for additional info. Eclipse plugin is available.
Google functional testing with SmartFrog – http://video.google.com/videoplay?docid=-4478242864801668108

JTR Project
Java based framework close to J2EE and JEE world. Moder architecture IoC (Inversion of Control) concept. XML configuration but bound to developer side. Visit http://jtrunner.sourceforge.net/JTR/Overview.html for next info.

Ready to use tools for distributed testing:

Now let’s get some time for test and try that frameworks. In next part of this article I will try to give You a answer and ready solution based on opensource, free product. I have some preferences and You ?

Discussion

No comments for “Distributed Test Automation Infrastructure Plan #1”

Post a comment