Alexander Heimlich

Aqua – JetBrains stellt IDE zur Testautomatisierung vor

JetBrains führt mit dem neuen Produkt JetBrains Aqua eine leistungsstarke IDE zur Testautomatisierung ein. Laut Entwicklern „beinhaltet die IDE alles, was ein QA Engineer braucht“ – Unterstützung mehrerer Programmiersprachen (darunter Python, Java, JavaScript, TypeScript und Kotlin), Verwendung verschiedener Datenbanken sowie Generierung von Testdaten mit einem Zufallsdaten-Generator, Vorbereitung von Testumgebungen mithilfe von Docker, integrierter Web-Inspektor etc.

Folgender Ausschnitt zeigt eine Liste vielversprechender Funktionen:

Einige Features, die JetBrains Aqua bietet

Die IDE befindet sich noch in Entwicklung, weitere Features wie z.B. Support für Playwright und Cypress folgt noch. Während der Preview-Phase kann Aqua über die JetBrains Toolbox App oder als Plugin in bestehenden IDEs heruntergeladen oder hinzugefügt werden. Sehen wir uns mal die Entwicklungsumgebung an.

New Project Wizard

Das Anlegen eines neuen Selenium-Projekts erfolgt schnell und unkompliziert über eine saubere UI. Durch ein Paar Mausklicks wird die JDK, Projektsprache, Testrunner (JUnit oder TestNG), sowie Build Tool (Maven/Gradle) ausgewählt.

Neues Projekt anlegen

Zusätzliche Projekt-Abhängigkeiten wie beispielsweise Selenide oder Assertions Libraries können gleich im nächsten Dialog-Fenster ausgesucht werden und schon ist ein Projekt angelegt.

Neues Projekt anlegen – zusätzliche Abhängigkeiten

Page Object Templates

Über das New File Menu können POs hinzugefügt werden. Diese werden nach bestimmten Templates kreiert, die nach Belieben ergänzt oder neu erstellt werden können.

Hinzufügen eines neuen Page Objects

Nach dem Erstellen des Page Objects erscheint neben der Klasse ein „Web“-Symbol. Darüber kann der integrierte Web-Inspektor geöffnet werden. Dieser stellt eine Live-View der zu testenden Seite dar und unterstützt die Entwickler bei der Auswahl von eindeutigen CSS oder XPath-Selektoren für die automatisierten Tests:

Ein neuangelegtes Page Object

Web-Inspektor

Solange der Web-Inspektor in der IDE offen ist, zeigt die Code Completion für CSS und XPath die wichtigsten oder die gerade eingetippten Lokatoren an:

Web-Inspektor in der IDE mit Highlight Syntax

Über das „+„-Symbol werden DOM-Elemente aus dem Web-Inspektor direkt als Variable in der Page Object Klasse angelegt:

Anlegen eines Locators und die dazugehörige Page Object Variable

Außerdem bietet Aqua umfangreiche Unterstützung für die Selenium-API und Selenide und gibt uns einen Einblick in den Code der CSS-, XPath-Selektoren, die in der Selenium-API und vielen anderen Bibliotheken für UI-Tests verwendet werden. So wird auch falsche XPath-Syntax erkannt und entsprechend markiert:

Falsche XPath-Syntax

Test Management Systems und Issue Tracker

Tests beinhalten normalerweise Links zu auftretenden Issues in einer Applikation. QA Engineers verwenden oft externe Libraries wie Allure Framework oder Selenide BDD, um auf diese Issues in den Tests aufmerksam zu machen. JetBrains Aqua bietet nun auch Annotationen für diese Libraries und lässt den Issue Link mit einem Klick öffnen. Die Reporters werden in den Einstellungen konfiguriert.

Issue Link über die Annotation @TmsLink

API Testing mit integriertem HTTP-Client

Dank des integrierten HTTP-Clients lassen sich HTTP-Requests verschicken und empfangen. Die Code Completion erspart uns ihrerseits eine Menge Arbeit.

Kleiner Auschnitt aus einer HTTP-Request-Datei

