Qytera News

Podcast #27: Testprozesse verbessern in der Praxis mit TMMi

Podcast #27: Testprozesse verbessern in der Praxis mit TMMiHördauer: 71 Minuten

Handlungsmotive, Erfolgsfaktoren und die gezielte Beseitigung von Hindernissen sind für das Verbessern von Testprozessen in der Praxis wichtig, wobei das Thema in vielfältigen Formen angegangen werden kann. Mit viel Erfahrung in dieser Hinsicht erklärt Matthias Rasking im Dialog mit Markus, welche Vorgehensweisen sich in der Praxis bewährt haben. TMMi als das weltweit führende Modell für Testprozessverbesserungen gibt den Rahmen.

Hör' Dir hier den ganzen Podcast an: Diese Themen erwarten Dich:

[00:00] Intro

[00:33] Überblick über den Podcast

[00:33] Vorstellung Matthias Rasking

[03:38] Einstieg in das Thema Testprozessverbesserung

[04:41] Auswahl des Themas

[05:18] Zielgerichtete Herangehensweise

[06:34] Kleine Schritte oder größerer Rahmen

[08:25] Testprozessverbesserung nebenbei

[09:21] Testprozessverbesserung im Rahmen der Verbesserung des SDLC

[10:36] Bedeutung von Referenzmodellen für die praktische Umsetzung

[12:23] Gewünschte Eigenschaften von Referenzmodellen für optimalen Einsatz

[13:32] Erfahrungen in der Praxis mit der Anwendung von Referenzmodellen

[15:15] Testprozessverbesserungen ohne Einsatz eines Referenzmodells?

[16:13] Einstieg in ein Testprozessverbesserungsprojekt

[18:14] Wichtige Erfolgsfaktoren für die Umsetzung

[20:03] Kundenmotive

[23:15] Die größten Hindernisse bei der praktischen Umsetzung

[25:12] Einfluss des Kontextes

[27:11] Faktoren bei der Aufwandsschätzung

[28:58] Erfolgsmessung von Verbesserungsmaßnahmen

[31:00] Erfahrungen mit Metriken

[32:46] Managementsupport

[34:58] Testprozessverbesserungsvorschläge von unten

[36:30] Unternehmensinterne Testprozessverbesserung

[37:43] Einsatz eines externen Dienstleisters

[39:50] Beteiligung eines erfahrenen Assessors

[41:41] Bewertung des Reifegrads eines Testprozesses im Team

[43:39] Erfahrung mit dem Scheitern eines Testprozessverbesserungsprojekts

[46:38] Vorteile von TMMi im praktischen Einsatz

[49:18] Kontinuierlicher Einsatz von TMMi

[50:57] Zusammenhang TMMi mit CMMI

[53:29] Künftige Änderungen an TMMi wegen CMMI 2.0

[55:57] Testprozessverbesserung lernen ?

[56:51] Ausbildung von Projektbeteiligten

[58:54] Separate Schulung eines Referenzmodells

[59:58] Praktischer Nutzen bringt einer Zertifizierung zum TMMi Professional

[101:27] Vorteile eines Trainings für einen Assessor

[103:10] Markt für Testprozessverbesserungen in Deutschland ?

[106:07] Änderung am Thema Testprozessverbesserung durch Agilität und DevOps

[108:26] Dienstleistungsangebot

[109:48] Kontaktaufnahme

[110:25] Outro

08. Februar 202408. Februar 2024Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Webinar: Cloud-basiertes Performancetesting mit Microsoft Azure Load Testing (JMeter, Azure DevOps)

Webinar: Cloud-basiertes Performancetesting mit Microsoft Azure Load Testing (JMeter, Azure DevOps)Lesedauer: 1 MinuteAgenda

Website-Performancetests sind für eine optimale Benutzererfahrung und SEO von entscheidender Bedeutung. Sie sind unerlässlich, um die Skalierbarkeit zu überprüfen und zu zeigen, wie gut eine Website unter (wechselnder) Last funktioniert. Apache JMeter spielt dabei eine zentrale Rolle, indem es zeigt, wie eine Website unter verschiedenen Lastszenarien reagiert. Seine Skalierbarkeit erlaubt es, von einfachen bis hin zu komplexen Testszenarien alles abzudecken.

