Projektarbeit / Testphase - Ist ein Integrationstest ausreichend?

[Pennytüte]

Moin,

hab eine Testphase nach der Implementierungsphase geplant, meint ihr ein Integrationstest (manuell nach einem selbsterstelltem Testprotokoll) ist ausreichend? Vorschläge?

Info: Benutze das erweiterte Wasserfallmodell. Würde ich bei allen Punkten der Implementierung, einen Test inkludieren, was nach meinem Verständnis normal ist, würde es ein agiles Vorgehensmodell sein wurde mir gesagt. Ok, wäre dann agil mit fest definierten Stufen wie bei dem Wasserfallmodell, oder was? Macht mich irgendwie kirre dieses strikte Benamen und sollte die Entwicklung denn nicht immer einen agilen Ansatz haben?

[stefan.macke]

Wer sagt denn, dass du strikt nach Wasserfall oder "agil" (übrigens ein sehr schwammiger Begriff für eine Doku!) entwickeln musst? Du kannst durchaus eine sinnvolle Anpassung an deinem Prozess vornehmen (in deinem Fall Tests ergänzen), wenn es dir sinnvoll erscheint und du das gut begründest.

[Rienne]

Hallo,

vor 6 Stunden schrieb Pennytüte:

hab eine Testphase nach der Implementierungsphase geplant, meint ihr ein Integrationstest (manuell nach einem selbsterstelltem Testprotokoll) ist ausreichend? Vorschläge?

ich kenne dein Projekt nicht, aber sollte man vor dem Integrationstest nicht erst einmal Modultests machen und schauen ob die einzelnen Komponenten für sich selber funktionieren bevor man das Zusammenspiel aller Komponenten testet?

vor 6 Stunden schrieb Pennytüte:

Benutze das erweiterte Wasserfallmodell. Würde ich bei allen Punkten der Implementierung, einen Test inkludieren, was nach meinem Verständnis normal ist, würde es ein agiles Vorgehensmodell sein wurde mir gesagt.

Agile Softwareentwicklung beinhaltet für mein Verständnis wesentlich mehr als das Testen.

Allerdings spricht der Rahmen eines IHK Projekts für mein Verständnis schon sehr gegen eine agile Entwicklung - ich meine du hast einen festen Zeitrahmen und sollst das Projekt alleine planen und durchführen. Das ist beispielsweise für Scrum schon ein KO-Kriterium, da du ja nicht Product Owner und Entwicklungsteam in einer Person vereinen darfst.

Und dass man seinen Code auch schon während man ihn schreibt oder direkt danach testet, ist vermutlich auch normal. Die meisten IDEs geben einem ja auch direktes Feedback zu Fehlern beim Tippen.

Und es ist ja auch meist so, dass man den Code auch kompilieren muss und da kommt es ja nicht selten zu Fehlermeldungen - ist ja auch eine Art Test.

 

Ich glaube das Wichtigste an deinem Projekt wird auch nicht sein, dich fest an ein Vorgehensmodell zu klammern, sondern deine Entscheidungen begründen zu können. Du kannst ja sagen, dass du dich am erweiterten Wasserfallmodell orientiert hast, du es aber für wichtig erachtet hast schon an Stelle x/y zu testen, weil "bla".

 

Liebe Grüße

Rienne

[Pennytüte]

Hi.

Zu dem Wasserfallmodell:

Also mir wurde halt gesagt, das schon die Tatsache, wenn ich z.B. "Implementierung der Dateneingabe inkl. Tests" bei der "Implementierungsphase" angebe, sei das halt kein erweitertes Wasserfallmodell mehr, da "Implementierung einer Funktion" und "Tests" ja getrennt sein müsste, wegen der klar definierten Schritte in einem Wasserfallmodell.

Wir kamen nach Beratschlagung dann zu dem Schluss , dass das was ich meinte ja eigentlich nur das normale Debuggen ist, während der Programmierung, ob denn das Programmierte auch funktioniert wie vorgesehen und das müsste man halt nicht extra erwähnen.

