So organisieren Sie die Arbeit der Qualitätssicherung. Ein praktischer Weg

Hintergrund

Kürzlich hat eine meiner Bekannten, QA-Ingenieurin, die lange Zeit in einem schleppenden Projekt gearbeitet hat, in dem ihre Verantwortlichkeiten streng umrissen waren, ihren Job gewechselt und ist in ein neu gestartetes Projekt eingestiegen. Nachdem sie ein paar Tage ohne die oben genannten Aufgaben verbracht hatte und ehrlich gesagt gelangweilt war, ging sie mit der Frage "Was soll ich tun?" Zum Management. worauf sie eine aussagekräftige Antwort erhielt "Organisieren Sie Ihre Arbeit." Und dann fiel sie in eine Betäubung. "Und wie ist das?" Und wirklich, wie?

Vor ein paar Monaten habe ich meinen Job selbst gewechselt und bin in ein englisches Projekt eingestiegen, das noch nie eine Qualitätssicherung hatte. Das Projekt selbst gibt es schon lange. Wie so oft hat ein Unternehmen, in dem es viel Geld gibt, ein Unternehmen gekauft, in dem es weniger Geld gibt, aber es gibt Kunden. Infolgedessen erhielt ein großes Unternehmen neue Kunden und minus einen Wettbewerber auf dem Markt. Mein Projekt erhielt eine Änderung des Managements und der Managementprinzipien.

In den ersten Tagen nach dem Treffen mit einem neuen Team hörte ich eine ehrliche, verwirrte Frage von einem der Entwickler des Londoner Büros: "Was werden Sie hier tun?"

In Wahrheit, nachdem ich zu diesem Projekt gekommen war und mich einige Tage umgesehen hatte, geriet ich wie mein Kollege zunächst in einen Stupor. Nicht, weil ich nicht wusste, was ich tun sollte. Vielmehr wusste ich nicht, wie ich mich richtig in die Fundamente einklemmen sollte, die sich hier entwickelt haben. Das Entwicklungsteam hatte eine wundervolle Existenz ohne Tester. Sie verwendeten Kanban, die Prinzipien der kontinuierlichen Lieferung, die fast täglich, sogar freitags, furchtlos, ruhig und sicher in der Produktion eingesetzt wurden. Und das alles, weil sie eine hervorragende Abdeckung mit Autotests hatten. Vielleicht das Beste, das ich je getroffen habe. Bei der Überprüfung der gegenseitigen Anfragen zögerten sie nicht, sich gegenseitig mitzuteilen, welche anderen Autotests hinzugefügt werden sollten. Der Autor der aktuellen Änderung hat seine Arbeit selbst in der Produktion eingesetzt, was bedeutet, dass er für seine Arbeit voll verantwortlich war. Und er trug es, obwohl ich im Projekt aufgetreten bin ... und vor dem Einsatz wäre es schön, meine Meinung zu hören.

Trotzdem war der Prozess natürlich nicht perfekt: Es kam vor, dass die Entwickler die Anforderungen nicht verstanden, Fehler übersehen und ziemlich oft auf der Seite der Kunden gab es einige Probleme, die Maßnahmen erforderten.

Angesichts der Notwendigkeit, meine Position im Team zu bestimmen, ging ich auch zur Führung. Nur unser Dialog war ganz anders aufgebaut, nicht wie der meines Freundes.

Arbeitsorganisation des QS-Ingenieurs

Stellen Sie die richtigen Fragen.

Also. Für einen Dialog berief ich die Leitung und die führenden Entwickler des Projekts ein. Es gibt eine wunderbare Regel des Managements, die ich natürlich nicht vergessen konnte: das Problem zu äußern, die Option zu äußern, es zu lösen, mindestens eine.

Trotzdem hatte ich zwei Fragen, deren Antworten ich nicht wissen konnte. Der einfachste Weg, um mit ihnen zu beginnen.

Erste Frage. Wie ist die Struktur der Organisation, nämlich wer steht über wem und wer ist für was verantwortlich?

Im Idealfall sollten Unternehmen ein hierarchisch dargestelltes Schema haben, das die Struktur des Unternehmens veranschaulicht. Aber ich bin nicht ideal, deshalb war es wichtig herauszufinden, an wen mit welchen Fragen und Vorschlägen Sie gehen können.

