Teilen von Entwicklungstestfällen (Einheiten- und Entwicklungsintegration) mit dem QS-Team (Testteam)?

Das Testteam (in einigen Organisationen das sogenannte QA-Team) besteht darauf, dass das Entwicklungsteam die Testfälle (des Entwicklungsteams) mit ihnen teilt. Ihre Argumente sind, dass die Entwicklungstestfälle der Ausgangspunkt für die QS-Tests sind.

Als Mitglied des Entwicklungsteams verstehe ich die Anfrage nicht. Für mich sollte der Tester die Lösung anhand der Anforderungen testen. Ich weiß nicht, ob das Testteam mit dem detaillierten Designdokument (Low-Level-Design) geteilt werden soll. Wir teilen ihnen jedoch das detaillierte Design mit.

Ich habe hier einige Beiträge gelesen, die besagen, dass das QA-Team seine Testfälle mit dem Entwicklungsteam teilen sollte, um eine bessere Lösung und einen besseren Durchsatz zu erzielen. Aber nichts von dem Entwicklungsteam, das seine Testfälle mit dem QS-Testteam teilt.

Es sieht so aus, als ob mein QS-Team sehr glücklich ist, wenn ich meine Entwicklungsfall- und Integrationstestfälle sowie die Testergebnisse teile.

Wenn Ihr Entwicklerteam und Ihr QA-Team nicht miteinander sprechen, besteht das gewisse Risiko, dass einige Tests unnötig zweimal durchgeführt werden und andere vergessen werden. Ein Worst-Case-Szenario ist, wenn Ihr Entwicklerteam einige nette automatische Integrationstests implementiert hat, die in wenigen Minuten oder Stunden ausgeführt werden, und Ihre QS-Mitarbeiter dieselben Dinge manuell testen und Tage oder Wochen für diese Aufgabe aufwenden. Ein anderes schlechtes Szenario ist, wenn beide Gruppen glauben, dass die andere Gruppe für irgendeine Art von Tests verantwortlich ist, und diese Tests daher weggelassen werden.

Unter der Annahme, dass beide Gruppen als Team und nicht gegeneinander arbeiten, ist es sinnvoll, sich gegenseitig detailliert darüber zu informieren, welche Tests von welcher Gruppe durchgeführt werden, und die beiden Gruppen ihre Aktivitäten koordinieren zu lassen.

Das Testteam (in einigen Organisationen das sogenannte QA-Team) besteht darauf, dass das Entwicklerteam seine Testfälle (des Entwicklerteams) mit ihnen teilt.

Sicher, die Qualitätssicherung sollte ein allgemeines Verständnis dafür haben, was von Unit- / Integrationstests abgedeckt wird und was nicht.

Ihre Argumente sind, dass Dev-Testfälle der Ausgangspunkt für die QS-Tests sind.

... auch wenn ihre Argumentation fehlerhaft ist. Das Mantra Nr. 1 einer QS-Person ist , den Entwicklern nicht zu vertrauen . "Mach dir keine Sorgen! Ich habe das gründlich überprüft!" ist der erste Schritt in Richtung eines riesigen Produktionsproblems.

Wie Doc Brown sagt, ist es nicht gut, eine ganze Menge QS-Zeit für etwas aufzuwenden, das durch automatisierte Tests gut abgedeckt wird. Aber es ist tollkühn, keine Zeit mit etwas zu verbringen , das durch automatisierte Tests gut abgedeckt wird. Und es ist verschwenderisch, eine ganze Menge Zeit damit zu verbringen, Ihre Komponententests detailliert zu dokumentieren, wenn die Qualitätssicherung ihnen sowieso nicht wirklich vertrauen sollte (und weil diese Dokumentationsstufe Ihre Entwickler dazu veranlasst, weniger / schlechte Komponententests durchzuführen).

In einer modernen Softwarearchitektur besteht die Absicht darin, dass die Tests nicht nur den Code testen, sondern dies auch auf eine Weise, die ihre Funktionalität dokumentiert.

Diese Dokumentation dessen , was der Code tut (zusätzlich zu dem, was es ist beabsichtigt , in den Spezifikationen zu tun) ist nützlich für QA'ers um besser auf die Absicht des Codes zu verstehen und auch , ob es den Anforderungen entspricht. Es ist auch eine nützliche Information, wenn QA-Mitarbeiter Testfälle schreiben, und es gibt ihnen einen Eindruck davon, was theoretisch bereits getestet wird. Einige der getesteten Bereiche könnten von zusätzlichen Fällen profitieren, andere könnten möglicherweise überhaupt keine Tests haben.

Die tatsächlichen Details dieser Exposition hängen stark von der organisatorischen Zusammensetzung und insbesondere von der technischen Tiefe der Tester ab (z. B. Lesen des Quellcodes).

Um etwas konträr zu sein ... Ich mag es oft, die Entwicklertests zu ignorieren und meine "eigenen" Tests zu entwickeln (ich bin Mitglied eines großen QE-Teams). Ich habe festgestellt, dass das Ignorieren von Entwicklertests dazu beiträgt, die Denkweise zu vermeiden, das Problem / Problem / Feature nur aus Entwicklersicht zu betrachten.

Mein QE-Motto lautet: QE sollte durch Testen des Produkts einen Mehrwert schaffen . "Unit-Tests zusammenführen und ausführen" allein ist keine ausreichende Qualitätssicherung!

Meine erste Reaktion auf diese Frage lautet „es kommt darauf an“.

Es hängt davon ab, was Sie unter „Testfällen des Entwicklungsteams“ verstehen.

• Wenn Sie nur Unit-Tests haben ( White-Box- Test); Das QA-Team (Integration und Systemtest) konnte Ihre Testfälle nicht nutzen. Unit-Tests dienen nur zur Überprüfung Ihres Geräts, das (meistens) nur eine Anforderung nicht erfüllt. White-Box-Tests sollten nicht der Weg für Integrations- oder Systemtests sein.

• Wenn Sie Verhaltenstests haben; Das QA-Team kann sie verwenden, um einige Integrationsszenarien abzuleiten.

• Wenn Sie TDD verwenden ; Tests sind per Definition ausführbare Dokumente der Anforderungen, Architektur und des Designs der Anwendung. Das QA-Team würde diese Testfälle definitiv benötigen.
• Einige Testdesignmethoden wie Gray-Box- Tests erfordern detaillierte Designinformationen, um Testpersonen wie Komponenten oder Subsysteme isolieren oder verspotten zu können (Integrationstest). Daher ist es auch erforderlich, das detaillierte Design mit dem QA-Team zu teilen.
• Systemtest-Leute kümmern sich nie um detailliertes Design. Sie konzentrieren sich auf Benutzerszenarien. Daher sind Entwicklungstests (White-Box) für sie nicht von Nutzen.

Meine bescheidene Empfehlung für Ihren Fall ist eine Bewertung von agilen Ansätzen wie Tester (QS) innerhalb des Entwicklerteams und Designtests (Feature, Integration, System) im Voraus.

Es gibt keinen Grund, warum Sie das, was Sie getestet haben, nicht mit dem QA-Team teilen sollten. Es sollte jedoch Ihre Tests duplizieren, die für die ordnungsgemäße Überprüfung der Anwendung wichtig sind.

1) Sie sind dafür verantwortlich, den Code / die Anwendung / was auch immer zu testen. Indem Sie Ihre Tests gegebenenfalls duplizieren, überprüfen sie, ob Ihr Test ordnungsgemäß durchgeführt wurde.

2) Als Entwickler sind Sie für das Testen Ihres Codes in Einheiten verantwortlich (im Allgemeinen haben jedoch einige Organisationen damit begonnen, dass Entwickler ihren Code auch testen). Dies ist ein anderer Ansatz und konzentriert sich in der Regel mehr auf die Abdeckung der Entscheidungspunkte in einer Methode.

3) Wie Sie bereits erwähnt haben, ist es wichtig, dass Ihr Testteam seine Testfälle mit Ihnen teilt, damit Sie über Fälle nachdenken können, die Sie ursprünglich möglicherweise nicht berücksichtigt haben.

4) Jemand erwähnte, dass es in der Verantwortung des Testteams liegt, die Anforderungen zu testen, und obwohl dies zutrifft, ist das detaillierte Design auch sehr hilfreich. Durch das Design kann das Testteam nicht nur sicherstellen, dass Sie die Anforderungen erfüllen, sondern es hilft ihnen auch, einige der Designentscheidungen zu verstehen und letztendlich bessere Testfälle zu erstellen.