Ich werde mich wohl eingehender mit agilen Vorgehensmodellen beschäftigen müssen, auch für mich persönlich, aber im hypothetischem Fall, dass wenn ich nun ein agiles Vorgehensmodell wählen würde, dann müsste ich das nat. auch genauer beschreiben und wir haben eigentlich im Großen und Ganzen gerade Mal, V Modell, Wasserfallmodell und SCRUM behandelt. Habe da mal reingesehen in Wikipedia und da müsste ich mich ja schon intensiver mit befassen um die agilen Vorgehensmodelle alle unterscheiden zu können?!?

 

Nebenbei:

Nun hab' ich die Tage zum ersten Mal von TDD gehört, mir waren Unit Tests (der Begriff) bereits bekannt, da bei meinem früherem Arbeitgeber solche im Nachhinein zur Kontrolle der Azubis angefertigt wurden (mit MTM und Einbindung in VS, TFS).

Erkenne definitiv den "Muss" Aspekt von TDD, muss mich da aber noch genauer mit beschäftigen. Da sind noch einige Ungereimtheiten aus den ganzen Tutorials und Webcasts (Youtube), vor allem "Unit Tests ohne TDD". Versteh' noch nicht ganz, warum viele sagen, dass sei so nicht sinnvoll. Ich versteh' das es ein Schemata der Programmierung mit TDD gibt und das dadurch endlose Vorteile entstehen, aber nicht warum das im Nachhinein nicht genauso sinnvoll sein kann (abgesehen von den Negativ Punkten wie: Zeitlicher Mehraufwand, nicht so guter/ simpler Code. etc.). Ist ja doch auch schon etwas umfangreicher das Thema in Verbindung mit einem Test Framework und einem Mocking Framework.

 

Fragen zu Begrifflichkeiten und Testphasen (wahrscheinlich auch im Kontext zu oben genanntem, da noch viel Lernbedarf besteht):

Projekt soll eine Desktop Anwendung werden inkl. Datenbank!

1. Wenn ich nun nach der Implementierungsphase eine Testphase plane, welche Tests wären denn da angebracht?

2. Geplant habe ich nun "Manueller Test" (Verhalten und Daten der Anwendung im Gebrauch, nach einem Testplan, den ich in der Entwurfsphase erstelle) und "Systemtest" (Software nach Installation). Das scheint mir von den Tests an sich und von den Begrifflichkeiten her am sinnvollsten, da das wenig Interpretationsspielraum lässt, denke ich zumindest.

Im Grunde ist das ja schon das testen der Units und der Integration (White Box u. Blackbox), aber diese sind ja offiziell automatisiert, also nenne ich das "Manuelle Tests"?!?

3. Systemtest oder Softwaretest beschreibt das Gleiche und muss nat. vor Abnahme des Auftraggebers getestet werden?

 

Sorry, hoffe das ist jetzt alles nicht zu konfus

Bearbeitet 14. September 2016 von Pennytüte

[Whiz-zarD]

vor 19 Minuten schrieb Pennytüte:

schäftigen. Da sind noch einige Ungereimtheiten aus den ganzen Tutorials und Webcasts (Youtube), vor allem "Unit Tests ohne TDD". Versteh' noch nicht ganz, warum viele sagen, dass sei so nicht sinnvoll. Ich versteh' das es ein Schemata der Programmierung mit TDD gibt und das dadurch endlose Vorteile entstehen, aber nicht warum das im Nachhinein nicht genauso sinnvoll sein kann (abgesehen von den Negativ Punkten wie: Zeitlicher Mehraufwand, nicht so guter/ simpler Code. etc.). Ist ja doch auch schon etwas umfangreicher das Thema in Verbindung mit einem Test Framework und einem Mocking Framework.

