Sie können sicherlich auf eine Teststrategie verzichten, wenn Sie unendlich viele qualifizierte Mitarbeiter, Zeit und Geld haben. Mit einem Wort, die Fähigkeit, eine Veröffentlichung im Laufe der Jahre zu kürzen. Unter solch hypothetischen Idealbedingungen ist keine Strategie erforderlich, da Sie Ihr Produkt auf alle vorhandenen Arten so lange testen können, wie Sie möchten, indem Sie die Techniken in beliebiger Reihenfolge für mehrere Kreise anwenden und früher oder später auf irgendeine Weise zu einer produktionsfertigen Qualität gelangen.

In der Realität verbrennt das Projekt immer die Frist, die Arbeitsfähigkeit / Fähigkeiten des Teams sind nicht aus Gummi und die Produktanforderungen entwickeln sich ständig weiter - und hier kann man nicht auf einen guten Plan verzichten. Daher kommt eine Teststrategie zur Rettung.

In diesem Artikel werden wir Fragen stellen, die diskutiert werden müssen, um eine Teststrategie zu erstellen, und anhand von Beispielen zeigen, wie Entscheidungen über Testwerkzeuge in einem bestimmten Fall getroffen werden.

0. Lass es uns am Ufer herausfinden

Warum brauchen wir eine Teststrategie?

• Organisation des Prozesses unter Bedingungen begrenzter Ressourcen. Daher wäre es zunächst schön zu erkennen, über welche Ressourcen wir verfügen.
• Damit alle Projektteilnehmer die Rolle des Testens verstehen, was es geben kann, welche Gewinne wir daraus ziehen werden. Damit jeder die gleichen Erwartungen und das gleiche Verständnis dafür hat, was im Bereich der Qualitätskontrolle geschieht. Und auch um mögliche Probleme zu identifizieren, die im Diskussionsprozess unvermeidlich werden.

Wer macht die Strategie aus?

Zuallererst natürlich QS und unbedingt ein Projektmanager.

Nehmen Sie also den Tester-Projektmanager oder Tester-Manager bei der Hand, gießen Sie Kaffee ein, nehmen Sie Papier, Marker, Laptops und ... los geht's!

1. Welche Arten von Tests werden wir für das Projekt verwenden und warum

Zu Beginn bieten wir an, alle vorhandenen Testarten abzurufen und zu entscheiden: Werden wir sie verwenden und warum? Schauen wir uns einige Beispiele an, wie Sie entscheiden können, ob eine bestimmte Art von Test erforderlich ist.

Testen der Versionsinstallation

Selbst wenn die Anwendung vollständig neu ist und zum ersten Mal installiert (bereitgestellt) wird, müssen Sie auf jeden Fall überprüfen, wie sie gestartet wurde: ob sie startet, ob es möglich ist, mit ihr zu arbeiten. Ob es sich um eine mobile Anwendung, einen Desktop oder ein Web handelt.

Für Webanwendungen ist es hilfreich zu diskutieren, wie wir überprüfen, ob die Daten nach dem Update nicht verloren gehen. Welche Art von Verhalten erwarten wir von einer aktiven Sitzung?

Für Desktop- und mobile Anwendungen müssen Sie sich überlegen, wie Sie die neue Distribution an den Benutzer und den vom Benutzer gestarteten Aktualisierungsprozess bereitstellen können.

Für alle Projekte ist es hilfreich, Dinge wie das Aufwärmen des Systems zu besprechen: Verzeichnisse installieren, Benutzer einrichten und andere Daten, die der Benutzer benötigt, um mit dem System zu beginnen.

Leistungstests

Solche Faktoren beeinflussen die Entscheidung: Wie viele Benutzer werden im System arbeiten, wie viele Daten werden verarbeitet.

Gegeben	Lösung
Wir wissen, dass 10 Personen das Produkt verwenden werden. Und wir wissen, dass sie Tabellen mit mehreren tausend Datensätzen übergeben werden.	Es ist sinnvoll, Volumentests mit großen Datenmengen zu planen.
Wir wissen, dass Benutzer bei der Verwendung des Produkts viele Mediendateien auf den Server des Kunden hochladen.	Sie müssen herausfinden, für welche Art von Last dieser Server ausgelegt ist, und diese Daten berücksichtigen.
Die Anwendung wird von mehreren Personen pro Woche verwendet, die Datenmenge ist minimal.	Leistungstests sind nicht erforderlich.

Regressionstests

