Sammlung von Newsfeeds

Mobile App Testing mit Ranorex und Appium

Qytera News -

Lesedauer: 4 Minuten

Nachdem ich verschiedene Mobile App Testing Automatisierungen mit den Werkzeugen Ranorex und Appium vorgenommen hatte, möchte ich hiermit meine Erfahrungen darstellen. Dabei möchte ich meine Herangehensweise in der Tool- und Geräteauswahl darstellen und dann auf die ersten Schritte in der Skriptentwicklung eingehen.

HerangehensweiseAuswahl Automatisierungstool

Zuerst muss ein Automatisierungstool gefunden werden, welches die Anbindung und Automatisierung von mobilen Geräten, wie Smartphones und Tablets, unterstützt. Hierbei ist darauf zu achten, dass diese auch Mobile Apps und nicht nur eine Browser Automatisierung unterstützen.

Neben kommerziellen Tools, wie TestComplete, SilkTest, eggPlant oder Ranorex haben sich auch OpenSource bzw. andere lizenzkostenfreie Produkte, wie iOS UI Automation, UI Automator oder auch Appium am Markt etabliert. Darüber hinaus gibt es eine zahlreiche Zahl von gehosteten Angeboten, die Gerätesimulationen zum Mieten anbieten. Hierunter fallen 21Labs, Test IO, Kobiton und Blazemeter. Dabei bieten viele dieser Cloud-Anbieter für den Einstieg auch eine kostenfreie, eingeschränkte Version an.

Da Aufgrund der Vielzahl der Anbieter hier kein Marktüberblick gegeben werden kann und alle Anbieter im Detail verglichen wurden, kann ich hier nur eine Auswahl von Tools zeigen, mit denen ich mich selbst beschäftigt habe.

Ich selbst habe aus vorherigen Projekten schon mit Ranorex Erfahrungen sammeln können und es war für mich naheliegend, mich mit dem Tool zu beschäftigen. Darüber hinaus gibt es für Appium eine große und präsente Community, so dass ich hier gute Chancen sah, eine erfolgreiche Umsetzung zu erzielen. Deshalb werde ich mich in den späteren Ausführungen auf Beispiele in Ranorex und Appium beschränken.

Physikalische Geräte

Nachdem sich für ein Automatisierungstool entschieden wurde, sollten die ersten Versuche mit einem physikalischen Gerät erfolgen. Egal ob iOS oder Android, das Gerät muss soweit umkonfiguriert werden, um einen Zugriff von “außen” zuzulassen. Hier ist die Freischaltung des Entwicklermodus und die Aktivierung des USB-Zugriff gemeint. Schließt man eines dieser umkonfigurierten Geräte an, sollte mit den Automatisierungstools ein Zugriff möglich sein.

Bild: Appium Inspector. (Klicken zum Vergrößern) [Quelle: Appium] ×

Bevor mit den Automatisierungswerkzeugen gearbeitet werden kann, ist die zu testende App als Ipk-Paket (für iOS) oder Apk-Paket (für Android) notwendig. Diese stellt die Entwicklung bereit.

In Appium lässt sich eine Geräteverbindung gut über den Inspector prüfen, auch anfangs ohne App. Aber erst mit der von Appium auf das Gerät übertragenen App lassen sich die Oberflächenelemente erkennen und bewerten (mit dem Inspector). Klar wird dabei, wie gut der Zugriff auf die Oberflächenelemente möglich ist.

In Ranorex sind einige weitere Schritte notwendig, um eine erfolgreiche Erstverbindung zu testen. Hier ist die Installation der Ranorex Service App notwendig, die vom Hersteller oder über den App Store oder Play Store geladen werden kann. Danach ist in Ranorex die App zu instrumentalisieren und kann dann auf das Gerät eingespielt werden. Danach können mit dem Ranorex Spy die App-UI-Elemente ermittelt und für die Automatisierung verwendet werden.

Bild: Ranorex Service und Instrumentalisierungs-Assistent. (Klicken zum Vergrößern) [Quelle: Ranorex] × Gerätesimulation

Standardmäßig erhält man mit den Entwicklungsumgebungen für Android (Android Studio) oder iOS (XCode) eingebaute Simulatoren von Mobilgeräten. Hier lassen sich vorab unterschiedliche Geräte definieren (z.B. Auflösung, Speicher). Egal ob man sich für Appium oder Ranorex entscheidet, können diese Gerätesimulatoren eingesetzt und genauso angesprochen werden, als wären es physikalische Geräte. Zwei für mich große Einschränkungen musste ich aber feststellen. Es ließ sich bei mir kein Bluetooth verwenden und bei iOS muss die Ipk explizit gegen ein x86-System kompiliert werden, da die App Store Apps nur für ARM geeignet sind.

Erste SchritteAppium

Da Appium keine GUI zur Testfallerstellung enthält, findet eine Umsetzung in zwei unterschiedlichen Werkzeugen statt. Appium Inspector erfasst die Oberflächenelemente und man erhält die Zugriffsmöglichkeiten mit xPath oder Id. Diese Informationen übernimmt man manuell in sein Appium-Projekt für den Webdriver Zugriff. So kann man die Elemente als Page-Objekte definieren und in seinem Automatisierungsskript verwenden. Hier kann auch die Verwendung eines Frameworks hilfreich werden, das bei der Erstellung und Verwaltung der Page-Objekten unterstützt.

Bild: Appium Element-ID Verwendung. (Klicken zum Vergrößern) [Quelle: Appium] × Ranorex

