So erstellen Sie eine Teststrategie: Die Version echter Ingenieure

  • Tutorial
Ohne eine Teststrategie können Sie sicherlich tun, wenn es unendlich viele qualifizierte Mitarbeiter gibt, Zeit und Geld. Kurz gesagt, die Fähigkeit, eine Veröffentlichung über die Jahre hinweg zu schneiden. Unter diesen hypothetischen idealen Bedingungen ist keine Strategie erforderlich, da Sie Ihr Produkt mit allen vorhandenen Methoden so lange testen können, wie Sie möchten, und zwar in beliebiger Reihenfolge, über mehrere Runden hinweg, und früher oder später werden Sie auf irgendeine Weise zur serienreifen Qualität kommen.

In der Realität verbrennt das Projekt immer die Deadline, die Arbeits- und Fertigkeiten des Teams sind nicht von Belang, und die Produktanforderungen werden ständig weiterentwickelt - und dies ist ohne einen guten Plan nicht möglich. Daher kommt eine Teststrategie zur Rettung.

In diesem Artikel bieten wir Fragen an, die diskutiert werden müssen, um eine Teststrategie auszuarbeiten, und wir zeigen anhand von Beispielen, wie Entscheidungen zu Testwerkzeugen in einem bestimmten Fall getroffen werden.



0. Wir werden am Ufer verstehen


Warum brauchen Sie eine Teststrategie?

  • Für die Organisation des Prozesses unter begrenzten Ressourcen. Daher wäre es zunächst einmal schön zu wissen, welche Ressourcen wir haben.
  • Damit alle Projektbeteiligten die Rolle des Testens verstehen, was er geben kann und welche Gewinne wir daraus ziehen. Damit hat jeder die gleichen Erwartungen und das gleiche Verständnis davon, was in der Qualitätskontrolle geschieht. Und auch um mögliche Probleme zu identifizieren, die im Diskussionsprozess unweigerlich sichtbar werden.

Wer macht die Strategie?

In erster Linie natürlich QS und unbedingt der Projektmanager.

Nehmen Sie also den Projektmanager des Testers oder den Tester - Manager bei der Hand, gießen Sie den 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


Wir schlagen vor, alle bestehenden Testarten abzurufen und zu entscheiden: Ob und warum? Sehen wir uns einige Beispiele an, wie Sie entscheiden können, ob eine bestimmte Art von Tests erforderlich ist.

Testen Sie die Installationsversion


In jedem Fall müssen Sie, selbst wenn die Anwendung vollständig neu ist und zum ersten Mal installiert (bereitgestellt) wird, prüfen, wie die Anwendung gestartet wurde: ob sie startet und ob Sie damit arbeiten können. Sei es eine mobile Anwendung, ein Desktop oder ein Web.

Für Webanwendungen ist es hilfreich zu besprechen, wie wir sicherstellen, dass die Daten nach der Aktualisierung nicht verloren gehen. Welches Verhalten erwarten wir von einer aktiven Sitzung?

Bei Desktop- und mobilen Anwendungen müssen Sie darüber nachdenken, wie Sie die neue Verteilung an den Benutzer übermitteln und den Aktualisierungsprozess, den der Benutzer startet.

Für alle Projekte ist es hilfreich, solche 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.

Leistungstest


Die Entscheidung wird von solchen Faktoren beeinflusst: wie viele Benutzer werden im System arbeiten, wie viele Daten verarbeitet werden.
GegebenLösung
Wir wissen, dass das Produkt von 10 Personen verwendet wird. Und wir wissen, dass sie Tabellen mit mehreren tausend Datensätzen rollen 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. Es ist notwendig, herauszufinden, für welche Last dieser Server ausgelegt ist, und um diese Daten zu berücksichtigen.
Die Anwendung wird von mehreren Personen pro Woche verwendet, die Datenmenge ist minimal. Leistungstests sind erforderlich.

Regressionstest


