AutomationSTAR

Test Automation Conference Europe

Fiona Nic Dhonnacha

A Comparison of Automated Testing Tools

This automated testing tools comparison of popular toolsets will help you identify the right automation tool for your project. This is a blog post provided by Rai Kou on EuroSTAR Huddle, our online community for free software testing resources.

A defining factor for successfully applying test automation in software projects is choosing and using the right set of test automation tools. This is a daunting task, especially for those new to software test automation because there are so many tools in the market to choose from, each having different strengths and weaknesses. There is no tool that can fit all automated testing needs which makes finding the right tool difficult. Learn how to identify the right automation tool for your project with this qualitative comparison of popular automated testing toolsets in the market.

Overview of Test Automation Tools

Selenium

Selenium is the most popular automation framework that consists of many tools and plugins for Web application testing. Selenium is known for its powerful capability to support performance testing of Web applications. Selenium is the most popular choice in the open-source test automation space, partly due to its large and active development and user community.

HP Unified Functional Testing (UFT)

Formerly QuickTest Professional (QTP), this is probably the most popular commercial tool for functional test automation. HP UFT offers a comprehensive set of features that can cover most functional automated testing needs on the desktop, mobile and Web platforms.

TestComplete

TestComplete is also a commercial integrated platform for desktop, mobile and Web application testing. Like UFT, TestComplete offers a number of key test automation features such as keyword-driven and data-driven testing, cross-browser testing, API testing and CI integrations. This tool supports a number of languages including JavaScript, Python, VBScript, JScript, DelphiScript, C++Script, and C#Script for writing test scripts.

Katalon Studio

This is an automated testing platform that offers a comprehensive set of features to implement full automated testing solutions for mobile and Web applications. Built on top of the open-source Selenium and Appium frameworks, Katalon Studio allows teams to get started with test automation quickly by reducing the effort and expertise required for learning and integrating these frameworks for automated testing needs.

Test Automation Tools Comparison

The table below provides a comparison of the tools based on the key features of software automation.

Strengths and Weaknesses

Below is a summary of key strengths and limitations of the tools, based on the comparison above.

There is no one-size-fits-all tool for automated testing. It is highly recommended that testers evaluate various tools in order to select what would best meet their automated testing needs. Programming languages and technologies used to develop software continue to evolve, as do the automated testing tools, making cost a significant factor in tool selection.

Commercial vendors often charge for tool upgrades, which can be substantial if your software uses emerging and frequently changing technologies. Open source and non-commercial tools, on the other hand, do not incur additional charges but require effort and expertise for integrating new upgrades. It is difficult to find the support and expertise needed for integrating various tools and frameworks into open-source solutions.

Emerging tools that integrate with open-source frameworks offer a viable alternative to both commercial and open-source automated testing solutions.

Test Automation Framework Architecture Types

This article explains what a test automation framework is and gives examples to consider for your own development projects. This blog provided by Alexandar Pushkarev on EuroSTARHuddle.com, our online community for free software testing resources.

What is a framework?

According to Wikipedia, a framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software [1]. It isn’t the easiest definition to digest, and one can usually struggle to actually tell the difference between a framework and a library. The key difference between framework and library, however, is who calls what. Long story short, when you use library, you call library’s code. In comparison, when you use a framework, it calls your code.

Test automation frameworks are by no means different. In general, a test automation framework is something that allows you to implement application-specific test automation solutions by writing and injecting some additional code. Surprisingly, in the test automation community, by framework, people often mean any test automation solution that happened to have any decent structure and design. Wikipedia also supports this opinion [2].

The most common “architecture type” of a test automation solution I’ve seen was something that could be described as a “big ball of mud“. And, in some cases, it performs just great- such things don’t take ages to implement, and it’s quite easy to support for some short periods of time, if you have a limited amount of tests.

The really challenging question is why and when you need a real test automation framework, and when you may go with the plain “big ball of mud” test solutions.

Start with the question, “why?”

All in all, test frameworks are designed to address following issues:

1. Test complexity

The simpler the test is on the top level, the easier it is to create, understand, communicate and maintain.

