Wir verbringen mehr Zeit mit der Implementierung von Funktionstests als mit der Implementierung des Systems selbst. Ist das normal?

12

Grundsätzlich haben wir drei Hauptprojekte, von denen zwei Webdienste und das andere eine Webanwendung sind. Während ich damit zufrieden bin, so viel wie möglich von unseren Webservices durch Funktionstests abzudecken (alle drei Projekte haben ihre richtigen Komponententests), brauchen Funktionstests für die Webanwendung viel Zeit für die Implementierung durch Entwickler. Mit viel meine ich zwei Mal oder manchmal mehr die Zeit, die benötigt wird, um die getestete Funktionalität mit eingeschlossenem Komponententest zu implementieren.

Die Managerrichtlinie besteht darin, jede einzelne von uns hinzugefügte Funktionalität zu testen, auch wenn dies nicht geschäftskritisch ist (dh eine neue CRUD).

Ich bin damit einverstanden, alle Webservices-Funktionen zu testen, da es schwierig ist, sie manuell zu testen. Außerdem laufen diese Tests schnell und erfordern nicht viel Implementierung.

Was nützt es also, mehr Zeit mit dem Schreiben von Funktionstests zu verbringen als mit dem Schreiben von Systemcode, dem Komponententest und dem Reparieren von QA-Tikets? Ist das normal? Sollten wir nicht Funktionstests nur für kritische Funktionen schreiben und QA Regressionstests für keine kritischen Funktionen durchführen lassen?

Hinweis: Wir entwickeln keine medizinische Software oder NASA-Software oder nichts so Kritisches.

Pablo Lascano
quelle
14
Wir haben keine Tests. Wir verbringen eine enorme Menge Zeit damit, Dinge nachträglich zu reparieren. "Sie können mich jetzt bezahlen, oder Sie können mich später bezahlen." Es ist später und es ist nicht schön.
MetalMikester
3
Ja - ein Teil des Bildes ist definitiv, dass eine gut gepflegte Testsuite die für die eigentliche Implementierung benötigte Zeit verkürzt.
Michael Borgwardt

Antworten:

16

Funktionstests sind sehr wichtig. Ja, sie brauchen Zeit zum Schreiben, aber wenn Sie die richtigen Funktionstests schreiben, werden sie sich mehr als lohnen.

Es gibt einige gute Gründe, automatisierte Funktionstests für eine Anwendung durchzuführen.

  • Wenn eine neue Funktion zu Ihrer Website hinzugefügt wird, werden Sie sofort informiert, wenn Änderungen an dieser neuen Funktion andere Funktionen auf Ihrer Website beeinträchtigen.
  • Es ist dokumentiertes Wissen darüber, wie die Anwendung ausgeführt wird und wie sie zusammenarbeitet, um die Geschäftsanforderungen zu erfüllen.
  • Wenn eine Bibliothek eines Drittanbieters aktualisiert werden muss, können Sie diese aktualisieren und Ihre Funktionstestsuite ausführen, um festzustellen, ob Probleme auftreten. Anstatt jede Seite selbst durchgehen zu müssen, können Sie sich von einem Computer eine Liste aller durchgebrochenen Tests erstellen lassen.
  • Belastungstest! Sie können Tausende gleichzeitiger Benutzer simulieren, die alle gleichzeitig auf Ihre Website zugreifen, und Sie können sehen, wo Ihre Website langsamer wird und sich unter dem Druck verbiegt. Sie können sehen, wie sich Ihre Website verhält, lange bevor Sie spät abends einen Anruf erhalten, bei dem die Website abgestürzt ist.
  • Die manuelle Durchführung von Funktionstests erfordert Zeit. Ja, das Schreiben der Fälle dauert lange, aber wenn Sie sich mit einem Binder mit 500 Seiten an Tests hinsetzen müssten, bevor Sie das Produkt versenden könnten, hätten Sie sich die automatisierten Tests gewünscht!
  • Testdokumente sind schnell veraltet. Wenn eine neue Funktion hinzugefügt wird, müssen Sie sicherstellen, dass das Haupttestdokument aktualisiert wird. Wenn jemand einige Tests überspringt, kriechen plötzlich Bugs in Seiten, die "fertig und getestet" sind. Momentan arbeite ich in einer solchen Umgebung und ich kann Ihnen versichern, dass dies ein Albtraum ist.

Letztendlich braucht es ja Zeit, um diese Fälle zu schreiben, aber Sie sollten stolz darauf sein, sie zu schreiben. Dies ist Ihre Art zu beweisen, dass Ihr Code zweifelsohne funktioniert und dass er mit allen anderen Funktionen funktioniert. Wenn QA zu Ihnen kommt und einen Fehler meldet, beheben Sie diesen und fügen ihn Ihrer Testsuite hinzu, um zu zeigen, dass er behoben ist, und um sicherzustellen, dass er nie wieder auftritt.

Es ist dein Sicherheitsnetz. Wenn jemand hereinkommt und einen gespeicherten Prozess überfällt und eine kleine Änderung vornimmt, damit er mit seinem Code funktioniert, stellen Sie fest, dass er drei andere Funktionen in diesem Prozess nicht mehr unterstützt. Sie werden es in dieser Nacht und nicht in der Nacht vor dem Abgabetermin fangen!

Wie zum Schreiben von Funktionstests für nur systemkritische Funktionen. Das gibt dir nicht das ganze Bild und es wird ermöglichen, dass sich Bugs durchschleichen. Es ist nur eine kleine Funktion erforderlich, die nicht systemkritisch ist, sondern indirekt mit einer systemkritischen Funktion interagiert, und es besteht die Möglichkeit, dass ein Fehler auftritt.

Tyanna
quelle
Danke für deine Antwort. Ich bin mir der Wichtigkeit und des Nutzens von Funktionstests bewusst, meine Bedenken beziehen sich auf das Kosten-Nutzen-Verhältnis beim Testen von ALL. Wir haben in den letzten drei Jahren einen Funktionstest entwickelt, aber jetzt in diesem Projekt sind die Kosten für die Implementierung von Test ALL weitaus höher als das Auffinden eines Fehlers in der Produktion, das Erhöhen eines Tickets und das Beheben eines Fehlers ... Ich frage mich, ob Es gibt einige Umstände, in denen es besser ist, KEINE Funktionsprüfung durchzuführen (in Bezug auf das Kosten-Nutzen-Verhältnis), als sie nicht durchzuführen, und ich frage mich, ob wir unter solchen Umständen besser wählen können, was mit Bedacht geprüft werden soll.
Pablo Lascano
@donsenior ~ Wenn der Test zu lange dauert, schauen Sie sich die verwendeten Tools an. Benutzt du sie richtig? Verwenden Sie überhaupt zeitsparende Tools? Das Schreiben von Tests dauert länger als das Schreiben des Codes b / c, für den Sie mehr Code schreiben müssen. Das ist die Natur des Testens. Wenn Sie anfangen, Tests auszuwählen und auszuwählen, für die Tests geschrieben werden sollen, wird es zu dem Punkt kommen, an dem niemand Tests schreiben wird, oder diese Tests werden schlampig sein.
Tyanna
Meine Idee für die Auswahl der zu testenden Komponenten ist keine zufällige Auswahl, sondern die Auswahl der wichtigsten Geschäftsfunktionen (und dies wäre nicht die Entscheidung der Entwickler, sondern die des Managers). Und ich denke genau das Gegenteil: Entwickler neigen dazu, jetzt schlampige Tests zu schreiben, weil sie alle testen müssen, selbst die Funktionalität, deren Test fünf Minuten und deren Automatisierung zwei Tage dauert. Ich bin damit einverstanden, dass die von uns verwendeten Tools möglicherweise nicht die besten sind, um unsere Web-App (Fitness und Java) zu testen. Ich fürchte, wir nähern uns dem Punkt des Schreibens und der Aufrechterhaltung des Funktionstests mehr als das System
Pablo Lascano
@donsenior ~ Sicher, es dauert 5 Minuten, um einen Fall zu testen, aber ein Computer benötigt weniger als eine Sekunde, um ihn zu testen. Sie sollten sich fragen: "Warum dauert es 2 Tage, um etwas zu schreiben, das 5 Minuten braucht, um von Hand getestet zu werden?" Schauen Sie sich noch einmal Ihre Werkzeuge an. Vielleicht sollte QA auch einige Testfälle schreiben? Das Problem besteht nicht darin, Testfälle für Ihr System zu schreiben, sondern darin, wie diese Testfälle geschrieben werden.
Tyanna
Nun, dieser Test dauert viel länger als eine Sekunde (denken Sie daran, dies sind Funktionstests, keine Komponententests). Aber das ist kein Problem, sie rennen nachts. Ich denke, Sie haben Recht, dass die Qualitätssicherung auch einige Testfälle schreiben sollte, aber leider ist das keine Entscheidung, die ich treffen kann. Vielen Dank für Ihre Antworten, ich habe diese als akzeptiert markiert!
Pablo Lascano
7

Mehr als 2 Mal ... scheint mir ein bisschen viel zu sein. Vielleicht möchten Sie die Gründe dafür analysieren. Dazu gehören:

  • Schlechte Werkzeugunterstützung für die Erstellung und Pflege der Tests

  • Verträge der Webservices werden im Design nicht ausreichend beschrieben. Entwickler müssen die Verträge während des Testens ausarbeiten, was normalerweise ein zeitaufwändiger Ausrichtungsprozess ist.