Die Einführung von Cloud-basierten Lösungen wie Microsoft Azure Load Testing erweitert diese Möglichkeiten zusätzlich. Azure Load Testing nutzt Cloud-Infrastrukturen für umfassende und realistische Tests, ohne dass lokale Ressourcen benötigt werden. Die Elastizität der Cloud, gepaart mit der Integration in Azure DevOps, kann die Durchführung kontinuierlicher Performancetests fördern und zur kontinuierlichen Verbesserung der Website-Performance beitragen. In diesem Webinar werden wir das Zusammenspiel zwischen JMeter, Azure Load Testing und Azure DevOps erläutern und veranschaulichen.

Sehen Sie sich hier das komplette Webinar an: -->Themenübersicht
  • Vorstellung Apache JMeter als Werkzeug
  • Wie man mit JMeter skaliert
  • Erklärung der Architektur von JMeter
  • Erklärung Azure Load Testing
  • Hands On Einblicke mit Azure Load Testing
    • Website (Single-Page)
    • Klickstrecke mit Apache JMeter
    • Einbindung in Azure DevOps Pipeline
Fazit

Performancetests sind entscheidend für die Optimierung der Benutzererfahrung einer Website. Die Kombination von Tools wie Apache JMeter und Cloud-basierten Lösungen wie Microsoft Azure Load Testing ermöglicht umfassende und realistische Testszenarien, die essentiell für die kontinuierliche Verbesserung der Website-Leistung sind.

Das Webinar richtet sich an:
  • Entwickler*innen
  • Performancetester*innen
  • DevOps-Engineers
  • Testmanager*innen
  • Testautomatisierer*innen

Datum und Uhrzeit: Am 21. März 2024 (Do) um 17:00

Dauer inkl. Q&A: 1 Stunde

Jetzt kostenlos anmelden -->Sprecher

Matthias Eggert:

Matthias war viele Jahre in der Automobilbranche als Softwareintegrator, Softwareentwickler und DevOps-Engineer tätig. Jetzt arbeitet er als DevOps-Engineer bei Qytera und beschäftigt sich sowohl mit modernen Arbeitsweisen, als auch mit aktuellen Technologietrends, wie Cloud-basierte Softwaretest Lösungen.

Moderator

Markus Thaler:

Markus Thaler war 22 Jahre in der Commerzbank tätig, wo er sich mehr als 10 Jahre um Teststandards, Testwerkzeuge und Testautomatisierung in einer zentralen Funktion gekümmert hat, bevor er nach einer Zwischenstation im Testinfrastrukturmanagement acht Jahre als Testmanager in der Risikofunktion der Commerzbank gewirkt hat. Vor der Commerzbank konnte er Testerfahrungen bei Lufthansa, Siemens, Nestle und der DZ-Bank gewinnen. Aktuell ist er als Senior Testmanager und Testarchitekt bei Qytera tätig.

Jetzt kostenlos anmelden -->16. Januar 202416. Januar 2024Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Überblick zum begehrten Testautomatisierungs Tool Playwright - Open Source End-To-End Tests

Überblick zum begehrten Testautomatisierungs Tool Playwright - Open Source End-To-End TestsLesedauer: 4 Minuten

Im Bereich der Open-Source End-To-End Test-Frameworks gesellt sich seit Kurzem ein neuer Player hinzu, nämlich Playwright. Wer mit Playwright loslegen will, braucht lediglich das Node.js Paket zu installieren, das alle nötigen Erweiterungen beinhaltet. Es beinhaltet auch alle nötigen Browser-Treiber, sodass nicht wie in Selenium jeder einzelne Browser-Treiber von Hand installiert werden muss.