Eine vollständige Überprüfung des gesamten Systems erfordert immer viel Zeit. Um eine Entscheidung zu treffen, muss daher die Zweckmäßigkeit beurteilt werden: Wie viel Zeit ist für eine vollständige Regression erforderlich und welche Risiken entstehen können, wenn wir sie nicht ausgeben.
GegebenLösung
Wir rollen die erste Version des Produkts oder Moduls des Programms aus. Regressionstests sind nicht erforderlich.
Das Projekt ist sehr umfangreich und es dauert einige Zeit, bis eine Reihe von Regressionen abgeschlossen ist, bevor neue Funktionen veröffentlicht werden, die mit dem Entwicklungszeitraum vergleichbar sind. Die erforderliche Versorgungsrate lässt dies nicht zu.Wir entscheiden, dass Regressionstests nicht durchgeführt werden, aber andere Arten von Tests und Überwachung werden stärker berücksichtigt.
Die Interaktion zwischen Microservices wird durch Vertragstests abgedeckt. Eine vollständige Regression durchzuführen ist unangemessen. Im Rahmen des manuellen Tests führen wir eine Regression der Funktionalität durch, wie vom Entwickler empfohlen.

Integrationstest


Um den Bedarf an Integrationstests zu ermitteln, ist es nützlich, alle externen Systeme aufzulisten, mit denen das Produkt interagiert, und anzugeben, welche Daten wir empfangen und senden.
GegebenLösung
Verkaufsdaten aus dem Portal werden an das Analysesystem übermittelt. Es ist wichtig, nicht nur zu überprüfen, ob die Verkäufe im richtigen Format verschwunden sind, sondern auch, dass das richtige Format angegeben wurde - nichts ging dabei verloren.

Lokalisierungstest


Hier ist es wichtig, Fragen zum Projekt zu beantworten:
  • welche sprachen sollen unterstützt werden
  • sorgen wir für die Anbindung weiterer Lokalisierungen während des Betriebs der Lösung
  • in welchen Ländern werden unsere Nutzer arbeiten,
  • ob es Verkäufe gibt und in welchen Währungen
  • Ob mit Zeitzonen gearbeitet werden muss.

GegebenLösung
Das System bietet zwei Sprachen: Russisch und Englisch. Es ist sinnvoll zu diskutieren, wie wir die Benutzeroberfläche in welcher Sprache verstehen.
Der Kunde verlangt, die Anwendung mehrsprachig zu gestalten. Es lohnt sich, die Fragen zu beantworten, wie wir die Texte überprüfen, woher wir die Texte auf Arabisch bekommen, wie der Bildschirm für den von rechts nach links geschriebenen Text angepasst wird.

Browserübergreifend und plattformübergreifend


Die Korrektheit der mobilen Anwendung kann nicht generell auf allen Geräten überprüft werden. Bei einer Webanwendung stellt sich sofort die Frage: Unterstützen wir IE9? Bevor diese Art von Tests in die Strategie geschrieben wird, analysieren wir (wenn die Lösung bereits funktioniert) oder wir gehen davon aus (wenn sie noch nicht funktioniert), was sie verwenden werden.

GegebenLösung
Benutzer der mobilen App sind Mitarbeiter im ganzen Land. Wir schauen uns die vorhandenen Statistiken über die Nutzung der Plattformen unserer Anwendung an und entscheiden, welche davon getestet wird.
Unsere Anwendung hat Firmenbenutzer auf stationären Maschinen.Wahrscheinlich können wir die Verwendung nur eines Browsers empfehlen. Und reduzieren Sie dadurch die Test- und Supportzeit für Cross-Browser-Kompatibilität.


Ebenso ist es notwendig, alle anderen Testarten zu zerlegen:
  • Funktional (wir führen oder nicht),
  • Akzeptanz (wer führt sie durch und wie)
  • UX / UI (Was sind die objektiven Kriterien für eine gute Schnittstelle)
  • Modular und unit (wer schreibt die Vertragstests, wer schreibt die Unit-Tests und ob wir sie überhaupt schreiben),
  • Sicherheitstests (wer gewährleistet die Datensicherheit und wie widerstandsfähig das System gegen Cracken ist)
  • Fehler und Wiederherstellung (wie sich das System in Notfallsituationen verhält)

und andere.

