Treffen Sie die Autoren des Juli-Artikels zum „ Testerkalender “ Andrei Marchenko und Marina Tretyakova, Tester und Analysten von Kontur. Diesen Monat werden die Jungs über Workflow-Modelle zum Testen von Analysen sprechen und darüber, wie sie vor der Entwicklungsphase mit dem Testen von Analysen begonnen haben. Die Erfahrung der Jungs wird Managern, Testern und Analysten mittelgroßer Produktteams nützlich sein, die nicht in einem Startup leben und für die Qualität wichtiger ist als Geschwindigkeit .

Analytics-Test-Workflow-Modelle

Modell 1

Der Tester arbeitet mit der Analyse, nachdem er die fertige Aufgabe erhalten hat. Er validiert die Aufgabe, indem er Analysen als Dokumentation dessen liest, was der Entwickler getan hat. Unabhängig von der Professionalität ist alles falsch. Fehler können in der Analyse oder im Entwicklercode auftreten.

Nachteile:

• Fehler in der Analyse werden nicht vor der Testphase erkannt.
• Es besteht das Risiko, dass die Aufgabe aus dem Testen zur Überarbeitung auf die Analyse zurückgeht. Infolgedessen erhöht sich die TimeToMarket-Aufgabe erheblich.

Während des Testens festgestellte Analysefehler sind teuer oder sehr teuer.

Vorteile:

• Die Zeit des Testers wird für Aufgaben reduziert, für die kein Analyst erforderlich ist (Infrastruktur, Refactoring).

Modell 2

Der Tester ist mit der Aufgabe verbunden, noch bevor sie in die Entwicklung übertragen wurde. Er betrachtet Prototypen einer Aufgabe oder liest nur die Dokumentation. Der Tester stellt dem Analysten alle Fragen zur Aufgabe. Der Analyst korrigiert die Kommentare umgehend. Der Tester führt Abnahmetests durch.

Nachteile:

• Der Tester muss ein angrenzendes Feld untersuchen (Design Analytics und TK).
• Wenn Sie zu diesem Modell wechseln, muss der Tester zunächst mehr Zeit mit dem Testen verbringen, da der Prozess "Die fertige Aufgabe ist angekommen - ich lese Analysen - ich teste" sich auf "die Beschreibung der zukünftigen Aufgabe - ich lese Analysen - ich teste Analysen - die fertige Aufgabe ist angekommen - ich teste" erstreckt.

Vorteile:

• Die Wahrscheinlichkeit, Analysefehler zu finden, nachdem die Aufgabe an die Entwicklung übertragen wurde, wird geringer
• Der Tester befindet sich bereits im Kontext der Aufgabe, wenn er zum Testen ankommt, daher prüft er sie schneller.
• Das Testen von Analytics erweitert den Horizont perfekt und bietet dem Spezialisten die Möglichkeit für den zukünftigen Übergang zur Analytics.
• Der Entwickler verbessert die Qualität seines Codes und des gesamten Produkts, da er vor dem Bestehen seiner Testlösung Abnahmetests besteht.

Wenn das Entwicklungsteam keine Überprüfung der Arbeit von Analysten hat, verbessert das Testen von Analysen die Qualität des Produkts und verringert das Risiko, Aufgaben mit Fehlern im ToR an die Entwicklung zu übertragen.

Als wir Testern, die am ersten Modell arbeiten, das zweite Modell empfahlen, hörten wir oft:

• "Wir haben in der Schlange und haben genug aktuelle Aufgaben, um mehr zu übernehmen."
• "Und sprich mit dem Manager."

Die Neugestaltung des Entwicklungsprozesses ist eine ernsthafte Führungsaufgabe.

Implementieren Sie Analytics-Tests vor der Entwicklung

Seit fast einem Jahr, wie im Kontur- Projekt. Der Standard im Entwicklungsprozess ist eine obligatorische Phase „Analytics-Tests“. Das Team kam nicht sofort dazu. Der Anstoß war die Zunahme der Anzahl der Aufgabenrenditen vom Testen bis zur Analyse und weiteren Verfeinerung.

Es war besonders schmerzhaft für große Aufgaben mit neuen Funktionen. Die in die Testphase übertragenen Front-End-Aufgaben waren roh, wurden häufig in den einfachsten Szenarien unterbrochen und im Hinblick auf die „Zweifachheit“ der Definitionen und Begriffe in der Analyse unterschiedlich implementiert.

Der Analyse-Testprozess wird nicht auf Knopfdruck oder durch irgendeine Art von Magie angezeigt. Dies ist eine mühsame Arbeit, die jedoch in Stufen unterteilt werden kann.

Stufe 0. Verkaufen Sie dem Team die Idee, Analysen zu testen

Sie können sich leicht eine Situation vorstellen, in der Sie plötzlich Feedback von Ihrer Arbeit mit Kommentaren, Vorschlägen und Korrekturen erhalten. Der erste Gedanke eines normalen Menschen wäre: „Warum hast du dich entschieden, mich zu testen? Sie vertrauen mir nicht? Sie überwachen die Qualität meiner Arbeit? “ Zu diesem Zeitpunkt ist es sehr wichtig, dass der Analyst nicht das Gefühl hat, auf Qualität überprüft zu werden, und im Falle eines fehlgeschlagenen Tests werden sie entlassen.

Eine Reihe von Fragen kann entfernt werden, wenn die Informationen im Schlüssel enthalten sind: „Dies gibt uns die Möglichkeit, sich früher über neue Funktionen zu informieren, die Testphase zu beschleunigen und die Einführung selbst kleiner Fehler im Code zu verhindern.“

Wenn Stufe 0 abgeschlossen ist, können Sie fortfahren.

Phase 1. Implementierung von Analytics-Tests im Entwicklungsprozess

Nachdem wir das Team überzeugt haben, beginnen wir mit der Einführung von Analysetests in den täglichen Workflow. Wenn der Workflow anfangs so aussah:

Das nach der Implementierung:

Wenn Ihr Team mehrere Analysten hat, die sich gegenseitig überprüfen, bevor sie die Aufgabe der Entwicklung übertragen, testen wir einen besseren Text. Wir meinen, dass Analytics Review es nicht testet, sondern nur einen Teil davon.

Stufe 2. Testen der Analyse

Es gibt Aufgaben, bei denen Prototypen die Textversion von Analytics ersetzen.

In diesem Fall wird der Prototyp auch als Text geprüft. Wenn Prototypen die Analyse ergänzen, ist es hilfreich, sich vor dem Lesen der Dokumentation die Entwurfslayouts zukünftiger Funktionen anzusehen. Dies ist Ihre einzige Chance, die Aufgabe als Benutzer zu betrachten, der die TOR nicht gelesen hat und nicht weiß, wie alles funktioniert und funktionieren sollte.

Was kann in Analytics überprüft werden:

1. Die vorgeschlagene Lösung erfüllt die Ziele der Aufgabe.

Wenn das Ziel der Aufgabe beispielsweise darin besteht, Feedback von Benutzern zu sammeln, sollte die Lösung das Aufzeichnen und Speichern von Benutzerantworten umfassen.

2. Einzigartigkeit der Interpretation.

Beispielsweise kann der Wortlaut „Informationen für den aktuellen Tag anzeigen“ unterschiedlich interpretiert werden. Sie können verstehen, wie Sie "Informationen für den in den Einstellungen ausgewählten Tag anzeigen" oder "Informationen für den Tag anzeigen, der heute gleich ist".

3. Durchführbarkeit der Entscheidung.

Machbarkeit ist die Fähigkeit, die in Analytics geschriebenen Anforderungen unter den bekannten Einschränkungen der Entwicklungsumgebung, der Programmiersprache und der algorithmischen Komplexität zu implementieren. Gute Analysten können sich den Algorithmus merken, mit dem sie das von ihnen geschriebene Problem lösen können. Es ist keine Tatsache, dass die Entwickler nach diesem Algorithmus vorgehen (sie sind sachkundiger, sie werden Wege finden, um den Algorithmus optimal zu machen usw.), aber seine Anwesenheit zeigt die Machbarkeit der Aufgabe.

4. Testbarkeit.

Wie überprüft werden kann, ob die Bedingung "Suchergebnisse verbessern" erfüllt ist, ist unklar. Wenn wir jedoch die Bedingung „Suchergebnisse sollten dem Benutzer innerhalb von 1 Sekunde nach Drücken des Steuerelements„ Suchen “angezeigt werden - neu schreiben, ist dies klar.

5. Verfügbarkeit alternativer Szenarien.

In der Formulierung „Wenn Nummer und Datum angegeben sind, drucken wir Nummer und Datum aus. Wenn das Datum nicht angegeben ist, drucken wir nur die Nummer "Es gibt nicht genügend Skripte:

• Es gibt keine Nummer, aber es gibt ein Datum.
• keine Daten.

6. Ausnahmebehandlung.

In der Formulierung „Sie können ein Dokument nur im Excel-Format herunterladen“ ist nicht klar, was passieren soll, wenn wir Dateien anderer Formate hochladen, und welcher Fehler beim Herunterladen angezeigt wird.

Artefakte beim Testen von Analysen

Welche Artefakte können nach dem Testen der Analyse verbleiben:

• kompilierte Testfälle
• Checklisten für Entwickler.

Checkliste für den Entwickler - die notwendigen, umfassenden und grundlegenden Überprüfungen der wichtigsten Szenarien, die funktionieren sollten, um getestet zu werden. Es ist auch ein Werkzeug zur Verbesserung der Codequalität. Bevor der Entwickler die Aufgabe zum Testen einreicht, besteht er die Checkliste und identifiziert Fehler schnell selbst.

Der Entwickler muss überredet werden, die Checkliste des Testers durchzugehen, die inneren Sorgen des Entwicklers zu beseitigen, "sie testen mich", und sich darauf zu konzentrieren, "den Prozess zu beschleunigen, das Testen zu beschleunigen, die Qualität zu verbessern". Infolgedessen geht unser Entwickler diese Checklisten durch und freut sich, dass nicht der Tester die Fehler gefunden hat, sondern er selbst ("niemand wird wissen, was ich in einem solchen Bullshit-Szenario durcheinander gebracht habe").

Was ist das Ergebnis?

Auf den ersten Blick scheint die Einführung einer neuen Phase im Entwicklungsprozess TimeToMarket nur zu erhöhen, aber dies ist eine Illusion. Zunächst ist der Analyse-Testprozess natürlich neu und ungetestet, und der Tester wird mehr Zeit damit verbringen. Wenn er in Zukunft Erfahrungen sammelt, kann er diese schneller durchführen. Die Ergebnisse, die in der Phase der Testanalyse erzielt wurden, verkürzen die Zeit in der Phase der direkten Tests und reduzieren die Anzahl der Rückgaben auf ein Minimum.

Dieser Analysetestprozess wurde in mehreren Contour-Teams implementiert. Entwicklungsteams erhielten eine Reihe unbestreitbarer Vorteile:

• Zeitersparnis in der Testphase: Es fallen keine Kosten für Testdesign und Testanalyse an, da alles bereits im Voraus erledigt wurde.
• Beschleunigung des Feedbacks an den Entwickler über die Checkliste, bevor wir kritische Fehler finden,
• Alle Interessenten können die Checklisten vorab überprüfen und einige Überprüfungen hinzufügen (in der Testphase ist diese Aktion "teurer").

Wir glauben, dass Sie diese Vorteile nutzen können, indem Sie die Analyse-Testphase in Ihrem Projekt implementieren.

Liste der Kalenderartikel:
Versuchen Sie einen anderen Ansatz
Angemessene Paartests
Feedback: wie es passiert
Tests optimieren
Lies ein Buch
Analytics-Tests
Der Tester muss den Fehler erkennen, Caner lesen und den Umzug organisieren.
Dienst laden
QA-Service-Metriken
Testen Sie die Sicherheit
Lernen Sie Ihren Kunden kennen
Rückstand nehmen