Die Anfragen können direkt aus der IDE gestartet und deren Responses unter View > Tool Windows > Services anzeigen lassen (in dem Fall mit Status 401, da wir bei der GET-Anfrage keine Authentifikation angegeben haben) :

Antwort der obigen HTTP-Anfrage

Datenbanken

Ein weiteres Feature von JetBrains Aqua ist die (gleichzeitige) Unterstützung von Datenbanken, z.B. direkter Zugriff auf Oracle, SQL Server, PostgreSQL, MySQL usw. aus der IDE. SQL-Abfragen können auch direkt implementiert werden.

Weiterentwicklung von Aqua

Die Preview-Phase der IDE ist vor kurzem veröffentlicht worden und wir haben in diesem Artikel ein paar Features davon gesehen. Weitere werden entwickelt, die bestehenden erweitert und noch leistungsfähiger gemacht, also auch wenn die gewünschten noch nicht dabei sind, können wir davon ausgehen, dass sie in naher Zukunft ebenfalls angeboten werden. Warten wir also ab, was JetBrains uns demnächst anbietet.

/0 Kommentare/von
Casian Steti

Besuch des QS-Tag 2022: Reinventing Quality – Frankfurt am Main

SOFTWARE QS-TAG 2022 REINVENTING QUALITY

In diesem kurzen Beitrag möchte ich die Impressionen meines kurzen Besuches desdiesjährigen Software QS-Tag 2022 – Frankfurt am Main (05.10.2022-06.10.2022) zusammenfassen. Rund um das Thema Reinventing Quality wurden viele Strategien, Techniken, Tools und Best Practices präsentiert und diskutiert. Ich habe viele dieser Vorträge besucht und kann darüber kurz berichten. Weiterlesen

/0 Kommentare/von
Magnus Hartmann
,

Das Ende von Protractor?

Bisherige Timeline

Mit dem Release Blog Post zu Angular 12, hatte das Angular Entwicklerteam bekannt gegeben das Support- / Entwicklungsende von Protractor zu evaluieren.
Nach einem Request for Comments wurde dann entschieden, die Entwicklung von Protractor mit dem Angular 15 Release Ende 2022 einzustellen. Die Zukunft für Teams, die auf Protractor unbedingt angewiesen sind, blieb ungeklärt.

Diese Nachrichten bedeuteten für unzählige Automatisierungsteams weltweit Recherche- und Handlungsbedarf,
Alternativen mussten gesucht werden und umfangreiche Migrationen waren einzuplanen.

Alternative Frameworks

Mit dem Release von Angular 12 wurde frühzeitig Support von weiteren Frameworks realisiert.
Neben Nightwatch, Cypress und WebdriverIO hat auch Playwright mit einem Migration Guide für Zukunftsfähigkeit gesorgt.

Hierbei hat sich Cypress laut npm trends als der populärste „Ersatz“ für Protractor positioniert.

Breaking News

Bis hierhin sind das alles altbekannte Fakten, wozu also dieser Artikel?
Seit Mitte Q3 2022 gibt es endlich ein Update zu dieser für viele QA Kollegen kritischen Frage.

 

Das vorläufige Support-Ende von Protractor ist verschoben!

 

In einem offiziellen Statement wurde bekannt gegeben, dass uns der Protractor Support noch ein weiteres Angular Major Release erhalten bleibt.
Die neue Timeline sieht vor, dass Protractor nicht wie bisher geplant Ende des Jahres 2022 deprecated wird, sondern erst mit Angular 16 im Sommer 2023 sein Lebensende erreicht.
Bis dahin beschränkt sich die Weiterentwicklung allerdings auf sicherheitsrelevante Themen und Browserkompatibilitäten.

Dies wird den vielen Projekten mehr Luft zur Migration geben und sorgt für ein wenig Entspannung in den betroffenen Teams.

Das endgültige Ende von Protractor?

Breaking News Teil 2