Eine kleine Anekdote aus meinem Berufsleben:
In der Software, an der ich arbeite, wurde damals in der Designphase (das war weit vor meiner Zeit) einen gravierenden Fehler gemacht und zwar hat man die Geschäftsobjekte direkt mit der Persistenzschicht verdrahtet. D.h. um ein Geschäftsobjekt erzeugen zu können, brauchst du zwingend eine Datenbankverbindung. Bei so einer Architektur im nachhinein Unittests zu schreiben ist unmöglich, da man anfangen müsste, die Datenbank zu mocken.

Desweiteren wurde der Fehler gemacht, Geschäftslogik in die UI zu verlegen, weil das so schön einfach ist. Unter Visual Studio einfach ein Doppelklick auf dem Button im Designer und los gehts ... Schreibe aber mal dafür einen Unittest. Viel Spaß.

Mit TDD umgeht man diese ganzen Probleme, weil man schon vornherein gezwungen wird, den Code so zu schreiben, sodass er auch Testbar ist. Ein weiteres Problem ist, wenn man die Unittests danach schreibt, dass man eigentlich nur noch die Schnittstellen nach außen testet und das reicht oft für ein Test nicht aus. Man sieht dann zwar, dass sich ein Ergebnis ändert hat, aber wo der neue Wert herkommt, sieht man nicht. Bei TDD geht es also darum, testbaren Code zu schreiben.

vor 51 Minuten schrieb Pennytüte:

1. Wenn ich nun nach der Implementierungsphase eine Testphase plane, welche Tests wären denn da angebracht?

Unittests
Teste deine Klassen und die Methoden.

vor 52 Minuten schrieb Pennytüte:

2. Geplant habe ich nun "Manueller Test" (Verhalten und Daten der Anwendung im Gebrauch, nach einem Testplan, den ich in der Entwurfsphase erstelle) und "Systemtest" (Software nach Installation). Das scheint mir von den Tests an sich und von den Begrifflichkeiten her am sinnvollsten, da das wenig Interpretationsspielraum lässt, denke ich zumindest.

Informiere dich mal über den Begriff "Testpyramide". Manuelle Tests gilt es zu vermeiden, weil die sehr zeitaufwendig sind und Zeit ist Geld. Hier in der Firma besteht der Regressionstest hauptsächlich aus manuellen Tests (die gründe stehen weiter oben) und der Test wird pro Major-Release mit 200 - 300 PT veranschlagt. Das ist enorm. Bei uns steht die Testpyramide auch auf dem Kopf und das ist das Worst-Case-Szenario.

Manuelle Tests sind eigentlich nur noch UI-Tests und die testen nur noch den Workflow. Also dass z.B. wenn man auf Button X klickt auch Dialog Y auftaucht und dass Eingabefehler abgefangen wird aber auch diese Tests lassen sich automatisieren. Da gibt es genug Tools.

vor einer Stunde schrieb Pennytüte:

3. Systemtest oder Softwaretest beschreibt das Gleiche und muss nat. vor Abnahme des Auftraggebers getestet werden?

Tests sollten immer durchgeführt werden, bevor es zum Kunden geht. Ansonsten hast du eine Bananen-Software: Reift beim Kunden.

Aber ich persönlich sehe viele Probleme bei der Abschlussprüfung, wie die IHK es sich vorstellt. Das sind veraltete Methoden, die man heute nicht mehr anwenden sollte. Heutzutage versucht man den Kunden mit in die Entwicklung zu integrieren, sodass er für Fragen und Antworten bereitsteht und so kann man auch viel schneller auf Anpassungen reagieren (sprich agil arbeiten). 

[stefan.macke]

vor 3 Stunden schrieb Whiz-zarD:

Aber ich persönlich sehe viele Probleme bei der Abschlussprüfung, wie die IHK es sich vorstellt. Das sind veraltete Methoden, die man heute nicht mehr anwenden sollte.

Jedem Prüfling steht die Wahl seines Vorgehensmodelles völlig frei. Es werden heutzutage bereits viele Projekte "agil" (was immer das dann konkret heißen mag), mit TDD oder nach Kanban umgesetzt. Niemand ist gezwungen, veraltete Prozessmodelle zu verwenden. Und es gibt auch keine Pluspunkte für Anwendung des Wasserfallmodells

