Heute feiert die Welt den Tag des Testers. Bei dieser Gelegenheit haben wir uns entschlossen, Ihnen dabei zu helfen, die Arbeit dieser Spezialisten aus verschiedenen Blickwinkeln zu betrachten, damit die Zusammenarbeit allen Teilnehmern maximalen Nutzen und minimalen Stress bringt.
Fotokredit: David Goehring CC BY
1. "Nochmals überprüfen, es gibt definitiv keinen Fehler"
Beginnen wir mit dem grundlegenden Problem. Das Ars Technica-Forum hat einen alten Thread, in dem ein Entwickler über den tiefen Hass auf „pedantische“ Tester spricht. Er ist furchtbar verärgert, dass einige Testexperten stundenlang nach den kleinsten Fehlern suchen. Und was am unangenehmsten ist, finden sie immer noch.
Was schief gehen könnte : Nicht jeder ist bereit, seine Fehler zuzugeben. Jemand beginnt ein altes Lied über „kein Fehler, sondern eine Funktion“, um zu beweisen, dass alles beabsichtigt war. Andere bitten beharrlich darum, den Code noch einmal zu überprüfen und sicherzustellen, dass kein Fehler vorliegt. Der Tester versucht nur, seine Arbeit gut zu machen, und statt Dankbarkeit wird er zur erneuten Prüfung geschickt.
Wie man ist : Es ist ganz einfach: Wenn der Tester einen Fehler in Ihrem Code gefunden hat und Sie verstehen, dass er Recht hat, ist es besser, diese Tatsache zuzugeben. Sie beide haben ein und dasselbe Ziel - ein debuggtes und funktionierendes Produkt herauszubringen. Humor hilft, sich in dieser Frage zu verständigen. Hier ist ein Artikel, in dem Tester einen „goldenen Fundus“ von Aussagen von Entwicklern zusammenstellen, die versuchen, ihren Code zu schützen. Wir empfehlen Ihnen, sie durchzugehen und sich vorzustellen, wie diese "klassischen" Sätze aus Sicht des Testers klingen.
2. „Eine Woche vor der Veröffentlichung. Ich hoffe, du hast für die nächsten zwei Tage keine anderen Dinge geplant. "
Manchmal kommt der Code einige Tage vor der Veröffentlichung zu den Testern. Dann müssen sie in Eile arbeiten. Einige QS-Experten glauben, dass Kollegen ihre Arbeit einfach unterschätzen. Angeblich denken sie, dass das Auffinden von Fehlern einfach und schnell ist, und haben das Debuggen im letzten Moment verschoben.
Was kann schief gehen : Im Notfall ärgern sich Tester nicht nur, sondern verlieren auch ihre Wachsamkeit. Zeitmangel ist einer der Hauptgründe, warum Tester Fehler überspringen.
Wie man ist : Es gibt verschiedene Entwicklungsmodelle. Aus Sicht der Qualitätssicherung gibt es zwei Hauptansätze: Kaskadierung und Agilität. Im ersten Fall erhalten Tester schrittweise Codefragmente. Im zweiten Fall testen sie den Code parallel zum Schreiben.
Agile hilft dabei, QS-Experten frühzeitig in das Projekt einzubeziehen. Dank dessen müssen Sie nicht "eine Stunde vor der Veröffentlichung" testen. Darüber hinaus können mit diesem Ansatz keine Fehler gefunden, sondern deren Auftreten verhindert werden. Wenn Ihre Tester über konstanten Zeitdruck klagen und Fehler verpassen, sehen Sie sich diese Methode an.
Foto: Tim Regan CC BY
3. „Ich habe den Code schnell optimiert. Schau bitte. "
Angenommen, Ihr Team arbeitet an einem Kaskadenmodell und weiß, wie Entwicklungsphasen richtig geplant werden. Tester erhalten den Code, und es scheint genügend Zeit für das Debuggen zu geben. Entwickler haben jedoch die Angewohnheit, in dieser Phase ein Minimum an Aufwand zu betreiben. Sie erhalten einen detaillierten Fehlerbericht, lesen ihn oberflächlich, beseitigen offensichtliche Fehler schnell und senden den Code an den nächsten Testzyklus.
Was möglicherweise schief geht : Das Problem ist, dass der Code nach oberflächlichen Änderungen häufig mit noch mehr Fehlern zurückgegeben wird. Der Tester verbrachte einige Zeit damit, einen detaillierten Bericht zu erstellen, und erhielt daraufhin eine Antwort. Er muss diesen Weg noch mehrmals gehen, nur weil der Entwickler keine Zeit mit „kleinen Fehlern“ verbringen möchte.
Wie man ist : Offensichtlich nicht eilen. Das reicht aber nicht. Sie müssen herausfinden, warum Sie dem Bericht nicht die gebührende Aufmerksamkeit schenken. Wenn dies banale Faulheit ist, können nur Sie sich selbst helfen. Es gibt andere Gründe. Sie glauben beispielsweise, dass QS-Ingenieure Sie mit Berichten über unbedeutende Fehler überfluten. Dann müssen Sie dieses Problem auf Führungsebene klären - sollten Tester Sie "im Detail" ablenken. Höchstwahrscheinlich lautet die Antwort ja. Einige Produktmanager fordern Entwickler sogar auf, dem Code gezielt kleinere Fehler hinzuzufügen, damit die Tester immer auf der Hut sind. Es ist wichtig, diesen Ansatz zu wählen und Fehlerberichte mit der gebotenen Aufmerksamkeit zu behandeln.
4. „Es scheint, dass ich mich bereits mit diesem Fehler befasst habe. Aber ich erinnere mich nicht genau. "
Manchmal ist ein oberflächlicher Ansatz ein systemisches Problem. In einigen Teams gehen Fehlerberichte zeitlich und räumlich verloren. Niemand reagiert ordnungsgemäß auf Berichte und zeigt nicht an, ob das Problem behoben wurde oder sich noch in der Schwebe befindet.
Was könnte schief gehen : Entwickler beheben einen Fehler, nehmen ihrer Meinung nach „geringfügige“ Änderungen am Code vor, vergessen, die Tester darüber zu benachrichtigen, und senden den Code an die Version. Infolgedessen tritt das Problem auf, wenn es zu spät ist. Und der Tester ist oft der „extreme“.
Wie man ist : Das Chaos-Problem muss systematisch gelöst werden. Das Durcheinander schadet der Entwicklung, daher müssen Sie den Kommunikationsprozess in einem Team vollständig umstrukturieren. Hier lohnt es sich, die grundlegenden Tipps zum Aufbau der Kommunikation zwischen Entwicklern und QS-Ingenieuren zu verwenden: um die Terminologie zu bestimmen; Anforderungen klar formulieren; Einführung einer Prioritätshierarchie für verschiedene Fehler. In Bezug auf die Verwechslung mit Fehlern gibt es gute praktische Tipps: a) Lassen Sie Fehler alles melden; b) dann ist es wichtig, sie zu priorisieren; c) Jeder geschlossene Fehler impliziert, dass ein Funktionstest geschrieben wird. d) Der Status "gelöst" wird nicht vom Entwickler, sondern vom Tester vergeben. Dieser Ansatz stellt sicher, dass das Problem wirklich gelöst wird.
Foto: Tim Regan CC BY
5. „Warum sollte ich das testen? Ich bin kein Tester! "
In einigen Teams liegt die Verantwortung für das Debuggen vollständig bei den Testern. Entwickler machen sich nicht die Mühe, Zeit mit den offensichtlichsten Unit-Tests zu verschwenden. Sie sind sich sicher, dass dies nicht ihre Aufgabe ist. Im Großen und Ganzen ist dies der Fall, obwohl es zu diesem Thema unterschiedliche Standpunkte gibt (die Ansichten der Community finden Sie hier ).
Was schief gehen könnte : Tester in dieser Situation müssen sich mit allen Mängeln hintereinander auseinandersetzen - selbst mit den primitivsten und dümmsten Fehlern. Das ist natürlich ärgerlich.
Wie man ist : Viele Entwickler bevorzugen unabhängige Tests, bevor sie an die QS-Abteilung gesendet werden. Dies hilft nicht nur, Tester zu entlasten, sondern auch zu lernen, das Produkt aus der Sicht des Kritikers und des Benutzers zu betrachten. Es wird angenommen, dass dies für Profis nützlich ist und den besten Effekt auf das Endergebnis hat. Für diejenigen, die sich nicht mit Schecks beschäftigen wollen, gibt es automatische Werkzeuge. Sie helfen dabei, die offensichtlichsten Fehler zu finden. Selbst wenn das Team QS-Ingenieure hat, ist eine strikte Trennung zwischen Entwicklern und QA nicht der beste Ansatz.
6. „Igor, heute arbeitest du zusammen mit Oleg. Es wird dir gefallen"
Produktmanager sind nicht auf den Kaskadenansatz und Agile beschränkt. Einige von ihnen experimentieren gerne. Vereinbaren Sie beispielsweise Paarprogrammierungs- und Testsitzungen.
Was möglicherweise schief geht : Dies ist ein effektiver Weg, um Fehler zu erkennen, hat aber auch Nachteile - die Menschen sind möglicherweise nicht begeistert von Innovationen. Ein QS-Spezialist, der es gewohnt ist, alleine, auf einer anderen Etage und an seiner Ausrüstung zu arbeiten, kann es einfach unangenehm sein, die vertraute Umgebung zu verlassen. Darüber hinaus kann er mit der Erfahrung und dem Wissen eines Partners nicht banal sein. Infolgedessen erhalten Produktmanager anstelle von produktiven Tests zwei unzufriedene Mitarbeiter.
Wie man ist : Der Hauptratschlag ist, sich nicht die Schulter abzuhacken. Agile und DevOps-Praktiken mögen attraktiv erscheinen, aber ohne angemessene Vorbereitung funktionieren sie nicht.
7. "Ich werde Ihr Gerät für Tests nehmen, macht es Ihnen etwas aus?"
Der Entwickler hat Zeit, mit dem Debuggen zu beginnen. Er bittet den Tester „buchstäblich für 20 Minuten“ um ein Testgerät und lässt es für lange Stunden.
Was möglicherweise schief geht : Meistens bringt der Entwickler das Gerät überhaupt nicht an seinen Platz zurück, und wenn dies der Fall ist, wird es vollständig entladen. In Anbetracht der Tatsache, dass Tester parallele Aufgaben auf diesem Gerät ausführen können, kann dies nur ärgerlich sein.
Wie man ist : Erinnern Sie sich, kleben Sie Aufkleber, tun Sie alles, aber bitte bringen Sie die Sachen der Tester pünktlich an ihren Platz zurück.
Foto: Dave Allen CC BY
Und der wichtigste Rat an Entwickler und Produktmanager, der sich aus allen vorherigen herausstellt: Respektieren Sie die Arbeit und Zeit anderer und setzen Sie sich so oft wie möglich an die Stelle eines Testers. Wenn er nicht gewesen wäre, hätte die ganze Welt von Ihren Fehlern gewusst.