Programmierer, die Tests durchführen

Ich frage mich, wie typisch es für Programmierer ist, die Hüte zu wechseln und die Arbeit des anderen zu testen. Angenommen, das Team möchte einen Ansatz mit "geteilter Verantwortung" verfolgen, um Aufgaben von der Formalisierung bis zur Freigabe zu verschieben.

1. Ist es eine gute Idee, Programmierer als Softwaretests arbeiten zu lassen, solange sie keine Funktion geschrieben haben?

2. Kommt das oft vor?

3. Inwieweit kann ein Programmierer seine eigene Arbeit "testen"?

Gibt es auch bei TDD- und Unit-Tests keinen Bedarf an einem Software-Testgerät im Entwicklungsprozess?

1. Wenn der Programmierer seine Funktionen testet, kann dies eine gemischte Sache sein. Einerseits kann der Programmierer mit dem Codeblock "zu vertraut" sein und einfach bekannte Pass / Fail-Parameter testen. Auf der anderen Seite, wenn der Programmierer, der mit seinem Code "zu vertraut" ist, fleißig dafür sorgt, dass die Funktion funktioniert, hat er mehr Wissen über Randfälle, die Probleme verursachen können, da er das Innenleben der Funktion und mögliche Lücken kennt darin.

2. Ich denke, das passiert meistens. Ich denke, die meisten Programmierläden sind in kleinen Teams oder stehen unter großem Druck, Dinge zu erledigen. Dies bietet ihnen nicht den Luxus eines engagierten QA / Testers in ihrer Gruppe, daher muss jeder seinen Anteil ziehen. Es gibt immer noch eine ganze Reihe von "Lone Cowboy" -Läden, in denen jeder Entwickler im Wesentlichen für den gesamten Lebenszyklus seiner App verantwortlich ist. Das ist bei mir der Fall.

3. Ich werde dafür auf # 1 zurückschieben. Ich denke, ein Programmierer ist in der Lage, seine eigene Arbeit außerhalb des TDD-Modells zu testen, da er genau weiß, wie seine Funktion funktioniert. Sie müssen darauf achten, "zurückzutreten" und in der Lage zu sein, bestimmte und umfassende Probleme mit dem Code zu behandeln (z. B. "Fettfingern" eines Texteingabefelds - was passiert?), Aber es kann getan werden.

Devs Testen jeder Code andere nicht getan werden sollte , anstatt der Prüfung durch einen fokussierten QA - Spezialist, aber wäre toll , zusätzlichzum Testen durch einen fokussierten Tester. Entwickler können gut darüber nachdenken, wie das Produkt funktioniert. Tester sind die einzigen Personen im Team (BAs, PMs, Entwickler usw.), die sich darauf konzentrieren, herauszufinden, wie das Produkt versagen könnte. Es ist eine ganz andere Denkweise. Denken Sie an Ihre "Ausfallzeit" - z. B. wenn Sie beim Duschen Projekte in Ihrem Kopf skizzieren. Denken Sie: "Oh, ich wette, dies wäre ein guter Weg, um diese Funktion in Angriff zu nehmen!" oder denkst du: "Hey, ich sollte sehen, ob ich diesen Code zum Scheitern bringen kann, wenn ich das tue!"? Die Arbeit findet nicht nur im Büro statt, und Entwickler werden in ihrer "Freizeit" wahrscheinlich nicht daran arbeiten, Code zu brechen. Tester sollten auch eine Vielzahl von Kenntnissen über Testwerkzeuge und -techniken sammeln und Erfahrung darin haben, zwischen ihnen zu wählen, die Entwickler nicht haben.

Gleichzeitig ist interdisziplinäre Erfahrung eine sehr gute Sache, und die Arbeit mit dem Code anderer Entwickler hat immer einen Vorteil. Wenn Entwickler mehr Aufwand in das Testen investieren, bevor eine bestimmte QS / Testperson den Code überprüft, führt dies wahrscheinlich zu einem Code mit besserer Qualität, was wahrscheinlich zu einer schnelleren Testdurchführung, einer besseren Testabdeckung und möglicherweise sogar zu einer Verringerung (aber nicht zu einer Beseitigung) führt. die Anzahl der benötigten dedizierten Tester.

Wenn Sie aufgrund der geringen Verfügbarkeit von Mitarbeitern wirklich Kompromisse eingehen müssen oder wenn der Qualifikationspool für die Qualitätssicherung dort, wo Sie sich befinden, außergewöhnlich schlecht ist, ist dieses Setup besser als nichts - aber das Ziel sollte immer noch sein, einen echten Tester zu gewinnen bevor das Team zu groß wird.

Ich habe noch nie eine schlechte Testmethode gesehen.

Sollten Programmierer ihren eigenen Code testen? Ja offensichtlich.

Sollten andere Leute ihren Code testen? Ja offensichtlich.

Ist das Testen der Abdeckung eine gute Idee? Ja.

Ist Monte-Carlo-Test gut? Ja.

Wir können das haben, was wir für ein ziemlich gutes Setup zum Testen halten, und dann führt eine neue Person einige Tests durch. Erraten Sie, was? Sie finden Probleme, die vorher nicht gefunden wurden.

Ein Zeichen dafür, dass die Qualität gut wird, ist, wenn sich der Prozentsatz der Probleme, die beim Testen festgestellt werden und keine wirklichen Fehler sind, 100% nähert.