[Whiz-zarD]

vor einer Stunde schrieb stefan.macke:

Jedem Prüfling steht die Wahl seines Vorgehensmodelles völlig frei. Es werden heutzutage bereits viele Projekte "agil" (was immer das dann konkret heißen mag), mit TDD oder nach Kanban umgesetzt. Niemand ist gezwungen, veraltete Prozessmodelle zu verwenden. Und es gibt auch keine Pluspunkte für Anwendung des Wasserfallmodells

TDD heißt nicht gleich, dass Agil gearbeitet wird. Agile Softwareentwicklung ist noch was anderes. Schaut man sich das "Agile Manifesto" an, so findet man folgende Leitsätze (kopiert aus Wikipedia):

• Menschen und Interaktionen stehen über Prozessen und Werkzeugen
• Funktionierende Software steht über einer umfassenden Dokumentation
• Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung
• Reagieren auf Veränderung steht über dem Befolgen eines Plans

Und das widerspricht so allem, was die IHK von der Abschlussprüfung erwartet. Aber gut, da rege ich mich schon seit über 10 Jahren auf. Als ich damals meine Mechatroniker-Ausbildung absolviert hatte, musste ich sogar noch auf die Uhrzeit genau angeben, was ich mache ... Da ist es schon ein großer Fortschritt, dass man nur noch die Stunden angeben muss.

Kanban muss aber auch nicht unbedingt agil sein. wenn z.B. bei Kanban nicht mit dem Kunden geredet wird, sondern stur die Aufgaben von "Bereit" bis "Fertig" abgearbeitet werden, haben wir hier ebenfalls ein Wasserfallmodell.

[Pennytüte]

Hey,

danke erstmal für die interressanten Meinungen. Vorschläge sind sehr willkommen, Testpyramide guck ich sofort mal.

 

Abgabetermin für die Projektarbeit ist jetzt bis spätestens 29. diesen Monat.

Mein Projekt wird sich mit einer Mini Desktop Anwendung für Kundendaten (Daten speichern, Daten ändern, Filtern) für ein1 Mann Unternehmen befassen.

 

Zu dem Vorgehensmodell:

Zeitlich wird das jetzt nat. eng, sich jetzt noch nur wegen ein paar Details auf ein agiles Vorgehensmodell umzustellen, zu dem ja auch das Wissen über eventuelle agile Vorgensmodelle fehlt.

 

Testphasen:

Ich denke nicht, dass ich das von der Zeit her noch hinkriege (bis zum Projektzeitraum und auch von der Planung her, für den geplanten Projektzeitraum), mir noch TDD ausreichend anzueignen.

1. @Stefan, ich seh' gerade in deiner Vorlage gar keine Testphase oder seh' ich gerade den Wald vor lauter Bäumen nicht?

2. Meint ihr denn mit Unit Tests und Integrationtests tatsächlich automatisierte Tests und wenn ja, dann auch ohne TDD?

3. Mein Dozent ist irgendwie ein bisschen Wischi Waschi, wenn ich mal so sagen darf. Dem muss ich dann erst mal erklären, dass doch die Unit Tests und Integrationstest wie allgemein bekannt, automatisiert sind. Mein Güte, dachte ok, bei Manuellen Tests und System Tests werd' ich doch wenigstens ein wenig positive Resonanz kriegen?!?

(Gefällt meinem Dozenten übrigens auch nicht, die Begriffe im Zeitplan, aber weiter weiß ich jetzt natürlich auch nicht so recht).

4. Wie detailliert war denn der Zeitplan in eurem Antrag?

Ich soll ihn detailliert angeben, hatte vorher nur den Groben, also die Oberpunkte: Analysephase, Entwurfsphase etc..

Soll aber den detaillierten einfügen, da der Antrag eventuell sonst abgelehnt werden könnte.

Bearbeitet 14. September 2016 von Pennytüte

[stefan.macke]

vor 2 Stunden schrieb Whiz-zarD:

TDD heißt nicht gleich, dass Agil gearbeitet wird.

Das ist mir bekannt. Es war auch nur eine Auflistung von Beispielen: agil, TDD, Kanban, Scrum, usw. "Agil" setzte ich in Anführungszeichen, da viele Prüflinge schreiben, sie arbeiten agil, ohne zu definieren, was das eigentlich heißt. Genau wie du schreibst, gibt es ja durchaus mehrere formale Prozesse, die sich agil nennen.

vor 2 Stunden schrieb Whiz-zarD:

Und das widerspricht so allem, was die IHK von der Abschlussprüfung erwartet.

Was erwartet "die IHK" denn? Mir sind keine Vorgaben bzgl. der Projektumsetzung oder des zu verwendenden Entwicklungsprozesses bekannt. Das fände ich auch sehr seltsam, da die Technologien und Methoden ja ständigem Wandel unterliegen und diese Vorgaben damit häufig überarbeitet werden müssten.

vor 2 Stunden schrieb Whiz-zarD:

Kanban muss aber auch nicht unbedingt agil sein.

Auch das ist mir bekannt. War nur ein Beispiel! In der letzten Sommerprüfung haben in meinem Ausschuss gefühlte 50% der Prüflinge "Kanban" angewendet (wieder in Anführungszeichen, da die meisten nicht erklären konnten, was außer Karteikarten an der Wand eigentlich dahinter steckt, also z.B. WIP-Limit, Pull anstatt Push usw.)

[stefan.macke]

vor 15 Minuten schrieb Pennytüte:

Zeitlich wird das jetzt nat. eng, sich jetzt noch nur wegen ein paar Details auf ein agiles Vorgehensmodell umzustellen, zu dem ja auch das Wissen über eventuelle agile Vorgensmodelle fehlt.

Du sollst auch gar nichts umstellen, weil "das Internet" dir das rät. Du sollst einen geeigneten Prozess für dein Projekt aussuchen. Das heißt, du musst dir der Vor- und Nachteile bewusst sein und eine eigene Entscheidung treffen. Das ist Teil deiner Prüfungsleistung!

vor 15 Minuten schrieb Pennytüte:

Ich denke nicht, dass ich das von der Zeit her noch hinkriege (bis zum Projektzeitraum und auch von der Planung her, für den geplanten Projektzeitraum), mir noch TDD ausreichend anzueignen.

Das ist auch völliger Unfug. Du sollst für das Projekt nichts extra lernen, sondern etablierte Methoden und Werkzeuge einsetzen, die du beherrschst.

vor 15 Minuten schrieb Pennytüte:

1. @Stefan, ich seh' gerade in deiner Vorlage gar keine Testphase oder seh' ich gerade den Wald vor lauter Bäumen nicht?

Ich weiß gerade nicht, welche Vorlage du genau meinst (ich habe mehrere ), aber es wird immer das Thema Testing behandelt. In den letzten Projekten gab es jedoch keine explizite Testphase, da mit TDD entwickelt wurde und die (Entwickler-)Tests parallel zur Implementierung stattfanden. Dennoch wird in der Doku auf dieses Verfahren eingegangen und dir Vorteile werden erläutert bzw. begründet, warum keine ausgedehnte (manuelle) Testphase stattfand.

vor 15 Minuten schrieb Pennytüte:

2. Meint ihr denn mit Unit Tests und Integrationtests tatsächlich automatisierte Tests und wenn ja, dann auch ohne TDD?

Unit-Tests und Integrationstests müssen nicht zwangsläufig durch TDD entstehen. Aber Unit-Tests sind wohl immer automatisiert. Integrationstests hoffentlich auch, können aber auch teilautomatisiert oder manuell durchgeführt werden.

