Ich habe 7 Schlüsselstufen in der Testentwicklung identifiziert, um zu veranschaulichen, wie sich die Ansätze zur Qualitätssicherung in Unternehmen ändern. Während Sie den Artikel lesen, können Sie die Entwicklung der Tests nachverfolgen, Ihren aktuellen Stand bestimmen und herausfinden, was getan werden sollte, um den Prozess und die Qualität der Tests zu verbessern.
Der Artikel wurde ursprünglich für das CIS-Magazin geschrieben, aber ich denke, er wird auch für Habr-Benutzer interessant sein.
Also die Bühnen.
- Es gibt keinen Tester. Seine Funktionen werden vom Entwickler oder Manager ausgeführt.
- Tester werden angezeigt, aber nur Testprojekte in der Fertigstellungsphase.
- Tester prüfen alle Aufgaben der Entwickler auf Übereinstimmung des Ergebnisses mit der ursprünglichen Aussage des Problems.
- Tester beschäftigen sich mit Testdesign.
- Ein Testmanagementsystem wird eingeführt.
- Die Testautomatisierung wird angezeigt.
- Die Hierarchie wird komplexer, neue Rollen erscheinen im Testteam.
Nun zu jeder Etappe im Detail.
Phase 1. Der Test wird vom Entwickler und / oder Manager durchgeführt
"Did - check for yourself" - der einfachste, "instinktivste" Testansatz. In kleinen Unternehmen eine alltägliche Sache. Wenn es nicht möglich ist, einen professionellen Tester zu engagieren, oder kein Verständnis für die Notwendigkeit von Tests besteht, wird diese Aufgabe von alleine erledigt. Sich selbst zu testen ist der irrationalste und problematischste Ansatz. Deshalb.
- Der Entwickler selbst testet nur die Szenarien, die er mit den Daten implementiert hat, die er im Entwicklungsprozess verwendet hat. Bei solchen Tests „im luftleeren Raum“ entfallen alternative Szenarien. Infolgedessen nimmt das Leben Anpassungen vor und in der Regel treten Fehler beim Endbenutzer auf.
- Wenn der Manager testet, dann tut er dies als zusätzliche Belastung, ohne über Fachwissen zu verfügen und ohne die Zeit und moralische Stärke zu haben, sich eng mit dem Testen zu befassen. So kann man grobe Fehler finden, aber viele Nuancen werden übersehen.
- Die subjektive Einstellung zu dem Projekt und der Wunsch, es schnell zu bewältigen, führten zu der Versuchung, die Augen vor einer Reihe von scheinbar „unbedeutenden“ Problemen zu verschließen.
Ein extremer Fall, in dem das Unternehmen überhaupt keine Tests durchführt und ein Fehlerbericht ... dem Kunden bringt. Er habe die Veröffentlichung erhalten, alles sei bereits auf dem Schlachtfeld, berichtete der Entwickler über den Start. Der Client öffnet das Projekt und stellt einen allgemeinen Datenbank- oder Serverfehler fest. Dann immer mehr Fehler. Der Kunde wird zum Tester für sein eigenes Geld.
Phase 2. Der Tester überprüft das Projekt ganz am Ende
Das Überprüfen des gesamten Projekts in der Vorabversion ist eine klassische Methode bei der Arbeit am Wasserfallmodell. Das Projekt ist in globale Phasen unterteilt (manchmal besteht das gesamte Projekt aus einer Phase). In jeder Phase wird zuerst Software erstellt und erst dann getestet. Testen ist schon da, und das ist gut so. Es gibt aber auch Probleme, und zwar sehr spezifische.
Erstens, wenn wir ganz am Ende testen, werden schwerwiegende Fehler auf der Architekturebene zu spät gefunden. Es wird notwendig sein, einen großen Teil oder sogar das gesamte Projekt zu wiederholen. Dies ist für niemanden von Vorteil.
Zum anderen können wir mangels Dokumentation nur Oberflächenversuche mit der freien Suchmethode durchführen. Dadurch werden einige der alternativen Szenarien sofort deaktiviert. Es kommt vor, dass es eine Dokumentation gibt, aber dabei ändern sich die Aufgaben und das fertige Produkt weicht vom Bild auf Papier ab. Auch hier gibt es Schwierigkeiten beim Testen und Parsen von Fehlerberichten.
Drittens wird bei einem Projekt in der Regel fast immer die Entwicklung als vorrangige Aufgabe behandelt. Lassen Sie etwas Zeit, um zu überprüfen. Es bleibt jedoch keine Zeit, um Fehler zu beheben. Infolgedessen verlangsamen manchmal beeindruckende Verbesserungen das Projekt und stören die Fristen.
Separates Testen von Schritten wirft ein anderes Problem auf. Zwischen den Phasen vergisst der Tester die Details des Projekts und muss sich jedes Mal damit befassen, was gerade passiert. Dies ist auch eine Verschwendung von Arbeitsstunden.
Die Prüfung des Projekts am Ende ist im Allgemeinen logisch und scheint korrekt zu sein. Bei dieser Methode wird jedoch das Risiko der Erkennung globaler Fehler nicht berücksichtigt. Daher wird das Testen weiterentwickelt.
Stufe 3. Alle Aufgaben werden auf Übereinstimmung des Ergebnisses mit der ursprünglichen Aufgabe überprüft.
Darüber hinaus ist das Unternehmen der Ansicht, dass es besser ist, Fehler zu erfassen, wenn sie sich ansammeln. Aus diesem Grund wechseln wir vom Wasserfallmodell zur agilen Methodik. Zu diesem Zeitpunkt sind die Tester enger in den Entwicklungsprozess eingebunden. Alle Aufgaben werden nacheinander wiederholt getestet: separat im Rahmen der Veröffentlichung in einer Kampfumgebung.
In dieser Phase werden die Aufgaben auf Übereinstimmung mit den angegebenen Anforderungen überprüft. Agile hilft dabei, besser zu arbeiten, aber nicht alle Tester und insbesondere ihre Führungskräfte sind bereit, sich auf neue Weise mit dem Testen zu befassen.
Der Kopf erwartet von den Testern Geschwindigkeit und Qualität, aber es gibt kein Verständnis für die Notwendigkeit der Testdokumentation und der Durchführung von Regressionstests. Daher die typischen Probleme dieser Evolutionsstufe.
Testen ist intuitiver als strukturiert. Das Prinzip "Was ich sehe, ist das, was ich teste" dominiert. Bei jeder Iteration werden unterschiedliche Überprüfungen in einer unterschiedlichen Reihenfolge durchgeführt. Infolgedessen können Sie den Fehler zumindest in einer der Testphasen überspringen oder gar nicht sehen. Alternative Szenarien und Änderungen der zugehörigen Funktionen können ebenfalls außer Sichtweite geraten.
Außerdem liegt das Problem bei Regressionstests, die, falls sie durchgeführt werden, unsystematisch sind. Tatsächlich prüft der Tester, was er für notwendig hält oder was der Entwickler / Manager ihm geraten hat, zu prüfen.
Phase 4. Die Tester beschäftigen sich mit dem Testdesign.
Zu diesem Zeitpunkt tritt das Testdesign in die Szene ein. Tester beginnen bewusst auf die Anforderungsanalyse zu achten. Die Funktionalität ist in logische Blöcke unterteilt, die von Checklisten oder Testfällen abgedeckt werden.
Checkliste - Eine Liste der Prüfungen, die zum Testen der Funktionalität erforderlich sind. Checklisten sind häufiger anzutreffen, da sie leichter auf dem neuesten Stand zu halten sind, insbesondere im Rahmen eines großen, dynamischen Projekts.
Ein Testfall ist eine Folge von Schritten, die zur Überprüfung der Funktionalität ausgeführt werden müssen. Eine Beschreibung jedes Schritts wird von einem Hinweis auf das erwartete Verhalten des Systems begleitet.
Es erscheint eine vollständige Testdokumentation, anhand derer Sie verfolgen können, wie eine bestimmte Funktion überprüft wird. Die Testdokumentation ist nicht nur für Ersttests, sondern auch für Regressionstests hilfreich.
All dies nennt man Testdesign. Es kann gesagt werden, dass sinnvolle professionelle Tests in dieser Phase beginnen. Dies ist mehr als nur ein Berg von Aufgaben, die geprüft werden müssen, sondern ein strukturierter Prozess zur Analyse von Anforderungen, zur Erstellung von Testdokumentationen und zum direkten Testen. Einschließlich der Änderung der Herangehensweise an Testdaten. Daten werden dabei nicht mehr spontan erfunden, sondern aus vorbereiteten Sets entnommen.
In der Testphase gibt es keine offensichtlichen Nachteile. Im Allgemeinen ist dies ein ordentliches Testniveau. Für das Streamen von Produktionsstandorten oder ähnlichen Projekten ist das Testdesign mehr als ausreichend. Die Hauptsache ist, sich dem Testprozess korrekt anzunähern: das Produkt analysieren, die Dokumentation erstellen und Tests daran durchführen.
Phase 5. Ein Testmanagementsystem wird eingeführt
Darüber hinaus wächst die Notwendigkeit, spezielle Systeme zum Speichern von Testfällen (Checklisten) und Durchführen von Testläufen zu verwenden.
Ein solches System ermöglicht:
- Speicheranforderungen und Testfälle;
- Verknüpfen Sie Anforderungen mit Testfällen
- Analysieren der Testabdeckung;
- verschiedene Versionen von Testfällen speichern;
- Probeläufe durchführen
- eine vergleichende Analyse der Testläufe durchführen;
- Testberichte aufbewahren;
- Verfolgen Sie die Arbeitsbelastung Ihres Teams, um Aufgaben und Ressourcen anzupassen.
Ein System ist immer ein neuer Evolutionsschritt. In unserem Fall wird zunächst die Kontrolle über den Testprozess verbessert. Wir führen Tests besser durch und erreichen eine neue Produktqualität.
In den späteren Phasen der Projektentwicklung hilft ein solches System allen Teilnehmern, sich daran zu erinnern, wie etwas funktionieren und wie es zu überprüfen ist. Das System beschleunigt die Einführung neuer Teilnehmer in das Projekt.
Phase 6. Regelmäßige Überprüfungen werden automatisiert
Bei der langfristigen Entwicklung von Projekten müssen die einzelnen Prüfungen automatisiert werden. Entwickler und Tester schreiben dazu Autotests. Entwickler machen normalerweise Unit-Tests, Tester machen UI-Tests. Sie beginnen damit, mit Autotests positive Szenarien für die Verwendung von Schlüsselfunktionen abzudecken: Autorisierung, Registrierung, Veröffentlichung von Aufzeichnungen und dergleichen.
Entwickelte Autotests werden in den kontinuierlichen Integrationsprozess (
CI / CD ) einbezogen, der es dem Team ermöglicht, Fehler sofort zum Zeitpunkt des Commits zu erkennen.
Autotests reduzieren die Kosten für Regressionstests erheblich und verbessern die Qualität des Endprodukts. Aber um sie zu machen, braucht man ein bestimmtes Testniveau. Es ist auch wichtig zu wissen, dass Autotests in der Anfangsphase eines Projekts keinen Sinn ergeben. Das System ändert sich schnell, daher ist es zur Vermeidung von Phantomfehlern auch erforderlich, Autotests zu ändern, was einige Zeit in Anspruch nimmt.
Stufe 7. Die Hierarchie wird komplexer, es erscheinen neue Rollen
Wir haben die höchste Stufe der Evolution erreicht, wenn die Hierarchie in der Testabteilung erheblich kompliziert ist und enge Spezialisten auftreten: ein Testmanager, ein Testleiter, ein Testanalyst, ein Testdesigner und so weiter.
Das Team wächst, die Aufgaben werden immer komplizierter. Zum Beispiel weiß ein
Testmanager am meisten über ein Produkt Bescheid und organisiert Tests auf einer höheren Ebene. Er kommuniziert häufiger und enger mit Kunden und der Entwicklung als mit dem Testteam.
Der Testleiter organisiert das Testen des Projekts und verteilt die Aufgaben innerhalb des Teams.
Der Testanalyst befasst sich mit der Analyse der Anforderungen, ihrer Zerlegung und Priorisierung, bereitet das Material für das Testdesign und die anschließenden Tests vor. Und der
Testdesigner wandelt die Anforderungen in Checklisten und Testfälle um.
Bei großen Projekten, bei denen ein ganzes Team von Testern arbeitet, sind neue Rollen erforderlich. Das Aufkommen solcher Rollen führt zu einem noch strukturierteren Testprozess, ohne den es nicht möglich ist, an großen und komplexen IT-Projekten zu arbeiten.
Schlussfolgerungen
Wir haben die wichtigsten Phasen der Testentwicklung in einem Unternehmen untersucht. Bewusstes professionelles Testen beginnt bereits in der Testphase. Das Testdesign sorgt für eine stetige Verbesserung der Produktqualität.
Der Testentwicklungsprozess ist nicht immer linear. Sie können bestimmte Phasen überspringen, kombinieren, mischen oder sofort auf eine höhere Ebene wechseln. Zum Beispiel haben wir ein Testmanagementsystem in Qualitica, das heißt, wir befinden uns in Phase 5. Jetzt haben wir fast gleichzeitig enge Spezialisten (neue Rollen, Phase 7) und Automatisierung (Phase 6).
Nicht jeder braucht das Testmanagementsystem, Autotests und vor allem einen Testdesigner. Es ist jedoch unwahrscheinlich, dass komplexe langfristige Projekte durchgeführt werden, wenn wir uns noch auf die instinktiven Tests oder die Endkontrolle beschränken. Daher wünsche ich mir, dass Sie den richtigen Punkt in der Testentwicklung finden und zu diesem Punkt gelangen, um die Testqualität zu verbessern und den Kunden ein qualitativ hochwertiges Produkt zu bieten.