Die Qualitätssicherungsabteilung (QS) sucht nach Fehlern in der Software. Die Methoden variieren von Unternehmen zu Unternehmen, dies wird jedoch normalerweise von Mitarbeitern durchgeführt, die mit der Software vertraut sind. Sie verwenden es auf verschiedene Arten und versuchen, Fehler zu finden, die Entwickler übersehen haben.

Der Begriff QS kann sich auf den Prozess selbst, auf die Organisation sowie auf einen einzelnen Tester innerhalb dieser Organisation beziehen. In der Regel werden Tester in einer Qualitätssicherungsorganisation als „QS“ bezeichnet. In diesem Artikel verwenden wir aus Gründen der Konsistenz die allgemeine Abkürzung QS anstelle des genaueren „Qualitätssicherungstesters“.

Verschiedene Unternehmen haben unterschiedliche QS-Verantwortlichkeiten für die Gesamtqualität des Produkts. Manchmal ist der Begriff „Qualitätssicherung“ für diese Abteilung nicht vollständig anwendbar, wenn nur nach Fehlern gesucht und deren Anzahl gezählt wird.

Die folgenden Personen sind in der QS-Abteilung problematisch:

• Feuerwehrschlauch
• Der Staatsanwalt
• Alarmist
• Wissenschaftler
• Irreführend
• Unterdrückt
• Zufälliger Clicker
• Freudig mutig

Feuerwehrschlauch

Ein Tester, der so viele Fehlermeldungen so schnell meldet, dass das Entwicklungsteam niemals fertig wird.

• Kann zu Alarmisten mutieren
• In Kombination mit einem Projektmanager wie Statistik ist dies gefährlich
• Korrekturwahrscheinlichkeit: hoch
• Gefahr für das Projekt: hoch

Das Problem

Wenn ein Fehler gefunden wird, ist es wichtig, einen eindeutigen Bericht zu erstellen und ihn sofort dem entsprechenden Entwickler zuzuweisen. Einige Tester können Fehler jedoch schneller finden, als das Entwicklungsteam sie behebt. Aus diesem Grund wächst die Liste der Fehler ständig und alle können niemals geschlossen werden.

Auf den ersten Blick scheint es ein Problem mit der Qualität des Produkts zu geben, aber dies ist nicht immer der Fall. Im Gegensatz zu einem herkömmlichen Tester, der mit einem sehr fehlerhaften Programm arbeitet, erzeugt ein Feuerwehrschlauch eine Lawine von Berichten mit einer oder mehreren charakteristischen Eigenschaften:

• Ihre Berichte sind schlecht detailliert, was eine schnellere Meldung von mehr Fehlern ermöglicht.
• Viele Fehler sind Duplikate anderer, da sie nur Variationen eines Hauptgrundes sind.
• Es ist keine Zeit, den Fehler zu reproduzieren, da es ausreicht, ihn einmal zu sehen, um einen Bericht zu schreiben.

Feuerwehrschlauchprüfer stehen häufig unter direktem oder indirektem Unternehmensdruck: Je mehr Fehler Sie finden, desto besser erledigen Sie Ihre Arbeit . Dies führt dazu, dass QS-Tester, die die eigentliche Fehlerursache sorgfältig überwachen und diese klar und präzise melden, als weniger produktiv gelten als Feuerwehrschläuche, die die maximale Anzahl von Berichten pro Zeiteinheit ausgeben.

Die Aktivitäten solcher Tester können zu Panik im Projekt führen, da das Produkt anscheinend von schlechter Qualität ist und das Projekt nun hinter dem Zeitplan zurückliegt. Ihr Einfluss auf die Moral kann unmittelbar und dramatisch sein: Das Entwicklungsteam betet darum, den Fluss der Fehlerberichte zu unterbrechen.

Lösung