Die zweite Frage. Das Unternehmen hat QA Engineer in das Projekt eingeführt. Was erwarten sie von mir, was waren ihre Ziele bei der Eröffnung dieser Position?

Wenn die Antwort sehr spezifisch ist, bestimmt sie weitgehend den Arbeitsbereich. In meinem Fall enthielt die Antwort viele allgemeine verschwommene Sätze, die ich als "mach was du willst, aber damit bei uns alles in Ordnung ist" empfand.

Damit endete der erste Teil der Diskussion.

Wir diskutieren den Aktionsplan

Der zweite und vielleicht wichtigste Teil der Diskussionen war die Präsentation meines Arbeitsplans und seiner Begründung. Ich musste den Segen meiner Vorgesetzten erhalten, um mich und meine Aktivitäten ungehindert in das Projekt einzuführen.

Es ist angenehm offensichtlich, dass clevere Bücher und Theorien nicht von Grund auf neu existieren. Deshalb habe ich mich mit dem Wissen ausgestattet, das ich in Vorbereitung auf die ISTQB-Zertifizierung gewonnen habe. Nachdem ich aus Neugier Bücher über Testtheorie und Scrum gelesen hatte, habe ich alles durch ein Sieb mit zehnjähriger Erfahrung geführt und einen Piloten zusammengestellt Projekt für QS-Strategie.

Mit dem Management verhandelt und von ihm voll unterstützt, erwarb er später das Format des offiziellen Dokuments des Unternehmens. Als nächstes möchte ich Ideen zur Erstellung eines solchen Dokuments austauschen. Sie bildeten die Quintessenz früherer Erfahrungen und den Weg, den das aktuelle Projekt eingeschlagen hat. Und vielleicht werde ich hier in Form von Zitaten einige Fragmente in meiner ursprünglichen Form nachdrucken: auf Englisch. Ich bin sicher, dass für jeden QS-Ingenieur die Erstellung eines solchen Plans die Schlüsselantwort auf die Frage "Wie organisieren Sie Ihre Arbeit?" Ist.

Wir bilden eine QS-Strategie

1. Einführung in die Qualitätssicherung

Erinnern / führen Sie den Begriff Qualitätssicherung zum ersten Mal ein. Glauben Sie mir, Ihr Team ist voll von Leuten, die sich sehr vage vorstellen, was es ist. Ganz allgemeine Definitionen können bei Wikipedia ausgeliehen werden . Zeigen Sie taktisch an, dass die Anwesenheit des QS-Teams im Projekt nicht bedeutet, dass die gesamte Verantwortung für die Qualität der Arbeit nur noch auf sie übertragen wird:

Testen ist ein Teil der Qualitätssicherung. Auf diese Weise können wir das Qualitätsniveau der von uns bewerteten Features bestimmen.

Es liegt nicht in der alleinigen Verantwortung der Tester, eine Qualitätssicherung durchzuführen. Das gesamte Team kann und sollte dazu beitragen, ein hohes Qualitätsniveau der gelieferten Produkte und Dienstleistungen sicherzustellen.

2. Einführung in die QS-Strategie

Bereiten Sie sich darauf vor, worüber mehr Menschen lesen werden.

Die Teststrategie ist ein sich weiterentwickelndes Dokument, in dem die Prozesse und die Art und Weise, wie wir die Qualität unseres Produkts in Zukunft sicherstellen, detailliert beschrieben werden.

Sound den Inhalt. Es kann entweder nur ein Inhaltsverzeichnis oder abstraktere Sätze sein. Erwähnen Sie hier das Vorhandensein eines Testansatzes, eines Testprozesses, einer Testautomatisierungsstrategie und die Notwendigkeit eines Testplans.

Es ist wichtig. Geben Sie das Zeitintervall für die Überarbeitung dieses Dokuments an. Und das Projekt und die Prozesse im Unternehmen entwickeln sich, dieses Dokument sollte sich nicht in einen Dinosaurier verwandeln. Planen Sie daher einen Termin ein, an dem Ihre Strategie überprüft und geändert wird. Meiner Meinung nach reichen sechs Monate aus, um mit neuen Gedanken zurückzukehren.

3. Testansatz