Da es sich bei Playwright um ein UI-basiertes Automatisierungstool für Webanwendungen handelt, lassen sich Aktionen wie beispielsweise das Anlicken von Schaltflächen oder Ausfüllen von Textfeldern ganz bequem automatisieren. Zu den unterstützten Programmiersprachen zählen Java, Python, .NET C#, TypeScript und JavaScript. Unter den Browsern werden Firefox, Chromium und Webkit unterstützt auf sowohl Windows, Linux und Mac OS.

Inhaltsverzeichnis:
  1. Warum Testautomatisierung?
  2. Die wichtigen Aspekte der Testautomatisierung
  3. Geschichte von Playwright und Selenium
  4. Vor- und Nachteile von Playwright zu Selenium
  5. CI-CD
  6. Trace Viewer
  7. Fazit
Warum Testautomatisierung?

Testautomatisierung kann zur Simulierung des Benutzerverhaltens verwendet und eingesetzt werden. Dabei wird getestet, ob auch Applikationen das gewünschte Verhalten aufweisen. Testautomatisierung sorgt in allererster Linie für bessere Software-Qualität, da Tests wesentlich schneller und effizienter durchgeführt werden können. Fehler, die beim stetigen manuellen Testen durch den Faktor Mensch auftreten können, können dadurch enorm reduziert werden. Auch können Entwicklerkapazitäten für wichtigere Aufgaben eingesetzt werden statt sich auf das repetitive Testen zu konzentrieren.

Die wichtigen Aspekte der Testautomatisierung
  • Geschwindigkeit, Effizienz und Skalierbarkeit: Da in der Regel die Verarbeitungszeit vom Computer viel schneller als die vom Menschen ist, werden auch die Tests entsprechend innerhalb von Sekunden ausgeführt. Das spart zum einen Zeit und kann auch nach Belieben parallel skaliert werden.
  • Reduzieren von Fehlern: Da Menschen nicht stetig produktiv arbeiten können, können insbesondere beim manuellen Testen Fehler auftreten. Weil automatisierte Tests davon in der Regel nicht betroffen sind, lassen sich so viele Fehlerherde eindämmen, womit auch eine zusätzliche Konsistenz und Zuverlässigkeit einhergeht.
  • Schnelleres Auffinden von Bugs: Je früher mit der Testautomatisierung in einem Projekt begonnen wird, desto früher können unerwünschte Bugs gefunden und rechtzeitig behoben werden, was die Effizienz innerhalb des Teams steigert.
  • Schnellerer Entwicklungszyklus: Automatisierte Tests können personenunabhängig zu jeder Zeit wiederholt ausgeführt werden und somit den Entwicklungsprozess beschleunigen.
Geschichte von Playwright und SeleniumSelenium

Mit einem Alter von fast 20 Jahren ist Selenium im Gegensatz zu Playwright eindeutig das ältere Gegenstück. Dieses entwickelte Jason Huggins im Jahre 2004 im Rahmen eines internen Projekts in seiner Firma ThoughtWorks, das als primäres Ziel das Testen von Webseiten verfolgte. Im Laufe der Zeit schlossen sich immer mehr Mitarbeiter dem Projekt an, inklusive Paul Hammant, der auch als Initiator die Entwicklung von Selenium Remote Control vorantrieb.

Im Jahre 2007 wechselte Huggins dann zu Google und führte dort weitere Verbesserungen an Selenium fort, während zur selben Zeit Simon Stewart parallel in ThoughtWorks die Browsersteuerung Webdriver entwickelte. Beide erkannten aber schnell, dass zwei getrennte Projekte am selben Entwicklungsobjekt wenig Sinn machen würden, weshalb beide dann zum Selenium Webdriver – auch Selenium 2.0 genannt – vereint wurden. Der Sprung auf Selenium 3.0 erfolgte dann am 13. Oktober 2016, das bis heute verwendet wird.

Playwright

Wesentlich kürzer auf dem Markt ist Playwright, das am 31. Januar 2020 von Microsoft veröffentlicht wurde. Die Köpfe, die hinter dessen Entwicklung steckten, waren auch diejenigen, die an der Entwicklung von Googles Puppeteer mitwirkten. Wie auch Selenium verfolgt Playwright das Testen von Webseiten. Trotz seines jungen Alters erfreut sich das Testing-Tool stetiger Beliebtheit, was sich auch aus den Zahlen sowie aus dem darauffolgenden Diagramm ersehen lässt. Zu erwähnen wäre, dass es sich hier um die JavaScript-Versionen handelt.