Eine weitere äußerst positive Nachricht wurde zeitgleich veröffentlicht.
Die Angular / Protractor Entwickler planen zusammen mit HeroDevs einen public fork, um das langfristige Überleben / den Support von Protractor zu sichern.

/0 Kommentare/von
Casian Steti

Performance Engineering vs Performance Testing

PERFORMANCE ENGINEERING VS PERFORMANCE TESTING

Software Performance-Testing und Software Performance-Engineering sind zwei unterschiedliche Seiten derselben Medaille.

Ebenso unterscheiden sich die Rollen eines Performance-Engineer von denen eines Performance-Testers.

Daher sind PTLC (Performance Testing Life Cycle) und PELC (Performance Engineering Life Cycle) definiert, um die Aktivitäten von Performance-Testing bzw. Performance-Engineering zu rationalisieren.

 

 

 

 

Die wichtigste Unterschiede zwischen Performance-Testing und Performance-Engineering :

  • Performance-Testing ist eine Qualitätsprüfung der Anwendung in Bezug auf die Reaktionsfähigkeit und Belastbarkeit. Performance-Test überprüfen, wie sich ein System unter Produktion nähe Last verhält, und um Probleme zu antizipieren, die unter Bedingungen hoher Last auftreten können. Andererseits zielt Performance-Engineering darauf ab, die Anwendung unter Berücksichtigung der Leistungsmetriken zu entwerfen und potenzielle Probleme früh im Entwicklungszyklus zu erkennen.
  • Performance-Testing ist ein besonderer QA-Prozess, der nach Abschluss einer Entwicklungsrunde stattfindet, während Performance-Engineering ein fortlaufender Prozess ist, der sich durch alle Phasen des Entwicklungszyklus erstreckt, z.B. von der Designphase über die Entwicklung bis hin zur QA.
  • Ein dedizierter Performance-Tester oder ein Team führen die Leistungstests durch, die über fundierte Kenntnisse des Leistungstestkonzepts, des Werkzeugbetriebs, der Ergebnisanalyse usw. verfügen. Ein Performance-Engineer ist eine Person, die über ausreichende Kenntnisse in den Bereichen Anwendungsdesign, Architektur, Entwicklung, Tuning, Leistungsoptimierung verfügt, um Engpässe zu finden und weiter Ursachenforschung und -Behebung zu arbeiten.
  • Wenn während des Performance-Tests ein Engpass identifiziert wird, besteht die Rolle des Performance-Testers darin, das Testergebnis zu analysieren und einen Fehler zu melden. Auf der anderen Seite besteht die Aufgabe eines Performance-Engineer darin, die Grundursache zu untersuchen und eine Lösung zur Behebung des Engpasses vorzuschlagen.
  • Der Performance-Tester kümmert sich nicht sehr um das Design und die Architektur der Anwendung. Er konzentrierte sich nur auf das Anwendungsverhalten unter Last, während der Performance-Engineer kümmert sich darum, wie effizient jede Komponente der Anwendung unter Last arbeitet.
  • Der während der Performance-Test identifizierte Engpass erfordert mehr Geld als ein gut abgestimmtes Anwendungsdesign, das von einem Performance-Engineer überprüft und zertifiziert wird.
  • Der PTLC deckt alle Phasen des Performance-Testing ab, während der PELC alle technischen Aktivitäten und Ergebnisse abdeckt.
  • Während Performance-Test in der Regel nach der Entwicklung der Anwendung durchgeführt werden, ist das Performance-Engineering tief in SDLC integriert, um sicherzustellen, dass das System mit hohen Standards erstellt wurde, um sicherzustellen, dass es für die Leistung optimiert ist.
  • Ein Performance-Tester mit guten Leistungstestfähigkeiten wird ein guter Performance-Engineer, wenn er Interesse an Engpassidentifikation, Ursachenanalyse und Anwendungsoptimierung hat. Um dieser Rolle gerecht zu werden, muss er jedoch über gute Kenntnisse des Anwendungsdesigns und der Anwendungsarchitektur verfügen.
  • Performance-Engineering ist jedoch eine breite Palette von Prozessen und auch eine Kultur, die ermöglicht Teams schnelle, effiziente und reaktionsschnelle Systeme und Applikationen bereitstellen
  • Performance-Engineering ist auch sehr geeignet für die Shift Left Ansätze.