Was ist ein Testansatz? Ich entferne mich ein wenig von dem umfangreichen offiziellen Wortlaut dieser Definition und erlaube mir, sie zu der These zu vereinfachen, dass dies „grundlegende Gedanken sind, mit denen wir jeden Tag anfangen zu arbeiten“. Schreiben Sie hier: Was ist der Motor Ihres Fortschritts?

Klassiker des Genres und gut funktionierende Ansätze sind „proaktiv“ und „risikobasiert“.

Wir werden einen proaktiven und risikobasierten Testansatz verfolgen.

Proaktiv - Dies bedeutet, dass der Testentwurfsprozess so früh wie möglich eingeleitet wird, um die Fehler zu finden und zu beheben, bevor der Build erstellt wird.

Risikobasiert - Dies bedeutet, dass wir unsere Testbemühungen so organisieren, dass das Produktrisiko beim Versand des Systems verringert wird. Laut ISTQB-Lehrplan „Risikobasiertes Testen ist die Idee, dass wir unsere Testbemühungen so organisieren können, dass das verbleibende Produktrisiko beim Versand des Systems verringert wird. Risikobasierte Tests verwenden das Risiko, um die entsprechenden Tests während der Testausführung zu priorisieren und hervorzuheben, aber es geht um mehr. Risikobasierte Tests beginnen früh im Projekt, identifizieren Risiken für die Systemqualität und nutzen dieses Risikowissen als Leitfaden für die Planung, Spezifikation, Vorbereitung und Durchführung von Tests. Risikobasierte Tests umfassen sowohl Abhilfemaßnahmen - Tests zur Verringerung der Wahrscheinlichkeit von Fehlern, insbesondere von Fehlern mit hoher Auswirkung - als auch Notfalltests zur Ermittlung von Problemumgehungen, um die an uns vorbeiziehenden Fehler weniger schmerzhaft zu machen. Bei risikobasierten Tests muss auch gemessen werden, wie gut wir Fehler in kritischen Bereichen finden und beseitigen können. »

Wenn wir über proaktives Handeln sprechen, müssen wir in erster Linie über die Spezifikation der Qualitätskontrollanforderungen sprechen. Die Manager, die die Spezifikationen der Elemente des nächsten Entwicklungszyklus zusammenstellen, denken größtenteils als normale Benutzer des Systems, während die Logik der Gedanken der Entwickler in einer anderen Dimension existiert. Erstens habe ich mehr als einmal gesehen, dass ein Entwickler, der eine Spezifikation liest, sie nicht in eine Programmiersprache übersetzen kann. Beispielsweise kann der in der Spezifikation genannte Benutzer nicht mit vorhandenen Rollen / Zugriffsrechten im System abgeglichen werden. Infolgedessen kann er nach seiner persönlichen Meinung die am besten geeignete Rolle auswählen, die sich als falsch herausstellt und die Funktionalität zurückgeben muss, um später zu arbeiten und Zeit zu verlieren. oder stellen Sie eine Frage an den Manager, der vielleicht in den Urlaub gefahren ist und wieder Zeit in Erwartung verliert. QA Engineer ist diese wunderbare Schicht zwischen dem benutzerorientierten Manager und dem technisch denkenden Entwickler, insbesondere wenn der QA Engineer White-Box-Tests nicht vernachlässigt. Wir sind in der Lage, Manager zu verstehen und ihre Gedanken an Entwickler zu übersetzen. Zur Zeit.

Risikobasierte Tests bieten interessante formale Methoden zur Bewertung von Projektrisiken und Produktrisiken. Es ist großartig, sie in die Praxis umsetzen zu können. Aber ich persönlich habe nie genug Zeit, um die Wahrscheinlichkeiten des Auftretens, die Schwere ihrer Folgen usw. zu ermitteln. und berechnen Sie die Risiken nach allen Regeln. Hier verlasse ich mich mehr auf meine Instinkte und meinen gesunden Menschenverstand. Beim Testen oder Abdecken von Autotests mit einer Risikozone (was die erste und wichtigste Aufmerksamkeit erhalten sollte) zum größten Teil:

• direkt gestaltete Funktionalität
• angrenzende und interagierende Bereiche
• kommerziell wichtige Funktionalität
• was am häufigsten bricht
• Abwärtskompatibilität (wenn beispielsweise das Metadatenformat geändert wird, funktionieren die vorhandenen Daten erfolgreich)