Vor dem Reparieren eines Feuerwehrschlauchs ist es wichtig, ihn genau zu identifizieren und nicht mit einer effektiven Qualitätssicherung zu verwechseln, die mit einem sehr fehlerhaften System kollidiert. Die klarsten Beweise stammen aus Beschwerden von Entwicklern:

• Die meisten Fehler sind Duplikate.
• Viele Fehler haben die gleichen offensichtlichen Ursachen, sodass sie als ein Fehler gemeldet werden können.
• Fehlermeldungen enthalten keine Details.

Um Abhilfe zu schaffen, sollte dem Feuerwehrschlauch erklärt werden, dass es keinen Anreiz gibt, eine große Anzahl von Fehlern zu melden. Ziel ist es, die Qualität des Systems zu verbessern und Entwicklern zu helfen. Danach sollte sich die Qualität des Produkts im gleichen (oder besseren) Tempo verbessern, jedoch ohne Panik.

Der Staatsanwalt

QA, die Entwickler nach jedem gefundenen Fehler beschuldigt, ihr Programm nicht getestet zu haben.

• Kann zu Alarmisten mutieren
• In Kombination mit einem Projektmanager wie Statistik ist dies gefährlich
• Korrekturwahrscheinlichkeit: hoch
• Gefahr für das Projekt: gering

Das Problem

Theoretisch kann ein Entwickler jeden Fehler finden und beheben, bevor er das Produkt an die QS-Abteilung überträgt. Daher sehen einige Tester jeden gefundenen Fehler als einen weiteren Beweis dafür an, dass die Entwickler ihre Arbeit nicht gut genug testen. Dieses unwiderlegbare Argument ermöglicht es dem Staatsanwalt, eine abweisende Meinung über das Entwicklungsteam noch lauter zu äußern.

Der Staatsanwalt frisst die Moral des Teams weg. Anstatt zur Verbesserung der Produktqualität beizutragen, versucht er zu beweisen, dass das Entwicklungsteam die Arbeit nicht erledigt. Jeder Fehler wird dem Haufen von Beweisen hinzugefügt, dass Entwickler sich übermäßig auf die Qualitätssicherung verlassen, anstatt Fehler selbst zu identifizieren.

Leider werden Staatsanwälte aufgrund eines typischen und ziemlich vorhersehbaren Prozesses geschaffen:

1. In der Produktion wurde ein kritischer Fehler festgestellt.
2. Dem Tester wird vorgeworfen, diesen Fehler verpasst zu haben.

Dies kommt zu oft vor und daher verteidigt sich die Qualitätssicherung natürlich mit einem unwiderlegbaren Argument.

Lösung

Bevor ein Ankläger korrigiert wird, muss eine Organisation zunächst aufhören, die Qualitätssicherung für Produktionsfehler verantwortlich zu machen. Diejenigen, die dies tun, müssen in produktiveren Methoden zur Verbesserung der Softwarequalität geschult werden.

Wenn die Organisation aufgehört hat, die Qualitätssicherung für Fehler in der Produktion verantwortlich zu machen, können Sie den Tester-Ankläger beheben, indem Sie ihn einladen, seine Meinung und seine Einstellung zu ändern.

Es sollte ihm klar gemacht werden, dass die Entwickler nur Menschen sind und alle Menschen dazu neigen, Fehler zu machen. Die QS-Abteilung muss dieses natürliche menschliche Eigentum der Entwickler kompensieren und als Schutz vor Fehlern dienen, die Kunden betreffen. Darüber hinaus ist es für einen Entwickler aufgrund des langwierigen und langwierigen Codierungsprozesses sehr einfach, den Wald hinter den Bäumen nicht zu sehen: Er konzentriert sich so darauf, ein bestimmtes Problem zu lösen, dass er vergisst, nach scheinbar offensichtlichen Dingen zu suchen.

