💪🏽 🔘 🚆 Warum und wie testen wir das Update? ⏯️ 🧜🏿 👩🏾‍🎓

In diesem Artikel werde ich erklären, warum es so wichtig ist, das Testen von Produktupdates nicht zu vergessen und wie dieser Prozess in unserem Unternehmen funktioniert. Die Stabilität von Updates hängt vom Ruf des Produkts und dem Vertrauen der Benutzer in Ihre Innovationen ab. Aus eigener Erfahrung kann ich sagen, dass ich manchmal vor dem Starten eines Updates, beispielsweise am Telefon, lieber mindestens einen Tag warte und die Kommentare lese (sie sind immer nur für die neueste Version relevant). Wenn die Kommentare missbräuchlich sind, geht die Wahrscheinlichkeit, dass ich mich für eine Aktualisierung entscheide, gegen Null. Die Bewertung der Anwendung aufgrund negativer Kommentare sinkt, und es ist nicht so einfach, sie wiederherzustellen, da Sie den Benutzer für die Installation eines neuen Updates interessieren müssen, was er jetzt befürchten wird.

Womit sind Benutzer normalerweise unzufrieden?

Die Anwendung funktioniert nach dem Update überhaupt nicht. Zum Beispiel weiß es einfach nicht, was mit den Daten im alten Format zu tun ist;
Boni, Rabatte, Benutzer-Ersparnisse (Spiele, Geschäfte, Cafés) gingen verloren;
Die neue Funktion, für die das Update angekündigt wird, funktioniert nicht.
Ein neues Feature funktioniert, aber einige der alten sind abgefallen.

All diese Probleme sind sowohl für die mobile Anwendung als auch für das DLP-System relevant, das wir zu Hause testen. Weiter darüber, womit wir es zu tun haben.

Was wir veröffentlichen und was aktualisiert werden muss

Unser Unternehmen bietet Kunden eine Lösung zum Schutz vor dem Verlust von Unternehmensinformationen mit der Möglichkeit, diese für jedes Unternehmen je nach Bedarf separat zu konfigurieren. Die Hauptelemente des Systems sind seine Einstellungen (nach welchen Kriterien werden die Eindringlinge durchsucht) und Ereignisse (aufgezeichnete Vorfälle).

Das Produkt besteht aus mehreren Teilen. In diesem Artikel werden wir den InfoWatch Traffic Monitor-Vorfallanalyse- und Speicherserver betrachten. Das Produkt läuft unter dem Betriebssystem der Linux-Familie und verfügt über eine eigene Datenbank. Der Sicherheitsbeauftragte verwendet die Webkonsole für die Arbeit. Derzeit werden zwei verschiedene Linux-Distributionen und zwei Datenbanken unterstützt. Das System kann auf verschiedene Arten installiert werden: All-in-One, wenn sich alle Komponenten auf einer Maschine befinden; und verteilte Installation, wenn Systemkomponenten auf verschiedenen physischen Maschinen vorhanden sind.

Zusätzlich zu der deklarierten Funktionalität des Systems müssen wir ein Update von den Hauptversionen N-1 und N-2 auf N sowie ein Update von allen Nebenversionen - Patches und Hotfixes jeder Version - garantieren. Dies liegt an der Tatsache, dass unsere Kunden häufig über eine ziemlich komplizierte IT-Infrastruktur verfügen. Das Update kann lange dauern. Daher ist es wichtig, die Anzahl der Updates zu begrenzen und nicht zu oft durchzuführen, um Ausfallzeiten zu vermeiden.

Alle diese Bedingungen bieten eine ausreichend große Anzahl von Konfigurationen unseres Produkts, für die wir jeweils ein erfolgreiches Update garantieren müssen. Damit ist ein Update gemeint, durch das:

Benutzerdaten gehen nicht verloren
alte Funktionen sind nicht kaputt
Neue Funktionen stehen zur Verfügung

In diesem Fall ist die Priorität der Anforderungen aus der obigen Liste in absteigender Reihenfolge der Wichtigkeit. Wenn Sie beispielsweise Prioritäten von der Ebene der Arbeit mit DLP-Systemen auf die Ebene der oben genannten Benutzeranwendungen übertragen, ist das Speichern des Spielbenutzers wahrscheinlich wichtiger als die Möglichkeit, ein neues Spiel zu starten. Und dem Benutzer von Anwendungen für die Bestellung von Lebensmitteln ist es egal, wie niedlich das neue Menü ist, wenn die Schaltfläche "Bestellung senden" nicht mehr funktioniert.

Betrachten Sie das Beispiel mit unserer Update-Tabelle, wenn die Hauptversion 3 veröffentlicht wird. Für Version 1.0.0 wurden zwei Patches und drei Hotfixes veröffentlicht, und für Version 2.0.0 gab es zwei Hotfixes.

1.0.0	2.0.0	3.0.0
1.0.1	2.0.1
1.0.2	2.0.2
1.1.0
1.1.1
1.2.0

Insgesamt haben wir im Beispiel neun Versionen, von denen wir auf die neue Version 3.0.0 aktualisieren müssen. Für jede Version unseres Produkts gibt es zwei Betriebssysteme und zwei Datenbanken. Jene. Insgesamt werden 27 aktualisierte Konfigurationen veröffentlicht. Und wenn wir auch verschiedene Installationsmethoden anwenden, kann diese Zahl leicht mit zwei multipliziert werden. Als Ergebnis erhalten wir 54.

Jede unserer Versionen enthält eine Reihe schwerwiegender (unter dem Gesichtspunkt der Auswirkungen auf das Produkt) Funktionen. Methoden zur Anpassung des Systems können sich ändern, die Analysesysteme werden verfeinert, Vorfälle werden durch neue Daten ergänzt, die Version der Umgebung ändert sich, z. B. die Version des Betriebssystems oder der Datenbank usw.

Historisch...

Seit jeher haben wir beim Testen von Produktupdates einen Forschungsansatz entwickelt. Er bewies sich unter den Bedingungen einer guten Kenntnis des Produkts und einer kleinen Anzahl von Umgebungen und getesteten Konfigurationen. Aber die Zeit verging, das Team wuchs und änderte seine Zusammensetzung: Sowohl Tester als auch Entwickler kamen und gingen, und einige undokumentierte Funktionen wurden sicher vergessen.

Das Planen von Forschungstests ohne gute Produktkenntnisse ist eine undankbare Aufgabe, die mit folgenden Konsequenzen behaftet war:

Das Testen von Updates dauerte jedes Mal anders. Häufiger wurde die Zeit nach dem Restprinzip zugewiesen, da das Update getestet wurde, wenn das Produkt bereits stabilisiert ist und der letzte Schliff vor der Veröffentlichung verbleibt.
Manchmal wurden einige Umgebungen vergessen.
, , . , , , «» - .

Die vorbereitende Vorbereitung erfolgte ebenfalls hauptsächlich nach Ermessen des Testers, der die Aufgabe erhielt und manchmal ohne Berücksichtigung aller Änderungen in der Version.

Zusätzlich zu den internen Merkmalen des Testprozesses fügte die Tatsache, dass in der Dokumentation nicht die Änderungen beschrieben wurden, die bei der Funktionalität des Produkts auftraten, dem Feuer Kraftstoff hinzu. Somit konnten wir nicht testen, was sich geändert hat, sondern was von der aktuellen Version überhaupt nicht betroffen war.

Infolgedessen war es unmöglich, aus dem Aktualisierungstestbericht klar zu verstehen, welche Überprüfungen durchgeführt wurden, bei welchen Werten usw.

Trotzdem waren wir einige Zeit mit den Ergebnissen der Forschungstests zufrieden: Es gab nicht so viele militärische Mängel für das Upgrade und es gab keine Ressourcen für Änderungen zum theoretischen Vorteil.

Etwas ist schief gelaufen

Die Situation änderte sich, als sich dennoch kritische Aktualisierungsfehler bei unseren Kunden einschlichen. Meistens wurden sie irgendwo außerhalb der Hauptaktualisierungsszenarien gefunden und waren mit Situationen verbunden, in denen beispielsweise ein in der vorherigen Version erstelltes und arbeitendes Analysetechnologieelement die Aktualisierung blockierte oder einige Ereignisse in der Clientdatenbank verloren gingen oder das kritischste Szenario Als nach dem Upgrade einige der Dienste nicht gestartet wurden und wir ein nicht funktionsfähiges Produkt erhielten. Auch bei unseren Kunden treten grundbedingte Mängel auf.

In dieser Situation hat uns der aktuelle Prozess nicht mehr zufrieden gestellt. Etwas musste geändert werden.
Wir haben zunächst Probleme formuliert, die uns unserer Meinung nach daran gehindert haben, das Update besser zu testen. Im Anschluss an die Diskussion wurde die folgende Liste von Problemen erstellt:

;
, ;
, , , , ;
, ;
;
. ? ? ? ?

Außerdem haben wir für jedes identifizierte Problem versucht, eine angemessene Lösung zu finden. Neben der Lösung spezifischer Probleme, die wir für uns selbst formuliert haben, haben wir uns im Verlauf der Diskussionen entschlossen, Anforderungen für den Testprozess selbst vorzulegen, an denen wir weiter arbeiten möchten.

Der Prozess sollte offener und transparenter gestaltet werden, daher verzichten wir vollständig auf Forschungstests zugunsten von Testfällen.

Um die erforderlichen Testfälle zu erstellen, benötigen wir Informationen zu Änderungen zwischen Versionen. Diese Informationen müssen von Produktentwicklern und Analysten angefordert werden.

Beim neuen Ansatz verwenden wir eine Kombination aus Überprüfungen von Systemobjekten (unverändert und während des Updates geändert) + Rauchprüfungen der Funktionalität (sowohl alte als auch neue oder geänderte alte).

Für das Upgrade wird die schwierigste Option zur Installation des Systems ausgewählt - die verteilte Installation. Für alle Betriebssysteme und DBs. Die einfacheren Optionen werden als Sonderfälle weggelassen.

Diese Kombination von Prüfungen gibt uns die Möglichkeit, die folgenden Systemkomponenten zu testen:

DB
Web (Frontend, Backend);
Linux-Komponenten

Infolgedessen wurde die Lösung für jedes unserer Probleme wie folgt dargestellt:
Es gibt nicht genügend Informationen zu den Änderungen in der aktuellen Version. Unzureichende Systemkenntnisse, nicht genügend Informationen über das System. Gemeinsam mit Analysten und Entwicklern ermitteln wir die sich ändernden Bereiche des Produkts zwischen der aktualisierten und der aktuellen Version.

Das Testen von Updates wird zur Regression. Es werden Funktionstests durchgeführt, keine Systemobjekte und Operationen an diesen. Wir werden das Update an Testfällen in Form von Rauchtests der Funktions- + Datenverifikation testen.

Bild

Unverständliche Berichterstattung. Berichterstattung und Ergebnisse können aus Testfällen entnommen werden.

Der Prozess ist undurchsichtig. Nach der Lösung jedes einzelnen Problems wurde ein neuer Prozess gebildet, der durch unsere Bedürfnisse gerechtfertigt und darüber hinaus so festgelegt wurde, dass sich jedes Mitglied des Teams nun mit seinen Prinzipien vertraut machen konnte.

Neuer Prozess

Infolgedessen haben wir einen ziemlich effektiven Prozess aufgebaut.

Wir haben die Tests in mehrere Phasen unterteilt, wodurch noch mehr ungeplante Boni erzielt wurden, die im Folgenden beschrieben werden:

Ausbildung.
- Wir analysieren die Änderungen im System und bereiten sie gemeinsam mit Analysten und Entwicklern auf sich ändernde Bereiche vor.
- In Übereinstimmung mit den Ergebnissen der Analyse erstellen wir eine Liste von Systemobjekten, die zum Testen von Aktualisierungen vorbereitet wurden.
- Für jedes Systemobjekt wird der erforderliche Satz von Zuständen, Status und Parametern bestimmt.
- Wir erstellen Stände mit der erforderlichen (aktualisierten) Version des Produkts.
- , .
- ( ).
- smoke- , .
:
- ;
- (, , , );
- , .
- .
- -, .
- .
- , .
- Überprüfungen von Vorgängen an Objekten (Erstellen, Bearbeiten, Löschen).
- Überprüfen der Interaktion von Objekten mit anderen Objekten (Erkennung).

Vor- und Nachteile des Ansatzes

Wir haben unser Ziel erreicht, nämlich:

Der Prozess ist transparent geworden. Wir wissen, dass wir testen, wie, wie viel Zeit es dauern wird und welche Artefakte ausgegeben werden. Wir haben objektive Kriterien erhalten, anhand derer wir unser Urteil über ein funktionierendes oder nicht funktionierendes Produktupdate abgeben konnten.
Die Berichte wurden klar. Das Vorhandensein von Testfällen und ein Bericht über die Ergebnisse ihrer Passage ermöglichten es, dem Projektmanager und dem technischen Direktor schnell über die Qualität der erstellten Baugruppe Bericht zu erstatten.
Größere und verständlichere Abdeckung als bei einem Forschungsansatz.
Jetzt testen wir eine Änderung der Daten und Funktionen. Dank der Reaktionsfähigkeit von Analysten und Entwicklern können wir mit hoher Genauigkeit sagen, was sich im System geändert hat und wo die Gefahr besteht, dass ein Fehler auftritt.

Bei einer neuen Teststrategie konnten wir jedoch das offensichtliche Minus des neuen Ansatzes nicht übersehen - eine signifikante Verlängerung der Testzeit.

Wir verbrachten nicht nur Zeit mit direkten Tests, wie dies auch bei Forschungstests der Fall war. Neue Zeitkosten waren hauptsächlich mit der Vorbereitung auf Tests verbunden, nämlich:

Änderungsanalyse;
Erstellung, Befüllung, Wartung von Ständen zur Aktualisierung;
Aktualisieren alter Testkits und Erstellen neuer.

Dieses Minus könnte durchaus entscheidend für die Entscheidung sein, die neue Methodik aufzugeben, wenn nicht für ein „aber“.

Alle Vorbereitungen, und dies ist die zeitaufwändigste Phase, könnten durchgeführt werden, sobald die endgültige Zusammensetzung der Freisetzung gebildet wurde, auch ohne ein fertiges Produkt. Auf diese Weise „verteilen“ wir die Zubereitung gemäß dem Testplan, ohne die übermäßig gesättigte Vorfreigabezeit zu überlasten. Es mussten nur noch die Tests am fertigen stabilisierten Produkt bestanden werden.

Insgesamt haben wir nach den Ergebnissen der ersten Stufe der Verbesserungen Folgendes erhalten: Wir haben begonnen, mehr Zeit mit Tests zu verbringen, aber gleichzeitig haben wir einen transparenten Prozess, eine klare Darstellung der Ergebnisse und mehr Abdeckung, was uns Folgendes ermöglicht:

Erkennen Sie weitere Fehler, wenn Sie Produktaktualisierungen in Ihrer Abteilung überprüfen.
Reduzieren Sie die Anzahl der Fehler, wenn die Implementierungsingenieure unsere Kunden aktualisieren.
Reduzieren Sie die Anzahl der vom technischen Support erhaltenen Mängel.

Was weiter? - über Optimierung

Es hätte gut geregelt werden können, aber Zeit ist immer Geld. Darüber hinaus wurden bereits nach den Ergebnissen des ersten Einbruchs der neuen Methodik Möglichkeiten zur Optimierung der Zeitkosten deutlicher sichtbar.

Wir gingen auf zwei Arten:

Optimierung basierend auf der Analyse von Testläufen: Hier haben wir offensichtliche und implizite Abhängigkeiten der Testergebnisse von den verwendeten Umgebungen identifiziert. So sind Funktionstests verlaufen.
Testautomatisierung. Dann kam unser Automatisierungsteam zur Rettung.

Ich werde etwas mehr über jeden Weg sprechen.

Erster Weg: Optimierung basierend auf der Analyse von Testläufen. Auf

diese Weise haben wir uns entschieden, den Update-Test zwischen Hauptversionen zu optimieren, d. H. zwischen denen, bei denen sich die Funktionalität erheblich geändert hat.

Das erste, was uns auffiel, waren die Tests, die von der Datenbank und nur von der Datenbank abhängen. Wir konnten verstehen, welche Überprüfungen ausreichen, um einmal an jeder Basis durchgeführt zu werden, und sie dann vollständig von unserer Kombinatorik mit dem Betriebssystem ausschließen.

Der zweite Schritt war der „Zusammenbruch“ der volumetrischen Überprüfungen der alten Funktionalität in einer Checkliste. In den ersten Iterationen stützte sich die Funktionalität, unabhängig davon, ob sie in der aktuellen Version, in der vorherigen oder immer erschien, auf einen eigenen vollständigen Test. Jetzt basieren vollwertige Tests nur noch auf neuen Funktionen, während die alte Funktionalität in der Checkliste überprüft wird.

Darüber hinaus war dieselbe Checkliste für uns bei der Veröffentlichung von Patches und Hotfixes sehr nützlich. Neben Updates zwischen Hauptversionen ist es auch wichtig, nach Updates innerhalb der Version zu suchen.

Der zweite Weg: Testautomatisierung

Zunächst möchte ich einen Vorbehalt machen, dass wir die Aktualisierung der Testautomatisierung nicht konzipiert haben, weil sie allgemein akzeptiert wurde und allgemein einen guten Ton hat, sondern weil die Aktualisierung die Art von Tests ist, die in keiner Version ausgeschlossen werden kann, sei es in der Hauptversion Release, Patch oder Hotfix. Wir haben diesen Pfad gewählt, um die Zeit zum Testen von Updates für kleinere Versionen, nämlich Patches und Hotfixes, d. H. Versionen, zwischen denen sich die Zusammensetzung der Funktion nicht ändert. In diesem Fall sah die Testautomatisierung sehr effizient aus.

Zu diesem Zeitpunkt ist das Testen von Updates beim Freigeben von Patches und Hotfixes fast vollständig automatisiert.

Das Testen von Updates, wenn Hauptversionen veröffentlicht werden, wird in manuelle und automatisierte Tests unterteilt. Manuelles Überprüfen auf veränderbare Bereiche, die von Funktionen betroffen sind. Tests für unveränderliche Bereiche werden automatisch verfolgt. Meistens handelt es sich eher um die Wiederverwendung von Autotests, die bereits für frühere Versionen geschrieben wurden, mit nur geringen Aktualisierungen für eine neue.

Um den Prozess der Automatisierung von Testfällen zu starten, mussten wir sie weiter verfeinern, da die Testsprache eines manuellen Testers viel mehr Schwierigkeiten zulässt, als sich ein Autotest leisten kann. Das heißt, wir haben auch Zeit für die Vorbereitung von Tests für die Automatisierung eingeplant, was sich fast schon beim ersten Durchgang ausgezahlt hat.

Zusammenfassung

Wir hatten einen Forschungsprozess zum Testen von Updates. Irgendwann hat er aufgehört, uns zufrieden zu stellen, weil die Qualität des Updates spürbar nachgelassen hat. Wir haben keinen Ersatz für Forschungstests als fertige Technik ausgewählt, sondern ihn basierend auf den von uns identifizierten Problemen entwickelt. Die Entwicklung einer neuen Methodik, die wir verwenden und weiter verbessern, wurde durch vorbereitete Problemlösungen sowie allgemeine Wünsche für den Testprozess beeinflusst.

Ich glaube nicht, dass wir in dieser Situation ein Fahrrad erfunden haben, als wir den Weg eingeschlagen haben, einen eigenen Prozess zu entwickeln, der speziell auf unser Projekt und die Eigenschaften unseres Produkts zugeschnitten ist. Wenn wir den Prozess in seine Bestandteile zerlegen, erhalten wir im Allgemeinen allgemein anerkannte und weit verbreitete Techniken.

Trotz der Tatsache, dass die Ergebnisse der Arbeit, die wir in einem nicht zu umfangreichen Artikel gesammelt haben, fast zwei Jahre gedauert haben, vom Verständnis des Problems über die Einführung neuer Lösungen bis hin zur Optimierung der Tests.

Wir haben versucht, hier alle Vor- und Nachteile sowie die Fallstricke unserer Entscheidungen ehrlich zu beschreiben, damit die Geschichte nicht ausschließlich wie eine Erfolgsgeschichte aussieht: „Es war schlecht - es wurde gut“.

Wir hoffen, dass Sie unsere Erfahrung nützlich finden.

Materialautor:Tryzhova (Ryzhova Tatyana).

Warum und wie testen wir das Update?