Sollte ein Entwickler auch als Tester fungieren? [geschlossen]


60

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 wir immer haben, ist, dass das Testen der Anwendung und das Bestehen dieser Tests sowie das Entfernen von Fehlern als eines der Kriterien definiert wurden, um ein PBI (Product Backlog Item) als erledigt zu betrachten.

Aber das Problem ist, dass, egal wie oft wir (3 Entwickler und 1 Designer) versuchen, die Anwendung zu testen und Anwendungsfälle zu implementieren, dennoch einige Fehler nicht gesehen werden und unsere Präsentation ( Murphys Gesetz ) für die Interessengruppen ruinieren .

Als Abhilfe empfahlen wir dem Unternehmen, einen neuen Tester zu beauftragen. Jemand, der seinen Job 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 Designer) auch ein Tester sein sollte.

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


1
Mögliches Duplikat von programmers.stackexchange.com/questions/100637/… , obwohl dies vom entgegengesetzten Standpunkt aus gefragt wurde.
Adam Lear

Im Scrum-Team, in dem ich schon war, testeten alle die Smartphone- oder Tablet-App und alle waren eine große Hilfe.
ott--

Autoren brauchen einen Editor.
JeffO,

Antworten:


59

Ex ante: Es scheint eine Menge Verwirrung darüber zu geben, was als testen von was nicht angesehen wird. Klar, 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 es für erledigt und gut genug hält. Entwickler sehen aber nicht alles. Sie erkennen möglicherweise keine Bugs. 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 der 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 größtenteils so getestet haben, wie es verwendet werden sollte.

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

Die Verwendung von Entwicklern als Testern erhöht zudem die Entwicklungskosten und wirkt sich weniger auf die Produktqualität aus als ein dedizierter Tester. Ich würde es nicht zulassen, dass Entwickler ihre Werke gegenseitig testen, wenn ich es mir von einem Tester billiger machen lassen könnte. Nur wenn die Rückkopplungsschleife zwischen Entwicklern und Testern zu teuer würde, müssten sich die Entwickler gegenseitig den Code überlagern, aber meiner Erfahrung nach ist dies selten der Fall und es hängt stark vom Prozess ab.

Das bedeutet nicht, dass ein Entwickler schlampig sein und alles dem Tester überlassen sollte. Die Software sollte durch Unit-Tests gesichert und technische Fehler auf ein Minimum reduziert werden, bevor die Software dem Tester übergeben wird. Trotzdem, manchmal haben Sie hier Fehler behoben, es gibt Probleme oder andere Fehler, 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 Hybridrolle sehen, indem ich Unit-Tests und UI-Tests schreibe. Sie sollten auf jeden Fall einen mieten .

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


9
Stimme überhaupt nicht zu ... Entwickler können sehr effektive Tester sein, aber der Entwickler eines Features sollte NICHT auch der Tester desselben Features sein. Viele kleine Teams spielen beide Rollen, indem drei Personen an drei verschiedenen Features arbeiten und dann die Tests an einen der anderen drei Entwickler übergeben. Es funktioniert sehr gut, wenn ein Team keinen QS-Tester hat.
maple_shaft

5
@maple_shaft: Imho gibt es keine Entschuldigung dafür, keinen Tester zu haben. Jedes Projekt liefert eine höhere Qualität mit einem speziellen Tester, auf den sich die Entwickler konzentrieren können und der sich gut entwickelt, wenn es einen gibt. Entwickler gegenseitig Code testen zu lassen, ist eine notdürftige Lösung, selbst für kleine Teams, imho. Sie sollten auch Joels Artikel darüber lesen .
Falcon

3
Entwickler können Tester sein - und ein guter Entwickler kennt tatsächlich viele Stellen, an denen Code schwach und bruchanfällig sein kann. Lassen Sie einfach nie jemanden den Code testen, den Sie entworfen oder geschrieben haben - das ist nutzlos. Der Code anderer Leute ist möglicherweise in Ordnung.
StasM

4
@deadalnix: Es verwirrt mich wirklich, warum Leute abstimmen, ohne meine Antwort zu lesen und zu verstehen. Um mich selbst zu zitieren: "Die Software sollte durch Unit-Tests gesichert und technische Fehler auf ein Minimum reduziert werden, bevor die Software dem Tester übergeben wird."
Falcon

2
"Andererseits versucht ein guter Tester, die Anwendung zu foltern. Seine / ihre Hauptabsicht ist es, sie zu brechen." - Stimme überhaupt nicht zu. Ich habe einen Tester, der ständig versucht, die Tastatur nach unten zu drücken oder Felder zu überlaufen. Sicher, das sind Fehler, aber eine Billionen-Dollar-Rechnung, die einen Fehler auslöst, steht so wenig auf meiner To-Do-Liste, dass ich mich nicht registrieren kann. Ein GREAT- Tester testet alle Szenarien, in denen verschiedene Benutzer die App verwenden würden. Ein guter Entwickler stellt sicher, dass alle Codepfade getestet wurden und die App bei bestimmungsgemäßer Verwendung funktioniert.
Paul

42

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

Das Testen des eigenen Codes ist jedoch kein guter Schritt. Entwickler neigen dazu, sich Gedanken über ihren eigenen Code zu machen, 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 die Arbeit der anderen testen. Wenn also A den Code schreibt und Komponententests durchführt, lässt Sie B diese Komponententests überprüfen und prüfen, ob noch 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 können Ihre Kollegen wirklich gut darin sein, Ihre Software zu beschädigen, weil ihnen das Spaß macht und sie sich nicht so sehr darum kümmern - weil es nicht IHR Code ist.


2
Oh ja, sicher. Stimme voll und ganz zu. Es ist nur so, dass Sie sich mit weniger zufrieden geben müssen, wenn Sie nicht 100% von dem bekommen können, was Sie wollen. Sie wissen, dass weniger nicht so gut ist, aber es ist besser als nichts.
quick_now

4
Ich stimme generell mit Kreuztests überein, aber bei einigen Teams, die Konflikte verursachen. Einige geben gerne anderen die Schuld ("meine Sachen funktionieren, deine nicht, lol, ich bin so viel besser als du") und das ist inakzeptabel. Das habe ich schon oft gesehen. Das Crosstesting sollte nur zwischen Kollegen durchgeführt werden, die sich gegenseitig respektieren. In meinem Team habe ich den namenlosen Entwickler vorgestellt, der für jeden Fehler verantwortlich gemacht wird, um zu verhindern, dass jemand sein Gesicht verliert. Bugs sind namenlos, sie passieren.
Falcon

5
+1 Es ist unmöglich, Ihren eigenen Code richtig zu testen. Es ist erstaunlich, welche Tricks der Verstand auf Sie anwenden kann - Sie sind sich zu 100% sicher, dass Sie eine Funktion codiert und getestet haben, und es wird jemand anderes erforderlich sein, um Ihnen zu zeigen, dass es tatsächlich nur in sehr engen Fällen funktioniert und nicht sei dir doch mal aufgefallen - aber du würdest es selbst nie sehen. Der Verstand verwendet kognitive Verknüpfungen, und diese machen es der Person, die den Code entworfen und entwickelt hat, beim Testen unmöglich, ihn ordnungsgemäß zu testen.
StasM

2
@StasM - einverstanden, mit einer kleinen Einschränkung: Ich habe festgestellt, dass ich Monate später, wenn ich wieder zu meinem eigenen Code zurückkehre, die Fehler erkennen und objektiver testen kann. Aber testen Sie Ihre eigenen nach dem Schreiben ist in der Tat sehr schwer.
schnell_now

1
@ Ben Aston: Ein Entwickler sollte immer noch Unit-Tests, Integrationstests usw. durchführen. Nur nicht ausschließlich. Die toten Winkel verschwinden nicht, nur weil Sie es wollen.
quick_now

11

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

Dennoch bieten Journalisten einige Rechtschreibprüfungen selbst an. Trotzdem ist der 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 sich nicht nur weiterentwickelt, sondern diese Arbeit auch ständig erledigt, bedeutet das nur eine einfache Tatsache - er ist ein Teilzeit-Tester.


10

Unabhängig davon, wie oft wir (3 Entwickler und 1 Designer) versuchen, die Anwendung zu testen und Anwendungsfälle zu implementieren, werden dennoch einige Fehler nicht gesehen und ruinieren unsere Präsentation ... für die Stakeholder.

Erwägen Sie, einen "kontrollierten Lauf" für einen oder zwei Sprints durchzuführen, um Entwickler und Testbemühungen getrennt zu 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 bisher).

Andernfalls (wenn Sie feststellen, dass das Testen nur wenig Zeit in Anspruch nimmt) sollten Sie zusätzliche Anstrengungen unternehmen, um es besser zu machen (oder zu lernen, wie man das macht). Besprechen Sie den zusätzlichen Aufwand, den Sie planen, mit Ihrem Management, da es möglicherweise vorgezogen wird, stattdessen einen Tester zu engagieren. :)


... wir haben der Firma empfohlen, einen neuen Tester zu mieten. Jemand, der seinen Job 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 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 sehr schwierig sein herauszufinden, wie viele Tester am besten für das Projekt 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 sich selbst als scrum / agil bezeichnen .


9

Nun, wir hatten zwei Entwickler im Quertest, nachdem der erste einige Änderungen an einem Eingabebildschirm vorgenommen hatte. Dies war der Zeitpunkt, an dem unser normaler Tester in Mutterschaftsurlaub war.

Er änderte im Grunde einen Rechnungslistenbildschirm, den die Benutzer verwendeten, um Rechnungen auszuwählen, bevor sie zoomten, um über eine Schaltfläche "Bearbeiten" etwas zu bearbeiten. Die ursprüngliche Liste wurde verworfen und eine neue Rasteransicht eingefügt, mit Filtern, Gruppieren, Sortieren und allen möglichen coolen Funktionen.

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

Es stellte sich heraus, dass der Entwickler das Kontrollkästchen (zur Auswahl) und die Schaltfläche "Bearbeiten" deaktiviert hat. Da die Entwickler ohnehin immer doppelt geklickt haben, um ein Element auszuwählen, hat keiner von ihnen einen Fehler gefunden.

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


3
Ich würde nicht sagen, dass sie in verschiedenen Welten leben, aber die Leute haben Gewohnheiten und der Code eines Entwicklers funktioniert, wenn er von jemandem mit derselben Gewohnheit verwendet wird. Ich kann nicht zählen, wie oft ich einen von einem Tester gefundenen Fehler nicht reproduzieren konnte, sah über seine Schulter, während er den Fehler reproduzierte, und sagte: "Wow, ich hätte niemals getan, was du gerade getan hast."
gnasher729

4

Wie andere hier bereits gesagt haben, können die Entwickler den Code der jeweils anderen Gegenüber testen (Unit- oder Funktionstests), und möglicherweise kann Ihr Scrum-Master und Produktbesitzer beim Integrationstest helfen. Für die Benutzerakzeptanztests sollten Sie jedoch sicherstellen, dass Sie den Code erhalten Viele Rückmeldungen aus den Tests des Kunden - dies bedeutet, dass er häufig so eingesetzt werden kann, wie es echte Benutzer tun, und über einen wirklich offenen Kommunikationskanal verfügt .


2

Sie sollten auf Testbarkeit achten, aber wenn Sie keinen speziellen Tester haben, gehen einige Dinge einfach durch die Lücken, da nicht genügend Stunden zur Verfügung stehen, um Software zu entwerfen, zu implementieren und zu testen.


2

Das Testen von Software ist ein Vollzeitberuf. 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 ist, 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 keine Fehler finden möchte .


1

Ich stimme ihrem Standpunkt zu, dass die Entwickler / Designer ihren Code testen sollten, mit der Begründung, dass der Designer / Entwickler, der einen Codeabschnitt erstellt hat, nicht der einzige Satz von "Augen" für diesen Code ist, bevor er sich zum Leben verpflichtet. Dies ist zwar nicht alles, hilft aber zumindest dabei, die Blindheit zu vermeiden, die sich beim Testen und erneuten Testen des eigenen Codes während der Entwicklung einschleicht.

Von der Erwähnung des Anwendungsfalls gehe ich davon aus, dass Sie auch Code-Coverage-Tools verwenden? Andernfalls kann es hilfreich sein, festzustellen, welcher Code möglicherweise nicht getestet wurde, und unter bestimmten Bedingungen kann es zu unerwarteten Fehlern kommen.

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, die dazu beitragen würde, die Rollen aller ein bisschen mehr zu fokussieren, und sie könnten auch sehen, ob es irgendwelche Muster dafür gibt wird vermisst, und was noch wichtiger ist, wie man es behebt.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.