Menü

7-stufige praktische Implementierung manueller Tests vor der Produktionsfreigabe

7 step practical implementation manual testing before production release

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Im vorherigen Beitrag dieser Serie zum manuellen Testen habe ich versucht, die Grundlagen des manuellen Testens so gut wie möglich zu beleuchten.

Wenn Sie es verpasst haben, Sie können es hier lesen .

Ich hoffe, es war erfolgreich, Sie so nah wie möglich an die Antworten zu bringen, nach denen Sie gesucht haben.

Würden Sie in diesem Fall nicht gerne mehr über die praktische Implementierung des manuellen Testens erfahren, wie Sie sich damit vertraut machen und wie Sie tatsächlich eine Karriere darin beginnen können?

Dieser Artikel beleuchtet all diese Aspekte.

Implementierung manueller Tests

Lasst uns beginnen.

Was du lernen wirst:

Manueller Testzyklus

Verstehen Manueller Testzyklus oder Software Test Life Cycle (STLC), zunächst müssen wir den Software Development Life Cycle (SDLC) verstehen, von dem Sie sicher bereits ein Verständnis haben.

Die Leute beziehen sich separat auf sie, sind sich aber nicht sicher, ob sie wirklich nebeneinander existieren können. Sie sind so eng miteinander verbunden. Nun, selbst in diesen Zyklen werden so viele Versionen erstellt und schweben im Internet, dass sie stark davon abhängen, welches Entwicklungsmodell ausgewählt wird.

Wie die meisten der Die Welt wird agil In diesen Tagen werde ich meine Sachen rund um Agile vereinfachen.

7 Praktische manuelle Testschritte vor der Produktionsfreigabe

Hier gehe ich.

Denken Sie daran, ich spreche sowohl von SDLC als auch von STLC.

# 1) Anforderungserfassung

Anforderungserfassungsphase

Business Analyst (Person / Team, das für das Sammeln von Anforderungen verantwortlich ist) dokumentiert die Anforderungen. Sie dokumentieren die Anforderungen, das ist das Highlight. Sie können sich nur darauf konzentrieren. Wo es dokumentiert ist, ist weniger wichtig.

Die Leute verwenden alles, um diese zu dokumentieren, was zu ihnen passt, aber nicht beschränkt auf traditionelle Plattformen wie MS Word Doc, moderne Plattformen wie Jira / Rally und New-Age-Tools wie Trello.

# 2) Anforderungsdiskussion / Teilen

Anforderungsdiskussionsphase

Business Analyst soll dann dokumentierte Anforderungen mit dem Entwicklungsteam, dem Testteam und dem UX-Team teilen (falls erforderlich). Dies geschieht normalerweise über ein formelles Meeting, bei dem SPOCs (Single Point of Contacts oder ein ganzes Team, es kommt darauf an) aus allen drei Funktionen die gesamte Anforderung erfüllen und verstehen.

In einer gesunden Arbeitskultur werden Anforderungen aus jedem Blickwinkel diskutiert und jedes Mitglied des Meetings kann Fragen und Zweifel stellen. Sobald alle Fragen beantwortet und die erforderlichen Änderungen an der Anforderung vorgenommen wurden, kann diese Phase als erledigt betrachtet werden. Wiederum unterscheiden sich das, was man dieses spezielle Meeting / diesen Schritt nennt, und seine Dokumentation von Unternehmen zu Unternehmen.

Weiterführende Literatur=> So überprüfen Sie das SRS-Dokument

Sobald alle Fragen beantwortet und erforderliche Änderungen an der Anforderung vorgenommen wurden, kann diese Phase als betrachtet werden Getan .

Wiederum unterscheiden sich das, was man dieses spezielle Meeting / diesen Schritt nennt, und seine Dokumentation von Unternehmen zu Unternehmen.

Zum Beispiel, Die Dokumentation wird als SRS (System Requirement Specification), Anforderungsdokument, Epic, User Story, Story Point (möglicherweise kleinste Anforderungseinheit) usw. aufgerufen oder aufgeschlüsselt. In ähnlicher Weise wird diese Besprechung, in der die Anforderung geteilt wird, als bezeichnet Anforderungsdiskussionstreffen, Pflege, Lochermeeting usw. Ich hoffe, Sie verstehen meinen Standpunkt?

Drücken Sie auf diese Terminologien, damit Sie sich unabhängig von den verschiedenen Namen immer an die Hauptidee erinnern.

Nach diesem Meeting werden zwei Schritte gleichzeitig ausgelöst, in keiner bestimmten Reihenfolge. Beziehen Sie sich auf die nächsten beiden Schritte.

# 3) Entwerfen

Das Entwicklungsteam beginnt mit der technischen Planung, sobald die Anforderungen besprochen wurden und keine größeren anstehenden Punkte vorliegen. Was in dieser Phase wieder getan wird, ist von Unternehmen zu Unternehmen unterschiedlich.

Diese Phase kann die folgenden Aufgaben umfassen, ist aber nicht darauf beschränkt:

  • Entscheidung über den Entwicklungsansatz
  • Konstruktionsdokument vorbereiten
  • Flussdiagramme entwerfen
  • Schätzung der Anstrengungen
  • Ermittlung der Auswirkungen dieser neuen Anforderung auf vorhandene Funktionen
  • Vorhandene Daten usw. müssen gepatcht werden.

Das UX-Team kann sich auch in diese Phase einmischen, wenn sich die Benutzeroberfläche ändert oder ein neuer Bildschirm entwickelt werden soll. Das UX-Team unterstützt das Entwicklungsteam und das Testteam mit dem UI-Prototyp für die Funktionalität / Funktion in der Diskussion. Dies kann ein Photoshop-Dokument, ein einfaches Bild, eine PowerPoint-Präsentation oder alles andere sein, damit das Entwicklungsteam versteht, wie die Bildschirme entwickelt werden sollen.

Hinweis:: Im Idealfall werden diese Bildschirme oder zumindest ihre Entwurfsversionen nur in der Anforderungsdiskussionssitzung angezeigt, um dem Team ein besseres Verständnis zu ermöglichen. Es wird mit der ursprünglichen Anforderung markiert, sodass jederzeit darauf verwiesen werden kann.

# 4) Entwurf von Testszenarien / Testfällen

Testszenario Entwurfsphase

Parallel zur Entwurfsphase beginnt das Testteam mit der Erstellung von Testszenarien und / oder Testfällen auf der Grundlage der besprochenen Anforderungen. Ob Testszenarien immer zuerst geschrieben werden und dann in Testfälle zerfallen, ist wiederum nicht konstant.

Meiner Meinung nach sind die Testszenarien immer vor Testfällen vorhanden, unabhängig davon, ob Sie sie dokumentieren oder nicht. Das Testszenario ist Ihr Aufzählungspunkt, den Sie sagen können. Sie führen Sie zu weiteren Details. Sobald das Schreiben des Testfalls abgeschlossen ist, kann es mit dem Entwicklungsteam geteilt werden, um ihnen eine Vorstellung vom Testumfang zu geben, und sie können auch sicherstellen, dass die Entwicklung, die stattgefunden hat oder stattfindet, den schriftlichen Testfällen entspricht.

Sobald das Schreiben des Testfalls abgeschlossen ist, kann es mit dem Entwicklungsteam geteilt werden, um ihnen eine Vorstellung vom Testumfang zu geben, und sie können auch sicherstellen, dass die Entwicklung, die stattgefunden hat oder stattfindet, den schriftlichen Testfällen entspricht.

Einmal geschriebene Testfälle werden idealerweise von einem Testleiter oder Kollegen aus verschiedenen Blickwinkeln überprüft:

  • Anforderungsdeckung
  • Rechtschreibgrammatik
  • Standards zum Schreiben von Testfällen (nichts als eine Vorlage, der ein Team / Unternehmen folgt)
  • Rückwärtskompatibilität
  • Plattformkompatibilität
  • Testdatenreferenzen
  • Arten von gezielten Tests usw.

Weiterführende Literatur=> Schreiben von Testfällen aus dem SRS-Dokument

Im Idealfall werden sie erst nach Überprüfung und erforderlichen Änderungen an das Entwicklungsteam weitergeleitet.