Konnte die Verbindung über die instrumentalisierte App aufgebaut werden, lässt sich mit Ranorex eine Automatisierung leicht aufzeichnen und entwickeln. Dies funktioniert wie mit einem nativen Desktopprogramm oder einer Webseite. Ranorex Spy zeichnet die RanoreXPathes für das Repository genauso wie bei einem Desktopprogramm oder Webseite auf und in den Actions lassen sich die spezifischen Mobilgeräte-Aktionen spezifizieren, wie Tippen, Wischen oder die Gerätetasten.

Bild: Ranorex Spy. (Klicken zum Vergrößern) [Quelle: Ranorex] × Bild: Ranorex Mobile Recording Actions. (Klicken zum Vergrößern) [Quelle: Ranorex] × Zusammenfassung

Bei dem Vergleich der beiden Tools konnte ich feststellen, dass ich in Appium anfangs einen relativ großen Aufwand mit der Installation der benötigten Werkzeuge verbracht hatte, um die ersten Schritte beginnen zu können. Vielfach war die Dokumentation oder das Hilfeforum nicht eindeutig auf mein gewähltes Setup anzuwenden, so dass ich mich sehr stark mit technischen Details des Tools auseinandersetzen musste.

Bei Ranorex fiel mir der Einstieg durch seine gute Dokumentation und mit Hilfe der eingebauten Assistenten viel leichter und ich konnte in kürzerer Zeit mit dem Scripting beginnen. Beim Scripting half Ranorex über die Actions anfänglich auch einen leichten Einstieg zu bekommen.

Es war kaum ein Unterschied zu Tests von Webapplikationen oder nativen Desktopprogrammen festzustellen. Dennoch fand ich mich mit Appium sehr schnell zurecht, konnte viele Analogien zu Web-Testing mit Selenium ziehen und erreichte in einer akzeptablen Zeit Erfolge, auch wenn ich kein spezialisierter Entwickler bin.

Letztendlich bezahlt man den Komfort eines leichteren Einstiegs in Ranorex durch die Lizenzgebühren. Diesen Vorteil sehe ich aber im weiteren Projektverlauf als immer unbedeutender an, so dass ich auch Appium weiterempfehlen kann.

Ausblick

Weiterführend zu dem oben gezeigten Einstieg sehe ich einen relativ großen Aufwand in der Definition und Einrichtung der ganzen Infrastruktur und bei der Einrichtung der Vielzahl an Geräten. Eine ausreichend ausgebaute Geräte-Matrix zu entwerfen, und diese in die Infrastruktur einzubinden, wird einige Zeit kosten. Da aber die Automatisierungsskripte weitestgehend über die verschiedenen Geräte wiederverwendet werden können, wird sich die Geräte-Matrix nicht wesentlich auf die Entwicklungsdauer der Automatisierungsskripte auswirken. Gerade bei einer große Anzahl von zu testenden Geräten lohnt sich eine Automatisierung. Dennoch rechnet sich auch hier der Aufwand erst durch die häufige Wiederholung der Testdurchführung im Produkt-Life-Cycle.

Es existieren eine Vielzahl an weiteren Herausforderungen auf die ich hier in der Kürze nicht eingehen konnte. Ich möchte Sie aber der Vollständigkeit halber nennen:

  • Infrastruktur (Netzwerk, Server, Anbindung Testgeräte per USB/Wifi, etc.)
  • IoT, App-Server Kommunikation, Anbindung von Zubehör
  • iOS und Android Gerätevielfalt und Betriebssystem-Versionsvielfalt
  • Skalierung / Parallelisierung

Auch wenn ich mich hier auf zwei Werkzeuge konzentriert habe, werden sich viele der hier angesprochenen Aspekte auf andere Automatisierungstools übertragen lassen.

01. Dezember 202001. Dezember 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Einführung agiler Methoden in einem großen Projekt

Qytera News -

Lesedauer: 4 Minuten

Nicht nur Startups und Kleinstprojekte beschäftigen sich mit aktuellen Methoden der Softwareentwicklung, sondern auch Großprojekte und Konzerne. Da hier durch die großen Organisationsstrukturen kein einheitliches und kleines Team gebildet werden kann, müssen andere Ansätze bzw. Erweiterungen angewandt werden, um diesen speziellen Anforderungen zu begegnen. Hiermit möchte ich einen Einblick geben, wie das Scaled Agile Framework (SAFe) in einem schon seit Jahren fortentwickelten Projekt zum Einsatz kommt und wie ich dies miterlebt und auch gestaltet habe.

Ausgangssituation

Ein seit über 10 Jahren laufendes Projekt, welches die Softwareentwicklung eines Kassensystems durchführt, sollte vom bestehenden Wasserfall-Vorgehen in ein agiles Vorgehen überführt werden. Hierbei waren ca. 50 Mitarbeiter betroffen, wobei die wenigsten davon schon praktische Erfahrungen in agiler Softwareentwicklung sammeln konnten.

Im Projekt wurde neben der Weiterentwicklung auch die Wartung von den gleichen Personen betrieben. Durch das Wasserfall-Vorgehen konnten nur ca. alle 10 Monate, also faktisch nur zwei Releases pro Jahr, ausgeliefert werden. Nur bei sehr kritischen Fehlern, waren Bugfixes mit großem Einsatz und viel bürokratischem Aufwand zusätzlich zu den geplanten Terminen möglich.

Auf der Auftraggeberseite waren eine Vielzahl von Ansprechpartnern für die verschiedenen Teilsysteme, bzw. mit einer anderen Sicht auf das Gesamtsystem, vorhanden, z.B. Multikanalvertrieb, der teilweise konkurrierende Anforderungen einbrachte und dies durch vielfältige und aufwändige Consulting-Leistung in Einklang gebracht werden musste.