Download-Zahlen Trend von Selenium und Playwright (JavaScript-Version) Bild: Die wöchentlichen Downloads von Selenium und Playwright - Stand: 29.11.2023 [Quelle: GitHub] × Vor- und Nachteile von Playwright zu SeleniumPlaywright
  • Auto-Waits: Wartet automatisch, bis auch die Elemente verfügbar und für Interaktionen bereit sind
  • Vorhandensein eines Trace Viewers, der es erlaubt, verfolgen zu können, wo Playwright beim Test exakt ausgestiegen ist und welche Aktionen ausgeführt wurden. Zudem gibt es die Möglichkeit einer Videoaufnahme, sodass auch die durchgeführten Tests von überall her erneut abgespielt werden können
  • API-Anbindung: Playwright kann auch auf API-Schnittstellen zugreifen, was zu sehr viel schnelleren und stabileren Tests führt. Zudem können Requests abgefangen und nach Belieben manipuliert werden, um schwer zu erreichende Zustände im Frontend zuverlässig zu erzeugen.
  • Mit etwas Aufwand ist die Anbindung an Test-Management Tools möglich
  • Da Playwright noch relativ neu auf dem Markt ist, hat es entspechend eine kleinere Community als Selenium
Selenium
  • Keine Auto-Waits: Es muss manuell angegeben werden, wo man warten will, bis die Elemente verfügbar sind, was aufwändiger zu implementieren ist
  • Kein Trace Viewer und keine Videoaufnahme vorhanden
  • Keine API-Anbindung vorhanden
  • Mit etwas Aufwand ist die Anbindung an Test-Management Tools möglich
  • Da Selenium wesentlich länger im Geschäft ist, ist es auch entsprechend weiter verbreitet
CI-CD

Aufgrund der umfassenden Dokumentation von Playwright ist eine bequeme Integration dessen in Azure DevOps und Jenkins möglich, um effektiv seine Tests durch die vorhergesehenen Pipelines laufen zu lassen. Falls ein Test in der Pipeline fehlschlagen sollte, wird auch innerhalb dessen angezeigt, warum dieser fehlgeschlagen ist:


Running 124 tests using 6 workers
[24/124] [regression] › name-overview/name-list/names/testcase.spec.ts:12:34 › 123456 Verify name › Max Mustermann
3) [regression] › name-overview/name-list/names/testcase.spec.ts:12:3 › 123456 Detect invalid names › Tim Mustermann

Error: expect(received).toBe(expected) // Object.is equality

Expected: "the name does not exist"
Received: null

20 | await addName.clickNext(true);
21 | const nameError = await addName.getNameError();
> 22 | expect(nameError).toBe(nameError.Undefined);
| ^
23 | });

Wer hingegen einen weiteren Performance-Boost benötigt, für den bietet Playwright den kostenpflichtigen Microsoft Playwright Testing Service an, der es erlaubt, via Cloud die Parallelinstanzen auf das Mehrfache zu skalieren, womit der Durchlauf von Tests in der Pipeline um das Vielfache beschleunigt werden kann. Das nächste Bild zeigt einen Testdurchlauf von Playwright mit rund 3000 Tests verteilt auf 50 Parallelinstanzen, die innerhalb von nur 32 Sekunden abgearbeitet werden:

Bild: Demo Testdurchlauf von Playwright mit rund 3000 Tests und 50 Instanzen [Quelle: Playwright] × Trace Viewer

Wie schon vorher erwähnt, ist einer der größten Vorzüge von Playwright der Trace Viewer, der das Auffinden von Problemen ungemein erleichtert. Das folgende Bild gibt einen kurzen Einblick dazu:

Bild: Der Trace Viewer von Playwright [Quelle: Playwright] × Fazit

