Klischees über IT-Fachkräfte zeichnen einen engen Persönlichkeitstyp: sozial eher passiv, auf ein einziges Interesse fixiert, ohne Bezug zur Kunst. In einer Umfrage unter Testern passten nur sechs Prozent auf dieses Profil. Die Befragten kamen unter anderem aus Bootsbau, Theater, Stadtplanung und internationalen Beziehungen, und viele pflegten aktive künstlerische Hobbys wie Komponieren oder Musizieren.
Das Wichtigste in Kürze
- Nur 6 Prozent der Tester in der Umfrage von Isabel Evans entsprachen dem IT-Klischee aus Rekrutierungsdatenbanken; die große Mehrheit der Menschen, die tatsächlich testen, passt nicht in dieses enge Profil.
- Datenbanken für Personalsuche und Berufsberatung verengen das Feld aktiv, weil sie nur klischeehaft “nerdige, unsoziale, kunstferne” Kandidaten in Richtung IT lenken und damit genau die Vielfalt aussieben, die den Beruf längst ausmacht.
- Rund 40 Prozent der Geisteswissenschaftler in der Stichprobe arbeiteten in Testautomatisierung und technischem Testen, und ebenso viele IT-Absolventen hatten nicht-technische Rollen: Das Studienfach sagt weder Rolle noch Eignung voraus.
- Das größte Qualitätsproblem mit Test-Tools war nicht die Optik, sondern die Operabilität: Tools mit attraktiver Oberfläche unterstützten die echten Testabläufe oft nicht, was Isabel Evans die Illusion der Usability nennt.
- Isabel Evans hat ihre Ergebnisse in 12 Heuristiken gefasst, formuliert als offene Fragen, die Tool-Entwicklern und Evaluatoren helfen, zu durchdenken, für wen ein Werkzeug gedacht ist und wie es die tatsächliche Testarbeit unterstützt.
Das IT-Klischee entscheidet mit, wer sich überhaupt bewirbt
Personalvermittler und Berufsberatungen arbeiten mit Datenbanken, in denen ein festes Bild davon steckt, wer in die IT gehört. Dieses IT-Klischee ist eng: wenig soziale Aktivität, kein echtes Interesse an Kunst, begrenzte Kommunikationsfähigkeit, oft ein einziges Hobby, auf das man sich fixiert. Die Botschaft solcher Datenbanken ist unmissverständlich: Wenn du so bist, ist IT etwas für dich.
Der Schaden entsteht, bevor überhaupt jemand eingestellt wird. Eine britische Studie von McChesney verglich drei Dinge: Menschen, die in der IT arbeiten, Menschen, die in die IT wollen, und das Stereotyp in diesen Datenbanken. Nur eine Minderheit der IT-Beschäftigten passte ins Klischee, etwa ein Viertel bis ein Drittel. Wer erst in die Branche wollte, lag näher am Klischee als die, die schon dort arbeiteten.
Der Rekrutierungsprozess verengt also den Trichter. Ein bestimmter Typ Mensch bekommt das Gefühl, dort hinzugehören. Alle anderen bekommen das Signal, dass sie nicht passen.
Tester kommen aus viel mehr Richtungen, als die Berufsbezeichnung vermuten lässt
Wer testet, bringt einen erstaunlich breiten Hintergrund mit, viel breiter, als das Etikett “Tester” nahelegt. Isabel Evans hat dazu eine Branchenumfrage über Online-Netzwerke und Konferenzen gemacht. Mit offenen Fragen wollte sie wissen, wie die Leute testen, welche Tools sie nutzen und wer sie außerhalb der Arbeit sind.
Heraus kamen Bootsbau, Theaterwissenschaft, internationale Beziehungen, Stadtplanung und Kunst. Die Befragten hatten Abschlüsse in Geisteswissenschaften, Naturwissenschaften, Sozialwissenschaften oder IT, manche gar keinen. Und die meisten hatten schon ganz andere Berufe hinter sich, bevor sie ins Testen kamen.
Als Isabel Evans das Modell von McChesney auf ihre eigene Stichprobe anwandte, entsprachen nur sechs Prozent dem IT-Klischee. In einer Gruppe, die angeblich aus lauter Nerds besteht, passte fast niemand ins Nerd-Profil.
Tester gestalten aktiv, statt passiv zu konsumieren
Ein großer Teil der Tester hat künstlerische Hobbys, und zwar aktiv betriebene. Das Klischee unterstellt jemanden, der still vor sich hin konsumiert. Die Daten zeigen das Gegenteil.
Nehmen wir Musik. Einige Tester gaben an, Musik zu hören, also passiv. Eine größere Gruppe spielt ein Instrument oder singt im Chor. Andere komponieren oder schreiben eigene Songs. Dasselbe Muster, aktiv und kreativ, zeigt sich auch bei anderen Interessen.
Viele nannten außerdem mehrere Hobbys gleichzeitig. Das Bild ist also nicht der Mensch mit dem einen Spezialinteresse, sondern Leute mit einem breiten, kreativen Leben.
Das Studienfach sagt nichts über die Rolle im Testen
Was jemand studiert hat, verrät wenig darüber, welche Testarbeit er später macht. Die Annahme, Geisteswissenschaftler landen im Testmanagement und im Testdesign und IT-Absolventen in den technischen Rollen, hält den Daten nicht stand.
Rund vierzig Prozent der Geisteswissenschaftler in der Umfrage arbeiteten in Testautomatisierung und technischem Testen. Rund vierzig Prozent der IT-Absolventen hatten überhaupt keine technische Rolle. Eignung, Freude an der Arbeit und der tatsächliche Job hängen nicht am Abschluss auf dem Zeugnis.
Wer also bei der Einstellung auf einen Informatikabschluss filtert, achtet auf ein Signal, das nicht verrät, wer die Arbeit gut machen wird.
Der Hintergrund prägt den Kommunikationsstil, und Teams brauchen die Mischung
Unterschiedliche Ausbildungen bringen unterschiedliche Arten mit, über das Testen zu sprechen, und ein starkes Team braucht alle davon. Als die Befragten ihre Herangehensweise beschrieben, zeigten sich klare Muster je nach Studienfach.
Geisteswissenschaftler schrieben klar, gut formuliert, fast wie eine Geschichte. Sie sprachen über Menschen und die Probleme, die sie lösen. Sozialwissenschaftler dachten von der Organisation her, von Teams und davon, wie Menschen zusammenarbeiten. Naturwissenschaftler lieferten geordnete Listen, knapp, aber aussagekräftig und mit echter Struktur. Menschen ohne Abschluss erzählten am liebsten, so als säße man gemeinsam bei einem Bier.
IT-Absolventen lieferten viele technische Details, oft aber schlecht gegliedert, mühsam zu lesen und ohne erzählerischen Faden.
“Wir brauchen die Geistes- und Sozialwissenschaftler, damit wir in der Organisation kommunizieren und unsere Geschichte erzählen, und wir brauchen die Naturwissenschaftler, die uns Ordnung und Struktur geben.”
(Isabel Evans)
Für die Praxis heißt das: Technisches Können zählt, aber jemand muss Risiken kommunizieren, erklären, was die Tests gefunden haben, und nachfragen, was die Stakeholder brauchen. Genau dafür braucht es kommunikative Stärken, die eine IT-Ausbildung eher nicht fördert.
Wie schlechte Test-Tools Tester frustrieren
Wie Tester ihre Tools erleben, ist emotional stark aufgeladen, und vieles davon ist negativ. Schon in Isabels früherer Forschung tauchten neben positiven Gefühlen vor allem Frust und Ärger rund um die Tools auf, insgesamt mit hoher emotionaler Intensität. Damit wird Tool-Qualität zu einer Frage von Gesundheit und Wohlbefinden am Arbeitsplatz, nicht nur von Produktivität.
Als Hauptverdächtige galt die Usability, und die spielte auch eine Rolle, nur nicht auf die offensichtliche Art. Das problematischste Qualitätsmerkmal war die Operabilität: ob das Tool es einem erlaubt, im eigenen Arbeitsablauf zu bleiben und die Aufgaben zu erledigen, die zum eigentlichen Ziel führen.
Dieser Befund stammt aus offenen Fragen, nicht aus Suggestivfragen. Die Teilnehmenden sollten eine Erfahrung mit einem Tool schildern. Die Qualitätsmerkmale wurden erst aus ihren Antworten herausgearbeitet, vorher wurde keines genannt.
Die Illusion der Usability: schöne Oberflächen, die im Einsatz versagen
Ein Tool kann benutzerfreundlich aussehen und die Arbeit trotzdem behindern, und genau in dieser Lücke entsteht der meiste Ärger. Manche Tools wurden gekauft, weil die Oberfläche ansprechend war. Sie sah gut aus. Sobald aber damit getestet wurde, passte das Tool nicht zu der Art, wie die Leute tatsächlich arbeiten.
Isabel nennt das die Illusion der Usability, also der Gebrauchstauglichkeit. Oberflächlicher Glanz wirkt in der Evaluierung wie gute Bedienbarkeit und fällt in sich zusammen, sobald echte Aufgaben anstehen. Wer ein Tool auswählt, sollte es deshalb am eigenen Arbeitsablauf testen, nicht an einem Demo-Bildschirm.
Warum kein Framework das perfekte Test-Tool hervorbringt
Ein einzelnes Framework, das das ideale Test-Tool ausspuckt, gibt es nicht, dafür sind es zu viele Variablen. Isabel wollte ursprünglich genau so etwas bauen: Informationen rein, Antwort raus, wie das Tool aussehen soll. Dieser Anspruch hielt nicht lange.
Den Kurswechsel brachte der Wissenschaftler Hussein Dugan. Sein Vorschlag: Der Beitrag sollte eine Sammlung von Heuristiken sein, kein Framework. Kein Werkzeug, das Werkzeuge baut, keine Lösung für das ganze Problem, sondern Fragen, die Entwickler und Evaluatoren auf Basis der Forschungsergebnisse durchdenken.
So funktionieren die 12 Heuristiken in der Praxis
Die Heuristiken sind 12 Fragen, keine 12 Antworten, denn die richtige Antwort hängt vom Kontext ab. Sie verlangen Nachdenken statt Abhaken. Wohin eine Frage führt, zeigt, wie das Tool gestaltet sein sollte oder ob es passt.
Eine feste Reihenfolge gibt es nicht. In Fallstudien aus der Industrie griffen die Beteiligten jeweils die Fragen heraus, die in ihrem Kontext wichtig waren, gingen sie in eigener Reihenfolge durch und kamen später im Prozess auf einzelne Fragen zurück. Die Heuristiken sind als Denkhilfe gedacht und bewusst flexibel.
| Aspekt | Was die Heuristiken sind | Was sie nicht sind |
|---|---|---|
| Form | 12 Fragen | Eine Sammlung fester Antworten |
| Einsatz | Denkhilfe, mit Urteilsvermögen angewendet | Eine lineare Checkliste |
| Reihenfolge | Nach Kontext gewählt und wieder aufgegriffen | Eine feste Abfolge von 1 bis 12 |
| Zweck | Ein Tool entwerfen oder bewerten | Ein Framework, das das Tool für dich entwirft |
Geplant ist, sie nach Expertenreviews und Verfeinerung in Fallstudien in einem Repository unter Creative-Commons-Lizenz zu veröffentlichen. Wer eigene Tools baut, auf Open Source aufsetzt, Tools verkauft oder im Team Tools bewertet, kann sie dann aufgreifen und frei nutzen.
Wie sich Recruiting jenseits des IT-Klischees öffnen lässt
Der erste Schritt: die Belege direkt zu den Leuten bringen, die einstellen. Das Klischee sitzt in HR-Prozessen und Karrieredatenbanken, also muss dort das Gespräch stattfinden, und zwar nicht nur für Tester. Dieselbe Verengung trifft Entwickler, UX-Leute, Product Owner, Systemanalytiker und Architekten.
Die veröffentlichte Forschung liefert dafür etwas Handfestes. Du kannst sie deiner Personalabteilung, deinen Recruitern und deinen Führungskräften vorlegen und damit die Diskussion anstoßen, wer eigentlich ermutigt wird, sich zu bewerben.
Ein vielfältiges Team ist außerdem ein repräsentatives Team. Wenn Software für alle Menschen gebaut wird, ergibt es wenig Sinn, dass sie nur von einer kleinen, engen Gruppe entwickelt wird. Wer den Kreis derer erweitert, die sich in der IT zu Hause fühlen dürfen, sorgt dafür, dass Teams die Menschen abbilden, für die sie arbeiten.
Häufig gestellte Fragen
Wie gut passen die Klischees über IT-Persönlichkeiten zu den Leuten, die tatsächlich in der Branche arbeiten?
Kaum. McChesneys britische Studie verglich Leute, die in der IT arbeiten, solche, die in die Branche einsteigen wollen, und das Klischee, das in den Rekrutierungsdatenbanken verankert ist. Nur etwa ein Viertel bis ein Drittel der berufstätigen IT-Fachkräfte entsprach diesem Profil, und die Berufseinsteiger lagen näher am Klischee als die Praktiker. In Isabel Evans’ Stichprobe unter Testern passten sechs Prozent darauf.
Aus welchen Bereichen kommen Menschen, die im Testen arbeiten?
Aus weitaus mehr Bereichen, als die Berufsbezeichnung vermuten lässt. Isabel Evans’ Branchenumfrage brachte Tester zutage, die aus den Bereichen Bootsbau, Theaterwissenschaft, Internationale Beziehungen, Stadtplanung und Kunst kamen. Ihre Ausbildung reichte von Abschlüssen in Geisteswissenschaften, Naturwissenschaften, Sozialwissenschaften bis hin zu IT-Studiengängen, und manche hatten gar keinen Abschluss. Die meisten hatten vor ihrer Tätigkeit als Tester ganz andere Jobs ausgeübt.
Ist ein Informatikstudium ein nützliches Auswahlkriterium bei der Rekrutierung von Testern?
Nein. Etwa vierzig Prozent der gefragten Absolventen aus den Geisteswissenschaften waren in der Testautomatisierung und im technischen Testen tätig, und etwa vierzig Prozent der IT-Absolventen hatten nicht-technische Aufgaben. Das Studienfach sagt weder etwas über die Eignung noch darüber aus, welche Arbeit jemand letztendlich ausübt; eine Auswahl danach schließt fähige Kandidaten aus, ohne die Auswahlliste zu verbessern.
Warum profitiert ein Team beim Testen von Leuten, die kein technisches Fach studiert haben?
Weil die Art und Weise, wie über das Testen kommuniziert wird, vom Bildungshintergrund abhängt, und ein Team diese Vielfalt braucht. Geisteswissenschaftler verfassten klare, erzählerische Beschreibungen über Menschen und die Probleme, die sie gelöst haben. Sozialwissenschaftler betrachteten die Dinge aus der Perspektive von Organisationen und Teams. Naturwissenschaftler erstellten geordnete, prägnante, informative Listen. IT-Absolventen lieferten technische Details, die oft schlecht strukturiert und wenig erzählerisch waren.
Welches Qualitätsproblem bereitet Testern bei ihren Tools die größten Schwierigkeiten?
Die Operabilität, nicht das Aussehen. Die entscheidende Frage ist, ob das Tool es einer Person ermöglicht, ihren Arbeitsablauf fortzusetzen und die Aufgaben zu erledigen, die zum eigentlichen Ziel führen. Die Gebrauchstauglichkeit spielte zwar eine Rolle, aber nicht auf die offensichtliche Weise. Der Befund ergab sich aus offenen Fragen: Die Leute beschrieben ihre Erfahrungen mit einem Tool, und die Merkmale der Qualität wurden erst im Nachhinein herausgearbeitet.
Was solltest du prüfen, bevor du ein Testtool mit einer attraktiven Benutzeroberfläche kaufst?
Teste es anhand deines tatsächlichen Arbeitsablaufs, nicht anhand eines Demo-Bildschirms. Manche Tools wurden gekauft, weil ihre Benutzeroberflächen gut aussahen, unterstützten dann aber die tatsächlichen Testabläufe nicht, sobald die Arbeit losging. Isabel Evans nennt das die Illusion der Usability (Gebrauchstauglichkeit): Eine oberflächlich ausgefeilte Oberfläche wirkt bei der Bewertung benutzerfreundlich, bricht aber bei echten Aufgaben zusammen.
Warum endet die Forschung zur Qualität von Testtools eher mit Fragen als mit einer Checkliste?
Weil es zu viele Variablen gibt, als dass ein einziges Rahmenwerk sie alle abdecken könnte, und die richtige Antwort vom Kontext abhängt. Isabel Evans gab ihren ursprünglichen Plan für ein Rahmenwerk auf, nachdem der Wissenschaftler Hussein Dugan stattdessen Heuristiken vorgeschlagen hatte. Das Ergebnis sind 12 Fragen. In Fallstudien aus der Praxis wählten die Beteiligten unterschiedliche Fragen als wichtig aus, gingen sie in ihrer eigenen Reihenfolge durch und kamen später darauf zurück.
Wie kann ein Unternehmen den Kreis der Bewerber für IT-Stellen erweitern?
Bring die Fakten zu den Leuten, die einstellen. Das Klischee ist in HR-Prozessen und Karrieredatenbanken verankert, genau dort gehört die Diskussion also hin: zu den Personalvermittlern, Personalabteilungen und Führungskräften. Die gleiche Verengung betrifft Entwickler, UX-Experten, Product Owner, Systemanalysten und Architekten. Software, die für alle entwickelt wird, passt schlecht zu einer kleinen Gruppe von Entwicklern.