Sprechen Sie mit Ihren Entwicklern.

Angenommen, Sie entwickeln sich in Sprints und haben diese Funktionstests nur als Teil des Sprints. Ohne diese Tests geht es nicht. Wenn Sie es nicht haben, kann sich Ihre Zeit für Integrationstests nach der Entwicklungsphase verdoppeln.

Andreas Huppert
quelle
Ich stimme zu, vielleicht verwenden wir nicht das richtige Tool zum Testen der Web-App. Kein Problem beim Testen unserer Webservices. Abgesehen davon, ob wir die Tests richtig oder falsch durchführen, mache ich mir Sorgen über die Kosten. Ich denke, dass es an diesem Punkt (in Bezug auf Kosten / Nutzen) besser ist, einige Tests für die QA-Abteilung durchführen zu lassen und die Fehler zu beheben, selbst wenn sie in der Produktion gefunden werden.
Pablo Lascano
Sie haben schlecht gestaltete Klassen als möglichen Grund für zu lange Testzeiten ausgelassen. Dies ist bei weitem der häufigste Grund, aus dem ich sehe, dass die Leute ständig ihren Code testen müssen.
Dunk
4

Ist es normal, mehr Zeit mit der Implementierung von Funktionstests zu verbringen als mit der Implementierung des Systems selbst?

Absolut. Das Schreiben wirklich guter Tests wird in vielen (guten) Läden die meiste Zeit in Anspruch nehmen.
Ein Verhältnis von 2: 1 ist also in Ordnung. Weniger erfahrene Entwickler berücksichtigen oft nicht die gesamte Testzeit.

Michael Durrant
quelle
2

Es gibt das Gesetz der sinkenden Rendite. Angenommen, Sie schreiben zuerst Tests für den riskantesten Code, dann nimmt der Wert, der durch weitere Tests generiert wird, mit der Zeit ab.

Unit-Tests sind Code und enthalten daher Fehler (genau wie alle anderen Codes). Das Beheben dieser Fehler nimmt Zeit in Anspruch.

Meiner Erfahrung nach enthalten Unit-Tests weit mehr Fehler als das System, das sie testen, und die Behebung dieser ist eine ständige Belastung.


quelle
1

Hier geht es um Qualität.

Wenn Sie den Markt erobern möchten, entwickeln Sie Ihre App so schnell wie möglich. Sie können sogar überhaupt keine automatischen Tests durchführen =), aber Sie geben Ihre App Ihrem Publikum vor Ihren Konkurrenten.

Aber wenn Sie wissen, dass Ihr Gehör nicht verschwindet, werden Sie alles tun, um sie nicht zu enttäuschen. Jedes Fehlerticket beeinträchtigt Ihren Ruf. Stellen Sie sich vor, ein Fehler beseitigt 50 Prozent Ihres Rufs, der andere 25 Prozent und so weiter. Kann es also zu viele Tests geben?

Nikita U.
quelle
Nun, ich bin mir nicht sicher, ob wir zu diesem Zeitpunkt tatsächlich Tickets reduzieren. Vielleicht haben wir weniger (aber nicht viel) QA-Tickets, aber die Anzahl der Fehler, die bei diesem Test gefunden wurden, ist (aus meiner Sicht) nicht groß genug, um diese Kosten zu rechtfertigen, wenn zwei Drittel der Softwareentwickler Funktionstests entwickeln.
Pablo Lascano
0

Wenn Sie mit "ist es normal" fragen, ob es üblich ist, nein, das ist es sicherlich nicht. Viele Entwicklerteams haben schlechte Testpraktiken (ich gehöre zu einem) und sogar Qualitätsbücher, die ich gelesen habe, raten dazu, ungefähr so ​​viel Zeit mit der Programmierung der Funktionalität zu verbringen wie mit den Tests. Wenn Sie normalerweise fragen, ob es gesund ist, hängt es davon ab, aber zweimal mehr Tests als nötig sind besser als kein Test.

Es muss nicht kritisch sein . Wenn Sie eine Funktion testen, testen Sie etwas Nützliches für Endbenutzer, und es liegt in Ihrer Verantwortung, zu wissen (und nicht zu raten), dass es immer richtig funktioniert. Wenn Sie für dieses Ziel zweimal mehr benötigen, sollten Sie dies tun - wenn möglich.

Es ist auch möglich, dass Ihre Richtlinien in Bezug auf automatisierte Tests zu streng sind, aber es ist schwer zu sagen, ohne zu wissen, welche Qualität sie anstreben, welche Ressourcen sie verwenden und wofür sie sie sonst verwenden könnten.

Arthur Havlicek
quelle