Good Mood

Entdecken Sie die Unterschiede zwischen Rauchtest und Sanity Testing im Detail mit Beispielen:

In diesem Tutorial werden wir lernen, was ist Sanity Testing und Rauchtest in Software-Tests. Wir werden auch die wichtigsten Unterschiede zwischen Vernunft und Rauchprüfung mit einfachen Beispielen lernen.

Meistens werden wir zwischen der Bedeutung von Gesundheitstests und Rauchtests verwirrt. Zunächst einmal sind diese beiden Tests viel „anders“ und werden in verschiedenen Phasen eines Testzyklus durchgeführt.,

Sanity-Tests

Sanity-Tests werden durchgeführt, wenn als QS-wir nicht genügend Zeit haben, um führen Sie alle Testfälle, sei es, Functional Testing, UI -, Betriebssystem-oder Browser-Tests.

Daher würde ich

„Sanity Testing als Testausführung definieren, die durchgeführt wird, um jede Implementierung und ihre Auswirkungen zu berühren, aber nicht gründlich oder ausführlich, es kann funktional, UI, Version usw. enthalten. testen in Abhängigkeit von der Implementierung und deren Auswirkungen.“

Geraten wir nicht alle in eine Situation, in der wir uns in ein oder zwei Tagen abmelden müssen, aber der Build zum Testen immer noch nicht freigegeben ist?,

Ah ja, ich wette, dass Sie auch diese Situation mindestens einmal in Ihrer Software-Test-Erfahrung konfrontiert haben müssen. Nun, ich sah mich viel damit konfrontiert, weil meine Projekte meistens agil waren und wir manchmal gebeten wurden, sie am selben Tag zu liefern. Hoppla, wie könnte ich den Build innerhalb weniger Stunden testen und freigeben?

Früher bin ich manchmal verrückt geworden, denn selbst wenn es eine kleine Funktionalität wäre, könnte die Implikation enorm sein. Und als Sahnehäubchen weigern sich die Kunden manchmal einfach, zusätzliche Zeit zu geben., Wie könnte ich den gesamten Test in wenigen Stunden abschließen, alle Funktionen und Fehler überprüfen und freigeben?

Die Antwort auf all diese Probleme war sehr einfach, dh nichts anderes als die Verwendung einer Strategie für Gesundheitstests.

Wenn wir dieses Testen für ein Modul oder eine Funktionalität oder ein komplettes System durchführen, werden die Testfälle für die Ausführung so ausgewählt, dass sie alle wichtigen Teile desselben berühren, dh breite, aber flache Tests.

Manchmal wird der Test sogar zufällig ohne Testfälle durchgeführt., Aber denken Sie daran, Sanity Test sollte nur durchgeführt werden, wenn Ihnen die Zeit knapp wird, verwenden Sie dies niemals für Ihre regulären Releases. Theoretisch ist dieser Test eine Teilmenge von Regressionstests.

Meine Erfahrungen

Aus meinem 8 Jahre Karriere in der Software-Tests, 3 Jahre war ich im Agilen Methodik und das war die Zeit, da ich hauptsächlich einen sanity-test.

Alle großen Releases wurden systematisch geplant und ausgeführt, aber manchmal wurden kleine Releases gebeten, so schnell wie möglich ausgeliefert zu werden., Wir hatten nicht viel Zeit, um die Testfälle zu dokumentieren, auszuführen, die Fehlerdokumentation durchzuführen, die Regression durchzuführen und den gesamten Prozess zu verfolgen.

Daher sind die folgenden einige der wichtigsten Hinweise, denen ich in solchen Situationen gefolgt bin:

#1) Setzen Sie sich mit dem Manager und dem Entwicklerteam zusammen, wenn sie die Implementierung diskutieren, weil sie schnell arbeiten müssen und daher können wir nicht erwarten, dass sie uns separat erklären.

Dies würde Ihnen auch helfen, eine Vorstellung davon zu bekommen, was sie implementieren werden, in welchem Bereich sich dies auswirken wird usw.,, dies ist eine sehr wichtige Sache zu tun, da wir manchmal die Implikationen einfach nicht erkennen und wenn eine vorhandene Funktionalität behindert wird (im schlimmsten Fall).

