Buch "So testen Sie bei Google" - kostenlose elektronische Version

BildHallo habrozhiteli!

Das Buch beschreibt das Testen von Softwareprodukten bei Google: Wie Prozesse organisiert sind, wie Teams organisiert sind, welche Techniken verwendet werden, wer für die Qualität verantwortlich ist. Die Prinzipien, auf denen Google-Tests basieren, gelten für Projekte und Unternehmen jeder Größe. Die Autoren des Buches haben selbst an Google-Produkten gearbeitet, Testtools erstellt, Prozesse angepasst und Tests direkt durchgeführt.

Das Buch richtet sich an Fachleute aus der Softwareentwicklungsbranche: Testspezialisten, Programmierer, Manager.

Auszug. Risikominderung


Es ist selten möglich, die Risiken vollständig auszuschließen. Wir fahren ein Auto, obwohl dies gefährlich ist, aber müssen wir uns an die Arbeit machen? Im Allgemeinen bedeutet die Möglichkeit eines Unfalls nicht, dass es passieren wird, und höchstwahrscheinlich wird nichts Schreckliches passieren. Warum? Denn durch unser Handeln reduzieren wir das mögliche Risiko. Zum Beispiel fahren wir nicht, während wir betrunken sind, und fahren nicht unter Bedingungen mit unzureichender Sicht. So reduzieren wir Risiken.

Bei der Entwicklung von Softwareprodukten ist es am einfachsten, Risikobereiche zu vermeiden: Je weniger Code, desto weniger Risiko. Neben der Verwendung von „Axt und Axt“ können wir noch viel mehr tun, um die Risiken zu verringern:

  • , , .
  • -, , .
  • , .
  • .
  • , . , .

Die spezifische Lösung hängt von den Merkmalen der Anwendung und den Erwartungen des Benutzers hinsichtlich ihrer Sicherheit und Zuverlässigkeit ab. Als Tester können wir natürlich in den Prozess der Risikominderung einbezogen werden, aber wir sind sicherlich in den Prozess der Identifizierung involviert. Wir beginnen mit der Priorisierung der in der Tabelle rot markierten Merkmale. Wir wollen testen, um Risiken zu reduzieren. Dies ist wichtig: Wenn Sie nicht alles testen können, testen Sie zuerst das Wichtigste. Und das Wichtigste ist, dass es den größten Risiken ausgesetzt ist.

In einigen Projekten fragen Tester nach der Bereitschaft des Produkts zur Veröffentlichung. Für einen guten Tester reicht es aus, einen Blick auf die Heatmap zu werfen, um festzustellen, ob das Produkt noch im Ofen aufbewahrt werden muss oder ob es Zeit ist, es auf dem Tisch zu servieren. Wenn wir über den Start eines experimentellen Google Labs sprechen, ist das Vorhandensein roter Risikozonen nicht so wichtig, wenn sie natürlich nicht mit der Sicherheit zusammenhängen. Und wenn dies die Veröffentlichung einer neuen Version von Google Mail ist, sind sogar die gelben Zonen eine ernsthafte Gefahr. Eine so einfache Farbabstufung ist allen klar, auch Top-Managern.

Die Bedenken hinsichtlich der Risiken lassen mit der Zeit nach, und das große Volumen erfolgreicher Tests ist ein gutes Zeichen dafür, dass die Risiken auf einem akzeptablen Niveau liegen. Hier profitieren wir von der Verknüpfung von Testfällen mit einzelnen Produktmerkmalen und anschließend mit Attributen und Komponenten in der Risikotabelle. Die „ACC-Analyse“ ist ideal für diesen Fall. Deshalb haben wir dieses Tool einfach so erstellt.

James Whittaker Prescription Test Plan in zehn Minuten


, , . , , — ? , , . Google, , -. , , : «», « » — « » ( ). ’, , - , .

— . -, , — , , ( ), , , . : , ,
?

- , , , . , — . : ?

- , - . . : -.

, : - . - , .

, . : . , , .
-, .

. : « , - ». , , . , , , , .

, , , (Google Docs, App Engine, Talk Video . .), .

, ACC-. , . — , — . , . - — . , , .

’, - . . ,
- .

, . , . 80% . ? , , ? , (, , ) . , , .

. -!


