Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Da letztendlich der Productowner zusammen mit dem Entwicklungsteam für die Qualität verantwortlich ist, gehören ja auch qualitätsbezogene Aktivitäten zum Scope der Aktivitäten. In dem ersten Artikel zur Serie über die Methode des exploratorativen Testens bin ich bereits auf die Testmethode selbst, und die Anwendungsgebiete eingegangen.
Das explorative Testen wird in der Praxis gerne verwendet, da sich ein Testprojekt hiermit durchaus spannend und lehrreich gestalten läßt. Da es normalerweise nicht gelingen wird, das ganze Produkt in einer Session zu testen, ist aber eine Methode erforderlich, die sicherstellt, daß man jeden Teil der Software einmal überprüft, und keine Bereiche ausläßt.
Hierfür verwendet man normalerweise Testtouren, wovon jede Tour einen definierten Inhalt abdeckt, und zudem durch einen sprechenden Namen gekennzeichnet ist. Im ersten Artikel zu dieser Serie (siehe Kapitel Weiterführende Informationen) habe ich einige Testtouren behandelt. Heute will ich die übrigen Touren nachliefern, für die dort der Raum nicht mehr gereicht hat.
James Whittakers hat in seinem Buch Exploratory Software Tours die wesentlichsten Touren beschrieben, die ich Ihnen hier kurz erläutere.
Jedes ältere und größere Softwareprojekt greift entweder direkt auf altes Coding zurück, oder es verwendet alte Software über eine Schnittstelle. Ziel der Museumstour ist es, genau dieses alte Coding zu prüfen. Auch, wenn Sie die Software neu erstellen, lohnt sich ein Test, der die älteren Teile miteinbezieht, einfach, um die Zusammenarbeit sicherzustellen.
Normalerweise häufen sich Fehlerstellen in einer Software, z.B weil die verwendete Technologie unstabil ist, oder das Design an seine Grenzen kommt. Normalerweise kennen Sie die Stellen nicht, sind jedoch mit zunehmender Testhäufigkeit immer besser in der Lage anzugeben, wo sich diese problematischen Bereiche vermutlich befinden. Ihre zukünftigen Tests sollten sich auf diese „üble Nachbarschaft“ konzentrieren. Die folgende Tour (Garbage Collector Tour) kann Ihnen dann dabei helfen, die Fehler aufzuräumen, die sie dort verstärkt finden.
Die Müllmänner besuchen normalerweise die gesamte Stadt, Straße für Straße, Mülltonne für Mülltonne. Dabei verweilen sie nur kurz, gehen jedoch sehr systematisch vor. Wenn Sie Ihre Software mit der Müllmanntour prüfen, besuchen Sie also jeden Teil kurz, und prüfen die Funktionsfähigkeit. Wichtig ist die systematische Abarbeitung aller Teile der Software.
Die Sammlertour zielt darauf ab, ein Feature komplett zu testen, inclusive aller Facetten. Sie ist ein wenig vergleichbar mit dem Touristen, der durch das Land reist, und überall Ansichtskarten kauft. Nur, daß Sie sich in Ihrem Test darauf konzentrieren, die Daten der Anwendung komplett zu sammeln.
Geschäftsleute reisen viel, oft und ausgedehnt. Ziel der Testtour ist es, die Software möglichst überall zu bereisen. Während des Tests führen Sie kurze und lange Touren darin durch, und versuchen sich durch möglichst viele Screens zu hangeln. Halten Sie insbesondere fest, wieviele Aktionen Sie durchführen müssen, um einen Eindruck von der Komplexität der Bedienung zu erhalten.
In Schottland gibt es viele Pubs. Einige davon sind besser, die anderen sind schlechter besucht. Genau wie in Schottland kann Ihnen auch beim Testen der Software ein Fremdenführer dabei helfen, die interessanten Stellen (und Pubs) zu finden. Die Pub Tour hilft Ihnen besonders, wenn Ihre Software komplex ist. Fragen Sie einzelne Nutzer, oder Nutzergruppen nach den Teilen der Software, die Sie besonders gut testen sollten.
Unsoziale Zeitgenossen tun normalerweise das Gegenteil von dem, was die Anderen tun. In der unsozialen Testtour konzentrieren Sie sich darauf, die Tests verkehrt herum auszuführen. Fangen Sie zum Beispiel „am Ende“ an, laden Sie Grafiken in Textfelder (und umgekehrt), oder drücken Sie die falschen Tasten. Normalerweise finden Sie hiermit die Bereiche, in denen der Entwickler die Ausnahmebehandlung vergessen hat.
Wie der Hilfsschauspieler im Fernsehen, testen Sie Ihre Software nur ungefähr. Konzentrieren Sie sich nicht auf den definierten Testfall, sondern auf die Bereiche in der Nachbarschaft. Zum Beispiel erfassen Sie eine amerikanische Adresse in einem deutschen Adressfeld, oder Sie rechnen mal mit Buchstaben, statt mit Zahlen.
In diesem Test kümmern Sie sich um die Langläufer in Ihrer Anwendung; normalerweise sind dies rechenintensive Arbeitsschritte, Datenkonvertierungen, Umformatierungsaufgaben, Datentransfers, etc. Prüfen Sie insbesondere, ob Sie diese langlaufenden Aktionen auch abbrechen können.
In diesem Scenario testen Sie, was passiert, wenn Sie mehr als eine Instanz Ihrer Anwendung gleichzeitig ausführen (z.B. 2 Browser öffnen, und dieselben Screens aufrufen). Wenn Abfragen vergessen worden sind, kann es passieren, daß sich diese beiden Instanzen in die Quere kommen. Genau auf diese Fälle haben Sie es abgesehen, wenn Sie diese Testtour verwenden.
Einige Fehler tauchen nur dann auf, wenn Ihre Anwendung lange läuft. Wenn zum Beispiel der Entwickler vergessen hat, den Speicher freizugeben, wenn er ein Objekt freigibt, wird mit der Zeit der Speicher knapp. Diese Tour zielt darauf ab, solche Situationen zu identifizieren.
Diese Tour zielt darauf ab, die gleichen Aktionen wieder und wieder zu wiederholen. Manche Fehler machen sich nämlich erst dann bemerkbar, wenn Sie oft genug wiederholen. Auch haben Sie oft Schwierigkeiten damit dieselben Fehler erneut zu erzeugen. Mit dieser Methode finden Sie Probleme, die stochastischer Natur sind.
Wie bei Supermodels üblich, interessieren Sie sich in diesem Test für die Fassade, bzw das User Interface. Die Inhalte interessieren Sie weniger. Konzentrieren Sie sich in diesem Test auf die Benutzeroberfläche, und stellen Sie fest, ob alle Bedienelemente richtig angeordnet sind, etc.
Viele Teile einer Anwendung arbeiten im Hintergrund auch dann, wenn kein User die Software verwendet. Zum Beispiel laufen viele Speichervorgänge in Hintergrund ab, ohne, daß die Benutzer aktiv arbeiten. Mit der After-Hours Tour prüfen sie solche Teile der Software gezielt.
Couch Potatoes sitzen im echten Leben vor dem Fernseher, essen Chips und schauen einen Film. Die Testmethode zielt darauf ab, ein Feature mit möglichst geringem Testaufwand zu testen. Zum Beispiel geben Sie nur genau soviele Daten ein, wie Sie benötigen, um von einem Screen zum nächsten zu navigieren. Mit diesem Sparansatz stellen Sie insbesondere sicher, daß die Standardfälle überprüft werden.
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