2. Prioritäten beim Testen


Bei allen Projekten kommt es zu höherer Gewalt, daher ist es in einem solchen Fall sinnvoll, ein Spickzettel mit einem vorsätzlichen Plan zu haben, anstatt nach zufälligen Schaltflächen zu greifen.



Im normalen Modus sind aussagekräftige Prioritäten ebenfalls wichtig. Beispielsweise sollte die Entwicklung von Autotests unter Berücksichtigung der Prioritäten geplant werden: Zunächst wird die Überprüfung der kritischsten Szenarien (Rauchprüfung) automatisiert.

GegebenLösung
Unser Programm wird an Flughäfen eingesetzt, um beim Einsteigen in ein Flugzeug Dienstleistungen an Passagiere zu verkaufen. Und wenn in diesem Moment eine Art Fehler auftritt, haben wir keine Zeit für einen Hotfix. Fehler sollten daher nicht sein! Zuerst prüfen wir das Nutzungsszenario am Flughafen.

3. Arbeitsumgebung


Es ist notwendig, mit dem Team zu überlegen, welche Umgebungen für die Arbeit erforderlich sind und wer sie verwendet. In der Regel sind 2-3 Umgebungen ausreichend und werden verkauft.
GegebenLösung
Im CD / CI-Projekt werden rauchbasierte Autotests für die erste Funktionsprüfung geschrieben. Wir benötigen eine Umgebung für die primäre Montage des Codes in einem Zweig, dem Rauchtest, in der die externen Systeme mit Steckern geschlossen werden. Sie benötigen außerdem eine Umgebung für manuelle und Integrationstests mit Kundenservice (QA).
Beta-Testsitzungen finden regelmäßig statt. Sie brauchen eine Umgebung, die "außen" sichtbar ist und stabiler ist als die QA-Umgebung.

4. Tester arbeitet an dem Projekt


Es ist sinnvoll, alle Aktivitäten, die wir vom Tester für das Projekt erwarten, vorab zu besprechen, da sie nicht unbedingt bei allen Projekten gleich sind. Für jemanden in einem Team kann es eine Überraschung sein, dass der Tester etwas tut oder nicht.

Dieses Element hilft den Managern, zu verstehen, welche Kompetenz vom Tester gefordert wird und welche Zeitbelastung erwartet wird. Für bestehende Projekte ist es auch wichtig anzugeben, dass wir (QA) dem Manager die Mittel zur Verfügung stellen können, die er hat.

Dies können zum Beispiel sein:
  • Einschätzung der Aufgaben des Sprints auf Vollständigkeit und Konsistenz,
  • Einschätzung der Arbeitskosten für die Prüfung,
  • Erstellen von Checklisten für Tests (oder Testfälle),
  • Überprüfung der Autotest-Skripte
  • Funktionelle Autotests schreiben,
  • direkte manuelle Prüfung
  • Implementieren Sie Änderungen in der Umgebung
  • Aktualisierung von Teststrategien usw.

5. Testen Sie die Dokumentation zum Projekt


Wir müssen uns auf das Ufer einigen und vielleicht das Format für die Pflege der Testdokumentation noch einmal regelmäßig überprüfen:
  • welche Testdokumentation werden wir am Projekt behalten,
  • schreiben wir testfälle
  • überprüfen wir Listen
  • und wie oft diese Dokumentation aktualisiert wird.

GegebenLösung
Für rund ein Drittel der Systemfunktionalität wurden bereits rund 300 Testfälle geschrieben. Sie sollten nicht nur periodisch übergeben, sondern auch von Zeit zu Zeit aktualisiert werden.Bei begrenzten Ressourcen entschieden wir uns, nicht mit Testfällen zu arbeiten, sondern uns auf Checklisten für die einzelnen Aufgaben zu beschränken. Dadurch sparen wir Zeit bei der Dokumentation, ohne die Testqualität zu beeinträchtigen.

6. Wie werden Testskripte generiert?