Eine vollständige Überprüfung des gesamten Systems nimmt immer viel Zeit in Anspruch. Um eine Entscheidung zu treffen, ist es daher erforderlich, die Angemessenheit zu bewerten: Wie viel Zeit ist für eine vollständige Regression erforderlich und welche Risiken können auftreten, wenn wir sie nicht durchführen.

Gegeben	Lösung
Wir führen die erste Version eines Produkt- oder Programmmoduls ein.	Regressionstests sind nicht erforderlich.
Das Projekt ist sehr umfangreich und eine vollständige Regression vor der Veröffentlichung neuer Funktionen erfordert Zeit, die mit der Entwicklungsperiode vergleichbar ist. Die erforderliche Lieferrate erlaubt dies nicht.	Wir beschließen, keine Regressionstests durchzuführen, sondern anderen Arten von Tests und Überwachung mehr Aufmerksamkeit zu schenken.
Die Wechselwirkung zwischen Microservices wird durch Vertragstests abgedeckt.	Eine vollständige Regression ist unpraktisch. Im Rahmen des manuellen Testens führen wir auf Empfehlung des Entwicklers eine Regression der Funktionalität durch.

Integrationstests

Um festzustellen, ob Integrationstests erforderlich sind, ist es hilfreich, alle externen Systeme aufzulisten, mit denen das Produkt interagiert, und anzugeben, welche Daten wir empfangen und senden.

Gegeben	Lösung
Verkaufsdaten aus dem Portal werden an das Analysesystem übertragen.	Es ist wichtig, nicht nur zu überprüfen, ob Verkäufe im richtigen Format eingegangen sind, sondern auch, dass sie im richtigen Format eingegangen sind - dabei ging nichts verloren.

Lokalisierungstests

Es ist wichtig, Fragen zum Projekt zu beantworten:

• Welche Sprachen sollen unterstützt werden?
• Sorgen wir für den Anschluss zusätzlicher Standorte während des Betriebs der Lösung?
• In welchen Ländern werden unsere Benutzer arbeiten?
• Wird es Verkäufe geben und in welchen Währungen?
• Müssen Sie mit Zeitzonen arbeiten?

Gegeben	Lösung
Das System hat 2 Sprachen: Russisch und Englisch.	Es ist sinnvoll zu diskutieren, wie wir die Benutzeroberfläche verstehen, in welcher Sprache der Benutzer angezeigt werden soll.
Der Kunde bittet darum, die Anwendung mehrsprachig zu gestalten.	Es lohnt sich, sich die Fragen zu beantworten, wie wir die Texte überprüfen, woher wir die Texte auf Arabisch beziehen und wie der Bildschirm für den von rechts nach links geschriebenen Text angepasst wird.

Browser- und plattformübergreifend

Wir können den korrekten Betrieb der mobilen Anwendung nicht auf allen Geräten im Allgemeinen überprüfen. Bei einer Webanwendung stellt sich sofort die Frage: Werden wir IE9 unterstützen? Bevor wir diese Art von Tests in die Strategie eingeben, analysieren wir (wenn die Lösung bereits funktioniert) oder nehmen an (falls sie noch nicht funktioniert), wofür sie verwendet wird.

Gegeben	Lösung
Benutzer mobiler Apps sind Mitarbeiter im ganzen Land.	Wir sehen uns die vorhandenen Statistiken zur Nutzung der Plattformen unserer Anwendung an und treffen eine Entscheidung, welche davon wir testen werden.
Unsere Anwendung hat Firmenbenutzer auf stationären Maschinen.	Wir können höchstwahrscheinlich empfehlen, nur einen Browser zu verwenden. Dadurch wird die Zeit für Tests und die Unterstützung der Cross-Browser-Kompatibilität verkürzt.

Ebenso müssen Sie alle anderen Testarten analysieren:

• Funktionell (durchgeführt oder nicht),
• Akzeptanz (wer leitet es und wie),
• UX / UI (was sind die objektiven Kriterien für eine gute Schnittstelle)
• Modular und Unit (wer schreibt Vertragstests, wer schreibt Unit-Tests und ob wir sie überhaupt schreiben),
• Sicherheitstests (wer garantiert Datensicherheit und wie widerstandsfähig das System gegen Hacking ist),
• Ausfall und Wiederherstellung (wie sich das System im Notfall verhält)

und andere.

2. Prioritäten beim Testen

Höhere Gewalt tritt bei allen Projekten auf. In diesem Fall ist es daher nützlich, einen Spickzettel mit einem gut durchdachten Plan zu haben, anstatt nach zufälligen Schaltflächen zu greifen.



Im normalen Modus sind auch sinnvolle Prioritäten wichtig. Beispielsweise sollte die Entwicklung von Autotests unter Berücksichtigung der Prioritäten geplant werden: Zunächst werden die kritischsten Szenarien automatisiert (Rauchtests).

Gegeben	Lösung
Unser Programm wird an Flughäfen verwendet, um Dienstleistungen an Passagiere beim Einsteigen in ein Flugzeug zu verkaufen. Und wenn in diesem Moment ein Fehler auftritt, haben wir keine Zeit für eine Hotfix. Daher sollte es keine Fehler geben!	Wir überprüfen zunächst das Nutzungsszenario am Flughafen.

3. Arbeitsumgebung

Es ist notwendig, mit dem Team zu überlegen und zu koordinieren, welche Umgebungen für die Arbeit erforderlich sind und wer sie verwenden wird. In der Regel reichen 2-3 Umgebungen und Verkäufe aus.

Gegeben	Lösung
Auf dem CD / CI-Projekt wurden Rauchtests zum ersten Testen der Funktionalität geschrieben.	Wir brauchen eine Umgebung für die primäre Zusammenstellung von Code in einem Zweig, die Durchführung von Rauchtests, in denen externe Systeme durch Stubs geschlossen werden. Sie benötigen außerdem eine Umgebung für manuelle Tests und Integrationstests mit dem Kundendienst (QS).
Beta-Testsitzungen finden regelmäßig statt.	Wir brauchen eine Umgebung, die "außen" sichtbar ist und stabiler als die QS-Umgebung.

4. Die Arbeit des Testers am Projekt

Es ist sinnvoll, alle Aktivitäten, die wir vom Tester für das Projekt erwarten, im Voraus zu besprechen, da sie nicht unbedingt für alle Projekte gleich sind. Es könnte jemanden im Team überraschen, dass der Tester etwas tut oder etwas nicht tut.

Dieser Punkt hilft Managern zu verstehen, welcher Grad an Kompetenz vom Tester benötigt wird und welche Zeitbelastung erwartet wird. Bei bestehenden Projekten ist es auch wichtig anzugeben, dass wir (QS) in der Lage sind, damit der Manager versteht, was er bedeutet.

Zum Beispiel könnte es sein:

• Bewertung der Sprintziele auf Vollständigkeit und Konsistenz,
• Bewertung der Arbeitskosten für Tests,
• Erstellung von Checklisten für Tests (oder Testfälle),
• Autotest-Skriptüberprüfung
• funktionale Autotests schreiben,
• direkte manuelle Prüfung,
• Bereitstellung von Änderungen an der Umgebung,
• Aktualisieren von Teststrategien usw.

5. Testdokumentation zum Projekt

Es ist notwendig, sich am Ufer zu einigen und möglicherweise das Format der Testdokumentation weiter und regelmäßig zu überprüfen:

• Welche Testdokumentation werden wir für das Projekt durchführen?
• werden wir Testfälle schreiben
• Checklisten machen
• und wie oft diese Dokumentation aktualisiert werden muss.

Gegeben	Lösung
Etwa 300 Testfälle wurden bereits für etwa ein Drittel der Systemfunktionalität geschrieben. Sie müssen nicht nur regelmäßig überprüft, sondern auch von Zeit zu Zeit aktualisiert werden.	Unter Bedingungen begrenzter Ressourcen haben wir beschlossen, nicht mit Testfällen zu arbeiten, sondern uns darauf zu beschränken, Checklisten für jede bestimmte Aufgabe zu erstellen. Dadurch sparen wir Zeit bei der Unterstützung der Dokumentation, ohne die Qualität der Tests zu verlieren.

6. Wie Testfälle generiert werden

Die Betriebsbedingungen und -szenarien hängen von der jeweiligen Lösung ab. Besprechen Sie daher Folgendes:

• Welche Testdesign-Techniken sind sinnvoll? Als Teil dieses Absatzes ist es hilfreich, eine Liste der Objekte, mit denen die Anwendung arbeitet, und ihrer Äquivalenzklassen zu erstellen.
• Welche Heuristiken und banalen Lebenserfahrungen helfen, Testskripte für ein bestimmtes Projekt zu erstellen. Für mobile Anwendungen ist es bequem, Standardheuristiken zu verwenden, z. B. „I SLICED UP FUN“.

