Im Laufe meiner Karriere hatte ich verschiedene Erfolge mit QA. Ich gebe zu, dass ich Fehlerberichte persönlich nehmen kann, aber normalerweise, wenn sie in einem Freiform-Stil hergestellt werden, der mehr wie eine Beschwerde formuliert: "Dieser Prozess funktioniert immer noch nicht!", Ohne ausreichende Informationen, um den Fehler zu reproduzieren.
>Ich bin bereit, an meiner Sensibilität für Kritik zu arbeiten, aber ich wäre auch an Tools und Techniken interessiert, die den QA-Prozess entpersonalisieren und informative Fehlerberichte anregen. Derzeit werden Fehler per E-Mail gemeldet oder manchmal, indem man sie aufruft und verbalisiert.
Alle Werkzeuge sollten: frei wie in Bier und einfach zu installieren / niedrige Verwaltung sein. Ich bin auch offen für Blog-Posts, Bücher oder Artikel darüber, wie ich mich selbst zu Fehlerberichten desensibilisieren kann.
Erhalte ein echtes Fehlerverfolgungssystem. FogBugz, Bugzilla, was auch immer (Ich bin kein Splint für Spolsky, aber ich werde sagen, dass FB bei weitem das am einfachsten zu bedienende System für unsere Tester ist, und einfach zu bedienen ist wirklich wichtig für sie). Dies macht es viel einfacher, QA-Prozesse und Fehlerberichts-Workflows zu definieren. Dies sollte dazu beitragen, dass es zu einer weniger persönlichen Interaktion zwischen Ihnen und Ihren Testern wird.
Nimm es niemals persönlich. Ich bekomme ständig Bugs, sowohl durch unser Bug-Tracking-System als auch durch persönliche Interaktionen. Unabhängig von ihrem Tonfall, antworte ich immer: "Danke, dass du das eingefangen hast, ich werde mich darum kümmern". Sie haben vielleicht einen schlechten Tag, vielleicht haben Sie einen schlechten Tag, wer weiß? Wenn sie nicht genügend Informationen zum Reproduzieren bereitstellen und diese Informationen nicht auf einer konsistenten Basis bereitstellen, siehe # 1 (erhalten Sie einen echten Workflow und bleiben Sie dabei).
Werkzeuge vergessen. Hier geht es um Kommunikation. Sie brauchen Leute, die die Disziplin haben, Ihnen genau zu sagen, was falsch ist, wie sie dort hingekommen sind und welche besonderen Bedingungen zu dem Ereignis geführt haben. Sie müssen auch in der Lage sein, Feedback zu geben, wenn Leute etwas schreiben wie "Es ist kaputt". Entwicklung und Qualitätssicherung müssen darüber sprechen, was von beiden Seiten benötigt wird.
Bezüglich der Empfindlichkeit habe ich festgestellt, dass diese Einstellung alles übertrumpft. Jedes Mal, wenn du einen Fehlerbericht siehst, musst du mit der Einstellung beginnen, dass "Dies ist kein persönlicher Angriff; es ist eine Gelegenheit, ein Problem zu lösen und etwas zu lernen." Ihre Antworten werden folgen.
Ich überlasse die Tool-Empfehlungen jemand anderem, denn das, was wir verwenden, ist nicht "frei wie im Bier".
Ihre erste Priorität muss die Fähigkeit sein, sich vom Prozess zu lösen. Dies kann kein persönliches Problem sein. Versucht, mit QA zu kommunizieren (entweder persönlich oder über den CoC), dass das Redigieren in den Fehlerberichten kontraproduktiv ist ("Dieser Prozess funktioniert noch nicht!", Wie du geschrieben hast, ist nicht hilfreich). Der Zweck des Prozesses besteht darin, die Qualität der endgültigen Ausgabe zu erhöhen. Solche Ausrufe fördern dieses Ziel nicht.
Als QA-Person, die im Grunde genommen ein Entwickler ist (automatisierte Regressionstests), glaube ich, dass ich beide Seiten dieses Problems sehen konnte.
Wie mehrere andere gesagt haben, ist dies ein Kommunikationsproblem, kein Tool wird es lösen. Tools wie bugzilla, verbessern die Effizienz der Kommunikation, aber Sie verlangen immer noch, dass beide Parteien daran arbeiten, die Kommunikationswege offen zu halten.
Ich habe gesehen, dass Entwickler oft Probleme damit haben, Bugs persönlich zu nehmen, was dazu führt, dass sie als "unwichtig", "Edge-Fälle", "wie beabsichtigt" usw. abgekratzt werden, wenn das Problem tatsächlich ein Problem ist . Auch wenn das Problem tatsächlich unwichtig ist, hilft einfach, Ihre Bewertung von Risiko / Nutzen bei der Behebung eines Fehlers zu teilen, um eine bessere Kommunikation zu fördern.
Umgekehrt lassen QA-Leute oft Details des Fehlers und Schritte, um es zu reproduzieren (ich selbst eingeschlossen). Wenn Sie als Entwickler auf fehlende Details stoßen, ist es Ihre Aufgabe, uns um weitere Details zu bitten (und bitte fragen Sie uns freundlich und umgehend). Das schlimmste Gefühl ist, wenn du einen Fehler schreibst und ihn an einen Entwickler schickst, und dann für ein paar Tage nichts mehr hörst, und er wird geschlossen als 'Kann nicht reproduziert werden'.
Am Ende ist der Schlüssel eine schnelle und freundliche Rückmeldung auf beiden Seiten . Wenn ich (in QA) mit einem Entwickler arbeite, der immer antwortet, wenn ich ihm einen Fehler übermittle und ich bin froh, dass ich helfen kann, das Problem zu lösen, bin ich viel eher bereit, mir die Zeit zu nehmen, ihm alle Details zu geben.
Genau wie Entwickler haben (oder sollten) die QS Mindeststandards einhalten. Wenn sie ein Problem melden, müssen sie Folgendes bereitstellen:
Wenn ich zur QA gehen und fragen muss, was das Problem ist oder wie es produziert wurde, werde ich genervt. "Das geht nicht" ist einfach nicht gut genug.
In einem von mir entwickelten System (einem Web-Reporting-System) habe ich alle Eingabedaten für jeden generierten Bericht generiert. Wenn die QA einen Bericht erstellte und ein Problem feststellte, konnte sie eine blinde URL aufrufen und eine ZIP-Datei mit folgendem Inhalt herunterladen:
Auf der Dev-Seite habe ich ein Tool geschrieben, das den Bericht nur basierend auf dieser ZIP-Datei erneut ausführen kann. Dies hatte mehrere Auswirkungen:
Der Effekt war tiefgreifend, und ich denke, dass dies ein Schlüsselproblem hervorhebt: Entwickler mögen es nicht, wenn Dinge schwer zu testen, schwer zu reproduzieren sind und so weiter. Ebenso mögen QA-Leute nichts, was ihre Arbeit schwieriger macht und sie mögen alles, was es einfacher macht.
Mein Rat für die harmonische Zusammenarbeit mit QA lautet also:
Ich hatte die absolut beste Erfahrung mit QA, wenn ich zusammenarbeite, um Bugs zu lösen und / oder zu analysieren. Weder Programmierer noch QS-Ingenieure sind die einfachsten Leute, mit denen man sich arrangieren kann, und es gibt einige grundlegende Spannungen zwischen diesen Gruppen.
Wenn ich Probleme mit Bugreports hatte, die gegen meinen Code eingereicht wurden, gehe zu ihnen und frage, was sie genau meinen, und / oder führe mich durch die Schritte, um sie zu reproduzieren. Die meiste Zeit waren die Probleme in einem Missverhältnis zwischen der Art, wie ich eine Anforderung gelesen hatte, und sie gingen davon aus, dass das funktionieren würde. Du sprichst wie Menschen, nicht nach einer Formel, und du findest es gemeinsam heraus (stimme zu, nicht zuzustimmen und jemanden anderen anrufen zu lassen ist hier eine Option).
Ein Bugreport, der in einem Bugtracker geposted oder archiviert wurde, kann sich in der Art, wie er formuliert wird, als beleidigend empfinden, und es wird mit Sicherheit so aussehen, als würde er mit dem Finger auf "dein Baby", deine Schöpfung, zeigen. Sprechen Sie mit der Person, die den Fehler einreicht, und Sie werden vielleicht ein gemeinsames Ziel bemerken: die Welt / Software ein wenig besser zu machen.
Meine Haltung gegenüber QA hat sich dadurch gelohnt, dass es zu einer Beziehung gegenseitigen Respekts wurde (obwohl keiner von uns das zugeben würde: P), anstatt "keinen Käfer" zu schreien, ging ich zuerst zu ihnen. Anstatt sofort zu behaupten, dass etwas ein Fehler ist, würden sie zuerst zu mir gehen. Am Ende machen wir alle unsere Arbeit. Es ist Programmierer, Software zu schreiben, und QA-Ingenieure, um Löcher in diese Software zu schießen. Und ich bin sehr dankbar, dass ich mit ein paar sehr aufgeweckten Leuten zusammengearbeitet habe, die mir gesagt haben, was ich falsch gemacht habe.
Oh, und niemals jemals verwende den Satz "Es ist kein Fehler, es ist ein Feature".
Ich stimme Paul Williams zu. Es scheint, dass der Prozess, den QA verwendet, um Probleme zu übermitteln, verbessert werden sollte. E-Mails und die verbale Kommunikation des Status des Problems lassen Raum für Verbesserungen. Ich stimme auch seinem Ratschlag zu, dass Entwicklung und Qualitätssicherung zusammenarbeiten, um den Prozess zu verbessern und zu kommunizieren. Ich bin ein QA-Ingenieur und mache das jetzt seit über 10 Jahren.
Sie klingen sehr reife und große Requisiten, weil Sie niemanden in die Luft gesprengt haben. Es ist in Ordnung, Wörter mit dem Effekt "Es ist immer noch gebrochen" zu schreiben, aber die QA-Person muss eindeutig mehr Fingerspitzengefühl lernen.
Ich stimme der Aussage von AnthonyWJones absolut nicht zu. Ich erkenne, dass jede Firma ihre eigene Kultur hat, aber die Art, wie er seine Antwort formulierte, legt nahe, dass eine "Wirf es über die Wand, QA ist verantwortlich für Qualität, nicht für mich". Mit dem ist nichts falsch, aber es hilft nicht, wenn Sie ein kooperatives und herzliches Umfeld fördern wollen. Eine gesündere Kultur ist eine, in der das gesamte Entwicklungsteam (einschließlich QS) die gleiche Verantwortung für die Qualität trägt.
Werkzeuge zur Entpersonalisierung scheinen mir die falsche Richtung zu sein.
"Meine Güte, das scheint wirklich so zu sein wichtiger Fehler, den wir beheben müssen. Vielen Dank um es zu finden, Alter.
Ich bin verwirrt wie man es reproduziert. Hast du irgendwelche Ideen? oder mehr Informationen? "
Wow, dieser Fehlerbericht, den du geschrieben hast, war wirklich großartig. Es hat mir viel Zeit gespart, den Fehler zu isolieren. Danke!
Willst du ein Bier trinken gehen? Bier, wie in frei?
usw.
Haben Sie sharepoint (oder ein Wiki, etc.) wo Sie arbeiten? Es wäre ziemlich einfach, ein Problemprotokoll für alle kostenlos zu erstellen. Ich werde mich nicht um die Auswahl von Tracking-Tools kümmern, da sind viele da draußen. Überprüfen Sie SourceForge oder Codeplex, wenn Sie frei haben möchten.
Das Wichtigste ist, dass du es auf keinen Fall persönlich nimmst - sie machen ihren Job genauso wie du. Das Festlegen eines Formats für "akzeptable" Fehlerberichte würde auch bei der E-Mail, die Sie gerade verwenden, hilfreich sein.
Sie sollten mindestens enthalten:
Jede anständige QA-Person sollte dies bereits tun und ein Skript testen.
Versuchen Sie, sie stärker in die Projektprozesse einzubeziehen. Wir haben regelmäßige Retrospektiven, in denen QS-Mitarbeiter gleichberechtigt mit Entwicklern gesprochen werden. Sie schlagen häufig Wege vor, wie wir Prozesse verbessern können, die ihre Arbeit erleichtern und ihnen die Qualitätssicherung erleichtern. Und noch wichtiger: Diese Vorschläge werden diskutiert und (falls vereinbart) angenommen. Dies macht QA und dev Teil des gleichen Prozesses und nicht in Opposition.
Es ist auch wichtig, dass Entwickler die Verantwortung für ihren Code übernehmen. Wenn QA viele Bugs in einem Bereich findet, dann liegt es daran, dass der Entwickler einen schlechten Job gemacht hat, es zu schreiben. Es ist nicht, weil QA schwierig sind. Das Entwicklerteam sollte das alles erkennen.
Ich denke nicht, dass Tools Ihnen sehr helfen können.
Bitten Sie QAs, Schritte zu schreiben, um das Problem zu reproduzieren, vorzugsweise beginnend mit
Dies wird ihre Gedanken strukturieren und Ihnen helfen zu verstehen, was QA sagen wollen.
Der beste Weg, mit solchen Aussagen umzugehen, wie "es funktioniert nicht", ist die Verwendung einer ähnlich knappen Frage als Antwort. "Danke, könntest du mir helfen, indem du mehr darüber erzählst, was du gefunden hast?" Dann lassen Sie den Ball in ihrem Gericht.
Wenn es eine Beschwerde gibt, die Sie nicht beantwortet haben, können Sie auf Ihre Anfrage für weitere Informationen verweisen. Tun Sie nicht jemand Arbeit, es ist die Aufgabe der QA zu definieren, was speziell nicht die Qualität sie sind verantwortlich für die Sicherung erfüllen.
Tags und Links qa issue-tracking