#2) Da Ihnen die Zeit knapp ist, können Sie die Testfälle in Tools wie Evernote usw. grob notieren, wenn das Entwicklungsteam an der Implementierung arbeitet. Stellen Sie jedoch sicher, dass Sie sie irgendwo schreiben, damit Sie sie später zum Testfall-Tool hinzufügen können.,

#3) Halten Sie Ihr Testbett gemäß der Implementierung bereit und wenn Sie der Meinung sind, dass es rote Flaggen wie eine bestimmte Datenerstellung gibt, wenn ein Testbett Zeit braucht (und es ist ein wichtiger Test für die Veröffentlichung), dann heben Sie diese Flags sofort an und informieren Sie Ihren Manager oder PO über die Straßensperre.

Nur weil der Client so schnell wie möglich möchte, bedeutet dies nicht, dass eine Qualitätssicherung freigegeben wird, selbst wenn sie zur Hälfte getestet wird.,

#4) Vereinbaren Sie mit Ihrem Team und Manager, dass Sie die Fehler aufgrund von Time Crunch nur dem Entwicklungsteam mitteilen und der formale Prozess des Hinzufügens und Markierens der Fehler für verschiedene Phasen im Fehlerverfolgungstool später durchgeführt wird, um Zeit zu sparen.

#5) Wenn das Entwicklungsteam am Ende testet, versuchen Sie, sich mit ihnen zu paaren (Dev-QA-Paarung genannt) und eine grundlegende Runde für ihr Setup selbst durchzuführen, um das Hin und Her des Builds zu vermeiden, wenn die Basisimplementierung fehlschlägt.,

#6) Nachdem Sie nun den Build haben, testen Sie zuerst die Geschäftsregeln und alle Anwendungsfälle. Sie können Tests wie eine Validierung eines Feldes, eine Navigation usw. für später beibehalten.

#7) Notieren Sie sich alle Fehler, notieren Sie sie und versuchen Sie, sie gemeinsam den Entwicklern zu melden, anstatt sie einzeln zu melden, da sie leicht an einem Haufen arbeiten können.

#8) Wenn Sie eine Anforderung für die Gesamtleistungstests oder Stress-oder Belastungstests haben, dann stellen Sie sicher, dass Sie ein ordnungsgemäßes Automatisierungsframework für das gleiche haben., Weil es fast unmöglich ist, diese manuell mit einem Vernunfttest zu testen.

#9) Dies ist der wichtigste Teil und in der Tat der letzte Schritt Ihrer Vernunftteststrategie – „Wenn Sie die Release-E-Mail oder das Dokument erstellen, erwähnen Sie alle Testfälle, die Sie ausgeführt haben, die gefundenen Fehler mit einer Statusmarkierung und wenn etwas nicht getestet wurde, erwähnen Sie es mit den Gründen“ Versuchen Sie, eine klare Geschichte über Ihre Tests zu schreiben, die jedem darüber vermittelt, was getestet, verifiziert und was nicht.

Ich habe dies religiös verfolgt, als ich diesen Test benutzte.,

Lassen Sie mich meine eigenen Erfahrungen teilen:

#1) Wir haben an einer Website gearbeitet, auf der Anzeigen basierend auf den Schlüsselwörtern angezeigt wurden. Die Werbetreibenden verwendet, um das Gebot für bestimmte Keywords zu platzieren, die einen Bildschirm für die gleiche entworfen hatte. Der Standardgebotswert wurde früher als $ 0.25 angezeigt, was der Bieter sogar ändern konnte.

Es gab einen weiteren Ort, an dem dieses Standardgebot angezeigt wurde, und es konnte auch in einen anderen Wert geändert werden. Der Client kam mit der Bitte, den Standardwert von $0.25 auf $0.5 zu ändern, aber er erwähnte nur den offensichtlichen Bildschirm.,

Während unserer Brainstorming-Diskussion haben wir vergessen (?) über diesen anderen Bildschirm, weil es nicht viel für, dass Zweck. Aber während ich testete, als ich den Grundfall lief, dass das Gebot $0.5 war und von Ende zu Ende überprüfte, stellte ich fest, dass der Cronjob für dasselbe fehlschlug, weil er an einer Stelle $0.25 fand.