Änderung der Einstellung: Wir müssen uns daran erinnern, dass wir alle in einem Team arbeiten. Kameraden sollten sich nicht gegenseitig für Fehler verantwortlich machen, sondern helfen, sie zum Wohle des Teams zu korrigieren. Für die Qualitätssicherung ist es besonders wichtig, im Rahmen des Projekts Partnerschaften mit dem Entwicklungsteam aufzubauen. Der ununterbrochene Prozess der Erkennung von Fehlern, der Meldung und des Lebenszyklus ihrer Behebung ist für die Qualität des Produkts von entscheidender Bedeutung.

Alarmist

QS, die besagt, dass das gesamte Produkt ein inakzeptables Qualitätsniveau aufweist, während seine Meinung nur auf einem oberflächlichen Eindruck beruht.

• Kann im Ankläger oder Feuerwehrschlauch mutieren
• Gefährlich in Kombination mit einem Projektmanager wie einem Pessimisten
• Korrekturwahrscheinlichkeit: hoch
• Gefahr für das Projekt: hoch

Das Problem

Im Kern haben verschiedene Anwendungsmerkmale unterschiedliche Qualität. Einige können relativ einfach sein oder von hochqualifizierten Entwicklern entwickelt werden, und daher gibt es nur wenige oder keine Fehler. Andere sind relativ hoch entwickelt oder werden von weniger erfahrenen Entwicklern entwickelt - und sind daher voller Fehler. Der Alarmist hatte nicht das Glück, sofort auf ein Gebiet von schlechter Qualität zu stoßen - und ohne weitere Untersuchung gab er bekannt, dass das gesamte Produkt ungeeignet sei .

Sie können viel darüber sprechen, wie QAs-Reifenentwickler ihre Zeit verschwenden (siehe einen Tester des Typs, der irreführend ist ), aber dies ist eine zweifache Situation. Tatsächlich gibt der Entwickler zu oft QS-schlecht getestete Software bewusst, um eine Belohnung für die geleistete Arbeit zu erhalten oder um zu erklären, dass er die Frist eingehalten hat. Wenn QA mit dem Testen eines solchen Systems beginnt, stößt es sofort auf viele Fehler, die der Entwickler hätte sehen müssen. Daher ist es klar, dass er das, was er gesehen hat, auf das gesamte Produkt hochrechnet und eine kritisch niedrige Qualität behauptet.

Ein Alarmist hat normalerweise eine gewisse Autorität in der QS-Abteilung, und seine Meinung wird respektiert. Je höher seine Autorität ist, desto zerstörerischer sind die Auswirkungen auf das Projekt. Ein typisches Szenario ist wie folgt:

• Das Produkt wird an die Qualitätssicherung übergeben.
• Ein Alarmist beginnt, einen Bereich von schrecklicher Qualität zu testen.
• Der Alarmist stoppt alle Tests und informiert die Behörden über ein ernstes Problem mit der Qualität des Produkts.

Dies ist ein klassischer Fall, bei dem ein Kind mit Wasser geworfen wird. Manchmal trifft die Qualitätssicherung die richtige Wahl, insbesondere wenn das Entwicklungsteam den Ruf hat, nicht verifizierte Software an die Qualitätssicherung zu übertragen. Es kommt jedoch vor, dass der Alarm aufgrund eines schwachen Entwicklers ausgelöst wird, dessen Code als erster zu einem Panikmacher kam.

Lösung

Ein Tester wird zum Alarmisten, wenn er wiederholt von einem Entwicklungsteam enttäuscht wurde. Wenn sie immer hochwertige Software liefern würde, gäbe es keinen Grund zum Misstrauen. Wenn der Tester jedoch ein Alarmist wird, wird es für das Entwicklungsteam schwierig sein, das Vertrauen wiederzugewinnen, insbesondere wenn das Team wirklich Entwickler hat, die einen Elefanten im Porzellanladen haben und inkompetent sind .

In großen Entwicklungsteams entsteht Code von geringer Qualität normalerweise von einzelnen Entwicklern, nicht vom gesamten Team. Daher ist es unbedingt erforderlich, dass die Arbeit weniger kompetenter Entwickler zuletzt getestet wird oder dass sie nicht in den Alarmisten fällt. Dies verbirgt jedoch das wahre Problem, dass es Entwickler im Team gibt, die sich negativ auf das Projekt auswirken .