Als ich sagte 'Sobald das Schreiben von Testfällen beendet ist', meinte ich einmal 'Alle Testfälle werden basierend auf der vollständigen Kenntnis der gegebenen Anforderungen und möglichen Testszenarien geschrieben, die bis zu diesem bestimmten Zeitpunkt aufgedeckt wurden'. Es ist nahezu unmöglich, auf Anhieb eine 100% ige Abdeckung der Testfälle zu erreichen.

Es wird Fehler geben, die Sie bei zufälligen (aber beabsichtigten) Aktionen, bei rein zufälligen Aktionen (Affentests) und in einigen seltenen Szenarien finden. Es gibt Chancen, die Sie bei einigen davon verpassen werden. Und irgendwann könnten Sie sogar sehr einfache verpassen, schließlich sind Sie ein Mensch. Aber hier können Sie zumindest eine gute Testfallüberprüfung und eine strukturierte Art des Testfallschreibens retten.

Meistens fügt ein Tester oder Testteam dem vorhandenen Block immer mehr Testfälle hinzu, wenn sie die Wahrheit aufdecken oder mehr über die Anforderungen nachdenken.

Nun, jetzt müssen einige von Ihnen an meinen Kenntnissen über Softwaretests zweifeln, da ein Wort (das beim Softwaretest zur Norm geworden ist) von mir noch nicht verwendet wird. Testplan richtig?

Lassen Sie mich etwas dazu sagen. Ich glaube fest an die Notwendigkeit der meisten Informationen, die im Testplan erwähnt werden, aber ich finde es umstritten, sie alle am selben Ort zu dokumentieren und absolut verbindlich zu machen.

Wie auch immer, das ist insgesamt ein separates Thema. Es ist schwierig, Informationen zu allen Anzügen zu teilen, aber lassen Sie mich es versuchen.

Entweder Sie, Sie mit Ihrer Testleitung oder Ihre Testleitung bereiten einen Testplan vor oder Sie dokumentieren die erforderlichen Informationen an verschiedenen Stellen.

Weiterführende Literatur=> So schreiben Sie ein Testplandokument

Informationen, die zu diesem Zeitpunkt unbedingt eingefroren werden sollten:

  • Der Umfang der Tests: Anforderungen, Abwärtskompatibilität, Plattformen, Geräte usw.
  • Person / Team, die testen wird
  • Schätzung des Testaufwands
  • Einschränkungen: Alle im Voraus getroffenen Annahmen oder Einschränkungen.
  • Menschen dokumentieren zusätzlich Eintrittskriterien, Austrittskriterien, Risiken usw., die meiner Meinung nach nicht unbedingt gesondert erwähnt werden müssen, da dies eher ein normales Verständnis sein sollte.
    • Aufnahmekriterien (Wann mit dem Testen begonnen werden soll): Nur wenige beginnen, wenn ein testbarer Teil der Funktionalität zum Testen verfügbar ist. Nur wenige warten darauf, dass die gesamte Funktionalität getestet werden kann. Sobald festgestellt wurde, dass der Grundfluss funktioniert, beginnt der Test.
    • Abbruchkriterium (Wann zu stoppen): Wenn kein Blocker vorhanden ist, können kritische und schwerwiegende (stoßgefährdete) Fehler bei Tests im offenen Stadium gestoppt werden. Oder auf halbem Weg, wenn viel zu viele Fehler auftreten, können die entsprechenden Stakeholder die Tests stoppen.
    • Risiko : Geschäftsrisiko oder Funktionsrisiko, wenn die Tests nicht gemäß dem dokumentierten Plan durchgeführt werden.

# 5) Entwicklungsphase

Softwareentwicklungsphase

Das Entwicklungsteam beginnt nach der Entwurfsphase mit der eigentlichen Entwicklung und dem Testen von Einheiten, sobald die Entwicklung testbarer Anforderungsblöcke abgeschlossen ist. Sie können die Funktionalität zum Testen in Blöcken weitergeben, sobald sie implementiert ist, oder sie können die gesamte Funktionalität auf einmal übergeben.

Im Idealfall werden formale Codeüberprüfungen und White-Box-Tests durchgeführt, bevor die entwickelten Funktionen zum Testen weitergegeben werden. Im Idealfall sollte sich das Entwicklungsteam neben Anforderungen und Konstruktionsdokumenten auch auf vom Testteam bereitgestellte Testfälle beziehen.