Im Konzern wurden vor dem Start immer wieder Forderungen an das Projekt gestellt, dass von der Idee bis zur Auslieferung weniger Zeit eingeräumt werden kann und dadurch mehr Releases pro Jahr entstehen sollen. Dazu sollten die Projekte mehr Transparenz gewähren und schneller auf aktuelle Themen reagieren. Darüber hinaus wollte das Management mit Scaled Agile Framework (SAFe) ein standardisiertes Vorgehen etablieren und die bestehenden Tools mit einem der am meisten verwendeten Werkzeuge Jira und Confluence ersetzen bzw. ergänzen.

Vorbereitende Maßnahmen

Bevor die bestehende Organisation geändert wurde, traf man einige vorbereitende Maßnahmen. Hierzu zählen SAFe Trainings für alle zukünftig in den Teams arbeitenden Kollegen, SCRUM Master Trainings für die beiden zukünftigen Scrum-Master und Produktschulungen zu den neu einzusetzenden Tools Jira und Confluence.

Nach der Teamzusammenstellung in sieben Teams, die grob in Frontend, Backend, Stammdaten und Infrastruktur aufgegliedert wurden, konnten sich diese über mehrere Tage finden und ihre zukünftige Zusammenarbeit gestalten. Daneben wurden zusätzlich übergreifende Projekte mit einigen Mitarbeitern gestartet, die hierbei Unterstützung geben sollten und gerade die bestehenden Prozesse und Vorgehensweisen für die agile Arbeitsweise anpassen sollten.

Der große Start - Big Bang

Nun kam der große Tag, an dem alle der ca. 50 Mitarbeiter mit der Agilität starten sollten. Ausgerechnet zu dieser Zeit brach aber Covid-19 über die Welt ein und nun sollte sich zeigen, ob alle Vorbereitungen auch diese Situation meisterten.

Wir starteten in das in SAFe vorgesehen Release-Train Product Increment (PI) Planning und waren wohl, mangels der Erfahrung noch etwas ideenlos, wie wir an den anfänglich 3 Tagen über ein paar Stunden hinweg, die Arbeit für ein 10 Wochen PI erledigen konnten. Aber wie es oft so ist, entstand eine passable Eigendynamik in den Teams, so dass wir uns doch helfen konnten und einen guten Plan hatten, was wir liefern können und welche Abhängigkeiten zu den anderen Teams existieren. Also starteten wir in unseren ersten 2-Wochen-Sprint.

Rituale

Die Teams selbst führten in ihren Sprints fünf Regeltermine ein, die für Ihre Arbeit wichtig erschienen und versuchten dabei sich an bestehende Standards aus Scrum und SAFe zu orientieren. Unter den Terminen wurde ein tägliches 15 Min. Daily für einen Statusbericht abgehalten, zum Sprintwechsel eine Vorstellung der eingeplanten User Stories in einem Review-Termin, eine Retrospektive für einen kontinuierlichen Verbesserungsprozess und ein Sprint Planning für neue abzuarbeitende User Stories.

Auch wenn anfänglich noch nicht alles rund lief und man von einem sehr gut funktionierenden Projekt bzw. einer funktionierenden Organisation kam, z.B. taten sich einige Mitarbeiter schwer im neuen Vorgehen und lehnten es schon fast ab in Teams zu arbeiten. Aber wir fanden uns in den Teams immer besser zurecht und konnten immer besser in Eigenverantwortung Aufgaben übernehmen und zuverlässig erledigte Arbeitspakete (User Stories) liefern.

Dadurch, dass wir durch Corona alle im Home-Office arbeiteten, wurde nach jedem Daily ein 15 minütiger “Parkplatz” installiert, in dem wir allgemeinere Themen, die nicht speziell das Projekt betrafen, kommunizierten. Hier wurden z.B. Änderungen an der Infrastruktur, Ergebnisse aus dem kontinuierlichen Verbesserungsprozess, Personalveränderungen oder andere Spezialthemen beantwortet, die ggf. auch nicht das ganze Team betrafen.

Darüber hinaus gab es wiederholt alle 10 Wochen das Release-Train PI Planning, in dem auf Epic-Ebene alle Teams gemeinsam ein Releaseplanning vornahmen und die zeitlichen Abhängigkeiten in ihrer Tätigkeit zu den anderen Teams auflösten. Hierbei bemerkte man auch von Mal zu Mal, dass wir weniger Zeit dafür benötigten und so reichte uns an zwei Tagen ein 2-3 Stunden Zeitfenster dafür.

Zusammenfassung und Fazit

Nach ca. einem halben Jahr konnte man feststellen, dass trotz der Vorbereitung in der Gesamtheit viel Erfahrung in agiler Entwicklung fehlte, von der profitiert werden konnte. So war der Start sehr holprig und man stellte immer wieder fest, dass in alte Muster verfallen wurde, z.B. wurde bei Personalengpässen das Management hinzugezogen und dadurch auf Lösungen außerhalb des Teams gewartet.

Auch der kontinuierliche Verbesserungsprozess wurde anfangs falsch verstanden, so dass jedes Problem vom Scrum-Master mitgenommen wurde und kaum eine Verbesserung aus dem Team erfolgte. Es zeigte sich, dass in einem halben Jahr in Summe kein höherer Output erreicht werden konnte, andererseits aber alle zugesicherten Softwarelieferungen erreicht wurden.

Leider haben einige Verbesserungsvorschläge nicht sofort funktioniert und wurden deshalb schnell verworfen, da sie nicht konsequent verfolgt wurden. Deswegen sollte am kontinuierlichen Verbesserungsprozess gearbeitet und nicht am Status Quo festgehalten werden. Ich denke auch, dass Impulse von außen, z.B. durch ein Coaching, viel Potential freisetzen könnten. Dennoch kann man hier von einem Erfolg sprechen, denn nun kann man mit ca. 5 statt 2 Releases sehr viel öfter liefern als noch im alten Vorgehen. Außerdem wurden nicht nur zum PI Planning, sondern auch zu jedem Sprintwechsel auf neue Gegebenheiten und somit sehr flexibel auf die aktuelle Tageslage reagiert.