Wissenschaftler

Ein Tester, der die meiste Zeit damit verbringt, Fehler zu dokumentieren und keine neuen zu finden.

• Kann in den Unterdrückten mutieren
• Gefährlich in Kombination mit einem Produktmanager wie dem Patentautor
• Korrekturwahrscheinlichkeit: hoch
• Gefahr für das Projekt: gering

Das Problem

Das Auffinden von Problemen im System kann genauso spannend sein wie die Schatzsuche. Und wenn Sie diesen Schatz finden, ist es nicht weniger interessant, das Rätsel zu lösen. Es kann argumentiert werden, dass ein Tester, der den Prozess des Auffindens von Fehlern auf diese Weise betrachtet, ideal ist. Ein Problem entsteht jedoch, wenn er seine faszinierende Reise sorgfältig dokumentieren möchte. Anstatt sich auf das Hauptproblem zu konzentrieren, muss der Entwickler eine lange Geschichte mit vielen nicht hilfreichen Details lesen und versuchen, die relevanten Informationen auszuwählen.

Der Wissenschaftler sieht buchstäblich die Notwendigkeit, "Fehler sorgfältig zu dokumentieren". Er beschreibt sie in Form einer Textgeschichte und nicht in Form einer kurzen Beschreibung mit einer klaren Abfolge von Schritten zur Reproduktion. Das Lesen solcher Berichte nimmt viel Zeit in Anspruch, und am Ende ist immer noch unklar, wo genau das Problem liegt. In der Regel enthält eine solche Beschreibung mehrere Fehler, die sich auf einen weiten Bereich des Systems und nicht auf ein bestimmtes Problem beziehen.

Die Hauptbeschwerde von Entwicklern beim Empfang von Fehlermeldungen von Wissenschaftlern ist, dass das Signal-Rausch-Verhältnis zu niedrig ist. Sie verbringen Zeit damit, den Strom des Bewusstseins zu durchsuchen und nach bestimmten Details zu suchen. Dies ist sowohl für den Entwickler als auch für den Tester Zeitverschwendung.

Lösung

Ein QS-Wissenschaftler lässt sich leicht korrigieren, indem er ihm beibringt, wie man die richtigen Berichte schreibt. Oft erfolgt die Korrektur sofort, sobald sie erklären, was von ihm verlangt wird. Der effektivste Weg, den richtigen Stil zu vermitteln, besteht darin, einen oder mehrere Berichte im richtigen Format neu zu schreiben, das als Modell für die Zukunft dienen wird. Infolgedessen schreibt ein begeisterter Tester klare und präzise Berichte über Fehler, die nicht idealer gemacht werden können.

Irreführend

Eine Qualitätssicherung, bei der Fehler häufig ungenau gemeldet werden, führt den Entwickler in die falsche Richtung, wenn er versucht, das Problem zu reproduzieren und zu beheben.

• Kann zu Alarmisten mutieren
• In Kombination mit einem Projektmanager wie Statistik ist dies gefährlich
• Korrekturwahrscheinlichkeit: hoch
• Gefahr für das Projekt: hoch

Das Problem

Der Fehlerbericht sollte Folgendes enthalten:

1. Die Fähigkeit festzustellen, dass tatsächlich ein Fehler vorliegt
2. Möglichkeit, Schritte zum Abspielen eines Fehlers zu definieren
3. Eine vollständige Beschreibung des Fehlers, häufig mit einer Grundursache
4. Klare Schritte zum Abspielen eines Fehlers

In jeder dieser Phasen kann der Bericht den Entwickler irreführen, wodurch er Zeit verschwendet:

