Ich habe mit einigen XP-Konzepten experimentiert, wie folgt:
Soweit so gut, bis ich einen großen Stumpf hatte:
Wie gestalte ich meine Testfälle, wenn noch kein Code vorhanden ist? Auf welcher Grundlage muss ich sie entwerfen? Von einfachen Annahmen? Von den ersten Anforderungen?
Oder passt UML-Diagramme und die "Analysephase"?
Ich musste nur fragen, denn in einigen XP-Büchern, die ich gelesen habe, gab es wenig bis gar keine Diskussion über ein Diagramm-Werkzeug (es gab eines, das mir Pseudo-Codes und eine Art Flussdiagramm vorschlug ... aber das tat es hilf mir nicht beim Schreiben meiner Tests)
Agile Prozesse sind oft papierbasiert, aber dies macht einige Grundannahmen, die in einer Unternehmensumgebung möglicherweise nicht zutreffen.
Auch wenn Ihr Team verteilt ist, können Sie immer noch Stifte und Papier (mit einem Farbscanner) oder ein Whiteboard (mit einer billigen Digitalkamera) verwenden. Das Erfassen der Bilder auf diese Weise kann agiler sein als der Versuch, speziellere Softwaretools zu verwenden, da Sie sich eher darauf konzentrieren, das Problem zu lösen, als das Werkzeug zu steuern oder die visuelle Darstellung zu optimieren.
Wie gestalte ich meine Testfälle, wenn noch kein Code vorhanden ist? Auf welcher Grundlage muss ich sie entwerfen? Von einfachen Annahmen? Von den ersten Anforderungen?
Sie beginnen mit der User Story, die von den anfänglichen Anforderungen und Diskussionen mit dem "Kunden vor Ort" abhängt, wenn Sie das Glück haben, einen zu haben.
Die Idee ist, dass Sie den Test vor dem Code schreiben, damit Sie wissen, wann Sie fertig sind. Der Code wird möglicherweise nicht korrekt ausgeführt oder kompiliert, von dem Punkt an, an dem Sie mit dem Schreiben des Tests beginnen, bis zu dem Punkt, an dem der Test ausgeführt und übergeben wird. Dies ist vergleichbar mit der traditionellen "Test-Leisten" -Entwicklung, mit der Ausnahme, dass die Zeit, in der der Code unterbrochen wird, kürzer ist und Sie am Ende einen Test haben werden.
Es verändert die Art und Weise, in der die Entwicklung von "Was soll ich als nächstes schreiben?" zu "Welche Prüfung soll ich als nächstes schreiben?". Die zweite Frage ist einfacher zu beantworten, solange Sie eine Grundidee davon haben, was Sie tun möchten.
Wie gestalte ich meine Testfälle wann? Es gibt noch keinen Code? Von was Basis muss ich sie entwerfen? Von einfache Annahmen? Von Anfang an Anforderungen?
Um einen Test zu schreiben, benötigen Sie keinen Code. Sie kennen Ihre Eingaben und kennen Ihre erwarteten Ergebnisse. So können Sie einen Testfall entwerfen, um es zu implementieren.
Ich sehe keine enge Beziehung zwischen UML-Sachen und XP. UML ist für das Design der Software und XP ist der Prozess, den Sie befolgen, um diese Software zu entwickeln. Also bitte klären Sie die Frage wenn möglich.
Die Testfälle stammen aus den ersten Anforderungen. Sie spezifizieren, was Sie bauen werden, also wo sonst würden die Tests herkommen?
Eine Technik, die Sie vielleicht hilfreich finden, ist ein Feature zu nehmen und es in drei Elemente aufzuteilen: Gegeben, Wann, Dann. Gegeben sind die Anfangsdaten, Wenn der Programmaufruf ist, Dann ist das gewünschte Ergebnis. Der Punkt ist, dass jede Anforderung, die Sie nicht so analysieren können, möglicherweise nicht korrekt ist, oder zumindest weitere Details benötigt.
Das Google-Testteam schätzt diesen Ansatz sehr und hat ausführlich darüber gebloggt. Erfahren Sie mehr.
XP hat keine "Analysephasen".
Sie müssen kein Diagrammwerkzeug mit XP verwenden , obwohl Sie nichts daran hindern können, eines davon zu verwenden.
Was möchten Sie modellieren?
Es klingt so, als ob Sie die Problemdomäne (d. h. Modellierung zur Analyse) beschreiben möchten, anstatt die Implementierung zu dokumentieren. XP funktioniert nicht wie herkömmliche Methoden, wo ein Spezialist "Analyse" und ein anderer "Codierung" durchführt. In XP ist es wahrscheinlich, dass der Analyst ein Entwickler ist, der mit jemandem im Unternehmen zusammenarbeitet, um User Storys zu analysieren und zu bewerten.
Sie beginnen normalerweise nicht mit der Dokumentation von Testfällen - wir schreiben automatisierte Tests in Code, entweder in Code oder in einer ausführbaren Spezifikation wie mit JBehave oder Gurke. Es ist so viel Aufwand wie sie zu zeichnen, aber mit einem viel besseren Return on Investment.
Tags und Links agile methodology extreme-programming