Gegeben	Lösung
Während des Versicherungsprojekts muss der Benutzer (Agent) die Maschine inspizieren. Während dieser Zeit müssen Fotos aufgenommen und auf den Server hochgeladen werden. Der gesunde Menschenverstand schreibt vor, dass es in Garagen kaum WLAN gibt. Und manchmal gibt es keine mobile Verbindung.	Sie müssen die Anwendung also nicht nur überprüfen, wenn Sie mit 3G arbeiten, sondern auch, wenn keine Kommunikation als solche vorliegt.
Jede Benutzeraktion in der mobilen Anwendung der Fluggesellschaft ist Teil eines Szenarios. Sie können beispielsweise kein Ticket ausstellen, ohne zuvor eine Reservierung erstellt zu haben.	Daher ist es logisch, die "Anwendungsfall" -Technik zu verwenden.

7. Das Verfahren zum Arbeiten mit dem Tracker

In verschiedenen Trackern unterscheiden sich die Möglichkeiten und Arten von Aufgaben. Basierend auf den Funktionen des Trackers empfehlen wir Ihnen, zu vereinbaren, wer und nach welchem ​​Prinzip die Priorität von Aufgaben bestimmt, in welcher Art von Aufgaben Fehler und Aufgaben angeordnet werden sollen.

Sprechen Sie mit dem Team über die wichtigsten Punkte:

• Wie werden wir zwischen von uns gefundenen Fehlern und von Kunden gefundenen Fehlern unterscheiden (und ob wir zwischen ihnen unterscheiden müssen)?
• Wie man Verbesserungen vornimmt
• Ist es notwendig, die Verbesserungen, die wir selbst erfunden haben, von denen zu unterscheiden, die der Kunde angefordert hat? Auf welche Weise?
• In welchem ​​Status sollte ein Fehler gemacht werden, wenn er nicht erneut auftritt?
• Welcher Status gilt als endgültig?

Gegeben	Lösung
Der Tester erstellt einen Fehler. Der Entwickler kann es nicht reproduzieren und übersetzt es in den abgelehnten Status.	Der Tester überprüft die Aufgabe erneut und setzt den Status auf Geschlossen (endgültig), wenn der Fehler wirklich behoben ist, oder verfeinert die Beschreibung und kehrt zu Neu zurück.
Der Kunde legt die Aufgabe zur Überarbeitung fest. Der Entwickler versteht, dass er nicht über genügend Daten verfügt, um diese zu implementieren.	Der Entwickler versetzt die Aufgabe in den Status "Feedback".

(Wir haben in diesem Artikel mehr über Möglichkeiten zur Beschreibung von Fehlern und Benutzergeschichten geschrieben.)

8. Kriterien zum Starten und Beenden des Tests

Wenn der Tester zu irgendeinem Zeitpunkt eine Aufgabe übernimmt, ist dies keine Ordnung, sondern Chaos. Weil die Aufgabe möglicherweise nicht bereit ist. Oder bereit, aber nicht kostenlos. Oder bereit, bereitgestellt, hängt jedoch von anderen Aufgaben ab, die noch nicht bereit sind. Infolgedessen verbringt der Tester viel Zeit und Nerven damit, Fehler zu suchen und zu beheben, aber tatsächlich müssen Sie nur warten. Daher sind wir uns einig, an welchem ​​Punkt der QS-Verantwortungsbereich für die Aufgabe beginnt und endet.

In den frühen Phasen der Projektentwicklung wird die Bereitschaft der Aufgabe / Version durch das Auge bestimmt.
Mit dem Wachstum des Selbstbewusstseins verstehen wir, dass wir klare Kriterien benötigen, damit die Aufgabe / Version bereit ist. Damit diese Entscheidung für alle transparent ist und nicht "der Tester die Beute spürt, dass alles normal ist". Im Zusammenhang mit einer optimierten CD glauben wir beispielsweise, dass die Aufgabe zum Testen bereit ist, sobald sie in der QS-Umgebung bereitgestellt wird und den Status "Gelöst" hat.

