Benötige ich einen automatischen Test? Wann wird es benötigt? Welchen Wert bringt es?
Der Artikel beschreibt, wann und warum Tests als solche erforderlich sind und in welchen Fällen deren Automatisierung erforderlich ist.
Während der Diskussion zu diesem Thema im Club zu ihnen gehalten. Francis Bacon („KifB Web-Meetings“ in Teleram), Kollegen tauschten Erfahrungen aus und schrieben ihre Gedanken auf.
Testautomatisierung ist erforderlich, wenn sie Wert bringt. Wann bringt das Testen selbst Wert? Zwei Fälle wurden identifiziert.
Wenn der Prozess Fehler in der Software erkennt, bevor er zum Kampf aufbricht
Wenn das Testen der neuen Version Fehler ergab, die später behoben wurden, war dieses Testen nicht umsonst.
Aber was ist, wenn sich die Situation umkehrt? Wenn die Tests keinen Fehler fanden, sie aber im Kampf auftauchten? Wenn auf dem Prüfstand Fehler festgestellt wurden (einschließlich des Prüfstands, der am nächsten am Kampf konfiguriert ist).
Es wird vermutet, dass in diesem Fall die Prüfung schlecht durchgeführt wurde.
Wie kann man die Qualität der Tests messen? Für diesen Fall ist die Metrik geeignet = die Anzahl der Fehler in der Testumgebung / (die Anzahl der Fehler in der Test- + Kampfumgebung). In diesem Fall wird die Anzahl der Fehler mit dem Grad der Kritikalität gewichtet.
Aber was ist, wenn beim Testen keine Fehler gefunden wurden und nicht auf dem Kampfserver gefunden wurden?
Es wird behauptet, dass in diesem Fall das Testen als solches keinen Wert gebracht hat und diese Arbeiten vergeblich durchgeführt wurden (mit Ausnahme des folgenden Falls, auf den wir später noch eingehen werden). Aus Leans Sicht ist dies ein Verlust.
Wann ist das möglich? Wenn sich das zu testende Modul nicht geändert hat. Was kann ein Modul ändern?
- Änderung des Modulcodes.
- Ändern der Version der verwendeten Bibliotheken (einschließlich Betriebssystem, Datenbank usw.). Die Änderung kann auf die Anforderungen der Aufsichtsbehörden zurückzuführen sein, weshalb die Bibliothek in einem festgelegten Zeitrahmen aktualisiert werden muss.
- Das Ändern von Einstellungen oder Daten, die das Verhalten einer universellen Funktion ernsthaft beeinträchtigen, deren umfassende Tests unnötig schwierig durchzuführen sind, führte dazu, dass die Tests abgebrochen wurden. Beispiele:
- Das Festlegen von Werbeaktionen in Lösungen wie Siebel CRM oder Oracle ATG kann zu einer Verschlechterung der Leistung der Berechnungsfunktionen der Aktion führen, und die Möglichkeit einer umfassenden Überprüfung ist aufgrund der übermäßigen Flexibilität und Vielseitigkeit dieser Lösungen nicht in angemessener Zeit möglich
- Die HTML-Beschreibung der Produktkarte kann eine fehlerhafte Dokumentstruktur oder Fehler in der darin geschriebenen js-Codebeschreibung enthalten, wodurch die Produktkartenseite beschädigt wird
- Die Verwendung von Funktionen ist für diesen Zweck nicht vorgesehen (Hammernägel mit einem Mikroskop). Beispielsweise wird eine Änderung der Art der Last, die den Anforderungen nicht inhärent ist und daher beim Testen nicht berücksichtigt wird. Zum Beispiel lohnt es sich, vor dem Black Friday einen separaten Lasttest für die Zielseite durchzuführen. Wohin geht der Verkehr, wenn für diesen Seitentyp keine solchen Ladeanforderungen bestehen?
- Ändern des Verhaltens der API anderer Module, die das in der Entwicklung befindliche Modul verwendet. Insbesondere, wenn die API-Funktionalität nicht durch Regressionstests abgedeckt wird.
Da die Optionen für Änderungen unterschiedlich sein können und die Durchführung eines vollständigen Regressionstests Geld kostet, sind nicht alle Tests wert. Eine Steuerungsoption besteht darin, die Tests mit Tags zu versehen und vor dem Testen. Der Testmanager legt fest, welche Testsuite für einen bestimmten Teil der Änderungen zur Ausführung gesendet werden soll.
Wann muss ich in diesem Fall Autotests schreiben?
Zunächst werden beim automatisierten Testen Einstellungsprüfungen, Designtests und das Schreiben von Testeinstellungsfällen nicht abgebrochen! Und ersetzt sie nicht. Ist dies nicht der Fall, sollte die Automatisierung nicht behandelt werden. Gleichzeitig sollten Autotests nicht nur als das Skript selbst verstanden werden, sondern auch als Vorbereitung für die Ausführung und Verwendung der Ergebnisse.
Wenn Sie nach dem Erstellen des Codes Autotests schreiben, führt dies zu einer Erhöhung von time2market (was automatisch zu einer Erhöhung des verbundenen Kapitals führt). Wenn entschieden wird, den Code mit Autotests abzudecken, sollten Sie diese Autotests daher parallel zum Hauptcode im Entwicklungsparadigma von "TestFirst" oder "TDD" schreiben.
Der Hauptwert der Testautomatisierung ist die Reduzierung von time2market aufgrund des schnelleren Uploads der neuen Version.
Tests sind erforderlich, um die Leistung kritischer Prozesse zu gewährleisten.
Trotz der Tatsache, dass das Auto nie Feuer gefangen hat, ist das Vorhandensein eines Feuerlöschers nicht nutzlos.
Ein Fehler auf einer Website mit hohem Datenverkehr, bei dem kein Artikel zum Warenkorb hinzugefügt werden kann, kann zu größeren Verlusten führen als die Kosten für die Entwicklung und das Testen dieser Funktion im Laufe des Jahres.
Daher ist es notwendig, kritische Prozesse hervorzuheben, die regelmäßig überprüft werden (die es wert sind, durchgeführt zu werden, wenn Änderungen auftreten). Vergleichen Sie:
- Verlust durch Ausfallzeit der Funktion vom Zeitpunkt der Erkennung bis zu ihrer Korrektur,
- Kosten manuelle regelmäßige Tests oder deren Automatisierung und deren anschließende Implementierung während der Amortisationszeit.
Aber was ist, wenn regelmäßige Tests lange Zeit keine Fehler finden und diese nicht im Kampf auftreten? Dann bringt das Testen keinen Wert und ist daher nicht notwendig. Wann ist das möglich?
- Das in der Entwicklung befindliche Modul ist nicht sehr groß.
- Stabiles, hochkompetentes Team.
- Integrationen werden durch Tests geschlossen oder auf der anderen Seite gibt es keine Änderungen.
Ist es möglich, überhaupt keine Tests durchzuführen?
Dies ist möglich durch den Start mehrerer Installationen der Lösung und das Testen neuer Beta-Versionen an „Katzen“, sofern dies technisch möglich ist und solche Freiwilligen gefunden werden. Nach dem Auslegen der neuen Version wird die Telemetrie überwacht und bei Verschlechterung der Indikatoren ein Rollback durchgeführt. (Denken Sie daran, dass die Telemetrie im Kampf unabhängig von der Verfügbarkeit von Tests sein muss.)
Ein weiterer Fall für die Nützlichkeit des automatischen Regressionstests ist das API-Testen (API-Vertragstest), wenn diese API zur Unterstützung eines kritischen Prozesses erforderlich ist. Dies ist besonders wichtig, wenn die Entwickler eines anderen Moduls etwas ändern und keine Qualitätsprüfungen von Änderungen auf ihrer Seite durchführen.
Wenn keine Testautomatisierung erforderlich ist
Wenn Sie eine große Menge geerbten, nicht sehr hochwertigen Codes erhalten haben. Das Abdecken von Autotests mit solch einem Chaos erhöht das Chaos.
In diesem Fall lohnt es sich, das logische Modul dieser Lösung hervorzuheben. Nachdem Sie die Interaktionsebene dieses Moduls mit dem Rest des Codes ausgewählt haben, müssen Sie die Interaktion mit Autotests abdecken. Dies bietet Garantien für die Integrität des Verhaltens und der Integrität des Moduls nach seiner Neukodierung.
Autotests ersetzen keine manuellen Tests. Manuelle Tests werden meistens schneller und billiger durchgeführt als das Schreiben und anschließende Begleiten von Autotests. Insbesondere wenn Tests nach der Entwicklung des Codes durchgeführt werden, sollte von diesen Tests nur das Teil automatisiert werden, das für die regelmäßigen Tests kritischer Funktionen verwendet wird.
Und schließlich - eine Checkliste der Bereitschaft des Unternehmens für Autotests
Machen wir gleich eine Reservierung. Diese Checkliste ist nicht für jedermann geeignet. Sie richtet sich an Tester von Unternehmen, für die die Softwareentwicklung die Haupteinnahmequelle darstellt.
Checkliste
- Das Unternehmen zeichnet den Hauptprozess der Geschäftsabwicklung und weiß, wo Sie sich befinden.
- Das Unternehmen hat den Prozess der Wertschöpfung für Kunden ausgearbeitet.
- Die Aufgabenverwaltung wurde eingerichtet, dh alle Beteiligten bringen Aufgaben in den gewünschten Status. Und die Aufgaben sind typisiert.
- Das Unternehmen hat Testziele formuliert.
- Die Überschriften der Aufgaben im Tracker werden "gekämmt", dh anhand des Titels können Sie verstehen, um welche Art von Aufgabe es sich handelt.
- Die Aufgabenregistrierung ist verwaltbar und spiegelt jederzeit den aktuellen Status und die Richtlinien des Projekts / Produkts wider.
- Es gibt ein Anforderungsregister, das überschaubar ist.
- Es gibt eine Rückverfolgbarkeit der Aufgabenanforderungen.
- Es gibt eine Rückverfolgbarkeit der Testanforderungen. Es ist bekannt, welche Anforderungen durch welche Tests abgedeckt werden.
- Aufgabentests sind nachvollziehbar. Es ist bekannt, dass bereits und wo getestet wurde.
- Es gibt eine Matrix des Einflusses der Komponenten aufeinander.
- Aufgaben werden auf Komponenten zurückgeführt.
- Alles ist auf Versionskontrolle.
- Es gibt eine versionierte Richtlinie darüber, wer, wie und warum. Es gibt ein Verständnis dafür, warum Git Flow ein schlechtes Modell ist.
- Bestehende Standards: Codierung und andere
- Es gibt ein ci
- Es gibt eine Release-Richtlinie, in der insbesondere bestimmte Versionsmethoden vorgeschrieben sind.
- Es gibt ein Repository für Artefakte, aus dem Sie ein Produkt, das zur Installation bereit ist, eindeutig herausnehmen können.
- Es gibt eine Richtlinie zum Markieren von Artefakten nach verschiedenen Kriterien. Die statische Code-Analyse wird nicht vergessen.
- Das Produkt-Sweep-Medium steigt per Fingerklick an. Die Umgebung ist auch auf Versionskontrolle.
- Die Umgebung wird vollautomatisch auf Richtigkeit überprüft. Ports, Java-Version, ...
- Produkt entfaltet sich beim Klicken mit Scheck
- Das Produkt wird vollautomatisch für die gewünschte Aufgabe konfiguriert. Dies gilt übrigens auch für Geschäftskonfigurationen. Und das wird auch automatisch eingecheckt.
- Sie haben die Möglichkeit, alle erforderlichen Testdaten wiederholt und automatisch zu generieren. Generierungsskripte befinden sich ebenfalls in der Versionskontrolle und sind mit Produktartefakten verknüpft.
- Alle oben genannten Funktionen funktionieren für jede Version des Produkts.
- Sie haben eine Übermittlungspipeline in der Freigaberichtlinie registriert.
Abschließend danke ich den Gruppenmitgliedern für die Diskussion und Hilfe bei der Vorbereitung des Artikels.