Ich habe dies meinem Team gemeldet und wir haben die Änderung vorgenommen und erfolgreich am selben Tag selbst geliefert.

#2) Unter demselben Projekt (oben erwähnt) wurden wir gebeten, ein kleines Textfeld für Notizen/Kommentare zum Bieten hinzuzufügen., Es war eine sehr einfache Implementierung und wir haben uns verpflichtet, sie noch am selben Tag zu liefern.

Daher habe ich, wie oben erwähnt, alle Geschäftsregeln und Anwendungsfälle getestet und bei einigen Validierungstests festgestellt, dass bei der Eingabe einer Kombination von Sonderzeichen wie </> die Seite abgestürzt ist.

Wir haben darüber nachgedacht und herausgefunden, dass die tatsächlichen Bieter solche Kombinationen auf keinen Fall verwenden werden. Daher haben wir es mit einer gut ausgearbeiteten Notiz zu diesem Thema veröffentlicht., Der Kunde akzeptierte dies als Fehler, stimmte jedoch mit uns überein, ihn später zu implementieren, da es sich um einen schwerwiegenden, aber nicht um einen früheren Fehler handelte.

#3) Kürzlich habe ich an einem mobilen App-Projekt gearbeitet, und wir mussten die in der App angezeigte Lieferzeit gemäß der Zeitzone aktualisieren. Es sollte nicht nur in der App, sondern auch für den Webdienst getestet werden.

Während das Entwicklungsteam an der Implementierung arbeitete, erstellte ich die Automatisierungsskripte für die Webdiensttests und die DB-Skripte zum Ändern der Zeitzone des Lieferelements., Dies ersparte meine Bemühungen und wir konnten innerhalb kurzer Zeit bessere Ergebnisse erzielen.

Sanity Testing Vs Regression Testing

Im Folgenden sind einige Unterschiede zwischen den beiden angegeben:

Strategie Für Mobile App-Tests

Sie müssen sich Fragen, warum ich erwähne speziell über mobile-apps hier?

Der Grund dafür ist, dass OS und Browser-Version für Web – oder Desktop-Anwendungen nicht viel variieren und vor allem die Bildschirmgrößen Standard sind. Bei mobilen Apps beeinflussen jedoch die Bildschirmgröße, das Mobilfunknetz, die Betriebssystemversionen usw. die Stabilität, das Aussehen und kurz gesagt den Erfolg Ihrer mobilen App.,

Daher wird eine Strategieformulierung kritisch, wenn Sie diese Tests in einer mobilen App durchführen, da ein Fehler Sie in große Schwierigkeiten bringen kann. Die Tests müssen intelligent und mit Vorsicht durchgeführt werden.

Im Folgenden finden Sie einige Hinweise, mit denen Sie diesen Test erfolgreich in einer „mobilen App“ durchführen können:

#1) Analysieren Sie zunächst die Auswirkungen der Betriebssystemversion auf die Implementierung mit Ihrem Team.

Versuchen Sie, Antworten auf Fragen wie zu finden, wird das Verhalten in verschiedenen Versionen unterschiedlich sein? Funktioniert die Implementierung mit der niedrigsten unterstützten Version oder nicht?, Wird es Leistungsprobleme bei der Implementierung von Versionen geben? Gibt es eine bestimmte Funktion des Betriebssystems, die sich auf das Verhalten der Implementierung auswirken könnte? etc.

#2) Analysieren Sie in der obigen Anmerkung auch für die Telefonmodelle, dh Gibt es Funktionen des Telefons, die sich auf die Implementierung auswirken? Ist die Implementierung von Verhaltensänderungen mit GPS? Ändert sich das Implementierungsverhalten mit der Kamera des Telefons? etc. Wenn Sie feststellen, dass keine Auswirkungen auftreten, vermeiden Sie Tests an verschiedenen Telefonmodellen.,

#3) Wenn es keine UI-Änderungen für die Implementierung gibt, würde ich empfehlen, UI-Tests auf der geringsten Priorität zu halten, können Sie das Team informieren (wenn Sie möchten), dass UI nicht getestet wird.