Als Newcomer im Bereich der Testautomatisierung bietet Playwright eine Bandbreite von Features, die Selenium leider missen lässt. Darunter sind insbesondere der Trace Viewer, die API-Anbindung sowie die Auto-Waits, die zum einen ein einfacheres Debugging ermöglichen, zum anderen für stabilere und performantere Tests sorgen.

Auch wenn Selenium auf dem Markt noch weit verbreitet ist, zeigen die wöchentlichen Downloads, dass sich langsam ein Abwärtstrend erkennen lässt, wohingegen Playwright immer mehr an Bedeutung gewinnt. Das hat auch unter anderem damit zu tun, dass Playwright die Defizite von Selenium erkannt und entsprechend optimiert bzw. ausgebaut hat. Für zukunftsorientiertes Automatisieren ist daher Playwright zu empfehlen. Wer hingegen auf ein aktuell weit verbreitetes Testing-Tool mit etablierter Community setzt, der sollte einen Blick auf Selenium werfen.

Link-Verzeichnis 20. Dezember 202320. Dezember 2023Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Qytera Akademie: ISTQB Certified Tester Foundation Level 4.0

Qytera Akademie: ISTQB Certified Tester Foundation Level 4.0Lesedauer: 3 Minuten

Im September 2023 wurde die deutschsprachige Version des Lehrplans zum ISTQB Certified Tester Foundation Level 4.0 vom German Testing Board (GTB) veröffentlicht. In diesem Artikel gehen wir auf Änderungen und Implikationen ein.

Inhaltsverzeichnis:
  1. Was hat sich mit ISTQB Certified Tester Foundation Level 4.0 geändert?
  2. Ich möchte mich zertifizieren lassen... was bedeutet die Version 4.0 für mich?
  3. Was bedeutet die neue Version für bereits Zertifizierte?
  4. Bietet die Qytera Trainings für den ISTQB Foundation Level Version 4.0 an?
  5. Fazit
Was hat sich mit ISTQB Certified Tester Foundation Level 4.0 geändert?

Während die Vorgängerversion im Wesentlichen eine Aktualisierung von Themen bedeutete, sind die Änderungen der Version 4.0 grundsätzlicher Natur. Im Syllabus heißt es dazu: "Der ISTQB® Foundation Lehrplan v4.0 ist eine umfassende Aktualisierung, die auf dem Foundation Level Lehrplan (v3.1.1) und dem Agile Tester Lehrplan 2014 basiert." Es wurden somit zwei Lehrpläne zusammengeführt und zu einem vereinheitlichten Lehrplan umgestaltet.

Wie sehen nun die durchgeführten Änderungen aus? Neue Abschnitte sind hinzugekommen, andere wurden überarbeitet, teilweise wurden Themen aber auch gestrichen. Einige wesentliche Änderungen möchte ich hier zusammenfassend darstellen.

  • In Kapitel 1 (Grundlagen des Testens) wurde der Abschnitt über Rollen und Kompetenzen beim Testen erweitert und verbessert, ein Abschnitt über den Whole-Team-Ansatz hinzugefügt. Unterschiede zwischen Denkweisen von Testern und Entwicklern werden nicht mehr behandelt.
  • In Kapitel 2 (Testen während des Softwareentwicklungslebenszyklus) wurden die Beziehungen zwischen Softwareentwicklungsaktivitäten und Testaktivitäten umgeschrieben . Neben neuen Abschnitten zu Praktiken wie Test-First-Ansatz, Shift-Left und Retrospektiven wurde Testen im Kontext von DevOps ergänzt. Die Teststufe Integrationstest wurde in zwei separate Teststufen aufgeteilt: Komponentenintegrationstests und Systemintegrationstests.
  • Kapitel 3 (Statischer Test) enthält nun nicht mehr die Anwendung eines Reviewverfahrens auf ein Arbeitsergebnis. Die diesbezügliche Übung ist entfallen.
  • In Kapitel 4 (Testanalyse und -entwurf) wurde anwendungsfallbasiertes Testen entfernt. Im Fokus steht ein Testansatz, der auf Zusammenarbeit basiert. Die Verwendung von Acceptance Test Driven Design (ATDD) zur Ableitung von Testfällen, User Storys und Akzeptanzkriterien werden in diesem Zusammenhang behandelt. In dem Kapitel wurde aber auch eine begriffliche Überarbeitung vorgenommen: Entscheidungstests und Entscheidungüberdeckung heißen nun Zweigtests und Zweigüberdeckung.
  • Kapitel 5 (Management der Testaktivitäten) behandelt Teststrategien/-vorgehensweisen nicht mehr, geht dafür mit einer zusätzlichen Übung auf Verfahren zu Schätzung des Testaufwands ein. Allseits gebräuchliche Konzepte und Werkzeuge im Testmanagement von agilen Projekten wie Iterations- und Releaseplanung, Testpyramide und Testquadranten werden in neuen Abschnitten behandelt. Das Thema Risikomanagement wurde neu strukturiert.
  • Das Kapitel 6 (Testwerkzeuge) wurde gekürzt. Der Abschnitt über die Auswahl von Werkzeugen, die Durchführung von Pilotprojekten und die Einführung von Werkzeugen im Unternehmen wurde entfernt.

