#Regressionstest

[frentmeister]

Millionen Zeilen Code aber nicht einen Test. Wo startet man?

Eine berechtigte Frage, oder? Aber wie gehen wir am besten vor? Wir haben auf der einen Seite massiv viele Zeilen Code, aber eben keinerlei Test. Das genau ist in vieler Hinsicht schon ein massiver Fehler. Woher wissen wir eigentlich, dass der Source nicht massive Sicherheitsprobleme hat? Aus meiner Sicht ist es immer natürlich besser direkt mit dem Verständnis des Codes zu beginnen und eben mit der Codeanalyse auch gleichzeitig eine gewisse Spur von Expertise - Codeanalysen: Beginnt mit der Codeanalyse und dem Verständnis: Startet damit, die Architektur und Funktionalität des Codebestands zu verstehen. Dies könnte das Durchlesen von Dokumentationen beinhalten, falls verfügbar, sowie das Untersuchen des Codes selbst. Identifiziert kritische Bereiche, Module oder Funktionen, die für die ordnungsgemäße Funktion der Anwendung unerlässlich sind. - Identifiziert Hochrisikobereiche: Fokussiert euch auf kritische Funktionalitäten oder Module, die bei einem Ausfall wahrscheinlich den größten Einfluss haben. Sucht nach komplexen Algorithmen, Ein- und Ausgabevorgängen oder Bereichen, in denen Fehler am wahrscheinlichsten auftreten. - Priorisiert: Priorisiert die identifizierten Hochrisikobereiche für das Testen. Erwägt, mit Bereichen zu beginnen, die für die Funktionalität der Anwendung am wichtigsten sind oder in denen Fehler am wahrscheinlichsten auftreten. - Unittesting: Beginnt damit, Unittests für einzelne Funktionen oder Module zu schreiben. Unittests konzentrieren sich darauf, kleine Codeeinheiten isoliert zu testen. Wenn der Codebestand nicht für einfaches Unittesting strukturiert ist, erwägt eine Refaktorisierung, um ihn testbarer zu machen. - Integrationstesting: Sobald ihr Unittests implementiert habt, geht zum Integrationstesting über. Integrationstests konzentrieren sich darauf, wie verschiedene Teile des Systems zusammenarbeiten. Testet Interaktionen zwischen Modulen, Komponenten oder externen Abhängigkeiten. - Regressionstesting: Nach der Implementierung von Tests für kritische Bereiche solltet ihr Regressionstests hinzufügen, um sicherzustellen, dass neue Codeänderungen keine neuen Fehler einführen oder vorhandene Funktionalität beeinträchtigen. Automatisiert Regressionstests, wo immer möglich, um Probleme frühzeitig im Entwicklungsprozess zu erkennen.Kontinuierliches Testen und Integration: Implementiert eine Continuous Integration (CI)-Pipeline, um den Testprozess zu automatisieren. Dadurch werden Tests automatisch durchgeführt, wenn Änderungen am Codebestand vorgenommen werden. Integriert das Testen in den Entwicklungsworkflow, um euch dazu zu ermutigen, Tests für neuen Code zu schreiben und vorhandenen Code zu refaktorisieren, um ihn testbarer zu machen. - Codeüberprüfung: Integriert Codeüberprüfungen in den Entwicklungsprozess, um sicherzustellen, dass neue Codeänderungen gründlich getestet werden und bewährten Praktiken entsprechen. Ermutigt euch dazu, testbaren Code zu schreiben, und gebt Anleitungen zum Schreiben effektiver Tests. - Dokumentation und Wissensaustausch: Dokumentiert Teststrategien, bewährte Praktiken und spezifische Testfälle oder Szenarien. Teilt Wissen und Erfahrungen mit dem Testen im Team, um Testpraktiken zu verbessern und Konsistenz sicherzustellen. - Iteration und Verbesserung: Testing ist ein fortlaufender Prozess. Überwacht und verbessert kontinuierlich die Testabdeckung und -effektivität im Laufe der Zeit. Lernt aus Fehlern und passt die Teststrategie entsprechend an.  

Codeanalyse

  - Statische Codeanalyse-Tools nutzen: Nutzt statische Codeanalyse-Tools wie SonarQube, ESLint, Pylint oder FindBugs, um automatisierte Analysen des Codes durchzuführen. Diese Tools können potenzielle Fehler, Verstöße gegen Coding-Standards, Sicherheitslücken und andere Probleme identifizieren. - Manuelle Codeüberprüfung: Nehmt euch Zeit, um den Code manuell zu durchsuchen und zu verstehen. Beginnt mit den Hauptkomponenten und kritischen Bereichen. Stellt sicher, dass ihr die Dokumentation lest, um ein besseres Verständnis für das beabsichtigte Verhalten der Anwendung zu erhalten. - Reverse Engineering: Wenn möglich, verwendet Reverse-Engineering-Tools, um Diagramme oder Modelle der Codearchitektur zu erstellen. Dies kann helfen, komplexe Abhängigkeiten und Interaktionen zwischen verschiedenen Modulen oder Komponenten zu visualisieren. - Code Metriken: Verwendet Metriken wie Codekomplexität, Testabdeckung, Kopplung und Kohäsion, um die Qualität und Wartbarkeit des Codes zu bewerten. Dies kann euch helfen, Bereiche mit hoher Komplexität oder niedriger Testabdeckung zu identifizieren, die einer näheren Prüfung bedürfen. - Anforderungsanalyse: Stellt sicher, dass ihr die Anforderungen und das beabsichtigte Verhalten der Anwendung versteht. Vergleicht den Code mit den Anforderungen, um sicherzustellen, dass alle Funktionen ordnungsgemäß implementiert sind. - Prototyping und Experimentieren: Erstellt Prototypen oder führt Experimente durch, um das Verhalten bestimmter Teile des Codes zu testen oder zu verstehen. Dies kann helfen, Annahmen zu validieren und potenzielle Probleme frühzeitig zu identifizieren. - Kommunikation im Team: Diskutiert den Code und die Ergebnisse eurer Analyse mit anderen Teammitgliedern. Der Austausch von Meinungen und Perspektiven kann helfen, ein umfassenderes Verständnis für den Code zu entwickeln und potenzielle Probleme zu erkennen. Durch die Nutzung dieser Methoden und eine systematische Herangehensweise könnt ihr eine gründliche Codeanalyse durchführen und die Grundlage für die Einführung von Tests und die Verbesserung der Codequalität legen.

Unittests

Stellt klar: Unit-Tests sind nicht länger eine optionale Aufgabe. Zeitraum Alle Code-Änderungen werden jetzt getestet, je nach Bedarf neu oder aktualisiert. Die ersten Tests werden WIRKLICH schwer sein, da es am Anfang so viele Hürden gibt und die Lernkurve steil ist. Plant also vielleicht einen oder sechs Monate ein, um alle mit Schulungen, Präsentationen, Coaching und Nachhilfe darauf vorzubereiten. Um so streng zu sein (der gesamte Code muss jetzt getestet werden), müsst ihr zunächst mit mehreren Ebenen und Teilen der Organisation zusammenarbeiten, um die Leute vorzubereiten und mit den Ressourcen und dem Wissen auszustatten, das sie für eine so große Veränderung brauchen. Es kann leicht mehrere Monate dauern, bis eine solche Veränderung in Gang kommt, und ein bis drei Jahre, bis sie in Schwung kommt, sodass die Unternehmensleitung für einen langen Zeitraum bereit sein und ihre Erwartungen festlegen muss. Das Ergebnis ist ein modernes Unternehmen, das sich im Wettbewerb behauptet und gewinnt. Die Alternative ist der Untergang des Unternehmens. Phase 1 - Beginnen Sie mit der Einführung der Tests Schritt 1) Schreiben Sie einen „Wahr ist wahr“-Test. Schritt 2) Schreiben Sie einen Test „Aufruf einer einfachen Methode im Anwendungscode funktioniert“. Schritt 3) Schreiben Sie einen Unit-Test für eine einfache Methode, die alle Abhängigkeiten abbildet und ausblendet. Phase 2 - Anwendung der Tests auf die tatsächliche Entwicklung Für alle Code-Änderungen in der Zukunft: Schritt 1) Schreiben Sie Tests, die zusammen mit dem Code übertragen werden. Schritt 2) Schreiben Sie fehlgeschlagene Tests, bevor Sie den Anwendungscode schreiben. Schritt 3) Schreiben Sie Tests für den Rückstand der fehlenden Tests Machen Sie bei all diesen Schritten neben den Vorteilen auch die Schwierigkeiten deutlich. Verwenden Sie einen CI-Server, auf dem Ihre Zweige und Tests laufen. Wie circleCI zum Beispiel. Legen Sie die Innereien offen, um sie zu verbessern. „Tests zu haben hilft uns nicht wirklich, wenn wir keine Möglichkeit haben, sie auszuführen. „Das ist nur eine von Dutzenden Ausreden von Leuten, die nicht davon überzeugt sind, dass Testen eine wirklich tolle Sache ist - für Entwickler! Außerdem, seien wir ehrlich, MUSS ein Entwickler seinen Code irgendwie ausführen, um sicherzustellen, dass der glückliche Pfad tatsächlich ohne Syntaxfehler funktioniert. Niemand, den ich je gesehen habe, schreibt Code „blind“. Das Testen findet bereits statt, es wurde nur noch nicht formalisiert und automatisiert, das ist wahrscheinlich der Fall. Ich selbst habe früher Code ohne automatisierte Tests geschrieben (man kann wohlgemerkt sagen, dass ich ihn oft getestet habe), und zwar Millionen von Zeilen. Ihn zu ändern war schrecklich! Tests sind der beste Freund eines Entwicklers. Ich meine, wie kann man Code mit Zuversicht umgestalten - das Geheimnis der Qualität - wenn man keine Tests hat, die einen schützen? Der Anreiz, etwas zu verbessern, aber zu riskieren, etwas anderes kaputt zu machen, führt meiner Erfahrung nach dazu, dass überall Mist hinterlassen wird. Ist erst einmal ein Fenster zerbrochen, ist das Haus schnell zertrümmert (broken window theory). Es gelingt oft nicht, Menschen mit Argumenten umzustimmen, daher ist es wichtig, mit gutem Beispiel voranzugehen und Mitarbeiter zu gewinnen.   Read the full article