TDD ist ein Prozess, der beschreibt, WANN die Tests geschrieben werden. Er gibt nicht vor, auf welcher EBENE (z.B. Unit, Integration, System) die Tests durchgeführt werden.

Wenn dir das alles nichts sagt, empfehle ich dringend in die Prüfungsvorbereitung zum Thema Softwaretest einzusteigen!

vor 15 Minuten schrieb Pennytüte:

4. Wie detailliert war denn der Zeitplan in eurem Antrag?

Ich empfehle immer als maximale Länge für Aufgaben ein paar Stunden, Obergrenze 8h. Also alle Arbeitspakete in Aufgaben runterbrechen, die max. 1 Arbeitstag dauern. Ich betone MAXIMAL. Die meisten Punkte sollten deutlich kleiner sein (z.B. Pflichtenheft erstellen 3h, Automatischen Build einrichten 1h, Entwicklung Oberfläche 4h).

[Whiz-zarD]

vor 21 Minuten schrieb stefan.macke:

Was erwartet "die IHK" denn? Mir sind keine Vorgaben bzgl. der Projektumsetzung oder des zu verwendenden Entwicklungsprozesses bekannt. Das fände ich auch sehr seltsam, da die Technologien und Methoden ja ständigem Wandel unterliegen und diese Vorgaben damit häufig überarbeitet werden müssten.

Es wird ein Zeitplan auf Stundenebene erwartet und das spricht gegen die agile Entwicklung. Diese Zeitangaben ist auch eine einzige Mogelpackung, denn wer kontrolliert es und wer kann sich daran halten?

[Pennytüte]

 

vor 52 Minuten schrieb stefan.macke:

Du sollst auch gar nichts umstellen, weil "das Internet" dir das rät. Du sollst einen geeigneten Prozess für dein Projekt aussuchen. Das heißt, du musst dir der Vor- und Nachteile bewusst sein und eine eigene Entscheidung treffen. Das ist Teil deiner Prüfungsleistung!

Das ist auch völliger Unfug. Du sollst für das Projekt nichts extra lernen, sondern etablierte Methoden und Werkzeuge einsetzen, die du beherrschst.

 

Ja, danke, das ist mal aussagekräftig und holt mich ein wenig runter. Glaub ich hab' ein wenig den Faden verloren.

 

vor 52 Minuten schrieb stefan.macke:

Ich weiß gerade nicht, welche Vorlage du genau meinst (ich habe mehrere ), aber es wird immer das Thema Testing behandelt. In den letzten Projekten gab es jedoch keine explizite Testphase, da mit TDD entwickelt wurde und die (Entwickler-)Tests parallel zur Implementierung stattfanden. Dennoch wird in der Doku auf dieses Verfahren eingegangen und dir Vorteile werden erläutert bzw. begründet, warum keine ausgedehnte (manuelle) Testphase stattfand.

Oh, werde die Entsprechende mal suchen und reinsehen, gibt mir bestimmt nen neuen Einblick.

 

vor 52 Minuten schrieb stefan.macke:

Unit-Tests und Integrationstests müssen nicht zwangsläufig durch TDD entstehen. Aber Unit-Tests sind wohl immer automatisiert. Integrationstests hoffentlich auch, können aber auch teilautomatisiert oder manuell durchgeführt werden.

TDD ist ein Prozess, der beschreibt, WANN die Tests geschrieben werden. Er gibt nicht vor, auf welcher EBENE (z.B. Unit, Integration, System) die Tests durchgeführt werden.

Wenn dir das alles nichts sagt, empfehle ich dringend in die Prüfungsvorbereitung zum Thema Softwaretest einzusteigen!

Ist mir im Großen und Ganzen schon klar gewesen, aber hmmm.. Mann, mein Dozent zeigt mir dann seine Folie und sagt so: Ja, aber hier steht das doch Herr...!

Werde mir die Prüfungsvorbereitung gleich mal ansehen.

 

Danke, Leute!

Bearbeitet 14. September 2016 von Pennytüte