VERWANDTE BEGRIFFE

/0 Kommentare/von
Alexander Heimlich

Software-Qualität mit JaCoCo und SonarQube

JaCoCo ist eine Open-Source-Bibliothek für Java, die die Code-Abdeckung (Code Coverage) einer Applikation misst. Die Code-Abdeckung ist ein wichtiges Kriterium für die Beurteilung der Testabdeckung einer Applikation, denn durch geeignete Tests und eine hohe Testabdeckungsrate wird der Produktionscode gründlich überprüft.

Einige Features von JaCoCo sind beispielsweise die Erstellung von Reports in verschiedenen Formaten (HTML, XML, CSV) und die Integration in IDEs und CI – Pipelines. In Kombination mit SonarQube oder Jenkins kann somit die Code Coverage außerhalb der IDE stattfinden und durchs Reporting für das Entwicklungsteam zentral und transparent verfügbar gemacht werden.

In diesem Artikel zeige ich die Einrichtung von JaCoCo mit JUnit Tests, sowie die Integration der Ergebnisse in SonarQube.

Weiterlesen

/0 Kommentare/von
Waldemar Siebert

Allure Listener für Screenshots und weitere Anhänge verwenden

Allure Reporting ist eines der beliebtesten Open Source Produkte im Testbereich. Aus gutem Grund! Die Reports aggregieren die benötigten Daten sehr übersichtlich. Die Anbindung an die meisten Testframeworks wie Cucumber, TestNG, Selenide und andere funktioniert in der Regel reibungslos.

Spannend wird es bei Allure nur, wenn es um spezielle Anforderungen geht. Es können Postprocessing Aggregationen von unterschiedlichen Runs sein, aber auch das Anhängen von Dateien (Log Files oder Screenshots…) im Test-Lebenszyklus. Um den letzten Punkt geht es in diesem Artikel.

Weiterlesen

/0 Kommentare/von
Waldemar Siebert

Container git Fehler „fatal: unsafe repository (/dir is owned by someone else)“ beheben

Tester führen Tests gerne in Docker Containern aus, soweit so bekannt.. Auch dass wir alle ganz gerne git verwenden, wundert eigentlich nicht wirklich. Nur kann die Kombination von beiden auch kleinere Probleme bereiten. So sind auch bei uns spontan, von einem Tag auf den anderen sämtliche Testfälle beim Cleanup der Umgebung ausgestiegen mit der Fehlermeldung:

+ git clean -fdx
fatal: unsafe repository ('/usr/share/jenkins/workspace/tests/nightly' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory '/usr/share/jenkins/workspace/tests/nightly'

Weiterlesen

/0 Kommentare/von
Alexander Heimlich

Playwright Update 1.17: Frame Locators, Playwright Assertions und Trace Viewer

Mit der Version 1.17 hat Playwright seine API aktualisiert und bietet seitdem neue Methoden zur Interaktion mit iframes. Hinzu kommen außerdem für Java neue Playwright- und LocatorAssertions-Klassen, die für Assertions in Testfällen verwendet werden können. Diese warten bis zum Eintreffen einer Bedingung, beispielsweise bis ein DOM-Node einen bestimmten Text hat. Sehen wir uns die einzelnen Updates an.

Weiterlesen
/1 Kommentar/von
Alexander Heimlich

ElementHandle vs. Locator in Playwright

Playwright Framework unterstützt mehrere Verfahren zum Auffinden von Oberflächenelementen auf einer Webseite. Neben den allgemein bekannten Selektoren gibt es in Playwright noch weitere Konzepte wie  ElementHandle und Locator, die die Suche nach DOM-Elementen auf einer Webseite unterstützen und im diesem Artikel näher beleuchtet werden.

Weiterlesen
/0 Kommentare/von