IT -Teststrategien, -umsetzung, -technologien

IT -Teststrategien, -umsetzung, -technologien

Posts 1-9 of 9
  • Christoph Heller
    Christoph Heller    Premium Member   Group moderator
    The company name is only visible to registered members.
    wer definiert einen Test?
    Der Entwickler einer Software hat (oder sollte haben) natürlich seine eigenen Tests was die Funktionalität anbelangt.
    Darüberhinaus gehende fachliche Tests können oft vom Entwickler nicht definiert werden und sollten auch nicht (oft ist es ja so das die Entwickler von der fachlichen Materie kaum Ahnung haben).
    Wer definiert jetzt aber die die fachlichen Tests?
    Bei meinem momentanen Projekt definieren die fachlichen Tests teilweise aus Leuten der Fachbereiche und teilweise aus Gremien der Entwicklungsabteilungen (diejenigen, die die technischen Spezifikationen erstellen).
    Dies wird dann gegenüber der nächsthöheren Instanz im Projekt präsentiert usw. bis zur Projektleitung.

    Wie läuft das bei anderen Projekten?
    • 17 Mar 2005, 10:07 am
  • Post visible to registered members
  • Hermann Trimmel
    Hermann Trimmel    Premium Member
    The company name is only visible to registered members.
    Re: wer definiert einen Test?
    Die funktionalen Tests, Abnahmetests etc. sollten durch die Mitarbeiter der Fachbereiche erstellt werden, denn deren Anforderungen sollten ja erfüllt werden. Wichtig ist es, dass die Testfälle möglichst frühzeitig erstellt werden, idealerweise schon mit dem Anforderungsdokument. Dass ergibt auch den Vorteil, dass Entwickler schon bei den Unit-Tests darauf zugreifen können.

    Der Fachbereich wird jedoch des öfteren Hilfe und Unterstützung brauchen, wie man Testfälle aufbaut und definiert, vor allem auch, wenn Testwerkzeuge verwendet werden sollen.
    • 01 May 2005, 6:35 pm
  • Henry Smid
    Henry Smid    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re: wer definiert einen Test?
    Abgesehen von der Tatsache, dass das Entwickeln von Unittests im Aufgabenbereich der Entwicklung eine wesentliche Säule der Qualitätssicherung ist, müssen rein fachliche Tests definiert werden. Das kein nur von den jeweiligen Fachbereichen, die die Software später einsetzen sollen (Fallbeispiel: Entwicklung als Projektaufgabe) oder von Produktdesignern (Fallbeispiel: Entwicklung von Softwareprodukten) geschehen.

    Wir betreiben Produktentwicklung. Für die neu zu entwickelnden Features werden Spezifiaktionen erstellt. Auf Basis dieser Spezifikationen werden Testfälle ermittelt. Das heisst, es werden geeignete Testfälle definiert, anhand derer später die Frage geklärt werden kann, ob die Spezifikation von der Entwicklung wie gewünscht umgesetzt werden konnte.

    Beispiel: Eine Spezifikation umfasst in der Regel 20 Seiten und resultiert dann in ein Testdokument mit ca. 100 Testfällen.

    Positiver Nebeneffekt: Man muss bedenken, dass bereits Spezifikationen Fehler enthalten (Faustregel: 1 Spezifikationsfehler pro Dokumentenseite). Es handelt sich dabei um besonders teure Fehler, da sich aus ihnen oft "korrekte aber falsche Implementieren" ergeben. Nicht alles wird in den laufenden Iterationen zwischen Entwickler und Anwender/Produktdesigner frühzeitig herausgearbeitet. Die Ermittlung von Testfällen auf Basis einer Spezifikation setzt voraus, dass diese nochmals einer gründlichen Analyse unterzogen wird, aus der sich insbesondere durch die Aufdeckung von unschlüssigen Detailspezifikationen (lassen sich nicht in sinnvolle Testcases abbilden) frühzeitige Korrekturen der Spezifikationen ergeben. Das Resultat ist gerade hier eine drastische Kosten- und vor allem Zeiteinsparung bezogen auf den Gesamtprozess

    Qualitätssicherung verfehlt ihr Ziel, wenn sie nur darauf abzielt, die Fehler der Entwickler aufzudecken zu wollen. Alle, die an der Erstellung von Softwareprodukten beteiligt sind, machen Fehler, die es frühzeitig aufzudecken gilt.

    Christoph Heller schrieb am 17.03.2005, 11:07:
    Der Entwickler einer Software hat (oder sollte haben) natürlich seine eigenen Tests was die Funktionalität anbelangt. Darüberhinaus gehende fachliche Tests können oft vom Entwickler nicht definiert werden und sollten auch nicht (oft ist es ja so das die Entwickler von der fachlichen Materie kaum Ahnung haben).
    Wer definiert jetzt aber die die fachlichen Tests? Bei meinem momentanen Projekt definieren die fachlichen Tests teilweise aus Leuten der Fachbereiche und teilweise aus Gremien der Entwicklungsabteilungen (diejenigen, die die technischen Spezifikationen erstellen).
    Dies wird dann gegenüber der nächsthöheren Instanz im Projekt präsentiert usw. bis zur Projektleitung.
     
    Wie läuft das bei anderen Projekten?
    • 24 May 2005, 11:50 am
  • Post visible to registered members
  • Paul Huber
    Paul Huber    Premium Member
    The company name is only visible to registered members.
    Re^2: wer definiert einen Test?
    Hallo Herr Dietrich,
    sie sprechen mir aus der Seele!

    Viele Grüße


    Paul Huber
    • 04 May 2006, 11:43 pm
  • Post visible to registered members
  • Jens Rotondo
    Jens Rotondo    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^3: wer definiert einen Test?
    Hallo zusammen,

    ich kann mich meinen Vorrednern anschließen, doch hat sich bei uns geziegt, dass die meisten Fehler "wiederholt" werden. Also ist neben der Spezifikation die "LessonsLearned" Datenbank ein wichtiger Input. Hier werden alle aufgetretenen Fehler sowie die UseCases verwaltet.


    Gruß aus Wiehl
    Jens Rotondo
    • 08 May 2006, 06:07 am
  • Wilhelm Seidl
    Wilhelm Seidl
    The company name is only visible to registered members.
    Re^2: wer definiert einen Test?
    Ja, Her Dietrich, ich sehe das wie Sie.

    Das größte Problem in den Projekten, die ich kenne, stellen jedoch die Requirements selbst dar. Man darf nicht vergessen, daß die Mitarbeiter der Fachabteilungen ihr "daily business" zu erledigen haben und im Normalfall weder IT-Fachleute sind noch in der Konstruktion von UseCases versiert sind. So bringt eben jeder, der damit "zwangsbeglückt" wird, seine Anforderungen zu Papier, so gut er es eben kann. Dies soll KEINE Kritik sein, das ist Realität.

    So hängen dann, in der Praxis, die überwiegende Anzahl der Projekte stark von der Qualität der Requirements ab. Im jährlichen Chaos-Report wird dies deutlich: Schlechte Requirements sind die häufigste Ursache fehlgeschlagener Projekte.

    Das Geheimnis "trotzdem erfolgreicher" Projekte ist meistens eine gute Requirement-Analyse, die manchmal bis zum "reverse engineering" reicht. Auf dieser gesicherten Basis werden konkrete Spezifikationen ermöglicht, aus denen - nach Analyse - Testcases erstellt werden.

    .. Und natürlich, sollte man für diese Aufgaben auch projekterfahrende, qualifizierte Tester einsetzen.

    Wilhelm Seidl
    Cellconsult.com GmbH
    • 11 May 2006, 1:19 pm