Get best of the week

Was wir aus dem Testen des staatlichen Informationssystems gelernt haben

Hallo alle zusammen! 

Ich leite den Testsektor in der Systemanalyse- und Testabteilung der LANIT-Abteilung für Unternehmenssysteme. Ich bin seit 14 Jahren auf diesem Gebiet. 2009 war ich zum ersten Mal mit dem Testen des staatlichen Informationssystems konfrontiert. Und für LANIT und für den Kunden war es ein riesiges und bedeutendes Projekt. Es ist seit mehr als neun Jahren im kommerziellen Betrieb.

Quelle

Dieser Text führt Sie in den Ansatz zum Testen von GIS ein, der in unserem Unternehmen verwendet wird. Insbesondere werden Sie herausfinden (der Link führt Sie zu dem Fragment des Artikels, auf den in einem bestimmten Absatz verwiesen wird):


Vor LANIT arbeitete ich in einer Testgruppe von fünf Personen, in der die Aufgaben dem Teamleiter zugewiesen wurden. Als ich zu LANIT kam, wurde ich beauftragt, ein geografisch verteiltes Testteam von vier Testern zu leiten, die zu Beginn des Projekts beteiligt waren, um das staatliche Informationssystem zu testen. Mit der Entwicklung des Projekts stieg die Anzahl der Tester in der Gruppe proportional zur Erhöhung der Funktionalität.

Kapitel 1. Start des ersten GIS-Testprojekts


Als wir anfingen, mit GIS zu arbeiten, mussten wir uns zunächst mit großen Funktionsvolumina (mehrere Dutzend Subsysteme mit jeweils bis zu Hunderten von Funktionen) befassen, die in kurzer Zeit getestet werden mussten. Das Team hatte die Aufgabe, sich im Funktionsumfang nicht zu verwirren und das Risiko fehlender Mängel zu minimieren.

Die normative Dokumentation, auf deren Grundlage technische Spezifikationen entwickelt wurden, änderte sich ständig, und das gesamte Team musste sich an Innovationen anpassen: Wir haben die technischen Spezifikationen für die Entwicklung und die Prioritäten des Projekts überarbeitet (infolgedessen hat sich der Testplan geändert). 

Für Analysten war es schwierig, sich auf die häufige Änderung der behördlichen Dokumentation einzustellen, was zu einem Unverständnis darüber führte, wie technische Spezifikationen auf dem neuesten Stand gehalten werden können, wie immer eine Reihe relevanter Spezifikationen für jede Version des Systems vorhanden sind, wie und wo der Grad des Einflusses einer Änderung in einer Spezifikation auf viele andere verwandte Dokumente angezeigt werden kann . 

Da das Ergebnis der Arbeit von Analysten von Entwicklern und Testern verwendet wurde, waren Fragen zur Relevanz technischer Spezifikationen, zur Verständlichkeit der Spezifikationshistorie und zur Konformität der technischen Spezifikationen der kommenden Release-Version für alle Teilnehmer des Projektteams akut. Die Folgen der Verwechslung mit der Dokumentation und der Versionierung der technischen Spezifikationen wirkten sich auf die Projektkosten aus.

Manchmal drehte sich die Situation um 180 Grad. Stimmen Sie zu, wenn ein Zug mit hoher Geschwindigkeit fährt, ist es unmöglich, die Richtung ohne Konsequenzen scharf zu ändern.

Ich nahm regelmäßig an Sitzungen teil und verstand den Grund für die Änderungen im Projekt. Am schwierigsten ist es, Remote-Testern zu erklären, warum wir die neue Registrierung einen Monat lang getestet haben. Jetzt müssen wir alles vergessen und uns darauf vorbereiten, die vollständig neu gestaltete Funktionalität dieser Registrierung zu testen. Die Menschen fühlten sich wie Zahnräder in einer riesigen Maschine, und ihre Arbeit wurde als völlig nutzlos angesehen.

Solche Änderungen haben das Team zunächst genervt und stark demotiviert. Das Team akzeptierte jedoch die Tatsache, dass es unmöglich ist, die Änderung der technischen Spezifikationen zu beeinflussen, aber Sie können lernen, wie man damit arbeitet. In dieser schwierigen Phase des Projekts hatte das Testteam eine neue Aufgabe, die bei kleineren Projekten normalerweise fehlte - die Testanforderungen. 

Infolgedessen wurden die Nachteile sich ändernder Anforderungen zu Vorteilen für Tester in Form einer neuen Testaufgabe und der Fähigkeit, das Endergebnis des Projekts zu beeinflussen. 

Neben der Interaktion mit Analysten stellte sich heraus, dass das Testteam von der Kommunikation mit externen Systemen abhängig war, in die sie integriert werden müssen. Nicht alle von ihnen waren bereit, ihre Testschaltung bereitzustellen und Systeme von Drittanbietern über ihre Veröffentlichungsdaten zu informieren und Informationen über Änderungen an Diensten auszutauschen. Eine solche Desynchronisation in der Kommunikation oder eine nachlässige Haltung gegenüber der Benachrichtigung über die Zusammensetzung von Änderungen an Webdiensten durch externe Systeme führte zu Produktfehlern und Schwierigkeiten bei der Durchführung von Integrationstests. Die Tester mussten die Kommunikation mit externen Systemen herstellen, die Fähigkeit zum Testen der Integration entwickeln und Entwickler für die Implementierung von Stubs gewinnen.

Das gesamte an dem Projekt beteiligte Testteam sah sich mit der Notwendigkeit konfrontiert, das Entwicklungsteam in den Produktionsprozess einzubeziehen. Zu Beginn des Projekts suchte das Entwicklungsteam nach neuen Ansätzen für die Arbeitsorganisation und führte die Verzweigungsmodelle Feature Branch Workflow und das Gitflow-Modell ein. Die Entwicklung kleiner Projekte verlief bisher ohne eine Reihe von Filialen, alle fühlten sich wohl. Angesichts der Unfähigkeit, die Version für einige Monate für die nächste Demonstration der Zwischenphase des Projekts für den Kunden zu stabilisieren, kamen der Entwicklungsmanager und der Architekt nach Analyse der Gründe zu dem Schluss, dass der Prozess der Softwareerstellung geändert werden muss. Dann begannen sie, Feature Branch Workflow und Gitflow aktiv für das Projekt zu verwenden. Eine weitere neue Aufgabe zum Testen erschien - die Untersuchung der Arbeitsprinzipien von Entwicklungsmodellen, um sich an den Prozess der Softwareerstellung anzupassen.

