Entwicklertests vs.QA-Teamtests – Was ist die richtige Arbeitsteilung?[geschlossen]

Question

Während ich versuche, mehr Entwicklertests einzusetzen, finde ich das Argument "Ist das ist das der QA nicht?" wird viel verwendet.Meiner Meinung nach macht es keinen Sinn, dem QA-Team die gesamte Testverantwortung zu übertragen, aber gleichzeitig sagen Spolsky und andere, dass man die Entwickler, die 100 US-Dollar pro Stunde kosten, nicht für etwas verwenden sollte, was ein Tester für 30 US-Dollar pro Stunde tun könnte .Welche Erfahrungen machen andere in einem Unternehmen mit einem engagierten QS-Team?Wo soll die Arbeitsteilung erfolgen?

Klärung:Ich meinte QA als Validierungs- und Verifizierungsteam.Entwickler sollten nicht die Validierung (kundenorientiertes Testen) durchführen, aber wo ist der Abteilungspunkt für die Verifizierung (Funktionstests)?

Answer 1

Es ist der Unterschied zwischen „Black-Box“-Tests (bei denen Sie wissen, was der Code tun soll, aber nicht, wie er funktioniert) und „White-Box“-Tests (bei denen Sie wissen, wie er funktioniert, wie Sie ihn testen).Wenn es um Qualitätssicherung geht, denken die meisten Menschen an „Black-Box“-Tests.

Ich arbeite für ein Unternehmen, dessen QA-Team auch aus Softwareentwicklern besteht.(Das engt das Feld ein eine Menge (falls Sie das Unternehmen erraten möchten.) Ich kenne Joels Meinung und meine Erfahrung führt dazu, dass ich teilweise anderer Meinung bin:Aus dem gleichen Grund, aus dem ein „White-Hat“-Hacker Sicherheitslücken effektiver findet, werden bestimmte Arten von Fehlern effektiver von White-Box-Testern gefunden, die wissen, wie man Code schreibt (und daher wissen, was die häufigsten Fehler sind – zum Beispiel beim Ressourcenmanagement). Probleme wie Speicherlecks).

Da QA-orientierte Entwickler bereits in der ersten Entwurfsphase Teil des Prozesses sind, können sie theoretisch dabei helfen, während des gesamten Prozesses qualitativ hochwertigeren Code voranzutreiben.Im Idealfall gibt es für jeden Entwickler, der an dem Projekt mit einem mentalen Fokus auf Funktionalität arbeitet, einen gegnerischen Entwickler, dessen mentaler Fokus darauf liegt, den Code zu knacken (und ihn dadurch zu verbessern).

So gesehen geht es weniger darum, Entwickler als Tester einzusetzen, sondern vielmehr um eine Art unzusammenhängender Paarprogrammierung, bei der ein Entwickler den Schwerpunkt auf die Qualitätskontrolle legt.

Andererseits sind für viele Tests (z. B. grundlegende UI-Funktionen) diese Fähigkeiten ehrlich gesagt nicht erforderlich.Da hat Joel recht.

Für viele Unternehmen könnte ich mir ein System vorstellen, bei dem Programmierteams die Codeüberprüfungs- und Testaufgaben gegen den Code der anderen tauschen.Mitglieder des Business Logic-Teams könnten beispielsweise gelegentlich eine Tour damit verbringen, Code für das UI-Team zu testen und zu überprüfen, und umgekehrt.Auf diese Weise „verschwenden“ Sie kein Entwicklertalent für Vollzeittests, sondern Sie profitieren von den Vorteilen, den Code (hoffentlich) der Prüfung und Bestrafung durch Experten auszusetzen.Dann kann ein traditionelleres QA-Team die „Black-Box“-Tests übernehmen.

Answer 2

Gegebenenfalls sollten Qualitätskontrollteams in der Lage sein, Sicherheits-, Regressions-, Benutzerfreundlichkeits-, Leistungs-, Stress- und Installations-/Upgrade-Tests durchzuführen und nicht Entwickler

Entwickler sollten Unit-Tests mit der Codeabdeckung für den zu schreibenden Code als Minimalziel durchführen.

Dazwischen gibt es noch einiges zu testen

• Vollständiger Codepfadtest
• Komponententests
• Integrationstests (von Komponenten)
• System-(Integrations-)Tests
• usw

Die Verantwortung hierfür liegt gemischt zwischen Qualitätssicherung und Entwicklung, basierend auf einer gegenseitigen Vereinbarung darüber, was am sinnvollsten ist.Einige Komponententests können nur durch Unit-Tests durchgeführt werden, andere werden während des Integrationstests usw. „ausreichend“ getestet.

Sprechen Sie miteinander und finden Sie heraus, was jeder am liebsten tut.Es wird einige Zeit dauern, aber es lohnt sich.

Answer 3

Es sollten immer einige Entwicklertests stattfinden.Wenn ein Entwickler zu viele Fehler produziert, verschwendet er/sie später Zeit damit, diese Fehler zu beheben.Es ist wichtig, dass die Entwickler nicht die Einstellung entwickeln, dass, na ja, wenn ich einen Fehler hinterlasse, dieser abgefangen wird und ich eine Chance bekomme, ihn zu beheben.

Wir versuchen, die Schwelle für erzeugte Fehler einzuhalten.Wenn dieser Schwellenwert während des Testens überschritten wird, liegt die Verantwortung dafür beim Entwickler.Es liegt an Ihnen, diesen Schwellenwert festzulegen (bei uns kann er von Projekt zu Projekt unterschiedlich sein).

Außerdem werden alle Unit-Tests von den Entwicklern durchgeführt.

Answer 4

Ich bin erst seit einem Jahr in der Branche tätig, aber meiner Erfahrung nach sind Entwickler für das Unit-Testen ihrer Funktionen verantwortlich, während die Qualitätssicherung für das Testen von Szenarien verantwortlich ist.Von der Qualitätssicherung wird auch erwartet, dass sie etwaige Randbedingungen prüft.

Answer 5

Ich füge meine Antwort auf eine Frage in unserem internen Forum ein.Wenn Sie etwa eine Stunde Zeit haben...Hören Sie sich Mary Poppendiecks an Wettbewerb auf der Grundlage der Geschwindigkeit Video. Empfohlen

Hinweis (Von Testern – ich verweise auf das QA-Team)

Entwickler-/Unit-Tests ________=_______ Usability-Tests und Exploration testen

'==================================================================

Abnahme / Kundentests ___=_____ Immobilienprüfung

Stellen Sie sich das als ein Quadrat mit vier Quadranten vor.:) :)

Die linke Hälfte sollte automatisiert sein.

• Entwicklertests stellen sicher, dass der Code so funktioniert, wie es der Programmierer wollte.Werkzeuge:NUnit / xUnit / welches selbstgemachte Tool auch immer
• Kundentests stellen sicher, dass der Code so funktioniert, wie der Kunde es wollte.Die Tests sollten sehr einfach zu schreiben sein und nicht erfordern, dass der Kunde .NET/Java erlernt.Andernfalls würde der Kunde diese Tests nicht schreiben (obwohl er möglicherweise die Hilfe eines Entwicklers benötigt).Fit verwendet beispielsweise HTML-Tabellen, die in Word geschrieben werden können.Werkzeuge:Fit -Regressionstools liegen auch hier.Aufnahme-Wiedergabe.

Die rechte Hälfte nutzt die Zeit und Mühe guter Tester besser aus.z.B.Kein automatisierter Test kann Ihnen sagen, ob der X-Dialog verwendbar ist.Menschen sind darin besser als Maschinen.

• Benutzerfreundlichkeit.Versuchen Sie, das System zum Absturz zu bringen (unbehandelte Fehlerszenarien abzufangen, Nullwerte einzugeben).Fangen Sie im Grunde Dinge ab, die der Entwickler übersehen hat.
• Für die Prüfung von Eigenschaften sind wiederum Menschen erforderlich.Hier prüfen Sie die vom Kunden vorgegebenen Eigenschaften, die Ihr System benötigt.z.B.Leistung – Hält Ihr Suchdialog die Reaktionszeit von 2 Sekunden ein?Sicherheit – Kann sich jemand in dieses System hacken?usw.Verfügbarkeit – ist Ihr System 99,99 % der Zeit online?

Tester sollten keine Zeit damit verbringen, Testpläne auf der linken Seite auszuführen.Es liegt in der Verantwortung des Entwicklers, sicherzustellen, dass der Code so funktioniert, wie es der Kunde und der Entwickler beabsichtigt haben.Tatsächlich können die Tester dem Kunden bei der Formulierung der Abnahmetests helfen.

Answer 6

Das Testen sollte so automatisiert wie möglich sein, was es wieder in Entwicklungsarbeit verwandelt, wenn die Tester Code schreiben, der der automatisierten Testsuite hinzugefügt wird.

Außerdem habe ich festgestellt, dass bei der Codeüberprüfung viel Qualitätssicherung durchgeführt wird, da die Leute zusätzliche Rand- und Eckfälle vorschlagen, die sie den überprüften Komponententests hinzufügen möchten (natürlich zusammen mit dem Code, den sie testen). .

Answer 7

Mein allgemeiner Standpunkt ist, dass Tester niemals Fehler auf Einheitenebene (einschließlich Grenzfälle) finden sollten.Die von den Testern gefundenen Fehler sollten auf Komponenten-, Integrations- oder Systemebene liegen.Natürlich können Tester zunächst „Happy Path“-Fehler und andere einfache Fehler finden, aber diese Anomalien sollten genutzt werden, um Entwicklern bei der Verbesserung zu helfen.

Ein Teil Ihres Problems könnte darin bestehen, dass Sie Entwickler für 100 Dollar pro Stunde und Tester für 30 Dollar pro Stunde einsetzen :}.Aber unabhängig von den Kosten denke ich, dass man, wenn man weiß, dass früher im Entwicklungszyklus entdeckte Fehler zwangsläufig billiger sind, wahrscheinlich immer noch Geld sparen würde, wenn man den Entwicklern mehr Tests überlassen würde.Wenn Sie über ein hochbezahltes Entwicklerteam und Hacktester verfügen, werden Sie wahrscheinlich viele der großen, offensichtlichen Probleme finden, aber Sie werden viele der eher obskuren Fehler übersehen, die Sie später noch einmal verfolgen werden.

Ich vermute also, dass die Antwort auf Ihre Frage lautet: Tester sollten so viel testen, wie Sie möchten.Sie können alle Ihre Tester entlassen und die Entwickler alle Tests durchführen lassen, oder Sie können eine Armee von Testern einstellen und die Entwickler alles einchecken lassen, was sie wollen.

Answer 8

Es gibt zwei Arten von QA-Gruppen: diejenigen, die den Status Quo aufrechterhalten wollen.Das haben wir immer gemacht.Sie hassen und stoßen von Natur aus diejenigen ab, die versuchen, die Dinge effizienter zu machen und damit ihre Komfortzone zu verlassen.Das ist mir mehr als einmal passiert.Leider sind QA-Manager genauso inkompetent wie ihre QA-Teams.Ein QS-Manager, der seit sechs Jahren im Management tätig ist, wird also jegliche Automatisierung abschaffen und viele Prozesse einführen, nur um deren Existenz zu rechtfertigen. Es liegt in der Verantwortung des oberen Managements, dies zu erkennen.Es gibt eher technische QA-Leute, die sich mit Werkzeugen auskennen.Leider ist eine Programmiersprache kein Werkzeug, sondern eine Vision.Die Zusammenarbeit mit diesen Leuten hängt wirklich davon ab, wie viel sie bereit sind zu lernen und wie sehr das Management bereit ist, das Risiko einzugehen, Dinge zu ändern.Die Tests sollten auf die gleiche Weise geschrieben werden wie ein Hauptcode mit einer objektorientierten Struktur, die leicht zu warten ist.Ich denke, dass Entwickler QA-Tests überprüfen sollten.Meistens stellte ich fest, dass die Automatisierung nichts testete.Leider gilt QA-Arbeit als Unterklasse, sodass sich Entwickler nicht darum kümmern.Ich selbst habe Glück, wenn ich von einem einflussreichen Entwickler in einer Gruppe Unterstützung bekomme, der bereit ist, einem Manager meine Bemühungen zu erklären.Leider funktioniert es nur in der Hälfte der Fälle.Tester sollten meiner Meinung nach dem Entwicklungsmanager Bericht erstatten.Und das gesamte Team sollte die Verantwortung dafür übernehmen, was QA-Tests tatsächlich testen.

Answer 9

Hier sind einige Beispiele dafür, wie Entwicklertests am effizientesten und lohnendsten sind:

• Der Entwickler ändert eine gemeinsam genutzte Bibliothek, während er an einer Funktion arbeitet – der Entwickler hat Einblick in mögliche Nebenwirkungen, die die Qualitätssicherung/Validierung nicht hat
• Der Entwickler ist sich der Leistung des Bibliotheksaufrufs nicht sicher und schreibt einen Komponententest
• Der Entwickler entdeckt den Pfad des Anwendungsfalls, der nicht in der Spezifikation berücksichtigt wird, die der Code unterstützen muss, schreibt Code, aktualisiert die Spezifikation und schreibt Tests

Es lässt sich darüber streiten, wie viele Testaufgaben der Entwickler im dritten Beispiel durchführen sollte, aber ich behaupte, dass es für den Entwickler am effizientesten ist, weil sich alle zugehörigen Details aus vielen Dokumentations- und Codeebenen bereits in seinem Kurzzeitgedächtnis befinden.Dieser perfekte Sturm kann von einem Tester im Nachhinein möglicherweise nicht mehr erreicht werden.

Sprechen wir über Qualitätssicherung oder Validierung?Ich denke an Qualitätssicherung im Sinne von Inspektionschecklisten, Durchsetzung von Codestandards, UI-Richtlinien usw.Wenn es um Validierung geht, macht es für Entwickler keinen Sinn, viel Zeit mit der Erstellung und Ausführung formaler Testfälle zu verbringen, aber Entwickler müssen alle Begründungen und Designdokumentationen bereitstellen, die zum Erstellen guter Tests erforderlich sind.