#4) Um Zeit zu sparen, vermeiden Sie Tests in guten Netzwerken, da es offensichtlich ist, dass die Implementierung in einem starken Netzwerk wie erwartet funktioniert. Ich würde empfehlen, mit dem Testen in einem 4G-oder 3G-Netzwerk zu beginnen.

#5) Dieser Test soll in kürzerer Zeit durchgeführt werden, aber stellen Sie sicher, dass Sie mindestens einen Feldtest durchführen, es sei denn, es handelt sich um eine bloße Änderung der Benutzeroberfläche.,

#6) Wenn Sie auf eine Matrix verschiedener Betriebssysteme und deren Version testen müssen, würde ich vorschlagen, dass Sie dies auf intelligente Weise tun. Wählen Sie zum Beispiel das niedrigste, mittlere und das neueste OS-Versionspaar zum Testen aus. Sie können im Release-Dokument erwähnen, dass nicht jede Kombination getestet wird.

#7) Verwenden Sie in einer ähnlichen Zeile für den UI-Implementierungstest kleine, mittlere und große Bildschirmgrößen, um Zeit zu sparen. Sie können auch einen Simulator und Emulator verwenden.,

Vorsorgemaßnahmen

Sanity-Test wird durchgeführt, wenn Sie sind läuft die Zeit knapp, und daher ist es nicht möglich, Sie zu führen und jeden Testfall und vor allem, dass man nicht genügend Zeit, um planen Sie Ihren Test. Um die Schuld Spiele zu vermeiden, ist es besser, Vorsichtsmaßnahmen zu ergreifen.

In solchen Fällen mangelt es an schriftlicher Kommunikation, Testdokumentation und Miss-Outs.,

Um sicherzustellen, dass Sie diesem nicht zum Opfer fallen, stellen Sie sicher, dass:

• Niemals einen Build zum Testen akzeptiert, bis Sie keine schriftliche Anforderung erhalten, die vom Client gemeinsam genutzt wird. Es kommt vor, dass Clients Änderungen oder neue Implementierungen verbal oder im Chat oder einem einfachen 1-Liner in einer E-Mail kommunizieren und erwarten, dass wir dies als Anforderung behandeln. Zwingen Sie Ihren Kunden, einige grundlegende Funktionspunkte und Akzeptanzkriterien bereitzustellen.
• Notieren Sie sich Ihre Testfälle und Fehler immer grob, wenn Sie nicht genügend Zeit haben, sie ordentlich zu schreiben. Lassen Sie diese niemals undokumentiert., Wenn es etwas Zeit gibt, teilen Sie es mit Ihrem Lead oder Team, damit es leicht darauf hinweisen kann, wenn etwas fehlt.
• Wenn Sie und Ihr Team zu wenig Zeit haben, stellen Sie sicher, dass die Fehler in einer E-Mail im entsprechenden Zustand markiert sind? Sie können die vollständige Liste der Fehler per E-Mail an das Team senden und die Entwickler dazu bringen, sie entsprechend zu markieren. Halten Sie den Ball immer auf dem Platz des anderen.
• Wenn Sie Automation Framework bereit haben, verwenden Sie das und vermeiden Sie ManualTesting, auf diese Weise können Sie in kürzerer Zeit mehr abdecken.,
• Vermeiden Sie das Szenario „Release in 1 Stunde“, es sei denn, Sie sind 100% sicher, dass Sie liefern können.
• nicht zuletzt, wie oben erwähnt, die dem Entwurf eine detaillierte Freigabe-E-Mail zu kommunizieren, was getestet wird, was übrig ist, Ursachen, Risiken, welche Fehler gelöst sind, welche ‚Latered‘ etc.

Als QA sollten Sie beurteilen, was der wichtigste Teil der Implementierung ist, der getestet werden muss, und welche Teile ausgelassen oder grundlegend getestet werden können.,

Planen Sie auch in kurzer Zeit eine Strategie, wie Sie vorgehen möchten, und Sie können das Beste in dem gegebenen Zeitrahmen erreichen.