2. Test maintenance cost

Test automation isn’t a thing that can be taken for granted; it has a price. One of the most painful prices for test automation is a maintenance cost. Well-designed framework should simplify maintenance.

3. Test execution time

Time is money. Time to get feedback from automated tests is also crucial – one wouldn’t like to wait for several hours, just to check that their commit wasn’t wrong.

4. Reporting

Testing is about not finding bugs or accepting stories. Well, not exactly. What testing’s really about is providing information. A test solution that has simple, maintainable tests – easy to maintain and enhance – may be just thrown away if it produces bad reports that are difficult to understand by non-technical stakeholders.

All things considered, if you don’t plan to have hundreds of complex tests scenarios, your tests are fast, and you’re happy with built-in Xunit framework – you may not need a test automation framework at all. The rule of thumb: the lower test level you’re interested in, the less complex your test automation solution should be. In most cases, you don’t need a framework for unit or integration tests, however you may want one for acceptance tests.

Regardless of what test level you’re interested in, there are some typical framework architectures that can be utilized. Most interestingly, framework architecture isn’t affected by test automation approach applied (keyword-driven, BDD, plain code or whatever), because those approaches affects only some layers (most prominently test layers) and don’t touch others. Let’s then take a look at the most known test framework architectures.

Layered architecture

While test automation frameworks are designed to address issues outlined above, it usually isn’t an overly complex software system. The most commonly known architecture pattern, known as Layered Architecture, is often used as a base for test automation framework architecture.

Components within the layered architecture are organized into horizontal layers, and each layer of the architecture has a specific role and responsibility in the application. Components within a specific layer are supposed to deal only with logic that corresponds to that layers [3].

Three-layered automation framework

The most known and widely used architecture for software test automation solutions is a three-layered architecture; in which the solution is divided into three logical horizontal layers – usually test layer, business layer, and core layer.

In such architecture, a test layer typically contains test scenarios itself, either in programming language or in any other form (like BDD feature files).

Business layer provides system under test (SuT) specific actions. For example, if we’re talking about online shopping, such actions may be ‘log in’, ‘add to cart’, etc.

Core layer is where real framework (who calls your code) really lives, and it deals with test orchestration, reporting and usually also provides low-level API to communicate with tested applications, like web-service facades, Selenium Web Driver wrappers, etc.

In a BDD inspired framework, a test layer will typically contain feature files, a business layer will contain steps definitions, while a core layer contains BDD- framework configuration and core component. For a data-driven framework, a test layer will contain data files, and a business layer will contain mid-level application specific abstractions.

Four-five layered automation framework

In case you may need something more complex, there are several options to enhance framework architecture. One of the options you may choose, is to extract validation code into separate level (or module, to be precise), which will be used by a business layer, while a core layer may provide interface or orchestration for validation.

In case you’re building hybrid framework, you may need a separate layer for data, so your test layer will have data and non-data tests. All this will add complexity to a core layer, so it may also be logical to separate it into several sub-levels at some point.

Plug-able test automation framework

In case your application is even more complex, you may want different validation for different environments, or different ways to communicate with applications for same tests (for example for testing desktop and mobile versions of the webpage). While it is possible to address this by creating sub-modules in core or validation layers, there’s also a neat way to do this completely opaque to the rest of the system. The idea is to use dependency injection and provide plug-able modules for validation and test-application interfacing.

The idea is essentially the same as in previous framework architectures, with only one difference – validation and facades implements the provided interface, which is used by a business layer, and concrete implementation is typically injected without the other layers’ knowledge about what was really injected.

Considerations

While it is often tempting to pick up the most complex architecture (just in case) or the simplest thing (faster to implement), it is often wise to complete some initial investigation of what you need, based on product vision or expected length of life.

Provided architectures are by no means a standard, they are just examples, and you may implement a plug-able three-layered thing, or even identify 7 different hierarchical layers. You may want some event-driven thing for testing of asynchronous workflow.

There are several typical highlights:

1) Try to make tests as simple, short, and atomic as possible. Ideally, tests should tell what’s being done, not how it’s done, and test only one specific things. Typically, the cost of complex test support outweighs benefits of having such tests.