Die Betriebsbedingungen und -szenarien hängen von der jeweiligen Lösung ab. Daher ist Folgendes zu diskutieren:
  • welche Techniken des Testdesigns sinnvoll sind. In diesem Rahmen ist es hilfreich, eine Liste von Objekten zusammenzustellen, mit denen die Anwendung arbeitet, sowie deren Äquivalenzklassen.
  • Welche Heuristiken und banale Lebenserfahrung helfen, Testszenarien für ein bestimmtes Projekt zu entwickeln. Für mobile Anwendungen ist es zweckmäßig, Standardheuristiken zu verwenden, beispielsweise "I SLICED UP FUN".

GegebenLösung
Beim Versicherungsprojekt muss der Benutzer (Agent) die Maschine inspizieren, währenddessen Fotos gemacht und auf den Server hochgeladen werden müssen. Der gesunde Menschenverstand legt nahe, dass es in den Garagen kaum WLAN gibt. Und manchmal gibt es keine mobile Kommunikation. Daher müssen Sie die Anwendung nicht nur beim Arbeiten mit 3G überprüfen, sondern auch bei fehlender Kommunikation.
Jede Benutzeraktion in der mobilen Anwendung der Fluggesellschaft ist Teil eines Szenarios. Sie können beispielsweise kein Ticket ausstellen, ohne eine Vorbuchung zu erstellen.Daher ist es logisch, die "Use Case" -Technik zu verwenden.

7. So arbeiten Sie mit dem Tracker


Verschiedene Tracker verfügen über unterschiedliche Fähigkeiten und Aufgabentypen. Basierend auf den Fähigkeiten des Trackers empfehlen wir Ihnen zu vereinbaren, wer und nach welchem ​​Prinzip die Priorität von Aufgaben bestimmt, welche Art von Aufgaben Fehler und Aufgaben ausgeben.

Sprechen Sie mit den wichtigsten Punkten des Teams:
  • Wie werden wir die von uns gefundenen Fehler von den Fehlern der Kunden unterscheiden (und ob wir sie unterscheiden sollen)
  • Verbesserungen vornehmen
  • Müssen wir die Verbesserungen, die wir selbst erfunden haben, von den vom Kunden geforderten unterscheiden? Auf welche Weise?
  • Was ist der Status, einen Fehler zu setzen, wenn es nicht noch einmal passiert,
  • Welcher Status wird als endgültig betrachtet.

GegebenLösung
Tester erstellt einen Fehler. Der Entwickler kann es nicht reproduzieren, übersetzt in den Status abgelehnt. Der Tester überprüft die Aufgabe erneut und setzt den Status auf Geschlossen (endgültig), wenn der Fehler wirklich nicht mehr besteht, oder er verfeinert die Beschreibung und kehrt zu Neu zurück.
Der Kunde legt die Aufgabe für die Überarbeitung fest. Dem Entwickler ist bekannt, dass er nicht genügend Daten zur Implementierung hat.Der Entwickler überträgt die Aufgabe in den Status Feedback.

(Weitere Informationen zur Beschreibung der Fehler und der Benutzerstory, die wir in diesem Artikel geschrieben haben ).

8. Kriterien für den Beginn und das Ende der Prüfung


Wenn der Tester zu irgendeinem Zeitpunkt eine Aufgabe übernimmt, ist dies keine Ordnung, sondern Chaos. Weil die Aufgabe möglicherweise nicht fertig ist. Oder bereit, aber nicht veneloena. Oder bereit, bekannt, hängt aber von anderen Aufgaben ab, die noch nicht fertig sind. Infolgedessen verbringt der Tester Zeit und Nerven, um Fehler zu finden und zu verarbeiten, aber man muss nur warten. Daher sind wir uns einig, wann der QS-Verantwortungsbereich für die Aufgabe beginnt und endet.

