IT -Teststrategien, -umsetzung, -technologien

IT -Teststrategien, -umsetzung, -technologien

Posts 1-9 of 9
  • Jens Wittig
    Jens Wittig    Premium Member
    The company name is only visible to registered members.
    Testmetriken - Bereich "Sackgassen" in Bug-tracking Tools
    Hallo zusammen,

    für meinen derzeitigen Kunden installiere ich derzeit 5 Testmetriken in die vorhandene Struktur. Eine davon ist das feststellen und sensibilisieren von "Sackgassen" - sprich kritische Status in Bezug auf Zuständigkeit / Solution des Bugtacking Tools. Derzeit wird dort Bugzilla eingesetzt - es wird am Dezember auf HPQC gewechselt.

    Ich versuche gerade alle kritischen Konstellationen zu ermitteln um sie frühzeitig in HPQC zu vermeiden in dem man dort bestimmte Situationen direkt unterbinden kann.

    Es wäre mir eine riesen Hilfe falls ihr möglichst viele solcher "Sackgassen" nennen könntet - irgendwie steh ich derzeit auf dem Schlauch ^^

    Beispiele die ich bisher habe:

    1.)
    Lösung --> Change Request
    Zuständigkeit --> Tester der den Bug reportet hat oder der Entwickler der den Bug als CR sieht

    Wie man hier sieht ist diese Konstallation ungünstig da hier nichts passieren wird. Weder der Tester noch der Entwickler kann den CR genehmigen oder auf later setzen.

    2.)
    Lösung --> Need more Info
    Zuständigkeit --> Entwickler

    Auch hier fühlt sich der Test nicht zuständig

    3.)
    Status --> closed
    letzte Zuständigkeit --> Entwickler

    Ist wohl in einigen Unternehmen immernoch Standard dass Entwickler Bugs closen - sollte halt nicht so sein ^^

    4.)
    Status --> Neu
    Zuständigkeit --> Entwickler

    Tatsächlich ist aber der Bugfix bereits eingespielt und ready for retest. Hier habe ich wirklich keine Ahnung wie man das tracken könnte :-/

    5.)
    Status --> unable to reproduce
    Zuständigkeit --> Entwickler

    Habt ihr evtl. Erfahrung welche solcher Konstellationen man unbedingt noch betrachten solle?

    Ich danke vorab :-)

    VG
    Jens
    • 30 Sep 2010, 6:28 pm
  • Post visible to registered members
  • Post visible to registered members
  • Jens Wittig
    Jens Wittig    Premium Member
    The company name is only visible to registered members.
    Re^2: Testmetriken - Bereich "Sackgassen" in Bug-tracking Tools
    merci schon mal für die antworten :-)

    ich habe mich nicht ganz richtig ausgedrückt:

    die zustände, wie sie im ausgangsposting beschrieben sind, sind eben genau der status quo der geändert oder aber zumindest reportet werden soll.

    z.b. need more info mit zuständigkeit entwickler --> sollte so eben nicht sein, der entwickler hat einfach vergessen die zuständigkeit auf den tester zu setzen.

    klar kann man alle paar wochen manuell da drauf schaun - aber ich würde das gerne mit einigen abfragen abfangen um dann alle beteiligten über die problematik dieser "sackgassen" zu informieren - und vor allem sie in HPQC direkt auszuschließen.
    • 01 Oct 2010, 5:04 pm
  • Martin Böhm
    Martin Böhm
    The company name is only visible to registered members.
    Re: Testmetriken - Bereich "Sackgassen" in Bug-tracking Tools
    Hallo Herr Wittig,

    ich verstehe nicht ganz, warum die Zuständigkeit manuell umgesetzt werden soll. Ein Bugtracking-Tool sollte m. E. mindestens in der Lage sein, mit einem Statuswechsel am Prozessobjekt auch die Zuständigkeit umzusetzen.
    Die Gefahr ist äußerst hoch, dass mit der Menge der CRs besonders in Multi-Projekten viele CRs übersehen werden. HPQC ist damit zugegebenermaßen nicht das beste Tool für diesen Zweck.

    Überdies sehe ich auch einen Status "unable to reproduce" oder "need more info" eher kritisch; Ein Review des Zustandsautomaten sollte im Ergebnis zeigen, dass ein Statusübergang immer genau dann erfolgt, wenn die Verantwortung über den CR wechselt. Auch halte ich das "Closen" von CRs durch Tester für nicht ganz optimal. Das sollte ein separater CR-Owner oder CR-Responsible tun, insbesondere dann wenn das Tool auch zur Abrechnung der jeweiligen Aufwände verwendet wird. Nicht selten sehen Tester, Entwickler, Auftraggeber, CR-Koordinator und Buildmanager das "erledigt" ein klein wenig anders.

    Sehr gute Erfahrungen habe ich mit Reports gemacht, die alle CRs ausgeben, die bestimmte Alterungsdaten überschritten haben, und zwar sortiert nach absteigendem Alter.
    Einige Beispiele:
    - Alle CRs die vor mehr als x Tagen das letzte mal "assigned" wurden. -> Damit erfasst man CRs, die von den Entwicklern nicht bearbeitet werden (möglicherweise weil sie zu niedrig priorisiert sind, die Entwickler überlastet sind, das Problem sich längst anderweitig erledigt hat oder was auch immer)
    - Alle CRs deren "enter" mehr als x Monate zurückliegt, aber immer noch nicht den Status "closed" erreicht haben -> Damit kann man Ping-Pong-CRs erfassen, die möglicherweise im SEP stecken geblieben sind, entweder weil nach jedem Refix der Retest immer wieder fehlschlägt oder weil zwischen CR-Anforderer und CR-Assigner Uneinigkeit über die Spezifikation herrscht.
    - Alle CRs deren "hold" mehr als x Monate zurückliegt. -> Damit kann man CRs ausschleusen, die fürs Projekt nicht mehr relevant sind, möglicherweise, weil sich Anforderungen geändert haben. Und darüberhinaus kann man das Projekt-/Anforderungsmanagement zur Konkretisierung der Projektziele anhalten.

    uswusf.

    Dabei möchte ich noch hinzufügen, dass ich den Zweck solcher Reports weniger in der Identifizierung von Sackgassen sehe, sondern sie vielmehr als Instrument zum Aufdecken und Beseitigen von Prozessunzulänglichkeiten sehe. Ein Klassiker ist das CR-Duplikate-Problem, wo zwar immerwieder sehr phantasievolle Lösungen erfunden werden, aber selten pragmatisch die Ursache der Duplikatproduktion im Projekt beseitigt wird.

    Mit freundlichen Grüßen
    Martin Böhm
    • 03 Oct 2010, 10:44 pm
  • Jens Wittig
    Jens Wittig    Premium Member
    The company name is only visible to registered members.
    Re^2: Testmetriken - Bereich "Sackgassen" in Bug-tracking Tools
    Hallo Herr Böhm,

    vielen Dank für Ihre Einschätzung. Wie von Ihnen geschrieben wäre natürlich die Ideallösung, dass solche Konstellationen gar nich erst entstehen können. Allerdings ist mir bisher kein Bugtracking-Tool bekannt bei dem man diesen Zustand de facto auschließen kann - zumindest nicht ohne erhebliches customizing.

    Genau deshalb war ja die Intention, dort eine Metrik einzusetzen - um zumindest die Prozessbeteiligten in diesem Bereich etwas zu sensibilisieren und eben bei der Einführung des QC ein Auge auf die Statusvergabe zu werfen.

    Die bisher genannten ungünstigen Konstellationen sind wahrscheinlich die am häufigsten anzutreffenden - mich würde aber interessieren ob es evtl. noch weitere "ungünstige" Status geben könnte die ich evtl. übersehen habe.

    Vielen Dank vorab
    • 05 Oct 2010, 5:55 pm
  • Post visible to registered members
  • Post visible to registered members
  • Katja Piroué
    Katja Piroué    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^2: Testmetriken - Bereich "Sackgassen" in Bug-tracking Tools
    Hallo in die Runde,

    ich denke, dass das Fehlen eines validen Defect Workflows das eigentliche Problem ist.
    Dies könnte man in Bugzilla aber genauso abbilden wie im QC.

    Dass CRs nicht bearbeitet werden liegt im organisatorischen Bereich.
    1) ein Entwickler kann zwar sagen, dass der Fehler aus seiner Sicht ein CR ist.
    Entscheiden kann aber nur der Kunde/Auftraggeber im Besten Fall ein Analyst. Für alle unklaren Fälle muss es ein CR Board/CR XY (Name wie gewünscht) geben.

    2) Eine Person - meist Testmanager oder Entwicklungsleiter beobachtet in den wöchentlichen Auswertungen, welche CRs es derzeit gibt.
    Ein Status wie: CR noch nicht angenommen o.ä. kann dabei hilfreich sein.

    3) Das CR Board muss sich in regelmäßegen Abständen treffen, zumindest bevor das nächste Release/Sprint zusammengestellt wird.

    4) ein Entwickler sollte bei neuen CRs auch die Aufwände schätzen, die dahinterstehen.

    5) Zusammensetzung des CR Boards:
    Testvertreter, Entwicklungsleiter, Analyst(falls vorhanden), Kundenvertreter( bei Spezial Themen auch ein Spezialist der Fachabteilung)

    In jedem Tool muß ein Workflow hinterlegt werden- diesen zu diskutieren kann ein Weilchen dauern, ist aber, wenn alle beteiligten Bereiche zugestimmt haben, ein wichtiger Baustein, um viele Diskussionen in heißen Projektphasen zu verhindern.

    Viel Erfolg bei der Umsetzung und: vor der Migration ist es wichtig, dass alle "schrägen" Zustände aus der Datenbank verschwinden.

    mit freundlichen Grüßen
    Katja Piroué
    • 24 Feb 2011, 08:54 am