2) Business layer should provide action implementation (how something is done), using interfaces provided by the core layer.

3) Validation layer should provide action implementation using interfaces provided by either core or business layers.

4) Core layer is the framework itself, and may have complex architecture on its own. Its responsibility is to provide interfaces for upper layer, and provide orchestration for test run and reporting. It also often provides low-level implementation for interfaces exposed to upper layers.

There’s no one-size-fits-all architecture, so you may suggest many other ways to separate test logic. The provided examples are just a starting point. What’s important is that you should be able outline the architecture of the solution you are working on, and guess if it fits to the project or application. My personal advice would be – stick to the simplest architecture that fits your immediate needs, but try to leave other options open in case you need them.

[1] https://en.wikipedia.org/wiki/Software_framework

[2] https://en.wikipedia.org/wiki/Test_automation#Framework_approach_in_automation

[3] Mark Richards, Software Architecture Patterns. O’Reilly Media, 2015

Architekturtypen des Testautomatisierungsframeworks

Dieser Artikel erklärt, was ein Testautomatisierungs-Framework ist, und gibt Beispiele, die Sie für Ihre eigenen Entwicklungsprojekte berücksichtigen sollten. Dieser Blog von Alexandar Pushkarev auf EuroSTARHuddle.com, unserer Online-Community für kostenlose Software-Testressourcen.

Was ist ein Rahmen?

Laut Wikipedia ist ein Framework eine Abstraktion, in der Software, die generische Funktionalität bereitstellt, selektiv durch zusätzlichen benutzergeschriebenen Code geändert werden kann, wodurch anwendungsspezifische Software bereitgestellt wird [1]. Es ist nicht die am einfachsten zu verdauende Definition, und man kann normalerweise Schwierigkeiten haben, den Unterschied zwischen einem Framework und einer Bibliothek zu erkennen. Der Hauptunterschied zwischen Framework und Bibliothek besteht jedoch darin, wer was aufruft. Lange Rede kurzer Sinn, wenn Sie die Bibliothek verwenden, rufen Sie den Code der Bibliothek auf. Wenn Sie dagegen ein Framework verwenden, ruft es Ihren Code auf.

Test automation frameworks are by no means different. In general, a test automation framework is something that allows you to implement application-specific test automation solutions by writing and injecting some additional code. Surprisingly, in the test automation community, by framework, people often mean any test automation solution that happened to have any decent structure and design. Wikipedia also supports this opinion [2].

Der häufigste „Architekturtyp“ einer Testautomatisierungslösung, den ich gesehen habe, war etwas, das man als „großen Schlammball“ bezeichnen könnte. Und in einigen Fällen funktioniert es einfach großartig – solche Dinge brauchen nicht ewig zu implementieren, und es ist ziemlich einfach, für einige kurze Zeiträume zu unterstützen, wenn Sie eine begrenzte Anzahl von Tests haben.

Die wirklich herausfordernde Frage ist, warum und wann Sie ein echtes Testautomatisierungs-Framework benötigen und wann Sie sich für die einfachen „Big Ball of Dreck“-Testlösungen entscheiden können.

Beginnen Sie mit der Frage: “Warum?”

Alles in allem sind Test-Frameworks darauf ausgelegt, folgende Probleme zu lösen:

1. Komplexität testen

Je einfacher der Test auf der obersten Ebene ist, desto einfacher ist er zu erstellen, zu verstehen, zu kommunizieren und zu warten.

2. Wartungskosten testen

Testautomatisierung ist keine Selbstverständlichkeit; es hat einen Preis. Einer der schmerzhaftesten Preise für die Testautomatisierung sind die Wartungskosten. Ein gut gestaltetes Framework sollte die Wartung vereinfachen.

3. Testausführungszeit

Zeit ist Geld. Die Zeit, um Feedback von automatisierten Tests zu erhalten, ist ebenfalls entscheidend – man möchte nicht mehrere Stunden warten, nur um zu überprüfen, ob sein Commit nicht falsch war.

4. Berichterstattung

