Einführung

Das Leben eines QA-Testers wird als unvollständig betrachtet, wenn die Begriffe ‚Smoke Testing‘, ‚Sanity Testing‘ und ‚Regression Testing‘ nicht hineingegossen werden. Obwohl dies einige regelmäßig verwendete Begriffe sind, gibt es auch einige häufige Missverständnisse.

Bevor wir mit den Details von Rauch-, Vernunft- und Regressionstests beginnen und was sie tatsächlich bedeuten, gehen wir einige häufige Missverständnisse und Mythen um sie herum durch:

1. Rauchtests und Gesundheitstests sind gleich und können synonym verwendet werden : Dies ist nicht wahr und sollte niemals durchgeführt werden, warum? wir werden das in diesem Artikel diskutieren.
2. Sanity-Tests entsprechen Akzeptanztests: Akzeptanztests werden durchgeführt, um sicherzustellen, dass der Build alle Anforderungen erfüllt, die der Client vor der Veröffentlichung angegeben hat, während Sanity-Tests durchgeführt werden, um sicherzustellen, dass das Produkt gesund ist, rational für detailliertere Tests. Diese sind und sollten nicht austauschbar verwendet werden.
3. Wenn ich Rauchtests mache, kann ich Sanity-Tests überspringen: Smoke-Tests sind Tests auf sehr hohem Niveau, da diese Tests durchgeführt werden, um sicherzustellen, dass dieser Build für jede andere Art von Tests geeignet ist. Dies könnte beispielsweise nur ein Test sein, um sicherzustellen, dass der Build installiert wird, und dann kann der Sanity-Test beginnen. Obwohl die Smoke-Testfälle manchmal zusammen mit Sanity-Testfällen ausgeführt werden, sollten diese nicht als ein und dasselbe verwechselt werden.
4. Regressionstests haben nichts mit Rauchtests oder Sanity-Tests zu tun: Theoretisch ist Sanity-Tests eine Teilmenge von Regressionstests. Einige Regressionstestfälle mit hoher Priorität stellen normalerweise einen Sanity-Testfall dar.
5. Wenn ich beabsichtige, die vollständige Regressionstestsuite auszuführen, muss ich keinen Smoke-Test oder Sanity-Test ausführen: Obwohl dies in einigen Fällen der Fall sein kann, da Sanity-Tests ohnehin eine Teilmenge von Regressionstests sind, ist es dennoch ratsam, zuerst die Sanity-Testfälle auszuführen und dann mit den restlichen Regressionstestfällen zu folgen.

In diesem Artikel werden wir versuchen, die obigen Verwirrungen ein für alle Mal zu beseitigen.

Falls Sie mehr über manuelle Tests lesen möchten, lesen Sie den Link hier.

Hinweis: Da wir den Begriff ‚Software Build‘ im Artikel viele Male verwenden werden, definieren wir ihn hier. „Software Build“ ist ein Prozess der Umwandlung von Quellcode, in eine Benutzeranwendung, nach mehreren Revisionen und Codeänderungen und Software-Build-Erstellung umfasst mehrere Prozesse wie, „Versionskontrolle, Codequalität & Kompilierung“ und Software Build ist auch das Ergebnis dieses Bauprozesses. In diesem Artikel wird ein Build als testbare Version der Software bezeichnet.

Smoke Testing

Smoke Testing ist ein Ansatz, der normalerweise in den ersten Entwicklungsphasen des Software Development Life Cycle(SDLC) durchgeführt wird, um sicherzustellen, dass die Kernfunktionalitäten eines Programms problemlos funktionieren. Es wird ausgeführt, bevor detaillierte Funktionstests an der Software durchgeführt werden.

Die Hauptabsicht von Smoke-Tests besteht nicht darin, tiefgehende Tests durchzuführen, sondern zu überprüfen, ob die Kern- oder Hauptfunktionalitäten des Programms oder der Software einwandfrei funktionieren. Smoke Testing zielt darauf ab, einen fehlerhaften Build in der Anfangsphase abzulehnen, damit das Testteam keine Zeit mit der Installation von & Test der Softwareanwendung verschwendet.

Smoke Testing wird auch als Build Verification Test bezeichnet.