In den frühen Stadien der Projektentwicklung wird die Bereitschaft der Aufgabe / Version durch das Auge bestimmt.
Mit zunehmendem Selbstbewusstsein verstehen wir, dass wir klare Kriterien benötigen, dass die Aufgabe / Version bereit ist. Damit diese Lösung für alle transparent ist und nicht „der Beutetester erkennt, dass alles normal ist“. In den Bedingungen einer angepassten CD glauben wir beispielsweise, dass die Aufgabe zum Testen bereit ist, sobald sie auf die QS-Umgebung angewendet wird und den Status Gelöst hat.
GegebenLösung
Das Projekt hat einen Prozess, bei dem für jede Revision eine Checkliste zum Testen vorbereitet wird.Wir betrachten die Aufgabe als verifiziert, wenn wir alle Elemente der Checkliste bestanden haben.
Das Projekt arbeitet an Sprints.Ein Sprint gilt als bereit, wenn sich alle Verbesserungen im Status "Geschlossen" befinden und keine Fehler mit einer Priorität "Normal" oder höher auftreten.
Das Projekt verfügt über eine Liste der Funktionen nach Prioritäten.Wir glauben, dass die Version zur Veröffentlichung bereit ist, wenn die Funktionalität der ersten Elemente in der Liste erfolgreich funktioniert.
Testfälle werden in das Projekt geschrieben und die Regressionstests werden vor der Veröffentlichung durchgeführt.Eine Version gilt als bereit zur Veröffentlichung, wenn nach den Ergebnissen des Regressionstests keine Fehler mit einer normalen Priorität oder höher gefunden wurden (oder der Prozentsatz nicht erfolgreicher Szenarien nicht höher als 5 ist).

9. Werkzeuge für die Arbeit


Der Abschnitt ist nützlich, um die verantwortlichen Aufgaben (an den Administrator und den Manager) in der Planungsphase des Tests zu erfassen und alle für den Einstieg erforderlichen Werkzeuge zu erhalten.

Es lohnt sich, solche Fragen zu diskutieren:
  • Welche Tools benötigen wir für die Testdokumentation?
  • Für welche Tools können Testdaten vorbereitet werden?
  • Welche Werkzeuge werden zur Automatisierung benötigt?

GegebenLösung
Um die implementierte Funktionalität zu beschreiben, haben wir uns für Mind-Maps entschieden.Die Jungs im Team arbeiten auf verschiedenen Plattformen. Sie müssen also 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.Daher benötigen wir Tools, mit denen wir Testdaten vorbereiten können (z. B. Rollenskripts in der Datenbank), den Start innerhalb der Pipeline (z. B. newman) zulassen und Stubs (z. B. WireMock) erstellen können.

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


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

  • Wie wir Fehler beim Verkauf verfolgen,
  • Wie werden wir Feedback von Benutzern sammeln?
  • Wie werden Statistiken zur Verwendung unserer Funktionen erfasst?

GegebenLösung
Nach der Freigabe einer neuen Funktion des Systems wird die Überwachung der Nutzung konfiguriert (z. B. die Anzahl der Verkäufe des Dienstes).Ein Leistungsabfall ist ein Auslöser für Untersuchungen. Möglicherweise funktioniert die Funktion nicht wie erwartet oder wir haben keinen Teil des Skripts implementiert.
Wir haben im Programm die Geschwindigkeit der Ausführung grundlegender Operationen eingestellt.Das Kriterium für die Qualität der Arbeit ist, dass bei einem Zustrom von Benutzern die Ausführungsgeschwindigkeit nicht abnimmt.

Fazit


Es gibt keine einheitliche und universelle Teststrategie, die für alle geeignet ist. Sie wird für jedes Projekt individuell zusammengestellt.

  • Es ist wichtig zu verstehen, dass Strategie kein Selbstzweck sein darf, sondern nur ein Werkzeug, mit dem wir unsere Ziele erreichen können.
  • Es ist 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 etwas zu früh war, um sich mit der Leistung zu beschäftigen, könnte es morgen Zeit sein. Daher ist es nach dem Erstellen einer Strategie wichtig, diese regelmäßig zu aktualisieren, zu aktualisieren und Änderungen an das Team vorzunehmen.
  • Nach dem Erstellen einer Strategie wird normalerweise klar, wo die Fehler beim Testen sind und was zu tun ist. Dies ist eine Gelegenheit, Ziele zu setzen, die Dynamik zu beobachten und ... die Strategie im Laufe der Zeit zu aktualisieren.

Jetzt auch beliebt: