Was ist ein gutes Maß für die Effizienz von Tests / Testern?


11

Ich bin dabei, an einer Diskussion mit dem Management über die Messung unserer Testeffizienz als QS-Organisation teilzunehmen. Der Hauptgrund dafür ist, dass die Hälfte unseres Teams ausgelagert ist und unser Unternehmen einige Kennzahlen darüber liefern möchte, wie effektiv / effizient wir sind, damit wir Basisdaten haben, über die wir mit dem Servicevertrag unserer Auftragnehmer Vertragsparameter aushandeln können .

Ich habe mich ein wenig umgesehen und die meiste Meinung, die ich zu diesem Thema gefunden habe, dreht sich um die Effizienz von Entwicklern: Codezeilen, gelieferte Story Points, eingeführte Fehler usw.

Aber was ist mit Testern? Unsere Tests basieren hauptsächlich auf Anforderungen und sind eine Mischung aus manuellen, halbautomatisierten und automatisierten Tests (nicht weil wir nicht alles automatisiert haben, sondern weil einige Dinge in unserem Testsystem nicht automatisierbar sind).


1
stevemcconnell.com/ieeesoftware/bp09.htm kann in irgendeiner Weise nützlich sein.

Das ist merkwürdig. Wenn Sie gmail.com testen müssen und keinen einzigen Fehler finden, denken Sie, dass Sie fehlgeschlagen sind? Wenn Sie eine Million Testfälle für etwas sehr Kleinliches schreiben, denken Sie, dass es Sie erfolgreich macht? Suchen Sie nach Defect Leakage, dh den Fehlern, die während der SIT nicht identifiziert wurden und durch UAT gerutscht sind. Es gibt andere Möglichkeiten, wie die Qualitätssicherung dem gesamten SDLC einen Mehrwert verleiht.

Antworten:


8

Die Anzahl der geschriebenen Tests ist nutzlos, und eine hohe Anzahl gefundener Fehler kann eher ein Maß für eine schlechte Entwicklung als für eine effiziente Qualitätssicherung sein.

Automatisierungsmaßnahmen (Codeabdeckung, Funktionsabdeckung ...) können gut sein, aber ich denke, sie sind eine größere Hilfe für die Entwicklung (als Entwickler weiß ich, wenn ich versehentlich etwas kaputt mache) als Kunden (das möchte ich tun und es funktioniert nicht).

Da Qualität gut ist, wenn Kunden keine Probleme haben, ist ein gutes Maß für die Effektivität (nicht die Effizienz) eines QS-Teams und -Prozesses das Maß für Fehler, die von Kunden gefunden wurden, die von QA nicht gefunden wurden .

Das Hauptproblem bei dieser Metrik besteht darin, dass es zu erheblichen Verzögerungen zwischen der geleisteten Arbeit und dem Beginn aussagekräftiger Zahlen kommen kann.


1
+1 letztendlich ist die Kundenzufriedenheit die Hauptmetrik für das gesamte Team
jk.


6

Es gibt einige Metriken, die wir bei meinem letzten Job zur Bewertung der Qualitätssicherung verwendet haben:

  • Anzahl der gefundenen Fehler. Ich hasse diesen. Es ist wie "Anzahl der geschriebenen Codezeilen" für einen Entwickler.
  • Anzahl der produzierten automatisierten Testfälle.
  • Prozentsatz der gesamten Anwendung, die in Funktionstests abgedeckt ist.
  • Anzahl der in der Inszenierung gefundenen Fehler im Vergleich zur Produktion.

Am Ende besteht die Aufgabe Ihres QA-Teams darin, die Fehler zu finden, bevor sie in freier Wildbahn veröffentlicht werden. Ihre Metriken sollten darauf basieren, dieses Ziel tatsächlich zu erreichen. Wenn es nur eine geringe Abdeckung von Testfällen, eine minimale Anzahl automatisierter Tests und eine hohe Fehlerquote in der Produktion gibt, leisten sie keine gute Arbeit. Wenn sie jedoch eine gute Erfolgsbilanz darin haben, die Fehler zu finden, lange bevor sie auf Prod treffen, sollten ihre Metriken ziemlich hoch sein.


3
Nur eine Bemerkung: Die ersten drei sind Managementkennzahlen, was bedeutet, dass der Auftragnehmermanager versuchen sollte, diese kurzfristig (monatlich oder vierteljährlich) zu optimieren. Allerdings hat nur der vierte echte geschäftliche Konsequenzen und sollte als alleinige Grundlage für die Vertragsverlängerung verwendet werden. (Ein schlechter Manager kann bei den ersten drei Metriken möglicherweise sehr gut punkten, indem er Zahlen aufbläst, lässt aber dennoch viele Fehler in die Öffentlichkeit gelangen.) Leider hat der vierte einen Datenerfassungszyklus von 2-3 Jahren.
Rwong

Funktionstests sollten Black-Box-Tests sein , oder irre ich mich?
BЈовић

"Anzahl der gefundenen Fehler": Dies sollte eine Maßnahme sein, die auf Entwickler angewendet wird. Wenn ich mich als Tester diesem Indikator unterziehe, werde ich mich bald mit einem Entwickler anfreunden, der bereit ist, Fehler in den von mir getesteten Code einzuführen.
Mouviciel

3

Die Qualitätssicherung sollte anhand von zwei Hauptkennzahlen gemessen werden: Wie viele Fehler kommen an der Qualitätssicherung vorbei, um im Feld gefunden zu werden? Was sind ihre Schwere?

Möglicherweise können Sie die Qualitätssicherung durchführen, um schwerwiegende Fehler zu finden, die näher an der Veröffentlichung liegen als die vollständige Entwicklung. Möglicherweise können Sie die Qualitätssicherung durchführen, wenn Sie die Tests nicht bis zum voraussichtlichen Abschlussdatum (pro Feature) abgeschlossen haben.

Letztendlich befürchte ich jedoch, dass Sie mehr Geld ausgeben werden, um die Effektivität Ihres Vertragspersonals zu messen, als Einsparungen, die durch den Einsatz eines Vertragspersonals erzielt werden ...


0

Das Unternehmen, in dem ich arbeite, verwendet eine Reihe von QS-Metriken.

Am relevantesten ist meiner Meinung nach die Codeabdeckung. Ein Tool wie EMMA funktioniert hervorragend, da es zusätzlich zu seinen manuellen Tests gründliche automatisierte Tests schreibt.

Was auch immer Sie tun, konzentrieren Sie sich nicht auf die Anzahl der Tests. Das ist ungefähr so nützlich wie LOC pro Tag.


-1

Viele Möglichkeiten, die Leistung in Entwicklungs- und Testphasen während der Projektausführung zu messen. Wir haben in unseren Projekten die folgenden Maßnahmen verwendet. Entwicklungsleistung gemessen anhand von 4 gängigen Code-Metriken (Wartbarkeitsindex, zyklometrische Komplexität, Vererbungstiefe, Klassenkopplungen). Für C # wird es in Microsoft Visual Studio erhalten. Für die Testabdeckung ist Ncover / Ndepend sehr nützlich. Testleistung gemessen an der Anzahl der Entwicklungsfehler, die durch die letzten 4 Sprints übertragen wurden Systemtestfehler, die über die letzten 4 Sprints übertragen wurden. Kein Automatisierungstest in einer bestimmten Version / gelieferten Funktionen bestanden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.