Werkzeuge zur Automatisierung von Software Acceptance Test (Abnahmetest)

    Test Automation Tools

Möglichst vollständige Liste aller 2018 verfügbaren Werkzeuge für Testautomatisierung

— zusammengestellt und kommentiert von Gebhard Greiter —


( siehe auch besonders bekannte, in 2008 am häufigsten genutzte, oder durch AcuTest empfohlene ) + Best Practices

Recht interessant ist auch, wie sich das Interesse an einzelnen Testwerkzeugen im Vergleich zueinander entwickelt:
Zahlen dazu finden sich auf Seite Test Automation Trends.

Werkzeug	Anbieter	Zuletzt durch mich betrachtete Version und deren Nützlichkeit (meiner Erfahrung nach):
		Den Test von Software modernsten Typs unterstützen:
BrowserStack	BrowserStack	Automated mobile app testing on real mobile devices. Here you'll find everything you need to test and debug your native, hybrid and web applications on real devices and desktop browsers.
TestProject	Open Tools	TestProject is a free SaaS test automation development framework designed for agile teams! It is built on top of industry standard open source tools, supports all major operating systems, and most importantly it enables a team first approach to test automation that makes it easy for every member of your software team to test Web, Android and iOS apps effortlessly. Using TestProject’s testing repository, teams can easily collaborate, all while locally creating, running and analyzing their test automation. TestProject's mission is to create a powerful and collaborative environment that the entire test automation community can use without any barriers, including the barrier of cost.
JEST	Open Source	Dient dem Test von in JavaScript geschriebenen Web Frameworks
T-Plan Robot Enterprise	T-Plan	T-Plan Robot Enterprise 3.3 (2013) ist an keine bestimmte Plattform gebunden und als einziges aller hier besprochenen Werkzeuge auch geeignet, Apps zu testen, die auf Android, iPhone, Windows Mobile, etc. arbeiten. Genau dieser Eigenschaft wegen erscheint es hier an erster Stelle. Typischerweise entwirft man Testcases, indem man sie per Recorder aufzeichnet und das so entstandene Skript dann von Hand geeignet ergänzt. Es kann dann sogar — automatisch — nach Java umgewandelt werden und so recht gut auch zu Testtreibern für Unit Test führen. T-Plans Skriptsprache ist proprietär, aber ebenso mächtig wie VBScript. T-Plan entstand aus dem Open Source Produkt VNC Robot, dessen letzte Version als T-Plan Robot 2.0.8 immer noch verfügbar ist.
Robotium	Open Source	Robotium is an Android test automation framework that has full support for native and hybrid applications. Robotium makes it easy to write powerful and robust automatic black-box tests for Android applications. Robotium Recorder will allow you to record Robotium test cases in minutes! Zur Einführung lese man Android user interface testing with Robotium (vom Recorder ist darin noch gar nicht die Rede). Noch interessanter ist die Übersicht How to test Android applications with different Android testing frameworks. Entwickler von Android Apps wird interessieren: Unit Test with Android Studio. Lies auch: The Top 5 Android UI Frameworks for Automated Testing (2017).
Visual Studio	Microsoft	VS 2012 (erst ab der Premium Variante) unterstützt sog. Coded UI Test. Man nutzt dazu die .NET 4.5 Bibliotheken unter C# oder VB.NET. Solcher Test führt Aktionen auf der GUI der Anwendung aus mit dem Ziel, korrekte Darstellung ihrer Oberflächenelemente nach Form und Inhalt prüfbar zu machen. Auch Testfall Recording und Umwandlung manueller Tests in automatisierten Test wird unterstützt. Coded UI Test kann datengetrieben sein, denn Studio 2012 bietet die Möglichkeit, dem Testtreiber eine Datenquelle mitzugeben, so dass jede ihrer Zeilen zu einer Iteration (Ausprägung) des logischen Testfalls wird. Auf Basis solcher Treiber kann zudem Last- und Stresstest gefahren werden sowie Load Test mit der Möglichkeit, viele gleichzeitig arbeitende Benutzer zu simulieren, die HTTP-Requests gegen einen beliebigen Web Server absetzen.
RESTEasy	Open Source	Da web-basierte APIs schon in naher Zukunft wohl nur noch REST-basierte Architektur haben werden, sollte man wissen, dass ein frei nutzbares Framework zur Verfügung steht, den Test solcher Schnittstellen per Java zu automatisieren: RESTEasy (von JBoss, aber nicht gebunden an deren Application Server: siehe diese Doku). Wer seine Testtreiber lieber in C# (.NET) schreibt, benutze das noch einfacher zu verstehende Paket RestSharp.
SpiraTest	Inflectra	Wer sich seine gesamte Testumgebung in der Cloud verwaltet wünscht, für den könnte SpiraTest in Kombination mit SpiraTeam interessant sein (siehe auch die Preislisten dazu). Ich selbst hatte bisher keine Gelegenheit, mit dieser Umgebung und ihren Automatisierungswerkzeugen Rapise und Remote Launch zu arbeiten. Wie der Hersteller selbst sie charakterisiert, ist nachzulesen in der recht ausführlichen Präsentation SpiraTest Overview — was ich da lese, scheint mir interessant und auf jeden Fall einer Evaluierung wert.
Selenium	Open source	Selenium unterstützt den Test von Web-Applikationen über deren GUI, und somit die derzeit und in absehbarer Zukunft sicher wichtigste Klasse von Test aus Sicht der Endanwender. Interessant ist, dass Google zunehmend mehr nach Selenium, denn QTP gefragt wird (was, obgleich QTP teuer, Selenium aber frei ist, nicht gerade für ein Nischen-Dasein von Selenium spricht). Wer mit Selenium Webdriver einen ersten nicht ganz trivialen Testfall automatisiert hat, wird dieses Werkzeug als einfach und nützlich erkennen. Spezielle Mechanismen zur Unterstützung von SOAP und WSDL finden sich darin allerdings nicht. Schade ist auch, dass IWebElement keine Methode get_OuterHTML() kennt. ISelenium scheint das mächtigste Interface zu sein (gut dokumentiert in WebDriver.chm für C#, VB, C++). Oft aber reicht es, nur die besonders einfachen Interfaces IWebDriver (repräsentiert den Browser) und IWebElement (repräsentiert je ein HTML Elemente) zu nutzen. Mit dem Selenium-Firefox-Plugin lassen sich Testabläufe aufzeichen, die man – auch modifiziert – dann jederzeit neu starten kann. Links: Selenium — Tutorials and Blogs [1] + BrowserStack on Selenium [N] [2] [3] [4] [5] [P] [J] [H] [6] [s] Siehe auch: Selenium RefCard (2016) Siehe auch: Selenium Tutorials + weitere Siehe auch: Selenium im Robot Framework Siehe auch: Selenium aus VBScript aufrufen Siehe auch: Selenium Cookbook — ein sehr hilfreiches Buch Siehe auch: Selenium via Python Selenium ist auch verfügbar als Cloud Service (wer ihn nur gelegentlich nutzen möchte, kann das i.A. sogar kostenfrei tun). Dieser Service hat ein REST API.
Katalon Studio	Katalon	Katalon Studio — derzeit (2019) kostenlos erhältlich — unterstützt sehr gut das Testen web-basierter Applikationen — siehe Overview — und ist u.A. auch Wrapper um Selenium. Katalon Studio is an all-in-one solution to support testers with limited technical knowledge. Katalon is hiding all technical complexities behind the scene and provides friendly UI with the manual mode (user can drag-drop, select keywords and test objects to form test steps), but still keeps necessary weapons for users who are able to dig deeper into coding with the scripting mode that fully supports development conveniences like syntax highlighting, code suggestion and debugging. Katalon Studio has the capability to record and generate test scripts on both Web and mobile apps. Katalon Studio is certainly helpful because Selenium and Appium are mainly automated testing platform libraries suitable for testers who possess good programming skills and can use an IDE like Eclipse or Visual Studio to import Selenium & Appium libraries (and their dependencies) into a development project, to install necessary unit testing frameworks like JUnit, NUnit and TestNG before starting to write a test case. Lies auch, wie sich Katalon Studio mit seinem kleineren Bruder Katalon Recorder vergleicht. Einen guten Eindruck davon, wie sich z.B. für eine größere Mengen von Microservices per Katalon eine gut wartbare Test Suite aufbauen lasst, gibt Data Driven Test. Katalon ist problemlos erweiterbar durch selbstgeschriebene Java Classes. Galt früher UFT (= QTP) als das mit Abstand nützlichste Werkzeug für Testautomatisierung, scheint nun Katalon auf dem Weg, diese Rolle zu übernehmen. Siehe auch: Handbuch zu Appium und Selenium vs QTP/UFT. Die alte Client/Server-GUI-Technologie allerdings unterstützt Katalon nicht.
Oracle Application Testing Suite	Oracle	Unterstützt alle Aspekte des Testens web-basierter Applikationen (insbesondere auch Lasttest), ist zudem Umgebung für Requirements und Issue Management. Siehe Overview.
Coverty	Coverity	Dieses Werkzeug findet Fehler durch Source-Code-Analyse (nur für C++, C# und Java). Es scheint hierin sehr effektiv zu sein und ist insofern einzigartig, als es auch Sicherheitslücken entdeckt. Lies mehr dazu in Coverities White Paper. Zum Auffinden applikationslogischer Fehler ist Test anderer Art notwendig. Dennoch: Wo eine Anwendung auf Robustheit und Sicherheit getestet werden soll, scheint kein anderes Werkzeug auch nur annähernd so hilfreich wie Coverity.
Free	Open Source	Automation Tools for iOS and Android
Kobiton	Appium	Eine cloudbasierte Plattform, welche den Crowd-Testing-Ansatz unterstützt. Er hat z.B. den großen Vorteil, dass man so eine App besonders einfach auf allen gängigen Smartphones getestet bekommt.
		Enterprise Integration Test scheint gut unterstützt durch:
Citrus	Open Source	The Citrus framework gives a complete test automation tool for integration testing of enterprise applications. You can test your message interfaces to other applications as client and server. Regression testing and continuous integration seem easy using Citrus because it fits into your build lifecycle as usual Java unit test. You can use Citrus with JUnit or TestNG in order to integrate with your application build. With powerful validation capabilities for various message formats like XML, CSV or JSON Citrus is designed to provide fully automated integration tests for end-to-end use cases. Citrus effectively composes complex messaging use cases with response generation, error simulation, database interaction and more. Test cases can be implemented in either XML or Java. During test Citrus simulates all surrounding interface partners (client or server) without any coding effort. With easy definition of expected message content (header and payload) for XML, CSV, SOAP, JSON or plaintext messages Citrus is able to validate the incoming data towards syntax and semantics.
		Wichtige Ressourcen für Security Test:
Free	Open Source	The OWASP Testing Guide, /LV
Free	Open Source	125 Network Security Tools
Free	Open Source	KALI Linux for advanced Penetration Testing
		The OSWE – A Real World Penetration Testing Certification
		Nun aber zu Testwerkzeugen, die sich vor allem auch auf Software anwenden lassen, die nicht auf Basis modernster Architekuransätze entwickelt wurde. Am breitesten aufgestellt ist man hier sicher mit den Test-werkzeugen von HP, insbesondere mit QTP: Universelle Testunterstützung bieten:
HP QuickTest Professional (QTP)	HP, nun MicroFocus	QTP und sein Nachfolger UFT scheinen nun » Micro Focus « zu gehören und dort zentrale Komponente des Pakets » Business Process Testing « zu sein. Die folgende Charakterisierung von QTP und UTF resultiert aus Erfahrungen bis etwa 2011: QTP 11.0 – man kann es einzeln — als QTP Essentials — oder kombiniert mit HP Service Test kaufen (d.h. als HP Unified Functional Testing Software: HP UFT oder sogar als HP UFT mobile, was auch den Test auf Smartphones genutzter Apps unterstützen möchte und so zu T-Plan konkurriert). In Kombination mit HP Service Test unterstützt QTP alles, was irgendeines der weiter unten genannten Werkzeuge kann. Selbst die SAP GUI ist damit problemlos aufrufbar. In Form des umfassenden Gesamtpakets HP UFT wird selbst noch Integrationstest in SOA-Architekturen gezielt unterstützt (siehe profi.com). Somit sehe ich HP Unified Functional Testing — eindeutig und mit Abstand — als die beste Wahl, insbesondere dann, wenn man Applikationsschnittstellen unterschiedlichster Art anzusprechen hat. Da QTP über VBScript gesteuert wird, lässt sich jeder Testtreiber mit jedem anderen kombinieren, d.h. aus ihm heraus mit aufrufen. Das gilt auch für ohne Hilfe spezieller Testwerkzeuge erstellte API Treiber, die – als EXE – dann sogar in jeder nur denkbaren Programmiersprache geschrieben sein dürfen. Mindestens einen Mitarbeiter, der sich selbst zu einem Experten für die Nutzung der Möglichkeiten dieses Werkzeugs macht, braucht man dazu aber schon. Er muss Program­mier-Erfahrung haben (um mit VBScript gut umgehen zu können), siehe z.B. [1] und [2]. Zum Einstieg helfen Erste Schritte mit HP UFT 11.5 und das Buch The UFT API Testing Manifesto. Lies auch: UFT/QTP Tutorials und UTF/QTP vs Selenium Sich von QTPs Object Repository abhängig zu machen, kann zu Schwierigkeiten führen (es enthält beim Recording entstehende GUI-Beschreibung). Man kann allen Scriptcode so gestalten, dass er diese Beschrei­bungen nicht nutzt. Sie nicht zu nutzen, erscheint zunächst schwieriger, macht die Treiber auf Dauer aber transparenter und daher besser wartbar. Geld für das allumfassende Gesamtpaket HP Unified Functional Testing Software auszu­geben, bevor man gelernt hat mit HP QuickTest (QTP) gut umzugehen — und bevor man sicher ist, dass dieses Werkzeug durch zahlreiche Mitarbeiter auf lange Zeit hin genutzt werden wird —, macht in meinen Augen keinen Sinn (ganz sicher nicht für kleinere Unternehmen, einzelne Arbeitsgruppen oder gar nur einzelne Pro­jekte). Zur Durchführung von Lasttest nutze man HP LoadRunner (den de-facto Standard). Ihn kennen zu lernen, betrachte man zunächst die kostenfrei verfügbare HP LoadRunner Community Edition (sie erlaubt 50 parallel arbeitende User zu simulieren). LoadRunners Konkurrenten sind: SilkPerformer (den manche Experten als noch besser empfinden; er ist zudem SAP-zertifiziert) sowie Web Performance (einfacher und kostengünstiger) und WebLOAD, nun aber vor allem Apache JMeter, mehr dazu in [1]. Zum Test der Performanz mobiler Applikationen offeriert HP als dediziertes Werkzeug HP Mobile Load. Ähnlichem Zweck wie HP QuickTest oder HP Service Test dienen folgende Produkte (die ich aber — Rapise und TestComplete mal ausgenommen — sämtlich als dem HP Produkt weit unterlegen sehe): | Zur systematischen Verwaltung riesiger Mengen von Test Cases gab es HP Quality Center (nun von Microfocus angeboten als HP ALM Quality Center). Vorsicht aber: Wo es nur um die Verwaltung einzelner Testprojekte geht, kann man sich mit Recht auf den Standpunkt stellen, dass das schwerfällige HP Quality Center die Tester eher behindert als ihnen hilft. Man braucht es nicht unbedingt.
TestComplete	SmartBear Software	TestComplete erinnert insofern an HP QTP, als man neue wie alte GUI-Technologien unterstützen möchte (nur SAP GUI scheint ignoriert zu werden). Mit TestComplete lassen sich .NET Applicationen testen ebenso wie z.B. Delphi-Anwendungen (für die man sonst wohl kein Testwerkzeug mehr findet). Ein ganz andere Frage aber ist, ob sich Testautomatisierung alter Client-Server-Applikationen denn über­haupt noch lohnt ... Da ich QTP genau, TestComplete aber nur von Produktbroschüren her kenne und da das Produkt auch aktuelle Applikationsarchitekturen unterstützt, wundert mich, dass es neben Mercury/HP QTP nie eine Rolle gespielt hat. Woran mag das liegen? Siehe Vergleichsbericht, aber auch drei Notizen über schlechte Erfahrungen bis hin zu Version 8. Wie man per TestComplete über EXCEL-Sheets parametrisierte Testsuiten entwickelt — sog. data-driven Test — ist sehr schön erklärt in SmartBears Webinar. Man erkennt daraus, dass TestComplete ebenso mächtig ist wie HP QTP (im Sinne dessen, was kompetente Testautomatisierer damit erreichen können). TestComplete ist ohne Zweifel eines der nützlichsten Testwerkzeuge überhaupt. Wer sich dafür entscheidet, wird für jede Testautomatisierungsaufgabe gut gerüstet sein. Den Einstieg erleichtern eBooks on Test Complete, ein Cookbook und White Papers wie etwa das zu HTML5 GUI Test. Siehe auch [1], [2], [3] und andere Seiten des umfangreichen, ausführlichen Handbuchs (dessen Seiten sich aber leider nur träge öffnen). Besonders nützlich: Man kann Testrahmen in C# implementieren, die alle durch TestComplete gegebene Funktionalität zu nutzen in der Lage sind (sog. Connected Applications).
Rapise	Inflectra	Existiert seit 2006, scheint vor allem (aber nicht nur) den Test von Webapplikationen sehr gut zu unterstützen. Mit Rapise arbeitet man ganz ähnlich wie mit HP QTP, Programmiersprache ist JScript (statt dort VBScript). Support für SAP GUI scheint zu fehlen. Wohl nach dem Vorbild von HP Quality Center offeriert Inflectra auch eine Umgebung für Requirements, Test, und Issue Management: SpiraPlan, SpiraTest, SpiraTeam.
		Keineswegs zu jedem Projekt (oder Team) passen:
IBM Rational Service Tester for SOA Quality	IBM Rational	2008 – IBM sagt: Service Tester for SOA Quality is a tool for ensuring the quality of web service based SOA applications.-
IBM Rational Robot	IBM Rational	2006 (Vers. 7.0) – dient dem Test klassischer Client Server Applikationen Dieses Produkt wurde 2006 durch wenige Hilfsfunktionen rein technischer Art erweitert, scheint sich ansonsten aber schon seit 2003 nicht mehr fortentwickelt zu haben, ist nun Teil von IBM Rational Functional Tester Plus:
IBM Rational Functional Tester	IBM Rational	2010 (Vers. 8.2) – ist einer der beiden Teile von IBM Rational Functional Tester Plus, unterstützt auch SAP GUI. Note: Ende 2012 hört man, SAP-Unterstützung sei nicht mehr gegeben, da keine Partnershaft mit Worksoft mehr bestünde. Bei Bedarf also gezielt danach fragen!
Testing Anywhere	Automation Anywhere	7.0 – ist weniger nützlich als QTP (aber kaum einfacher)
Worksoft Certify	Worksoft	2010 – Worksoft Certify is an automated functional testing solution for SAP lifecycle management and cross-platform business process validation.
SilkTest	MicroFocus	War urspünglich ein Produkt von Borland, unterstützt jetzt gezielt auch SAP. Insbesondere SilkPerformer — ein Werkzeug für Lasttest — erscheint vielen Testern als sehr gelungen und hilfreich.
TOSCA Testsuite	TRICENTIS Technology & Consulting	7.2.2 – hiermit lassen sich nur Testfälle bauen, die sehr wenig bewirken: Umfangreiche Prüfungen vorzu­nehmen — solche also, die Kontextwissen erfordern — ist unmöglich. Positiv nur: TOSCA unterstützt auch den Test von Anwendungen, die man als Anwender per SAP-GUI bedient. Da die Komplexität unterstützter Testfälle extrem begrenzt ist, frage ich mich, wie sich bei Einsatz von TOSCA ein akzeptables Kosten/Nutzen-Verhältnis ergeben kann.
expecco	eXept Software AG	2012 – Dieses Werkzeug will — wie TOSCA — den Tester davon befreien, den die Testfälle realisierenden Code sehen zu müssen. Mit expecco allerdings lässt sich das erreichen ohne sich damit in eine Sackgasse zu begeben: Durch expecco verwaltete und aufrufbare Testschritte können in frei wählbarer Programmier­sprache implementiert sein. Dies spricht auch dann noch für das Produkt, wenn man — wie ich etwa — nicht so recht daran glauben mag, dass man Testtreiber, die nicht-triviale Fehler finden sollen, mit einer an UML erinnernden Methodik einfach zusammenklicken kann. Zum Aufzeichnen von Test für web-basierte Anwendungen ist Selenium RC in expecco integriert. Als in Smalltalk/X implementiertes Werkzeug arbeitet expecco auf MS Windows ebenso wie auf jeder UNIX-basierten Plattform. Informative, für jeden verständliche Testreports lassen sich empfänger-spezifisch konfigurieren. Wer als Format CSV wählt, kann sie sogar noch automatisch lesen und weiter verarbeiten. Welche Art von Anwendungen auf welchen Plattformen expecco unterstützt, wird wohl noch am ehesten klar auf Seite Unterstützte Technologien. Siehe auch die (allzu knappe) Online Docu zu expecco — Installationen des Produkts enthalten weitere, dann eher hilfreiche Dokumentation. Selenium-supported Test Frameworks
	Wichtiger Hinweis:	TOSCA und (auf andere, weniger radikale Art) expecco unterscheiden sich von anderen Test­frameworks vor allem dadurch, dass ihre Hersteller glauben, es könne Sinn machen, Testauto­ma­tisierung auch durch Tester durchführen zu lassen, die nicht programmieren können oder wollen. Meine Ansicht: Das geht meist schief insofern, als dann entweder nur allzu triviale Testtreiber entstehen oder, wo Tester dem entgegenwirken wollen, sie zunehmend mehr mit dem Werkzeug selbst zu kämpfen haben werden (so dass eben dieses Werkzeug ihr Tun dann recht schnell auf diese zweite Weise allzu ineffizient macht). Die Rollen Tester und Testautomatisierer zu trennen (wie eXept das tut), finde ich dennoch gut. Ich würde lediglich dazu raten, dass Tester, deren Nützlichkeit vor allem darin bestehen soll, dass sie die Fachlichkeit der zu testenden Applikation sehr genau kennen, von der Pflicht, Test zu auto­matisieren, ganz befreit werden: Es reicht, wenn sie ihn aufrufen können und in der Lage sind, den Test­automatisierern hinreichend genaue Vorgaben fachlicher Art zu machen.
Axe	Odin	2010 – Test Cases werden in EXCEL Tabellen spezifiziert (aber wie genau?). Scheint, da Scripting nicht unterstützt ist, ähnliche Grenzen zu haben wie TOSCA, kann sich aber — ganz anders als TOSCA — auf andere Testwerkzeuge abstützen.
TestDrive	Original Software	Nach Gartner (Jan 2011) hat TestDrive neben TOSCA von TRICENTIS die niedrigste "ability-to-execute" unter allen 2010 von Gartner betrachteten "Integrated Software Quality Suites". Interessanterweise besteht die "Vision" beider Werkzeughersteller darin, zu glauben, dem Test­auto­matisierer wäre am ehesten mit "code-free testing technology" gedient – was mir als ein für ihre Kunden ganz verhängnisvoller Irrtum erscheint, denn tatsächlich gilt: Erfolgreich (und sein Geld wert) kann ein Testautomatisierer nur sein, wenn ihm eine Programmiersprache zur Verfügung steht, am besten ein einfache, aber dennoch mächtige Skriptsprache. Siehe hierzu auch "Test Automation Reality" von Carl Nagle.
SOAPSonar (Automation Edition)	Chrosscheck Networks	2010 – unterstützt Automatisierung des Tests web-services-basierter SOA Anwendungen.
Parasoft SOAtest	Parasoft	9.0 – kenne ich nicht, scheint aber sehr interessant, unterstützt auch Lasttest, Komponententest und — als einziges aller hier genannten Produkte — automatisches Erstellen von Testtreibern für Security Test (penetration testing). Im Tools Journal liest man: Parasoft SOAtest automates web application testing, message/protocol testing, cloud testing and security testing. Parasoft SOAtest and Parasoft load test (packaged together) ensure secure, reliable, compliant business processes and seamlessly integrate with Parasoft language products (e.g., Parasoft Jtest) to help teams prevent and detect application-layer defects from the start of the SDLC. Some features are client/server emulation, multi-layer verification, test case organization, regression testing, automatic test case generation, and coding standard enforcement. ABER: Was "ability-to-execute" betrifft, hat Gartner in 2011 Parasoft als recht schwach eingestuft (s.u.). Fehlt vielleicht eine Scripting-Schnittstelle?
QF-Test	Quality First Software GmbH	GUI-Test ist gut unterstützt für Anwendungen, deren GUI in Java-Technologie (Swing/Eclipse, SWT, JavaFX) implementiert ist, web-basiert und zugeschnitten auf MS Internet Explorer, Firefox, Chrome, Edge, Opera oder Safari. QF-Test passt zudem zu Electron, Webswing und JPro. Aber auch Android Apps und Windows-Anwendungen können getestet werden. Als Scripting Interface steht eine per Jython, Groovy oder JavaScript aufrufbare Bibliothek hilfreicher Funktionen zur Verfügung. Selbst geschriebene Java Classes sind ebenfalls aufrufbar. Auch eine Batch-Schnittstelle zum Aufruf der Test Cases existiert. Dieses Werkzeug ist auf MS Windows ebenso einsetzbar wie direkt über Unix oder Linux und macOS. Warum er QF-Test besser fand als den einst recht bekannten WinRunner, beschrieb 2006 Mark Michaelis in einem Evaluation Report. Siehe auch weitere Studien, insbesondere eine von Siemens. Bemerkenswert ist, dass QF-Test mit dem GUI-Code der Anwendung so perfekt zusammenarbeitet, dass gelegent­liches Fehl­verhalten des Testwerkzeugs (wie man es z.B. von HP QTP her kennt) überhaupt nicht vorkommt.
Ranorex	Ranorex GmbH	Ranorex unterstützt Recording und Ergänzen des aufgezeichneten Codes von Hand. Genauer: Durch Recording entstandener Code kann — in jeweils eigenen Dateien — durch sog. Usercode (geschrie­ben in C# oder VB.NET) ergänzt werden. Er kann auch durch Abändern aufgezeichneten Codes entstehen. Will man Test um von Hand codierte Aktionen erweitern oder bestehende Aktion verändern, erstellt man neue User Code Actions oder macht aus schon existierenden Aktionen User Code Actions. Damit ist von Hand fortzuschreibender Code stets klar getrennt von Code, den erneutes Recording zu ersetzen hätte. Möglich sind auch Testtreiber, die gar keinen durch Recording entstandenen Code enthalten. Mit Ranorex lassen sich nicht nur .NET-Anwendungen, sondern z.B. auch Anwendungen mit SAP-GUI, Anwendungen von Oracle ERP und sämtliche in Java oder Delphi geschriebenen Anwendungen testen.
WebUI Test Studio	Telerik, Inc.	2011 – dient dem Test webbasierter Dialogschnittstellen (auch solchen, die mit Silverlight arbeiten). Seine Stärken und Schwächen sind ähnlich denen von Ranorex (man programmiert in C# oder VB; Kern des Produkts ist eine in .NET programmierte Bibliothek WebAii, deren Sourcecode man nicht bekommt. Mit darin enthalten ist eine Funktion zum Erstellen von Bildschirm Snapshots).
Robot Framework	Open Source	Sehr gut dokumentiertes, frei verfügbares Testwerkzeug (entwickelt und supported by Nokia Siemens Networks): Testcases werden in Tabellenform spezifiziert und automatisch interpretiert.
Sahi Pro	Tyto Software	2011 (Vers. 3.6) – unterstützt nur Web-Applikationen. Testtreiber werden in Sahi Script (Open Source) geschrieben. Eigene Befehle zum Zugriff auf das DOM kann man – als JavaScript function – selbst schreiben und dann aufrufen wie eine durch Sahi definierte Methode. Siehe auch: Data Driven Testautomation with Sahi (Samples) und Sahis Grenzen.
TestPartner	Micro Focus	6.3 – zu einseitig und weniger nützlich als QTP (aber kaum einfacher)
Visual Studio Test Professional	Microsoft	2010 – zu speziell, scheint für Acceptance Test nicht geeignet
SAFS	Open source	2011 – SAFS ist ein Framework, welches gestatten sollte, portable Testtreiber zu schreiben: Mindestens solche, die man auf Basis von IBM Rational Robot ebenso wie auf Basis von IBM Rational Functional Tester ausführen kann. Mittlerweile werden auch TestComplete (von SmartBear Software) und Selenium mit unterstützt. Mindestens wer eines dieser Produkte nutzt, könnte dann also auch an SAFS interessiert sein. Lesenswertes zu seiner Geschichte (und Intention) findet sich hier.
Canoo WebTest	Open source	2008 – Freeware, unterstützt nur Web-Applikationen (HTTP-basierte GUI). Test Cases werden in XML spezifiziert. Man muss also zunächst eine einfachere Notation finden und Hilfswerkzeug, welches sie nach XML umsetzt. Mit den zur Verfügung gestellten Befehlen kann man Eingaben tätigen, Buttons und Links anklicken sowie in der dann hochkommenden nächsten Seite die Existenz beliebiger Texte und XPath-Ziele verifizieren. Trotz seiner etwa 100 Befehle scheint WebTest weniger mächtig als Sahi Script.
Abbot	Open source	2008 – Seine Hersteller sagen: Abbot lets you programmatically drive UI components implemented in Java (AWT or Swing), and Costello — built on Abbot — allows you to easily launch, explore and control an application. The framework may be used with both scripts and compiled code.
WATIR	Open source	2011 – schon recht alte Freeware, mit der man web-basierte Dialogschnittstellen triggern und auslesen kann (als Scriptsprache dient Ruby), hat als Werkzeug keine Zukunft.
HTTP Test Tool	Open source	2011 – Freeware, unterstützt nur HTTP-Applikationen und kann (als kleine Utility) nur im Ausnahmefall nützlich sein.
AutoIt	Open source	Seit Version 3.2 enthält die Skriptsprache AutoIt — als sog. User-defined Function (UDF) — die Bibliothek IE.au3, mit der sich der Zugriff auf Webseiten per MS Internet Explorer sehr gut automatisieren lässt. Wer sich ernsthaft mit AutoIt befassen möchte, findet über DMOZ ein noch unfertiges, aber dennoch hilfreiches Buch dazu. Darüber hinaus enthält AutoIt.chm (Teil der AutoIt3 Installation und gemeinsamer Index zu AutoIt3.chm und UDFs3.chm) gute Dokumentation jeder einzelnen Funktion. Leider ist AutoIt eine Insellösung, da die Funktionalität der UDFs nicht über VBScript aufrufbar zu sein scheint (warum der Autor eine eigene, dem VBScript recht ähnliche Sprache erfand, ist nicht wirklich verstehbar — immerhin aber stellt er die Funktionalität von AutoIt3 selbst auch per DLL zur Verfügung: siehe AutoItX).
Perl	Open source	Wer Test mit Hilfe der Skriptsprache Perl automatisieren möchte (was ich nicht empfehlen würde), kann über die Bibliothek Win32::IEAutomation auf Webapplikationen zugreifen. Wie Roland Schmitz mir schrieb, werden alternativ dazu auch WWW::Mechanize oder WWW::Mechanize::Firefox gerne genutzt.
Weitere ...	Open source	Für eilige Leser: Kurzer Vergleich zwischen Ranorex, QTP (= UTF) und Selenium. Hier eine Liste weiterer Test Utilities: Die meisten werden nur in seltenen Ausnahmefällen nützlich sein (er­gänzend zu einer allgemeineren Plattform), andere aber — mindestens SoapUI und TestLink — unterstützen mögliche Schwerpunkte der Testaufgabe und sind daher (als Spezialisten) fast unentbehrlich. Gemeines Merkmal aller ist, dass sie sich nicht ausschließlich auf Black Box Test konzentrieren: Smartphone Apps zu testen, siehe auch Containers JUnit for testing multithreaded Code soapUI — for testing SOAP and REST-based Web services HttpMaster — for testing Web Requests SAP eCATT iMacros, see also: Web Scripting with iMacros (via COM Interface) Yasca for Code Analysis cppcheck sehr gut: erkennt so manchen Buffer Overrun schon in Sourcecode (!) Page Speed – Google's online Page Implementation Review Tool (und mehr) Advanced REST Client — um genau zu sehen, was der Aufruf eines REST APIs produziert SoapUI and LoadUI (siehe auch Soap UI Pro) ABTools – bestens zum automatischen Erstellen von Screenshots pywin JWebUnit – ein Java API um Webanwendungen per GUI zu triggern und auszulesen xUnit – Unit Test for .NET appications (hat NUnit ersetzt) Abbot — Classes for Java-based GUI and unit test JUnit or TestNG – Unit Test for Java Applications, add Hamcrest (matcher functions) JUnit Rules (for Java 8 or later) WindowTester: Teil der frei verfügbaren, Eclipse-basierten, Google Java Developer Tools QUnit – Unit Test for JavaScript WinTask – nicht nur, aber auch für Test UI Automation for .NET (Microsoft) WebDriver support for Internet Explorer (Microsoft, 2014) GUI Test Automation per Windows Powershell Test Automation for ASP.NET AJAX Microsofts Ansatz: das Windows Automation API (nur für geübte C/C++ Entwickler) Die einzige mir bekannte Anwendung dieser durch Microsoft bereitgestellten Basisfunktionalität ist das Open Source Paket TestStack White (Core). Allerdings scheint derzeit (Mitte 2014) nur ein einziger Entwickler daran zu arbeiten. Er schreibt: Microsoft introduced a number of interesting technologies with .NET 3.0 including WPF, WCF and WF that have generated a lot of noise. But also quietly included what was a powerful technology, UI Automation (UIA), which slipped under many people's radar. UIA is a .NET library that allows you to identify UI controls, get their property values and manipulate them on Windows platform. It represents a big step towards having a usable programmatic interface to the Window's UI. Prior to UIA one could have used the Windows Message API, but it dealt with very low level C functions. As one would expect, functional test automation is a natural way in which such a library can be used. White does that. White supports functional testing for Win32, WinForm, WPF and SWT applications. White also makes use of the Windows Messages where UIA doesn't provide all the required support. Erste, noch kaum brauchbare, Fragmente einer Dokumentation von White finden sich hier. DalekJS — for automated cross browser testing with JavaScript (siehe Kommentar) HttpUnit HTTPie — Use it for CLI interaction with web services HttpClient Html Agility Pack (HAP) for HTML Scraping, see also this CasperJS und seine Basis PhantomJS Slimdog Mocha — a Testframework for JavaScript FEST (ein API zum Test Swing-basierter GUIs) GUIdancer for automated test via GUI by people who do not like to write code (!) Maveryx and Jubula – Open Source products to automate the Test of Java Applications —            keines von beiden scheint mir auch nur annäherend so nützlich wie QF-Test (s.o.) Jacareto is an Open Source capture & replay tool for programs written in Java. Robot Framework (Nokia Siemens Networks 2008-2011, mit sehr gutem Handbuch) Wie man Web Services testet, die man nur per WSDL kennt LinqPad um LINQ Queries interaktiv zu testen (oder LINQ zu lernen) Fiddler um beim Test HTTP Traffic beobachten zu können smtp4dev zum Test von Programmen, die eMails senden Test Generator for Java Applications — a console application TestLink (ein Test-Management-Tool, das ich lieber nutze als HP Quality Center) Web QA Test Tools Viele weitere ..., siehe auch hier und hier. Guru's Liste der angeblich "20 best" Test Automation Tools How to choose Test Automation Tools Hilster offers a Tool for automizing the Test of Embedded Systems 12 free tools for API design, development, and testing Tools for Penetration Test (A) — see Cheat Sheet Tools for Penetration Test (B) + /more + Weitere kleine Tools Um Anwendungen auf ihre Robustheit gegen SQL Injection zu testen, verwende man z.B. SQLmap. Mehr dazu — und auch noch zu anderen solcher Tools — findet sich gesagt auf den Seiten [PT] und [CW]. | Warum Tester in Konkurrenz zu einander arbeiten und entlohnt werden sollten Glossar: Begriffe, die jeder Tester kennen sollte Kurzanleitung für Tester und Test Manager — der  p r a x i s r e l e v a n t e  Teil von ISTQB The OWASP Web Security Testing Guide + /tools Main tools for wireless penetration tests Common Software Testing Mistakes Mindestumfang eines SOA Test Modells The Practical Test Pyramid German Software Testing Blogs + For Rookies | End-to-End-Test: ein Erfahrungsbericht (Bachelorarbeit). Zudem hilfreich: A Comparison of Automated Testing Tools (2017) | Testwerkzeuge, auf die Entwickler gelegentlich hinwiesen: Testing Board — Their List of Testautomation Tools Open Source Testing Tools for Web and Mobile Apps Mobile App Testing Tools for both Android and iOS Portswigger's Burp – Tools and Knowhow for Security Test | Was aktuellere Reviews der Landschaft aller Testwerkzeuge sagen Top Software Test Automation Software of 2020 — Gartner Peer Insights Test Automation Landscape 2020 Report Top 10 API Testing Tools (Details & Updates Done for You!) Top 15 Mobile Testing Tools for 2021 (Latest Update) EDUCBA's List of Test Automation Tools

Gesamteindruck:

Wer Tools zur Automatisierung von Black Box Test (Acceptance Test) für Applikationen jeder Art sucht — ActiveX, Fat Client, Thin Client, SAP, SOA — der wird wohl nur bei HP und IBM fündig.

Nur HP allerdings bietet solche Werkzeuge in optimal integrierter Form an (Integrationsrahmen ist QTP's VBScript Interpreter).





Wie Forrester die "ability to execute" der wichtigsten Player einschätzt, zeigt eine Liste auf Seite 11 in Forrester's Report (2015).
Parasoft, Smartbear, Testplant und Tricentis sind auch dort als Schlusslichter eingestuft.
Dass Parasoft dennoch "a very strong product offering" attestiert wird, scheint mir ein Widerspruch dazu.

Test erfolgreich zu automatisieren ist schwierig:

Experten wissen: Wird nur per GUI getestet, verlaufen 75% aller Testautomatisierungsprojekte im Sande.

Wer denkt, es würde reichen, allen Testern im Unternehmen eines der oben genannten Werkzeuge zur Verfügung zu stellen, wird meist schon Monate später merken, dass das nicht funktioniert hat: Die meisten Tester werden mit dem Werkzeug nicht wirklich gut klar kommen und werden zu viel Zeit damit verschwenden, mit ihm zu kämpfen. Testfälle, die sie damit erstellen, werden allzu trivial (und daher wenig nützlich) sein.

Dies zu vermeiden sollte man das Werkzeug zunächst nur zwei oder drei Personen verfügbar machen, die man zu Test-Automatisierern ausbilden möchte. Sie sollten einige Monate Zeit bekommen, ein unternehmensweit anwendbares Nutzungskonzept für das Werkzeug zu erstellen und seine Nützlichkeit zu beweisen, indem sie eine Reihe typischer Testfälle in einheitlicher Form automatisieren (und das auch in der Absicht, anhand die­ser Beispiele dann später die eigentlichen Tester in den Gebrauch des Werkzeugs und der inzwischen entstandenen Hilfsfunktionen — man nennt jene ein Testframework — einführen zu können).

Erst wenn anhand dieses Frameworks auch einige wirklich komplexe Testfälle erfolgreich automatisiert sind,
macht es Sinn, das Werkzeug allen Testern verfügbar zu machen.
Das kleine Team der Test-Automatisierer (bzw. Framework-Entwickler) muss dennoch bestehen bleiben: Sie werden gebraucht, das Framework zu pflegen und bei Bedarf auch fortzuentwickeln.

Geht man anders vor, so wird fast sicher passieren, was Carl Nagle (ein Mitarbeiter von SAS) beobachtet hat:

Case Study: Costly Automation Failures

"In 1996, one large corporation set out evaluating the various commercial automation tools that were available at that time. They brought in eager technical sales staff from the various vendors, watched demonstrations, and performed some fairly thorough internal evaluations of each tool.

By 1998, they had chosen one particular vendor and placed an initial order for over $250,000 worth of product licensing, maintenance contracts, and onsite training. The tools and training were distributed throughout the company into various test departments — each working on their own projects. None of these test projects had anything in common. The applications were vastly different. The projects had individual schedules and deadlines to meet.

Yet, every one of these departments began separately coding functionally identical common libraries. They made routines for setting up the Windows test environment. They each made routines for accessing the Windows programming interface. They made file-handling routines, string utilities, database access routines — the list of code duplication was disheartening!

For their test designs, they each captured application specific interactive tests using the capture/replay tools. Some groups went the next step and modularized key reusable sections, creating reusable libraries of application-specific test functions or scenarios. This was to reduce the amount of code duplication and maintenance that so profusely occurs in pure captured test scripts. For some of the projects, this might have been appropriate if done with sufficient planning and an appropriate automation framework. But this was seldom the case.

With all these modularized libraries testers could create functional automated tests in the automation tool's proprietary scripting language via a combination of interactive test capture, manual editing, and manual scripting. One problem was, as separate test teams they did not think past their own individual projects. And although they were each setting up something of a reusable framework, each was completely unique — even where the common library functions were the same! This meant duplicate development, duplicate debugging, and duplicate maintenance. Understandably, each separate project still had looming deadlines, and each was forced to limit their automation efforts in order to get real testing done.

As changes to the various applications began breaking automated tests, script maintenance and debugging became a significant challenge. Additionally, upgrades in the automation tools themselves caused significant and unexpected script failures. In some cases, the necessity to revert back (downgrade) to older versions of the automation tools was indicated. Resource allocation for continued test development and test code maintenance became a difficult issue. Eventually, most of these automation projects were put on hold. By the end of 1999 — less than two years from the inception of this large-scale automation effort — over 75% of the test automation tools were back on the shelves waiting for a new chance to try again at some later date."

Wie man wirklich vorgehen sollte, sagt uns Carl Nagle ebenfalls (jede seiner Aussagen entspricht voll und ganz auch meiner Erfahrung):

Test Automation Reality

by Carl Nagle

We cannot afford to engineer or reengineer automation frameworks for each and every new application that comes along. We must strive to develop a single framework that will grow and continuously improve with each application and every diverse project that challenges us.

Problems with Test Automation

Historically, test automation has not met with the level of success that it could. Time and again test automation efforts are born, stumble, and die. Most often this is the result of misconceived perceptions of the effort and resources necessary to implement a successful, long-lasting automation framework. Why is this, we might ask? Well, there are several reasons.

Foremost among this list is that automation tool vendors do not provide completely forthright demonstrations when showcasing the "simplicity" of their tools:

We have seen the vendor's sample applications. We have seen the tools play nice with those applications. And we try to get the tools to play nice with our applications just as fluently. Inherently, project after project, we do not achieve the same level of success. This usually boils down to the fact that our applications most often contain elements that are not compatible with the tools we use to test them. Consequently, we must often mastermind technically creative solutions to make these automation tools work with our applications. Yet, this is rarely ever mentioned in the literature or the sales pitch. The commercial automation tools have been chiefly marketed for use as solutions for testing an application. They should instead be sought as the cornerstone for an enterprise-wide test automation framework. And, while virtually all of the automation tools contain some scripting language allowing us to get past each tool's failings, testers have typically neither held the development experience nor received the training necessary to exploit these programming environments.

Most unfortunate of all, otherwise fully capable testers are seldom given the time required to gain the appropriate software development skills.

For the most part, testers have been testers, not programmers.

Consequently, the "simple" commercial solutions bought have been far too complex to implement and maintain; they become shelfware.

Test automation must be approached as a full-blown software development effort in its own right.

Without this, it is most likely destined to fail in the long term.

Some Test Strategy Guidelines

Past failings like these have been lessons for the entire testing community. Realizing that we must develop reusable test strategies is no different than the reusability concerns of any good application development project. As we set out on our task of automating test, we must keep these past lessons forefront.

In order to make the most of our test strategy, we need to make it reusable and manageable. To that end, there are some essential guiding principles we should follow when developing our overall test strategy:

• Test automation is a fulltime effort, not a sideline.
• Test design and test framework are totally separate entities.
• The test framework should be application-independent.
• The test framework must be easy to expand, maintain, and perpetuate.
• The test strategy as well as the test design vocabulary should be framework independent.
• Strategy and design should remove most testers from the complexities of the test framework.
  
  

These ideals are not earth shattering or relatively new. Yet, it is seldom these principles are fully understood and instrumented. So what do they mean?

Test automation is a fulltime effort, not a sideline

While not necessarily typical design criteria, it bears repeating. The test framework design and the coding of that design together require significant front-loaded time and effort. These are not things that someone can do when they have a little extra time here, or there, or between projects. The test framework must be well thought out. It must be documented. It should be reviewed. It should be tested. It is a full software development project like any other. This bears repeating again and again.

Will our test framework development have all of these wonderful documentation, design, review, and test processes? Does our application development team? We should continuously push for both endeavors to implement all these critical practices.

Test Design and Test Framework need to be totally separate entities

The Test Design details how the particular functions and features of our application will be tested. It will tell us what to do, how and when to do it, what data to use as input, and what results we expect to find. All of this is specific to the particular application or item being tested. Little of this requires any knowledge or care of whether the application will be tested automatically or manually. It is, essentially, the how to of what needs to be tested in the application.

On the other hand, a Test Framework, or specifically, the test automation framework, is an execution environment for automated tests. It is the overall system in which our tests will be automated. The development of this framework requires completely different technical skills than those needed for test design.

The test framework should be application-independent

Although applications are relatively unique, the components that comprise them, in general, are not. Thus, we should focus our automation framework to deal with the common components that make up our unique applications. By doing this, we can remove all application-specific context from our framework and reuse virtually everything we develop for every application that comes through the automated test process.

We should focus our automation framework to deal with the common components that make up our unique applications:

Nearly all applications come with some form of menu system. They also have buttons to push, boxes to check, lists to view, and so on. In a typical automation tool script there is, generally, a very small number of component functions for each type of component. These functions work with the component objects independent of the applications that contain them.

Traditional, captured automation scripts are filled with thousands of calls to these component functions. So the tools already exist to achieve application independence. The problem is, most of these scripts construct the function calls using application-specific, hard coded values. This immediately reduces their effectiveness as application-independent constructs. Furthermore, the functions by themselves are prone to failure unless a very specific application state or synchronization exists at the time they are executed. There is little error correction or prevention built-in to these functions.

To deal with this in traditional scripts we must place additional code before and/or after the command, or a set of commands, to insure the proper application state and synchronization is maintained. We need to make sure our window has the current focus. We need to make sure the component we want to select, or press, or edit exists and is in the proper state. Only then can we perform the desired operation and separately verify the result of our actions.

For maximum robustness, we would have to code these state and synchronization tests for every component function call in our scripts. Realistically, we could never afford to do this. It would make the scripts huge, nearly unreadable, and difficult to maintain. Yet, where we forego this extra effort, we increase the possibility of script failure.

What we must do is develop a truly application-independent framework for these component functions. This will allow us to implement that extra effort just once, and execute it for every call to any component function. This framework should handle all the details of insuring we have the correct window, verifying the element of interest is in the proper state, doing something with that element, and logging the success or failure of the entire activity. We do this by using variables, and providing application-specific data to our application-independent framework. In essence, we will provide our completed test designs as executable input into our automation framework.

Does this mean that we will never have to develop application-specific test scripts? Of course not. However, if we can limit our application-specific test scripts to some small percentage, while reusing the best features of our automation framework, we will reap the rewards project after project.

The test framework must be easy to expand, maintain, and perpetuate

Our goal should be a highly modular and maintainable framework. Generally, each module should be independent and separate from all the other modules. What happens inside one is of no concern to the others.

With this modular black-box approach, the functionality available within each module can be readily expanded without affecting any other part of the system. This makes code maintenance much simpler. Additionally, the complexity of any one module will likely be quite minimal.

However, modularity alone will not be enough to ensure a highly maintainable framework. Like any good software project, our design must be fully documented and published. Without adequate, published documentation it will be very difficult for anyone to decipher what it is the framework is designed to do. Any hope of maintenance will not last far beyond the departure of the original framework designers. Our test automation efforts will eventually become another negative statistic.

To prevent this, we should define documentation standards and templates. Wherever possible, module documentation should be developed directly in the source code itself. Tools should be retained, or designed and developed, so that we can automatically extract and publish the documentation. This will eliminate the task of maintaining two separate sets of files: the source code, and its documentation. It will also provide those doing the code maintenance quite a ready reference. Nearly everything they need to know should exist right there in the code. We must always remember: our ultimate goal is to simplify and perpetuate a successful test automation framework. To put something in place that people will use and reuse for as long as it is technically viable and productive.

The test strategy/design vocabulary should be framework independent

As noted before, the framework refers to the overall environment we construct to execute our tests. The centerpiece is usually one of many commercially available automation tools. In good time, it may be more than one. In some rare circumstances, it might even be a proprietary tool developed or contracted specifically for our test automation needs.

The point is, different tools exist and some will work better for us than others in certain situations. While one tool might have worked best with our Visual Basic or C/C++ applications, we may need to use a different tool for our web clients. By keeping a specific tool consideration out of our test designs, we avoid limiting our tests to that tool alone.

The overall test strategy will define the format and low-level vocabulary we use to test all applications much like an automation tool defines the format and syntax of the scripting language it provides. Our vocabulary, however, will be independent of any particular test framework employed. The same vocabulary will migrate with us from framework to framework, and application to application. This means, for example, the syntax used to click a button will be the same regardless of the tool we use to execute the instruction or the application that contains the button.

The test design for a particular application, however, will define a high-level vocabulary that is specific to that application. While this high-level vocabulary will be application specific, it is still independent of the test framework used to execute it. This implies that the high-level in­struc­tion to login to our website with a particular user ID and password will be the same regardless of the tool we use to execute it. When we provide all the instructions necessary to test a particular application, we should be able to use the exact same instructions on any number of different framework implementations capable of testing that application. We must also consider the very likely scenario that some or all of this testing may, at one time or another, be manual testing.

This means that our overall test strategy should not only facilitate test automation, it should also support manual testing. Consequently, the format and vocabulary we use to test our applications should be intuitive enough for mere mortals to comprehend and execute. We should be able to hand our test over to a person, point to an area that failed, and that person should be able to manually reproduce the steps necessary to duplicate the failure.

A good test strategy, comprised of test designs and test framework, can remove the necessity for having both manual and automated test scripts for the same test: The same "script" should suffice for both. The important thing is that the vocabulary is independent of the framework used to execute it. And the test strategy must also accommodate manual testing.

Remove most testers from the complexities of the test framework

In practice, we cannot expect all our test personnel to become proficient in the use of the automation tools we use in our test framework. In some cases, this is not even an option worth considering. Remember, generally, testers are testers — they are not programmers.

Sometimes our testers are not even professional testers. Sometimes they are application domain experts with little or no use for the technical skills needed for software development. Sometimes testers are application developers splitting time between development and test.

And when application developers step in to perform testing roles, they do not want or need a complex test scripting language to learn. That is what you get with commercial automation tools. And that may even be counter-productive and promote confusion since some of these script­ing languages are modified subsets of standard programming languages. Others are completely unique and proprietary. Yet, with the appropriate test strategy and vocabulary as discussed in the previous section, there is no reason we should not be able to use all our test resources to design tests suitable for automation without knowing anything about the automation tools we plan to deploy. The bulk of our testers should be able to concentrate on test design, and test design only. It is the automation framework folks who will focus on the tools and utilities to automate those tests.


Read also:

• Classical Testing Mistakes
• Case Studies of Software Test Automation — wichtige Erfahrungen, sie entsprechen voll auch meinen
• How to choose a Tool for Test Automation
• When to automate, or not to automate, a Test
• Is your Acceptance Test Suite sufficiently easy to maintain?
• 5 Pillars of a Successful Test Automation Implementation
• The Cost of Poor Software Quality
• Test Management Research 2017
  |
• Um weltweit genutzte Smartphone-Apps zu testen, könnte Crowdsourced Testing der effektivste Weg sein. [1]
  |
• Test Automation Challenges — Ergebnis einer (nicht repräsentativen) Umfrage aus 2018
• Die 2017 am häufigsten verwendeten Test Automation Tools
• Test Automation 2018 — wohin die Reise geht (und wie Testwerkzeuge im Vergleich zueinander Nutzer finden).

stw4515SQTPW — Selenium . QTP . Werkzeug — News?

Mehr + B G E + S H A + More

Wissenswertes zur Testproblematik

||

Kennen Sie das Niveau Ihrer Software-Qualitätssicherung?

Aqua — ein modernes Test Management Werkzeug

Andagon — ein Anbieter von Test Outsourcing

Andagons Blog zu Testimplementierung

At Andagon

About Andagon

||

Automation Testing for Beginners – The Ultimate Guide

Continuous Testing Advice

The Testing Board Tutorials

Tools zur GUI-Automatisierung (2014)

On testing Mobile Apps

Testing Trends (2016)

Test in the Cloud – Success Stories

DZone's Guide on Test Automation (2017)

Testing Board, Selenium Tutorial