Test Maturity Model: Wie kann ein Tester ein Projekt bewerten und Prozesse planen?

Hallo! Mein Name ist Misha und ich bin Senior QA mit einer kaufmännischen Erfahrung von mehr als 6 Jahren. Jetzt arbeite ich in Provectus, aber ich habe meinen Testerweg als Student begonnen, als ich an Alpha- und Betatests verschiedener Spiele teilgenommen habe. Irgendwann dachte ich: "Warum nicht professionell anfangen?" Und los geht's. In dieser Zeit konnte ich an verschiedenen Projekten teilnehmen: von Start-ups bis zu Unternehmen, von kleinen Lerneinheiten bis zu großen Anwendungen mit starker Geschäftslogik.

Aber oft wurde ich in kleine Teams eingeführt, in denen es 5 Entwickler für 1-2 Tester gab und in der Regel viel Hitze im Projekt war. Eigentlich möchte ich Ihnen mitteilen, wie Sie lernen, zu verstehen, wo Sie sich befinden, und wie Sie beginnen, die Formulierung von QS-Prozessen voranzutreiben.

Zunächst sollten Sie verstehen, an welchem ​​Projekt Sie arbeiten.

Nachdem ich Erfahrungen aus der Teilnahme an Projekten gesammelt hatte, würde ich sie bedingt in drei Typen einteilen:

• Projekte ohne Prüfung;
• Projekte mit unfairen Tests;
• Projekte testen.

Zum Zeitpunkt meines Engagements befand sich jeder von ihnen in einem Entwicklungsstadium. Ich begann diese Situationen zu beobachten und begann meine Vision zu entwickeln - wie man Testprozesse auf ihnen fördert. Nach einiger Zeit stieß ich auf das Reifegradmodell, und sie legte sich eins zu eins auf meine Grundlagen. Dies stärkte meine Überzeugung, dass dies der richtige Ort ist.

Was ist ein Reifegradmodell?

Und hier füge ich sehr geschickt ein Zitat aus Wikipedia ein :

Capability Maturity Model Integration (CMMI) - eine Reihe von Modellen (Methoden) zur Verbesserung von Prozessen in Organisationen unterschiedlicher Größe und Aktivität. CMMI enthält eine Reihe von Empfehlungen in Form von Praktiken, deren Umsetzung es den Entwicklern des Modells zufolge ermöglicht, die Ziele zu verwirklichen, die für die vollständige Umsetzung bestimmter Tätigkeitsbereiche erforderlich sind.

Kurz gesagt, dies ist eine Reihe von Modellen, die zeigen, wie gut die Prozesse in der Organisation nach bestimmten Kriterien organisiert sind. Mit einer solchen Bewertung kann man nüchtern beurteilen, ob es sich lohnt, einem bestimmten Auftragnehmer den einen oder anderen Auftrag zu erteilen.

Daraus begann eigentlich die Entwicklung des Reifegradmodells. In den 80er Jahren stellte das US-Verteidigungsministerium fest, dass es die Qualität der Arbeit von Softwareentwicklungsunternehmen nicht genau beurteilen konnte. Und da diese Regierungsstruktur ebenfalls auf einem solchen Niveau liegt, ist dies nicht akzeptabel. Das Geld ist in Staatsbesitz, die Fristen sind klar abgegrenzt und zuverlässige Software für Waffen ermöglicht es jedem, ruhiger zu schlafen. Auf dieser Grundlage beauftragte das Ministerium das Software Engineering Institute mit der Erstellung eines solchen Bewertungssystems. Ein Jahr später wurde der erste Fragebogen und vier Jahre später die erste Version des Modells erstellt.

Reifegradmodellstufen

Dies sind 5 Ebenen, in denen die Arbeit / Zuverlässigkeit / Stabilität des Unternehmens bewertet wird.

Wo im Reifegradmodell getestet wird

Für Tester gibt es ein spezielles MM, es heißt TMMi. Es enthält auch 5 Ebenen, auf die ich näher eingehen und überlegen möchte, was für jede von ihnen typisch ist.

Das erste Level ist "Anfänger"