Es gibt eine große und wachsende Entwicklungsbewegung namens Test Driven Development oder TDD. Ich behaupte nicht, ein Experte zu sein, und habe mich tatsächlich bemüht, diese Methode standardmäßig auszuführen, aber das Wesentliche ist, dass der Entwickler zuerst einen fehlgeschlagenen Test schreibt und dann den Code schreibt, um diesen Test zu bestehen.

Das Konzept hat viele Stärken. Eine davon ist, dass Sie eine Reihe großartiger Tests haben. Ein weiterer Grund ist, dass Sie, da dies in vielen kleinen Schritten erfolgt, sofort wissen, ob Sie etwas kaputt machen. Eines der Dinge, die ich mit dieser Methode und anderen "Testmandaten" gesehen habe, ist, dass Entwickler nicht herumlaufen, um zusätzliche Funktionen einzubauen, weil sie cool oder ordentlich sind. Eine Funktion ist immer mit Kosten verbunden, und oft sieht oder fühlt ein Entwickler diese Kosten nicht. Bei TDD ist dies der Fall, da Sie einen Testfall schreiben, bevor Sie Code schreiben.

Es gibt auch Erweiterungen dieser Theorie, die das Schreiben von Tests zur Anforderungsquelle führen, wo der Geschäftsexperte eine Reihe von Funktionstests schreibt, aus denen die Spezifikation besteht, und die Entwickler dann zu dieser Reihe von Testfällen entwickeln.

Mit TDD schreibt der Entwickler viele Tests, einige sprechen sich für ein Verhältnis von 1: 1 für Testcodezeilen zu Codezeilen aus.

Umkehren - Ich denke, es ist von großem Wert, mindestens ein paar Leute für das Team zu rekrutieren, die besser testen als programmieren können. Es ist eine Fähigkeit, die sich von der Entwicklung unterscheidet, und ich denke - selbst bei TDD und anderen agilen Praktiken -, dass jemand mit einem guten Auge für Tests für die Produktqualität von unschätzbarem Wert ist.

So einfach zu fragen - sollten Tester genauso viel codieren wie Codierer testen.

IMO - ja, es sollte zumindest eine kleine Mischung geben. Wenn Sie eine Perspektive auf das andere Ende der Produktherstellung haben, sind Sie rund und können neue Erkenntnisse gewinnen.

Ich denke, dass es in der Verantwortung eines Programmierers liegt, eine angemessene Sorgfalt walten zu lassen, bevor ein Code eingecheckt und abgemeldet wird. Dies bedeutet:

• Schreiben gründlicher Unit-Tests.
• Testen Sie diesen Code in einem realen Anwendungsszenario und versuchen Sie, ihn zu brechen - dh interagieren Sie mit ihm, wie er in der Produktion verwendet wird.

...

• Dann sollte ein anderer Programmierer diesen Code und die Komponententests überprüfen.

• Dann sollte ein engagierter Tester / eine QS-Person diesen Code testen.

Ich denke nicht, dass es eine Entschuldigung dafür gibt, die ersten 3 nicht zu machen. Und ich denke nicht, dass es eine Entschuldigung dafür gibt, den letzten Schritt nicht zu machen, aber einen dedizierten Testertest zu haben, ist jedes Stück Code teuer und kleinere Unternehmen (denke zumindest), dass dies Luxus ist, den sie sich nicht leisten können.

Persönlich glaube ich nicht, dass bestimmte Tests jemals aus der Gleichung herausgenommen werden sollten. Ich denke, Sie müssen Leute finden, die zumindest nicht das gleiche Produkt (oder vielleicht ein großes Modul) entwickeln, was es einigen anderen Programmierern ermöglichen würde, zu testen, solange sie wirklich keine Ahnung haben, was die Implementierung ist. Ich denke, das Wichtigste ist, dass Entwickler unabhängig davon, ob sie es jemals tun oder nicht, als Tester und Tester als Entwickler fungieren können sollten. Das Vorhandensein von Wissensdatenbanken und Vertrautheiten erleichtert die Entwicklung, das Testen und die Kommunikation zwischen beiden erheblich.

1. Ja, obwohl sie nicht "als Softwaretests arbeiten". Das Schreiben von Tests gehört zum Job eines Programmierers. Gute Tests zu schreiben ist auch eine Fähigkeit. Die Unfähigkeit, die eigenen Funktionen ordnungsgemäß zu testen, ist kein Fehler beim Testen, sondern ein Indikator für mangelnde Fähigkeiten *.

2. Das würde ich sicherlich hoffen.

3. Während ein Programmierer seine Arbeit vollständig testen kann, kann ein externer QS-Prozess von Nutzen sein. Ich habe jedoch selten festgestellt, dass dies der Fall ist.

Das Ziel des Testens ist dreifach:

1. Entwicklung vorantreiben
2. Änderungen verwalten
3. Vertrauen schaffen

Entwicklertests können und sollten all diesen Zwecken dienen. Wenn Entwicklertests für sie ausreichen, sind keine weiteren Tests erforderlich.

* Die Paarprogrammierung macht es noch schwieriger, solche schlechten Tests zu schreiben, da Sie niemals Ihre eigenen Funktionen testen.