IT -Teststrategien, -umsetzung, -technologien

IT -Teststrategien, -umsetzung, -technologien

Posts 1-7 of 7
  • David Rosenberg
    David Rosenberg    Premium Member
    The company name is only visible to registered members.
    Softwarevalidierung
    Hallo,

    der folgende Beitrag dient der Diskussion von notwendigen Schritten zur Sicherstellung der Qualität von Software. Der folgende Testprozess bezieht sich auf das Testen von Web- und Lotus Notes Projekten.

    Für unsere Kunden testen wir im Jahr ca. 200 Projekte mit verschiedensten Ausmaß (10 - 300 Std. reine Testzeit)
    Lassen Sie mich zuerst erläutern welches Testen bzw. Validieren ich meine:
    Überwiegend führen wir nicht das Unittesten oder andere Codetests durch sondern wir überprüfen das System an Hand des Requirements Document (RD) sprich dem Pflichtenheft.

    Testaufbau in seinen groben Zügen:
    1. Nachdem das System im RD und einigen anderen Dokumenten spezifiziert wurde beginnt die Entwicklungsphase. der Entwickler führt eigenständig Codetests auf der Entwicklungsumgebung durch.

    2. Sobald das System umgesetzt wurde fängt unsere Validierung an. Wir studieren alle relevanten Informationen (RD, Meetings mit Entwickler, usw.) um ein Verständnis für das System zu erlangen.
    --> bei komplexeren Systemen werden wir auch schon in Punkt 1. involviert.

    3. Erstellung des Test Plans: Hier halten wir alle relevanten Informationen fest wie das System zu testen ist, in welcher Umgebung, Welche Risiken bestehen und wie kann man ihnen entgegenwirken; usw.

    4. Erstellung der Test Scripte (TS): Wir erstellen komplette Szenarien um alle Requirements ausreichend (positiv und negativ) zu testen. Wir testen nur auf der Benutzeroberfläche (einige Projekte erfordern natürlich auch das kontrollieren von Datenbanken die der Enduser später nicht nutzten wird) Diese Phase wird ausschließlich auf der Entwicklungsumgebung durchgeführt und zwar so lange bis keine Fehler mehr auftreten. Die TS enthalten alle Informationen was gemacht wurde und was eigentlich passieren sollte, so das jeder Benutzer (auch Non-IT) alles nachvollziehen kann.

    5. Das Ausführen dieser TS wird dann in einer simulierten Produktionsumgebung (Testumgebung) durchgeführt. Hierbei werden alle tatsächlichen Ergebnisse mit den Erwarteten verglichen und auf Passed oder Failed gesetzt. (Bei Fehlern wird dieser Prozess wiederholt bis alles Fehler behoben worden sind)

    6. Alle Ergebnisse und Abweichungen werden in einem Report festgehalten.

    Laut verschiedenen Statistiken findet man genau in dieser Phase sprich dem simulierten Endbenutzer die meisten Fehler. Viele Unternehmen setzten dieses Konzept aber nicht um.
    Gerne gebe ich Ihenn auch Bispiele für Vorteile dieser Methode.

    Mich würde Ihre Meinung zu diesem Prozess interessieren.
    Setzten Sie solche Projekte auch um oder sind Sie überwiegend im Bereich des Codetestens?
    Wieso wird es nicht umgesetzt?
    Kennen Sie Unternehmen die eine solche Leistung in Anspruch nehemn würden?

    Ich freue mich auf Ihre Antworten.

    Grüße
    David Rosenberg
    • 22 Sep 2005, 1:57 pm
  • Christoph Heller
    Christoph Heller    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re: Softwarevalidierung
    Ihre Beschreibung fußt ja auf der Annahme das die Software fertig umgesetzt wurde.
    Da finde ich das ganze auch sehr schlüssig.

    Wie verhält sich sich der Prozess bei Releases der Software? Wie ändern sich die Tests, ändern sie sich überhaupt?

    Wie ist das bei Implementierung, deren Tests beginnen, wo die Software noch gar nicht komplett umgesetzt wurde. Gibt es verschieden Testebenen bei Ihrem Prozess?
    • 23 Sep 2005, 11:15 am
  • David Rosenberg
    David Rosenberg    Premium Member
    The company name is only visible to registered members.
    Re^2: Softwarevalidierung
    Christoph Heller schrieb:
    Ihre Beschreibung fußt ja auf der Annahme das die Software fertig umgesetzt wurde.
    Da finde ich das ganze auch sehr schlüssig.
     
    Wie verhält sich der Prozess bei Releases der Software? Wie ändern sich die Tests, ändern sie sich überhaupt?
          Bei einem neuen Release verändert sich die Art der TS nicht. Bei einer Erweiterung eines bestehenden Systems werden die TS ebenfalls erweitert und erhalten auch einem neuen Release. Ich sollte noch erwähnen dass innerhalb des TS alle Testfälle einzeln erfasst sind. Jeder Fall hat seine eigene Run-Nummer. Das bedeutet innerhalb des gleichen Release können Testfälle unterschiedliche Run-Nummern haben, da einige Fälle beim ersten Durchlauf Pass waren andere wiederum beim zweiten, dritten, … . Das ist abhängig von den Fehler die gefunden wurden und wie schnell sie gelöst werden.

    Wir versuchen immer so viel wie möglich von der existierenden Dokumentation wieder zu verwenden.
    Wenn an einem System beispielsweise nur ein paar Modifikationen durchgeführt wurden, werden nur die Fälle angepasst die sich mit den veränderten Teilen beschäftigt haben und auch nur diese werden executed, es sei denn die Modifikationen haben das gesamte System beeinflusst, wodurch es wieder notwendig wäre einen Full System Test zu machen.

    Bezüglich der Tests von Modifikation ist noch zu erwähnen, dass auch der Test Plan und der Test Report angepasst werden müssen. Wenn die Test Strategie und die Test Gegebenheiten sich nicht geändert haben ist es auch nicht notwendig den TP zu bearbeiten oder neu zu releasen. Hingegen muss es für jede neue Testphase einen eigenen Test Report geben.


    Wie ist das bei Implementierung, deren Tests beginnen, wo die Software noch gar nicht komplett umgesetzt wurde. Gibt es verschieden Testebenen bei Ihrem Prozess?
    Das oben beschriebene Testen ist nur sinnvoll bei Tests von abgeschlossenen System Modulen. Ich denke dass es am besten an Beispielen zu erklären ist:

    Es soll eine Website erstellt werden. Diese Seite hat sowohl ein Front-End als auch ein Back-End zur Administration. Das Back-End wird zuerst fertig gestellt. In diesem Fall kann man auch schon unseren Test durchführen. Man muss allerdings bedenken das später Tests erstellt werden müssen die das Zusammenspiel von Back-End und Front-End abdecken.

    Wenn das Back-End nur zu einem Teil umgesetzt wurde macht es keinen Sinn den beschriebenen Prozess zu verwenden, da man hier bei am Ende des Tests mehr Zeit investiert hätte als wenn man erst nach der Fertigstellung des gesamten Moduls getestet hätte.

    Grundsätzlich ist dieses Testen anwendbar für abgeschlossene Module, es sollte nicht für unfertige eingesetzt werden.
    Natürlich werden während der Entwicklung weitere Tests durchgeführt. Diese Tests werden und sollten von dem jeweiligen Entwickler gemacht werden.

    Der beschriebene Testprozess kontrolliert die Umsetzung der Requirements (Pflichtenheft). Der Vorteil dieses Testens liegt darin das wir das System einem Soll-Ist Vergleich unterziehen wodurch wir in der Endphase in einer simulierten Produktionsumgebung den End-User simulieren. Durch dieses Verfahren ist es möglich ein höheres Maß an Fehlerfreiheit zu erreichen, als es durch das reine Codetesten möglich ist.
    Es gibt mehrere Studien bei denen festgestellt wurde, dass die meisten Fehler in Produktion gefunden werden - diese Fehler sind auch bekanntlich die teuersten – und genau da setzt unser Test an.

    Wir testen also nicht nur das System nach den Requirements, sondern simulieren die Realität mit verschiedenen Standard Tests um der Bedienung durch den User gerecht zu werden.
    Des weiteren hat diese Art des Testens den Vorteil das man kein Fachpersonal nutzen muss welches aus der IT kommt und Stundenlöhne eines Entwicklers beziehen möchte. Der Tester muss nur auf den Dokumentationsstandard geschult werden und allgemeine Grundkenntnis haben. – eben wie der User selbst.
    Wir haben auch festgestellt, dass Entwickler oft nicht für diese Art von Testen geeignet sind, weil sie nicht „einfach“ genug denken, um sich in einen Non-It Benutzer hineinzuversetzen.

    In meinen Augen spart man bares Geld mit dieser Art von Tests. Ich bin jedoch für jede Art von Kritik offen.

    Grüße
    David Rosenberg
    • 25 Sep 2005, 12:16 pm
  • Thomas Hahn
    Thomas Hahn    Premium Member
    The company name is only visible to registered members.
    Re^3: Softwarevalidierung
    Sehr geehrter Herr Heller,

    ich habe Ihr Testsystem leider noch nicht ganz verstanden.....
    In Ihren Beispiel erwähnen Sie, dass mit dem Test bereits begonnen werden kann, wenn das Back-End bereits fertiggestellt ist, das Front-End aber noch nicht. Mit Back-End setze ich jetzt einmal die Benutzeroberfläche voraus. Dann lassen sich natürlich schon gewissen Benutzerflows testen - was machen Sie aber, wenn zuerst das Front-End fertig ist? Wie wollen Sie dann testen?

    Ausserdem ist in der Regel ein Warten bis zum Ende der Entwicklung nicht möglich - die größten Einsparungen haben Sie, wenn Sie sich bereits früh erste Releases liefern lassen und manuell zu testen beginnen (nachdem Sie auf Grundlage der Anforderungen Ihre Testfälle erstellt haben).

    Was machen Sie, wenn Sie nach Testbeginn Fehler feststellen, die falsch spezifiziert wurden?

    Wie unterscheiden Sie zwischen den Tests, die die Entwickler machen und den Tests gegen die Requirements?

    Es gibt mehrere Studien bei denen festgestellt wurde, dass die meisten Fehler in Produktion gefunden werden - diese Fehler sind auch bekanntlich die teuersten – und genau da setzt unser Test an.
    Kann ich noch nicht erkennen -schließlich setzen Sie ein fertiges Modul voraus.
    Kosten sparen werden Sie bei einem Requirements Review, Design Review, Code Review.

    Des weiteren hat diese Art des Testens den Vorteil das man kein Fachpersonal nutzen muss welches aus der IT kommt und Stundenlöhne eines Entwicklers beziehen möchte. Der Tester muss nur auf den Dokumentationsstandard geschult werden und allgemeine Grundkenntnis haben. – eben wie der User selbst.
    Welche Grundkenntnisse setzen Sie denn voraus? Anwendungskenntnisse oder Testkenntnisse?
    Ganz so einfach ist es für den Benutzer in der Regel nicht, effektive Testfälle zu ermitteln. Mancher Benutzer ist stark Mausfixiert und weiss gar nicht, dass man z.B. auch mit Strg-C, Strg-V kopieren und einfügen kann.

    Wir haben auch festgestellt, dass Entwickler oft nicht für diese Art von Testen geeignet sind, weil sie nicht „einfach“ genug denken, um sich in einen Non-It Benutzer hineinzuversetzen.
    Für einen Abnahmetest sollten Sie keine Entwickler einsetzen. Manchmal <dürfen> Sie das auch nicht!!

    Können Sie vielleicht eine Beispielanwendung geben, bei dem Sie mit 10 Stunden Test auskommen?

    Mit freundlichen Grüßen
    Thomas Hahn
    • 22 Oct 2005, 9:48 pm
  • Thomas Hahn
    Thomas Hahn    Premium Member
    The company name is only visible to registered members.
    Re^4: Softwarevalidierung
    Mit meinem vorigen Posting wollte ich natürlich Herrn Rosenberg ansprechen und nicht Herrn Heller!
    • 30 Oct 2005, 09:28 am
  • David Rosenberg
    David Rosenberg    Premium Member
    The company name is only visible to registered members.
    Re^4: Softwarevalidierung
    Hallo,

    ich glaube wir haben uns in so ziemlich allen Punkten missverstanden.
    Also Back-End wäre z.B. der Admin Bereich bei einem CMS und Front-End das was man im Internet als normaler Benutzer sieht.

    Unser Testen setzt auch nicht erst an wenn die Software fertig ist, dass habe ich vielleicht etwas falsch ausgedrückt. Mit fertig meine ich, dass der Entwickler mit seiner Umsetztung der Requirements eine vorerst funktionierende Applikation hat, die von dem Test Team dann gegen die Requiremets getestet werden kann. wir befinden uns also noch in der Entwicklung.
    Fehler werden in der sogennanten Dry Run Phsase direkt an den Entwickler berichtet. Dann geschieht ein bug fix und die Test Fälle in denen die Fehler aufgetratetn sind bzw auch andere davon betroffenen Bereiche werden nochmals getestet.
    Diese Phase ist erst abgeschlossen wenn alle Fehler beseitigt wurden. Dann wird die Applikation in die Testumgebung (simulierte Produktionsumgebung) implementiert . Hier findet dann die execution statt, um wirklich sicher zu sein dass die Applikation sicher läuft.

    Der Unterschied zwischen dem Testen der Entwickler und dem welches wir durchführen liegt darin, dass wir nicht in den Code schauen sondern in fast allen Fällen nur über die Oberfläche testen, so wie ein simulierter Nutzer es machen würde. Wir testen sowohl positiv als auch negativ (negativ bedeutet z.B. wir machen Eingaben die so nicht funktioniren dürften und erhoffen eine korrekte Fehlermeldung)

    Auf die Personalfrage gehe ich gerne ein sobald wir dies Punkte geklärt haben.

    Grüße und freue mich auf ihr feedback.
    DR
    • 04 Nov 2005, 5:42 pm
  • Dr. Helmut Geilert
    Dr. Helmut Geilert    Premium Member
    The company name is only visible to registered members.
    Re: Softwarevalidierung
    Hallo zusammen,

    Prinzipiell bin ich mit der Methode einverstanden. Hier aber einige Fragen:

    Welches Pflichtenheft wurde bei Änderungen während des Projektes aktualisiert ? Ich kenne keins.

    Wie kann man sicher sagen, dass die Änderung in einem Modul nicht Nebenwirkungen auf andere hat ? Das war stets eines unserer größten Probleme.

    Wie sieht ein Tool-Einsatz aus ?

    Viele Grüße
    Helmut Geilert
    • 01 Dec 2005, 2:37 pm