Auf der ersten Ebene ist das Testen nicht strukturiert und chaotisch. Es gibt keine stabile Umgebung zur Unterstützung von Testprozessen. Das Team achtet nicht auf Planung und Standards.

Das Hauptziel ist es, das Produkt ohne kritische Probleme pünktlich zu liefern, da hier nur Tests verwendet werden, um zu zeigen, dass die Anwendung ohne ernsthafte Störungen funktioniert. Oft hängt der Erfolg solcher Projekte nur vom Heldentum und den Fähigkeiten des Einzelnen ab und nicht von etablierten Prozessen.

Als Ergebnis:

• keine Testdokumentation;
• das Produkt ist instabil;
• Ablehnung von Prozessen in Problemsituationen;
• Testen ist nichts anderes als Hilfe beim Debuggen.

Zweite Stufe - "Wiederholbar"

Auf der zweiten Ebene wird das Testen zu einem kontrollierten Prozess. Disziplin und Fortschritte stellen sicher, dass diese Praktiken während des Stresses beibehalten werden. Testen wird immer noch als die Aktivität angesehen, die der Entwicklung folgt. Testpläne werden entwickelt und implementiert, mit deren Hilfe sie klar bestimmen, welche Art von Tests wann und von wem notwendig ist.

Das Hauptziel ist es sicherzustellen, dass das Produkt die angegebenen Anforderungen erfüllt.

Als Ergebnis:

• Es gibt die Haupttypen und -typen von Tests (Integration, Modular, Regression, Akzeptanz).
• Testpläne implementiert;
• Testaktivitäten werden überwacht und kontrolliert;
• Der Vorgang ist dokumentiert und kann wiederholt werden.

Dritte Ebene - "Definiert"

Auf der dritten Ebene wird das Testen nach dem Programmieren nicht mehr als Aktivität angesehen. Das Testen ist vollständig in das Projekt integriert. Die Testplanung erfolgt zu einem früheren Zeitpunkt und ist im Masterplan festgelegt. Nichtfunktionale Tests (z. B. Verwendbarkeit) werden eingeführt.

Als Ergebnis:

• Das Testen beginnt mit der Anforderungsphase.
• Es werden Aktivitäten hinzugefügt, mit denen Sie effizienter arbeiten können (interne Schulungen, zusätzliche Überprüfungen).
• Nichtfunktionale Tests werden eingeführt.

Vierte Stufe - "messbar"

Auf der vierten Ebene ist das Testen ein klar definierter, gut etablierter und messbarer Prozess. Das Testen wird als Bewertung wahrgenommen und umfasst alle Vorgänge des Softwareentwicklungslebenszyklus. Die Praxis der Messung der Testqualität wird eingeführt. Diese Messungen werden verwendet, um die Leistung und die Kosten des Testens vorherzusagen.

Als Ergebnis:

• Testen als messbarer Prozess;
• Messungen werden zur Vorhersage verwendet;
• Das Team sucht nach Möglichkeiten, den Testprozess effizienter zu gestalten.

Fünfte Ebene - "Innovativ"

Auf der fünften Ebene sind alle Ansätze und Prozesse gut etabliert. Das Team hört in dieser Phase nicht auf, sondern verbessert die Prozesse weiterhin systematisch und versucht ständig, die Zeit des Testzyklus und die Markteinführungszeit zu verkürzen, ohne die Qualität des Projekts zu beeinträchtigen. Das Testen konzentriert sich auf die Prävention. Automatisierung wird hinzugefügt, um Ressourcen effizienter zu nutzen.

Als Ergebnis:

• kontinuierliche Prozessverbesserung;
• Fokus auf Prävention und Optimierung.

Wie das Wissen über diese Struktur hilft

Fall Nr. 1. Unfaire Tests