4. Testprozess

Sagen Sie uns, welche methodische Abfolge von Arbeiten Sie einhalten möchten. Ich habe nichts Kompliziertes erfunden, aber ich habe die Idee von ISTQB übernommen und verwendet.

Wenn Sie meinen Weg gehen, machen Sie sich mit der von den Autoren von ISTQB empfohlenen Arbeitsreihenfolge vertraut und wissen Sie, welche Schritte Sie wie unternehmen werden. Wir beginnen mit der Planung und Kontrolle. Diese beiden leben zusammen, weil Auf der Grundlage der Überwachung ihrer eigenen Aktivitäten können Pläne regelmäßig neu erstellt werden. Als nächstes folgt die Arbeit mit der Dokumentation und dem Schreiben von Testfällen, deren Inbetriebnahme (unter Verwendung der geplanten Testdaten und einer geeigneten Umgebung), Abschluss der Tests und Bereinigung nach sich selbst (Löschen temporärer Dateien usw.).

Wir werden den Testprozess verwenden, der im ISTQB-Lehrplan auf Foundation-Ebene beschrieben ist: Testplanung und -kontrolle, Testanalyse und -design, Testimplementierung und -ausführung, Bewertung der Ausstiegskriterien und Berichterstellung sowie Testabschlussaktivitäten.

5. Verantwortlichkeiten

Identifizieren Sie Ihre und die Verantwortlichkeiten anderer im Bereich der Verbesserung der Produktqualität. Melde deine Mission.

Betonen Sie zunächst noch einmal, dass jedes Teammitglied ein Tester für sich ist und jeder testet, worauf er sich bezieht. Schrieb Code - teste ihn.

Zweitens klären und verstehen Sie die Richtung Ihrer kontinuierlichen Entwicklung. QA Engineer ist der Chefexperte für Produktfunktionalität : Er weiß, wie und was funktioniert, kann erklären, wie und was getestet werden muss. Er ist eine Person, die das Betriebsverhalten des Kunden vorhersagt, was bedeutet, dass er keine ernsthaften Probleme entstehen lässt.

Drittens geben Sie an, wie Sie mit Managern und Entwicklern interagieren . Halten Sie beispielsweise bei Three Amigos Agile Approach an

Zusammenarbeit zwischen Business, Entwicklung und Qualitätssicherung
a. Geschäft - Welches Problem versuchen wir zu lösen?
b. Entwicklung - Wie können wir eine Lösung finden, um dieses Problem zu lösen?
c. Testen - Was ist damit, was könnte möglicherweise passieren?

6. Teststufen und QS-Automatisierungsstrategie

Heute ist dieser Abschnitt für mich zu einem eigenständigen Dokument geworden. Geben Sie jedoch auf Organisationsebene des aufkommenden QS-Prozesses im Team an, welche Arten von Tests von wem durchgeführt werden. Was wird manuell gemacht, was wird automatisiert und nach welchem ​​Prinzip. Wer ist für welche Autotests verantwortlich?

Zum Beispiel schreibe ich zum aktuellen Projekt nur End-to-End-Tests, deren reibungsloser Betrieb aus geschäftlicher Sicht von strategischer Bedeutung ist. Gleichzeitig schaue ich mir die Pull-Anfrage des Entwicklers an und gebe gegebenenfalls Empfehlungen zur Testabdeckung. Der Rest (Einheit, Integration, Laden usw.) ist die Arbeit der Entwickler. Beim vorherigen Projekt habe ich Lasttests durchgeführt, und ich habe zusammen mit den Entwicklern Integrationstests geschrieben.

7. Funktionsworkflow

Heute arbeitet mein Projekt mit zweiwöchigen Sprints an Scrum. Daher habe ich für jede Story ein Schritt-für-Schritt-Dokument zum Lebenszyklus.

Unabhängig von der Methodik, an die sich das Projekt hält, beschreiben Sie Schritt für Schritt, wie Sie die tägliche Arbeit erledigen. Wenn wir oben mehr über Taktiken gesprochen haben, sollte es klare Hinweise darauf geben, was zuerst kommt und was dann.

Zum Beispiel ist meine Version