Im Gegensatz zu einer konzernweiten Umstellung, bei der wahrscheinlich mehrere Tausend Mitarbeiter gleichzeitig ein agiles Vorgehen beginnen, hat es bei einer projektbezogenen Umstellung der Softwareentwicklungsmethode den Charme, dass schon umgestellte Projekte Ihre Erfahrungen über ein Coaching mit weiteren Projekten teilen könnten. Somit dauert es zwar länger, bis ein Gesamtunternehmen umgestellt werden kann, aber meines Erachtens wird der zu erwartende Produktivitätseinbruch bei einer stufenweise Einführung geringer ausfallen.

17. November 202017. November 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Aufgaben eines Testautomation Engineers

Qytera News -

Lesedauer: 4 Minuten

In Zeiten zunehmender Digitalisierung ist die Automatisierung der Tests ein essenzieller Bestandteil von Softwareentwicklungsprojekten. Gerade in komplexeren Projekten empfiehlt es sich, professionelle Hilfe durch einen Testautomation Engineer einzuholen. Zudem gehen wir in diesem Blogartikel auch darauf ein wie man zu einer ISTQB Advanced Level Test Automation Engineer Zertifizierung kommt. Zunächst beginnen wir mit den unterschiedlichen Tätigkeiten, die sich ein professioneller Test Automation Engineer in seiner täglichen Arbeit stellt.

Was ist ein Testautomation Engineer?

Ein Testautomation Engineer ist ein Entwickler oder Tester mit soliden Kenntnissen in den Bereichen Qualitätssicherung, Qualitätsmanagement und Entwicklung. Die Tiefe der benötigten Kenntnisse differiert hierbei stark je nach Art des Entwicklungsprozesses, des System Under Test (SUT) und der eingesetzten Tools.

Typische Aufgaben eines Testautomation Engineers

Zu den typischen Aufgaben einen Testautomation Engineers gehört das Schreiben, Warten und Ausführen von automatisierten Testfallskripten. Diese können auf jeder Ebene der Testpyramide angesiedelt sein. So können Tests auf Komponentenebene (z.B. Unit Test), Integrationsebene (z.B. API Test) und/oder der UI-Ebene (z.B. Seleniumtest) zu den Aufgaben eines Testautomation Engineers gehören.

Bild: Rolle eines Testautomation Engineers bei Testautomatisierungslösungen. (Klicken zum Vergrößern) [Quelle: Qytera] × Auswahl der Testautomatisierungs-Tools