Gegeben	Lösung
Für das Projekt wurde ein Prozess eingerichtet, bei dem für jede Revision eine Checkliste zum Testen erstellt wird.	Wir betrachten die Aufgabe als verifiziert, wenn wir alle Punkte auf der Checkliste bestanden haben.
Das Projekt arbeitet an Sprints.	Sprint gilt als bereit, wenn sich alle Verbesserungen im Status "Geschlossen" befinden und keine Fehler mit der Priorität "Normal" und höher vorliegen.
Das Projekt hat eine Liste der Funktionen nach Priorität erstellt.	Wir glauben, dass die Version zur Veröffentlichung bereit ist, wenn die Funktionalität aus den ersten Punkten der Liste erfolgreich funktioniert.
Das Projekt hat Testfälle geschrieben und vor der Veröffentlichung Regressionstests durchgeführt.	Eine Version gilt als zur Veröffentlichung bereit, wenn basierend auf den Ergebnissen der Regressionstests keine Fehler mit der Priorität Normal oder höher gefunden wurden (oder der Prozentsatz nicht erfolgreicher Szenarien nicht höher als 5 war).

9. Werkzeuge für die Arbeit

Der Abschnitt ist dann nützlich, um die verantwortlichen Aufgaben (gegenüber dem Administrator und dem Manager) bereits in der Testplanungsphase festzulegen und zu Beginn der Arbeit alle erforderlichen Tools zu erhalten.

Es lohnt sich, solche Themen zu diskutieren:

• Welche Tools benötigen wir für die Durchführung der Testdokumentation?
• Welche Tools können Testdaten aufbereiten?
• Welche Tools werden für die Automatisierung benötigt?

Gegeben	Lösung
Um die implementierte Funktionalität zu beschreiben, haben wir uns für Mind-Maps entschieden.	Die Mitarbeiter des Teams arbeiten auf verschiedenen Plattformen. Sie müssen daher ein Mind-Map-Dateiformat auswählen, mit dem Sie unter Windows, Linux und Mac arbeiten können.
Wir waren uns einig, dass wir das Projekt automatisieren müssen.	Wir benötigen also Tools, mit denen wir Testdaten vorbereiten (z. B. Skripte in die Datenbank rollen), innerhalb der Pipeline starten (z. B. newman) und Stubs erstellen können (z. B. WireMock).

10. Tools zur Bewertung und Überwachung der Projektqualität

In diesem Abschnitt schlagen wir vor, zu vereinbaren, welche KPIs für die Beurteilung des Zustands der Anwendung gelten (zusätzlich zur offensichtlichen Berechnung der Testabdeckung). Dieser Indikator sollte messbar und erreichbar sein. Verstehen und beantworten Sie insbesondere die folgenden Fragen:

• Wie wir Fehler im Produkt verfolgen
• Wie werden wir Feedback von Benutzern sammeln?
• Wie werden wir Statistiken über die Nutzung unserer Funktionen sammeln?

Gegeben	Lösung
Nach der Freigabe einer neuen Funktion des Systems wird die Nutzungsüberwachung konfiguriert (z. B. die Anzahl der Serviceverkäufe).	Der Rückgang ist ein Auslöser für die Untersuchung. Möglicherweise funktioniert die Funktion nicht wie erwartet, oder wir haben einen Teil des Skripts nicht implementiert.
Wir haben das Programm so konfiguriert, dass die Geschwindigkeit der Ausführung grundlegender Vorgänge überwacht wird.	Das Kriterium für die Qualität der Arbeit wird sein, dass bei einem Zustrom von Benutzern die Ausführungsgeschwindigkeit nicht abnimmt.

Fazit

Eine einheitliche und universelle Teststrategie, die für alle geeignet ist, gibt es nicht. Es ist für jedes Projekt individuell gestaltet.

• Es ist wichtig zu verstehen, dass Strategie kein Selbstzweck sein sollte - sie ist nur ein Werkzeug, mit dem wir unsere Ziele erreichen können.
• Es ist ganz normal, dass es nicht immer möglich ist, alle gestellten Fragen sofort zu beantworten. Dies ist eine Gelegenheit, erneut mit dem Kunden oder den Benutzern des Produkts zu sprechen.
• Das Projekt wächst und wenn es gestern zu früh war, um sich um die Produktivität zu kümmern, dann wird es wahrscheinlich morgen Zeit sein. Daher ist es nach der Erstellung einer Strategie wichtig, diese regelmäßig zu aktualisieren und aufzufüllen und Änderungen im Team vorzunehmen.
• Nach dem Schreiben einer Strategie wird normalerweise klar, wo die Fehler beim Testen liegen und was zu tun ist. Dies ist eine Gelegenheit, Ziele zu setzen, die Dynamik zu beobachten und ... die Strategie nach einiger Zeit zu aktualisieren.