Der folgende Workflow beschreibt den Prozess, den wir intern übernehmen werden.
1. Holen Sie sich die Geschichte, bevor Sie die Sitzung planen
2. Erstellen Sie eine Checkliste gemäß den Akzeptanzkriterien und der Beschreibung
3. Beachten Sie unklare Details / Fragen
4. Klären Sie Fragen zur Planung
5. Aktualisieren Sie die Checkliste
6. Markieren Sie alle Abhängigkeiten und wie Sie sie überwinden möchten
7. Wenn sich die Story im Review befindet, prüfen Sie, ob die Akzeptanzkriterien von Autotests abgedeckt werden
8. Ermutigen Sie den Entwickler, alle Akzeptanzkriterien mit Autotests abzudecken, oder tun Sie es selbst
9. Wenn die Story zum Testen bereit ist, führen Sie manuelle Tests mithilfe der Checkliste durch
10. Erstellen Sie Fehler für die Story, falls vorhanden, und geben Sie das Element an die Entwicklung zurück
11. Wenn Fehler behoben sind, führen Sie erneut manuelle Tests anhand der Checkliste durch
12. Überprüfen Sie, ob alle Autotests bestanden wurden
13. Erstellen Sie bei Bedarf eine Aufgabe zum Implementieren zusätzlicher Autotests für die Integration
14. Verschieben Sie die Story in den Status "QA bestanden"

8. Testplan

Wählen Sie die Art des Testplans, die Plattform, auf der Sie ihn speichern möchten, und den Zweck seiner Existenz. Bieten Sie jedem die Möglichkeit, dort hineinzuschauen.

Bei diesem Projekt besteht mein Testplan aus einer Reihe von Checklisten für jede Story. Mit dem aktuellen Automatisierungsgrad reicht dies vorerst aus.

Beim vorherigen Projekt wurde der Testplan für gründliche manuelle Tests und als ideologische Grundlage für zukünftige Autotests verwendet.

Wenn Sie viele manuelle Tests haben, schreiben Sie Testfälle detailliert, damit jeder neue QS-Ingenieur, der zum Projekt gekommen ist, diese unabhängig durchführen kann.

So arbeiten Sie mit einem Dokument

Diesen ganzen Plan und effektive Worte zu schreiben ist sehr cool. Die Behörden werden es zu schätzen wissen, daran habe ich keinen Zweifel. Es gibt jedoch einen wichtigen Punkt in der Existenz dieses Dokuments. Dies sind ehrliche Antworten auf Fragen für wen und warum ist das alles geschrieben?

Wenn Sie jeden Satz aufschreiben, wäre es schön, über die Fragen nachzudenken: „Möchte ich wirklich so arbeiten?“ "Werde ich das im Projekt wirklich zum Leben erwecken?"

Wenn beide Antworten positiv sind, drucken Sie sicher weiter.

Wenn eine der Antworten "Nein" lautet, ist dies meiner Meinung nach ein sicheres Zeichen, um keine unnötigen Pflichten aufzuhängen.

Wenn eine der Antworten aus der Reihe "Ich weiß es noch nicht" stammt, lassen Sie sie vorerst auf Ihren Seiten leben.
Ich habe solche Momente auf der Liste geblieben, was in ein paar Monaten zuerst überprüft wird.

Zuerst habe ich mein Dokument für mich selbst geschrieben. Ich habe Momente, in denen ich mich von den beschriebenen Prozessen zurückziehe und sogar ein wenig gegen sie vorgehe. Sich an die Situation anzupassen, um hier und jetzt Ressourcen effizient zu nutzen, ist normal. Aber die überwiegende Mehrheit, mit der üblichen Routinearbeit, ist mein Dokument mein Reiseführer. Mehr als einmal war ich davon überzeugt, dass der bestehende Plan / die Strategie in jedem Bereich den gewünschten Ergebnissen immer schneller und schmerzfreier näher kommt als das völlige Fehlen. Ich wünsche Ihnen, dass Sie Ihre Arbeit einfach und effizient aufbauen können!

Vor der Veröffentlichung selbst war der Artikel stark reduziert, schmerzhaft groß schien es mir für die Sandbox. Ich werde dieses Thema gerne später fortsetzen. Trotzdem bin ich immer gerne bereit, mich weiterzuentwickeln. Wenn ich etwas völlig vergessen habe, schreibe mir bitte einen Kommentar.

Vielen Dank!