Wer sich für weitere Details zu den Änderungen interessiert, kann diese im Anhang C zum deutschen Syllabus der Version 4.0 finden. Wer mehr über die Hintergründe und die Entstehungsgeschichte der Version 4.0 erfahren will, der sei hingewiesen auf den Vortrag “Der neue CTFL 4.0” von Stephanie Ulrich (GTB) auf dem A4Q-Summit in Zürich. Stephanie hat aktiv an der Neugestaltung der Foundation Level Version 4.0 mitgewirkt.

Insgesamt macht der Lehrplan für den Foundation Level 4.0 einen kompakteren Eindruck als sein Vorgänger. Trotz Themenerweiterungen hat sich der Umfang um einige Seiten reduziert. Beim Verfassen des Lehrplans wurden dafür strikte Vorgaben eingehalten, die die Textlänge der Abschnitte abhängig zur kognitiven Stufe zugehöriger Lernziele beschränken. Dafür wurde u.a. auch auf Beispiele verzichtet.

Zur Prüfungsvorbereitung steht in deutscher Sprache für Version 4.0 aktuell eine Musterprüfung zur Verfügung. Wem das nicht reicht kann zusätzlich fünf Musterprüfungen auf Englisch nutzen (über ISTQB). Es ist davon auszugehen, dass weitere Musterprüfungen in deutscher Sprache zur Verfügung gestellt werden. Die Anzahl der Fragen in der Prüfung haben sich durch Foundation Level 4.0 nicht geändert. Es bleibt bei 40 Fragen, für deren Beantwortung ein Prüfling 60 Minuten Zeit hat. Nicht-Muttersprachler erhalten wie bisher weiterhin 15 Minuten Extrazeit.

Ich möchte mich zertifizieren lassen... was bedeutet die Version 4.0 für mich?

Wenn Sie kurz vor der Zertifizierung stehen, könnten Sie sich noch nach Version 3.1 prüfen lassen (zeitlich ist dies bis November 2024 möglich). Wenn Sie jedoch noch am Anfang Ihrer Lernbemühungen stehen, raten wir Ihnen, direkt mit dem Lehrplan für Foundation Level Version 4.0 einzusteigen.

Was bedeutet die neue Version für bereits Zertifizierte?

Streng genommen ändert sich für Sie nichts. Ihr Zertifikat bleibt gültig. Andererseits sollten Sie sich mit dem neuen Lehrplan beschäftigen, um zu sehen, was sich geändert hat und wie sich der Testbereich wandelt.

Bietet die Qytera Trainings für den ISTQB Foundation Level Version 4.0 an?

Die Qytera GmbH ist für den Foundation Level in der Version 4.0 beim German Testing Board bereits akkreditiert. In 2024 wird Qytera nur noch Schulungen nach dem 4.0 Lehrplan anbieten.

Fazit

