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.

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