GIS umfasst die Aufteilung eines Projekts in Funktionsblöcke, von denen jeder eine Reihe von Komponenten enthält, die vom Unternehmen eng miteinander verbunden sind und / oder eine unabhängige technische Funktion ausführen. Wenn zu Beginn des Projekts alle Tester die neu eingetroffenen Funktionsblöcke überprüften und alle im Team austauschbar waren und alle Blöcke gleich gut kannten, musste mit der Erweiterung des Projekts auch die Anzahl der Tester erhöht und in Gruppen aufgeteilt werden. Das Wachstum des Teams führte zur Trennung in Testgruppen und zur Zuweisung von Projektrollen innerhalb jeder Gruppe.

Als sich das Projekt entwickelte, tauchten Merkmale staatlicher Informationssysteme auf. 

Kapitel 2. Funktionen von GIS. Wie Tester mit ihnen leben und arbeiten


Erstens unterliegt ein großes GIS erhöhten Anforderungen an Zuverlässigkeit und Auslastung, Systembetrieb - 24/7, Systemstörungen sollten nicht zu Datenverlust führen, Systemwiederherstellungszeit - nicht mehr als 1 Stunde, Reaktionszeit - nicht mehr als 2 Sekunden und vieles andere. 

Da es sich um ein Webportal handelte, mussten die Tester in den Testprozess von Mehrbenutzer-Webportalen eintauchen und einen Ansatz für das Testdesign und den Testprozess entwickeln, wobei die Besonderheiten der Weboberfläche berücksichtigt wurden.

Eine Webanwendung kann von einer großen Anzahl von Benutzern gleichzeitig verwendet werden. Es war erforderlich, Lasttests für den offenen Teil des GIS bereitzustellen, der von allen Benutzern verwendet wurde, um das Lastmodell vorherzusagen und Lasttests durchzuführen.

Der Benutzer kann über eigene Zugriffsebenen verfügen. Es war erforderlich, die Matrix der Benutzerrollen im Anwendungsverwaltungssubsystem mithilfe von Testdesign-Techniken zu testen.

Benutzer können auf eine Entität zugreifen, was zu einem wettbewerbsfähigen Zugriff führt. Damit die Eingabedaten eines Benutzers die Daten eines anderen Benutzers nicht überschreiben, mussten wir eine Testanalyse von Situationen durchführen, in denen es möglich ist, die Daten in den persönlichen Dashboards der Benutzer gleichzeitig zu ändern, um die Überprüfung der korrekten Tests mit Diagnosemeldungen in die Tests einzubeziehen.

Eines der Merkmale des Systems war die Verwendung der SphinxSearch- Suchmaschine .mit denen das Testteam nicht arbeiten konnte. Um die Feinheiten des Testens zu verstehen, musste Sphinx die Entwickler konsultieren und verstehen, wie die Datenindizierung erfolgt.

Die Tester beherrschten die Funktionen des Testens von Suchvorgängen anhand von Wortformen, Wortfragmenten und Synonymen. Durch die Suche in den angehängten Dokumenten begannen sie zu verstehen, warum die neu erstellten Suchdaten nicht im Suchergebnis angezeigt wurden und ob dies ein Fehler war. 

Das Projekt verfügte über ein Subsystem der angewandten Verwaltung, das nicht nur die Benutzerregistrierung umfasste, sondern auch durch das Vorhandensein einer Matrix von Benutzerrollen erschwert wurde. Es wurde in den persönlichen Konten von Administratoren von Organisationen konfiguriert. Die Anzahl der Kombinationen von Überprüfungen der Rollenmatrix war groß und die Anzahl der Arten von Organisationen war ebenfalls nicht gering, dh die Anzahl der Kombinationen von Überprüfungen nahm exponentiell zu. Es war notwendig, den bekannten Ansatz für das Entwerfen von Tests zu ändern, die früher für kleine Projekte verwendet wurden. 

Da das System eine Weboberfläche voraussetzte, mussten browserübergreifende Tests durchgeführt werden, die ursprünglich nicht geplant waren. Als das Projekt gerade gestartet wurde, war Internet Explorer 7.0 der einzige Browser, der inländische Kryptografie unterstützte, und die Mehrheit der Benutzer verwendete diesen Browser. Zu Beginn des Projekts wurde daher zum Testen der Logik und Funktionalität der Arbeit persönlicher Konten nur der IE dieser Version verwendet. Für den offenen Teil des Portals war jedoch Unterstützung für alle zu diesem Zeitpunkt vorhandenen Browser erforderlich. In diesem Moment dachten sie jedoch nicht an browserübergreifende Tests.

Als sie mich fragten: "Wie verhält sich das System in allen bekannten Versionen von Browsern?" - Ich war, gelinde gesagt, in Panik, da das Volumen des Testmodells riesig war (ungefähr 4.000 Testfälle), der Regressionstestsatz ungefähr 1.500 Testfälle betrug und das Testteam die gesamte Menge ausschließlich in einem standardmäßig ausgewählten Browser überprüfte. Dieser Fall musste sehr schnell gelöst und mit Einfallsreichtum eingesetzt werden, um die Fristen für die erste Version einzuhalten und die wichtigsten Browserversionen mit Tests abzudecken.

Im Internet gab es damals nur wenige Artikel zum Testen und Entwickeln von Testmodellen. Für unser Team war es zu dieser Zeit eine unverständliche Aufgabe, ein großes Testmodell zu erstellen, zu speichern und auf dem neuesten Stand zu halten. Es war nicht klar, wie man von Forschungstests wegkommen sollte, die unendlich werden konnten, und es gab keine Ressourcen für den endlosen Test: weder menschlich noch vorübergehend.

Nachdem das GIS in den Testbetrieb und dann in den industriellen Betrieb versetzt wurde, erschien eine neue Aufgabe - die Behandlung von Benutzervorfällen. 

Bevor ein vollwertiger GIS-Benutzer-Support-Service erstellt wurde, traf das Testteam den ersten Treffer von Benutzeranforderungen, da es am meisten in die Details des Systems vertieft war und versuchte, die Hauptaufgaben des Testens neuer Verbesserungen zu kombinieren und eingehende Vorfälle, die von SLA überlagert wurden, rechtzeitig zu verarbeiten.

Das Testteam hat eine solche Aufgabe noch nicht erlebt. Der Ablauf von Vorfällen musste verarbeitet, systematisiert, lokalisiert, korrigiert, verifiziert und in den neuen Freigabezyklus integriert werden. 

Das Verständnis und die Reife des Betriebsprozesses wuchsen und verbesserten sich mit dem Wachstum des Systems. 

Ich habe nur einen Teil der Funktionen aufgelistet, auf die das Testteam bei der Arbeit mit GIS gestoßen ist.

Kapitel 3. Probleme beim Testen von GIS und Methoden zu deren Lösung. Empfehlungen an Testmanager von Teams.


Während das Testteam an mehreren großen GIS arbeitete, erarbeiteten wir Empfehlungen für Testmanager. Später wurden sie in die Methodik des Testprozesses solcher Systeme in unserer Abteilung umgewandelt und verbessern sich weiter, wenn neue Probleme in Projekten ähnlichen Umfangs gelöst werden.

Was tun bei viel Funktionalität?


Keine Panik und Aufteilung der Funktion in Blöcke / Module / Funktionen. Verbinden Sie den Analysten mit der Prüfung des Ergebnisses. Stellen Sie sicher, dass die Vision der Funktionsblöcke korrekt ist. 

Wir empfehlen:

  1. .

    , , , , production. , .
  2. //.

    , , — ,   ///. , , , - , , , / // , , « » , .

Was tun mit Wissensmatrizen und der Abdeckung funktionaler Anforderungen?


Die Funktionalität wird nicht kleiner. Jetzt gibt es noch viel davon, aber es ist in einer neuen Darstellung (in Form einer Matrix). Es muss ermittelt werden, welche Funktionen aus geschäftlicher Sicht am wichtigsten sind und welche nicht in Rohform für Benutzer bereitgestellt werden können. So beginnt die Priorisierung der Funktionalität. Ideal, wenn der Analytiker dem Tester dabei hilft. Zumindest wird er die Richtigkeit der durch Tests gesetzten Prioritäten zu schätzen wissen.

Den wichtigsten Funktionen / Blöcken / Modulen wird eine hohe Priorität für den Test zugewiesen, die weniger wichtigen werden von den Tests mit der zweiten Priorität abgedeckt, der Rest wird der dritte sein, oder wenn die „Fristen laufen“, können Sie den Test für eine ruhigere Zeit verschieben. 

So haben wir die Möglichkeit, die für den Kunden wirklich wichtige Funktionalität zu testen. Wir ordnen die Dinge in einer Vielzahl von Funktionen, wir verstehen, was von Tests abgedeckt wird und was noch abgedeckt werden muss. Wir wissen, dass es notwendig ist, die Tests zu verstärken. Im Falle einer Krankheit / Entlassung verantwortlicher Tester verstehen wir, an welchen der Tester die Teams Verbesserungen für den Test bestehen sollten (in Korrespondenz mit der Wissensmatrix), welche neuen interessanten Funktionen / Module / Subsysteme kann ich bedingt anbieten Vasya, Pete, Lisa, wenn sie es leid sind, dasselbe zu testen. Das heißt, ich habe ein visuelles Werkzeug, um Tester zu motivieren, die etwas Neues über das Projekt lernen möchten.

Was tun, wenn Anforderungen die Historizität nicht unterstützen, verwirrt und dupliziert sind? Wie arbeiten Tester damit?


Wir empfehlen, den Anforderungsprüfungsprozess für das Projekt zu implementieren. Je früher ein Defekt entdeckt wird, desto geringer sind seine Kosten.

Von der Wissensmatrix verteilte Tester beginnen sofort mit der Untersuchung und Überprüfung dieser technischen Spezifikationen für die Entwicklung. Um allen klar zu machen, welche Fehler in den Anforderungen enthalten sind, wurde ein Regelwerk für Analysten „Rezept für Qualitätsanforderungen“ entwickelt, nach dem versucht wurde, Anforderungen zu schreiben, und Vorlagen für technische Spezifikationen wurden erstellt, um sie in einem einzigen Stil zu beschreiben. Den Testern wurden Regeln für das Format der technischen Spezifikationen und Empfehlungen für die Beschreibung der Anforderungen erteilt, um zu verstehen, auf welche Fehler in den Anforderungen zu achten ist.

Natürlich bestand die Hauptaufgabe des Testers darin, logische Inkonsistenzen oder unerklärliche Momente des Einflusses auf verwandte Funktionen / Subsysteme / Module zu finden, die der Analyst übersehen konnte. Nachdem Fehler festgestellt wurden, wurden sie im Bugtracker behoben, der dem Autor der Anforderung zugewiesen wurde. Der Analyst stoppte die Entwicklung und / oder unterhielt sich mit dem Tester. Der Entwickler teilte mit, dass die Bedingung entsprechend dem Fehler geändert werden würde (um die Entwicklung nicht zu verlangsamen), nahm Korrekturen vor und veröffentlichte die korrigierte Version Anforderungen. Der Tester prüfte und schloss die Arbeiten am Defekt entsprechend den Anforderungen. Dieses Verfahren gab dem Team die Gewissheit, dass das erkannte Problem nach einigen Wochen der Entwicklung im Test definitiv nicht auftreten würde.

Neben der Früherkennung von Fehlern erhielten wir ein leistungsstarkes Tool zum Sammeln von Messdaten zur Qualität der Arbeit von Analysten. Mit Statistiken über die Anzahl der Fehler in den Anforderungen könnte der leitende Analyst des Projekts Maßnahmen ergreifen, um die Qualität der Arbeit in seiner Gruppe zu verbessern. 

Was tun, wenn Lasttests durchgeführt werden müssen?


Es ist notwendig, die Anforderungen an die Last zu untersuchen, ein Modell zu erstellen, Testfälle zu entwickeln, das Testmodell der Last mit dem Analysten zu koordinieren und Lastskripte unter Einbeziehung kompetenter Spezialisten für Lasttests zu entwickeln. 

Natürlich können Sie die Last mit dem Testmodell nicht erraten, aber für einen genaueren Treffer können Sie zusätzlich zum Analysten einen Architekten oder DevOps-Spezialisten gewinnen, der nach Analyse der Informationen, Statistiken und Metriken feststellen kann, welche anderen Fälle im vorgeschlagenen Lastmodell erforderlich sind.

Es lohnt sich auch, den Prozess des Ausführens von Lasttests zu implementieren, die Lastergebnisse zu übernehmen und an die Entwickler weiterzugeben, um Engpässe zu beseitigen.

Der Ladevorgang sollte regelmäßig vor der Freigabe jeder Freigabe durchgeführt werden. Ändern Sie regelmäßig das Lastmodell, um neue Engpässe zu identifizieren.

Was tun, wenn Integrationstests durchgeführt werden müssen, für die keine Erfahrung vorliegt?


Es gibt grundlegende Möglichkeiten: Sie können beispielsweise Fortbildungskurse zum Thema Rest-API-Tests absolvieren, Artikel im Internet lesen, über Skype Erfahrungen mit Kollegen austauschen, den Prozess demonstrieren und einen Spezialisten einstellen, der sich mit Rest-API-Tests auskennt. 

Es gibt viele Möglichkeiten, in diese Art von Tests einzutauchen. In meinem Team wurde ein erfahrener Spezialist eingestellt, der mich und das gesamte Testteam in Zukunft schulte, Handbücher entwickelte: Worauf beim Testen der Rest-API zu achten ist, wie ein Testdesign zur Überprüfung der Integration zu erstellen ist, Webinare mit einer Demonstration des Testprozesses für das gesamte Team durchzuführen. 

Wir haben Testaufgaben entwickelt, bei denen jeder die Möglichkeit hatte, diesen Prozess zu üben und in ihn einzutauchen. Jetzt verbessert sich das Material, das bereits im Laufe der Jahre entwickelt wurde, nur noch, und der Prozess des Lernens und Eintauchens in die Rest-API-Tests dauert 1-2 Wochen, während das Tauchen je nach Komplexität des Projekts und Volumen des Testmodells früher einen Monat oder länger dauerte. 

Quelle

Wie kann man nicht in Code-Zweigen, Ständen, Bereitstellungen verwirrt werden und den erforderlichen Code testen?


Während sich GIS in der Anfangsphase der Entwicklung befindet, gibt es nur zwei Codezweige: Master und Release. Die zweite wird in der Stabilisierungsphase getrennt, um abschließende Regressionstests durchzuführen und Punktfehler der Regression zu korrigieren.

Als der Release-Zweig an die Produktion gesendet wurde und die nächste Iteration der Entwicklung begann, beschlossen wir irgendwann, die Entwicklung neuer Aufgaben zu parallelisieren, damit die durch das Release geplante größere Aufgabe rechtzeitig abgeschlossen werden konnte. Irgendwann gab es 3-4 oder mehr solcher Zweige. Es sind mehr als drei Prüfstände im Einsatz, um so schnell wie möglich mit dem Testen zukünftiger Versionen zu beginnen.

Tester sind sich sicher, dass der Infrastrukturspezialist, der beispielsweise die Revision Nr. 10001 auf einem der Prüfstände installiert hat, alles korrekt durchgeführt hat und den Test starten kann. Der Infrastrukturspezialist führte die Bereitstellung über den Codezweig durch, berichtete, dass der Stand bereitgestellt, der Code installiert und getestet werden konnte.

Wir starten den Test und verstehen Folgendes:

  • Es gibt Fehler, die bereits behoben wurden.
  • Die Funktionalität des vorhandenen Blocks unterscheidet sich erheblich von der ähnlichen Funktionalität, die auf einem anderen Prüfstand steht und sich auf die nächste geplante Version vorbereitet, während innerhalb des übertragenen Codezweigs keine Änderungen daran vorgenommen werden sollten.
  • Wir beginnen, Fehler zu registrieren, die Entwickler geben sie zurück, der Holivar beginnt in den Design-Chats und findet heraus, was wir tatsächlich installiert haben und warum nicht, was wir erwartet haben.

Wir haben eine Analyse durchgeführt und festgestellt, dass die Entwickler dem Infrastrukturspezialisten keine Anweisungen gegeben haben, von welchem ​​Zweig aus bereitgestellt werden soll, der Mitarbeiter aus dem Entwicklungszweig gesammelt wurde und der Entwickler nur einen Teil des Codes aus dem Feature-Zweig in den Entwicklungszweig zusammenführen konnte. 

Der Tester, der die Filialleitung überhaupt nicht verstand, bekam die Aufgabe und eine Verbindung zum Stand, lief zum Testen, verbrachte Zeit, bekam viele Mängel, die meisten waren aufgrund all dieser Verwirrung irrelevant.

Was wir getan haben, um ähnliche Situationen in Zukunft zu vermeiden:

  • Der Entwickler bereitet Anweisungen für den Infrastrukturspezialisten vor, die angeben, von wo aus die Bereitstellung bereitgestellt werden soll. Die Anweisung wird über die Aufgabe an jira weitergeleitet.
  • Der Infrastrukturspezialist ist nicht verwirrt und tut, was ihm gegeben wurde.
  • GIT, , jira ;
  • jira : 

  • Gitflow , , hotfixes develop,  .


, ,   ?


Wir empfehlen Ihnen, im Voraus eine Teststrategie zu erstellen. Da Sie diesen Punkt jedoch verpasst haben, wird sich meine Erfahrung wahrscheinlich als nützlich erweisen.

Zunächst müssen Sie verstehen, welche Browser in den Anforderungen angegeben sind. Wenn Sie sich dafür entschieden haben, aber absolut keine Zeit ist, sehen wir uns hier beispielsweise die Statistiken der am häufigsten verwendeten Browser an . Dann versuchen wir, drei oder fünf der beliebtesten Browser zu erreichen.

Da das Projekt groß ist und das Testteam groß war, war es physisch möglich, jedem Tester einen beliebten Browser gemäß Statistik zuzuweisen. Er führt seine Regressionsfälle in einer speziellen Browserversion durch. Besonderes Augenmerk muss auf das Layout, die Klickbarkeit von Schaltflächen und Links gelegt werden. Dieser Prozess sieht folgendermaßen aus: Es gibt beispielsweise 100 Skripte für einen Regressionstest, das Team hat 5 Tester, jeder kann 20 Skripte zur Arbeit nehmen, jedem wird ein Browser zugewiesen. Bei einem Regressionslauf überprüfte jeder Tester seine Fälle in einem der Browser. Die Abdeckung ist am Ende nicht vollständig, aber da viele Szenarien immer noch bis zu dem einen oder anderen Grad wiederholt werden, stieg der Prozentsatz der Abdeckung aufgrund der Übergabe eines Teils der Regressionsskripte durch verschiedene Browser. 

Dies ergab natürlich keine 100% ige Testabdeckung aller Funktionen, ermöglichte jedoch eine signifikante Reduzierung des Risikos, dass Cross-Browser-Fehler gemäß den wichtigsten Geschäftsszenarien im System in die Produktion gelangen.

Darüber hinaus haben wir nicht nur die Regression, sondern auch den Test auf Verbesserungen und die Validierung von Fehlern überprüft und verschiedene Browser überprüft, um den Umfang der browserübergreifenden Kompatibilität zu erweitern.

In Zukunft begannen sie, den Ansatz mit der Verteilung von Testern durch Browser auf den Verfeinerungstest anzuwenden, ohne auf die Regressionstestphase zu warten, wodurch der Prozentsatz der Tests, die verschiedene Versionen von Browsern abdecken, weiter erhöht wurde.

Was wir haben:

  • Optimierte Testkosten, sowohl finanziell als auch zeitlich, für ein Zeitintervall haben wir sowohl den Regressionstest als auch den Cross-Browser überprüft.
  • , Severity;
  • , , .

?


Sehr schnell hatten wir eine Frage zum Ausführen von Tests in einem einzelnen Repository, zum Aktualisieren und zum Ausführen von Testläufen mit Markierungen für das Ergebnis der Ausführung.

Das Team bestand aus Mitarbeitern mit Erfahrung mit dem TestLink- Testmanagementsystem . Dies ist das einzige Open-Source-Testfall-Managementsystem, daher wurde es ausgewählt, um zu funktionieren. In diesem System eine sehr einfache grafische Oberfläche und Design ohne unnötigen Schnickschnack. Wir haben das Programm schnell mit Tests gefüllt, es stellte sich die Frage, wie man es wartet. Zunächst wurden viele Ressourcen für die Aktualisierung der Fälle für jede Revision aufgewendet, und diese Option erwies sich als nicht funktionsfähig.

Nach Rücksprache mit dem Analysten und dem Testteam haben wir festgestellt, dass es aufgrund der Kosten für den Support nicht immer erforderlich ist, ein so großes Testmodell auf dem neuesten Stand zu halten. 

Alle Fälle wurden gemäß der Matrix der funktionalen Anforderungen in Ordner unterteilt. Jedes Funktionsmodul / Subsystem speicherte eine Reihe von Fällen in einem separaten Ordner. Dadurch konnten wir Testfälle visuell strukturieren. In TestLink wurden Schlüsselwörter erstellt, mit deren Hilfe der Fall zu einer bestimmten Gruppe gehört, zum Beispiel:

  • Rauch - wird für Testfälle verwendet, die im Rauchtest enthalten sind ( Durchführung einer Mindestmenge von Tests, um offensichtliche Mängel kritischer Funktionalität festzustellen );
  • Autotest - wird für Testfälle verwendet, anhand derer Autotests entwickelt werden.
  • Priorität 1 - Wird für Testfälle verwendet, die sich auf Geschäftsfunktionen mit der Bezeichnung Priorität 1 beziehen.

Daher ist ein Testdesign immer auf neue Verbesserungen ausgelegt, wodurch ein Checklistendokument angezeigt wird. Darin werden die Prüfungen priorisiert, und nur ein Teil der Prüfungen fällt unter „Priorität 1“, oder es werden bereits Test- und Regressionstestfälle im TestLink-System erstellt.

Wie kann man immer ein aktuelles Regressionsfallmodell für eine geplante Version und ein plötzliches HotFix in der Produktion haben?


Vor Beginn des Regressionstests wurden alle vorbereitenden Arbeiten, einschließlich der Aktualisierung oder des Hinzufügens neuer Fälle zur Regression, abgeschlossen. Dies bedeutet, dass beim Ausführen eines für die neue Version relevanten Testfalllaufs Fehler auftreten können, wenn HotFix in solchen Testfällen überprüft wird. 

HotFix-Korrekturen wurden am alten Code-Zweig (letzte Version) vorgenommen und Änderungen am Code durch Fehlerbehebungen vorgenommen, während aktuelle Testfälle aufgrund der Verbesserungen der zukünftigen Version geändert werden konnten. Das Ausführen von Testfällen, die für eine zukünftige Version relevant sind, kann zur Registrierung falscher Fehler führen und die Veröffentlichung von HotFix verzögern.

Um die Registrierung falscher Fehler und die Unterbrechung der HotFix-Testfristen zu vermeiden, haben wir uns für einen Mechanismus entschieden, der der Verwaltung von Code-Verzweigungen ähnelt. Nur das Zusammenführen und Aktualisieren von Fällen zwischen Zweigen (lesen Sie "Ordner") von TestLink wurde von Testern nach einem bestimmten Algorithmus manuell durchgeführt, während dies im Gitflow-Modell automatisch von Git durchgeführt wird.

Hier ist eine Reihe von Testfällen in TestLink:


Der Prozess der Aktualisierung von Fällen in TestLink wurde erfunden

  • Der Testmanager kopiert den Ordner mit den Fällen "Test Project 1.0.0" und erstellt eine neue Testsuite, die die Nummer der nächsten geplanten Version trägt. Es stellt sich heraus, dass der Ordner mit den Fällen "Testprojekt 2.0.0" versehen ist.
  • Nachdem Sie die Verbesserungen für eine zukünftige Version untersucht haben, werden Testfälle aus dem Ordner „Test Project 2.0.0“ analysiert, um festzustellen, ob sie für neue Verbesserungen aktualisiert werden müssen.

Falls erforderlich, aktualisieren Sie die Fälle:

  • Der für die Revision zuständige Tester nimmt Änderungen am Testfall im Set „Testprojekt 2.0.0“ vor.
  • Wenn Sie einen Testfall löschen müssen, müssen Sie ihn zuerst in den Ordner „Löschen“ verschieben. Dies geschieht, um einen versehentlich gelöschten Testfall wiederherzustellen, oder wenn die Anforderungen zurückgegeben werden und der Testfall erneut angefordert wird (der Test) Fälle nur aus dem Ordner, der der Testsuite der zukünftigen geplanten Version entspricht, in der dieser Testfall nicht relevant ist);
  • Wenn wir einen Testfall hinzufügen, muss dies nur in dem Ordner erfolgen, der der Testsuite der zukünftigen geplanten Version entspricht.
  • Testfälle, die sich ändern, sind mit dem Schlüsselwort „Geändert“ gekennzeichnet (erforderlich, um die Metrik des Grads des Einflusses von Verbesserungen auf die Regressionsfunktion zu bewerten);
  • Die hinzugefügten Fälle sind mit dem Schlüsselwort „Hinzugefügt“ gekennzeichnet (erforderlich, um die Metrik anhand der Auswirkungen von Verbesserungen auf die Regressionsfunktion zu bewerten).

Daher haben wir immer eine aktuelle Testsuite von Fällen, die der vorherigen Version des Systems entsprechen, und verwenden sie für den HotFix-Test. Außerdem arbeiten wir an der Aktualisierung der neuen Testsuite, bereiten uns auf Regressionstests vor und stabilisieren die neue geplante Version. Gleichzeitig können 3-4 Testzweige (lesen Sie „Ordner“) von TestLink, die verschiedenen Versionen des Systems entsprechen, gleichzeitig abgerufen werden. Dies ist besonders wichtig, wenn Sie Verbesserungen in den Funktionszweigen testen.

Nach jeder Veröffentlichung können wir anhand der Bezeichnungen "hinzugefügt" / "geändert" abschätzen, um wie viel sich unser Regressionsmodell geändert hat. 

Wenn das Regressionsmodell stark zunimmt, während sich das Verbesserungsvolumen in der Version im Vergleich zur vorherigen Version nicht wesentlich geändert hat, ist dies eine Gelegenheit, über die Richtigkeit der Festlegung von Prioritäten in der Checkliste für Revisionsprüfungen nachzudenken. Möglicherweise hat der Tester die falsche Auswahl der Fälle für die Regression getroffen, und es müssen Maßnahmen ergriffen werden: Erklären Sie dem Tester beispielsweise das Prinzip der Priorisierung, beziehen Sie den Analysten in die Koordinierung der Prioritäten ein und ändern Sie das resultierende Regressionsmodell, indem Sie redundante Testfälle entfernen.

Wie kann das Regressionstestmodell optimiert werden?


Wir haben mit einem Regressionstestmodell begonnen und den Prozess der Entwicklung von Regressions-Testfällen optimiert, indem wir Prioritäten hervorgehoben und nur Fälle der Priorität 1 in die Regression aufgenommen haben. Angesichts der Tatsache, dass das Testmodell nach einer Weile groß wurde, stiegen die Kosten für die Ausführung seiner Fälle und wir fielen nicht mehr in das Zeitintervall, das für die Durchführung eines Regressionstests für das Projekt akzeptabel war.

Es ist an der Zeit, die Testautomatisierung zu implementieren, deren Zweck war:

  • Verkürzen Sie die Zeit, um Regressionstestfälle abzuschließen.
  • Verwenden Sie automatische Tests, um Voraussetzungen für die Durchführung nachfolgender Überprüfungen zu schaffen und so die Zeit und die Personalkosten für die Erstellung von Testdaten zu optimieren.
  • Verbesserung der Qualität von Regressionstests durch Beseitigung des Einflusses des menschlichen Faktors auf die Ergebnisse eines manuellen Tests;
  • , .

Für die Automatisierung von GUI-Tests in Java wurde ein Framework entwickelt (GIT wurde als Versionsverwaltungssystem für die Quellcodeverwaltung verwendet).

Ein separates automatisiertes Testteam war an der Entwicklung von Autotests beteiligt, die die Aufgabe erfolgreich bewältigten. Für zukünftige Projekte in ähnlichem Umfang ist geplant, in Zukunft bestehende Entwicklungen anzuwenden und zu Beginn des Projekts automatisierte Tests zu starten, um so schnell wie möglich von seiner Verwendung zu profitieren. Weitere Informationen zur Automatisierung des Testens großer GIS finden Sie in einem Artikel meiner Kollegen, die direkt an der Organisation und Durchführung automatisierter Tests beteiligt waren.

Seitens der funktionalen manuellen Tests wurde auch das Regressionsmodell optimiert. 

Am Beispiel von zwei großen GIS haben das Team und ich Testsitzungen oder Testtouren entwickelt und implementiert, deren Kern wie folgt war: Es war notwendig, den Geschäftsprozess in jedem Subsystem zu analysieren und die Sitzung (Tour) der Prüfungen zu überdenken, die diesen Geschäftsprozess durchlaufen, wobei die meisten simuliert wurden Häufig ausgeführte Benutzeraktionen für den Prozess. 

Bei einem GIS-Projekt wurde dies als "Testsitzung" bezeichnet, bei einem anderen als "Testtour". Das Wesentliche blieb jedoch das gleiche - wir haben das durchgängige (durch die gesamte Revision) Schlüsselgeschäftsszenario durchdacht, das die Geschäftsidee der implementierten Revision vollständig abdeckt (es kann mehrere solcher Szenarien geben). 

Das Szenario der Testtour wurde mit dem Analysten vereinbart, detaillierte Regressionstestfälle wurden entwickelt und in Fällen, in denen es ihnen nicht gelang, einen Regressionstest für das gesamte Testmodell durchzuführen, konnten sie sich auf die Durchführung einer „Regressionssitzung“ oder einer „Regressionstesttour“ beschränken, die in der Regel nahm weniger Zeit in Anspruch und ermöglichte es, klar zu verstehen, ob es Probleme mit wichtigen Geschäftsprozessen im System gibt.

In Zukunft wurden Testtouren durch Autotests abgedeckt, und von Routineprüfungen befreite Tester wechselten zu Testverbesserungen der nächsten geplanten Versionen. 
Ein Beispiel für eine Testtour: „Erstellen, Bearbeiten, Veröffentlichen und Aufheben einer Entität“. 

Eine Testtour kann zum Beispiel kompliziert sein:

  • Rechte zum Erstellen, Bearbeiten und Annullieren geben,
  • Erstellen Sie eine Entität im "Persönlichen Konto" des Benutzers mit der Rolle "Spezialist".
  • ,
  • ,
  • ,
  • « » «»,
  • , .

SLA?


Ich empfehle, den Prozess der Lokalisierung von Vorfällen von Benutzern nicht als einfache Aufgabe zu behandeln. Sie sollten dies als Teil des Testprozesses nehmen. Darüber hinaus ist dies ein viel kreativerer Prozess als beispielsweise das Überprüfen von Testfällen. Es ist notwendig, Logik anzuwenden, die Erfahrung von Testdesign-Technikern, um dem Fehler auf den Grund zu gehen, ihn zu erfassen und an die Entwicklung weiterzugeben.

Natürlich ist es wünschenswert, den GIS-Betriebsprozess (idealerweise) mit drei Unterstützungsebenen zu organisieren. Infolgedessen schlagen die offensichtlichsten Vorfälle, die häufig nur Tester lokalisieren können, im Testteam fehl, die bereits in den ersten beiden Zeilen herausgefiltert wurden.

Zur Einhaltung der SLA empfehlen wirMachen Sie den Prozess der Vorfalllokalisierung zu einer Aufgabe im Testteam mit der höchsten Priorität und versuchen Sie, Optimierungsmethoden einzuführen, damit die Geschwindigkeit der Vorfallwiedergabe so hoch wie möglich ist. 

Um den Zeitaufwand für Tester zu optimieren, können Sie:

  • Pflege einer Projekt-Wissensdatenbank mit typischen oder häufig auftretenden SQL-Abfragen;
  • Organisieren Sie den Prozess des Rankings eingehender Aufgaben im Bugtracker so, dass der Tester auf dem Anzeigefeld sofort einen gefallenen Vorfall sieht und ihn mit der ersten Priorität zur Arbeit bringt.
  • Hinzufügen von Countdown-Zeitzählern in JIRA für Aufgaben mit SLAs;
  • ein Warnsystem für Vorfälle einrichten;
  • production ( — ), , , , , , production;
  • « » « ». . 

Über die "Wissensmatrix" wurde oben geschrieben. Bei der „Verantwortungsmatrix“ handelt es sich um eine Tabelle, in der analog zur „Wissensmatrix“ Funktionsblöcke / Module / Subsysteme ausgeschrieben sind und welche der Testgruppen für das Testen der Funktion verantwortlich ist. In der Regel ist dies der Teamleiter oder Senior / Lead-Tester in einer Gruppe.

Was ist, wenn der Tester eines Funktionsblocks / Moduls / Subsystems nicht das gesamte Bild des Geschäftsprozesses im Projekt versteht?


Dies ist ein schmerzhaftes Thema, auf das wir in mehreren großen GIS-Projekten gestoßen sind. Das Team erstellte eine „Wissensmatrix“, die Tester führten eine Selbsteinschätzung des Grads des Eintauchens in die Funktionalität durch und ordneten sich ihrer Funktionalität zu. Aber irgendwann schieden erfahrene Tester, die von Beginn des Projekts an teilnahmen, aus der Gruppe aus, und neue Spezialisten waren noch nicht in alle Geschäftsprozesse vertieft und sahen nicht das vollständige Bild. Dies führte dazu, dass beim Testen von Fällen in einem Modul die Ergebnisse dieses Falls im nächsten Modul verwendet werden sollten. Wenn daher falsche Ergebnisse an die Eingabe des zweiten Moduls geliefert wurden (Voraussetzungen waren nicht ideal für die Ausführung von Fällen aus dem vorherigen Modul), musste die Situation analysiert werden und Protokollfehler.

Die Tester dachten jedoch nicht darüber nach, warum solche Zahlen zu ihren Eingaben kamen, und arbeiteten einfach ihre Fälle aus. Formal wurde der Test durchgeführt, alles ist in Ordnung, es wurden keine Mängel festgestellt, und wenn der Analyst die Funktion akzeptiert oder sich auf die Abnahmetests vorbereitet, werden erhebliche Probleme in der Arbeit der Geschäftslogik geklärt, die beim Test übersehen wurden. Der Grund war ein mangelndes Verständnis des vom System durchgeführten End-to-End-Geschäftsprozesses.

In dieser Situation wurde Folgendes unternommen:

  • unter Einbeziehung des Analytikers in die Funktion eingetaucht;
  • In der Testgruppe wurden Schulungen durchgeführt, Erfahrungsaustausch, Geschichten bei Kundgebungen über das Subsystem und die darin stattfindenden Ereignisse sowie Diskussionen über neue Verbesserungen, die für das Subsystem in der nächsten geplanten Version geplant sind.
  • Anwerbung von Analysten und Einführung von Informationsvorlagen in die Spezifikationsspezifikationen über den Grad der Auswirkungen von Verbesserungen auf Module / Subsysteme von Drittanbietern;
  • Die Implementierung des Testprozesses für Testsitzungen (Touren), die Tester sind und diese mit Analysten koordinieren (trägt dazu bei, das Risiko eines Missverständnisses des Geschäftsprozesses durch das Team und die Anzahl der Geschäftsfehler im System zu verringern).

Fuh! Ich habe versucht, die Hauptprobleme und Empfehlungen für ihre Beseitigung zu sammeln, aber dies ist weit entfernt von allen nützlichen Informationen, die ich teilen möchte.

Kapitel 4. Metriken zur Bestimmung der Qualität des Projekts und die Methode zur Bewertung der Arbeitskosten für Tests


Bevor wir die Sammlung von Metriken für das Projekt einführten, fragten wir uns: „Warum sollten wir das tun?“ Die Hauptziele waren die Überwachung der Qualität des Testteams, die Qualität der in der Produktion produzierten Version und die Überwachung der Leistungsindikatoren der Teilnehmer der Testgruppe, um zu verstehen, wie das Team entwickelt werden kann.

Es wurde analysiert, welche Metriken zur Erreichung der Ziele erforderlich sind. Dann wurden sie in Gruppen eingeteilt. Dann überlegten sie, was ohne zusätzliche Änderungen im Prozess gemessen werden kann und wo Hilfe von anderen Mitgliedern des Projektteams benötigt wird.

Nach Abschluss aller Vorbereitungsphasen begann die regelmäßige Zusammenstellung der Metriken: einmal im Monat / Release / Sprint / Quartal - abhängig vom Projekt und den Merkmalen des Produktionsprozesses.

Nachdem wir die ersten Metriken gesammelt hatten, mussten die Zielindikatoren ermittelt werden, nach denen wir in dieser Phase der Projektentwicklung streben möchten. Dann mussten regelmäßig Metriken erstellt und die Gründe für ihre Abweichung von den Zielindikatoren analysiert werden, Maßnahmen zur Verbesserung der Indikatoren ergriffen werden, dh nicht nur der Testprozess, sondern auch der gesamte Produktionsprozess des Projekts optimiert werden.

Natürlich waren nicht nur Tester an der Verbesserung der Qualität beteiligt, sondern auch Analysten und der Entwicklungs- und Release-Manager waren an der Optimierung des Prozesses beteiligt. Die DevOps-Ingenieure waren alle wichtige Teilnehmer am Prozess, da jeder die Qualität des Releases verbessern und seine Arbeit verbessern wollte. 

Ein Beispiel dafür, wie die Erfassung von Metriken und Zielen für eines der abgeschlossenen Projekte aussieht:


Methode zur Bewertung der Arbeitskosten für Tests


Um den Projektmanager über genauere Fristen für den Abschluss des Tests zu informieren, basierend auf der Erfassung von Metriken aus ähnlichen Projekten, wurde eine Methodik zur Bewertung des Testaufwands entwickelt, die die genaueste Berichterstattung über die Fertigstellungstermine der Tests ermöglicht und über die Risiken des Tests informiert.

Diese Technik wird bei allen GIS-Implementierungsprojekten verwendet. Unterschiede können nur in einigen Metrikwerten bestehen, das Berechnungsprinzip ist jedoch dasselbe.

Metriken zur detaillierten Bewertung der Testkosten


Zeitmetriken werden durch wiederholte Messungen der tatsächlichen Kosten von Testern mit unterschiedlichen Kompetenzstufen in verschiedenen Projekten erhalten, wobei das arithmetische Mittel genommen wird.

Die Zeit zum Registrieren eines Fehlers beträgt 10 Minuten (die Zeit zum Registrieren eines Fehlers im Bug-Tracker).
Die Zeit zum Überprüfen des Fehlers / der Verfeinerung beträgt 15 Minuten (die Zeit zum Überprüfen der Richtigkeit der Korrektur von 1 Fehler / Verfeinerung).
Zeit zum Schreiben von 1 TC (Testfall) - 20 Minuten (Zeit zum Entwickeln eines Testfalls im TestLink-System).
Zeit bis zum Abschluss von 1 TC - 15 Minuten (Zeit bis zum Abschluss der Prüfung eines Testfalls im TestLink-System).
Zeit für einen Test. Die Gesamtzeit, die durch Hinzufügen der Kosten in der Checkliste für die Spalte "Vorlaufzeit, min."
Testbericht Zeit - 20 Minuten (Zeit zum Schreiben eines Berichts gemäß der Vorlage).
Zeit für Fehler . Geplante Zeit für die Registrierung aller Fehler / Klarstellungen (Zeit für die Registrierung von 1 Fehler / Klarstellung * mögliche Anzahl von Fehlern / Klarstellungen (10 Fehler für die Überarbeitung - die geschätzte Anzahl von Fehlern pro Überarbeitung)).
Gesamtzeit auf DV (Fehlervalidierung) . Geplante Zeit für die Validierung aller gefundenen und korrigierten Fehler / Verfeinerungen (Zeit für die Validierung von 1 Fehler / Verfeinerung * geschätzte Anzahl von Fehlern / Verfeinerungen).
Vorbereitung der Testdaten. Die Zeit für die Aufbereitung von Testdaten wird subjektiv berechnet, basierend auf den Erfahrungen mit dem Testen ähnlicher Aufgaben im aktuellen Projekt in Abhängigkeit von verschiedenen Parametern (Umfang der Aufgabe aus Sicht des Testanalysten, Kompetenzen des Codeentwicklungsteams (neues unbekanntes Team oder bewährtes Team, für das Statistiken zur Arbeitsqualität vorliegen)). , Integration zwischen verschiedenen Modulen usw.).

Durch Messung der tatsächlichen Kosten eines der Projekte wurde Folgendes berechnet: 

  • nicht mehr als 1 Stunde pro Aufgabe bis zu 60 Stunden Entwicklungszeit,
  • nicht mehr als 3 Stunden pro Aufgabe bis zu 150 Stunden Entwicklungszeit,
  • Nicht mehr als 4 Stunden pro Aufgabe bis zu 300 Stunden Entwicklungszeit.

In besonderen Fällen können sich die geplanten Kosten für die Aufbereitung der Testdaten in Absprache mit dem Testmanager ändern.
 
Zeit, TC zu schreiben . Die Zeit zum Schreiben des TC, die geschätzt wird, nachdem die Checkliste zur Überprüfung und Priorisierung zum Testen bereit ist. Für den Regressionstest wurden TCs mit Priorität 0 markiert (Anzahl der Prioritätsprüfungen 0 * 20 Minuten (Schreibzeit für 1 TC)).
Zeit zum Rückschritt nach TC. Zeit für eine Iteration des Regressionstests gemäß TC im TestLink-System (Anzahl der TC * durchschnittliche Ausführungszeit von 1 TC (15 Minuten)). 
Risiken 15% der Zeit für den Test ist verlegt (Risiken bedeuten alle manuellen Operationen, Stürze, Blockierprobleme usw.). 
Gesamtzeit zum Testen.Die Gesamtkosten für das Testen eines HL (Vorbereitung der Testdaten + Testdurchführung + Zeit zum Registrieren von Fehlern / Klarstellungen + Validieren von Fehlern / Verfeinerungen + Zeit zum Regressieren gemäß Priorität TC 0 + Risiken) in h / h.
Gesamtzeit für die Aufgabe. Gesamtkosten für die gesamte Testaufgabe, angegeben in h / h (Gesamtzeit für das Testen + Zeit für den Bericht + Zeit für das Schreiben von TC).

Alle diese Metriken werden im Projekt verwendet, um verschiedene Aufgaben im Zusammenhang mit Planung und Arbeitsbewertungen zu lösen, sowohl vorübergehend als auch finanziell. Wie die Praxis gezeigt hat, ergibt eine solche Schätzung einen minimalen Fehler (nicht mehr als 10%), was ein ziemlich hoher Indikator für die Zuverlässigkeit der Schätzung ist.

Natürlich dürfen Sie keine Metriken verwenden oder Ihre Metriken gemäß Statistiken können sehr unterschiedlich sein, aber das Prinzip der Schätzung der Kosten für Testarbeiten kann auf jedes Projekt angewendet werden und die für Ihr Projekt und Ihr Team optimalste Berechnungsformel auswählen.

Kapitel 5. Rezept für einen erfolgreichen GIS-Testprozess


Es ist wichtig, Testmanagern und Testern zu zeigen, dass Sie bei Schwierigkeiten und neuen Aufgaben Lösungen finden, den Testprozess optimieren und versuchen können, die gesammelten Erfahrungen auf zukünftige Projekte anzuwenden. 

Ich habe Überraschungen für alle Leser vorbereitet - ein Rezept für einen erfolgreichen GIS-Testprozess und Dokumentvorlagen, die Sie herunterladen und für Ihre Projekte verwenden können.
Daher werde ich versuchen, das Rezept, wie der Prozess des Testens eines großen Informationssystems erfolgreich sein kann, und was wir empfehlen, in diesen Prozess einzubeziehen, kurz und präzise darzulegen.

Aus dem Analyseprozess:

  • Implementieren Sie Vorlagen für technische Anforderungen
  • Umsetzung der Regeln für die Entwicklung technischer Anforderungen in einer Gruppe von Analysten;
  • eine Regelung zur Benachrichtigung über die Bereitschaft der technischen Anforderungen des Projektteams zu entwickeln.

:

  • - ;
  • ;
  • ;
  • :

    ○ - ;
    ○ -;
    ○ ;
  • , , , , , ;
  • , , , , ;
  • ;
  • ;
  • ;
  • ;
  • (, , ..);
  • , , ;
  • Nutzen Sie die Empfehlungen erfahrener Kollegen, Entwicklungen aus anderen Projekten, fertige Spickzettel , führen Sie Brainstorming-Sitzungen mit dem Team durch und suchen Sie nach neuen Methoden zur Optimierung und Verbesserung des Prozesses.

Jetzt bereite ich mich gerade darauf vor, das neue GIS zu testen. So sieht mein Arbeits-Wiki aus, das bereits viele Punkte berücksichtigt, die wir empfohlen haben:


Überraschung für geduldige Leser.


Wenn Sie den Artikel bis zum Ende lesen, verdienen Sie ein Geschenk. Ich möchte Ihnen nützliche Vorlagen zur Verfügung stellen, die Sie in Ihrer Arbeit verwenden können:

  • Die Checklistenvorlage , die die Mindestempfehlung zum Testen von Schnittstellenelementen von Bildschirmformularen enthält (natürlich gibt es umfassendere Optionen für Überprüfungen, dies ist nur ein Beispiel), enthält Formeln zur Berechnung der Testkosten mit Erläuterungen zur Berechnungsmethode.
  • Testberichtvorlage ;
  • Matrixvorlage : Wissen / Verteilung nach Browsern / Plattformen / Urlaubsplan des Projektteams;
  • Eine Liste der wichtigsten Metriken für das Projekt mit Erläuterungen.

Ich hoffe, dass unsere Empfehlungen, Beispiele, Ideen, Links und meine Vorlagen vielen Teams helfen werden, den Testprozess kompetent aufzubauen, ihre Kosten zu optimieren und die Aufgaben in einem verantwortungsvollen und komplexen Projekt erfolgreich zu bewältigen. 

Wenn Sie dem LANIT-Testteam beitreten und an den GIS-Tests teilnehmen möchten, empfehle ich Ihnen, die offenen Stellen unseres Unternehmens zu prüfen.

Komm zu unseren Testschulen!
, , .


Ich wünsche Ihnen allen interessanten Projekten und viel Glück!

PS Es ist wirklich wichtig, eine kleine Umfrage durchzuführen. 

More articles:


All Articles