Google Test Analytics basiert auf den oben beschriebenen Risikobewertungskriterien ("sehr selten", "selten", "manchmal", "oft"). Wir möchten die Risikoanalyse nicht zu einer schwierigen Aufgabe machen, da sie sonst nicht abgeschlossen wird. Die genauen mathematischen Details interessieren uns nicht, da die Zahlen wenig bedeuten. Es reicht zu wissen, dass „A“ riskanter ist als „B“, ohne auf die genaue Bedeutung der Risiken zu achten. Durch einfaches Wissen darüber, welche Chance riskanter ist als eine andere, kann der Testmanager die Arbeit der Tester effizienter verteilen. Und Leute wie Patrick Copeland können leicht entscheiden, wie viele Tester jedem Entwicklungsteam zugewiesen werden sollen. Das Verständnis der Risiken kommt dem gesamten Unternehmen zugute.

Die Risikoanalyse ist ein unabhängiges wissenschaftliches Gebiet, das in vielen Branchen anerkannt ist. Wir verwenden eine vereinfachte Version der Methodik, aber dies hindert uns nicht daran, uns für neue Forschungsergebnisse zu interessieren, um unseren Testansatz zu verbessern. Wenn Sie mehr über die Risikoanalyse erfahren möchten, beginnen Sie mit dem Artikel „Risikomanagement“ auf Wikipedia.

GTA hilft, Risiken zu identifizieren, und Tests helfen, sie zu reduzieren. Der Tester dient als Vermittler in diesem Prozess. Er kann interne Tests in einigen der riskantesten Bereiche oder Aufgabenentwickler und Entwickler beim Testen durchführen, um Regressionstests hinzuzufügen. In seinem Arsenal befinden sich weitere Tools: Forschungstests, die Gewinnung interner und Beta-Benutzer sowie die Stärke der externen Community.

Es liegt in der Verantwortung des Testers, alle gefährdeten Bereiche zu kennen. Er sollte versuchen, die Risiken in irgendeiner Weise zu reduzieren, die ihm unterliegt. Hier sind einige Empfehlungen, die wir im Umgang mit Risiken nützlich finden.

  1. Schreiben Sie für die riskantesten Funktionen und rot markierten Attribut- / Komponentenpaare eine Reihe von User Stories, Verwendungsszenarien oder eine Testanleitung. Bei Google liegt die Verantwortung für die riskantesten Gelegenheiten beim Tester. Er kann seine Arbeit mit Kollegen koordinieren, verschiedene Werkzeuge verwenden, aber die persönliche Verantwortung liegt immer noch bei ihm.
  2. , . , GTA? ? ? . , , .
  3. , / , , . .
  4. — . , . , . , : «!», . , .
  5. , . , , . , « ?» « ?». Google , , .
  6. 6 , , , . ! .




, . , , , .

, , - . - , , , . , , . , , .

, , . -, - — !

— . - . — . Google , . -: Google Documents — , .

, , , . — .

Wir werden mit risikoarmen Chancen nicht zu fehlerhaft sein. Wir können entscheiden, dass das Schreiben von Testfällen für diese Bereiche zu teuer ist. Stattdessen können wir uns auf Forschungstests oder Crowdsource-Tests beschränken. Um die Arbeit von Testern aus der externen Community zu verwalten, verwenden wir häufig das Konzept von Touren - dies sind allgemeine Anweisungen für Forschungstests. Einfach ausgedrückt, dieser Ansatz gibt Ihrer Anfrage die Einzelheiten, die Sie benötigen. Wenn Sie beispielsweise die Community fragen: „Machen Sie eine FedEx-Tour für eine solche Reihe von Funktionen“ - wir werden ein viel besseres Ergebnis erzielen, als nur die Anwendung zu geben und auf das Beste zu hoffen. Wir ermitteln sofort die zu testenden Funktionen und geben Anweisungen dazu.

Crowdsourcing




— . , , - ! , . . ?

, , . , , — , , -. , Chromium, . , , . , .

( ) — . , , . , , ? — .

, , , . , : -1000 , : Chrome, : 1 = 1000 20 = 50 . .

, , , . , , . Chrome, , , ( « Chrome»). . , . « , » , .

- — Google: , , . , . , , , (, uTest). .

Die Stärke der ACC-Analyse besteht also darin, dass wir eine Liste von Produktmerkmalen erhalten, die nach Risiko sortiert und verschiedenen Leistungsträgern zugewiesen werden können. Tester, die an demselben Projekt arbeiten, erhalten möglicherweise unterschiedliche Testfunktionen. Interne Benutzer, „zwanzig Prozent“ Teilnehmer, Tester, Community-Tester, Entwickler und Entwickler in Tests erhalten alle ihre Funktionslisten, und zur Freude des Testers werden wichtige Bereiche mit weniger Überschneidungen abgedeckt, als wenn wir nur den Antrag für ausgehändigt hätten Testen für alle.

Die Arbeit des Testers endet im Gegensatz zur Arbeit des Entwicklers beim Testen nicht mit dem Einlass des Produkts.

» Laden Sie epub und pdf herunter

All Articles