[s4hana-experts]

S/4HANA Testmanagement inkl. SAP Solution Manager

Der SAP Solution Manager bietet Fiori-Apps zur Testplanung, -durchführung, -überwachung und -dokumentation sowie zur automatischen Durchführung von Regressionstests, Einbindung von weiteren Testsystemen, für das Testdatenmanagement, Analysen, Auswertungen etc. Focused Build ergänzt diesen Funktionsumfang dahingehend, dass aus den Anforderungen bzw. Arbeitspaketen Testpläne abgeleitet werden…

[technicaltester]

Hvilket testniveau er det rigtige for en regressionstest?

Jeg er blevet stillet dette spørgsmål et par gange, og her er hvad jeg mener om hvordan en regressionstest skal se ud.

En regressionstest handler om at sikre at vi ikke ser regressioner, så alt funktionel test kan mere eller mindre falde ind under denne kategori, men det som de fleste forbinder med en regressionstest, så er det en test der er fokuseret på at fejl vi har oplevet ikke kommer igen samt at sikre god testdækning af højrisiko områder. Højrisikoområder bør i deres natur allerede have en høj testdækning, men somme tider får de ekstra kærlighed i regressionstesten også.

Da regressiontesten som regel har meget til fælles med en standard systemtest, så har man også en tendens til at lægge den på det niveau, og det er nok heller ikke helt forkert. Vi har dog lært dels af shift-left bevægelsen i test samt af almindelig sund fornuft, at det er en god ide at fange regressioner så tidligt som muligt. Det betyder at komponent testen nok også er et ret godt sted at placere den.

Min anbefaling til placering af regresionstest er derfor følgende: Den skal både være på komponent niveau og på systemtest niveau. Her kommer en kort forklaring:

Komponent niveau regressionstesten fanger regressioner hurtigst muligt og, lidt afhængig af build opsætning, sikkert allerede inden udvikleren, der har introduceret en regression, har committet koden til et repositorie. Hvis ikke er det helt klart en forbedringsmulighed til build setup’et. Problemet med denne test er imidlertid at den ofte kan have rigtigt mange permutationer før at den fanger alle scenarier, og det er ikke altid at udviklere er opmærksom på dem. Derfor er det helt sikkert også en god ide at lige tjekke på niveauet ovenover.

En anden ting er at der som regel ikke er nogen testrapportering andet en en dæknings metrik, så der er ikke nogen andre en udvikleren og eventuelt den tester der har hjulpet udvikleren med at lave komponent testen, som ved at der bliver testet for regressioner som en del af komponent testen. Det betyder at projekt personer som ikke er udviklere eller testere, som regel ikke ved at regresionstesten eksistere hvis den kun findes på dette niveau.

Systemtest niveau regressionstesten er sådan set at betragte som en fuldkommen klassisk systemtest, dog hvor der er fokus på at alle de fejl der er fundet i systemet gennem dets levetid har en eller flere testcases der sikre at disse fejl ikke kommer igen.

Det god ved at have regressionstest på dette niveau er at der formentligt vil være en eller anden form for testrapport som vil afspejle at denne test er blevet foretaget. Det gør at projektets interessenter kan blive informeret om at regressiontesten er blevet udført som en del af testrapporten.

En anden god ting er også at systemtesten som regel laves på et integreret miljø hvor forudsætningerne er lidt anderledes end på udviklerens lokale miljø. Det gør at det giver mening at køre testen begge steder da man ikke vil finde regressioner relateret til integrationer på udviklerens lokale miljø. Dog koster det også mere at afvikle test på dette niveau end det gør på komponent niveau, men man skal her også huske at man kan opnå store besparelser på afviklingsomkostningerne hvis man automatisere testen, og en regressionstest er en prima kandidat til at blive automatiseret da den i natur er tjekkende mere end den er udforskende, men mere om det i en anden artikel.

Konklusion er at regressionstest bør findes både på komponenttest niveau og på systemtest niveau. Hvert niveau har sine fordele og selv om noget vil være duplikeret, så vil der også være mange steder hvor testen komplimetere hinanden.

[digital-dynasty]

heise | Visuelle Regressionstests mit BackstopJS zur pixelgenauen Prüfung von Webseiten

BackstopJS testet automatisiert, ob sich das Aussehen einer Webseite verändert hat. Webentwickler können so unbeabsichtigte Auswirkungen ihrer Arbeit prüfen. Read more www.heise.de/ratgeber/…... www.digital-dynasty.net/de/teamblogs/…

http://www.digital-dynasty.net/de/teamblogs/heise-visuelle-regressionstests-mit-backstopjs-zur-pixelgenauen-prufung-von-webseiten

[test-springer]

sdfgfdsgfdsg

[frentmeister]

Moderne Regressionstests in der Cybersicherheit: Ein Paradigmenwechsel - Teil 1 neuer Ansatz, neuer Workflow

Seit mehreren Jahren nutze ich den Owasp Zap - Schwachstellentester für meine Projekte und dies immer sehr erfolgreich. Gerade hinsichtlich der Flexibilität, auch hinsichtlich einer Testautomatisierung, der schier großen Dichte von Erweiterungen, und der Open Source Lizenzierung, bietet Owasp Zap eine solide Basis, die man immer wieder nutzen kann.

Die Notwendigkeit eines neuen Ansatzes

In der sich schnell entwickelnden Welt der Cybersicherheit ist es für Produktsicherheitsteams entscheidend, Schwachstellen nicht nur zu erkennen und zu beheben, sondern auch sicherzustellen, dass diese Probleme nicht wieder auftauchen. Ein wesentlicher Bestandteil dieses Prozesses ist das Regressionstesten. Traditionelle Methoden des manuellen Regressionstestens stoßen jedoch an ihre Grenzen. In diesem Blogbeitrag möchte ich eine innovative Methode vorstellen, die den Prozess der Regressionstests in der Cybersicherheit revolutioniert und an die Anforderungen der heutigen Zeit anpasst – basierend auf OWASP ZAP. https://youtu.be/5ZGo_eR46To  

Das Problem mit manuellen Tests

Viele von uns kennen die Situation: Eine Schwachstelle wird gemeldet, sei es durch einen aufmerksamen Nutzer, ein Bug-Bounty-Programm oder einen Penetrationstest. Der Entwickler behebt das Problem schnell, und alles scheint in Ordnung. Doch nach einiger Zeit taucht dieselbe Schwachstelle wieder auf. Die Ursache? Eine unbedachte Änderung hat den ursprünglichen Patch rückgängig gemacht. Dies ist ein klassischer Fall von Regression, und genau hier kommen Regressionstests ins Spiel. Traditionell wurden diese Tests manuell durchgeführt. Dies bedeutete, dass Sicherheitstechniker jede behobene Schwachstelle erneut überprüfen mussten. Dieser Prozess war nicht nur zeitaufwendig, sondern auch fehleranfällig und ineffizient. Zudem fehlte es an Skalierbarkeit, um mit der zunehmenden Anzahl von Schwachstellen und deren Behebungen Schritt zu halten. In meinen Projekten der letzten 26 Jahren, führte dies zu einer endlosen Flut von Jira-Tickets, die alle erneut getestet werden mussten. Und das ist eine Endlose fummelei, und nur mit dem Einsatz von mehreren Leuten überhaupt zu bewältigen.

Eine neue Herangehensweise mit OWASP ZAP

Um diese Herausforderungen zu meistern, haben ich einen neuen Ansatz entwickelt, der Automatisierung und Skalierbarkeit miteinander verbindet, indem ich OWASP ZAP als Grundlage nutzen. ZAP (Zed Attack Proxy) ist ein Open-Source-Webanwendungsscanner, der sich ideal für die Automatisierung von Sicherheitstests eignet. Der neue Prozess im Detail