Einmal kam ich zu einem kleinen Projekt, bei dem ein Kunde, seine Freunde oder eine Katze Tests durchführten. Nachdem wir die Situation bewertet und das Modell betrachtet haben, können wir verstehen, dass wir uns auf Stufe 1 befinden und dass wir uns bei der Aktivitätsplanung auf Stufe 2 konzentrieren sollten. Nachdem ich Jira in Ordnung gebracht hatte, wo es eine große Anzahl von Fehlern gab (von denen die meisten doppelt oder nicht reproduzierbar waren), begann ich, Testdokumentation in Form von Checklisten zusammenzustellen und die grundlegenden Testprozesse zu ordnen. Wie Regressionstests und Sanity Checks bei größeren Änderungen.

Fall Nr. 2. Ohne Prüfung

Meiner Meinung nach können Projekte dieser Art in drei Fällen durchgeführt werden:

• Das Projekt fängt gerade erst an.
• Es war kein Tester für das Projekt erforderlich, obwohl ein wenig Funktionalität vorhanden war.
• Das Full-Stack-Team schloss den Mangel an Testern mit Qualitätscode-Überprüfung und Entwicklertests.

Einmal in einem dieser Projekte können Sie oft den Vorteil der Tatsache erkennen, dass es sich auf einem geheimen Nullniveau befindet. Wir können über die erste Ebene springen und sofort alles qualitativ mit einem guten Sinn, Gefühl und Arrangement tun, geleitet von den Zielen der zweiten. Oft können wir Testpläne implementieren, auf deren Grundlage alle erforderlichen Testarten durchgeführt werden. Sie können den gleichen Workflow sofort mit dem Entwicklungsteam identifizieren, das bei Projekten aus dem ersten Fall fehlt.

Fall Nr. 3. Testen war

In Wahrheit der seltenste Fall: Ein Mann hat aufgrund bestimmter Ereignisse beschlossen, sein Team / seine Abteilung / seine Arbeit zu ändern, und gibt Ihnen seine eigenen Ideen. In dieser Situation verfügen Sie bereits über ein etabliertes Interaktionssystem mit Entwicklern, eine bestimmte Basis für die Testdokumentation. Weitere Entwicklungspfade können die Verbesserung des etablierten Prozesses oder den Übergang zur dritten Ebene umfassen - Einführung von Tests in früheren Phasen oder Hinzufügen von nicht funktionalen Tests.

Fall Nummer 4. Drei in einem

Als ich zu meinem Projekt in Provectus kam, war ich mit einer Situation konfrontiert, in der es nur wenig von den drei oben beschriebenen Fällen gab. Wie im Fall Nr. 1 war das erste, was zu tun war, Jira in Ordnung zu bringen. Wie im zweiten Fall wurde beschlossen, alles sofort mit hoher Qualität zu erledigen, um sich sofort von der zweiten Ebene leiten zu lassen. Daher begann ich sofort, Testdokumentation zu entwickeln und Testmanagement-Tools zu implementieren. Ich habe auch versucht, das Beste aus den Artefakten vergangener Iterationen herauszuholen, wie es im dritten Fall der Fall war.

Nach sehr kurzer Zeit kann ich mit Sicherheit sagen, dass wir bereits bewusst auf die dritte Ebene gehen - sogar vernetzte Tests in der Phase der Geschäftsanforderungen :)

Schlussfolgerungen

Nach meiner Erfahrung können die meisten ukrainischen Projekte sowie Projekte, die lange Zeit nicht konzipiert wurden, erfolgreich auf Stufe 3 live geschaltet werden. Wenn Sie jedoch ein langfristiges Projekt haben, gibt es unendlich viele Möglichkeiten, es zu verbessern, und Sie können sich sicher von den Errungenschaften auf höchstem Niveau leiten lassen.

Abschließend möchte ich sagen, dass der Zweck dieses Artikels darin bestand, nicht so sehr zu zeigen, wie man mit dem klassischen MM oder TMM selbst arbeitet, sondern dass Sie mit seiner Hilfe klar verstehen können, in welchem ​​Stadium das Projekt, an dem Sie beteiligt sind, und welche Bewegungen zu nehmen sind und welche nicht wert sind. Darüber hinaus können Sie auf der Grundlage seiner Prinzipien Ihr eigenes Modell erstellen, das nicht nur in der Entwicklung, sondern auch in verschiedenen Lebensbereichen angewendet werden kann. Und vor allem - es ist getestet und funktioniert :)