Wie kann man Unit-Tests mit einem kleinen Scrum-Team implementieren, ohne die Hälfte der Sprint-Unit-Testing-Geschichten aufzuwenden?

Meine Entwickler sind nicht an Unit-Testing-Frameworks gewöhnt und lernen noch

Dies wird sich im Laufe der Zeit verbessern, wenn sie mehr Erfahrung sammeln.

Es gibt nur 2 von ihnen und jeder mit seiner Spezialität (Front-End und Back-End), sodass sie sowohl die Codierung als auch die Komponententests für ihre Seite der Geschichten durchführen müssen.

Das ist absolut normal. Wer sonst würde Tests schreiben? Selbst wenn Sie jemand anderen zum Schreiben von Tests hätten, müssten Sie ihn wahrscheinlich zum gleichen Satz wie die Entwickler einstellen und bezahlen. Tests erscheinen nicht auf magische Weise.

Dies hat dazu geführt, dass wir Sprints nicht bestanden haben, weil Unit-Tests am Ende so lange dauern, dass die Stories nicht vor dem Ende des Sprints fertig sind.

Ja. Ihre Schätzungen liegen völlig daneben, denn Sie haben bisher keine funktionierende, produktionsreife Software geliefert, Sie haben halbwegs getestete Prototypen geliefert. Und das ist gut für Prototypen, das sind sie: nicht serienreif. Das ist der Sinn eines Prototyps, etwas in Gang zu bringen, sich nicht in Details zu verlieren, zu zeigen, dass ein Konzept umsetzbar ist. Aber jetzt müssen Sie Software in Produktionsqualität liefern. Und das dauert länger als Prototypen. Es gibt wenig, was Sie tun können. Verbessern Sie Ihre Schätzungen, um dies zu berücksichtigen, damit Sie bei Sprints nicht scheitern.

Aber wenn Ihr Team nicht genug in der von Ihnen benötigten Qualität produziert, gibt es keine Wunderwaffe. Sie brauchen mehr Leute. Stellen Sie einen weiteren Frontend-Entwickler und Backend-Entwickler ein. Die Produktion von produktionsreifer Software anstelle von Prototypen ist leicht die doppelte Arbeit.

Auch wenn Sie nicht gefragt haben: Wenn Sie mehr Leute einstellen, haben Sie die Chance, Ihre Prozesse zu verbessern. Wenn Sie einen Frontend-Entwickler und einen Backend-Entwickler haben, die jeweils Kenntnisse über ihre Domäne haben, gibt es ungefähr keine Option für Teamarbeit. Ich meine sicher, Backend und Frontend müssen miteinander reden, aber das ist nicht die Teamarbeit, von der ich spreche. Es gibt niemanden, der mit dem Backend hilft, wenn sie stecken bleiben. Es gibt niemanden zu fragen, wenn das Frontend bei einem Problem hängen bleibt. Im Moment haben Sie kein Team, Sie haben ein Fließband. Sie brauchen mehr Leute mit demselben Spezialgebiet, damit sie sich gegenseitig helfen und als Team arbeiten können. Sie müssen in der Lage sein, zu kompensieren, wenn einer von ihnen eine Woche Urlaub hat oder sich krank melden muss. Sie müssen Ihr Team auf Produktionsgröße bringen. Als erster Schritt zu einem minimalen, Barebones-Team könnten Sie einen Full-Stack-Entwickler einstellen, der bei einem Teil oder dem Projekt helfen kann. Besser wäre von jeder Rolle eine mehr. Scrum funktioniert nicht sehr gut mit einem Zwei-Personen-Team.

TL;DR

Das eigentliche Problem dabei ist, dass Ihr Unternehmen die Testkosten als unerwünschten Overhead und nicht als erwartete und notwendige Kosten für die Geschäftstätigkeit für Produktentwicklung, Wartung und Support betrachtet. Konzentrieren Sie sich darauf, das zu beheben.

Analyse und Empfehlungen für das Reframing

Hätten Sie Tipps, wie Sie diesen Prozess verbessern können, damit das Testen rationalisierter/schneller ist?

TDD und BDD sind keine "schneller gehen"-Tasten. Während Teams im Laufe der Zeit beim Testen oft etwas effizienter werden, sind die Ziele des Testens enger ausgerichtet an :

1. Reduzierung der technischen Schulden.
2. Eliminierung bestimmter Klassen häufiger oder vorhersehbarer Fehler.
3. Erstellen einer ausführbaren Dokumentation.
4. Code durch emergentes Design und umfassende Regressionstests flexibler machen.
5. Vereinfachen Sie Tests, Support und Wartung, indem Sie den Code zum Testen und Debuggen von vornherein entwerfen.

Während diese Dinge das Hinzufügen neuer Funktionen oder das Finden/Beheben von Fehlern in der Zukunft einfacher machen, beschleunigen sie die aktuelle Entwicklung normalerweise nicht. Tatsächlich führt das Refactoring (oder schlimmer noch, das Redesign) von Code für die Testbarkeit unweigerlich zu kurzfristigem Widerstand und langfristigem Overhead. Darüber hinaus erfordert es Zeit und Mühe, alle mit neuen Werkzeugen und Techniken vertraut zu machen, und verbraucht per Definition Teamkapazität.

Hier gilt es einiges zu beachten:

• Sie zahlen die Testkosten so oder so, entweder als Overhead während der Entwicklung oder als spätere Wartungsprobleme. Sie können sie genauso gut im Voraus bezahlen, da diese Kosten fast unvermeidlich sind.
• Unabhängig davon, ob Sie die Kosten in TDD/BDD bezahlen oder sie durch technische Schulden belasten lassen, sollten alle Kosten (einschließlich der Testkosten) dem Projekt sichtbar angerechnet werden. In Scrum tun Sie dies, indem Sie TDD/BDD zur Definition of Done hinzufügen und in Ihre Product-Backlog-Schätzungen einbacken.

Beachten Sie, dass es in vielen agilen Frameworks auch vollkommen akzeptabel ist, architektonische Runway- Elemente direkt zum Product Backlog hinzuzufügen . Da Sie gerade dabei sind, einen neuen Testansatz zu übernehmen, kann und sollte die Arbeit im Zusammenhang mit Werkzeugen, Schulungen und anderem Overhead, die sonst nicht einem typischen Feature zugeordnet werden können, vom Product Owner im Product Backlog priorisiert werden . Dadurch wird sichergestellt, dass diese notwendige Arbeit als geplante Arbeit und nicht als unerwarteter oder unerwünschter Mehraufwand behandelt wird. Bei Verwendung dieses Ansatzes werden architektonische Start- und Landebahn- und Testaktivitäten ordnungsgemäß als Geschäftskosten behandelt.

Um zu wiederholen, was die anderen angedeutet haben:

Testen ist kein notwendiges Übel.

Das Testen ist eine entscheidende Komponente bei der Bereitstellung hochwertiger (oder zumindest funktionierender) Software.

Denken Sie daran, dass Sie nur eine Chance haben, einen ersten Eindruck zu hinterlassen, und die Bereitstellung fehlerhafter Software Ihren Ruf zerstört.

Um Ihre Frage zu beantworten: Sie müssen mehr Zeit für das Testen einplanen – und noch mehr Zeit für das Beheben von Fehlern, die entdeckt werden, sobald das Testen beginnt.

Um "diesen Prozess zu verbessern, damit das Testen rationalisierter/schneller ist", stellen Sie das Testen in den Mittelpunkt und nicht eine Bestrafung, die nach der Planung hinzugefügt wird.

Also, wie gehen Sie vor?

Sie erwähnen, dass Ihre Geschichten groß sind und nicht geschrumpft werden können. Möglicherweise benötigen Sie die Hilfe eines erfahrenen technischen Projektmanagers, um Ihrem Team zu erklären, wie Sie die Stories verkleinern können .

Große Storys = große Code-Blöcke = größere Wahrscheinlichkeit von Fehlern = schwieriger zu beheben.

Ein erfahrener (Ex-)Programmierer/PjM zeigt Ihrem Team, wie Sie Ihre Geschichten in überschaubare Bits (oder Bytes) verkleinern können.

Beispielsweise würden Techniken wie Stubbing verwendet werden; Während Sie fortschreiten, verwandeln Sie jeden Stub in echten Code. Aber inzwischen haben Sie viele kleine Geschichten – eine pro Funktion – die codiert und einheitengetestet und sogar von Experten begutachtet werden können, da sie mit einer einzigen Funktion eine überschaubare Größe haben.

Und es wird nicht länger dauern - es wird wahrscheinlich die Zeitleiste verkürzen, da mehr Zeit in die Planung des Codes investiert wird, bevor er geschrieben wird.