Wieviele Software-Tester braucht es im Entwicklungs-Team?
In der Softwareentwicklung hat es sich durchgesetzt, dass es neben den Programmierern, Tester (QA) gibt, welche die Programmierung auf Fehler überprüfen.
Das liegt auch daran, dass den Entwicklern selbst, oftmals die eigenen Fehler (Bugs) im Code nicht auffallen, da sie die Software nur aus einer bestimmten Sicht sehen, nämlich ihrer eigenen.
QA-Mitarbeiter können hier verschiedenste Tests durchführen, um kleine und grössere Bugs im System zu finden.
Braucht es überhaupt Tester?
In manchen Teams gibt es überhaupt keine QA-Mitarbeiter. Zum Beispiel in kleinen Teams, oder in welchen auf die Agile Softwareentwicklung gesetzt wird.
Oftmals setzt man eher auf das sogenannte Pair-Programming, in welchem zwei Entwickler den geschriebenen Code des Gegenübers gegenprüfen. Damit sinkt auch der Aufwand für einen eventuellen Tester.
Dennoch macht es Sinn auf Tester zu setzen.
Hier ein paar Gründe:
- Ein Tester kostet pro Stunde meistens weniger als ein Developer. Meistens ist der Entwicklerstundensatz das Doppelte oder Dreifache als das von einem QA-Mitarbeiter.
- Die QA-Mitarbeiter werden die Software/ Module von einer anderen Sichtweise sehen und andere, von den Entwicklern eventuell übersehene, Bereiche prüfen.
Wieviele braucht es?
Es gibt unterschiedliche Meinungen zu dem, wieviele QA’s es in einem Team benötigt. Ein bekannter Blogger und Softwareunternehmer namens Joel Spolsky sagt, dass es für jeweils zwei Entwickler einen QA geben sollte.
Andere empfehlen einen für drei (1:3) Entwickler, andere wiederum von einen für fünf (1:5) oder einen auf sieben (1:7).
Es ist sicherlich auch eine Frage,
- wie schnell die Software auf dem Markt sein muss (umso schneller, desto mehr QA’s)
- wie hoch das Budget ist (hohes Budget, mehr Tester; geringes Budget, weniger Tester; bei weniger Testern muss es jedoch klar sein, dass es länger benötigt die Software live zu schalten und auch, dass eventuell die Endnutzer einen Teil des Testings unternehmen müssen. Das geht wiederum meistens nur, wenn es sich um interne Abteilungen handelt, welche die Endnutzer sind. Diesen kann man Fehler schon eher zutrauen, als wenn es sich um externe Endnutzer handelt, welche Teil des Kundenunternehmens, oder aber private Nutzer/ Konsumenten, sind.)
- Komplexität der Software (simple Software, weniger QA’s; komplexe Software, mehr QA’s)
Kosten
Oftmals ist es schwer Testing-Stunden einem Kunden in Rechnung zu stellen. Der Kunde der für das Projekt zahlt, hat eventuell nicht die Erfahrung, um zu wissen, ob es und wieviel Testing-Arbeit es benötigt. Es mag für einen Budgetverantwortlichen unverständlich erscheinen, warum es 10 Tester in einem Team mit 30 Entwicklern braucht.
Daher wird, meiner Meinung nach, oftmals die Entscheidung, auch von der Auftragnehmer Seite (z.B. Softwareunternehmen), getroffen, weniger QA-Mitarbeiter zu haben.
Es hat jedoch einige Nachteile, welche durch zu wenige Tester entstehen, welche im Folgenden beschrieben sind:
- Zuviele Bugs werden durch den Endkunden gefunden: Einige Unternehmen handeln nach diesem Prinzip. Dann sollte man jedoch auch die entsprechenden Prozesse haben, so dass dieses Feedback auch bei Fehlerbehebungen berücksichtigt wird. In manchen Fällen wird auf Unternehmensseite zu wenig getestet, nur um dann das Feedback der Kunden zu überhören.
- Das Testen von Software durch die Entwickler selbst kann sehr viel Zeit beanspruchen. Oftmals sehen die Entwickler es auch nicht als ihre Aufgabe an, das Testing selbst durchzuführen, oder haben dazu einfach keine Lust. Falls jedoch das QA im Detail befolgt wird, dann dauert es zu lange, bis etwas brauchbares vorgezeigt werden kann.
Gibt es gute QA-Mitarbeiter?
Einige Verantwortliche von Softwareprojekten, haben das Argument, dass es nur sehr wenige gute QA-Mitarbeiter gibt. Denn gute Leute gehen lieber in die Programmierung, in den Vertrieb oder das Management.
Das Argument ist valide, denn die Karriere-Chancen sind beschränkt und es bieten sich für solche Mitarbeiter meistens Entwicklungsmöglichkeiten in die anderen Bereich. Zum Beispiel startet ein brillanter Hochschulabsolvent als QA-Mitarbeiter, um dann zum Programmierteam zu wechseln.
Hier macht es Sinn auf junge Tester zu setzen oder auf Mitarbeiter die bereits auf eine lange Karriere im Bereich Testing zurückblicken. Den jüngeren QA Mitarbeitern kann man einen Karriereweg aufzeigen, in welchem man im späteren Verlauf, zum Beispiel nach ein bis zwei Jahren in eine Programmierlaufbahn, etc. gehen kann. Bei Mitarbeitern, welche schon lange im Testing unterwegs sind, kann man davon ausgehen, dass diese auch in diesem Aufgabenfeld bleiben.
Fazit
Man sollte das Ziel im Fokus halten. Wollen wir Software, welche grossartig ist, mit hohem Kundennutzen, welche skalierbar, wartbar und fehlerfrei ist? Dann macht es Sinn etwas mehr in das Testing zu investieren, so dass Bugs bereits bei der Entstehung gefunden werden und der Endnutzer ein tolle Applikation bekommt, welche er ohne Performanceeinbussen oder Crashes vom System nutzen kann.
Bilder: Flickr.com/ TownePost/ Mann
Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.
Schreibe einen Kommentar