Mit dem Lehrplan für den Foundation Level 4.0 wird interessierten Personen der Einstieg in das systematische Testen erleichtert. Durch den Einbezug aktueller Themen wie Agilität und DevOps rücken die im Kurs behandelten Testthemen näher an die aktuell erlebte Arbeitswelt von Kursteilnehmern. Andererseits hat die im Foundation Level behandelte Themenvielfalt zugenommen und macht eine gute Prüfungsvorbereitung noch wichtiger als in der bisherigen Version.

15. Dezember 202315. Dezember 2023Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Webinar: Hohe Softwarequalität sicherstellen mit Playwright Reporting in CI/CD Pipelines (AWS, GitHub)

Webinar: Hohe Softwarequalität sicherstellen mit Playwright Reporting in CI/CD Pipelines (AWS, GitHub)Lesedauer: 1 MinuteAgenda

Liebe Testmanager*innen & Testautomatisierer*innen, es ist eine Herausforderung für Sie, die Qualität Ihres Softwareprodukts am Ende des Testzyklus zu verstehen und zu überprüfen? Vielleicht haben Sie bereits Testautomatisierung implementiert, jedoch fühlen Sie sich unsicher, ob bedeutende Fehler behoben sind und Ihr Produkt wirklich reibungslos funktioniert?

Wenn in Tests Fehler auftreten, ist die Untersuchung der Ursachen typischerweise mühsam. Oft ist nicht mal klar, ob wirklich die Anwendung den Fehler enthält oder der Test schlicht fehlerhaft ist. Aussagekräftige Rückschlüsse lassen sich dann erst nach einer manuellen Reproduzierung der Tests ziehen, was Zeit und Nerven kostet. Auch das darauffolgende Schreiben von Bugs mit detaillierten Steps to Reproduce resultiert oft in Prokrastination, sodass die Anwendung letztlich immer instabiler wird.

Playwright bietet ein Feature, mit dem sich alle der oben angesprochenen Probleme lösen lassen: Der HTML-Report. Im Gegensatz zu anderen Testautomatisierungstools wie Cypress oder Selenium liefert Playwright diesen völlig Open Source mit und steigert die bereits hohe Nutzerfreundlichkeit deutlich. Wie genau das Reporting-Feature von Playwright die Ursachenfindung vereinfacht, verschnellert und präzisiert, werden wir in diesem Webinar behandeln.

Sehen Sie sich hier das komplette Webinar an: -->Themenübersicht
  • Überblick über Playwright Reporting
  • Warum ist der Playwright HTML Report besonders nützlich?
  • Wie kann man Playwright HTML Reports als Pipeline-Artefakt in GitHub verfügbar machen?
  • Wie kann man die Reports über AWS auch Teammitgliedern zur Verfügung stellen, die keine Ahnung von GitHub haben?
  • Wie kann man dabei verhindern, dass die im Report enthaltenen, sensiblen Daten veröffentlicht werden?
Fazit

Playwright bietet für das Reporting mächtige Möglichkeiten, die sich in Verbindung mit Cloud-Technologien gewinnbringend in jedem Projekt einsetzen lassen. Sich diesem Thema zu widmen lohnt sich auf jeden Fall, wenn man stabile Produkte entwickeln und eine langfristig nachhaltige Fehlerkultur leben möchte.

Das Webinar richtet sich an:
  • Testmanager
  • Testautomatisierer
  • Testanalysten
  • Entwickler

Datum und Uhrzeit: Am 7. Dezember 2023 (Do) um 17:00

Dauer inkl. Q&A: 1 Stunde

Jetzt kostenlos anmeldenSprecher

Sebastian Vollbrecht:

Sebastian Vollbrecht ist nach Erhalt seines M. Sc. Informatik direkt im Testing gelandet. Dort konnte er als Consultant innerhalb kürzester Zeit bereits mehrere Projekte erfolgreich abschließen, in denen hauptsächlich JMeter, Cypress, Selenium und Playwright zum Einsatz kamen. Auch durch die im Studium gesammelte Praxiserfahrung konnte er sich einen essentiellen Erfahrungsschatz erarbeiten und weiß mittlerweile, dass das Reporting von (Test-)Ergebnissen oft eines der wichtigsten Element gelungener Projektarbeit ist. Als Verfechter der Open Source weiß er Plugin-Architekturen und Modifizierbarkeit zu schätzen und freut sich, dass auch die Tester-Community diesen Gedanken wertschätzt. Zurzeit ist er als Test Automation Engineer für die Qytera Software Testing Solutions GmbH tätig.