Sehen wir uns ein einfaches Beispiel an, in dem Sie eine E-Mail-Anwendung zum Testen erhalten. Die wichtigsten Funktionen wären, sich bei der E-Mail-Anwendung anzumelden, eine E-Mail zu verfassen und zu senden, oder? Und falls die E-Mail nicht gesendet wird, ist es sinnvoll, andere Funktionen wie Entwürfe, gelöschte Nachrichten, Archive usw. zu testen? Dies bedeutet, dass Sie den Build ohne weitere Validierung löschen müssen. Dies wird als Rauchtestung bezeichnet.

Das Hauptaugenmerk der Rauchtests liegt auf der Prüfung der kritischen Bereiche und nicht der vollständigen Anwendung.

Wann Smoke-Tests durchzuführen sind

• Wenn Entwickler dem QA-Team einen neuen Build zur Verfügung stellen. Ein neuer Build bedeutet hier, wenn der Build neue Änderungen von den Entwicklern vorgenommen hat.
• Wenn ein neues Modul zur bestehenden Funktionalität hinzugefügt wird.

Automatisierung & Rauchprüfung:

Normalerweise ist dies die Art von Tests, die ausgeführt wird, bevor tatsächliche Automatisierungstestfälle ausgeführt werden können. Für Unternehmen, in denen Continuous Testing integriert ist, entspricht Smoke Testing der erfolgreichen Installation des Builds zum Ausführen von Testfällen oder der Ausführung des ersten Testfalls. Dies ist also keine Art von Test, die absichtlich automatisiert wird, aber wenn die Testautomatisierung eingeführt wird, kann die Testautomatisierung nur dann erfolgreich ausgeführt werden, wenn die Software die Tests bestanden hat. Andernfalls schlägt der erste ausgeführte Testfall möglicherweise fehl.

Sanity Testing

Sanity Testing ist eine Art Test, der durchgeführt wird, um zu überprüfen, ob ein Softwareprodukt ordnungsgemäß funktioniert, wenn ein neues Modul oder eine neue Funktionalität in ein vorhandenes Produkt implementiert wird. Sanity Testing ist eine Softwaretesttechnik, bei der die Qualität der Softwareversion schnell bewertet wird, um festzustellen, ob sie für weitere Testrunden in Frage kommt oder nicht.

Sanity-Tests werden normalerweise nach Erhalt eines ziemlich stabilen Software-Builds durchgeführt oder manchmal, wenn ein Software-Build geringfügige Änderungen im Code oder in der Funktionalität erfahren hat. Sie entscheidet, ob End-to-End-Tests eines Softwareprodukts weiter durchgeführt werden sollen oder nicht.

Sanity Testing ist auch ein Oberflächentest, der bei der Entscheidung hilft, ob der Software-Build gut genug ist, um ihn an die nächste Teststufe weiterzugeben.

Warum Sanity-Tests durchführen

• Um die Konformität neu hinzugefügter Funktionalitäten und Features in bestehendem Code zu überprüfen und zu validieren.
• Sicherzustellen, dass die eingeführten Änderungen keine Auswirkungen auf andere bestehende Funktionalitäten des Produkts haben.
• Um zu entscheiden, ob weitere Tests durchgeführt werden können oder nicht.

Wann Sanity-Tests durchgeführt werden

• Build wird nach vielen Regressionen empfangen oder wenn sich der Code geringfügig ändert.
• Der Build wird nach der Fehlerbehebung empfangen.
• Kurz vor der Bereitstellung in der Produktion.

Automatisierung & Sanity Testing:

Wenn man bedenkt, dass Sanity-Tests als Teilmenge von Regressionstests betrachtet werden, sind dies die Testfälle, die automatisiert werden können. Ein empfohlener Ansatz besteht darin, diese Testfälle auszuführen, bevor die vollständige Regressionstestsuite ausgeführt wird. Der Vorteil ist, dass bei Fehlern in den Sanity-Testfällen Fehler eher früher als später gemeldet werden können.

Regressionstests

