Qualitätsmanagement für Software-Projekte

Qualitätsmanagement für Software-Projekte

Posts 1-4 of 4
  • Thomas Engelhardt
    Thomas Engelhardt    Premium Member
    The company name is only visible to registered members.
    Testautomatisierung - Migration von WinRunner nach QTP
    Das Testautomatisierungswerkzeug WinRunner wird nicht mehr lange unterstützt; für alle Versionen gibt es von HP (ehemals Mercury) nur noch bis zum 1.1.2011 den eingeschränkten Support. Dafür bietet HP seinen Kunden einen kostenlosen Umstieg nach QTP 9.5 an. Das Thema "Umstieg oder nicht?" ist also für alle WinRunner-User aktuell.

    Da ich mich derzeitig intensiv mit dem Thema beschäftige, möchte ich hier eine Diskussion anstoßen, in der es um die Vor- und Nachteile der Migration von WinRunner nach QTP geht, aber auch um ihre konkrete Durchführung.

    Ein verspätetes "Alles Gute im Neuen Jahr!" von
    Thomas Engelhardt
    • 06 Jan 2009, 4:26 pm
  • Carsten Büche
    Carsten Büche    Premium Member
    The company name is only visible to registered members.
    Re: Testautomatisierung - Migration von WinRunner nach QTP
    Thomas Engelhardt schrieb:
    Das Testautomatisierungswerkzeug WinRunner wird nicht mehr lange unterstützt; für alle Versionen gibt es von HP (ehemals Mercury) nur noch bis zum 1.1.2011 den eingeschränkten Support. Dafür bietet HP seinen Kunden einen kostenlosen Umstieg nach QTP 9.5 an. Das Thema "Umstieg oder nicht?" ist also für alle WinRunner-User aktuell.
    Ich kenne nicht Ihren Bedarf, aber ich denke mal das, wenn eine Migration erfolgen soll, doch schon eine Menge an TSL-Code vorhanden ist, der wie in unserer Branche üblich, nicht trivial ist im Workflow und stark in Abhängigkeit zu den Testdaten steht . Je nachdem auf welchem Level ein Automat, mittels einer prozeduralen Sprache wie "TSL", modular zur Reife gebracht wurde.

    Das Ansinnen also eine Lösung zu finden die ohne Nachbearbeitung reibungslos funktioniert halte ich für unrealistisch.


    Deshalb würde ich das, was bis dahin läuft weiter pflegen (Wenn es sich nicht lohnt alles neu zu erstellen) und die Funktionen in den Tools zum gegenseitigen Aufrufen nutzen. Aber im QC ist man ja eh frei in der Auswahl des jeweiligen Testtools. Zumal HP ja ebenfalls vom "Funktionaltester" spricht und damit Winrunner u n d QTP meint. Denn beide decken nicht die gleichen Add ons ab. Und dann ist da noch die große Masse an Projekten mit laufenden Testautomaten in Winrunner die man doch nicht wirklich so vor den Kopf stoßen kann. Bei aller Liebe zum Buissness.

    Ich würde mal behaupten das Winrunner einfach schon gut ist und nicht mehr so viel Pflege bedarf wie ein neues Baby.

    Wo bei ich da nicht gegen QTP spreche. Ganz im Gegenteil. ich habe in den letzten Jahren seine Vorzüge durchaus zu schätzen erlernt. Aber es gibt halt bei Winrunner Freiheiten die ich als Kenner von TSL vermisse und erst über Umwege in QTP implementieren kann.

    Mein Vorschlag an HP wäre z. B. eine Oberfläche und ein Repository für beide tools. Da könnte HP mal zeigen ob Sie was vom Geschäft verstehen, zumal beide tools ja von Mercury entwickelt wurden.

    Das wäre dann ein super tool.

    Z. B QuickWinTestRunner SuperProfessional

    zu Deutsch: AllGeschäftlicher SchnellGewinnProbierLäufer
    (Sollten hier Assoziationen zur Eierlegenden Wollmichsau aufkommen ist dies beabsichtigt)

    Gruß

    C. Büche
    This post was modified on 12 Jan 2009 at 01:18 pm.
    • 12 Jan 2009, 10:47 am
  • Thomas Engelhardt
    Thomas Engelhardt    Premium Member
    The company name is only visible to registered members.
    Re^2: Testautomatisierung - Migration von WinRunner nach QTP
    Herr Büche, vielen Dank für Ihr feed-back!

    Zuerst einmal: die Frage nach der Durchführung einer Migration ist abhängig vom Bedarf des Kunden. Deshalb ist unsere Strategie bei der Kundenunterstützung, zuerst den konkreten Kunden-Bedarf in einem Workshop zu ermitteln und dabei gemeinsam mit ihm das geeignete Vorgehen zu finden.
    Obwohl es Werkzeuge gibt, die auf Knopfdruck eine Code-Konvertierung von TSL nach VBS (mehr oder weniger vollständig) durchführen (WinQuick und QTPGenie), gehören die meisten Kunden vermutlich in eine der beiden Kathegorien:
    * Die einen, die möchten, dass alles so bleibt wie es ist. Schließlich lässt sich WinRunner ja immer noch einsetzen. (Und zusätzliche Kosten für Weiterbildung für neue Werkzeuge kann man auch sparen.) Außerdem gibt es einige Umgebungen, die von WinRunner unterstützt werden, nicht aber von QTP (Client/Server: Forte, Delphi, Centura, Stingray, SmallTalk und ERP/CRM: Baan, PeopleSoft, Siebel5,6 GUI Client, Oracle GUI Forms).
    * Die anderen, die möchten, dass alles besser wird. Hier bietet es sich an, die Chancen zu nutzen, die QTP bietet: Modularisierung durch Actions, GUI-Elemente im Object Repository, Testdatenhaltung in Excel-Tabellen, Benutzung von externen Bibliotheken in VBS (Die Script-Sprache ist recht einfach und verbreitet).

    Zum Vorgehen: Ein sanfter Übergang nach QTP ist wegen der functional testing license ohne Mehrkosten möglich. Spätestens wenn neue Objekte/Funktionen hinzu kommen, die von WinRunner nicht mehr unterstützt werden, bietet sich ein paralleler Einsatz von beiden Testautomatisierungswerkzeugen an.
    Zudem sind TSL-Skripte auch in QTP benutzbar.

    Wohl kaum ein WinRunner-Kunde wird aus Kostengründen ganz auf Mercury-Testwerkzeuge verzichten und sich neu orientieren - z. B. in Richtung SilkTest oder Selenium. Aber auch das ist ein gangbarer Weg, der nicht prinzipiell ausgeschlossen werden soll.
    This post was modified on 14 Jan 2009 at 03:33 pm.
    • 13 Jan 2009, 5:08 pm
  • Post visible to registered members