Sollten Programmierer Testern beim Entwerfen von Tests helfen?

Inwiefern sollten Programmierer Testern bei der Entwicklung von Tests helfen?

Ich denke nicht, dass sie überhaupt helfen sollten. Ich mache mir Sorgen, dass, wenn sie Testern beim Entwerfen von Tests für ihren eigenen Code helfen, sie die Tester mit ihren eigenen Vorurteilen und blinden Flecken in Bezug auf diesen Code "infizieren".

Ich bin der Meinung, dass die Anforderungen ausreichen sollten, um die Informationen bereitzustellen, die Tester für die Erstellung ihrer Tests benötigen. Wenn es einen Teil der Implementierung gibt, den die Programmierer als bedenklich empfinden, dann denke ich, ist es ihre Pflicht, Komponententests durchzuführen, um diesen Teil zu testen, oder sogar ihre eigenen informellen Systemtests durchzuführen, um diesen Teil zu testen.

Allerdings sind nicht alle, die ich kenne, damit einverstanden (und ich verstehe einige ihrer Punkte bis zu einem gewissen Grad). Was denken andere darüber? Wird das irgendwo in der Literatur diskutiert?

Genau. Programmierer können den Testern helfen, die Funktionsspezifikationen zu verstehen, Ressourcen für die Forschung zu finden, sollten jedoch die Gedanken der Tester nicht mit ihren eigenen Vorstellungen über die Vorgehensweise beim Testen belasten.

Ich denke, es gibt Raum für Entwickler und Tester, um im Bereich der Qualitätssicherung friedlich zusammen zu leben. :)

Ich denke, die Entwickler sollten für die erste Teststufe - Unit-Tests und grundlegende Integrationstests - verantwortlich sein, um sicherzustellen, dass ihre Produkte in den meisten Fällen funktionieren, bevor sie sie an die Tester weitergeben.

Es liegt an den Testern, Akzeptanztests auf der Grundlage von Anforderungen zu erstellen, die keinerlei Implementierungsdetails unterliegen (dies wird normalerweise als "Black-Box-Test" bezeichnet). Wenn Tester und Entwickler die Anforderungen nicht genau verstehen, sollte dieses Problem entweder vom Projektmanager (falls vorhanden) behoben werden oder es muss sichergestellt werden, dass sich in der Entwurfsphase des Features alle auf derselben Seite befinden.

Ich denke, sowohl das Testen als auch die Entwicklung sind gemeinsame Anstrengungen. Daher sollten Entwickler (IMO) Testideen an Tester weitergeben. Ich denke nicht, dass es sie ansteckt oder Tester überhaupt befleckt. Der Tester sollte diese Tests natürlich um viele andere Testansätze erweitern.

Ich bin auch ein großer Fan von Testern, die Entwicklern helfen. Ich habe viele Male in meiner Karriere mit Entwicklern über Ideen für das Design nachgedacht und sie zusammengebracht, um Fehler zu beheben (und auf die Fehler und vorgeschlagenen Korrekturen aufmerksam zu machen). Ich habe jemals einen Entwickler mit Tester-Cooties beschmutzt.

Wenn Sie es nicht als eine gemeinsame Anstrengung ansehen, wird der Code von Entwickler zu Test einfach "über die Wand geworfen" ... und Sie erhalten eine geringere Qualität. Das ist die Wahrheit in meiner Welt, aber (natürlich), ymmv.

So wie ich das sehe, ist es nicht die Aufgabe von QA, meinen Code zu testen. Der Tester muss sicherstellen, dass mein Code alle Anforderungen für diese Aufgabe erfüllt.

Wenn ich etwas an die Qualitätssicherung übergebe, stelle ich sicher, dass sie die von mir ausgeführte Aufgabe kennen und nicht die Einzelheiten meines Codes. Ich gebe niemals irgendetwas an die Qualitätssicherung weiter, das 'Bone Head'-Bugs enthält. Das verschwendet meine Zeit, ihre Zeit ... und so ziemlich jedermanns Zeit.

Bei meinem letzten Job war die Qualitätssicherung von Anfang an dabei. Dies war auch in den Sitzungen zur Anforderungserfassung, den Projektbesprechungen und den Designtreffen der Fall. Sie hörten zu und stellten Fragen und während die Entwickler Code schrieben, schrieben sie ihre Testpläne. Es hat super geklappt und wir haben eine Menge Probleme aufgegriffen, die wahrscheinlich durchgeglitten wären.

Ich denke, Sie sind hier ziemlich falsch. Ich war Tester und Entwickler und habe als Tester stark von der Anleitung der Entwickler in Bereichen profitiert, die sie als risikoreich oder fragil erachteten. Als Entwickler möchte ich, dass Tester die Probleme finden, die ich nicht gründlich untersucht habe.

Es gab keine "Verschmutzung", es sei denn, Ihr Code ist Rohabwasser, und das wäre aus einem ganz anderen Grund.

Anforderungen machen eine schreckliche Arbeit bei der Kommunikation der technischen Probleme, die ein QS-Experte interessieren würde, weil sie bestenfalls aufzeigen, was Business-Analysten geschafft haben, zu erfassen. Gute Entwickler werden sich bewusst sein, dass ihr Code auf dem "glücklichen Weg" optimiert ist, und wollen wissen, was sie unberücksichtigt gelassen haben. Sie werden zumindest eine Vorstellung davon haben, was schief gehen könnte und welche Bereiche von der Qualitätssicherung untersucht werden sollen. Sie wissen aufgrund ihres Designs auch, wie groß das Risiko für ein bestimmtes Merkmal ist.

Als Tester, der nicht vom Entwicklerteam angeleitet wurde, habe ich manchmal einen falschen Ansatz gewählt, bei dem gute Fehlerberichte erstellt wurden, die risikoreichen Codepfade und größeren Probleme, die durch eine bessere Zusammenarbeit hätten vermieden werden können, jedoch nicht vollständig ausgenutzt wurden mit dem Entwicklungsteam an Kunden ausgeliefert.

Ein Tester sollte sich sicherlich nicht darauf beschränken, nur das zu testen, was der Entwickler für wichtig hält. Er wird jedoch nicht geschädigt, wenn er erfährt, welche Bedenken die Entwickler hinsichtlich des Codes haben. Manchmal können sie ihren Ansatz basierend auf ihrem Wissen über die Implementierung optimieren. Nur wenn ein Tester besonders kurzsichtig ist, wird er die Meinung des Entwicklers über die Risiken als letztes Wort betrachten. Sie werden Dinge, die der Entwickler als risikoarm identifiziert, nicht vollständig ausschließen, aber sie werden mehr Aufwand in Dinge investieren, die eine größere Auswirkung auf die Kunden haben könnten.

Das QA-Team sieht wahrscheinlich Bereiche mit einem größeren kombinatorischen Testumfang als die Anforderungssammler oder -entwickler eines Systems, kennt jedoch möglicherweise keine Komponenten des Systems, die eine subtilere Art von Fragilität aufweisen, die von der Kenntnis des Designs profitiert oder Implementierung des Systems.

Nach meiner Erfahrung führt die Zusammenarbeit zwischen Qualitätssicherung und Entwicklung zu qualitativ besseren Produkten. Ich würde niemals empfehlen, nur eine Black-Box-Übergabe durchzuführen.

Als Tester habe ich überhaupt keine Einwände gegen Programmierer, die Testfälle vorschlagen (obwohl dies nicht bedeutet, dass ich mich nur an diese Testfälle halte) oder Implementierungsdetails beschreiben. Manchmal kann es sehr hilfreich sein, jemanden sagen zu lassen: "Ich denke, dieses Bit könnte riskant sein. Ich würde es wirklich begrüßen, wenn Sie dieses Bit gründlich testen würden." Wenn ich einige Implementierungsdetails kenne, kann ich auf jahrelange Erfahrung zurückgreifen, um die Tests auszuwählen, die meiner Meinung nach am wahrscheinlichsten fehlschlagen. Manchmal bedeutet nur eine kurze Erwähnung, dass ein paar Tests plötzlich meine Prioritätenliste vergrößern.

Beschmutzt es mich? Ich bin ein bisschen gekitzelt von der Idee, dass Programmierer ritterlich danach streben, meine Testerreinheit zu bewahren, aber wirklich - nein, das ist ein Mythos. Mehr Informationen lösen für mich in der Regel noch mehr Fragen aus, nicht weniger. Ich denke, es ist eine Denksache - ich finde keine Bugs, weil ich unwissend bin, ich finde Probleme, weil ich ein skeptischer, nicht vertrauenswürdiger Typ bin, der einfach zu verdammt stur ist, um alles auf Vertrauen zu setzen. Bei jedem System, das ich getestet habe, habe ich festgestellt, dass ich umso mehr Probleme und "interessantere" finde, je tiefer ich es verstehe.

Ich überprüfe gerne die Testpläne und schlage zusätzliche Testfälle vor, an die die Qualitätssicherung möglicherweise nicht gedacht hat. Ich bin mir nicht sicher, wie das "die Tester mit meinen eigenen Vorurteilen infizieren würde".

Ich befand mich in der seltsamen Situation, dass ich später Testfälle in Selenium implementieren und schreiben musste, da wir nur wenig QA-Mitarbeiter haben. Ich glaube, eine testgetriebene Entwicklung wäre sehr hilfreich, aber sie ist in meinem Shop noch nicht angepasst.

Eine Sache, die ich beim Schreiben von Tests hilfreich finde, ist, dass ich beim Schreiben von Tests Fehler finde. Ich denke in einer anderen Perspektive, um mir zu helfen, robusteren Code zu schreiben. Es ist jedoch richtig, dass die Testabdeckung begrenzt sein könnte. In diesem Fall können QAs uns immer mitteilen, was sie abgedeckt werden möchten. Oder wir können passiv weitere Tests hinzufügen, wenn Fehler auftreten.

Ich führe QA durch und im Gegensatz zu den meisten Domänen ist es weitaus schwieriger, unseren Code zu verwenden, als Programmierkenntnisse zu erlernen. Wir zählen daher darauf, dass die Entwickler uns Testfälle für ihre brandneuen Whizzbang-Funktionen geben, da wir nicht wissen, wie das geht. In jedem Fall sind die QA-Probleme eher das Auffinden von Rückschritten und Dingen, die kaputt gehen, als das ursprüngliche Testen neuer Funktionen. In jedem Fall, wenn das Ergebnis eine komplexe Berechnung ist, ist es schwierig zu wissen, was eine korrekte und was eine falsche Antwort ist, oder selbst wenn eine abnormale Beendigung eine gute oder schlechte Sache ist.

Auf jeden Fall weiß ein Entwickler, wenn er ehrlich ist, wahrscheinlich etwas über die Schwachstellen seines Babys. Er weiß wahrscheinlich, bei welchen Parameterwerten er verschiedene Algorithmen oder Domänen in einer Tabellensuche auswählen muss oder was auch immer. Wenn er ernsthafte Tests ernst nimmt, sollte er in der Lage sein, eine Reihe von Tests in angemessener Größe zu generieren, die einen Großteil des Codes abdecken.