• Wenn kein Fehler auftritt, sucht der Entwickler nach einem Problem, das nicht vorhanden ist
• Wenn der Fehler nicht reproduziert werden kann, verbringt der Entwickler Zeit mit seiner Reproduktion
• Wenn der Fehler nicht richtig beschrieben wird, verbringt der Entwickler viel Zeit damit, nach einer zu spezifischen oder zu breiten Grundursache zu suchen
• Wenn die Schritte zum Reproduzieren ungenau sind, verbringt der Entwickler viel Zeit damit, sie zu interpretieren, oder erklärt möglicherweise keinen Fehler, obwohl er dies tut

Manchmal ist ein Entwickler aufgrund eines einfachen Testerfehlers verwirrt. Ein irreführender Tester generiert jedoch häufig solche Berichte, was bei den Entwicklern zu erheblicher Unzufriedenheit führt. Wenn die Situation weiterhin besteht, verliert der Tester schließlich das Vertrauen der Entwickler, und diese beheben nicht einmal mehr echte Fehler und lehnen solche Fehlerberichte ab.

Lösung

Die irreführende Qualitätssicherung ist oft gut darin, Fehler zu finden und sie nur schlecht zu dokumentieren. Daher lohnt es sich, ihn zu trainieren.

Eine der effektivsten Methoden ist die Überwachung des Entwicklers, der anhand seines Berichts versucht, das Problem zu identifizieren. Es reicht aus, sich einfach neben den Entwickler zu setzen, der einen seiner Berichte erhalten hat, und ruhig (ohne Einmischung) zu beobachten, wie der Entwickler versucht, es herauszufinden. Normalerweise führt dies zu einem gesunden Gespräch darüber, wie Fehler am besten gemeldet werden können, was sowohl dem Entwickler als auch der Qualitätssicherung zugute kommt.

Unterdrückt

Qualitätssicherung, die von Entwicklern so weit geschlagen wird, dass es unwahrscheinlich ist, dass Fehler gemeldet werden, da Mobbing befürchtet wird.

• Kann zu einem frechen Mut mutieren
• Gefährlich in Kombination mit Primadonna- Typen und Geiselnehmern
• Korrekturwahrscheinlichkeit: Niedrig
• Gefahr für das Projekt: gering

Das Problem

Vielleicht gibt es keine größere Manifestation von Nachsicht als die typische Einstellung der Entwickler zur Qualitätssicherung. Außerdem kann man oft sehen, dass aggressive Entwickler den Tester offen einschüchtern, selbst wenn er einen natürlichen Fehler in ihrem Code meldet. Um dem entgegenzuwirken, sollte eine erfolgreiche Qualitätssicherung bei der Arbeit mit aggressiven Entwicklern die folgenden Merkmale aufweisen:

• Bereits das große Vertrauen der Entwickler gewonnen, so dass seine Fehler immer ernst genommen werden.
• Kann nicht weniger Aggression und Ausdauer in einem Streit mit einem Entwickler zeigen, der den Fehler nicht erkennt.

Leider haben nicht viele Tester solche Eigenschaften, so dass Entwickler sich oft die Füße abwischen und in erster Linie der Qualitätssicherung vorwerfen, einen neuen Fehler entdeckt zu haben. Egal wie unlogisch es auch erscheinen mag, dies ist ein typisches Bild unter folgenden Bedingungen:

• Der Entwickler hat ein hohes Selbstbewusstsein (siehe Entwickler wie eine Primadonna ).
• Der Entwickler glaubt, besser als der Tester zu wissen, wie das System funktioniert (siehe einen Entwickler wie einen Geiselnehmer )

Nachdem die Qualitätssicherung im Laufe der Zeit gründlich geschlagen wurde, wird normalerweise die Konfrontation mit feindlichen Entwicklern vermieden, um Stress abzubauen. Infolgedessen werden Fehler dieser spezifischen Entwickler selten gemeldet, obwohl sie möglicherweise vorhanden sind. In der Regel wird eine Situation nur erkannt, wenn Probleme in der Produktion auftreten und eine Untersuchung beginnt, warum die Testabteilung keinen Fehler festgestellt hat. Ein depressiver Tester gibt eine der folgenden Erklärungen:

• Er sprach mit dem Entwickler und sagte, dass dies kein Fehler sei.
• Er reichte einen Fehlerbericht ein, der jedoch vom Entwickler abgelehnt wurde.
• Er fand einen Fehler, aber "hielt es nicht für wichtig genug."

Ein passiver Charakter macht es oft schwierig, eine unterdrückte Qualitätssicherung zu erkennen. Der Schlüssel wird darin bestehen, die Entwickler zu analysieren, mit denen diese Qualitätssicherung zusammenarbeitet, und nach offensichtlichen Anzeichen von Feindseligkeit zu suchen.

Lösung

Entwickler verspotten Tester sehr oft direkt. Daher sollten sie wie alle Hooligans behandelt werden:

• Fordern Sie, sofort aufzuhören, sich über die Qualitätssicherung lustig zu machen, und aggressives Verhalten zu unterlassen.
• Professionelle Kommunikation trainieren.
• Ablehnen, wenn der Entwickler sein Verhalten nicht korrigieren kann.

In besonders schweren Fällen muss die Personalabteilung eingreifen, insbesondere wenn die Situation zu offener Feindseligkeit verkommen ist.

Es ist traurig, dass diese Situation eher die Norm als die Ausnahme ist. Der einzige Unterschied ist der Grad der Feindseligkeit.

Zufälliger Clicker

Qualitätssicherung, die per Zufallsklick nach Fehlern sucht.

• Kann in einem Feuerwehrschlauch mutieren
• Gefährlich in Kombination mit einem Produktmanager wie dem Patentautor
• Korrekturwahrscheinlichkeit: Niedrig
• Gefahr für das Projekt: gering

Das Problem

Die Suche nach Fehlern im System erfolgt nach zwei Hauptmethoden:

1. Entsprechend dem Testplan durch methodische Bearbeitung der Liste der Testfälle.
2. Zufälliges Herumwandern in der Anwendung, um Benutzeraktionen zu emulieren.

Das Schreiben eines Testplans ist eine zeitaufwändige Aufgabe, und es gibt keine Garantie dafür, dass der Plan zu Beginn des Tests nach Änderung der Anforderungen weiterhin relevant ist. Dies kann dazu führen, dass der Tester die Testpläne vollständig aufgibt und stattdessen nur mit der Anwendung interagiert, in der Hoffnung, Fehler zu finden.

In der Tat zeigt eine versehentliche Interaktion mit der Anwendung Fehler, insbesondere in einem frühen Stadium der Produktentwicklung. Wenn das Produkt jedoch älter wird, wird es viel schwieriger, Fehler auf diese Weise zu finden, da die verbleibenden Fehler in Grenzfällen verborgen sind. Dies führt zu einem falschen Sicherheitsgefühl, als ob die Anwendung keine Fehler aufweist, obwohl sie einfach nicht ordnungsgemäß getestet wurde.

Es ist wichtig zu bedenken, dass die zufällige Interaktion mit der Anwendung eine akzeptable Methode bleibt, da sie Situationen aufdecken kann, die nicht im Plan dokumentiert sind. Dies ist jedoch nur eine Ergänzung des Testplans, kein Ersatz.

Lösung

Ein zufälliger Klicker kann in einem von zwei Fällen auftreten:

1. Ihm wurde nicht beigebracht, wie man die Anwendung richtig testet.
2. Er vermeidet aktiv das Schreiben eines Testplans.

Wenn das Problem mangelnde Schulung ist, müssen Sie diese bereitstellen. In diesem Fall kann der Tester jedoch immer noch in die zweite Kategorie fallen und möchte keinen Testplan erstellen, selbst wenn er weiß, dass er dies tun sollte.

Das Schreiben eines guten Testplans erfordert ein seltenes Maß an Organisation, Sorgfalt und Konzentration. Infolgedessen genießen bestimmte Arten von Menschen solche Arbeit, die meisten jedoch nicht. Wenn Sie sehr viel Glück haben, findet der zufällige Klicker die Eigenschaften, die zum Schreiben guter Testpläne erforderlich sind, aber die Wahrscheinlichkeit ist gering.

Freudig mutig

Ein Tester, dessen Berichte so passiv aggressiv sind, dass Entwickler sie als unhöflich interpretieren.

• Kann zum Staatsanwalt mutieren
• Gefährlich in Kombination mit einem Entwickler vom Typ Diva
• Korrekturwahrscheinlichkeit: Niedrig
• Gefahr für das Projekt: gering

Das Problem

Das korrekte Melden eines Fehlers ist ein zeitaufwändiger und kognitiv schwieriger Prozess, und einige QAs möchten nicht genügend Aufwand betreiben. In der Regel handelt es sich dabei um Tester mit einigen Rechten: Sie glauben, dass sie nicht versuchen müssen, den Wortlaut zu wählen. Sie schauen die Entwickler auch oft verächtlich an und glauben nicht, dass es sich lohnt, Zeit für eine Art Fehleranalyse aufzuwenden: Eine allgemeine Aussage reicht aus, damit die Entwickler es wagen, herauszufinden, was los ist.

Typische Fehlerberichte eines unachtsamen Testers enthalten die folgenden Sätze:

• "Es funktioniert nicht."
• "Es ist wieder kaputt."
• "Das Problem wäre offensichtlich, wenn Sie diese Funktion tatsächlich verwenden würden."
• "Ich weiß nicht, warum sie es verpasst haben."
• "Überprüfen Sie es das nächste Mal sorgfältig"
• "Ich weiß nicht, warum wir es nicht richtig implementieren können."

Offensichtlich sind Entwickler mit Berichten, die ähnliche Ausdrücke anstelle von Schritten verwenden, um den Fehler zu reproduzieren, nicht sehr zufrieden. Dies wird selten von einem professionellen QS-Analysten durchgeführt, tritt jedoch häufig auf, wenn ein anderer Mitarbeiter des Unternehmens, der nach Fehlern gesucht wurde, einen Fehler meldet. Dies geschieht normalerweise, wenn vor der Veröffentlichung nur noch wenig Zeit verbleibt und nicht genügend Tester vorhanden sind. Infolge dieser "Hilfe" kommt es normalerweise zu Chaos, da Berichte von Entwicklern abgelehnt werden, was zu noch mehr Kontroversen im Team führt, was die Empörung weiter vertieft.

Lösung

Im Allgemeinen sollten professionelle Tester dafür verantwortlich sein, Fehler zu finden. Leider gibt es in der Branche die Meinung, dass jeder nach Fehlern suchen kann, aber das ist nicht so. Es ist genauer zu sagen, dass jeder einen Fehler erkennen kann, aber in der Regel können nur professionelle QS-Spezialisten wichtige Fehler, die in Grenzsituationen verborgen sind, identifizieren und so melden, dass der Entwickler diesen Fehler sofort verstehen, reproduzieren und daher beheben kann.

Ein nachlässig handelnder Tester glaubt, dass er jedes Recht auf solche leichtfertigen Berichte hat. Wenn er in die QS-Abteilung eintritt, sollte er gewarnt werden, sein kontraproduktives Verhalten zu korrigieren. Wenn die Suche nach Fehlern nicht in seiner direkten Verantwortung liegt, sollte es ihm untersagt sein, Fehler zu melden, bis er lernt, dies professionell zu tun.

Es ist oft viel effizienter, den nachlässig gewagten Tester einfach zu entfernen, als zu versuchen, ihn zu reparieren. Durch seine Handlungen macht er definitiv klar, dass er sich nicht auf Tests einlassen möchte, daher liegt das Entfernen im gemeinsamen Interesse.

Siehe auch:

• "Problempersonen unter Entwicklern"
• "Problempersonen unter Projektmanagern"