Rauchtest

Rauchtest ist kein erschöpfender Test, aber es ist eine Gruppe von Tests, die ausgeführt werden, um zu überprüfen, ob die grundlegenden Funktionalitäten dieses bestimmten Builds wie erwartet funktionieren oder nicht. Dies ist und sollte immer der erste Test sein, der bei jedem „neuen“ Build durchgeführt wird.,

Wenn das Entwicklungsteam einen Build zum Testen an die Qualitätssicherung freigibt, ist es offensichtlich nicht möglich, den gesamten Build zu testen und sofort zu überprüfen, ob eine der Implementierungen Fehler aufweist oder ob eine der Arbeitsfunktionen defekt ist.

Wie stellt eine QA angesichts dessen sicher, dass die grundlegenden Funktionen einwandfrei funktionieren?

Die Antwort darauf wird sein, einen Rauchtest durchzuführen.

Sobald die Tests als Rauchtests markiert sind (in der Testsuite), wird der Build erst dann von der Qualitätssicherung für eingehende Tests und/oder Regressionen akzeptiert., Wenn einer der Rauchtests fehlschlägt, wird der Build abgelehnt und das Entwicklungsteam muss das Problem beheben und einen neuen Build zum Testen freigeben.

Theoretisch wird der Rauchtest als Oberflächen-Level-Test definiert, um zu bestätigen, dass der Build, den das Entwicklungsteam dem QS-Team zur Verfügung stellt, für weitere Tests bereit ist. Diese Tests werden auch vom Entwicklungsteam durchgeführt, bevor der Build an das QS-Team freigegeben wird.

Dieser Test wird normalerweise für Integrationstests, Systemtests und Tests auf Akzeptanzebene verwendet. Behandeln Sie dies niemals als Ersatz für den tatsächlichen End-to-End-Test., Es umfasst sowohl positive als auch negative Tests, abhängig von der Build-Implementierung.

Rauchprüfbeispiele

Diese Prüfung wird normalerweise für Integrations -, Abnahme-und Systemtests verwendet.

In meiner Karriere als QA habe ich einen Build immer erst akzeptiert, nachdem ich einen Rauchtest durchgeführt hatte. Lassen Sie uns also anhand einiger Beispiele verstehen, was ein Rauchtest aus der Perspektive all dieser drei Tests ist.

#1) Abnahmetests

Wenn ein Build an die Qualitätssicherung freigegeben wird, sollte ein Test in Form eines Abnahmetests durchgeführt werden.,

In diesem Test besteht der erste und wichtigste Rauchtest darin, die grundlegende erwartete Funktionalität der Implementierung zu überprüfen. So sollten Sie alle Implementierungen für diesen bestimmten Build überprüfen.

Nehmen wir die folgenden Beispiele als Implementierungen, die in einem Build durchgeführt wurden, um die Rauchtests für diese zu verstehen:

• Hat die Anmeldefunktion implementiert, damit sich die registrierten Treiber erfolgreich anmelden können.
• Implementierte die Dashboard-Funktionalität, um die Routen anzuzeigen, die ein Treiber heute ausführen soll.,
• Implementierte die Funktionalität, um eine entsprechende Meldung anzuzeigen, wenn für einen bestimmten Tag keine Routen vorhanden sind.

Im obigen Build bedeutet der Rauchtest auf Akzeptanzebene, dass die drei grundlegenden Implementierungen einwandfrei funktionieren. Wenn einer dieser drei fehlerhaft ist, sollte die Qualitätssicherung den Build ablehnen.

#2) Integrationstest

Dieser Test wird normalerweise durchgeführt, wenn die einzelnen Module implementiert und getestet werden., Auf Integrationstestebene wird dieser Test durchgeführt, um sicherzustellen, dass alle grundlegenden Integrations-und End-to-End-Funktionalitäten wie erwartet einwandfrei funktionieren.

Es kann die Integration von zwei Modulen oder allen Modulen zusammen sein, daher variiert die Komplexität des Rauchtests je nach Integrationsgrad.

Betrachten wir die folgenden Beispiele für Integrationsimplementierungen für diesen Test:

• Implementierte die Integration von Route-und Stopps-Modulen.
• Implementiert die integration von ankunft status update und spiegeln die gleiche auf die stopps bildschirm.,
• Implementiert die integration von kompletten pick up bis die lieferung funktionalität module.

In diesem Build überprüft der Rauchtest nicht nur diese drei Basisimplementierungen, sondern auch für die dritte Implementierung in einigen Fällen die vollständige Integration. Es hilft sehr, die Probleme herauszufinden, die bei der Integration auftreten, und diejenigen, die vom Entwicklungsteam unbemerkt geblieben sind.

#3) Systemprüfung

Wie der Name schon andeutet, umfasst der Systemtest auf Systemebene Tests für die wichtigsten und am häufigsten verwendeten Workflows des Systems., Dies geschieht erst, nachdem das komplette System bereit ist & getestet wurde, und diese Prüfung auf Systemebene kann auch als Rauchprüfung vor dem Regressionstest bezeichnet werden.

Vor Beginn der Regression des Gesamtsystems werden die grundlegenden End-to-End-Funktionen im Rahmen des Rauchtests getestet. Die Smoke Test Suite für das komplette System umfasst die End-to-End-Testfälle, die die Endbenutzer sehr häufig verwenden werden.

Dies geschieht normalerweise mit Hilfe von Automatisierungstools.,

Bedeutung in der SCRUM-Methodik

Heutzutage folgen die Projekte bei der Projektumsetzung kaum der Wasserfall-Methodik, meist folgen alle Projekte nur Agile und SCRUM. Im Vergleich zur traditionellen Waterfall-Methode hat Smoke Testing einen hohen Stellenwert in SCRUM und Agile.

Ich habe 4 Jahre in SCRUM gearbeitet. Und wie wir wissen, sind die Sprints in SCRUM von kürzerer Dauer und daher ist es äußerst wichtig, diese Tests durchzuführen, damit die fehlgeschlagenen Builds sofort dem Entwicklungsteam gemeldet und behoben werden können.,

Im Folgenden finden Sie einige Informationen zur Bedeutung dieser Tests in SCRUM:

• Aus dem Sprint von vierzehn Tagen wird der QA Halbzeit zugewiesen, aber manchmal verzögern sich die Builds für die QA.
• In Sprints ist es für das Team am besten, dass die Probleme frühzeitig gemeldet werden.
• Jede Geschichte hat eine Reihe von Akzeptanzkriterien, daher ist das Testen der ersten 2-3 Akzeptanzkriterien gleich dem Testen dieser Funktionalität. Kunden lehnen die Lieferung ab, wenn ein einzelnes Kriterium fehlschlägt.,
• Stellen Sie sich vor, was passieren wird, wenn das Entwicklungsteam Ihnen den Build innerhalb von 2 Tagen geliefert hat und nur noch 3 Tage für die Demo übrig sind und Sie auf einen grundlegenden Funktionsausfall stoßen.
• Im Durchschnitt hat ein Sprint Geschichten von 5-10, daher ist es wichtig, wenn der Build angegeben wird, sicherzustellen, dass jede Story wie erwartet implementiert wird, bevor der Build in Tests übernommen wird.
• Wenn das komplette System getestet und regressiert werden soll, ist ein Sprint der Aktivität gewidmet., Zwei Wochen vielleicht etwas weniger, um das gesamte System zu testen, daher ist es sehr wichtig, die grundlegendsten Funktionalitäten zu überprüfen, bevor Sie mit der Regression beginnen.

Smoke Test Vs Build Acceptance Test

Smoke Testing ist direkt Verwandte zu Bauen Acceptance Test (BAT).

In BAT führen wir dieselben Tests durch, um zu überprüfen, ob der Build nicht fehlgeschlagen ist und ob das System einwandfrei funktioniert oder nicht. Manchmal kommt es vor, dass beim Erstellen eines Builds einige Probleme auftreten und der Build beim Bereitstellen nicht für die Qualitätssicherung funktioniert.,

