Sollten Entwickler an Testphasen beteiligt sein?

Wir verwenden einen klassischen V-förmigen Entwicklungsprozess. Wir haben dann Anforderungen, Architektur, Design, Implementierung, Integrationstests, Systemtests und Akzeptanz.
Tester bereiten in den ersten Phasen des Projekts Testfälle vor. Das Problem ist, dass die Testphasen aufgrund von Ressourcenproblemen (*) zu lang sind und aus zeitlichen Gründen häufig verkürzt werden (Sie kennen Projektmanager ...;)). Entwickler machen ihre Unit-Tests so, wie sie sollten.

Meine Frage ist also einfach: Sollten Entwickler in die Testphasen involviert sein und ist es nicht zu "gefährlich"? Ich fürchte, es wird den Projektmanagern ein falsches Gefühl von besserer Qualität geben, da die Arbeit erledigt wurde, aber wären die zusätzlichen Manntage von Wert? Ich bin nicht wirklich zuversichtlich, dass Entwickler Tests durchführen (keine Beleidigung hier, aber wir alle wissen, dass es ziemlich schwierig ist, ein paar Klicks zu brechen, was Sie in mehreren Tagen gemacht haben).

Vielen Dank für Ihre Meinung.

(*) Aus unbekannten Gründen ist eine Erhöhung der Anzahl der Tester bis heute keine Option.

(Nur im Voraus, es ist kein Duplikat von Sollten Programmierer Testern beim Entwerfen von Tests helfen? Hier geht es um die Testvorbereitung und nicht um die Testausführung, bei der die Auswirkungen von Entwicklern vermieden werden.)

Ihre Frage sehr wörtlich betrachten ("involviert in") Meine einzige Antwort ist eine absolut eindeutige

JA

Entwickler sollten niemals das letzte Wort über ihren eigenen Code haben.

Entwickler sollten jedoch daran beteiligt sein, die Arbeit anderer Entwickler zu testen. Es macht zwei Dinge:

1. Es bringt den Einblick eines Entwicklers in das Testen. Dies ist sowohl auf den allgemeinen Fall zurückzuführen, dass nur bekannt ist, welche APIs zu einem bestimmten Zeitpunkt wahrscheinlich verwendet werden, welche Ausnahmen von diesen APIs ausgehen können und wie sie behandelt werden sollten. Es hilft auch bei einem bestimmten Projekt, da die Entwickler den verschiedenen Diskussionen darüber, warum etwas getan wird, viel mehr ausgesetzt sind als normalerweise bei der Qualitätssicherung, was bedeutet, dass sie möglicherweise Randfälle erkennen, die bei der Qualitätssicherung nicht auftreten würden. Von einem Entwickler entdeckte Fehler sind wahrscheinlich auch billiger zu beheben, da ein Entwickler normalerweise mehr Informationen und viel mehr Einblicke in die sofortige Behebung bietet.
2. Es gibt dem Entwickler die Exposition gegenüber Teilen der Anwendung, denen er sonst möglicherweise nicht ausgesetzt ist. Dies wird sie auf lange Sicht zu besseren Entwicklern für diese App machen. Wenn ich weiß, wie meine API verwendet wird, kann ich das nächste, was ich tun sollte, viel besser vorhersehen, als wenn ich nur von einer Spezifikation abfahre. Am wichtigsten ist, dass ich feststellen kann, wann die Spezifikation falsch ist, bevor ich mit dem Codieren beginne, wenn ich die Anwendung und ihre Verwendung kenne.

Warum würden Sie nicht so viele Augen wie möglich benutzen? Sie können es sich selten leisten, den Einstellungsprozess und den Einstiegsprozess zu durchlaufen, um zusätzliche QS-Mitarbeiter für die Crunch-Zeit an Bord zu holen. Wo finden Sie die zusätzlichen Augen, die Sie benötigen? Oder versuchen Sie, die Crunch-Zeit mit der gleichen Anzahl von QS zu überstehen, die Sie die ganze Zeit hatten? Selbst wenn die Entwickler 20% ihrer Zeit damit verbringen, Tests durchzuführen und 80% der aufgetretenen Fehler zu beheben, hat die App immer noch mehr Augen als zuvor. Automatisierte Tests geben Ihnen nur ein gewisses Maß an Sicherheit und werden niemals 100% betragen.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

Für alles andere als Unit-Tests absolut nicht. Entwickler wissen einfach zu viel über die App und wie sie funktionieren soll, um objektive Tester zu sein.

Der grundlegende Unterschied in der Testphilosophie zwischen Entwicklern und Qs besteht darin, dass der Programmierer normalerweise sein Programm testet, um zu beweisen, dass sein Code funktioniert ("positive" Tests). QA kann und tut dies, konzentriert sich aber zusätzlich darauf, herauszufinden, was nicht funktioniert, indem versucht wird, die Software zu beschädigen (mithilfe von "negativen" Tests).

In dem Maße, in dem das QS-Personal möglicherweise durch die Programmierertests beschädigt wird, die "beweisen", dass die Software funktioniert, sollte zwischen den Entwicklertests und den QS-Tests eine Isolation bestehen . Der Entwickler kann den QS-Tests sicherlich weiterhelfen, indem er demonstriert, was funktioniert. Es liegt jedoch an der QS, unabhängig zu überprüfen, ob die Software nicht kaputt geht.

Das Beste, was der Programmierer tun kann, um den Testaufwand zu unterstützen, ist die Bereitstellung einer umfassenden, qualitativ hochwertigen und überprüfbaren Einheitentestsuite, die Tests enthält, die den individuellen Anforderungen im Anforderungsdokument entsprechen.

Nun, in Bezug auf Tests gibt es 3 Arten.

Black Box, graue Box und weiße Box.

Black Box bezieht sich auf Benutzer, die das Produkt testen, ohne zu wissen, wie das Produkt intern funktioniert.

Gray Box bezieht sich auf Power-User, die Kenntnisse in Computerprogrammierung haben, aber nicht im Entwicklungsteam sind. Diese Personen testen, ob das Produkt Speicherlecks, Probleme mit den Systemanforderungen usw. aufweist.

Hier ist der Hauptteil: White Box bezieht sich auf Entwickler, die das Produkt auf Codeebene testen. Dies bedeutet zu sagen, dass sie Unit-Tests, Debugging, ... usw. durchführen.

Daher ist es gut, dass Benutzer und Entwicklungsteam alle in die Testphase involviert sind. Für jeden Test ist jedoch ein angemessenes Engagement von Benutzern und Entwicklungsteam erforderlich, je nachdem, was getestet wird.

UNIT TESTING ist ein Muss für alle Entwickler

Informationen darüber, wie dies zu Ihrem Vorteil genutzt werden kann, finden Sie unter den folgenden Links, wenn Sie sich für die C ++ - Entwicklung interessieren:

• Eine kurze Einführung in das Google C ++ Testing Framework
• Open Source C / C ++ - Unit-Test-Tools, Teil 1: Lernen Sie das Boost-Unit-Test-Framework kennen
• Open Source C / C ++ - Unit-Test-Tools, Teil 3: Lernen Sie CppTest kennen

Es gibt keine Möglichkeit, wie eine QA-Person diese Tests durchführen kann. AUF KEINEN FALL.

Unter der Annahme, dass das Projekt eine erhebliche Anzahl von Entwicklern hat, müssen die Entwickler auf jeden Fall an Tests arbeiten. Eine Einschränkung wäre, dass Entwickler nicht daran arbeiten, ihren eigenen Code zu testen (dies schließt Unit-Tests nicht ein).

Ich würde eher sehen, wie Verwaltungsmitarbeiter (oder potenzielle Benutzer) die QS-Tests durchführen als Entwickler. Jemand, der nicht weiß, wie das Produkt funktioniert, muss versuchen, es zu verwenden. Entwickler sind in der Regel sehr eingeschränkt in der Art und Weise, wie sie sich dem Testen nähern, und ehrlich gesagt sind sie zu teuer pro Stunde, um sie auch für QS-Tests zu verwenden.

Du schreibst:

Das Problem ist, dass die Testphasen aufgrund von Ressourcenproblemen (*) zu lang sind und aus Zeitgründen häufig verkürzt werden. Dies liegt daran, dass Entwickler sie nicht ausführen. Eines der größten Internetunternehmen, das die besten und stabilsten Produkte liefert, verwendet überhaupt keine Tester. Sie verwenden nur automatische Tests, die alle von den Entwicklern selbst durchgeführt werden. Die Ergebnisse sind x10 bessere Produkte als wenn der Entwickler das Testen "Testern" überlässt.

Es ist so, als würden Bauarbeiter Ihr Haus bauen, aber ein anderes Team muss sicherstellen, dass das Gebäude tatsächlich steht, die Türen sich öffnen und schließen, die Klimaanlage funktioniert usw. Es wird wahrscheinlich x10 dauern, um Gebäude zu bauen, und die meisten werden am Ende enden unzuverlässig sein.