Eine weitere Aufgabe des Testautomation Engineers ist die Beratung des Testmanagers oder die direkte Auswahl des richtigen Automatisierungstools. Hierbei müssen die Anforderungen, Kenntnisse der Tester und Eigenschaften des Testobjekts berücksichtigt werden. Sollte das Tool auch von Mitarbeitern ohne tiefe Programmierkenntnisse bedient werden können, lohnt es sich oft, auf Tools mit einer integrierten Aufnahmefunktionen (z.B. Ranorex zu setzen. Der Testautomation Engineer ist hierbei vor allem für komplexere Funktionen, Konfigurationen und die Architektur zuständig.

Auswahl der richtigen Testautomatisierungsarchitektur

Der Testautomation Engineer ist auch für Entwurf, Entwicklung und Weiterentwicklung der Automatisierungslösung zuständig. Hierbei müssen die Anforderungen und Größe des SUT beachtet werden. Sollte die Test Automation Solution (TAS) für einen längeren Zeitraum eingesetzt werden sowie eine größere Anzahl von Testfällen enthalten, lohnt es sich häufig, auf bewährte Methoden oder Entwurfsmuster wie das Page Object Pattern Design zu setzen. Hierbei wird die Test Automation Architectur (TAA) so gestaltet, dass verschiedene Seiten einer Applikation in einzelne Objekte gegliedert werden. Somit ist die TAS leichter wartbar, da Änderungen nur an einer zentralen Stelle gepflegt werden müssen anstatt in jedem Testfall.

Eine andere Möglichkeit ist es, die Fachseite mit in die Automatisierung einzubinden. Hierzu empfehlen sich Ansätze wie ein Keyword oder Behaviour Driven Design (wie BDD). Bei beiden Ansätzen werden die Automatisierungsskripte in eine leicht verständliche (Meta-) Sprache übersetzt, um sie auch für Mitarbeiter mit wenig Programmierkenntnissen leichter zugänglich zu machen. Ebenso sind künftige Anforderungen, wie die Anbindung der TAS z.B. an eine CI/CD Pipeline zu berücksichtigen.

Bild: Testautomatisierungs-Framework für den Testautomation Engineer. (Klicken zum Vergrößern) [Quelle: Qytera] × Reporting

Bei der Erstellung des TAF ist zudem auf das richtige Reporting zu achten. Die Ergebnisse können je nach Anforderungen, z.B. per Mail, über eine eigene Reportingseite oder direkt im Testmanagementtool gespeichert werden. Die Auswertung und die Ergebnismeldung an den Testmanager oder Kunden liegen ebenfalls im Verantwortungsbereich des Testautomation Engineers.

Optimierung einer bestehenden Test Automation Solution

In vielen Projekten sind bereits kleine Testsuiten für Regressionstests oder Smoke Tests vorhanden. Diese stoßen jedoch ohne sorgfältige Planung oft schnell an ihre Grenzen, da sie schlecht wartbar oder langsam sind. Deshalb ist ein wesentlicher Bestandteil der Aufgaben eines Testautomation Engineers die Optimierung der bestehenden TAS.

Dies kann über verschiedene Wege verfolgen: z.B. eine solide Grundarchitektur zu entwickeln, um die Wartbarkeit zu steigern oder die TAS für eine Parallelausführung durch z.B. Jenkins oder Selenium Grid vorzubereiten. Eine andere Möglichkeit ist es, bestehende, mehrfach ausgeführte Testschritte oder Testfälle die z.B. auf der Systemeben ausgeführt werden, durch schnellere Funktionen auf der Integrationsebene auszutauschen. Außerdem sollten auch die Testfälle regelmäßig einem Review unterzogen werden, um gegebenenfalls alte und nicht mehr kritische Testfälle durch aktuelle zu Ersetzen.

Bild: Software-Entwicklungs-Lebenszyklus für einen Testautomation Engineer. (Klicken zum Vergrößern) [Quelle: Qytera] × Auswahl der Testautomatisierungsstrategie

Der Testautomation Engineer entscheidet oder berät den Testmanager ebenfalls in der Auswahl der richtigen Testautomatisierungsstrategie. Testautomatisierung lohnt sich vor allen bei Tätigkeiten, die oft wiederholt werden müssen, wie dem Regressionstest. Es lohnt sich jedoch oft auch, Ansätze wie risikobasiertes Testen oder der Automatisierung nach User Journey (szenariobasiertes Testen) mit in die Automatisierung einfließen zu lassen. Hierbei kann aus verschiedenen Ansätzen gewählt und kombiniert werden. Dadurch besteht ein Teil der Aufgaben auch darin, die bereitgestellten manuellen Testfälle zu überarbeiten und für die Automatisierung zu optimieren.

Ebenso ist eine Planung für die Durchführung der Testfälle nötig. So kann ein Regressionstest z.B. über ein Nightly Build ausgeführt werden, wohingegen ein Smoketests durch eine Änderungen in der Software ausgelöst werden kann.

Wie wird man Testautomation Engineer und welche Rolle spielen dabei Zertifizierungen?

Eine Ausbildung zum Testautomation Engineer im herkömmlichen Sinne existiert nicht. Es gibt allerdings die Möglichkeit, sich nach ISTQB (International Software Testing Qualifications Board) zertifizieren zu lassen. Hierfür muss man zuerst das Zertifikat ISTQB Certified Tester Foundation Level erlangen, für welches man mindestens 18 Monate Tätigket im Testbereich nachweisen muss. Im Anschluss kann man dann das Zertifikat ISTQB Advanced Level Test Testautomation Engineer anstreben.

Das Erwerben von Zertifizierungen hat mehrere Vorteile für Ihre Berufslaufbahn als professioneller Tester. Zum einen punkten Sie bei der Bewerbung für eine Stelle im Bereich Testautomation Engineer. Hier ist es auch nicht falsch, wenn man zusätzlich noch Zertifikate im Bereich Test Analyst oder Technical Test Analyst vorweisen kann. Häufig wird bei der Wahl einer Besetzung darauf geachtet, dass die nötigen Zertifizierungen vorliegen.

Zum anderen lernt man viele Standards in unterschiedlichen Bereichen wie Testarchitektur oder Testautomatisierung Planung. Die Standards, welche mit den ISTQB-Zertifizierungen erlernt werden können, sind in der Praxis erprobt und bilden eine Basis, auf der man schnell mit anderen Personen zusammenarbeiten kann. Sowohl Begrifflichkeiten als auch Abläufe sind bei gleicher Basis des Teams eine spürbare Erleichterung.

Zusätzlich ist es mit dem Wissen, welches man durch die Zertifizierungen erlangt, eine spürbare Erleichterung, sich in einem neuen Umfeld zurechtzufinden.

Fazit

Die Aufgaben eines Testautomation Engineer sind vielschichtig und haben Bezug zu vielen anderen Tätigkeiten in der Softwareentwicklung. Deshalb ist eine gute Kommunikationsfähigkeit ein Bestandteil der Fähigkeiten eines Testautomation Engineers. Durch eine schnelllebige digitale Welt und der Anforderung, neue oder geänderte Funktionalitäten immer schneller dem Anwender zu Verfügung zu stellen, ist Testautomatisierung ein fester Bestandteil der modernen Softwareentwicklung geworden. Ein Testautomation Engineer kann ihnen hierbei helfen, die Qualität ihrer Software besser abzusichern.

13. Oktober 202013. Oktober 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Testmanagement in agilen Organisationen (Spotify-Modell)

Qytera News -

Lesedauer: 2 Minuten

Bei dem Musik- und Video-Streamingdienst Spotify ist aus der Anwendung verschiedener agiler Methoden ein Organisationsmodell geworden. Es wird heute gemeinhin als Spotify-Modell bezeichnet. Im Rahmen der digitalen Transformation haben einige Unternehmen ihre Organisation nach dem Spotify-Modell ausgerichtet, in der Finanzbranche z.B. die ING, die Commerzbank und die Sparkassen. Mit dem Organisationsmodell von Spotify wird eine Matrixorganisation auf Basis von Tribes, Squads, Chapters und Product Ownern eingeführt.

Bild: Spotfify-Modell für agile Organisationen. [Quelle: Kniberg und Ivarsson 2012]

Squads entwickeln Softwareprodukte im Auftrag von Product Ownern. Development Engineers und Business Experts testen sie und Application Operation Engineers bringen sie anschließend in die Produktionsumgebung. Als Entwicklungsmodelle kommen Scrum oder Kanban zum Einsatz. Teamübergeifender Erfahrungsaustausch findet in Chapters und Guilds statt.

Da die Rolle Testmanager in Spotify-Modell nicht vorgesehen ist, werden notwendige Testmanagementaufgaben im Tribe agilen Rollen zugeordnet. Es hat sich praktisch bewährt, einen Mitarbeiter für übergreifende Testmanagementaufgaben im Tribe zu bestimmen und Mitgliedern der Squads operative Testmanagementaufgaben zu übertragen.

Test Guild und teamübergreifender Austausch

Im Rahmen der digitalen Transformation ist die Etablierung einer Test Guild ein hilfreicher Schritt. Vertreter mit Testschwerpunkt aus den Squads treffen regelmäßig zusammen, um sich über testbezogene Best Practices auszutauschen, über anstehende Neuerungen beim Einsatz von Verfahren und Tools zu informieren oder Optimierungsmöglichkeiten im Testprozess für den Tribe zu besprechen. Dabei sind die Mitglieder der Test Guild nicht unbedingt diejenigen, die operative Testmanagementaufgaben in den Squads wahrnehmen. Sie sind aber die bestimmten Ansprechpartner für das Thema Test in den Squads und autorisiert Anliegen in die Test Guild einzubringen.

Neben der Führung der Test Guild sind auch Vereinbarungen zu Testthemen mit anderen Tribes zu treffen, insbesondere wenn starke Abhängigkeiten bestehen. Der übergreifend tätige Testmanager im Tribe ist für diese Aufgabe prädestiniert.

Testinfrastruktur und Testautomatisierung

In der spezifischen Ausrichtung der Testprozesse werden übergreifend tätigen Testmanagern im Tribe (auch als Testmaster bezeichnet) auch tribeweite Testinfrastrukturaufgaben übertragen: Administration des eingesetzten Testmanagementtools, toolgestützte Verwaltung von Testumgebungen, Testusern, Testdaten und nicht zuletzt das Thema Testautomatisierung.

Testautomatisierung auf Komponentenebene (JUnit) - oder für die Middleware - wird tendenziell von Development Engineers übernommen. Stattdessen muss die Automatisierung fachlicher, meist frontendbasierter, Tests an Entwickler in Auftrag gegeben werden, da Fachtestern im Regelfall dazu das technische Know-How fehlt. Damit sinnvoll automatisiert werden kann, müssen die notwendigen Voraussetzungen geschaffen werden, indem z.B. ein Regressionstestportfolio für die Kernfunktionalitäten der automatisierten Anwendungen definiert und ein Pflegeprozess für das Portfolio aufgesetzt wird.

Continuous Integration und Continuous Deployment (CI/CD-Pipeline)

Übergreifendes Ziel der Einführung einer agilen Organisation ist die schnellere und flexiblere Bereitstellung der Features von Softwareprodukten unter Beibehaltung des notwendigen Qualitätsniveaus. Um dieses Ziel erreichen zu können, wird ein weitgehend einheitlicher, automatisierter Prozess bereitgestellt. Dieser beginnt mit dem Zusammenbau von Komponenten und reicht bis zum Deployment der angepassten oder neuentwickelten Komponenten in Produktion. Cloudtechnologien, Docker und Kubernetes werden dabei immer häufiger verwendet.

Automatisierte Tests sind in diesem Prozess fester Bestandteil: mit einer Änderung von Softwareprodukten werden in Testumgebungen automatisierte Tests passend bereitgestellt. Im Zielbild soll nach erfolgreicher Ausführung automatisierter Tests in vorgegebenen Testumgebungen eine Softwarekomponente ohne manuelle Eingriffe in Produktion deployed werden können.

Bis zur durchgehenden operativen Umsetzung des Zielbilds sind automatisierte und manuelle Testausführungen für Auswertungen und Entscheidungen allerdings zusammenzubringen. Auch dafür haben Testmanager in der agilen Organisation in einem geeigneten Testmanagementtool zu sorgen.

Mit der unternehmensweiten Fokussierung auf eine CI-/CD Pipeline gewinnt die Integration von Testprozessen mit Softwareentwicklungs- und Deploymentprozessen an Bedeutung. In einer Tribe Charta sind unternehmensweite Vorgaben der beteiligten Prozesse in der CI/CD-Pipeline für einen Tribe zu regeln. Testprozessbestandteile der Tribe Charta werden in der Regel vom übergreifenden Testmanager in Abstimmung mit der Test Guild eingebracht.

Fazit

In agilen Organisationen werden operative Testmanagementaufgaben von Mitgliedern der agilen Teams (Squads) übernommen. Für gemeinsame Beschlüsse, Informationsaustausch und Initiativen zur Testoptimierung empfiehlt sich innerhalb der Tribes die Einrichtung einer Test Guild, in der jede Squad von einem Teammitglied mit Testschwerpunkt vertreten wird.

Die Organisation der Test Guild, die Festlegung der Testrichtlinien für den Tribe, sowie teamübergreifende Aufgaben für Testinfrastruktur und Testautomatisierung verbleiben bei einem übergreifend tätigen Testmanager.

Dieser Überblick sollte Ihnen Anhaltspunkte für die Verteilung von Testmanagementaufgaben in einer agilen Organisation geben.

10. Oktober 202011. November 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Testdatenmanagement mit XDM - Effiziente und moderne Testdatenversorgung

Qytera News -

Lesedauer: 2 Minuten

Immer schneller werdende Softwareentwicklungszyklen, steigende Kosteneffizienz und sich stetig verbessernde Qualität haben dazu geführt, dass Testdatenmanagement integraler Bestandteil der Softwareentwicklung geworden ist.

Praktiken wie Continous Delivery, Continous Integration und DevOps sind maßgeblich an dessen Entwicklung beteiligt, da sich die Bereitstellung von Testdaten an die schnellen Entwicklungszyklen der Softwareentwicklung anpassen muss. Automatisierung und Flexibilität sind unverzichtbar, damit passende Testdaten zu jedem Zeitpunkt bereitstehen können. Es darf keine wertvolle Zeit darauf verwendet werden, Testfälle vor jedem Test mühsam zusammenzustellen oder immer dieselben starren Testfälle zu verwenden.

Testdatenmanagement wird damit zu einer der wichtigsten Bedingungen für den Erfolg der Software. Ziel des Testdatenmanagements ist die Planung, Organisation und Bereitstellung zielgerichteter Testumgebungen.

XDM – Agile Testdaten für agile Softwareentwicklung

XDM stellt Testdaten flexibel und automatisch in zeitlich definierten Abständen oder bei Bedarf ad-hoc bereit. Dabei automatisiert XDM sämtliche Datenbankoperationen und garantiert regelmäßige Ausführung über einen Scheduler. Die dabei transportierten Daten können inhaltlich verändert oder maskiert (anonymisiert / pseudonymisiert) werden. Ein sicherer Testdatenaustausch wird somit garantiert – Testdaten sind zu jedem Zeitpunkt verfremdet.

XDM ist nicht auf die reine Datenbereitstellung beschränkt, sondern ist ebenso in der Lage, Strukturanpassungen vorzunehmen. Die mit XDM kopierten Daten werden in für Testdaten vorgesehene Umgebungen abgelegt, die dann für einzelne Tests verwendet werden können oder als Basis für weitere Testumgebungen dienen.

Der XDM DataShop stellt das abteilungsübergreifende, zentrale Kommunikationsmittel der Testdatenbereitstellung dar – hier werden Kopieraufträge formuliert, überwacht und koordiniert.

Der DataShop ermöglicht es Bedarfsträgern, wie Entwicklern und Testern, Testdaten flexibel über ein Bestellportal anzufordern. Testdaten werden entweder auf Basis von Testfällen (zusammenhängenden Tabellenzeilen; ideal für kleinere Softwarekomponenten) bereitgestellt oder in Form von Massendaten (komplette Tabellen). Letztere eignen sich optimal für Tests, die größere Datenmengen benötigen, wie Stresstests oder Systemtests – also solche, die Anwendungen holistisch und auf Belastbarkeit testen.

Effizienz durch Spezialisierung

Mit Hilfe von XDM können verschiedene Arbeitsbereiche und Teilgebiete des Testdatenmanagements funktional getrennt werden. Dadurch ist es im Unternehmen möglich, einzelne Aufgaben bestimmten Abteilungen zuzuteilen. Alle Beteiligten nutzen eine bestimmte Komponente von XDM, welches dadurch als zentrales Kommunikationsmittel fungiert und gemäß modernen Praktiken, wie DevOps, die bessere Vernetzung der Bereiche Entwicklung (Development) und Betrieb (Operations) vorantreibt.

Unterschieden wird grundsätzlich zwischen Modellierern und Bestellern. Während Modellierer in Form von Datenbankadministratoren und Anwendungsarchitekten als technisch versierte Benutzer Grundlagen für eine flexible Testdatenbereitstellung – wie Bestellmasken, Kopieraufträge, Verbindungen und Regeln schaffen, müssen Besteller in Form von Testern und Entwicklern lediglich Testdaten anfordern.

Bild: Test Data Delivery Pipe mit XDM. (Klicken zum Vergrößern) [Quelle: UBS Hainer] × Erstellen Sie Ihre eigene Test Data Delivery Pipe

Ausgangsbasis des skalierbaren Testdatenmanagementkonzepts ist die Golden Copy, eine von der Produktion (durch Klonen) entkoppelte Testdatenumgebung, die in der Regel aus mehreren Datenbanken unterschiedlichen Typs besteht, welche gemäß geltenden DSGVO-Richtlinien während des Erstellprozesses anonymisiert (bzw. pseudonymisiert) wird.

Aus der Golden Copy können fachlich zusammenhängende Teile selektiert werden, die anschließend in eine neue Umgebung geladen werden.

Die Inhalte dieser Umgebungen entsprechen dem dafür vorgesehenen Zweck. Beispielsweise kann eine System-Test-Umgebung erstellt werden, die Datengrundlage für einen System-Test bereitstellt. Umgebungen können dabei entweder für den vorhergesehenen Zweck jedes Mal neu erstellt oder sukzessive erweitert werden.

Ein Testfall kann beispielsweise von einem Entwickler oder einem Tester über den DataShop bestellt werden. Dazu ruft dieser die Bestellmaske auf, die dem Zweck seiner Bestellung am besten entspricht, bestimmt die Parameter und führt die Bestellung schließlich durch.

Beispielsweise können gewünschte Testfälle spezifiziert oder deren Anzahl bestimmt werden. Möglich ist auch die Nutzung integrierter Modifikationsmethoden, die Daten während des Kopiervorgangs anpassen können. Sämtliche in XDM genutzte Prozesse können von Dritt-Software über eine Schnittstelle bedient werden. Darüber hinaus lassen sich externe Skripte oder Tools über XDM anstoßen.

Fazit

Die XDM Test Data Delivery Pipe fügt sich somit nahtlos in bestehende Prozesslandschaften ein und hebt diese auf ein neues Level! Lange Wartezeiten beim Beschaffen wichtiger Testdaten gehören damit der Vergangenheit an.

Über den Autor

Florian Kattner

Florian Kattner ist technischer Consultant bei UBS Hainer und berät Kunden zu Themen wie Testdatenmanagement und (DSGVO-konformer) Datenverfremdung. Darüber hinaus führt er zu diesen Themen Seminare durch und tritt als Redner auf Veranstaltungen auf.

01. Oktober 202001. Oktober 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Lasttest und Performancetest mit JMeter

Qytera News -

Lesedauer: 2 Minuten

Bei JMeter handelt es sich um ein von der Apache Foundation entwickeltes Tool für Last-, Performance- und Stresstests. Die Software ist Open Source und in Java programmiert. (Zur Ausführung wird eine Java-Installation benötigt.)

Der ursprüngliche Ansatz, der beim Einsetzen von JMeter verfolgt werden sollte, war eng mit dem Testing von Web-Applikationen verbunden. Mittlerweile hat das Tool viele weitere Schnittstellen erhalten, die das Testen von weiteren Applikationsarten (wie Schnittstellen, Mailserver, Datenbanken, Verzeichnisdienste, etc.) ermöglichen. Im Folgenden zeigen wir Ihnen einige der wichtigsten Features der JMeter Software.

Verschiedene Timer

Ihre echten User klicken nicht gleichmäßig über alle Seiten: Sie lesen den Inhalt einer Seite und gehen dann weiter. Dies kann mit verschiedenen Timern (mit fest eingegebenen oder auch zufälligen Zeitintervallen) simuliert werden.

Pre- und Post-Processing

Pre-Processors führen Tasks aus, bevor ein Abruf geschieht, Post-Processors danach. Pre-Processors dienen also der Vorbereitung eines bestimmten Aufrufs, beispielsweise indem sie Daten für den Aufruf erhalten. Post-Processors machen hingegen etwas mit den erhaltenen Daten aus dem Abruf. Ein häufiges Beispiel: zur Spamvermeidung ändern sich unsichtbare Formularinhalte ("nonce" = used only once), die dann vor jedem Absenden neu abgerufen werden müssen. Dies geschieht per Pre-Processor. Vor allem für die Nutzung von APIs gibt es den JSON-Extractor, der Inhalte aus einem JSON-Objekt extrahieren kann.

Gibt es ein Reporting-Feature?

Das Thema Reporting ist insbesondere für Last-, Performance- und Stresstests nötig. Hier wird mit großen Datenmengen gearbeitet, welche mit statistischen Methoden ausgewertet werden. JMeter bietet die Möglichkeit, einfach und schnell dynamische Reports, Diagramme und Graphen aus den erfassten Messungen zu generieren. Nachfolgend sind vier Beispiele aufgelistet.

Bild: JMeter APDEX-Tabelle. (Klicken zum Vergrößern) [Quelle: Apache Software Foundation] ×

Die APDEX-Tabelle (Application Performance Index) ist ein Standard, um die Nutzerzufriedenheit aus den Daten abzulesen. Ein APDEX wird für jede Transaktion mit dem jeweiligen Schwellenwerten berechnet. Im Request-Summary-Graphen wird der prozentuale Anteil an erfolgreich bzw. nicht erfolgreich durchgeführten Transaktionen dargestellt.

Bild: JMeter Statistics-Tabelle. (Klicken zum Vergrößern) [Quelle: Apache Software Foundation] ×

Die Statistics-Tabelle ist eine Übersicht aller Metriken einer Transaktion (eingeschlossen der drei konfigurierbaren prozentualen Spalten).

Bild: JMeter Errors-Tabelle. (Klicken zum Vergrößern) [Quelle: Apache Software Foundation] ×

Mithilfe der Errors-Tabelle wird die Gesamtanzahl an Fehlern und deren prozentualer Anteil aus der Gesamtanzahl an Requests dargestellt.

Bild: JMeter Antwortzeiten Diagramm. (Klicken zum Vergrößern) [Quelle: Apache Software Foundation] ×

Ein zoombares Diagramm mit dem sämtliche Transaktionen nach folgenden Ereignissen anzeigt werden: Antwortzeiten während einer Zeitperiode; Datendurchfluss während einer Zeitperiode; Latenzen während einer Zeitperiode; Hits pro Sekunde; Codes pro Sekunde; Transaktionen pro Sekunde

JMeter mit Selenium ...?

In unserem Selenium-Seminar weisen wir immer wieder darauf hin, dass Selenium sich nicht für Last- und Peformancetests eignet. Aber manchmal wird doch mehr benötigt als JMeter allein schafft. Auf der Website von Blazemeter wird eine Schritt-für-Schritt Anleitung vorgestellt, wie die Integration beider Tools gelingen kann. Aber ist sie notwendig, was wird damit erreicht? Somit wird die Infrastruktur geschaffen, Lasttests/Performancetests durchzuführen, in den mit dem "echten" Webbrowser interagiert wird und wiederum Selenium WebDriver durch JMeter aufgerufen wird. Diese Integration verschafft den Vorteil beim Lasttest, dass auch die Rendering-Zeiten vom Webbrowser berücksichtigt werden, die sonst nicht in die JMeter-Statistik einfließen.

Fazit

JMeter ist ein hervorragendes Tool für Last- und Performancetests, das allem durch die Anwendungsbreite punktet: heute können Sie damit Lasttests mit Webseiten durchführen, morgen Stresstests mit APIs und auch Sie die Performance Ihrer Datenbanksysteme können Sie damit testen. Darüber hinaus haben Sie vielfältige Möglichkeiten, Reports zu erstellen - und diese sind für die Interpretation der Ergebnisse essenziell. Soll es außerdem eine Open Source Software sein, die von einer bekannten Organisation verwaltet wird, kommen Sie an Apache JMeter nicht vorbei.

01. Oktober 202006. Januar 2021Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen: