Der Zehnkampf: Crowdtesting in der ISTQB-Welt

Transkript

1 Der Zehkampf: Crowdtestig i der -Welt Der Zehkampf: Crowdtestig i der -Welt Das Iteratioal Software Testig Qualificatios Board () ist heute mit über ausgestellte Zertifikate weltweit der De-facto-Stadard im Testausbildugsmarkt. Es bildet strukturiert alle Facette dieser Diszipli ab ud erläutert sie dem kudige Tester. Doch was ist der seit Jahre wachsede Bereich rud um das Crowdtestig? Wie ka es sei, dass dort scheibar jeder teste ka? I diesem Artikel solle die mit Crowdtestig verbudee Aktivitäte i der -Welt verortet werde. Im Ergebis zeigt sich, dass auch Crowdtestig echtes Teste ist. Status quo: Die beide Kotrahete I diesem Artikel soll versucht werde, die beide bisher häufig disjukte oder sogar widersprüchliche Stoßrichtuge Crowdtestig, wo jeder mitmache ka, ud -Testig, das echte Experte auszeichet, zu aalysiere ud faktische Gemeisamkeite sowie Gegesätze aufzuzeige. Hierfür werde die eizele Kotrahete i de folgede Abschitte kurz vorgestellt, bevor die Detailaalyse i Form eies Zehkampfes begit. Crowdtestig Crowdtestig, also das Teste vo Software mithilfe der Schwarmitelligez der Iteretgemeide, ist eie verhältismäßig juge Diszipli, die erst vor weige Jahre i die Softwareetwicklug Eizug gehalte hat. Der Begriff etstad i Alehug a de Termius Crowdsourcig, der 2006 vo Jeff Howe ud Mark Robiso i eiem Artikel für das amerikaische Wired Magazi geprägt wurde (vgl. [How06]). Im Gegesatz zum klassische Softwareteste komme beim Crowdtestig icht ur professioelle zertifizierte Experte zum Zuge, soder auch uvoreigeommee ud bezüglich des Testes ugeschulte Edverbraucher bzw. Laie ohe Testerfahrug ud Etwicklugsketisse. Teil der Crowd ka grudsätzlich jeder werde, der über ei iteretfähiges Gerät verfügt. Er muss sich lediglich auf der Plattform eies etsprechede Abieters registriere ud de Umgag mit seiem Gerät beherrsche. Crowdtestig als ei euer Asatz der Qualitätssicherug erfreut sich kotiuierlich steigeder Beliebtheit. Laut der aktuelle Ausgabe des jährlich erscheiede World Quality Report vo Capgemii, Sogeti ud HP, bei dem rud IT-Experte ud Etscheider aus 25 Läder zu euste Treds i pucto Softwaretestig ud Quality Assurace befragt wurde (vgl. [Cap14]), spielt Crowdtestig mittlerweile eie etscheidede Rolle i der Testig-Praxis: 2014 setze bereits 54 Prozet der Firme auf Crowdtestig bzw. plae, die Methode i ihre Etwicklugsprozess zu implemetiere. Weitere 17 Prozet der Befragte zoge eie Eiführug für 2016 bis 2017 i Betracht. Wie schell die Bekatheit der Diszipli wächst, zeigt dabei icht zuletzt der Vergleich mit dem World Quality Report , der im Oktober 2012 der Öffetlichkeit vorgestellt wurde (vgl. [Cap12]). Damals wurde och keierlei gesoderte Date zu Crowdtestig erhobe. Aber icht ur bei de Uterehme steigt die Nachfrage ach Crowd-basiertem Softwareteste. Auch die Zahl derjeige, die als Tester arbeite wolle, immt kotiuierlich zu. So sid beispielsweise bei dem 2011 gegrüdete größte deutsche Abieter Testbirds mittlerweile über Persoe registriert, um Software uter reale Bediguge auf Herz ud Niere zu prüfe. Jede Tag komme über 100 Neuamelduge hizu. Abb. 1: Das -Traiig-Schema. Status quo Das Iteratioal Software Testig Qualificatios Board () wurde im November 2002 als No-Profit-Orgaisatio gegrüdet ud hat als Missio, das Teste als professioelle Diszipli systematisch zu schule ud die Teilehmer etspreched zu zertifiziere. Heute realisiert der diese Zielsetzug auf drei aufeiader aufbauede Ebee ud bietet je Ebee uterschiedliche Testmodule a. Das vollstädige Schema ist i Abbildug 1 dargestellt. Das ist dabei als Dachverbad i über 50 Läder durch atioale Orgaisatioe vertrete. I Deutschlad überimmt diese Rolle der -Mitgrüder das Germa-Testig-Board (GTB) (vgl. [Ger-a]).

2 Der Zehkampf: Crowdtestig i der -Welt Teste ist der Prozess, der aus alle Aktivitäte des Lebeszyklus besteht (sowohl statisch als auch dyamisch), die sich mit der Plaug, Vorbereitug, Durchführug ud Bewertug eies Softwareprodukts ud dazugehöriger Arbeitsergebisse befasse. Ziel des Prozesses ist es sicherzustelle, dass diese alle festgelegte Aforderuge geüge, dass sie ihre Zweck erfülle, ud etwaige Fehlerzustäde zu fide. Kaste 1: Teste ach -Glossar (vgl. [Ger-b]). Die Aufgabe des /GTB ist es sicherzustelle, dass das Teste weltweit stadardisiert geschult wird. Dafür werde so geate Syllabi erarbeitet, die festlege, welche Ihalte ud welche Lerziele pro Testmodul zu erfülle sid. Die Erstellug vo Traiigsmaterial, die Schulug selbst ud auch die abschließede Prüfuge werde icht durch das /GTB durchgeführt, soder durch uabhägige Traiigsprovider ud Zertifizierugsstelle, dere Eigug jeweils durch das Board im Vorfeld geprüft wurde (Akkreditierug). Mit über zertifizierte Tester Die Qualitätsmerkmale sid ei Satz vo Eigeschafte eies Softwareprodukts, ahad desse seie Qualität beschriebe ud beurteilt wird. Ei Softwarequalitätsmerkmal ka über mehrere Stufe i Teilmerkmale verfeiert werde. Qualitätsmerkmale sid Fuktioalität, Zuverlässigkeit, Beutzbarkeit, Effiziez, Äderbarkeit ud Übertragbarkeit (vgl. [Ger-b]). Kaste 2: Qualitätsmerkmale ach -Glossar. weltweit ud über zertifizierte Tester alleie i Deutschlad ist dieses Traiigsschema damit heute ei De-facto- Stadard im Bereich des professioelle Testes. Der Kampf begit: Zeh Rude Im Folgede stelle wir zeh wichtige Aspekte des Testes vor. Hierbei wird auf eie sehr präzise Nomeklatur Wert gelegt, die dem frei verfügbare -Glossar etstammt (vgl. [Ger-b]). Diese soll dabei helfe, aschließed ei möglichst präzises Kotrastiere mit de Aspekte des Crowdtestigs zu ermögliche. Pro Aspekt soll sich so zeige, ob Crowdtestig überhaupt etwas mit dem -Teste zu tu hat, ob es dem -Verstädis widerspricht oder iwieweit die Methode eie kokrete Istaz des Testaspektes darstellt. Die zeh Disziplie selbst sid allesamt der -Defiitio des Testes etomme (siehe Kaste 1). Diese Defiitio wird zur Ableitug der folgede zeh Aspekte für eie Gegeüberstellug des Testverstädisses vo ISQTB ud Crowdtestig verwedet (die Reihefolge der Eizeldisziplie spielt dabei keie besodere Rolle): 1. Alle festgelegte Aforderuge (siehe Abschitt Qualitätsattribute ) 2. Alle Aktivitäte des Lebeszyklus (siehe Abschitt Teststufe) 3. Softwareprodukt ud dazugehörige Arbeitsergebisse (siehe Abschitt Testobjekte/Testelemete ) 4. Prozess (siehe Abschitt Testprozess ) 5. Sicherstelle (siehe Abschitt Testfälle ) 6. Durchführug (siehe Abschitt Testumgebug ud Testifrastruktur ) 7. Bewertug (siehe Abschitt Testergebis ) 8. Plaug (siehe Abschitt Testmaagemet ) Abb. 2: Qualitätsmerkmale der ISO

3 Eie Teststufe ist eie Gruppe vo Testaktivitäte, die gemeisam ausgeführt ud verwaltet werde. Teststufe sid mit Zustädigkeite i eiem Projekt verküpft. Beispiele für Teststufe sid der Kompoetetest, der Itegratiostest, der Systemtest ud der Abahmetest. ([Ger-b]) Testelemet bzw. -objekt ist das eizele Elemet, das getestet wird. Gewöhlich existiere ei Testobjekt ud viele Testelemete (vgl. Testobjekt i [Ger-b]). Kaste 4: Testelemet ud -objekt ach -Glossar. Der fudametale Testprozess umfasst die folgede Aktivitäte ()(vgl. [Ger-b]): Plaug ud Steuerug Aalyse ud Desig Realisierug ud Durchführug Bewertug ud Berichterstattug Abschluss der Testaktivitäte Kaste 3: Teststufe ach -Glossar. Kaste 5: Testprozess ach. 9. Fehlerzustäde (siehe Abschitt Fehlerzustäde ) 10. Zweck erfülle (siehe Abschitt Testziel ) Diszipli 1: Qualitätsattribute Sämtliche Aktivitäte rud um Qualitätssicherug diee dem Zweck, Trasparez über die Softwarequalität zu erhalte ud diese gegebeefalls zu verbesser. I der Defiitio des -Glossars wird Qualität über Qualitätsmerkmale verfeiert (Kaste 2): Softwarequalität wird folglich über mehrere Stufe i eifache hadhabbare Qualitätsmerkmale dekompoiert. Der -Schulugskao versucht, die uterschiedliche Softwarequalitätsmerkmale durch etsprechede Testmodule vollstädig abzudecke. So gibt es z.b. dediziertes Security-Teste sowie das Teste techischer Qualitätsattribute (siehe obe). Aktuelle Bestrebuge i Richtug Usability-Testig uterstütze diese Sichtweise, belege aber auch, dass der -Schulugskao och icht vollstädig ist. Das orietiert sich dabei eg a der ISO9126 (siehe Abbildug 2) ud ist aktuell dabei, die Nachfolgeorm eizubaue. Crowdtestig Crowdtestig versteht sich als euer Asatz, um die Qualität vo Software zu utersuche ud Hilfestellug bei dere Verbesserug zu leiste. Die Methode erhebt aber icht de Aspruch, sämtliche ach ISO 9126 defiierte Qualitätsmerkmale zu erfülle bzw. das Teste aller Merkmale abzudecke. Vielmehr legt Crowdtestig de Fokus auf Beutzbarkeit ud Uterkategorie vo Fuktioalität wie Richtigkeit oder Koformität. Effiziez, Zuverlässigkeit, Äderbarkeit ud Übertragbarkeit spiele higege keie bzw. ur eie utergeordete Rolle. Diszipli 2: Teststufe Die geforderte hohe Kotiuität des Testes führt dazu, dass die kokrete Aktivitäte sehr uterschiedlich sid ud auch vo gaz adere Persoe ausgeführt werde: So ist das Teste, das ei Etwickler i Form des Etwicklertests i Java realisiert, gaz aders durchzuführe, als ei Abahmetest des Gesamtsystems beim Auftraggeber. Das systematische -Testverstädis liefert für eie Klassifikatio der Testaktivitäte de Begriff der Teststufe (siehe Kaste 3). Grudsätzlich uterstützt der -Kao alle Teststufe, d.h. im Kao werde operative Methode ud Maagemetaforderuge für alle Teststufe vorgestellt. Als Beispiel sei auf die uterschiedliche White-Box-Testmethode mit etsprechede Abdeckugsmaße im TTA-Modul ebeso verwiese wie auf de Abahmetest, der Trasparez über Restrisike bei Produktivschaltug erzeugt. Crowdtestig Crowdtestig adressiert i de meiste Fälle späte Teststufe, wie z. B. de Systemtest. Das hägt gaz wesetlich vo der Eifachheit des Deploymets des System Uder Test (SUT) a die Crowd zusamme: Ei fast fertiges ud zudem meist web-basiertes System ist leichter a eie Vielzahl vo Crowdtester auszurolle als eie Teilkompoete für de Itegratiostest. Letztere bedarf vieler Stubs ud Mocks, die zwar iter vorhade sei köe, aber i de selteste Fälle eie Status habe, der ei exteres Test-Roll-Out ohe Spezialketisse ermöglicht. Deoch ist auch der Kompoetetest prizipiell möglich ud wird i eiige Spezialfälle auch durchgeführt: So ka ei Logi-Use-Case ach eier Vorbereitug durchaus auch scho ohe irgedeie Busiess Logik vo der Crowd getestet werde, um Hadhabug ud Darstellug bewerte zu köe. Dispili 3: Testobjekte/ Testelemete Eg verwadt mit der Teststufe ist die Klassifikatio der Dige, die überhaupt getestet werde: So ist es ei Uterschied, ob eie eizele Fuktio als SUT getestet wird oder ei vollstädiges System. hält hierfür die hierarchisch defiierte Begriffe Testobjekt ud Testelemete vor (siehe Kaste 4): Der -Traiigskao versucht, alle uterschiedliche Testobjekte abzudecke. Das führt dazu, dass i eiige Traiigseiheite je ach Traiigsmodul auch sehr techische Testobjekte wie Software-Code oder Kotrollfluss-Graphe bearbeitet werde. Crowdtestig Die Testobjekte bei Crowdtestig sid primär laufede Softwareaweduge mit eier GUI. Diese etstamme vor allem dem B2C-Bereich, um keie aufwädige Eiarbeitugszeite beim Crowdtester eiplae zu müsse. Testobjekte aus dem Busiesslastige SAP-FI- oder HR-Bereich sid daher selte im Fokus vo Crowdtestig bzw. werde bei Testbirds beispielsweise über de Asatz Brig-Your-Ow-Crowd abgewickelt, bei dem uterehmeseigee Mitarbeiter i de Testprozess eigebude werde. Auch Embedded-Systeme, die keie oder weig GUI habe, soder dere Fuktioalität primär im Dateaus- 01/

4 Der Zehkampf: Crowdtestig i der -Welt Die Testfälle umfasse folgede Agabe: die für die Ausführug otwedige Vorbediguge die Mege der Eigabewerte (ei Eigabewert je Parameter des Testobjekts) die Mege der vorausgesagte Ergebisse die erwartete Nachbediguge. Testfälle werde etwickelt im Hiblick auf ei bestimmtes Ziel bzw. auf eie Testbedigug, wie z. B. eie bestimmte Programmpfad auszuführe oder die Übereistimmug mit spezifische Aforderuge zu prüfe (wie Eigabe a das Testobjekt zu übergebe ud Sollwerte abzulese sid) (vgl. [Ger-b]). Kaste 6: Testfälle ach. tausch mit physische Devices liegt, komme kaum für Crowdtestig i Frage. Diszipli 4: Testprozess Bereits die Defiitio des Testes als Prozess zeigt deutlich das Bestrebe des IST- QB, Teste zu professioalisiere, d.h. plabar, auskuftsfähig ud steuerbar zu gestalte. Hierfür schult der de so geate fudametale Testprozess, dem sich alle Testihalte uterorde (siehe Kaste 5): Ebeso stadardisiert wie die Defiitio ist mittlerweile auch die etsprechede Visualisierug dieses Prozesses (siehe Abbildug 3): Crowdtestig Betrachtet ma de Testprozess eies Objekts im Gesamte, so liegt der Fokus vo Crowdtestig im Bereich der Testdurchführug. De für die meiste Uterehme ist die Methode ur ei Bestadteil bzw. eie Kompoete i ihrem fudametale Testprozess. Utersucht ma Crowdtestig jedoch als eigee Testprozess, so umfasst es wiederum sämtliche ach defiierte Aktivitäte. Die Zustädigkeite sid jedoch je ach Aktivität auf verschiedee Schulter verteilt. Dabei muss zuächst uterschiede werde, ob Uterehme de Crowdtestig-Diestleister mit dem Projektmaagemet beauftrage oder im Rahme eier Self-Service-Optio lediglich die Ifrastruktur utze ud die Tests selbst aufsetze ud die Ergebisse auswerte. Im so geate Maaged Service, der die Grudlage der vorliegede Erläuteruge ist, gibt es drei uterschiedliche Rolle: Die Testifrastruktur umfasst die orgaisatorische Elemete, die für die Durchführug des Tests beötigt werde, bestehed aus: Testumgebug Testwerkzeuge Büroräume Verfahre usw. Testumgebug wird beötigt wird, um Tests auszuführe. Sie umfasst Hardware, Istrumetierug, Simulatore, Softwarewerkzeuge ud adere uterstützede Hilfsmittel (vgl. [Ger-b]). Kaste 7: Testifrastruktur ud -umgebug ach. de Auftraggeber, der die Software etwickelt hat, de Crowdtestig-Diestleister mit seie Testmaager, die Tester selbst. Abb. 3: Fudametaler Testprozess ach. Der Testmaager des Crowdtestig-Abieters steht dabei i egem Austausch mit dem Kude bzw. Auftraggeber. Bei der Plaug ud Itegratio vo Crowdtestig i bestehede Prozesse steht der Abieter dem Kude berated zur Seite. Normalerweise bespreche die beide Parteie im Rahme eies Kick-Off-Meetigs zu Begi eies Projekts gemeisam mögliche Fragstelluge ud Probleme ud lege das Testdesig fest. Die Steuerug des gesamte Prozesses erfolgt da durch die Plattforme. Bei der Realisierug ud Durchführug iklusive Bewertug komme wiederum die Crowdtester selbst is Spiel. Sie führe die geforderte Testschritte durch ud reporte diese. Bei der Auswertug der Testberichte kommt es abermals zu eiem Rollewechsel. Die vo de Tester erstellte Protokolle werde durch de Abieter aggregiert ud kosolidiert ud zum Abschluss der Aktivitäte a de Kude übergebe. I desse Veratwortug liegt es da, die gefudee Fehler oder Usability-Probleme zu behebe. Diszipli 5: Testfälle Die Sicherstellug i der Test-Defiitio (siehe obe) verlagt die Reproduzierbarkeit des Testes: Was sid die Vorbediguge, was muss wirklich i welcher Umgebug wie durchgeführt werde, gege was wird das Ergebis kotrastiert ud was sid sostige otwedige Nachbediguge. Grudlage dieses systematische, reproduzierbare Testes sid laut die so geate Testfälle (siehe Kaste 6): Crowdtestig Beim Crowdtestig wird zu rud zwei Drittel explorativ getestet. Hierzu erhalte die Tester typische High-Level Use-Cases, die im Rahme des Testdesigs vo Kude ud Crowdtestig-Diestleister gemeisam festgelegt wurde. Daebe ka aber auch mithilfe vo systematische Testfälle gearbeitet werde. Diese werde vom Auftraggeber geliefert oder köe vom Crowdtestig-Abieter zusamme mit dem Kude aus de spezifische Aforderuge a die Software abgeleitet ud formuliert werde. Im Rahme der Testdurchführug werde diese da vo de Crowdtester abgearbeitet ud dokumetiert. Diszipli 6: Testumgebug/ Testifrastruktur Die Durchführug vo Tests beötigt bestimmte Ressource. Das fägt bei dem Mesche (oder im Falle der Automati- 72

5 schwerpukt Tipp 4: Abahmetests sollte immer grü Das sei Testergebis Zero Bug ist Policy. das Ergebis der Auch Ausführug we das Release eies och Tests. ei Dazu paar Woche gehöre etfert (vgl. [Ger-b]): sei mag, ist es sehr wichtig, Testfälle icht läger als otwedig fehlschlage zu lasse auch Bildschirmausgabe we ma die vermutliche Ursache ket. Ei fehlschlageder Testfall ka durchaus Dateäderuge Probleme verdecke, die erst ach Behebug der Berichte offesichtliche Ursache zu Tage trete. Ziel des Versedete Mitteiluge Teams muss es sei, die Testfälle auch währed der Etwicklug grü zu halte. Grü bezieht sich hier auf die Sigalfarbe, die traditioell i Build- Umgebuge Kaste 8: Testergebis eigesetzt werde. ach. sierug bei dem Computer) a, der die Tests durchführe soll ud der hierfür bestimmte Zuarbeit (Raum, Strom usw.) gehesweise, we die Erweiterug durch beötigt. Aber auch fei-graularer gibt Umpriorisierug doch icht stattfidet ud es für bestimmte Testobjekte bestimmte die Tests weiterhi mauell durchgeführt Aforderuge a die Umgebug, die otwedig sid. Das köe mobile Edgerä- werde müsse. Aus userer Erfahrug loht sich eie te, WLAN, ei SAP-Umsystem oder adere sprechede, achvollziehbare Zuordug architektoische Kompoete sei. vo Aforderuge (User-Storys) ud Akzeptaztests. Wird eie Aforderug verädert oder erweitert, fließt der Auf - Der lehrt für diese otwedige Beistellleistuge die beide hierarchisch zuei- wad für eie otwedige Apassug besteheder Akzeptaztests mit i die ader stehede Begriffe Testifrastruktur ud Testumgebug (siehe Kaste 7). Schätzug ei. Gibt es außerhalb des Etwicklugsteams Iteressete für die Akzeptaztest-Kriterie, erhalte diese Crowdtestig wertvolles Feedback zu de Auswirkuge Die Ifrastruktur wird beim Crowdtestig der Äderug. Köe Aforderuge ud durch de Tester selbst bereitgestellt. Er arbeitet vo zuhause aus, a eiem vo ihm Akzeptaztests eiader icht zugeordet werde, kommt das böse Erwache bei der gewählte Ort oder bei der Eibidug vo Etwicklug: Die Äderuge dauer füf Locatio Based Services am jeweils erforderliche Stadort bzw. i der etspreche- Miute, das Apasse der fehlgeschlagee alte Akzeptaztests zwei Tage. de Zoe. Die Tester überprüfe die Aweduge auf ihre eigee Geräte, also Mauelle Tests Smartphoe, PCs oder Tablets, wodurch Mauelle Tests sid auch i agile Pro - poteziell eie eorme Vielfalt a Geräte jekte wichtig. Sie schließe die Lücke zwische automatisierte Tests ud aufwädig ud Betriebssysteme zur Verfügug steht, die vo Uterehme mit eiem eigee oder gar icht automatisiert prüfbare Gerätepool so kaum abzubilde ist. Aforderuge. Dabei köe mauelle Beötigt der Crowdtester für die Durchführug des Tests jeseits seier eigee tech- Tests zeitaufwädig ud fehlerafällig sei. Auch i der agile Welt eige Projekt - ische Geräte weitere Hilfsmittel, Werkzeuge oder Hardware, so stelle ihm diese teams dazu, mauelle Tests zu verachlässige, we die Zeit am Ede eier der Auftraggeber bzw. der Crowdtestig- Diestleister zur Verfügug. Der Abieter trägt die Tipp Veratwortug 5: Pair-Testig dafür, im UAT. dass die Tester Zugriff User-Acceptace-Tests auf die Testobjekte sollte habe. dabei ieapps im Beta-Stadium durch die Softwareetwickler müsse über etsprechede Distributiosplattforme führt werde. UAT mittels Pair-Testig wie etwa hatbird- Flight sich verteilt dagege werde. bewährt. Zugriff Hier führt auf Stagig ei durchge- Umgebuge Beutzer werde UAT durch, beispielsweise der Etwickler mittels O Demad-Verbiduge sitzt daebe ud bekommt via direkt SSH wert-odevolles Feedback zur Beutzbarkeit seier VPN hergestellt. Wie bereits Arbeit. Im uter Idealfall dem ist Pukt dieser Tester Testobjekt der erläutert, Kude wird selbst Crowdtestig oder ei Mitarbeiter ormalerweise vor fem allem fachliche bei Wisse, Aweduge aber keie weite- aus dem mit tiere Ketisse über de Quellcode. Iteratio kapp wird. Das führt zu eiem Zum Testmaagemet gehöre die gefährliche Trugschluss: We es akzeptabel ist, mauelle Tests im Notfall wegzu- Plaug, Aufwadsschätzug, Überwachug ud Kotrolle vo Testaktivitäte, die üblicherweise durch eie lasse, sid sie scheibar icht wichtig. Auch i der agile Welt ist es der Zweck Testmaager erfolge (vgl. [Ger-b]). vo Tests, Fehler i der Software zu fide. We automatisierte Tests dazu ur bedigt i der Lage sid, gibt es lediglich Kaste 9: Testmaagemet ach. eie Alterative: mauelles beziehugsweise exploratives Teste, bei dem die Tester ihre Kreativität ud Spotaität eisetze, um Fehler zu fide. Ei wesetlicher Nutze maueller Tests besoders B2C Bereich eigesetzt, sodass die Testumgebug isgesamt überschaubar bleibt. bei eue Features ist die kotextbezogee Perspektive auf die zu prüfede Weitere Hardware für B2C-Tests würde Fuktioalität. De im Gegesatz zu sich typischerweise i de Größeordug automatisierte Tests ket der mauelle vo beispielsweise Set-Top-Boxe, Messgeräte für de Hausgebrauch oder Baby- Tester dere aktuelle Kotext. We es Kude ud Budget zulasse, phoes befide. plae wir am Ede eier Iteratio für alle Etwickler eie Tag ei, desse Fokus auf maueller Testdurchführug liegt. Ziel dieses Tages ist es, die Software zerbreche zu Diszipli 7: Testergebis Die Bewertug eies Softwareproduktes lasse. Geligt es, de Code durch Beut - wird etlag des -Stadards idealerweise icht ad-hoc oder aus dem Bauchge- zer eigabe oder Datekostellatioe zu zerbreche, wird für die Situatio, die dazu fühl heraus gemacht, soder fußt auf dem geführt hat, ei automatisierter Test Ergebis durchgeführter Tests mit systematische Testfälle. geschriebe. Aschließed wird der Ma - gel ach voll ziehbar behobe ud mit dem automatisierte Test dafür gesorgt, dass die so ge woee höhere Robustheit erhalte defiiert daher als Grudlage eier bleibt. solche systematische Bewertug das Testergebis (siehe Kaste 8): Plädoyer für Nicht- Diese Testergebisse bilde aschließed Automatisierug die Grudlage, um gemeisam mit dem We die geforderte Fuktioalität implemetiert wurde, also sämtliche automati- Gesamt-Systemveratwortliche eie systematische Bewertug des Softwareproduktes durchzuführe. Es ist daher durchaus sierte Tests durchgeführt ud um evetuell otwedige mauelle Tests der eue im Sie eies -Testes, ei Produkt Features ergäzt wurde, schließt sich eie mit bekate Fehler i Produktio zu weitere mauelle Stufe a. ehme. Die Testergebisse solle aber eie Der User-Acceptace-Test (UAT) diet möglichst vollstädige Liste dieser Fehler dazu, eie Software uter reale Bedi gu - ethalte ud eie Bewertug bezüglich des ge zu teste ud zu prüfe, ob eie damit mögliche Risikos erlaube. Software effiziet ud effektiv geutzt werde ka. Software, die für Edaweder Crowdtestig gedacht ist, muss bei dieser Testart vom Auch Crowdtestig agiert mit systematische Testergebisse: Jeder Tester muss Beutzer selbst geprüft werde. Dazu ist es otwedig, de fachliche Kotext der zu prüfede Soft ware zu kee ud eizu- OBJEKTspektrum ist eie Fachpublikatio des Verlags: SIGS DATACOM GmbH Lidlaustraße 2c Troisdorf Tel.: / Fax: / ifo@sigs-datacom.de beziehe. Test werk zeuge sid hierzu icht Mit Failure wird die Abweichug eier i der Lage. Aus userer Sicht ist ei vollstädig automatisierter UAT auch i der Kompoete/eies Systems vo der erwartete Lieferug, Leistug oder dem agile Welt icht seriös durchführbar ausgeomme automatisierte Smoke-Tests, die Ergebis bezeichet (vgl. [Ger-b]). die Vollstädigkeit der Fuk tio alität oberflächlich prüfe. Gele getlich werde automatisierte GUI-Tests (Graphi cal-user- Kaste 10: Failure ach. Iterface) als UAT bezeichet. Diese Tests sid fuktioale Tests uter Eibeziehug eier Oberfläche ud köe zum Beispiel im Regressiostest eie wertvolle Beitrag leiste. Sie sid aber kei Er satz für die sei Vorgehe mit etsprechede Screeshots dokumetiere, die getätigte Ei- Eibeziehug des Mesche als Tester. ud Ausgabe hiterlege ud gegebeefalls Abweichuge zwische Soll- ud Ist aufzeige. Tipp Diese 6: Zeitaher Teil-Testergebisse UAT. werde dem Kude Währed allerdigs der UAT i icht der klassische direkt übermittelt, Projektwelt soder eie erst abgeschlossee sauber kosolidiert. Phase Hierzu gehöre darstellt, bietet das es Etfere sich i agile vo Projekte Redudaze, a, das umittelbar Cluster ach vo dem Testergebisse Abschluss eier etspreched Fuktioalität bestimmter Nutzer-Feedback Use-Cases eizuhole. Will der zum Etwickler Thema i Folge Eilogge) des (z.b. alle Testergebisse ud eie Feedbacks Stadardisierug Äderuge vorehme, bezüglich istder Testergebisform. seie Arbeit Diese effektiver Aufgabe als ach wird eiem vom UAT-Feedback mehrere Woche. Testmaager beim Crowdtestig-Abieter durchgeführt. Das abschließede Ergebis wird gaz ach dem Systemveratwortliche zugespielt, um ihm damit eie Ei Fokus des UAT liegt auf der Istal - lierbarkeit der Software. Diese lässt sich systematische Bewertug zu ermögliche. leicht i Kombiatio mit der obe beschriebee automatisierte Prüfug auf Vollstädigkeit awede: We dieser Diszipli 8: Testmaagemet Smoke-Test erfolgreich war, ließ sich die Software offebar erfolgreich istalliere. Grudaahme des -Verstädisses Ziel des UAT ist es, die Beutzbarkeit eier vo Teste ist, dass es sich hierbei um eie Software zu prüfe. Aus eigeer Erfahrug eigestädige Fachdiszipli ierhalb des wisse wir, dass für eie erfolgreiche UAT Projektes hadelt. Die fixe Parameter eies i alle Teststufe gewissehaft gearbeitet Projekts (Budget, Zeit, Qualität) müsse daher aber mit der Testdiszipli sychroisiert werde muss. Für Et wickler gibt ichts Schlimmeres als eie UAT, der vo de sei. Diese Aktivität wird als Testmaagemet bezeichet (siehe Kaste 9): Tester oder vom Kude ach weige Miute abgebroche wird, weil viele offesichtliche Fehler i de vorherige Teststufe Die Testaktivitäte müsse folglich ebeso geplat ud budgetiert werde wie icht etdeckt wurde ud der Software otwedige Hardware, Software ud Etwicklugstätigkeite. Auch hier zeigt das magelde Qualität bescheiigt wird. -Verstädis eie hohe Pragmatismus, de es gibt kei Teste um jede Last ud Performace-Tests Die Teststufe Last- ud Performace-Tests diet im Wesetliche dazu, drei icht- 01/ /

6 Der Zehkampf: Crowdtestig i der -Welt Crowdtestig ist eie Testmethode, um vor alle Dige die Qualitätsattribute Beutzbarkeit ud die Uterkategorie vo Fuktioalität wie Richtigkeit oder Koformität zu teste. Dabei fokussiert es spätere Teststufe wie de Systemtest, da das Testobjekt meist eie laufede IT-Awedug ist. Crowdtestig ist eie besodere Methode der Testdurchführug, die sich als Ergebis der etlag des fudametale Testprozesses vorgelagerte Schritte der Plaug, Aalyse ud Desig da besoders abietet, we es um explorative Tests mit der Vorgabe eiiger weiger High-Level-Use Cases geht. Die uterschiedliche Testumgebuge werde dabei vo de Tester mitgebracht ud bedürfe im Desig ur der Vorgabe kokreter Aforderuge. Das Testergebis wird vo de Tester zetral erfasst ud vo eiem kleie Testmaagemet ierhalb der Durchführugsphase systematisch so aufbereitet, dass der Status quo des getestete Produktes klar ersichtlich wird ud dem große Testmaagemet weiter verarbeitet werde ka. Crowdtestig liefert so uterschiedliche Fehlerwirkuge ud ikludiert isbesodere Behideruge bei der Zweckerfüllug des Produkts. Kaste 11: Crowdtestig etlag dieser Aalyse. Preis oder Teste bis zum Abwike. Der Testaufwad orietiert sich wie adere Aktivitäte a produktspezifische Parameter (Komplexität, Wiederverwedugsgrad, Veretztheit usw.), orgaisatorische Parameter (Haftugsfrage, verfügbare Testexpertise usw.) ud awedugsspezifische Parameter (Risikobewertuge, Awedugsdauer usw.). Ei Testmaagemet stellt sicher, dass diese Plaug währed des Testes eigehalte wird, oder weist frühestmöglich auf begrüdete Abweichuge hi (we z.b. bestimmte Aahme icht zutreffe, wie fuktioierede Umsysteme). Crowdtestig Das umfassede Testmaagemet erfolgt beim Crowdtestig zumeist beim Auftraggeber. Dieser hat eie Gesamt-Testpla, der gegebeefalls eie Aufgabeblock Crowdtestig ethält. Im Rahme des Maaged Services wird das Maagemet dieses Blocks da dem Crowdtestig-Provider über eie Vertrag weitergeleitet. I diesem sid üblicherweise Laufzeite, Koste ud Abdeckugsmaße festgehalte. Der Crowdtestig-Abieter überimmt bei Beauftragug diese Teilblock ud führt für ih das Testmaagemet durch. Eie Besoderheit dieses Testmaagemets ist die eigeschräkte Möglichkeit der Kotrolle, da es keierlei Weisugsbefugis gegeüber dem Crowdtester gibt. Kompesiert wird dies meist durch das Gesetz der große Zahle: So werde kritische Testaktivitäte durchaus mehrfach vergebe, um sicherzustelle, dass die Ergebisse zum gewüschte Zeitpukt i etsprecheder Qualität vorhade sid. Diszipli 9: Fehlerzustäde Bereits die -Defiitio vo Teste adressiert de Bereich vo Fehler, i dem sie das Aufdecke vo Fehlerzustäde als Testziel et. Diese aufgedeckte Defekte müsse icht i jedem Fall für de Beutzer sichtbar werde, es besteht lediglich ei Potezial für eie Produktbeeiträchtigug. Typische Fehlerzustäde ohe Außewirkug sid White-Box-Defekte, wie z. B. fehlede Speicherfreigabe eizeler Objekte: Diese habe prizipiell das Potezial, das Produkt zu beeiträchtige, i dem es z.b. lagsamer wird, werde aber i der Regel icht offekudig. Solche Fehlerzustäde mit eier ach auße direkt sichtbare Falschwirkug werde als Fehlerwirkug (Failure) bezeichet (siehe Kaste 10): Etlag des -Verstädisses hat Teste das Ziel, die vorhadee Fehlerzustäde möglichst systematisch aufzudecke. selbst spricht hier sogar vo eier Fehlertaxoomie, da jeder Fehlerzustad uterschiedliche Charakteristika aufweist (z. B. Etwicklugsphase, i der der Fehlerzustad iduziert wurde, Kritikalität eier Fehlerwirkug). Das Testergebis etlag des -Verstädisses umfasst also icht ur die pure Listug vo Fehlerzustäde, soder die Eiordug ierhalb eier projektspezifisch zu erarbeitede Fehlertaxoomie. Crowdtestig Beim Crowdtestig überprüfe die Tester icht ur die Beutzerfreudlichkeit eier Software, soder je ach Aforderug des Auftraggebers auch Teilaspekte der Fuktioalität. Mithilfe vo strukturierte Testfälle oder ahad typischer High-Level Use-Cases begebe sich die Tester auf die Suche ach Defekte, welche die Fuktiosweise der Awedug beeiträchtige, also ach Fehlerwirkuge. Alle ach auße sichtbare Fehlerzustäde werde vo de Tester geau dokumetiert ud mithilfe vo Screeshots oder auch Screecast belegt. Die Testmaager des Crowdtestig-Abieters überprüfe bei alle eigereichte Abweichuge ud Fehler, ob diese vollstädig ud achvollziehbar dokumetiert wurde, ud kategorisiere sie aschließed etspreched ihrem Schwierigkeitsgrad vo kritisch über schwer hi zu mittel ud leicht i eie etsprechede Fehlertaxoomie. Kritische Fehler gefährde dabei die komplette Fuktioalität des Systems oder eizeler awedugsspezifischer Norme ud sollte daher so schell wie möglich behobe werde. Die fertige Bug-Liste köe vom Aufraggeber i gägige Trackig-Systeme wie JIRA exportiert werde. Die Behebug der Fehlerzustäde liegt dabei komplett i der Veratwortug des Kude. Crowdtestig fidet daher Fehlerzustäde mit -wirkuge ud listet diese als Ergebis ierhalb eier eifache Fehlertaxoomie. Diszipli 10: Testziel Ei besoderes Testziel vo, das bereits i der Testdefiitio geat wird, ist die Sicherstellug der Zweckerfüllug. Die deutliche Erweiterug des Testfokus gegeüber der reie Prüfug, ob Aforderuge erfüllt werde, soll folgedes Beispiel verdeutliche: Ei systematisches Teste vo Schwimmweste, die laut präziser Spezifikatio aus Stahl ud Beto herzustelle sid, ka zwar sicherstelle, dass diese Aforderuge allesamt erfüllt werde, das Testziel der Zweckerfüllug geht hier allerdigs weiter, idem geprüft wird, ob der Zweck der Schwimmweste mit dem spezifikatioskoforme Produkt zu erreiche ist. Das Testziel hat also etlag des - Verstädisses immer auch de Awedugskotext im Fokus, was isbesodere deutlich erweiterte Aforderuge a die Tester stellt. Viele große Testorgaisatioe 74

7 strukturiere allei aus diesem Grud ihre Tester ach Brache, um z.b. für das Teste eier Versicherugsapplikatio etsprechedes Brachewisse für die Frage ach der Zweckerfüllug als Testziel eibrige zu köe. Crowdtestig Das Testziel der Zweckerfüllug steht beim Crowdtestig deutlich im Vordergrud. Hauptkriterium der Testerselektio ist eie hohe Nähe zum spätere typische Aweder. Ei Großteil der dem Crowdtestig zugeführte Applikatioe adressiert de B2C-Markt, d.h. der spätere Edkude wird etlag der geschickte Selektio beim Crowdtestig direkt is Teste ivolviert ud ka daher so gut wie kaum ei aderer über das Testziel der Zweckerfüllug etscheide. Bezoge auf die Uterscheidug zwische der Product Quality ud der Quality i Use (vgl. ISO 25010) fokussiert Crowdtestig deutlich die Quality i Use, die das Produkt hisichtlich seier Fähigkeit beurteilt, de Nutzer bei der Lösug seier Aufgabe zu uterstütze. Ud geau hier liefert Crowdtestig als Methode eie eizigartige Mehrwert, da die aus de riesige Pools selektierte Tester im Idealfall bereits die spätere Edkude sid. So ka die Quality i Use uter reale Bediguge ud außerhalb eier küstliche Laborsituatio durch Persoe beurteilt werde, welche die Aweduge theoretisch auch später im Gebrauch habe köte. Crowdtestig legt etlag der -Nomeklatur de Testziel-Fokus auf die Zweckerfüllug. Literatur & Liks [Cap14] Capgemii, Sogeti, HP, World-Quality-Report , Ausgabe 6 Cap12] Capgemii, Sogeti, HP, World-Quality-Report , Ausgabe 5 [Ger-a] Germa Testig Board, GTB, siehe: [Ger-b] /GTB Stadardglossar der Testbegriffe, siehe: [How06] J. Howe, The Rise of Crowdsorcig, i: WIRED Magazi (Olie), 2006, siehe: Crowdtestig präzise defiiert Wie der obe beschriebee Zehkampf gezeigt hat, lasse sich die Besoderheite vo Crowdtestig im -Glossar sehr gut verorte: Sämtliche Aspekte des Testes werde teilweise i stark spezialisierter Form vo Crowdtestig adressiert. Damit ka Crowdtestig u wie folgt sehr präzise defiiert werde (siehe Kaste 11). Crowdtestig: Nicht stattdesse, soder auch ist mit über zertifizierte Tester der De-facto-Stadard im Bereich des Testes: Mit seie drei Ebee ud uterschiedliche Spezialtheme deckt es alle Bereiche des Testes vo Software ab. Das Crowdtestig als sehr juge Testdiszipli immt am Markt effektiv rasat a Fahrt auf, ohe jedoch systematisch im -Verstädis jemals verortet worde zu sei. Dieses Vakuum gibt provokative Aussage Vorschub, wie z. B.: war gester, heute ist die Crowd. Systematisches Teste ach hat keie Platz für die Crowd. I diesem Artikel kote systematisch gezeigt werde, dass Crowdtestig eie wohldefiierte Ort im -Verstädis besitzt. I zeh Disziplie rud um die betrachtete Qualitätsattribute, die uterstützte Teststufe, die relevate Testobjekte/Testelemete, de zu Grude liegede Prozess, die agewedete Testfälle, die otwedige Testumgebug/ Testifrastruktur, das erwartete Testergebis, das fortwährede Testmaagemet, die aufgedeckte Fehlerzustäde sowie das Testziel ka Crowdtestig als eie spezifische Testmethode aufgefasst werde. Diese ersetzt keieswegs das klassische Teste, soder ist komplemetär vor alle Dige für iovative B2C-Aweduge im mobile Kotext geeiget. Ei so eigesetztes Crowdtestig ka sich hervorraged i ei -koformes Teste itegriere. Die Autore Georg Hasbauer (g.hasbauer@testbirds.de) ist Grüder ud Geschäftsführer des Crowdtestig-Spezialiste Testbirds ud veratwortet die Bereiche Fiaze ud Cotrollig. Er ist für das strategische Busiess Developmet sowie die Zusammearbeit mit Großkude zustädig. Dr. Frak Simo (frak.simo@bluecarat.de) ist Mitglied der Geschäftsleitug vo BLUE- CARAT, eiem mittelstädische IT-Beratugshaus. Er ist im Vorstad des Germa Testig Boards, Vorsitzeder der BITKOM-Lekugsausschusses Software ud Leiter des BITKOM- Arbeitskreises Software-Architekture. Veroika Wasza (v.wasza@testbirds.de) ist Marketig&PR-Maageri bei der Testbirds GmbH ud betreut isbesodere die DACH- Regio. Sie verfügt über lagjährige Erfahrug i der Öffetlichkeitsarbeit mit Fokus auf B2B ud digitale Theme. 01/