it-swarm-eu.dev

Sollte ein Entwickler auch als Tester fungieren?

Wir sind ein Scrum-Team aus 3 Entwicklern, 1 Designer, dem Scrum-Master und dem Product Owner. Wir haben jedoch keinen offiziellen Tester in unserem Team. Ein Problem, das immer bei uns ist, ist, dass das Testen der Anwendung und das Bestehen dieser Tests sowie das Entfernen von Fehlern als eines der Kriterien definiert wurde, um ein PBI (Product Backlog Item) als erledigt zu betrachten.

Das Problem ist jedoch, dass unabhängig davon, wie oft wir (3 Entwickler und 1 Designer) versuchen, die Anwendung zu testen und Anwendungsfälle zu implementieren, einige Fehler nicht erkannt werden und unsere Präsentation ruinieren ( Murphys Gesetz ) Stakeholder.

Als Abhilfe empfahlen wir dem Unternehmen, einen neuen Tester einzustellen. Jemand, der seine Aufgabe hat, würde testen und nur testen. Ein offizieller professioneller Tester.

Das Problem ist jedoch, dass Scrum Master und Stakeholder der Meinung sind, dass ein Entwickler (oder ein Designer) auch ein Tester sein sollte.

Haben sie recht Sollten wir Entwickler (auch Designer) auch Tester sein?

60
Saeed Neamati

Ex ante: Es scheint viel Verwirrung darüber zu geben, was als Testen angesehen wird, was nicht. Sicher, jeder Entwickler muss seinen Code testen, während er ihn erstellt. Er muss überprüfen, ob er funktioniert. Sie/er kann es keinem Tester geben, bevor er/sie denkt, dass es fertig und gut genug ist. Aber Entwickler sehen nicht alles. Sie erkennen möglicherweise keine Fehler. Diese Fehler können erst später im Entwicklungszyklus gefunden werden, wenn gründliche Tests durchgeführt werden. Die Frage ist, ob Entwickler diese Art von Tests durchführen sollten oder nicht, und meiner bescheidenen Meinung nach muss dies aus Sicht eines Projektmanagers betrachtet werden:

Entwickler können Tester sein, aber sie sollten keine Tester sein. Entwickler neigen dazu, unbeabsichtigt/unbewusst zu vermeiden, die Anwendung auf eine Weise zu verwenden, die sie beschädigen könnte. Das liegt daran, dass sie es geschrieben und meistens so getestet haben, wie es verwendet werden sollte.

Ein guter Tester hingegen versucht, die Anwendung zu foltern. Seine/ihre primäre Absicht ist es, es zu brechen. Sie verwenden die Anwendung häufig so, wie es sich Entwickler nicht vorgestellt hätten. Sie sind näher an den Benutzern als am Entwickler und haben oft einen anderen Ansatz, um einen Workflow zu testen.

Die Verwendung von Entwicklern als Tester erhöht außerdem die Entwicklungskosten und wirkt sich weniger auf die Qualität des Produkts aus als die Verwendung eines dedizierten Testers. Ich würde nicht zulassen, dass Entwickler ihre Arbeiten einem Cross-Test unterziehen, wenn ich es von einem Tester für wenig Geld besser machen lassen kann. Nur wenn die Rückkopplungsschleife zwischen Entwicklern und Testern zu teuer würde, hätten Entwickler den Code des anderen gegenseitig überprüft, aber meiner Erfahrung nach ist dies selten der Fall und hängt stark vom Prozess ab.

Das bedeutet nicht, dass ein Entwickler schlampig sein und alles dem Tester überlassen sollte. Die Software sollte durch Komponententests gesichert und technische Fehler auf ein Minimum reduziert werden, bevor die Software an den Tester übergeben wird. Trotzdem , manchmal haben Sie hier behoben, dort Probleme oder andere Fehler behoben, die kein Entwickler vorhersehen konnte, das ist in Ordnung. Außerdem sollten Integrationstests hauptsächlich von den Entwicklern durchgeführt werden. Das Hauptziel des Testers besteht darin, zu überprüfen, ob die Anforderungen erfüllt sind.

In einem so kleinen Team (und auch abhängig von der Größe der Anwendung) kann ich den Tester auch in einer hybriden Rolle sehen und Unit-Tests und UI-Tests schreiben. Sie sollten auf jeden Fall einen mieten.

Wichtiger als der Tester sind jedoch regelmäßige Einfrierungen/Verzweigungen. Präsentieren Sie nichts, was nicht richtig getestet wurde. Wenn Sie eine Funktion hinzugefügt oder geändert haben, muss alles, was sie umgibt, erneut überprüft werden. Sie erhalten nur dann einen schlechten Ruf, wenn Ihr Unternehmen dies nicht tut. Geben Sie nichts Instabiles frei. Wenn der Kunde die Software bis zu einem bestimmten Datum haben möchte, beenden Sie die Entwicklung früh genug und testen Sie sie ordnungsgemäß, damit Sie genügend Zeit für Fehlerbehebungen haben. Oft ist es besser, Last-Minute-Feature-Anfragen abzulehnen, als sie schlecht zu implementieren oder ohne ordnungsgemäße Tests freizugeben.

59
Falcon

Entwickler können Tester sein - des Codes anderer Entwickler.

Das Testen des eigenen Codes ist jedoch kein guter Schritt. Entwickler neigen dazu, mentale Blockaden in Bezug auf ihren eigenen Code zu haben, und haben daher Schwierigkeiten, umfassende oder geeignete Tests zu entwerfen.

Es wird immer Entwickler geben, die denken, dass sie das gut machen, aber normalerweise nicht (und ich weiß, dass ich viele blinde Flecken habe).

Wenn Sie WIRKLICH KEINEN Tester einstellen können, lassen Sie die Entwickler sich gegenseitig testen. Wenn A den Code schreibt und Unit-Tests durchführt, veranlasst B, diese Unit-Tests zu überprüfen und zu prüfen, ob weitere Dinge hinzugefügt werden könnten . Und lassen Sie B versuchen, den Code (als Benutzer) zu testen und Fehler zu melden.

Dies ist nicht perfekt, aber es ist besser als ein einzelner Entwickler, der versucht, alles zu tun.

Manchmal sind Ihre Kollegen wirklich gut darin, Ihre Software zu beschädigen, weil sie davon Spaß haben und sich nicht so sehr darum kümmern - weil es nicht IHR Code ist.

42
quickly_now

Sollte der Journalist dazu neigen, richtig zu schreiben? Ich meine, es ist Aufgabe der Korrektoren und Redakteure, alle grammatikalischen Fehler zu finden.

Trotzdem bieten Journalisten selbst eine Rechtschreibprüfung an. Trotzdem ist Korrektor ein eigenständiger und wichtiger Beruf.

Das Gleiche gilt für Entwickler und Tester, mit der Ausnahme, dass die Qualitätssicherung ein noch wichtigerer Bestandteil der Entwicklung ist. Selbst wenn Sie ein guter Entwickler sind, haben Sie keine Zeit, alle Testfälle gründlich zu testen, um alle Umgebungen, Browser und Betriebssysteme abzudecken, die Ihr Produkt unterstützt.

Wenn man neben der Entwicklung auch ständig diesen Job macht, bedeutet das nur eine einfache Tatsache - er ist ein Teilzeit-Tester.

11
shabunc

egal wie oft wir (3 Entwickler und 1 Designer) versuchen, die Anwendung zu testen und Anwendungsfälle zu implementieren, dennoch werden einige Fehler nicht gesehen und ruinieren unsere Präsentation ... gegenüber Stakeholdern.

Erwägen Sie, einen "kontrollierten Lauf" für ein oder zwei Sprints durchzuführen, indem Sie Entwickler und Testbemühungen separat verfolgen. Analysieren Sie am Ende eines solchen Laufs die gesammelten Daten, um herauszufinden, wie viel Aufwand Sie für das Testen aufwenden.

Wenn Sie feststellen, dass das Testen viel Aufwand erfordert, geben Sie diese Daten an das Management weiter. Dies ist ein überzeugender Beweis für Ihre Anfrage (viel überzeugender als jetzt).

Andernfalls (wenn Sie feststellen, dass das Testen wenig Zeit in Anspruch nimmt) sollten Sie zusätzliche Anstrengungen unternehmen, um es besser zu machen (oder zu lernen, wie das geht). Verhandeln Sie den zusätzlichen Aufwand , den Sie mit Ihrem Management planen - da diese möglicherweise lieber einen Tester einstellen möchten. :) :)


... haben wir dem Unternehmen empfohlen, einen neuen Tester einzustellen. Jemand, der seine Aufgabe hat, würde testen und nur testen. Ein offizieller professioneller Tester.

Das Problem ist jedoch, dass Scrum Master und Stakeholder der Meinung sind, dass ein Entwickler (oder ein Designer) auch ein Tester sein sollte.

Ich muss zugeben, das Management Ihres Unternehmens sieht für mich ziemlich lahm aus. Ich meine - ok, es kann wirklich schwierig sein herauszufinden , wie viele Tester für das Projekt am besten geeignet sind, okay.