Beim Testen geht es darum, keine Fehler zu finden oder Geschichten zu akzeptieren. Nun, nicht genau. Beim Testen geht es wirklich darum, Informationen bereitzustellen. Eine Testlösung mit einfachen, wartbaren Tests – leicht zu warten und zu verbessern – wird möglicherweise einfach verworfen, wenn sie schlechte Berichte produziert, die für nicht-technische Beteiligte schwer verständlich sind.

Alles in allem, wenn Sie nicht vorhaben, Hunderte von komplexen Testszenarien zu haben, Ihre Tests schnell sind und Sie mit dem integrierten Xunit-Framework zufrieden sind, benötigen Sie möglicherweise überhaupt kein Testautomatisierungs-Framework. Als Faustregel gilt: Je niedriger die Teststufe, für die Sie sich interessieren, desto weniger komplex sollte Ihre Testautomatisierungslösung sein. In den meisten Fällen benötigen Sie kein Framework für Unit- oder Integrationstests, aber vielleicht möchten Sie eines für Akzeptanztests.

Unabhängig davon, an welcher Testebene Sie interessiert sind, gibt es einige typische Framework-Architekturen, die verwendet werden können. Interessanterweise wird die Framework-Architektur nicht durch den angewendeten Testautomatisierungsansatz (schlüsselwortgesteuert, BDD, einfacher Code oder was auch immer) beeinflusst, da diese Ansätze nur einige Schichten (vor allem Testschichten) betreffen und andere nicht berühren. Werfen wir dann einen Blick auf die bekanntesten Testframework-Architekturen.

Geschichtete Architektur

Während Testautomatisierungs-Frameworks entwickelt wurden, um die oben beschriebenen Probleme zu lösen, handelt es sich normalerweise nicht um ein übermäßig komplexes Softwaresystem. Das bekannteste Architekturmuster, bekannt als Layered Architecture, wird oft als Grundlage für die Framework-Architektur der Testautomatisierung verwendet.

Komponenten innerhalb der mehrschichtigen Architektur sind in horizontalen Schichten organisiert, und jede Schicht der Architektur hat eine bestimmte Rolle und Verantwortung in der Anwendung. Komponenten innerhalb einer bestimmten Schicht sollen sich nur mit Logik befassen, die dieser Schicht entspricht [3].

Dreischichtiges Automatisierungsframework

Die bekannteste und am weitesten verbreitete Architektur für Softwaretestautomatisierungslösungen ist eine dreischichtige Architektur; in dem die Lösung in drei logische horizontale Schichten unterteilt ist – normalerweise Testschicht, Geschäftsschicht und Kernschicht.

In einer solchen Architektur enthält eine Testschicht normalerweise selbst Testszenarien, entweder in Programmiersprache oder in irgendeiner anderen Form (wie BDD-Funktionsdateien).

Die Business-Schicht bietet spezifische Aktionen für das zu testende System (SuT). Wenn wir beispielsweise über Online-Shopping sprechen, können solche Aktionen „Anmelden“, „In den Warenkorb legen“ usw. sein.

In der Kernschicht lebt das echte Framework (das Ihren Code aufruft) wirklich, und es befasst sich mit der Testorchestrierung, Berichterstellung und bietet normalerweise auch eine Low-Level-API zur Kommunikation mit getesteten Anwendungen, wie Webdienstfassaden, Selenium-Webtreiber-Wrappern usw.

In einem BDD-inspirierten Framework enthält eine Testschicht typischerweise Funktionsdateien, eine Geschäftsschicht enthält Schrittdefinitionen, während eine Kernschicht die BDD-Framework-Konfiguration und Kernkomponente enthält. Bei einem datengesteuerten Framework enthält eine Testschicht Datendateien und eine Geschäftsschicht anwendungsspezifische Abstraktionen auf mittlerer Ebene.

Vier-fünf-Schichten-Automatisierungsframework

Falls Sie etwas Komplexeres benötigen, gibt es mehrere Optionen zur Verbesserung der Framework-Architektur. Eine der Optionen, die Sie wählen können, besteht darin, den Validierungscode in eine separate Ebene (oder genauer gesagt in ein Modul) zu extrahieren, die von einer Geschäftsschicht verwendet wird, während eine Kernschicht eine Schnittstelle oder Orchestrierung für die Validierung bereitstellen kann.

Falls Sie ein hybrides Framework erstellen, benötigen Sie möglicherweise eine separate Ebene für Daten, sodass Ihre Testebene Daten- und Nicht-Datentests enthält. All dies erhöht die Komplexität einer Kernschicht, daher kann es auch logisch sein, sie irgendwann in mehrere Unterebenen zu unterteilen.

Plug-fähiges Testautomatisierungs-Framework

Falls Ihre Anwendung noch komplexer ist, möchten Sie möglicherweise unterschiedliche Validierungen für unterschiedliche Umgebungen oder unterschiedliche Kommunikationswege mit Anwendungen für dieselben Tests (z. B. zum Testen von Desktop- und mobilen Versionen der Webseite). Es ist zwar möglich, dies durch die Erstellung von Untermodulen in Kern- oder Validierungsschichten anzugehen, aber es gibt auch eine nette Möglichkeit, dies für den Rest des Systems völlig undurchsichtig zu machen. Die Idee besteht darin, die Abhängigkeitsinjektion zu verwenden und steckbare Module für die Validierung und die Schnittstelle zwischen Testanwendungen bereitzustellen.

Die Idee ist im Wesentlichen die gleiche wie in früheren Framework-Architekturen, mit nur einem Unterschied – Validierung und Fassaden implementieren die bereitgestellte Schnittstelle, die von einer Geschäftsschicht verwendet wird, und die konkrete Implementierung wird normalerweise injiziert, ohne dass die anderen Schichten wissen, was wirklich injiziert wurde .

Überlegungen

While it is often tempting to pick up the most complex architecture (just in case) or the simplest thing (faster to implement), it is often wise to complete some initial investigation of what you need, based on product vision or expected length of life.

Vorausgesetzt, Architekturen sind keineswegs ein Standard, sie sind nur Beispiele, und Sie können ein steckbares dreischichtiges Ding implementieren oder sogar 7 verschiedene hierarchische Schichten identifizieren. Möglicherweise möchten Sie eine ereignisgesteuerte Sache zum Testen des asynchronen Workflows.

Es gibt mehrere typische Highlights:

1) Versuchen Sie, Tests so einfach, kurz und atomar wie möglich zu gestalten. Idealerweise sollten Tests sagen, was getan wird, nicht wie es getan wird, und nur eine bestimmte Sache testen. Typischerweise überwiegen die Kosten einer komplexen Testunterstützung die Vorteile solcher Tests.

2) Die Geschäftsschicht sollte eine Aktionsimplementierung bereitstellen (wie etwas getan wird), indem Schnittstellen verwendet werden, die von der Kernschicht bereitgestellt werden.

3) Die Validierungsschicht sollte eine Aktionsimplementierung unter Verwendung von Schnittstellen bereitstellen, die entweder von Kern- oder Geschäftsschichten bereitgestellt werden.

4) Die Kernschicht ist das Framework selbst und kann selbst eine komplexe Architektur haben. Seine Verantwortung besteht darin, Schnittstellen für die obere Schicht bereitzustellen und die Orchestrierung für den Testlauf und die Berichterstellung bereitzustellen. Es bietet auch häufig eine Low-Level-Implementierung für Schnittstellen, die oberen Schichten ausgesetzt sind.

There’s no one-size-fits-all architecture, so you may suggest many other ways to separate test logic. The provided examples are just a starting point. What’s important is that you should be able outline the architecture of the solution you are working on, and guess if it fits to the project or application. My personal advice would be – stick to the simplest architecture that fits your immediate needs, but try to leave other options open in case you need them.

[1] https://en.wikipedia.org/wiki/Software_framework

[2] https://en.wikipedia.org/wiki/Test_automation#Framework_approach_in_automation

[3] Mark Richards, Muster der Softwarearchitektur. O’Reilly Media, 2015

**Dieser Blog wurde von Google aus dem Englischen ins Deutsche übersetzt.

part of the