# 6) Testphase

Wie bereits erwähnt, unterscheidet sich der Beginn dieser Phase von Unternehmen zu Unternehmen, von Team zu Team.

Das Testteam beginnt mit dem Testen, wenn ein testbarer (etwas, das unabhängig getestet werden kann) Teil der gesamten Anforderung entwickelt wird oder wenn die gesamte Anforderung entwickelt wird.

wie man Eclipse für c verwendet

Lassen Sie mich in dieser Phase einen weiteren Drilldown durchführen und über die wichtigen Aufgaben sprechen:

  • Das Tester- / Testteam beginnt mit der Testrunde (Sondierungstest und Ausführung schriftlicher Testfälle) und der Protokollierung von Fehlern
  • Das Entwicklungsteam löst sie nach Priorität.
  • Ein neuer Build (Code) wird in einer Umgebung erstellt, in der Tests durchgeführt werden
  • Behobene Fehler werden dann vom Tester / Testteam überprüft und als behoben markiert
  • Dieser Zyklus wird fortgesetzt, bis die Zeitaustrittskriterien erreicht sind.
  • Bitte beachten Sie, dass Fehler bei Bedarf auch als ungültig, doppelt gekennzeichnet und auch als Verbesserungen eingestuft werden können.

Eine andere Sache, die von Unternehmen zu Unternehmen unterschiedlich ist, ist die Anzahl der durchzuführenden Testrunden. Wie in einigen Fällen findet die erste Testrunde an kleinen Feature-Teilen statt, sobald diese fertig sind, gefolgt von einer End-to-End-Testrunde in einer anderen Umgebung, sobald alle Anforderungen entwickelt sind. Aber auch hier habe ich von Leuten gehört, die drei richtige vollständige Testrunden und die vierte als Vernunft- / Rauchrunde absolvieren.

Die erste Agenda für mehrere Testrunden ist das Testen der Funktionalität in verschiedenen Umgebungen und die zweite für das Durchführen von End-to-End-Tests, sobald alle Story-Punkte entwickelt sind. Die Vernunftsrunde gewinnt normalerweise schnell an Selbstvertrauen, sobald alle Geschichten in einer Veröffentlichung unabhängig voneinander entwickelt und getestet wurden.

Lesen Sie die detaillierten Schritte=> Testausführungsphase

# 7) Business Analyst (BA) Review

Business Analyst überprüft die angeforderte Funktionalität entweder anhand des Testergebnisses oder anhand des Testergebnisses und des Herumspielens mit der Anwendung, um ein tatsächliches Gefühl zu erhalten. Dieser Schritt ist wiederum unternehmensübergreifend unterschiedlichen Maßnahmen unterworfen.

Die BA kann den Umfang der gesamten Veröffentlichung auf einmal oder in Teilen überprüfen. Abhängig davon kann dieser Schritt vor dem endgültigen Test der geistigen Gesundheit oder nach der letzten Runde der geistigen Gesundheitstests durch das Testteam erfolgen.

Über 7 Schritte werden ausgeführt, damit alle User Stories / Anforderungen erfüllt werden, insbesondere Release (Versand). Sobald alle diese Schritte für alle Anforderungen abgeschlossen sind, gilt die Freigabe als versandbereit.

# 8) Versand / Freigabe

Die Version ist nach erfolgreicher Überprüfung durch den Business Analyst als versandbereit gekennzeichnet.

Empfohlene Lektüre=> Testfreigabeprozess

Arten von manuellen (lesen Sie menschliche) Tests

Nun, wenn wir über allgemeine Arten von Tests in Zahlen sprechen müssen, dann habe ich irgendwo etwas gefunden 100 Arten von Tests mit unterschiedlichen Namen . Um ehrlich zu sein, bin ich nicht klug genug, um die Unterscheidung zwischen all diesen Typen zu verstehen (Wortspiel beabsichtigt).

Es ist klar und einfach: Testen der Funktionalität der Anwendung anhand der gegebenen Anforderungen mit menschlichem Aufwand und Intelligenz. Es wird weiter in einige Typen unterteilt, basierend auf Umfang und Agenda der Tests. Typen, die im nächsten Absatz aufgeführt sind.