Aber mindestens einen Tester zu haben, ist nur eine sichere Sache - wirklich lustig, dass sie zögern , es zu versuchen, während sie behaupten selbst scrum/ agil.

10
gnat

Nun, wir hatten zwei Entwickler im Kreuztest, nachdem der erste einige Änderungen an einem Eingabebildschirm vorgenommen hatte. Zu diesem Zeitpunkt war unser regulärer Tester im Mutterschaftsurlaub.

Er hat im Grunde einen Rechnungslistenbildschirm geändert, auf dem die Benutzer vor dem Vergrößern Rechnungen auswählten, um einige Änderungen über die Schaltfläche "Bearbeiten" vorzunehmen. Die ursprüngliche Liste wurde verworfen und eine neue Rasteransicht eingefügt, mit Filtern, Gruppieren, Sortieren und allerlei coolen Funktionen.

Die Tests verliefen hervorragend und sie haben die Änderungen am nächsten Tag auf den Kunden hochgeladen. Zwei Wochen später ruft der Kunde an und sagt: "Wir mögen das neue Ding, das Sie eingegeben haben, sehr. Wir können jetzt alle möglichen Informationen sehen. Aber ... ähm ... wohin gehen wir jetzt, um die Rechnungen zu bearbeiten?" ?? "

Es stellte sich heraus, dass der Entwickler das Kontrollkästchen (zur Auswahl) und die Schaltfläche zum Bearbeiten deaktiviert hat. Da die Entwickler ohnehin immer doppelklickten, um ein Element auszuwählen, fand keiner von ihnen etwas Falsches daran.

Entwickler und Benutzer leben in verschiedenen Welten. Cross-Tests sind besser, als wenn der Entwickler seine eigene Arbeit testet, aber es ist immer noch nicht ganz dasselbe.

9
Permas

Wie andere hier bereits gesagt haben, können die Entwickler den Code der anderen (Unit- oder Funktionstests) gegenseitig testen, und möglicherweise kann Ihr Scrum Master und Produktbesitzer beim Integrationstest helfen. Für Benutzerakzeptanztests sollten Sie jedoch sicherstellen, dass Sie den Code erhalten viel Feedback aus dem Kundentest - was bedeutet häufige Bereitstellungen, mit denen sie so arbeiten können, wie es echte Benutzer tun, und ein wirklich offene Kommunikation Kanal.

4
StevenV

Das Testen von Software ist ein professioneller Vollzeitjob. Es braucht ein gutes Gehirn, Talent und viel Erfahrung, um ein guter Tester zu werden. Es ist lächerlich anzunehmen, dass ein Softwareentwickler, egal wie clever er auch sein mag, einem professionellen Tester nahe kommen kann, wenn das Testen nur ein kleiner Bestandteil seiner täglichen Arbeit ist.

Hinzu kommt das Problem, dass der Softwareentwickler unbewusst nicht möchte, dass Fehler gefunden werden.

2
gnasher729

Sie sollten unter Berücksichtigung der Testbarkeit entwerfen, aber wenn Sie keinen dedizierten Tester haben, werden einige Dinge einfach durch die Ritzen rutschen, da der Tag nicht genügend Stunden hat, um Software zu entwerfen, zu implementieren und zu testen.

2
davidk01

Ich stimme ihrem Standpunkt zu, dass die Entwickler/Designer ihren Code testen sollten, mit dem Hinweis, dass der Designer/Entwickler, der einen Codeabschnitt erstellt hat, nicht die einzigen "Augen" für diesen Code sind, bevor er sich zum Leben verpflichtet hat. Das wird zwar nicht alles erfassen, aber es wird zumindest helfen, die Blindheit zu vermeiden, die sich beim Testen und erneuten Testen Ihres eigenen Codes während der Entwicklung einschleicht.

Aufgrund der Erwähnung des Anwendungsfalls gehe ich davon aus, dass Sie auch Tools zur Codeabdeckung verwenden. Wenn nicht, kann dies helfen, festzustellen, welcher Code möglicherweise nicht getestet wurde, und unter bestimmten Bedingungen zu unerwarteten Fehlern führen.

Abgesehen davon, wenn es genug Arbeit gibt oder Ihre Organisation eine anständige Größe hat, würde ich zustimmen, dass eine professionelle QS-Person benötigt wird, um die Rollen aller ein bisschen mehr zu fokussieren, und sie könnten auch sehen, ob es irgendwelche Muster gibt, was wird vermisst und vor allem, wie man es behebt.

1
canadiancreed