Regressionstests sind die Überprüfung von „Fehlerbehebungen oder Änderungen an der Anforderung“ und stellen sicher, dass sie andere Funktionen der Anwendung nicht beeinträchtigen. Regressionstests sind bei der Automatisierung wirksam und werden normalerweise durchgeführt, nachdem einige Änderungen am Software-Build nach Anforderungsänderungen oder Fehlerbehebungen vorgenommen wurden.

Sobald die Überprüfung der geänderten Funktionalität abgeschlossen ist, müssen alle betroffenen Funktionen der Anwendung vollständig getestet werden. Dies nennt man Regressionstests.

Wenn Fehlerbehebungen in der vorhandenen Software vorgenommen werden, müssen einige Testszenarien ausgeführt werden, um die Fehlerbehebungen zu überprüfen. Darüber hinaus muss das QS-Team die betroffenen Bereiche basierend auf den Codeänderungen überprüfen. Beim Regressionstest müssen alle diese Testszenarien ausgeführt werden, um die damit verbundenen Funktionen zu übernehmen.

Wann Regressionstests durchzuführen sind

• Nach Codeänderung entsprechend den erforderlichen Änderungen
• Nachdem der Anwendung einige neue Funktionen hinzugefügt wurden
• Nachdem einige Fehlerbehebungen in den Build integriert wurden

Automatisierung & Regressionstests:

Regressionstestfälle sind eigentlich die idealen Testfälle für Automaten. Wenn eine Organisation mit der Automatisierung beginnt, sind dies normalerweise die Testfälle, die zuerst automatisiert werden. Wenn Regressionstests eine Aktivität sind, die für Ihre Tester viel Zeit in Anspruch nimmt und dieselben Testfälle mehrmals wiederholt werden, ist es an der Zeit, dass Sie auch über Automatisierung nachdenken.

Wenn Sie nach einem Tool suchen, das Ihnen den Einstieg in Ihre Automatisierungsreise erleichtert, müssen Sie auch sicherstellen, dass Sie das richtige Tool auswählen. Ein Tool, das Ihnen auch einen ROI für die investierten Anstrengungen bietet. Wir haben den Leitfaden, der Ihnen dort helfen kann:

10 Points to Help You Choose the Right Test Automation Tool

Differences Between Smoke vs Sanity vs Regression Testing

Schlüsselpunkte

• Smoke- und Sanity-Tests helfen dem QA-Team, Zeit zu sparen, indem sie schnell testen, ob eine Anwendung ordnungsgemäß funktioniert oder nicht. Außerdem wird sichergestellt, dass das Produkt für weitere Tests geeignet ist. Während Regressionstests dazu beitragen, das Vertrauen in die Softwarequalität nach einer bestimmten Änderung zu erhöhen. Insbesondere, dass die Codeänderungen keine verwandten Bereiche betreffen.

• Smoke-Tests werden sowohl vom Entwicklerteam als auch vom QA-Team durchgeführt und können als Teilmenge strenger Tests angesehen werden. Während beide Sanity & Regressionstests nur vom QA-Team durchgeführt werden. Sanity-Tests können auch als Teilmenge von Akzeptanztests betrachtet werden.

• Smoke-Tests werden in der Anfangsphase von SDLC ausgeführt, um die Kernfunktionalitäten einer Anwendung zu überprüfen. Während Sanity & Regressionstests in der Endphase von SDLC durchgeführt werden, um die Hauptfunktionen einer Anwendung zu überprüfen.

• Gemäß der Anforderung, & Zeitverfügbarkeit zu testen, muss das QA-Team möglicherweise Sanity ausführen und & Regressionstests für ihren Software-Build durchführen. In solchen Fällen werden zuerst Rauchtests ausgeführt, gefolgt von Sanity-Tests & Dann sind basierend auf der Zeitverfügbarkeit Regressionstests geplant.

In der Praxis müssen alle QA-Teams Smoke-, Sanity- und Regressionstests durchführen. Alle diese Testtypen haben eine vordefinierte Anzahl von Testfällen, die mehrmals ausgeführt werden. Diese sich wiederholende Ausführung macht sie auch zu einem idealen Kandidaten für die Testautomatisierung. Wenn Sie nach Automatisierung suchen, wird empfohlen, ein Tool zu verwenden, das Ihnen von Anfang an einen ROI für die Automatisierung bietet. Testsigma ist ein solches Tool.