Es wird weiter in einige Typen unterteilt, basierend auf Umfang und Agenda der Tests. Typen, die im nächsten Absatz aufgeführt sind.

Wenn ich darf, lassen Sie mich ein paar Zeilen über menschliche Tests sprechen (die ich jedem Tester empfehlen möchte, nur manuelle Funktionstests durchzuführen). Lassen Sie sich jetzt nicht verwirren. Meiner Ansicht nach ist manuelles Funktionstest eine Teilmenge von Human Testing. Weil es so viele Dinge gibt, die nur der menschliche Geist tun kann.

Nachfolgend finden Sie eine Liste mit einigen der beliebtesten und wichtigsten Testtypen, die in Human Testing eingeteilt werden können:

  • Manuelle Funktionsprüfung :: Testen der Funktionalität der Anwendung anhand der gegebenen Anforderungen mit menschlichem Aufwand und Intelligenz. Darüber hinaus werden je nach Umfang und Agenda der Tests einige Typen unterteilt, z. B. Systemtests, Komponententests, Rauchtests, Sanity-Tests, Integrationstests, Regressionstests, UI-Tests usw.
  • Leistungstest :: Dies wird in NonFunctional Testing eingeteilt, oder? Aber es ist wieder der Mensch, der es umsetzt, obwohl die Ausführung entweder durch einen Menschen oder durch ein Werkzeug erfolgt. Der Tester sollte diesen Test zumindest in Bezug auf die Reaktionszeit durchführen (um festzustellen, ob er akzeptabel ist), wenn er kein Werkzeug für Lasttests und alles verwenden soll.
  • Browser / Plattformkompatibilitätstests: Die zu testende Anwendung sollte wie erwartet aussehen und funktionieren (offensichtlich kann es je nach Browser-Engine einen geringfügigen Unterschied geben) zwischen Browsern und Plattformen (oder Geräten, wenn es sich um eine mobile Anwendung handelt).
  • Usability-Tests :: Lassen Sie mich zunächst zustimmen, dass dies ein großes Thema für sich ist und normalerweise Spezialisten für Usability-Tests gehört. Ich glaube immer noch, dass wir als Tester zumindest berichten oder hervorheben sollten, wenn wir etwas als weniger brauchbar empfinden, oder wir sollten unsere Ansicht teilen.
  • Sicherheitstests :: Wieder sehr großer Testtyp und erfordert natürlich viel praktisches Wissen. Der Tester sollte versuchen, mindestens grundlegende Tests wie URL-Manipulationen, Cross-Site-Scripting, SQL-Injection, Sitzungsentführung usw. zu erlernen und auszuführen, je nach verfügbarem Wissen und wo immer zutreffend.
  • Mandantenfähigkeitstests: Wenn Ihre Anwendung mandantenfähig ist, d. H. Eine einzelne Instanz, die Daten mehrerer Clients enthält, ist dieser Test ein Muss. Unabhängig von der ausdrücklichen Erwähnung in den Anforderungen sollte dies erfolgen. Die Daten eines Kunden, die einem anderen Kunden angezeigt werden, sind eine Art Entwicklungs- und Testverbrechen.

Hinweis:: Die obigen Ansichten sind meine persönlichen Ansichten. Ich empfehle Ihnen auch, sich die umfangreiche Liste der Testtypen für Ihr Wissen anzusehen und sie zu befolgen / zu verwenden, wenn Sie dies für erforderlich halten. Über Jahre hinweg habe ich verstanden, dass Sie, ob Sie etwas verwenden oder nicht, an etwas glauben oder nicht, immer noch Kenntnisse über weit verbreitete Konzepte in Ihrem Bereich haben sollten.

Das ist alles für diesen Teil. Danke fürs Lesen. Teilen Sie Ihre Ansichten / Ihr Feedback in Kommentaren mit.

Im nächsten und letzten Teil davon Reihe manueller Test-Tutorials Ich werde versuchen, euch allen zu helfen Welche Vorbereitungen sollten Sie treffen, wenn Sie in das Testfeld einsteigen möchten, und welche Möglichkeiten gibt es, um dorthin zu gelangen?

Literatur-Empfehlungen

^