Ich würde sagen, dass BAT Teil einer Rauchprüfung ist, denn wenn das System ausfällt, wie können Sie als QA den Build zum Testen akzeptieren? Nicht nur die Funktionalitäten, das System selbst muss funktionieren, bevor die QS mit eingehenden Tests fortfahren.

Rauchprüfzyklus

Das folgende Flussdiagramm erklärt den Rauchprüfzyklus.

Sobald ein Build in einem QA bereitgestellt wird, besteht der grundlegende Zyklus darin, dass der Build, wenn der Rauchtest bestanden wird, vom QA-Team für weitere Tests akzeptiert wird, aber wenn er fehlschlägt, wird der Build abgelehnt, bis die gemeldeten Probleme behoben sind.,

Prüfzyklus

Wer sollte den Rauchtest durchführen?

Nicht das gesamte Team ist an dieser Art von Tests beteiligt, um die Zeitverschwendung aller QS zu vermeiden.

Rauchtests werden idealerweise vom QS-Lead durchgeführt, der anhand des Ergebnisses entscheidet, ob der Build zum weiteren Testen an das Team übergeben oder abgelehnt werden soll. Oder in Abwesenheit des Leads können die QS selbst diese Tests durchführen.

Manchmal, wenn das Projekt in großem Maßstab ist, kann eine Gruppe von QA diese Tests auch durchführen, um nach Showstoppers zu suchen., Dies ist jedoch bei SCRUM nicht der Fall, da SCRUM eine flache Struktur ohne Leads oder Manager ist und jeder Tester seine eigene Verantwortung gegenüber seinen Geschichten hat.

Daher führen einzelne QS diese Tests für die Geschichten durch, die sie besitzen.

Warum sollten wir Rauchtests automatisieren?

Dieser Test ist der erste Test, der auf einem Build durchgeführt wird, der von den Entwicklungsteams veröffentlicht wurde. Basierend auf den Ergebnissen dieses Tests werden weitere Tests durchgeführt (oder der Build wird abgelehnt).,

Der beste Weg, diese Tests durchzuführen, besteht darin, ein Automatisierungstool zu verwenden und die Smoke Suite so zu planen, dass sie ausgeführt wird, wenn ein neuer Build erstellt wird. Sie denken vielleicht, warum sollte ich „die Rauchtestsuite automatisieren“?

Lassen Sie uns den folgenden Fall betrachten:

Nehmen wir an, Sie sind eine Woche von Ihrer Freilassung entfernt und von den insgesamt 500 Testfällen besteht Ihre Rauchtestsuite aus 80-90. Wenn Sie alle diese 80-90 Testfälle manuell ausführen, stellen Sie sich vor, wie viel Zeit Sie benötigen. Ich denke 4-5 Tage (minimum).,

Wenn Sie jedoch Automatisierung verwenden und Skripte erstellen, um all diese 80-90 Testfälle auszuführen, werden diese idealerweise in 2-3 Stunden ausgeführt und Sie haben die Ergebnisse sofort bei sich. Hat es nicht Ihre kostbare Zeit sparen und geben Ihnen die Ergebnisse über den Build-in viel weniger Zeit?

Vor 5 Jahren habe ich eine Finanzprojektions-App getestet, die Eingaben zu Ihrem Gehalt, Ihren Ersparnissen usw. enthält., und projiziert Ihre Steuern, Ersparnisse, Gewinne in Abhängigkeit von den Finanzregeln. Außerdem hatten wir Anpassungen für Länder, die vom Land und seinen Steuerregeln abhängen, die sich geändert haben (im Code).,

Für dieses Projekt hatte ich 800 Testfälle und 250 Rauchtestfälle. Mit der Verwendung von Selen könnten wir die Ergebnisse dieser 250 Testfälle in 3-4 Stunden leicht automatisieren und abrufen. Es rettete nicht nur unsere Zeit, sondern zeigte uns so schnell wie möglich über die Showstoppers.

Daher, es sei denn, es ist unmöglich zu automatisieren, nehmen Sie die Hilfe der Automatisierung für diese Prüfung.

Vor-und Nachteile

Werfen wir zunächst einen Blick auf die Vorteile, die es im Vergleich zu seinen wenigen Nachteilen viel zu bieten hat.

Vorteile:

• Einfach durchzuführen.
• Reduziert das Risiko.,
• Defekte werden sehr früh erkannt.
• Spart Aufwand, Zeit und Geld.
• Läuft schnell, wenn automatisiert.
• Geringste Integrationsrisiken und-probleme.
• Verbessert die Gesamtqualität des Systems.

Nachteile:

• Diese Prüfung ist nicht gleich oder ein Ersatz für eine vollständige Funktionsprüfung.
• Auch nach dem Rauchtest können Sie Showstopper-Fehler finden.,
• Diese Art von Tests ist am besten geeignet, wenn Sie automatisieren können, sonst wird viel Zeit für die manuelle Ausführung der Testfälle aufgewendet, insbesondere in großen Projekten mit rund 700-800 Testfällen.

Rauchtests sollten auf jeden Fall bei jedem Build durchgeführt werden, da dies auf die schwerwiegenden Fehler und Showstopper in einem sehr frühen Stadium hinweist. Dies gilt nicht nur für neue Funktionalitäten, sondern auch für die Integration von Modulen, Problemlösung und Improvisation. Es ist ein sehr einfacher Prozess durchzuführen und das richtige Ergebnis zu erzielen.,

Diese Prüfung kann als Einstiegspunkt für die vollständige Funktionsprüfung von Funktionalität oder System (als Ganzes) behandelt werden. Aber vorher sollte das QS-Team sehr klar sein, welche Tests als Rauchtests durchgeführt werden sollen. Diese Prüfung kann den Aufwand minimieren, Zeit sparen und die Qualität des Systems verbessern. Es nimmt einen sehr wichtigen Platz in Sprints ein, da die Zeit in Sprints geringer ist.

Dieser Test kann sowohl manuell als auch mit Hilfe von Automatisierungstools durchgeführt werden. Der beste und bevorzugte Weg ist jedoch die Verwendung von Automatisierungstools, um Zeit zu sparen.,

Unterschied zwischen Rauch-und Vernunfttests

Meistens werden wir zwischen der Bedeutung von Vernunfttests und Rauchtests verwirrt. Erstens sind diese beiden Tests viel „unterschiedlich“ und werden in verschiedenen Phasen eines Testzyklus durchgeführt.

Es folgt eine schematische Darstellung ihrer Unterschiede:

SMOKE TESTING

• Dieser Test entstand in der Hardware-Testpraxis, ein neues Stück Hardware zum ersten Mal einzuschalten und es als Erfolg zu betrachten, wenn es nicht Feuer und Rauch fängt. In der Softwareindustrie ist dieses Testen ein flacher und breiter Ansatz, bei dem alle Bereiche der Anwendung getestet werden, ohne zu tief zu geraten.,
• Ein Rauchtest wird entweder mit einem schriftlichen Satz von Tests oder einem automatisierten Test
• Ein Rauchtest wurde entwickelt, um jeden Teil der Anwendung auf flüchtige Weise zu berühren. Es ist flach und breit.
• Dieser Test wird durchgeführt, um sicherzustellen, ob die wichtigsten Funktionen eines Programms funktionieren, ohne sich jedoch um die feineren Details zu kümmern. (Wie build-Verifizierung).
• Dieser Test ist ein normaler Gesundheitscheck für den Build einer Anwendung, bevor er eingehend getestet wird.,

SANITY TESTING

• Ein Sanity Test ist ein enger Regressionstest, der sich auf einen oder mehrere Funktionsbereiche konzentriert. Vernunfttests sind normalerweise eng und tief.
• Dieser Test ist normalerweise nicht verschlüsselt.
• Mit diesem Test wird festgestellt, dass ein kleiner Teil der Anwendung nach einer geringfügigen Änderung noch funktioniert.
• Dieser Test ist ein flüchtiger Test, er wird immer dann durchgeführt, wenn ein flüchtiger Test ausreicht, um nachzuweisen, dass die Anwendung gemäß den Spezifikationen funktioniert. Diese Teststufe ist eine Teilmenge von Regressionstests.,
• Dies ist zu überprüfen, ob die anforderungen erfüllt sind oder nicht, überprüfung aller funktionen breite-erste.