Projektmangment=> Aufteilung der Phasen: Konzept,Implementierung,Test



  • Naja Theorien leist man ja tausende im I-Net:)

    Ich bin hier um die Praktiker zu fragen;)

    Dass man die Test plant und durchführt muss während man entwicklet, ist sinnvoll das stimmt;)

    ABer wie sieht die Realität aus?? Plaudert aus euerem nähkästchen!

    Wieviel Frontloading betreibt ihr, und konzipiert Design und Verhalten via UML bevor ihr implementiert?

    DANKEEE;)



  • Das gehört für mich alles mehr oder weniger zur "Implementierung" dazu, vor allem Testen. Ich mache da keine Unterteilung, halbe Stunde Code einhacken, zwei Stunden testen. Wenn ich was geschrieben habe und am Testen/Debuggen bin, dann gehört es noch zur Implementierung.
    Die Planung nimmt nicht so viel Zeit ein, wobei das auch etwas schwer zu sagen ist. Was ab und zu etwas ausartet, sind irgendwelche Diskussionen, da diskutiert monatelang immer wieder über irgendwas, bevor man anfängt. Seh ich jetzt aber nicht unbedingt als Planung in dem Sinne.
    So richtige Planung mit UML usw. machen wir nicht. Mit etwas Erfahrung kann man sich meist eh schon gut vorstellen, wie man etwas machen würde. Und dann hat man auch schon seinen eigenen Stil, da kann man noch so lang rumplanen, wird eh nichts anderes rauskommen. Ich kritzel dann aber schon öfter irgendwelche Diagramme auf Papier und versuche mir das Endergebnis vorzustellen. Aber sicher nicht zu detailliert, das bringt nichts. Irgendwelche Details kann man nicht planen, bevor man loslegt, halte ich für sehr kontraproduktiv.



  • 30 Coden und 2h testen ist doch schonmal nich schlecht was dann die qualität des endprodukt angeht:)

    Ich frage mich wie man ab besten abwägt wie detailiert man frontloading betreibst, bzw. man die Grobstruktur bzuw. das Design via UML feshaält. hat dann später auch was für die Doku:)

    Was ich aber auch nich verstehen kann, wieso man sich "stundenlang" mühe macht, klassendiagramm für irgendwelche Konstrukte via UML zu modelieren, was man in ner zentel der Zeit schon gecodet hat, und evtl. man sogar reverse Engineering betreibt:)

    Große strukturiere Unternehmen mit strengen Projektorganisationen und Methoden schreiben immer SCRUM oder sonst was vor, und spezielle TEstmodel (V-model) usw.

    Aber läuft es da dann wirklich soooo streng ab, oder wird auch mehr oder wneiger mit grobkonzept drauf los gecoded und geprüft ob was umsetzbar ist?!

    GRüßle



  • Also ich kann dir hier nur was zum Thema Implementierung vs. Tests sagen.
    Und zwar dass die Verteilung 1 Implementierung : 2 Tests die dein Prof genannt hat vermutlich nicht ganz verkehrt ist.
    WENN man Wert auf Tests legt. (Bei uns wird leider meist wenig Wert darauf gelegt.)

    Kommt natürlich auf das Projekt drauf an. Aber doppelt so viel Aufwand für Tests wie für die Implementierung ist sicher nicht übertrieben. Kann sogar noch mehr sein. Weil es immer haufenweise Corner-Cases zu testen gibt, bzw. die "interessanten" Tests meist auch recht aufwändig zu schreiben sind.

    Dabei beziehe ich mich jetzt auf automatisierte Tests.
    Das normale (meist nicht automatisierte) Testen während dem Entwickeln gehört für mich auch zur Entwicklung mit dazu. Wobei ich immer wieder auf Entwickler treffe die das nicht bis kaum machen. Was mich immer total verblüfft -- woher wollen die denn wissen dass ihr Code funktioniert, wenn sie ihn nicht probelaufen lassen?

    OK, was Planung angeht kann ich auch noch ein bisschen was sagen. Und zwar dass ich UML als Planungswerkzeug für überbewertet halte. Auf dieser Ebene wird bei uns auch nicht geplant. Es gab ein paar Versuche in diese Richtung, aber dabei ist kaum jemals was sinnvolles rausgekommen.

    Softwaredesign ergibt sich einfach während der Implementierung. Wichtig dabei ist dass man die Anforderungen von Beginn an so gut wie möglich kennt (wird nie perfekt sein, aber man sollte zumindest ungefähr wissen ob man ein Auto oder doch einen Haarföhn bauen will). Und dass man, wenn der Schuh (=das Design) anfängt zu drücken, den Refactoring-Hammer auspackt.
    (Ich treffe immer wieder auf Leute die mich ganz verdutzt angucken wenn ich über das Thema spreche, und Dinge wie "Du machst während der Implementierung (eines neuen, "frischen" Projekts) schon Refactoring???" sagen. Und dabei die Augen verdrehen. Was für mich eine dämliche Frage ist - natürlich mache ich während Implementierung schon Refactoring. Vorab kann man nie an alles denken, und egal wie gut der Plan zu Beginn ist, wenn man ihn im Verlauf der Implementierung nicht wie nötig anpasst, wird Murks dabei rauskommen.)



  • Guten Morgen,

    danke für die praxisnahen Ausführungen;) Naja ich denke, dass wenn man eine Kompoenente implementiert, welche ein best. Verhalten aufweißen muss, man diese Verhalten auch parallel bei der entwicklung testen muss.. logischerweiße..

    Die Autmoatisierten Tests sind ja wirklich abhängig von der Qualtätsanforderungen nehme ich an..

    Wer macht den die Automatisierten Tests? Die Tester?? Es gibt ja auch Rollen der "Software-Tester" , ist es nich sinnvoller, dass die Entwickler die Tests schreiben, oder verleitet es die nur das nötigste zu testen, um vorran zu kommen!?

    Grüße 🙂



  • InDerTheorieStudent schrieb:

    Wer macht den die Automatisierten Tests? Die Tester?? Es gibt ja auch Rollen der "Software-Tester" , ist es nich sinnvoller, dass die Entwickler die Tests schreiben, oder verleitet es die nur das nötigste zu testen, um vorran zu kommen!?

    Bei uns wird ja leider sehr wenig automatisiert getestet. Aber wenn, dann schreiben die Entwickler auch die Tests. Weil wir keine Tester haben 🙂

    Ich bin aber der Meinung dass es sinnvoller wäre wenn die Tests zumindest von einem anderen Entwickler oder Entwicklerteam geschrieben werden. Wenn einer die Komponente und die Tests für die Komponente entwickelt, dann kann das mMn. nie so gut funktionieren als wenn es verschiedene Leute machen.

    Selbst wenn man voraussetzt dass der Entwickler der beides macht wirklich gute und vollständige Tests, die möglichst viele Fehler finden, schreiben will...
    Das Problem ist dabei immer noch das selbe wie wenn man seinen eigenen Code testet (nicht automatisiert).
    Wenn ich als Entwickler beim Implementieren Annahme X treffe (die aber nicht zutrifft, was mir bloss nicht auffällt), dann werde ich beim Testen wohl auch X annehmen, und daher keine problematischen nicht-X Fälle testen. Wenn ich beim implementieren nicht an Sonderfall Y denke, dann werde ich Sonderfall Y vermutlich auch nicht testen.

    Andrerseits kenne ich als Entwickler auch bestimmte Sonderfälle die mir beim Implementieren aufgefallen sind, und die ich (hoffentlich richtig) in meinem Code behandle. Das können leicht Sonderfälle sein, an die man so, ohne den Code dafür entwickelt zu haben, gar nicht denkt. Die sollten natürlich auch getestet werden.

    Was man auch oft hört, ist dass (ausschliesslich) der Teamleiter/Projektleiter/Lead-Programmer die Tests schreibt. Ich kann mir aber nicht vorstellen dass das besonders gut funktioniert. Und zwar einfach weil man als Teamleiter/Projektleiter/Lead-Programmer sowieso schon viel zu tun hat, und die Zeit die dann übrig bleibt um Tests zu schreiben wird wohl nicht ausreichen um eine brauchbare Abdeckung zusammenzubekommen. Diese Variante hab ich aber noch nicht selbst erlebt, also kann ich auch nichts aus Erfahrung dazu sagen. Ich glaube nur dass es nicht besonders gut funktioniert.

    Um es zusammenzufassen: ich glaube dass es Sinn macht, wenn sowohl der Entwickler, der die Komponente entwickelt hat, Tests dafür schreibt, als auch andere Entwickler. Vermutlich idealerweise abwechselnd. Tests zu schreiben macht auch irgendwie Spass, aber zumindest ich hätte keine Lust immer nur Tests zu schreiben.



  • Geringe Testabdeckung kommt nicht immer davon, dass man zu wenig Tests hat. Die kann auch daher kommen, dass es zu viel redundanten Müllcode gibt, der schwer testbar ist. Und das kommt daher, dass man kein Refactoring macht und Prototypen nicht wegwirft (was man immer dringend machen sollte).

    Außerdem wird jedes neue Feature in eine der "Hauptklassen" oder "Manager" hineingekippt. Ein Test entsteht natürlich nicht, weil neuer Code die "funktioniert doch"-Eigenschaft automatisch vom existierenden "funktioniert doch"-Code übernimmt. Wenn das Programm ein GUI hat, auf Dateien zugreift, mehrere Threads startet oder über das Netzwerk kommuniziert, sind Tests für die meisten Entwickler sowieso undenkbar.

    Interessanterweise hilft Scrum dabei zum Beispiel überhaupt nicht. Es muss ja nur gut genug laufen, um im Sprint Review bei einer sehr kurzen Demonstration zu überzeugen. Ob da irgendwas getestet wurde, interessiert nicht. Tests haben keinen "customer value". Sprints sind sowieso zu kurz für den ganzen Zyklus aus Nachdenken, Ausprobieren, Umsetzen und Überprüfen (und ggf Aufräumen). Ratet mal, was am Ende des Sprints wegfällt, wenn man "fertig werden" will.



  • InDerTheorieStudent schrieb:

    Wer macht den die Automatisierten Tests? Die Tester?? Es gibt ja auch Rollen der "Software-Tester" , ist es nich sinnvoller, dass die Entwickler die Tests schreiben, oder verleitet es die nur das nötigste zu testen, um vorran zu kommen!?

    Wir haben eine QA Abteilung, die manuelle Tests durchführt. Das sind schon einige Leute, zwar nicht so viele wie in der Entwicklung, aber schon recht viele. Und ich finde, das funktioniert auch halbwegs. Ich kanns zumindest daran erkennen, dass die Abteilung vor paar Jahren noch nicht so groß war und es jetzt viel besser funktioniert als früher 😉 Da kann man dann auch oft Testaufträge vergeben, testet mal ein bestimmtes Feature mit allen CAD Systemen oder mit allen Datenbanken oder mit den Testdaten von einem bestimmten Kunden. Und mit den Testprotokollen usw. haben die das mittlerweile auch halbwegs drauf, d.h. wenn wir in einer Version mal alles umbauen, dann finden die tatsächlich auch vieles, was nicht mehr funktioniert.
    Für die automatischen Tests haben wir mittlerweile auch zwei Leute. Aber das funktioniert alles noch nicht so recht, so wirklich viel bringt das nicht. Muss vielleicht noch eine Weile reifen, hat bei der QA auch gedauert.
    Dann schreiben die Entwickler selber ab und zu Unittests, aber eher selten. Ich halte auch selber nicht so viel von Unit Tests. Kann funktionieren, tut es meist aber nicht und meist steckt man sehr viel Arbeit in etwas rein, wo am Ende dann fast sicher rauskommt, dass man gerade an die wichtigen Testfälle und Sonderfälle nicht gedacht hat.



  • Coole Diskussionsrunde Jungs;)

    Hmm ok, verstehe .. wenn die Zeit eng wird, dann testet man am ende weniger! Klar haben test, keinen "customer value" aber ehr ein Qualitätsmerkmal der Firma oder..
    Wenn die Software später im Feld dauernt abstürzt, was mit keiner funktionalen Anforderung zu tun hat, is der Kunde trotzdem unzufriedne!?

    Was genau machen den die Tester? Habe das hier jetzt so interpretiert, dass er nach Schema X und vll. Checklisten die Funktion der Software testet.. testet er denn auch den Code der test, also unit-tests etc.!?

    Wie penibel Tests von den Entwickler selbst gemacht werden hängst ja best. auch von der Motivation ab!? Man möchste ja auch fertig werden, oder hat nen kreative Phase und will diese nich mit Tests unterprechen!

    Gibt es denn best. Testmodele und vorgehenweißen ? Ich lese nur von den Phasen des
    Testplan: Testvorbereitung, Testspezifikation, Testausführung, Testauswertung,

    Das ist ja ziemlich viel Bürokrati für bisschen Testen, wer hat da schon Bock drauf!?

    Ich finde man müsste ein schnlankes Testmodel entwickeln, damit das testen auch nicht zu kurz kommt, bzw. die motiviation dazu stimmt..hmm



  • Man kann auflisten, was jemand im Einzelnen mit dem Produkt machen kann. Diese Liste der Merkmale sollte nicht zu grob und nicht zu fein aufgelöst sein. Da ist Augenmaß gefragt. Jeder der Punkte muss aber genau genug beschrieben sein, um im Prinzip von jedem überprüft werden zu können.

    Für jeden Punkt macht man mindestens einen Test. Wenn pro Punkt sehr viele Tests entstehen, ist der Punkt wahrscheinlich zu umfangreich und sollte aufgeteilt werden. So ein Test kann automatisch oder manuell sein. Ein automatischer Test ist als Programm geschrieben, das nach jeder Code-Änderung von einem zentralen CI-System ausgeführt wird. Ein manueller Test wird etwas seltener durchgeführt, aber mindestens vor jedem öffentlichen Release. Die manuellen Tests können die Entwickler selbst durchführen oder dedizierte Tester. An den Testprotokollen können Entscheider erkennen, was wirklich geht und was nicht.

    So eine Liste muss es nicht nur für das Gesamtprodukt geben. Auch Teilprodukte, zum Beispiel Code-Bibliotheken, können so etwas haben. Im Prinzip kann API-Dokumentation als Grundlage für die Tests dienen. Solche Tests sind in der Regel automatisch, weil Programme gut Bibliotheken aufrufen und Ergebnisse kontrollieren können.



  • InDerTheorieStudent schrieb:

    Ich finde man müsste ein schnlankes Testmodel entwickeln, damit das testen auch nicht zu kurz kommt, bzw. die motiviation dazu stimmt..hmm

    Ich glaube, das schafft man nicht, bzw. ich seh den Bedarf noch nicht. In größeren Firmen gibt es auch größere Abteilungen, die sich um Tests kümmern und da werden auch Entwickler beschäftigt. Aber ich glaube, ein wirklich guter Entwickler wird wohl kaum testen wollen, was andere geschrieben haben. Ich kanns mir zumindest nicht vorstellen, das zu machen. Ich will ein System immer ganz genau verstehen und Probleme auch selber lösen wollen, und nicht nur oberflächlich analysieren, was so passieren könnte und die verschiedenen Fälle durch Tests abdecken. Würde ich nicht machen.
    Die Entwicklung und die Tests während der Entwicklung sind zu komplex, um da pauschal sagen zu können, dass durch irgendwelche Modelle etwas besser wird. Erfahrene und verantwortungsbewusste Entwickler testen besser. Kann aber auch von vielen externen Faktoren abhängen.
    Umfangeiche Tests können sehr schwierig sein und es ist oft auch nicht sinnvoll, dass die Entwickler selbst die machen. Ich finde es sehr gut, dass es in unserer Firma eine QA Abteilung gibt, die irgendwelche Massentests übernimmt. Und einfach dadurch, dass 20 Leute mit der Software rumspielen und verschiedene Sachen ausprobieren, fallen sehr viele Bugs auf. Natürlich muss man als Entwickler versuchen, möglichst viele Sonderfälle zu berücksichtigen und dann entsprechend zu testen, aber auch wenn er sich dann noch mal 5x mal so viel Zeit nimmt wie für die Entwicklung, wird er sicher nicht alles finden.



  • Verstehe danke schon mal:) Was ich mir noch überlegt habe, wer testet denn den Test-Code??;) :p

    Aber du redest dann ehr von User-Acceptance-Tests.. also was die Tester in deiner Firma tun?

    Was ist mit Unit-Tests.. die machen wohl die Entwickler selber.. evtl. ist ein Pair-Programming auch rel. gut geeignet Fehler im vorraus zu erkennen!?!



  • InDerTheorieStudent schrieb:

    Aber du redest dann ehr von User-Acceptance-Tests.. also was die Tester in deiner Firma tun?

    Hast du dich auf meinen Beitrag bezogen oder TyRoXx? Kann ich nicht ganz nachvollziehen. Wenn du mich meinst, dann meinte ich nicht unbedingt User Acceptance bzw. würde es nicht so bezeichnen. Wir machen was im CAD/PDM Bereich. Nur um ein Beispiel zu nennen, können auch Modelle generiert werden oder wieder "einlesen". Da gibts recht viele Features, die man berücksichtigen muss und es kommen ständig welche dazu oder werden umgebaut. Da ist es am einfachsten, manuell zu testen, ob alle mit allen CAD Systemen das passiert, was passieren sollte. Das automatisch zu testen wäre schwierig. Sind aber langwierige Tests, wo viele Testdaten benutzt werden und sich in der QA jemand das Ergebnis dann anschaut. Die CAD Systeme haben z.B. viele Eigenheiten und Bugs, die man als Entwickler nicht unbedingt berücksichtigen kann. Könnte z.B. sein, dass man grad radiale Muster implementiert und der Entwickler die dabei auch intensiv getestet hat. Dann testet aber jemand mit anderen Eingabedaten und stellt fest, dass die sich in Kombination mit einer Blechkonstruktion plötzlich anders verhalten. Sowas hat man nicht von vornherein im Griff, man muss da wirklich möglichst viele unterschiedliche Kombinationen ausprobieren und hoffen, dass man nichts übersehen hat. Dann werden aber Testprotokolle erstellt und vor jedem Release neu getestet.

    Was ist Test-Code? Unit Tests? Von Unit Tests halte ich wie gesagt nicht so viel. Weiß natürlich keiner, wie viel sie wirklich abdecken und ob die auch richtig funktionieren. Das ist bei uns etwas, was Entwickler selber verwalten. Wir haben eine Plattform, wo die Unit Tests ausgeführt werden. Was dann aussagt, müssen die Entwickler selber wissen. Wenn da schiefgeht kann man sich das auf jeden Fall aber mal anschauen.



  • Ne, ich meinte schon dicht!

    Ich meine wenn eine SW Release draußen ist, wird das ja erst intern in der QA gesteste, was ja dann schon User-Acceptance-Tests sind.. quasi die Beta testen!

    Mit Test-Code meinte ich jeglicher Implementations- Logik, die verwendet wird um Code zu testen, sei es Unit- Tests oder Automatisierte Tests.. sind ja auch alles Programme!



  • Sehr interessant hier!

    Mich würde interessieren, was gegen Unit-Tests spricht? Ich persönlich bin Unit-Tests ggü sehr positiv eingestellt und habe oft das Gefühl, dass negative Argumente auf ein falsches™ Verständis, wie viel ein Test testen soll, ruhen.

    In der Praxis haben wir es mit Unit Tests versucht (und auch wirklich intensiv am Anfang gemacht), bis dann die ersten Deadlines auf uns zukamen. Die Tests waren natürlich das Erste, was auf der Strecke blieb - aber: Bei einigen Bugs bin ich mir sicher, dass wir sie mit Tests schneller gefunden/gelöst hätten.



  • unittests schrieb:

    Mich würde interessieren, was gegen Unit-Tests spricht?

    Gegen Unittests spricht, dass sie in der Theorie so eingeschränkt sind, dass sie nicht viel aussagen. Bei einem Unittest sollen ja laut Thorie alle anderen Module ignoriert werden (Dummys, Mocks...). Die meisten Probleme treten aber beim Zusammenspiel der einzelnen Module auf. Ich denke viele werden ihr Unittests aber soweiso mehr wie Integrationstests implementieren.


Anmelden zum Antworten