Wir haben ein ziemlich komplexes Java-System, das einige Back-End-Tiers einschließlich einer Datenbank und eines proprietären Swing-Frontends enthält. Es gibt Back-End-APIs, an die externe Parteien angeschlossen werden können, die unser Front-End nachahmen. Es gibt ungefähr 5 Silos in unserer Organisation, die dieses System teilen. Insgesamt unterhalten rund 15 Entwickler dieses System.
Gibt es eine Faustregel, wie groß unser QA-Team sein sollte?
Bearbeiten: Um ein bisschen Kontext basierend auf Fragen hinzuzufügen, die in den Antworten angesprochen wurden:
Als ehemalige Testteamleiterin würde ich vorschlagen, so viele Tests wie möglich durchzuführen. Es klingt wie eine Menge Leute in Ihrer Organisation von Ihrer Software abhängen. Testen Sie früh und testen Sie oft.
Es ist sehr wichtig zu erkennen, dass das Testen in aller Verantwortung liegt. Entwickler müssen gute Komponententests schreiben. UI-Entwickler sollten die Benutzeroberfläche manuell testen.
Ich versuche, die testgetriebene Entwicklung zu fördern, die Metriken im Auge zu behalten (ein formales Fehlerverfolgungssystem zu verwenden, Fehlerdichten zu verfolgen usw.), einen kontinuierlichen Integrationsservice einzurichten und Code für die Testbarkeit zu entwickeln (verwende ein Framework wie Spring für die Abhängigkeitsinjektion) , verwenden Sie Mocks und Stubs für externe Dienste, usw. - ich würde mich freuen, detaillierter zu diskutieren). Die Kosten, um einen Fehler zu beheben, werden exponentiell teurer, je später Sie es finden, also ist es am besten, bevor es zur formalen Qualitätssicherung kommt.
Jeff
Beginne mit einem 1 QA zu 5 oder 6 Entwicklern. Dann fange an, es zu optimieren, je nachdem, wie viel Arbeit du denkst, dass die QAs tun müssen oder nichts zu tun haben.
In Wahrheit basiert das nur auf meiner eigenen Erfahrung, weil es zu viele Faktoren gibt. Wie entwickelt oder stabil ist Ihre Codebasis? Wie groß ist es? Wie umfassend muss das Testen sein? Um welche Art von Test- und Analyse-Tools handelt es sich? Wie oft sind Meilenstein-Releases? Was für einen Entwicklungsprozess hast du? Wie viel manuelle Tests und wie viel automatisiertes Testen?
Es gibt viel mehr Fragen. Fange einfach mit einer beliebigen Zahl an und gehe von dort aus.
Ein vernünftiges QA-zu-Dev-Verhältnis kann nur relativ zur Komplexität einer Anwendung abgeleitet werden.
Es ist klar, dass ein Überentwickler wahrscheinlich eine komplexe Anwendung finden kann, bei der nur 3 QAs Vollzeit aufgrund der Komplexität des Arbeitsablaufs effizient testen können; wiederum kann es 1 QA für 3 Junior-Entwickler geben, die eine relativ einfache Eingabe-Ausgabe-Berichtanwendung zusammenfügen.
Die Anzahl der QA-Mitarbeiter, die Sie benötigen, hängt von der Anzahl und Komplexität Ihrer Anforderungen ab und nicht von der Anzahl der von Ihnen verwendeten Softwareentwickler.
Es hängt viel davon ab, was das System macht und welche Konsequenzen die Defekte haben. Schreibst du Finanzsoftware? Oder soziale Netzwerke? Die wahrscheinlichen Kosten eines Fehlers sind größer als die des anderen, so dass der QA-Aufwand variiert. Ähnlich, wenn es sich um ein Produkt handelt (mit mehreren installierten Benutzerbasen, die möglicherweise schwieriger zu patchen sind), müssen Sie stabiler sein, als wenn es intern ist.
Sie müssen auch fragen, ob Sie erwarten, dass sie grundlegende Systemtests oder Volumen- und Belastungstests durchführen. Es scheint, dass Sie eine Kombination aus UI-Tests und API-Tests betrachten.
Wenn Sie davon ausgehen, dass Sie von einem "normalen" System sprechen und wir grundlegende Systemtests sprechen, dann sollten Sie sagen, dass 33% aller Anstrengungen Testaufwand sein sollten. Theoretisch ergibt das ein Verhältnis von 1 zu 2, aber angenommen, dass deine Entwickler Unit-Tests sind, dehne sie vielleicht auf 1 zu 3. Natürlich laufe ich momentan mit 1 zu 4 und das ist nicht genug (ich werde es gleich beheben Das Geschäft erlaubt mir).
Sie möchten aber auch prüfen, wie ausgereift Ihre Softwareentwicklungsprozesse sind und wie Ihre Spezifikationen aussehen. Neben der richtigen Anzahl von Testern müssen Sie ihnen die richtigen Informationen zum Testen geben - wenn sie das nicht haben, werden sie nicht in der Lage sein, einen Job zu machen, und es ist wohl verschwendetes Geld.
>Eine andere Option, um dort hinein zu werfen - es klingt, als ob das Produkt eine Weile in Entwicklung war. Neben einem Kern von regulären Testern, möchten Sie vielleicht einen Bulk-up für einen ersten großen Test mit kurzfristigen Auftragnehmern. Wenn Sie nur eine Testressource mitbringen, möchten Sie sie nicht mit einem größeren Rückstand starten.
Es hängt wahrscheinlich davon ab, wie stark die Codebasis ist (ob es viele integrierende Module gibt) und wie involviert die Benutzererfahrung ist (wenn es viele visuelle Elemente und Eingabesteuerelemente zum Testen gibt).
Wenn es ein ziemlich komplexes System ist, sollten Sie 2-3 QA-Ingenieure für jeweils 5 Entwickler in Betracht ziehen. Wenn sich die Features jedoch nicht wesentlich ändern oder weniger involviert sind, würde ich denken, dass Sie mit nur 1 QA für jeden 5 Entwickler (vielleicht sogar für jeden 10 Entwickler) durchkommen könnten.
Ich weiß nicht, ob sich sein Standpunkt seit dem vor neun Jahren geändert hat, aber Joel würde es empfehlen 1 Vollzeit-QA-Person pro 2 Vollzeit-Entwickler. Ich würde sagen, mit einem System, das sich ständig weiterentwickelt und regelmäßig aktualisiert wird, ist dieses Verhältnis ziemlich gut.
Andererseits, wenn Ihr System sich nicht oft ändert, selten aktualisiert, warum sollten Sie dann viele Entwickler haben? Ich habe mich selbst davon überzeugt, dass 1: 2 in fast allen Situationen das perfekte Verhältnis ist. :)
2 Testingenieure pro 3 Entwickler sind ein guter Start. Wenn viele Testfälle Dinge betreffen, die nicht automatisiert werden können (physikalisches Stecken / Ziehen von Stöpseln, okulare Überprüfung des UI-Renderings), fügen Sie 1 Tester pro 2 Testingenieuren hinzu.