- Identifikation und Triage: Sobald eine Schwachstelle entdeckt wird, prüft ein Security-Tester, ob sie sich für einen automatisierten Regressionstest eignet. Erfüllt sie die Kriterien, wird sie mit einem speziellen Jira-Label versehen (natürlich geht auch jedes andere System, was über eine Tag-Funktion verfügt). - Erstbewertung der Schwachstelle: Die Schwachstelle wird entweder durch interne Tests, Bug-Bounty-Programme, Penetrationstests oder Benutzerberichte entdeckt. - Dies schließt ausdrücklich auch den Einsatz durch eine CI/CD Lösung mit ein, die auf Owasp Zap beruht. Aktive und passive Scanner, die z. B. in wöchentlichen Testruns entsprechend eure Projekte auf Schwachstellen vertestet. - Dokumentation und Risikobewertung: Alle relevanten Details der Schwachstelle werden dokumentiert, einschließlich der betroffenen Systeme, der Art der Schwachstelle und möglicher Auswirkungen. - Eignungsprüfung für die Automatisierung:  - Reproduzierbarkeit: Der Security-Tester überprüft, ob die Schwachstelle einfach und zuverlässig reproduzierbar ist. Dies bedeutet, dass die Schwachstelle mit einer einfachen Anfrage und einer spezifischen Antwort auftritt. - Automatisierungspotential: Es wird beurteilt, ob die Schwachstelle durch ein automatisiertes Skript reproduziert und getestet werden kann. Beispiele hierfür sind Schwachstellen wie offengelegte Anmeldeinformationen im Antwortkörper oder API-Aufrufe ohne Sitzungsvalidierung. - Kategorisierung und Priorisierung: - Kritikalität: Die Schwachstelle wird nach ihrer Kritikalität eingestuft. Kritische Schwachstellen, die sofortige Aufmerksamkeit erfordern, werden höher priorisiert. Eine Bewertung für Risiko behaftete Schwachstellen findet ihr bei OWASP, oder hier. - Wiederholungswahrscheinlichkeit: Schwachstellen, die eine hohe Wahrscheinlichkeit haben, wieder aufzutreten, werden ebenfalls höher priorisiert. - Spezielle Kennzeichnung im Jira (oder vergleichbares Testmanagement-System): - Label-Zuweisung: Erfüllt die Schwachstelle die Kriterien für die Automatisierung, wird sie im Jira-System mit einem speziellen Label versehen. Dieses Label identifiziert die Schwachstelle als geeignet für automatisierte Regressionstests. - Erstellung eines benutzerdefinierten ZAP-Skripts: Für jede geeignete Schwachstelle erstellen wir ein individuelles ZAP-Skript, das speziell darauf ausgelegt ist, die Regression dieser Schwachstelle zu überprüfen. - Integration ins Repository: Das neue Skript wird in unser Code-Repository für automatisierte Regressionstests eingefügt. Ein automatisierter Job plant regelmäßige Ausführungen, zieht Updates und führt die ZAP-Skripte aus. - Automatisierte Überprüfung und Wiedereröffnung von Tickets: Schlägt ein Regressionstest fehl, wird das entsprechende Jira-Ticket automatisch wieder geöffnet – dies kann man über Xray lösen. Dazu wird es aber einen gesonderten Beitrag geben. Diese Struktur ermöglicht eine nahtlose Integration in ZAP und stellt sicher, dass jedes benutzerdefinierte Skript mit dem Jira-Ticket der Schwachstelle verknüpft ist. Beispielprozess für ein OWASP ZAP-basiertes Regressionstest-Skript in Python Hier ist ein Beispiel für ein Python-Skript, das OWASP ZAP verwendet, um eine Schwachstelle auf Regression zu testen: import requests from zapv2 import ZAPv2 # ZAP API Konfiguration zap = ZAPv2(apikey='your_zap_api_key', proxies={'http': 'http://localhost:8080', 'https': 'http://localhost:8080'}) # Ziel-URL target_url = 'http://example.com/vulnerable_endpoint' # Schwachstelle: Überprüfung auf offengelegte Anmeldeinformationen im Antwortkörper def check_vulnerability(response): if 'sensitive_information' in response.text: print("Vulnerability still exists!") reopen_jira_ticket("JIRA-1234") # Funktion zum Wiederöffnen eines Jira-Tickets def reopen_jira_ticket(ticket_id): jira_url = f"http://your_jira_instance/rest/api/2/issue/{ticket_id}/transitions" headers = { 'Content-Type': 'application/json', 'Authorization': 'Basic your_jira_auth_token' } payload = { 'transition': { 'id': 'your_reopen_transition_id' } } response = requests.post(jira_url, headers=headers, json=payload) if response.status_code == 204: print(f"Jira ticket {ticket_id} reopened successfully.") else: print(f"Failed to reopen Jira ticket {ticket_id}: {response.text}") # Testen der Schwachstelle mit OWASP ZAP def run_regression_test(): # Starten des ZAP-Scans zap.urlopen(target_url) print(f"Scanning target: {target_url}") # Warten auf Scan-Ergebnisse while int(zap.spider.status) < 100: print(f"Spider progress: {zap.spider.status}%") # Abrufen der HTTP-Antwort response = requests.get(target_url, proxies={'http': 'http://localhost:8080'}) # Überprüfen auf Schwachstelle check_vulnerability(response) # Hauptfunktion if __name__ == "__main__": run_regression_test()

Die Vorteile der Automatisierung

Der Wechsel zu einem automatisierten Regressionstestsystem auf Basis von OWASP ZAP bringt zahlreiche Vorteile mit sich: - Erhöhte Effizienz: Der Automatisierungsprozess reduziert den Zeitaufwand für manuelle Tests erheblich und minimiert menschliche Fehler. - Kontinuierliche Tests: Anstatt punktuelle Tests durchzuführen, ermöglicht die Automatisierung kontinuierliche Überprüfungen. - Zeitersparnis: Sicherheitstechniker können sich auf komplexere und wertvollere Aufgaben konzentrieren, da die Routinearbeiten durch Automatisierung erledigt werden.

Fazit: Ein Schritt in die Zukunft

Regressionstests sollten ein integraler Bestandteil des Lebenszyklus von Schwachstellen in jedem Unternehmen sein. Durch die Implementierung eines automatisierten Ansatzes mit OWASP ZAP haben wir die Effizienz und Genauigkeit in unserem Team erheblich verbessert und wertvolle Zeit gespart. Ich ermutige andere Unternehmen und Sicherheitsexperten, ähnliche Methoden zu übernehmen, um ihre Sicherheitsprozesse weiter zu optimieren und einen Schritt in Richtung einer sichereren digitalen Zukunft zu machen. Read the full article

[frentmeister]

Was ist der Unterschied zwischen "automatisierten Tests" und "automatisierten Regressionstests"?

Ein Regressionstest ist etwas, das eure Testergebnisse mit bestimmten Anforderungen abgleicht. Gute Beispiele hierfür sind Unit-Tests und funktionale Tests. Diese geben Aufschluss darüber, ob sich die Funktionalität eurer Anwendung verschlechtert hat oder nicht (daher Regression). Es gibt noch andere Arten von automatisierten Tests: Fuzzy-Inputs und automatisierte Erkundungstests kommen mir in den Sinn. Diese haben nicht immer vorhersehbare, wiederholbare Ergebnisse, wie eure Regressionstests. Für einen Tester wäre es ziemlich mühsam und zeitaufwendig, sie manuell durchzuführen, daher ist es nicht verkehrt, sie zu automatisieren und das Ergebnis zu betrachten. Die Grenze des Testens liegt darin, wie schnell man denken und dann automatisieren kann, und nicht darin, wie schnell man klicken kann. Einige Beispiele für automatisierte Nicht-Regressionstests sind: - Jeder automatisierte Test, der weggeworfen und nicht für Regressionstests verwendet wird, ist kein Regressionstest, einschließlich Unit-Tests, die später nicht für Regressionstests verwendet werden. Technisch gesehen ist jeder automatisierte Test, der für eine neue Funktionalität geschrieben wurde, kein Regressionstest, solange er nicht mindestens einmal die korrekte Funktionalität überprüft hat. Erst dann kann er nachweisen, dass sich die Funktionalität nicht geändert hat. - Zuverlässigkeitstests, bei denen ihr das zu testende System so lange wie möglich in einer produktionsnahen Umgebung laufen lasst, um zu sehen, wie lange es ohne Fehler oder Abstürze läuft Stresstests, bei denen es darum geht, zu sehen, wie sich das zu testende System bei starker Beanspruchung oder eingeschränkten Ressourcen verhält; Ihr könnt z. B. CPUs entfernen oder die Bandbreite verringern oder eine große Anzahl von Benutzern simulieren. - Bei einigen Leistungstests gibt es möglicherweise keine spezifischen Prüfungen, die zu verifizieren sind, und es wird eine Person benötigt, um die Ergebnisse zu interpretieren, obwohl einige Leistungstests als Regressionstests durchgeführt werden können (z. B. "Führe 100 Iterationen dieser Funktion aus. Wenn es weniger als 5 Sekunden gedauert hat, ist der Test bestanden, ansonsten ist er fehlgeschlagen"). Glowcoder erwähnte Fuzz-Tests, bei denen die Eingaben in eine Funktion nach dem Zufallsprinzip erfolgen, aber das Thema verdient es, etwas erweitert zu werden. Beim Fuzz-Testing sucht der Tester nach unerwartetem Verhalten, das Probleme verursachen könnte, wie Sicherheitslücken, Abstürze und Hänger.   Beispiele für Regressionstests sind: - Wiederholung früherer Tests: Tests, die zuvor durchgeführt wurden, um sicherzustellen, dass sie auch nach einer Änderung weiterhin erfolgreich durchgeführt werden können. - Funktionalitätstests: Tests, die sicherstellen, dass die bestehenden Funktionen der Software nach einer Änderung weiterhin korrekt funktionieren. Dies kann z.B. die Überprüfung von Benutzereingaben, die Ausgabe von Daten oder die Interaktion mit anderen Systemen umfassen. - Edge-Case-Tests: Tests, die sicherstellen, dass die Software auch in Randfällen oder ungewöhnlichen Szenarien korrekt funktioniert. Dies könnte z.B. die Behandlung von ungültigen Eingaben oder unerwarteten Zuständen sein. - Integrationstests: Tests, die sicherstellen, dass die Software nach einer Änderung weiterhin korrekt mit anderen Komponenten oder Systemen interagiert. - Leistungstests als Regressionstests: Bestimmte Leistungstests können auch als Regressionstests dienen, wenn sie sicherstellen, dass Änderungen keine negativen Auswirkungen auf die Leistung der Software haben. Aber wie definiert man das nun genauer? "Automatisierte Tests" bezieht sich im Allgemeinen auf Tests, die automatisiert durchgeführt werden, um die Funktionalität einer Software zu überprüfen. Diese Tests können verschiedene Arten von Tests umfassen, wie z.B. Unit-Tests, Integrationstests oder Systemtests. Das Hauptziel automatisierter Tests ist es, Fehler frühzeitig im Entwicklungsprozess zu finden und die Qualität der Software sicherzustellen. "Automatisierte Regressionstests" sind eine spezifische Art von automatisierten Tests, die darauf abzielen, sicherzustellen, dass neue Änderungen oder Updates an einer Software keine bereits behobenen Fehler reintroduzieren (Regressionen). Sie überprüfen, ob die bestehende Funktionalität nach einer Änderung immer noch wie erwartet funktioniert. Regressionstests werden typischerweise nach jeder Änderung am Code oder an der Konfiguration durchgeführt, um sicherzustellen, dass keine unerwünschten Nebeneffekte auftreten.     Read the full article

[frentmeister]

Kosten senken durch Abhärtung von automatisierten Testfällen ?

Bekanntlich ein sehr großes Problem, die Wartung von Testfällen gerade in der Testautomatisierung kostet Zeit, obwohl meistens die Änderung relativ klein ist. Vielfach liegt es daran das in den Testfällen harte Codierungen von Werten vorliegen, das verursacht dann zeitnah einen Ausfall solch eines Testfalls. Und in den meisten Fällen müssen dann immer diese Testfälle bearbeitet werden, obwohl sich eventuell nur ein Pixel geändert hat. Das ist aber ein vollkommen falscher Ansatz, Ziel muss immer die Abhärtung eines Testfalls sein, nicht die elend lange Bearbeitung von Testfällen, was nachhaltig mehr Kosten verursacht als euch und euren Vorgesetzten, bzw. eurem Team lieb ist. https://www.dev-crowd.com/2022/08/09/wie-mache-ich-automatisierte-testfaelle-effizienter/ Schon 2022 hatte (siehe oberhalb) ich mir dazu Gedanken gemacht, wie man automatisierte Testfälle effektiver machen könnte. Betrachtet man das zusätzlich mit der Möglichkeit eines Einsatzes einer KI (wäre effektiv darüber nachzudenken) so ergibt sich ein neuer Ansatz, über den ich hier mal berichten möchte. Warum spare ich Kosten? - Weniger False-Positive Ergebnisse: Stabilisierte Tests führen zu weniger Fehlalarmen. Falsch-positive Ergebnisse können Teams dazu veranlassen, unnötig Zeit in die Untersuchung von Problemen zu investieren, die tatsächlich nicht existieren. - Zeitersparnis: Wenn Testfälle stabil sind und weniger oft fehlschlagen, verbringen Entwickler und QA-Teams weniger Zeit damit, die Ursachen von Testfehlern zu untersuchen. - Höhere Zuverlässigkeit: Stabile Tests erhöhen das Vertrauen in die Testergebnisse. Dies kann dazu führen, dass Software schneller freigegeben wird, da weniger Zeit für manuelle Überprüfungen aufgewendet wird. - Weniger Wartungsaufwand: Stabile automatisierte Testfälle benötigen weniger häufige Überarbeitungen. Das reduziert die Gesamtkosten für die Wartung des Testframeworks. - Bessere Nutzung von Ressourcen: Durch die Reduzierung von Fehlalarmen und den damit verbundenen manuellen Überprüfungen können Ressourcen (z. B. Testumgebungen, Hardware) effizienter genutzt werden. - Frühe Fehlererkennung: Gut abgegrenzte automatisierte Tests können Fehler früh im Entwicklungszyklus aufdecken, was oft kostengünstiger ist als das Beheben von Fehlern in späteren Phasen oder nach der Produktfreigabe. - Konsistente Testausführung: Automatisierte Tests werden jedes Mal in der gleichen Weise ausgeführt, was eine größere Konsistenz im Vergleich zu manuellen Tests gewährleistet. - Skalierbarkeit:  Ihr könnt mehr Tests in kürzerer Zeit ausführen, insbesondere wenn ihr  in der Lage seid, Tests parallel oder in verteilten Umgebungen auszuführen. - Dokumentation: Automatisierte Testfälle können als eine Art von Dokumentation für das Verhalten des Systems dienen. Sie zeigen klar, was von der Software erwartet wird. - Rückmeldung in Echtzeit: Bei der Integration von Testautomatisierung in eine CI/CD-Pipeline können Entwickler sofortiges Feedback über den Status ihres Codes erhalten. - Höhere Testabdeckung: Automatisierte Tests können eine höhere Codeabdeckung erreichen, besonders wenn sie regelmäßig und umfassend eingesetzt werden. - Häufigere Releases: Mit stabilen Tests können Organisationen sicherer und häufiger Software-Releases durchführen. - Verbesserung der Teammoral: Wenn QA-Teams weniger Zeit mit wiederholtem manuellen Testen und der Untersuchung von Fehlalarmen verbringen, könnt ihr euch auf komplexere und wertvollere Aufgaben konzentrieren. - Reduzierung menschlicher Fehler: Während des manuellen Testens können menschliche Fehler auftreten, etwa durch Übersehen oder inkonsistente Testausführung. Automatisierte Tests reduzieren dieses Risiko. - Erhöhte Marktreife: Die Fähigkeit, Software schneller und mit höherer Qualität zu testen und zu releasen, kann den Markteintritt beschleunigen. - Regressionsüberprüfung: Automatisierte Tests erleichtern die Durchführung von Regressionstests, um sicherzustellen, dass neue Änderungen keine vorhandenen Funktionen beeinträchtigen.   Wie setze ich das um? - Gute Testdesign-Praktiken: Dies beinhaltet die Verwendung von Page-Object-Modellen, geeignete Testdatenverwaltung und das Isolieren von Tests voneinander. - Wartezeiten und Synchronisierung: Bei UI-Tests sollten dynamische Wartezeiten verwendet werden, um sicherzustellen, dass Elemente geladen sind, bevor Aktionen ausgeführt werden. - Umgang mit flüchtigen Tests: Tests, die intermittierend fehlschlagen, sollten identifiziert und behoben oder vorübergehend deaktiviert werden. - Regelmäßige Überprüfung und Aktualisierung: Tests sollten regelmäßig überprüft werden, um sicherzustellen, dass sie noch relevant sind und korrekt funktionieren. - Granularität der Tests: Schreibt kleine, zielgerichtete Tests, die nur eine bestimmte Funktionalität oder ein bestimmtes Feature testen. Dadurch wird die Fehlersuche erleichtert, da fehlschlagende Tests schnell auf eine spezifische Ursache hindeuten. - Idempotenz: Stellt sicher, dass Tests idempotent sind, d.h., sie können mehrmals unter denselben Bedingungen ausgeführt werden und liefern jedes Mal dasselbe Ergebnis. - Testumgebungen: Verwendet dedizierte Testumgebungen, die dem Produktionsumfeld so ähnlich wie möglich sind, um sicherzustellen, dass Tests in einer konsistenten und kontrollierten Umgebung laufen. - Logging und Berichterstattung: Ein gutes Logging und Berichtssystem kann dabei helfen, Probleme schneller zu diagnostizieren. Insbesondere bei Fehlschlägen sollte detaillierte Information verfügbar sein. - Code-Review für Tests: Genau wie Produktionscode sollten auch Testcodes regelmäßig überprüft werden. Dies stellt sicher, dass die Tests den Best Practices folgen und effektiv sind. - Priorisierung von Tests: Nicht alle Tests sind gleich wichtig. Bestimmt, welche Tests kritisch sind und welche weniger kritisch sind. Dies hilft bei der Entscheidungsfindung, wenn ihr beispielsweise eine schnelle Regressionstest-Suite ausführen müsst. - Cross-Browser- und Cross-Plattform-Tests: Wenn ihr Webanwendungen testet, stellt sicher, dass Ihre Tests in verschiedenen Browsern und Plattformen funktionieren. Tools wie Selenium Grid oder Dienste wie BrowserStack und Sauce Labs können dabei helfen. - Datengetriebene Tests: Anstatt für jede Datenkombination einen separaten Test zu schreiben, könnt ihr einen Test schreiben, der durch eine Reihe von Datenpunkten geführt wird. Frameworks wie pytest bieten Unterstützung für datengetriebene Tests. - Fehlerbehandlung: Berücksichtigt wie euer Testframework mit unerwarteten Fehlern, wie z.B. Timeouts, Abstürzen oder externen Abhängigkeiten, umgeht. Implementiert geeignete Fehlerbehandlungen, um solche Situationen zu adressieren. - Integration mit CI/CD: Integriert eure Tests in Ihre Continuous Integration/Continuous Deployment-Pipeline, um sicherzustellen, dass Tests automatisch bei jedem Code-Check-in oder -Release ausgeführt werden. - Monitoring und Alarmierung: Stellt sicher, dass ihr benachrichtigt werdet, wenn Tests fehlschlagen, insbesondere in CI/CD-Pipelines oder bei nächtlichen Testläufen. - Testabdeckung: VerwendetTools zur Messung der Codeabdeckung, um sicherzustellen, dass Ihr Code angemessen durch Tests abgedeckt ist. - Isolation von externen Diensten: Wenn euer Code externe Dienste oder APIs verwendet, sollten ihr diese Dienste während des Tests durch Mocks oder Stubs ersetzen, um sicherzustellen, dass eure Tests nicht von externen Faktoren beeinflusst werden. - Modularisierung von Testcodes: Vermeidet redundante Codes, indem ihr gemeinsame Vorgehensweisen und Funktionen in wiederverwendbare Module oder Hilfsfunktionen auslagert. - State Management: Stellt sicher, dass ihr den Zustand vor und nach Tests zurücksetzt, um Seiteneffekte zu vermeiden und die Unabhängigkeit der Tests zu gewährleisten. - Testen von Rand- und Ausnahmefällen: Neben den Standard-Testfällen sollten ihr auch Rand- und Ausnahmefälle in Betracht ziehen, um die Robustheit eures Codes zu überprüfen. - Performance- und Lasttests: Neben funktionalen Tests solltet ihr auch die Leistung und Skalierbarkeit eurer Anwendung unter verschiedenen Lastbedingungen testen. - Testen von Sicherheitsaspekten: Führt Sicherheitstests durch, um potenzielle Schwachstellen oder Sicherheitslücken in eurer Anwendung zu identifizieren. - Visual Testing: Für UI-basierte Anwendungen kann das visuelle Testen sicherstellen, dass die Benutzeroberfläche wie erwartet erscheint, insbesondere nach Änderungen oder Updates. - Verwaltung von Testkonfigurationen: Stellt sicher, dass ihr leicht zwischen verschiedenen Testkonfigurationen (z.B. verschiedene Umgebungen, Datenbanken oder Endpunkte) wechseln könnt. - Feedback-Schleifen: Nutzt das Feedback aus den Tests, um den Entwicklungsprozess kontinuierlich zu verbessern. - Schulung und Wissenstransfer: Stellt sicher, dass das Team regelmäßig geschult wird und Best Practices in Bezug auf Testautomatisierung und zugehörige Werkzeuge kennt. - Testtreiber und Teststubs: In einem TDD (Test Driven Development) Ansatz können Testtreiber (um fehlende Teile zu simulieren) und Teststubs (um komplexe Teile zu vereinfachen) verwendet werden, um den Testprozess zu erleichtern. - Code- und Testmetriken: Verwendet Metriken, um den Zustand euer Tests und eures Codes im Laufe der Zeit zu überwachen.   Wie härte ich Selenium und Python basierte Testfälle ab?   Wartet auf Elemente: - Verwendet explizite Wartezeiten, um auf das Erscheinen von Elementen zu warten, anstatt feste Zeitverzögerungen zu verwenden. - Nutzt Wartebedingungen wie WebDriverWait in Kombination mit erwarteten Bedingungen (ExpectedConditions), um auf das gewünschte Element zu warten, bevor ihr damit interagieren. from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # Beispiel für das Warten auf ein Element mit WebDriverWait element = WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, "element_id")) )   Fehlerbehandlung: - Implementiert robuste Fehlerbehandlungen, um auf unerwartete Ausnahmen vorbereitet zu sein. - Verwendet try-except-Blöcke, um Ausnahmen abzufangen und entsprechend zu reagieren. try: # Führen Sie hier Ihre Aktionen aus except NoSuchElementException: # Handle den Fall, wenn das Element nicht gefunden wird except TimeoutException: # Handle den Fall, wenn ein Timeout auftritt   Loggt eure Informationen: - Fügt Protokollausgaben hinzu, um den Testverlauf und Fehlermeldungen besser nachverfolgen zu können. - Verwendet Python-Logging oder andere geeignete Protokollierungsmechanismen. import logging # Konfigurieren Sie das Logging logging.basicConfig(level=logging.INFO) logger = logging.getLogger(__name__) # Protokollieren von Informationen logger.info("Aktion erfolgreich ausgeführt") logger.error("Ein Fehler ist aufgetreten")   Verwendet den Headless-Modus: - Führt Tests im Headless-Modus aus, um die Leistung zu verbessern und die Stabilität zu erhöhen, insbesondere auf Servern ohne grafische Benutzeroberfläche. from selenium.webdriver.chrome.options import Options options = Options() options.headless = True driver = webdriver.Chrome(options=options)   Testdatenmanagement: - Trennt die Testdaten von Testfällen, um die Wartbarkeit zu verbessern. - Verwendet externe Dateien oder Datenbanken, um Testdaten zu speichern und auf sie zuzugreifen Parallelisierung: - Nutzt Tools wie Selenium Grid oder Cloud-basierte Testplattformen, um Tests parallel auf verschiedenen Browsern und Plattformen auszuführen, was die Ausführung beschleunigen und die Ausfallsicherheit erhöhen kann. Überwachung und Berichterstattung: - Überwacht eure Testausführungen und erstellt detaillierte Berichte über den Status und die Ergebnisse Ieurer Tests. - Verwendet Test-Frameworks und Berichterstattungswerkzeuge wie PyTest und Allure Report. Read the full article

[frentmeister]

Sind Blackbox-Automatisierungstests in variablen Anwendungskonfigurationen sinnvoll?

Die Frage, ob Black-Box-Automatisierungstests in variablen Anwendungskonfigurationen sinnvoll sind, ist komplex, und die Antwort hängt von einer Reihe von Faktoren ab. Zunächst ist es wichtig, den Unterschied zwischen Black-Box- und White-Box-Tests zu verstehen. Black-Box-Tests sind eine Testmethode, bei der der Tester keine Kenntnisse über die interne Funktionsweise der getesteten Anwendung hat. Der Tester konzentriert sich ausschließlich auf die Eingaben und Ausgaben der Anwendung. Beim White-Box-Testing hingegen wird das Innenleben der Anwendung getestet, z. B. der Code und die Datenbank. https://www.youtube.com/watch?v=nQQwBsK7YII Bei einem variablen Anwendungsaufbau können Black-Box-Tests ein nützlicher Ansatz sein. Da jede Anwendung über einen anderen Technologie-Stack verfügt, ist es für QAs möglicherweise nicht machbar oder effizient, mehrere Technologien zu erlernen, um anwendungsnahe Unit-/Integrationstests zu schreiben. In diesem Fall kann die Verwendung von Tools wie Postman für API-Tests und UI-Frameworks wie Playwright oder Cypress für UI-Tests eine gute Option sein. Diese Tools sind eher für externe Tests konzipiert und können mit einer Vielzahl von Technologie-Stacks arbeiten. https://www.youtube.com/watch?v=4BRHQ-yXFZ8 Es ist jedoch wichtig zu beachten, dass Blackbox-Tests ihre Grenzen haben. Da der Tester keine Kenntnisse über die interne Funktionsweise der Anwendung hat, kann es schwieriger sein, bestimmte Probleme oder Fehler zu erkennen. An dieser Stelle können White-Box-Tests nützlich sein. Durch das Testen der internen Funktionsweise der Anwendung können QAs Probleme auf einer detaillierteren Ebene identifizieren. Letztendlich hängt der beste Ansatz von den spezifischen Bedürfnissen und Anforderungen Ihres Unternehmens und Ihrer Anwendungen ab. Je nach Situation kann es sinnvoll sein, eine Kombination aus Black-Box- und White-Box-Tests zu verwenden. Das Wichtigste ist, dass ihr einen Testansatz wählt, der effektiv und effizient ist und der es Ihnen ermöglicht, Probleme so schnell und effektiv wie möglich zu erkennen und zu beheben. Black-Box-Computerisierungstests können in Abhängigkeit von der jeweiligen Einstellung und den Zielen des Testsystems bei der Gestaltung von Anwendungen hilfreich sein. Black-Box-Tests beziehen sich auf eine Strategie, bei der die inneren Funktionen der zu testenden Anwendung dem Analysator nicht bekannt sind. Alles in allem konzentriert sich der Analysator auf die Datenquellen und Ergebnisse des Frameworks, um dessen Verhalten zu bestätigen. Bei faktoriellen Anwendungsarrangements, bei denen sich die Designs, Bedingungen oder Informationsdatenquellen ändern können, können Black-Box-Tests dabei helfen, zu garantieren, dass die Anwendung unter verschiedenen Umständen formgetreu arbeitet. Im Folgenden werden einige Überlegungen angestellt: Funktionales Testen: Black-Box-Tests können bei der Überprüfung der praktischen Voraussetzungen der Anwendung unter verschiedenen Bedingungen sehr hilfreich sein. Durch die Angabe von Datenquellen und die Betrachtung der Ergebnisse können die Analysatoren bestätigen, dass die Anwendung unabhängig von der grundlegenden Anordnung korrekt funktioniert. https://www.youtube.com/watch?v=d4gZ89r1_YU Regressionstests: Wenn Änderungen an der Anwendung oder ihren aktuellen Gegebenheiten vorgenommen werden, sind Rückfalltests unerlässlich, um zu gewährleisten, dass die aktuelle Nützlichkeit nicht beeinträchtigt wird. Black-Box-Computerisierungstests können bei der schnellen Durchführung einer Reihe von Tests helfen, die bestätigen, dass die Anwendung tatsächlich formgetreu funktioniert. https://www.youtube.com/watch?v=AWX6WvYktwk&t=2s Kompatibilitätstests: Variable Anwendungsarrangements können verschiedene Arbeitsrahmen, Programme oder Gadgets umfassen. Black-Box-Tests können dabei helfen, die Ähnlichkeit der Anwendung mit diesen unterschiedlichen Bedingungen zu untersuchen, indem sie das Verhalten der Anwendung in zahlreichen Designs überprüfen. https://www.youtube.com/watch?v=ST4qubEcqyI&t=1s Testen der Benutzerfreundlichkeit: Blackbox-Tests können bei der Bewertung der Kundenerfahrung mit der Anwendung in verschiedenen Arrangements hilfreich sein. Analysatoren können sich auf Aspekte wie Bequemlichkeit, Reaktionsfähigkeit und Offenheit konzentrieren, ohne Punkt für Punkt Informationen über die innere Ausführung zu benötigen. https://www.youtube.com/watch?v=q8IPHOlUbV0 Dennoch ist es wichtig zu beachten, dass Blackbox-Tests Einschränkungen haben. Sie sind möglicherweise nicht geeignet, um Defekte auf niedriger Ebene oder Ausführungsfehler aufzudecken, die Informationen über die inneren Abläufe erfordern. In solchen Fällen kann eine Mischung aus Black-Box- und White-Box-Tests (bei denen der innere Aufbau bekannt ist) besser geeignet sein. Letztendlich hängt die Entscheidung über den Testansatz von den jeweiligen Zielen, Anforderungen und verfügbaren Ressourcen ab. Häufig ist es sinnvoll, ein ausgewogenes Testsystem zu haben, das eine Mischung aus verschiedenen Methoden enthält, um eine vollständige Einbeziehung zu gewährleisten. Read the full article

[frentmeister]

Heuristiken zur Erkennung von "einmaligen" Tests?

Bei der Entscheidung, ob ich einer Regressionssuite etwas hinzufüge oder nicht, würde ich eine Reihe von Aspekten berücksichtigen. Vieles von dem, was ich in Betracht ziehen würde, wäre allerdings sehr produktspezifisch; zu verstehen, wie die Kunden das Produkt verwenden, wie das Upgrade-Verhalten aussieht und so weiter, wäre hier notwendig. - Wie hoch ist das Risiko, dass der Fehler, den der Test aufdecken soll, übersehen wird? Je nachdem, auf welcher Ebene der Test stattfindet (Einheitstest, Integrationstest, Validierungstest usw.), kann dies schwer abzuschätzen sein, aber je näher ihr an dem seid, was der Endbenutzer sehen wird, desto einfacher ist es wahrscheinlich, das Risiko einzuschätzen. - Wo in der Programmhierarchie befindet sich die Codeänderung, die getestet werden soll? Bei miserablem Spaghetti-Code ist das vielleicht schwer zu erkennen, aber je mehr Dinge von einer Funktion abhängen, desto weniger Dinge müsst ihr (wahrscheinlich) im Zusammenhang mit dieser Funktion testen, da ihr Ausfall eine Reihe anderer Komponenten des Betriebssystems zerstören könnte. - Wie viele Dinge müssen schiefgehen, damit der Fehler aufgedeckt wird? Hier würde ich dazu tendieren, Dinge, bei denen mehr Dinge schiefgehen können, in der Regressionssuite zu belassen, als Dinge, die sich leichter aufdecken lassen, weil es wahrscheinlicher ist, dass man die einfachen Fehler in unverbundenen Tests findet, als die komplizierteren Fehler. (Dies setzt voraus, dass ihr Tester habt, denen Fehler auffallen, die nicht in der Dokumentation des Testszenarios enthalten sind). - Wie lange ist der fragliche Fehler schon im Code, und wodurch wurde er aufgedeckt? Dies ist schwer zu quantifizieren, ohne mehr darüber zu wissen, was getestet wird, aber wenn ihr etwas habt, das speziell durch einen Sonderfall aufgedeckt wurde, würde ich es nicht unbedingt zu einem Regressionssuit hinzufügen, aber ich würde es zu meiner Liste der "dummen Dinge, die Endbenutzer tun, die mir nie in den Sinn gekommen wären" hinzufügen, die ich in Zukunft beim Schreiben von Tests berücksichtigen sollte. - Wie subtil wäre ein Problem in einem bestimmten Bereich? Je subtiler das Problem ist, desto mehr Tests solltet ihr darum herum durchführen. - Wie oft wird eine Funktion in der Praxis vorkommen? In dem von Ihnen genannten Beispiel, der Datenbankaktualisierung, muss diese Funktion vielleicht nur einmal getestet werden, wenn ihr sicher sein könnt, dass jeder den neuen Code erhält, sobald er freigegeben wird, bevor ihr eine neue Version veröffentlichen. Wenn ihr jedoch jemanden habt, der in drei Jahren eine neue Version des Programms erhält und derzeit eine Version benutzt, die zwei Jahre veraltet ist, dann könnte es ein Problem sein, das Upgrade-Szenario nicht in Ihren Regressionssuit aufzunehmen. (Ich bin mir nicht sicher, wie ihr die Migrationstests jetzt durchführt, daher kann dies etwas sein, worüber ihr euch Gedanken machen müsst, oder auch nicht). Ich verstehe die Bedeutung von guten "Regressionstests", um sicherzustellen, dass behobene Fehler nicht erneut auftreten. Aber ich denke, es ist möglich, zu weit zu gehen und am Ende mit einer massiven "Regressionstest-Suite" für jeden behobenen Fehler, jede geänderte Funktion, sogar jede entfernte Funktion zu landen... ihr versteht, worauf ich hinaus will. Gibt es Heuristiken oder Techniken, um zu identifizieren, wann ein Test in die langfristige Regressionssuite gehört, im Gegensatz dazu, wann es besser wäre, einen "Einmal"- oder "Wegwerf"-Test zu schreiben, der für die nächste Version ausgeführt und dann verworfen wird? Idealerweise möchten wir dies zum Zeitpunkt der Erstellung der Tests identifizieren, aber auch Tipps zur Identifizierung dessen, was im Laufe der Zeit aussortiert werden kann, sind hilfreich. Die Hauptsorge besteht darin, den Zeitaufwand für jeden Release-Test zu minimieren. Wir haben eine große Legacy-Codebasis, die alte Technologien verwendet, die nicht sehr geeignet für automatisiertes Testen sind, was bedeutet, dass ein großer Teil unserer Regressionstests manuell durchgeführt wird. Wir möchten unsere manuelle Testbelastung für jeden Release nicht mit Tests erhöhen, die keinen langfristigen Wert bieten. Wir befinden uns auch in einer regulierten Umgebung, daher benötigen wir eine Möglichkeit, zu dokumentieren, was wir getestet haben, und ich denke, es ist sinnvoll, einen guten Test zu entwerfen, wenn ihr etwas ändert, anstatt nur ad hoc zu testen. Aber einige Dinge werden realistischerweise nicht zwei Jahre später plötzlich fehlschlagen, wenn wir jetzt zeigen, dass sie behoben sind. Einige Beispiele, bei denen mein "Bauchgefühl" sagt, dass sie nur für die erste Version nützlich sind: - Änderung der Form einer grafischen Steuerungsanzeige und Sicherstellen, dass alle Stellen, an denen eine solche Anzeige angezeigt wird, die neue Form verwenden (d.h., wir haben uns nicht wiederholt und den Code für die Anzeige dupliziert - dies ist ein Beispiel aus unserer Legacy-Codebasis, in der wir häufig kopierten Code und andere Wiederholungen gefunden haben). - Für ein Softwareprodukt, das Hardware steuert, haben wir die Unterstützung für einige Add-On-Geräte entfernt, die von der Hardware unterstützt wurden und in einer Datenbank gespeichert sind. Wir haben getestet, dass ein Upgrade der Datenbank von der Version, die die Geräte unterstützt hat, zur Version, die sie nicht mehr unterstützt, angemessen funktioniert und dass die Geräte in der neuen Version nicht mehr vorhanden sind. - Behebung eines "offensichtlichen" Fehlers, bei dem ein Dialogfeld nicht ordnungsgemäß aufgeräumt wird, wenn abgebrochen wird, usw. Um die manuelle Regressionssuite davor zu bewahren, übermäßig groß zu werden: - Testwartung und -bereinigung: Überprüft regelmäßig die vorhandene Regressionssuite und identifiziert Tests, die nicht mehr relevant sind, redundant sind oder nur geringen Mehrwert bieten. Entfernen oder überarbeitet solche Tests, um Duplizierungen zu minimieren und den Fokus der Suite zu optimieren. - Testpriorisierung: Priorisiert die Tests basierend auf ihrer Bedeutung, der Abdeckung von Risiken und den Nutzungsmustern. Konzentrieren Sie sich auf kritische Funktionen, Bereiche mit hohem Risiko und häufig verwendete Funktionen. Durch die Priorisierung von Tests können begrenzte manuelle Testressourcen effektiv eingesetzt werden. - Risikobasiertes Testen: Wendet risikobasierte Testtechniken an, um Bereiche mit hohem Risiko zu identifizieren und die Testbemühungen entsprechend zu verteilen. Diese Vorgehensweise stellt sicher, dass die kritischsten und anfälligsten Teile des Systems angemessen berücksichtigt werden, während weniger kritische Bereiche einer leichteren Prüfung unterzogen werden. - Automatisierungsmöglichkeiten: Untersucht die Möglichkeiten zur Automatisierung bestimmter Aspekte des Regressionstests. Automatisierte Tests können den manuellen Testaufwand erheblich reduzieren und eine umfassendere Abdeckung ermöglichen, ohne dass dabei erheblicher Zeitaufwand entsteht. Konzentriert euch auf die Automatisierung von wiederholten oder zeitaufwändigen Tests. - Testgetriebene Entwicklung: Fördert einen testgetriebenen Entwicklungsansatz, bei dem Tests vor der Implementierung neuer Funktionen oder der Behebung von Fehlern geschrieben werden. Diese Praxis fördert die Erstellung gezielter, gut konzipierter Tests, die weniger dazu neigen, die Regressionssuite aufzublähen. Beachtet, dass es ein iterativer Prozess ist, die richtige Balance zwischen gründlichem Regressionstesten und effizientem manuellem Testen zu finden. Überprüft und passt die Regressionssuite regelmäßig anhand von Feedback, Testergebnissen und sich ändernden Prioritäten an. Read the full article

[frentmeister]

Was sind wichtige Testszenarien, die speziell für Universal Windows Platform (UWP)-Anwendungen gelten?

Universal Windows Platform-Apps sind in Gerätefamilien gruppiert, die euch helfen, eine einzige App zu erstellen, die auf jedem Windows 10-Gerät läuft. UWP-Apps verwenden WinRT-APIs, um eine leistungsstarke Benutzeroberfläche und erweiterte asynchrone Funktionen bereitzustellen, die sich ideal für Geräte mit Internetverbindung eignen. https://www.youtube.com/watch?v=zlnq3HAhwr8 Die folgenden Testszenarien mit der Universal Windows Platform sind:- - Bereitstellungs- und Starttests: - Überwacht die App während der Zertifizierungstests, um aufzuzeichnen, wenn sie abstürzt oder sich aufhängt. - Starttest der Plattformversion: - Überprüft, ob die Windows-App auf einer zukünftigen Version des Betriebssystems ausgeführt werden kann. - Validierungstest für die Abbruchsteuerung von Hintergrundaufgaben: - Überprüft, ob die Anwendung über eine Abbruchsteuerung für deklarierte Hintergrundaufgaben verfügt. - App-Manifest-Compliance-Test: - Überprüft den Inhalt des App-Manifests, um sicherzustellen, dass der Inhalt korrekt ist. - BinScope Binary Analyzer Test:- Untersucht die Binärdateien der App auf Codierungs- und Erstellungspraktiken, die die App weniger anfällig für Angriffe machen oder als Angriffsvektor genutzt werden können. - Private Code Signing:- Testet auf das Vorhandensein von Binärdateien mit Private Code Signing innerhalb des App-Pakets. - Test auf unterstützte APIs:- Überprüft die Anwendung auf die Verwendung von nicht konformen APIs. - Leistungstest:- Die App muss schnell auf Benutzerinteraktionen und Systembefehle reagieren, um ein schnelles und flüssiges Benutzererlebnis zu bieten. - Test der App-Manifest-Ressourcen: - Überprüft die im App-Manifest definierten Ressourcen, um sicherzustellen, dass sie vorhanden und gültig sind. - Test der Debug-Konfiguration: - Prüft die App, um sicherzustellen, dass es sich nicht um ein Debug-Build handelt, oder testet die App, um sicherzustellen, dass es sich nicht um ein Debug-Build handelt und nicht mit Debug-Frameworks verknüpft ist. - Direct3D-Feature-Level-Test: - Testet Microsoft Direct3D-Anwendungen, um sicherzustellen, dass sie auf Geräten mit älterer Grafikhardware nicht abstürzen. - App Capabilities test:- Überprüft, ob die App die Fähigkeiten EnterpriseAuthentication, SharedUserCertificates und DocumentsLibrary deklariert. Wenn eine dieser Fähigkeiten deklariert wird, zeigt der Test eine Warnung für den Benutzer an. - Test der unterstützten Verzeichnisstruktur: - Überprüft, ob die Anwendungen bei der Installation Unterverzeichnisse erstellen. - WinJS-Hintergrundtask-Test: - Der WinJS-Hintergrundtask-Test stellt sicher, dass JavaScript-Anwendungen über die richtigen Beendigungsanweisungen verfügen, damit die Anwendungen keinen Akku verbrauchen. Top-Software-Testunternehmen stellen auch sicher, dass alle App-Images die richtigen Größenbeschränkungen, die richtigen Dateiformatbeschränkungen, die Dateikodierung und die Windows-Sicherheitsfunktionen einhalten. Read the full article

[frentmeister]

Welche Arten von manuellen Testfällen sollten für Regressionstests automatisiert werden?

Die Automatisierung ist ein fortlaufender Prozess, der nie aufhört und immer verbessert werden kann. Ihr solltet zunächst eine Priorisierung der Testfälle vornehmen und dann mit der Automatisierung der wichtigsten Fälle beginnen. Konzentriert euch zunächst auf die funktionalen Fälle. Zum Beispiel solltet ihr zuerst einen Basic procedure, einen Smoke-Test, einen Happy Flow usw. automatisieren. https://www.youtube.com/watch?v=kEw92MbO7to Wenn alle wichtigen Testfälle automatisiert sind und der Prozess stabil ist, habt ihr Zeit, die restlichen Testfälle zu automatisieren, die weniger wichtig sind und eine geringere Auswirkung haben. Selbst wenn ihr für die Automatisierung eines bestimmten Tests mehr Zeit aufwendet als für die manuelle Durchführung, werdet ihr langfristig mehr Zeit gewinnen, wenn dieser Testfall automatisiert ist. Ich muss auch erwähnen, dass ihr euer Automatisierungsframework von Anfang an sorgfältig entwerfen solltet, damit es einfach zu warten ist und ihr keine Zeit verliert, wenn ihr versucht, das Framework in der Zukunft zu refaktorieren oder zu verbessern. Es ist sehr aufwendig, Tests zu verwalten und zu priorisieren. Der Abdeckungsgrad ist einer von mehreren guten Näherungswerten.Eine Möglichkeit, Prioritäten zu setzen, besteht darin, mithilfe von Tools zu messen, welche Teile der Anwendung am häufigsten verwendet werden (was sich von der Abdeckung unterscheidet), und die Tests entsprechend zu konzentrieren, um diese Teile abzudecken. Eine andere Möglichkeit ist die Verwendung von Expertenmeinungen und Faustregeln: Schreibt einen "Happy Path Test" für die aus Benutzersicht wichtigsten Funktionen und für Funktionen, die für die Sicherheit wichtig sind (die Kosten wären hoch, wenn euer Unternehmen wegen der Bereitstellung falscher Informationen verklagt würde). Messt die Testabdeckung und fügt weitere Tests hinzu, um sie zu erhöhen. Die Abdeckung ist natürlich ein kompliziertes Thema (müssen eure Tests Fehlerbehandlungen abdecken, die selten und schwer auszulösen sind? usw.).Nach dem klassischen Ansatz solltet ihr die Kosten für die Durchführung automatisierter Tests als Investitionen betrachten und daher die Tests auswählen, deren Automatisierung euch einen maximalen ROI bescheren würde. (ROI = Return on Investment) Die Herausforderung besteht hier in der Berechnung des NetProfit-Wertes, da dieser von eurem speziellen Projekt abhängt und davon, was ihr tatsächlich minimieren müssen (entweder die Kosten für das Testen oder die Testzeit). Ihr solltet die durchschnittliche Anzahl der Builds pro Release, die Testprioritäten (die zu überarbeiten sind, da sich der Wert des Tests ändern kann), die Zeit für jede einzelne Testausführung und die geschätzte Zeit für die Implementierung und Wartung der Test- und Testausführungsumgebung berücksichtigen. Dann sortiert eure Tests nach dem ROI-Wert (ROI = Return on Investment) und plant die Durchführung entsprechend den euch zur Verfügung stehenden Ressourcen. https://www.youtube.com/watch?v=HJ8E8wKm5RY Das Testen von Software ist in erster Linie eine risikobasierte Tätigkeit, sodass die Testfälle mit Bedacht für eine häufige Durchführung ausgewählt werden sollten, um mit möglichst geringen Investitionen eine maximale Rendite zu erzielen. Es gibt hauptsächlich drei Arten von Testsuiten, die bei jeder Veröffentlichung einer Softwareanwendung ausgeführt werden: Regressionstests, veröffentlichungsspezifische Tests und Verifizierungstests zur Fehlerbehebung. Ich würde die folgenden Testfälle als Teil der Regressionssuite auswählen: - Fehler, die häufig aufgetreten sind: Einige Bereiche in der Anwendung sind so fehleranfällig, dass sie in der Regel nach einer kleinen Änderung des Codes fehlschlagen. Wir können diese fehlgeschlagenen Testfälle während des gesamten Produktzyklus im Auge behalten und sie in die Regressionstestsuite aufnehmen. - die die Kernfunktionen der Anwendung überprüfen: Bevor ihr die Testfälle entwerft, identifiziert alle Kernfunktionen der Anwendung. Stellt sicher, dass die Testfälle alle im Anforderungsdokument genannten Funktionen abdecken. Man kann eine Rückverfolgbarkeitsmatrix verwenden, um sicherzustellen, dass keine Anforderung ungetestet bleibt. - für Funktionalitäten, die in letzter Zeit Änderungen erfahren haben: Pflegt die Historie der Funktionsänderungen für die Testfalldokumentation, um die Testfälle zu identifizieren, die in die Regressionssuite aufgenommen werden sollen. - Abdecken von Integrationsszenarien: Dazu gehören alle Integrationstestszenarien an der Funktionsgrenze, an der zwei Module miteinander kommunizieren und Daten weitergeben und die Integration stattfindet. - die von Natur aus komplex sind: Einige Systemfunktionen können nur durch eine komplexe Abfolge von UI-Ereignissen erreicht werden. - die eine hohe geschäftliche Priorität haben: Priorisiert die Testfälle in Bezug auf die Auswirkungen auf das Geschäft und auf kritische und häufig verwendete Funktionen. Es ist immer hilfreich, wenn eine Analyse durchgeführt wird, um festzustellen, welche Testfälle relevant sind. Eine Idee ist, die Testfälle nach Wichtigkeit und Kundennutzen in verschiedene Prioritäten einzuteilen. Durch die Auswahl von Testfällen nach Priorität lässt sich der Aufwand für Regressionstests erheblich reduzieren. - Auf einer "Fall-zu-Fall"-Basis: Es bleibt immer Raum für Expertenurteile und Erfahrung, um Testfälle von Fall zu Fall auszuwählen, je nach Unternehmen/Domäne/Projekt/Team/Funktion usw. Read the full article

[frentmeister]

Regressionstest abhärten: Erstellung von Regressionstests nach dem Prinzip "slow to break".

Ich habe gelernt, dass es eine Reihe von Schlüsselfaktoren gibt, um leicht zu wartende, zuverlässige automatisierte Tests zu haben. Ordnet die Steuerelemente an einer einzigen Stelle zu Eure Steuerelemente sollten an einer einzigen Stelle abgebildet werden, sodass ihr bei einer Änderung eines Steuerelements dieses nur an einer einzigen Stelle ändern müsst. Wenn sich ein Steuerelement an einer einzigen Stelle befindet, könnt ihr eine einzeilige Codeänderung vornehmen, wenn ein Entwickler die Steuerelemente neu zuordnet. Ich ordne auch den Typ des Steuerelements zu, sodass der Entwickler von einem Link zu einer Schaltfläche wechseln kann und ich nur diese Steuerdatei zu ändern brauche. Versteckt nebensächliche Details Versteckt nebensächliche Details. Jedes Detail, das nicht direkt mit dem Zweck eures Tests zusammenhängt, gehört an einen anderen Ort als in euren Test. Versteckt es lieber irgendwo, z. B. in einer Variablen oder in einer Methode, und gebt ihm einen guten Namen. Eliminiert Duplikate Eliminiert Duplikate. Jedes Bit an doppelten Daten ist eine Variable, die darauf wartet, geboren zu werden und einen aussagekräftigen Namen zu erhalten. Jede Abfolge von doppelten Testschritten ist eine Methode, die darauf wartet, geboren zu werden und einen aussagekräftigen Namen zu erhalten. Benennen Sie jede wichtige Idee Benennt jede wichtige Idee. Warum meldet sich der Testcode als "F.D.Gumby" an und nicht als ein anderer Benutzer? Weil das der Manager ist, der den Mitarbeiter eingestellt hat, den Sie auf die Gehaltsliste setzen? Dann fügen Sie "F.D.Gumby" in eine Variable ein und nennen Sie sie "hiring manager" (oder wie auch immer), um ihre Absicht auszudrücken. Abstrahiert das Testautomatisierungstool wo immer es möglich ist Ich habe im Wesentlichen drei Aktionen, die ich 99 % der Zeit ausführe: Invoke, Setvalue und GetValue. Mit Invoke wird ein Link oder eine Schaltfläche angeklickt, ein Kontrollkästchen aktiviert oder deaktiviert usw. SetValue setzt Werte in Steuerelemente, z. B. Text in ein Textfeld. GetValue holt Daten aus den Steuerelementen, die in erster Linie zur Überprüfung verwendet werden. Jede Automatisierungsaktion, z. B. die Durchführung einer Suche, ruft nur die Methoden invoke, Set und get auf. Dies ermöglicht eine fast vollständige Abstraktion des zugrundeliegenden Automatisierungstools und eine einzige Stelle in Ihrem Code, an der die steuerungsspezifischen Methoden der unteren Ebene aufgerufen werden. Verwendet reguläre Ausdrücke, um Ihre Kontrollnamen zuzuordnen Durch die Verwendung regulärer Ausdrücke können ihr das Steuerelement so definieren, dass der Entwickler es an eine beliebige Stelle auf der Seite verschieben kann und Ihre Tests trotzdem ausgeführt werden. Erstellt Testdatenobjekte, um eure Testdaten zu speichern Ich erstelle Testdatenobjekte, die normalerweise ziemlich genau 1:1 mit den Steuerelementen auf einer Seite übereinstimmen. Dann erstelle ich ein erwartetes und ein tatsächliches Objekt und leite diese Objekte an die verschiedenen Ebenen im Stapel weiter. Die Erstellung zusätzlicher Tests kann dann in einigen Fällen so einfach sein wie die Verwendung eines vorhandenen Tests mit anderen Daten. Trennt den Test von der Implementierung Die Trennung von Belangen ist ein wichtiges technisches Designprinzip, das ihr bei den Tests anwenden solltet. Die Absicht des Testfalls sollte so weit wie möglich von der physischen Implementierung getrennt werden, die die Interaktion mit der Seite durchführt. Zum Beispiel statt ...   public void SearchOnGoogle() { using (var browser = new IE("http://www.google.com")) { browser.TextField(Find.ByName("q")).TypeText("Stack Exchange"); browser.Button(Find.ByName("btnG")).Click(); Assert.IsTrue(browser.ContainsText("Stack Exchange - Free, Community-Powered Q&A")); } } Ihre Tests sollten also auf höchster Ebene eine domänenspezifische API haben.   public void SearchOnGoogle() { SearchEngine.WebSearch("Stack Exchange"); SearchEngine.Verifcation.WebSearch("Stack Exchange - Free, Community-Powered Q&A"); } } ... public void WebSearch(string value) { ControlHandler.SetValue(Controls.txtSearchValue, value); ControlHandler.Invoke(Controls.btnSearch); } Ausführliche Informationen zu diesem Thema findet ihr in Capture The Essence Of Your Test Cases von Michael Hunter. Durch die Anwendung dieser Prinzipien lassen sich automatisierte Regressionstests viel leichter korrigieren, wenn sich entweder die Anforderungen oder die Implementierung ändern. Weitere Einzelheiten und Beispiele finden Sie in meinem Artikel "Writing Maintainable Automated Acceptance Tests" (PDF). Siehe auch Bob Martins ausgezeichnetes Video zu denselben Ideen.   Read the full article

[frentmeister]

Korrektes Management von Regressionstests als Schnittstelle zwischen verschiedenen Testteams innerhalb von SAFe-Scrum

Um Regressionstests als Schnittstelle zwischen verschiedenen Testteams in einer SAFe-Scrum-Umgebung mit vielen Teams und einer großen Anzahl von Testfällen richtig zu verwalten, würde ich die folgenden Schritte vorschlagen: Definiert klare Richtlinien für die Erstellung und Verwaltung von Testfällen: Alle Teams sollten ein einheitliches Format für die Erstellung und Dokumentation von Testfällen befolgen, einschließlich klarer Definitionen für manuelle und automatisierte Testfälle. Erstellt ein zentrales Testfall-Repository: Alle Testfälle aus verschiedenen Teams sollten in einem zentralen Repository (z. B. X-Ray) gespeichert werden, um sicherzustellen, dass sie leicht zugänglich und durchsuchbar sind. Einen Prozess zur Überprüfung von Testfällen einrichten: Ein spezielles Team oder eine Einzelperson sollte alle Testfälle überprüfen, bevor diese in das zentrale Repository aufgenommen werden, um sicherzustellen, dass sie korrekt und vollständig sind und den Richtlinien entsprechen. Definiert Testlaufvorlagen: Erstellt Vorlagen für verschiedene Arten von Testläufen, z. B. für einzelne Team-Testläufe und komplette Regressionstestläufe, um Konsistenz und Effizienz zu gewährleisten. Implementiert die Automatisierung von Testfällen: Automatisiert so viele Testfälle wie möglich mithilfe von Tools wie Jenkins, um den Arbeitsaufwand für manuelle Tests zu verringern und die Gesamteffizienz des Testprozesses zu verbessern. Regelmäßige Überprüfung und Aktualisierung der Testfälle: Um das Risiko zu minimieren, ständig neue und alte Testfälle gemixt zu haben, ist es wichtig, die Testfälle regelmäßig zu überprüfen und bei Bedarf zu aktualisieren. Verwendet ein Testmanagement-Tool wie X-Ray: Es kann euch helfen, den Überblick über alle Testfälle und Testläufe zu behalten, und gibt euch einen Überblick über die Testergebnisse. Erwägt den Einsatz eines Tools für die Testfallverwaltung wie TestRail, mit dem ihr alle Ihre Testfälle, Testläufe und Testergebnisse organisieren, verwalten und verfolgen könnt. Automatisierte Testfälle statt manueller Testfälle: Eliminiert nach Möglichkeit manuell durchgeführte, geskriptete Regressionstests - Versucht, geskriptete Regressionstests so weit wie möglich zu automatisieren. Es gibt einige Dinge, die nicht automatisiert werden sollten, z. B. Hardware-Interaktionen, Ausdrucke, Überprüfung des Erscheinungsbilds der Benutzeroberfläche usw. Der Rest sollte so weit wie möglich automatisiert werden.  Unittest nutzen: Wenn ihr Zugang zu den Unit-Tests habt, würde ich mit diesen beginnen und die Unit-Tests erweitern, damit ihr so viel Pfad-/Codeabdeckung wie möglich habt. Ich würde auch das Unit-Test-Framework verwenden, um Integrationstests auf niedrigerer Ebene durchzuführen, um die Geschäftslogik abzudecken, damit die schnellstmöglichen Tests so viel Arbeit wie möglich erledigen. E2E-Test nutzen: Wenn die Benutzeroberfläche die API verwendet, würde ich mich viel mehr auf die API-Tests konzentrieren, um die End-to-End-Funktionalität abzudecken, da diese schneller sind als die UI-Tests. In diesem Szenario würde ich die UI-Tests auf die Formulareingabe/-übermittlung und die Überprüfung, ob die eingegebenen Daten übermittelt werden, beschränken und vielleicht eine Handvoll End-to-End-Tests mit kritischen Funktionen durchführen. Plant die Automatisierung: Wenn ihr könnt, solltet ihr eure automatisierten Tests in den Build-Prozess einbinden. Ihre API-Tests, Unit-Tests und Integrationstests sollten nach jedem Build ausgeführt werden. Für UI-Tests solltet ihr bei jedem Build einen Smoke-Test verwenden und tägliche Durchläufe der gesamten UI-Testsuite planen, um sicherzustellen, dass die Testläufe nicht zu einem Engpass werden. Arbeitet mit den Entwicklern zusammen: Bei Unit- und Low-Level-Integrationstests solltet ihr mit den Entwicklern zusammenarbeiten. Dies kann möglich sein oder auch nicht, aber wenn es möglich ist, ist es der beste Weg, um sicherzustellen, dass ihr eine gute Abdeckung habt, die gut funktioniert. Stellt sicher, dass ihr ein durchsuchbares Test-Repository habt - Alle von euch definierten Tests, ob manuell oder automatisiert, sollten für alle Tester sichtbar sein und von den Testern, die mit diesem Teil des Systems arbeiten, bearbeitet werden können. Wenn ihr eine Namenskonvention verwendet und damit beginnt, alle Tests so umzubenennen, dass sie der Namenskonvention entsprechen, werdet ihr nach und nach doppelte Tests finden und die Redundanzen beseitigen können. Die manuellen Tester sollten in der Lage sein zu sehen, welche Tests automatisiert sind, sodass ihr eure Tests effektiver ausrichten könnt. Beachtet, dass jede Namenskonvention funktioniert, solange sie konsistent ist. Bereinigt die manuellen Tests: Auch hier gilt, dass alle stark skriptbasierten manuellen Tests nach Möglichkeit automatisiert werden sollten. Erfahrene manuelle Tester sind viel besser geeignet, um manuelle Tests durchzuführen. Read the full article

[frentmeister]

Was sollten Tester tun, wenn sie keine Fehler im Produkt finden können?

Grundsätzlich läuft etwas falsch, wenn euer Testteam im aktuellen Produkt keine Fehler findet. Denn dann ist das Team eventuell betriebsblind oder zu unerfahren. Auch andere Faktoren spielen hier in diesen Kontext mit ein. Selbst in der perfekten Welt, in der die Software die Hände der Entwickler zu 100 % fehlerfrei und mit vollständigen Funktionen verlässt, ist das einfach nicht wahr. Ja, wenn ihr in der 11. Stunde einen geschäftskritischen Fehler finden, ist das großartig, und ihr seid der Held. Aber wenn ihr alle ausgezeichneten Testfälle ausführt und keine Fehler entdecken, habt ihr etwas von gleichem oder höherem Wert geschaffen. Das ist Qualitätssicherung. - Ihr könnt den Arbeitsaufwand für eine neue Funktion nicht mit Sicherheit abschätzen. Denn ein Fehler könnte sich direkt unter der Oberfläche einer kritischen Komponente verstecken. - Ihr könnt einen Änderungssatz nicht effizient testen. Denn ohne eine Vertrauensbasis muss jeder Test ein vollständiger Regressionstest sein. - Ihr könnt euer Produkt nicht an seriöse Kunden verkaufen, weil euer Entwickler auf die Frage, ob es XYZ kann, antwortet: "Nun, theoretisch schon. Ich denke, das Testmanifest hat es auf den Punkt gebracht. Konzentriert euch auf die Fehlervermeidung und nicht auf die Fehlersuche. Wenn Fehler die Produktion erreichen, sollten Sie eine Ursachenanalyse durchführen und verhindern, dass ähnliche Fehler in Zukunft auftreten.  

Dazu gibt es auch noch weitere Informationen: https://less.works/less/technical-excellence/thinking-about-testing.html https://moreagiletestingmanifesto.wordpress.com/2015/08/02/agile-testing-manifesto/ http://www.jamesshore.com/Agile-Book/root_cause_analysis.html http://moderntesting.org   Read the full article