Smoke-Test (Smoke-Testing, Rauchtest)

Was ist ein Smoke-Test (Smoke-Testing, Rauchtest)?

Smoke Testing, auch Build Verification Testing oder Confidence Testing genannt, ist eine Softwaretestmethode, mit der festgestellt wird, ob ein neues Software-Build für die nächste Testphase bereit ist. Mit dieser Testmethode wird bestimmt, ob die wichtigsten Funktionen eines Programms funktionieren, aber es wird nicht auf feinere Details eingegangen.

Als vorläufige Prüfung von Software findet der Smoke-Test grundlegende und kritische Probleme in einer Anwendung, bevor tiefer gehende Tests durchgeführt werden. Wenn eine Software einen Smoke-Test besteht, fahren die Teams der Qualitätssicherung (QS) mit weiteren Tests fort. Ein Fehlschlag bedeutet, dass die Software an das Entwicklungsteam zurückgegeben werden muss.

Das Ziel von Smoke-Tests ist es, einfache, aber schwerwiegende Fehler mit Hilfe von Testfällen zu entdecken, die die wichtigsten Funktionalitäten einer Software abdecken. Smoke-Tests werden von QS-Teams durchgeführt, die bei jedem Build einen minimalen Satz von Tests verwenden, die sich auf die Softwarefunktionalität konzentrieren.

Ohne diese Tests könnten größere Probleme übersehen werden, so dass die Chance besteht, dass diese Probleme im weiteren Verlauf größere Störungen verursachen.

Der Begriff Smoke Testing stammt von einer grundlegenden Art von Hardwaretests, bei denen ein Gerät den Test besteht, wenn es beim ersten Einschalten nicht in Brand gerät. Tägliche Build und Smoke-Tests gehören zu den Best Practices der Branche, die vom Institute of Electrical and Electronics Engineers im Code Complete des ehemaligen IEEE-Chefredakteurs und Softwareentwicklungsexperten Steve McConnell empfohlen werden.

Was sind die verschiedenen Arten von Smoke-Tests?

Zu den Arten von Smoke-Tests gehören folgende:

• Manuelle Smoke-Tests. Menschliche Softwaretester führen Smoke-Tests manuell durch. Dazu gehört das händische Entwickeln und Aktualisieren von Testfällen. Auch Testskripte werden für neue oder vorhandene Funktionen manuell geschrieben.
• Automatisierte Smoke-Tests. Software-Tools werden zur Automatisierung des Smoke-Testing-Prozesses eingesetzt. Smoke-Testing-Tools machen den Testprozess effizienter, indem sie automatisch relevante Tests bereitstellen.
• Hybride Smoke-Tests. Hybridtests sind eine Kombination aus manuellen und automatisierten Smoke-Tests, bei denen die Tester Testfälle schreiben und die Tests dann mit Hilfe eines Tools automatisieren.

Funktionsweise und Durchführung von Smoke-Tests

QS-Tester führen Smoke-Tests durch, nachdem die Entwickler einen neuen Build einer Anwendung geliefert haben. Der Test wird manuell oder automatisch mit zuvor geschriebenen Skripten durchgeführt.

Wenn der Smoke-Test erfolgreich verläuft, wird die Software in ein bestehendes Build in der QS- und Staging-Umgebung integriert. Das Software-Build wird dann strengeren Tests unterzogen, zum Beispiel Unit- und Integrationstests. Wenn der Smoke-Test fehlschlägt, haben die Tester einen schwerwiegenden Fehler entdeckt, der alle weiteren Tests stoppt. Die QS-Teams fordern dann die Entwickler auf, einen korrigierten Build zur Verfügung zu stellen.

Dieser breit angelegte Anfangstest ist eine effektivere Strategie zur Verbesserung des Softwarecodes, als wenn das Team zu diesem frühen Zeitpunkt des Softwareentwicklungsprozesses spezifische und strenge Tests durchführt.

Smoke-Tests werden auch aus der Perspektive der Benutzererfahrung durchgeführt. Bei diesem Ansatz werden wichtige Funktionen getestet, beispielsweise ob der Build zugänglich ist oder ob die Benutzeroberfläche und der Anmeldemechanismus korrekt funktionieren. Eine andere wichtige Funktion ist, ob eine Auswahl mit der beabsichtigten Aktion übereinstimmt.

Wie Smoke-Tests durchgeführt werden, hängt von der Art des Tests ab, und die Vorgehensweisen können von Unternehmen zu Unternehmen unterschiedlich sein.

Ein allgemeiner Prozess zur Durchführung eines Smoke-Tests kann wie folgt aussehen:

• Entscheiden Sie sich zwischen manuellen, automatisierten oder hybriden Tests. Manuelle Tests werden in der Regel zuerst durchgeführt, während automatisierte Tests durchgeführt werden können, sobald weitere Elemente zum Smoke-Test hinzugefügt wurden.
• Erstellen Sie Testszenarien. QS-Tester müssen wissen, wie viele Testfälle sie für jede Kernfunktion der Software benötigen. Pass- oder Fail-Metriken sollten auf der Grundlage der Software und der organisatorischen Anforderungen und Standards festgelegt werden.
• Erstellen Sie die Rauchtests. Schreiben und erstellen Sie die Test-Suites entweder mit manuellen oder automatisierten Verfahren.
• Ausführen und Aufzeichnen der Tests. Während die Smoke-Tests durchgeführt werden, sollten die Tester über einen Prozess verfügen, um die Ergebnisse für jeden Test aufzuzeichnen. Dies kann entweder manuell oder automatisiert erfolgen.
• Analysieren Sie die Ergebnisse der Smoke-Tests. Wenn die Software fehlschlägt, wird sie für weitere Tests an das Entwicklungsteam zurückgeschickt. Wenn sie bestanden wird, ist sie bereit für strengere Funktionstests.

Bei manuellen Smoke-Tests müssen die Tester diese Tests schreiben und aktualisieren. Die Skripte werden manuell geändert, um sie an die jeweiligen Anforderungen anzupassen. Bei automatisierten Smoke-Tests werden zusätzliche Tools eingesetzt, um Kernfunktionen schnell zu testen. Bei hybriden Smoke-Tests schreibt ein Tester die Testfälle und automatisiert die Tests mit Hilfe automatisierter Test-Tools.

Vorteile von Smoke-Tests

Smoke-Tests sind aus den folgenden Gründen ein wertvoller Teil des Testprozesses:

• Durch die Automatisierung können die Tests schneller und häufiger durchgeführt werden.
• Zukünftige Builds werden auf fehlerfreier Software aufgebaut.
• Fehler werden in frühen Entwicklungsstadien identifiziert.
• Sie verringern die Risiken, die mit dem Hinzufügen von Code zu bestehenden Build-Integrationen verbunden sind.
• Smoke-Tests können aufgrund ihres geringen Ressourcenbedarfs und des einfachen Prozesses häufig durchgeführt werden.
• Es besteht Flexibilität bei der Implementierung mit manuellen, automatisierten und hybriden Typen.
• Die Softwarequalität wird bereits in einem frühen Stadium der Entwicklung überprüft, um sicherzustellen, dass ein Build stabil ist.

Nachteile von Smoke-Tests

Smoke-Tests haben jedoch auch einige Nachteile, darunter unter anderem:

• Smoke-Tests decken nicht alle Funktionen einer Software ab – es werden nur bestimmte Kernfunktionen getestet.
• Nicht jeder Fehler oder jedes Problem kann mit Smoke-Tests gefunden werden, und einige können auch noch später in der Entwicklung auftauchen und entdeckt werden.
• Manuelle Smoke-Tests dauern länger, wenn sie in größeren Projekten eingesetzt werden.

Was ist der Smoke-Test-Zyklus?

Der Smoke-Testing-Zyklus beginnt mit der Lieferung eines Builds durch das Entwicklungsteam. Dieser Build wird von der Qualitätssicherung für einen ersten Smoke-Test freigegeben. Spezifische Testfälle werden auf der Grundlage von Kern- oder Schlüsselfunktionen priorisiert, Tests werden erstellt und die Software wird dann getestet.

Wenn die Software den ersten Smoke-Test nicht besteht, wird sie an das Entwicklungsteam zurückgegeben, wo sie korrigiert und dann an die QS zurückgeschickt wird. Wenn die Software diese Tests besteht, wird sie in einen bestehenden Build in der QS- und Staging-Umgebung integriert. Die Software ist nun bereit für strengere Funktionstests.

Dieser Zyklus hilft bei der Identifizierung grundlegender und kritischer Probleme in einer Anwendung, bevor das Team, das daran arbeitet, gründlichere Tests durchführt. Aus diesem Grund werden Smoke-Tests in der Anfangsphase des Testzyklus‘ durchgeführt.

Beispiele für Smoke-Tests

Beim Smoke-Testing werden die grundlegenden Funktionalitäten und Kernmerkmale der in der Entwicklung befindlichen Software getestet. Ein Beispiel für einen Smoke-Test könnte das Testen einer Anmeldefunktion einer Webanwendung sein. Aus der Sicht des Benutzers wird die Seite aufgerufen, und der Tester gibt einen gültigen Benutzernamen und ein Passwort ein und versucht, sich anzumelden. Ein erfolgreicher Test würde zu einer erfolgreichen Anmeldung führen. Wenn die Funktion nicht funktioniert, wird sie an das Entwicklungsteam zurückgeschickt.

Ein weiteres Beispiel für einen Smoke-Test wäre die Prüfung, ob ein Artikel in einen Warenkorb eines E-Shops gelegt werden kann. Auch hier würde ein Tester eine bestimmte Seite aufrufen und versuchen, den Artikel in seinen Warenkorb zu legen. Bei einem erfolgreichen Test wird der Artikel dem Warenkorb hinzugefügt, während ein Fehler dazu führt, dass der Artikel nicht im Warenkorb dargestellt wird.

Eine andere Funktion, zum Beispiel die Suchfunktion in einer Anwendung, könnte ebenfalls einem Smoke-Test unterzogen werden. Die Anwendung wird geöffnet, und der Benutzer navigiert zur Suchleiste, sucht nach einer Datei und wählt sie aus, um zu sehen, ob er auf sie zugreifen kann.

Automatisierung und Smoke-Tests

Automatisierte Smoke-Tests können die Testzeit drastisch verkürzen. Manuelle Tests können einen längeren Zeitraum in Anspruch nehmen, je nachdem, wie viele Smoke-Tests erforderlich sind. Nach der Automatisierung dieser Tests kann das Smoke-Testing nur noch wenige Minuten dauern. Wenn Entwickler häufig Builds erstellen oder kontinuierliche Tests implementieren, kann die Qualitätssicherung durch die Automatisierung von Smoke-Tests schnelleres Feedback zu Test-Builds geben.

Zu den Tools für automatisierte Smoke-Tests gehören Selenium und PhantomJS. Selenium ist eine Open-Source-Software, die Testparameter auf mehreren Webbrowsern automatisiert und ausführt. Selenium automatisiert auch die Steuerung von Browsern auf verschiedenen Betriebssystemen. PhantomJS ist eine Option für die Integration und Automatisierung mit kontinuierlichen Integrations-Tools wie Jenkins und TeamCity. PhantomJS ist nicht ressourcenintensiv.

Smoke-Tests versus Regressionstests

Regressionstests sind eine weitere Möglichkeit, um sicherzustellen, dass sich neue Codeänderungen nicht negativ auf die bestehende Codebasis einer Anwendung auswirken. Bei Regressionstests handelt es sich um eine Art von Softwaretest, bei dem geprüft wird, ob Änderungen an einer Anwendung zu Fehlern führen.

Ähnlich wie Smoke-Tests werden Regressionstests von einem QS-Ingenieur durchgeführt und stellen sicher, dass Änderungen an einem Programm keine neuen Fehler hinzufügen. Wie Smoke-Tests sollten auch Regressionstests häufig bei jedem neuen Build durchgeführt werden. Beide Testarten können auch automatisiert oder manuell durchgeführt werden.

Im Gegensatz zu Smoke-Tests, bei denen es sich um oberflächliche Tests handelt, sind Regressionstests tiefgreifend und detailliert. Regressionstests zielen auf bestimmte Vorgänge in der Software ab und nehmen einige Stunden in Anspruch.

Bei Regressionstests wird beispielsweise explizit jeder Link auf einer aktualisierten Webseite überprüft, um sicherzustellen, dass jeder Link noch wie vorgesehen funktioniert. Während sich Smoke-Tests auf die Überprüfung der Stabilität einer Funktion konzentrieren, wird bei Regressionstests die Konsistenz einer Funktion überprüft.

Regressionstests sind auch nicht wie Smoke-Tests für die Freigabe oder Ablehnung von Software-Builds verantwortlich.

Smoke-Tests vs. Sanity Tests

Sanity-Tests sind Bewertungen auf hoher Ebene, die die Zuverlässigkeit einer Anwendung sicherstellen sollen. Dieser Testtyp konzentriert sich auf Testfälle mit neuen Funktionen, um Fehler im Build zu identifizieren. Häufig umfassen Sanity-Tests auch einen Test kritischer Anwendungs-Workflows und Integrationen.

Sanity- und Smoke-Tests ähneln sich in ihrer Art und können miteinander verwechselt werden. Smoke-Tests konzentrieren sich auf die Überprüfung kritischer Softwarefunktionalitäten, bevor tiefer gehende Tests durchgeführt werden, während Sanity-Tests die Funktionalitäten wie Fehlerbehebungen nach dem Build überprüfen. Mit anderen Worten: Während Smoke-Tests durchgeführt werden, um die Stabilität eines Builds zu überprüfen, werden Sanity-Tests an stabilen Builds durchgeführt. Sanity-Tests sind auch eine Teilmenge der Regressionstests, während Smoke-Tests eine Teilmenge der Akzeptanztests sind.

Smoke-Tests werden in der Regel auch dokumentiert, Sanity-Tests hingegen nicht. Darüber hinaus können Smoke-Tests sowohl von Entwicklern als auch von QS-Testern durchgeführt werden, während Sanity-Tests nur von den Testern durchgeführt werden.