Moderator

Markus Thaler:

Markus Thaler war 22 Jahre in der Commerzbank tätig, wo er sich mehr als 10 Jahre um Teststandards, Testwerkzeuge und Testautomatisierung in einer zentralen Funktion gekümmert hat, bevor er nach einer Zwischenstation im Testinfrastrukturmanagement acht Jahre als Testmanager in der Risikofunktion der Commerzbank gewirkt hat. Vor der Commerzbank konnte er Testerfahrungen bei Lufthansa, Siemens, Nestle und der DZ-Bank gewinnen. Aktuell ist er als Senior Testmanager und Testarchitekt bei Qytera tätig.

Jetzt kostenlos anmelden 16. November 202316. November 2023Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Podcast #24: Testautomatisierung, CI/CD & DevOps in der Automobilindustrie

Podcast #24: Testautomatisierung, CI/CD & DevOps in der AutomobilindustrieHördauer: 49 Minuten

CI/CD und DevOps in der Automobilindustrie sind anders, als in anderen Branchen. Neben der Software sind bei den Softwaretests zudem die Mechanik und Elektronik zu berücksichtigen. Vor der Freigabe kommt der Fahrversuch und der ist automatisiert (noch) nicht möglich. Funktionale Sicherheit steht im Fokus, auch wenn IT-Sicherheit an Bedeutung gewinnt. ISO 26262, ASPICE und AUTOSAR geben den Rahmen. Matthias führt im Dialog mit Markus in diese Welt ein.

Hör' Dir hier den ganzen Podcast an: Diese Themen erwarten Dich:

[00:00] Intro

[00:33] Kurzer Überblick über den Podcast

[01:12] Vorstellung Matthias Eggert

[02:48] Was ist bei der Softwareentwicklung in der Automobilindustrie anders?

[06:42] Bedeutung der Software in der Automobilindustrie

[08:06] Rolle mechanischer und elektronischer Anteile beim Testen von Fahrzeugen

[10:25] SIL (Software in the Loop) und HIL (Hardware in the Loop)

[12:33] Der Fahrversuch in der Auslieferungskette

[14:59] Trends der Softwareentwicklung in der Automobilindustrie

[16:01] Softwareanteil bei e-Fahrzeugen

[16:29] Zentralcomputer in einem Auto und autonomes Verfahren

[17:46] Bedeutung der Wiederverwendbarkeit

[19:43] Produktfamilien und ihre Vorteile

[20:31] Auswirkungen des Einsatzes von Produktfamilien

[21:51] Funktionaler Sicherheit in einem Auto

[22:33] Bedeutung der ISO 26262 für funktionale Sicherheit

[23:19] Nachweis bidirektionaler Traceablity

[25:01] Überdeckungsmessung mit modified condition decision coverage (mcdc)

[28:08] Relevante Standards für die Automobilindustrie (ASPICE, AUTOSAR)?

[29:47] Safety bleibt top-priority: was ist mit Security in der Automobilindustrie?

[31:32] Besonderheiten einer CI/CD-Pipelines in der Automobilindustrie

[33:33] Effektive Implementierung der Prinzipien von CI/CD als Herausforderung

[36:45] CI/CD-Pipelines und Produktfamilien

[38:02] Agil arbeiten im Automotive Kontext?

[40:35] Was bedeutet DevOps für Dich?

[41:01] DevOps im Automobilbereich: Kontextbezogene Grenzen von CD

[44:14] Beteiligte an frühzeitigem Feedback

[45:19] Als Fahrer eines Autos Feedback in die Ci/CD-Pipeline einbringen

[46:06] Erwartbare Änderungen im Automobilbereich

[48:12] Outro

14. November 202314. November 2023Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen: