Mit dieser Aussage erntet man im Allgemeinen Kopfnicken bei den Betroffenen. Aber stimmt das wirklich? Und falls ja – ist mobiles Testen an sich komplex oder nur im Vergleich zu anderen Testarten? Und woher kommt diese Komplexität?

Im Testen nichts Neues

Zugegeben, wenn man die Vielzahl der möglichen Übertragungstechniken, Schnittstellen, Sensoren, Plattformen und Betriebssysteme, Bildschirmgrößen, Gerätehersteller, Apps, Browser und nicht zuletzt die schier unendliche und ständig wachsende Anzahl an Geräten betrachtet, dann ergibt sich schnell das Bild einer diversifizierten und fragmentierten Technologielandschaft in der man den Überblick verlieren kann.

Auf der anderen Seite kann man aber argumentieren, dass die einzelnen Bestandteile des mobilen Testens an sich nichts Neues sind: Cross-Browser, Usability, Accessibility, Networking, Performance, Services – das alles kennen wir doch eigentlich schon. Multipoint-Touchscreens und Wischgesten alleine rechtfertigen nicht von höherer Komplexität beim Test zu reden (wobei ihre Portabilität sich hin und wieder schon recht lästig gestaltet).

Komplexität? Nein.

Trotzdem erlebe ich immer wieder, dass mobile Projekte spätestens beim Test in Schieflage geraten. Aber warum? Meiner Meinung nach nicht weil es um Komplexität geht – sondern um Intensität. Die Intensität des Testens ist im mobilen Bereich anders – nämlich viel höher. Dies wird durch einige Faktoren bestimmt auf die ich im weiteren genauer eingehe.

Selten sind die Prozesse der Projektabwicklung von Angebot über Anforderungen, Design bis Test so sauber verzahnt und aufeinander abgestimmt, dass nicht doch kleine Reibungsverluste entstehen. Die daraus resultierenden Auswirkungen sind oft bekannt und spürbar, können jedoch ausgeglichen werden. Beim mobilen Testen wird aber ein größeres und anders strukturiertes Arbeitsvolumen in diese Prozesse gekippt. Ursprünglich nur marginale Reibungsverluste potenzieren sich zu handfesten Problemen.

Der Auslöser ist die Intensität, die mobiles Testen mit sich bringt und die meiner Meinung nach von den folgenden Faktoren bestimmt und beeinflusst wird:

Faktor 1: Druck

Zum einen haben wir im mobilen Markt eine extreme Dynamik stetiger Veränderung. Die Nutzer konsumieren und kommunizieren zunehmend mobil und sind dort statt über andere Kanäle erreichbar. Das erhöht den Druck auf Hersteller und Dienstleister sich mit dem Thema „mobile“ auseinander zu setzen. Wer keine mobile Präsenz zeigt existiert nicht. Die Folge: Alles drängt zu mobile, der Zeit- und Konkurrenzdruck nimmt zu.

Zum anderen steigt die Bedeutung der beim Endkunden wahrgenommenen Qualität eines mobilen Auftritts: Eine schlechte App-Bewertung ist unmittelbar weltweit öffentlich. Ein schlecht gemachter mobiler webshop wird potentielle Käufer nicht dazu bewegen zur Desktopseite zu wechseln – sondern zum besser funktionierenden mobilen webshop der Konkurrenz.

In früheren Zeiten verlief ein Softwarevertrieb à la Bananenprinzip relativ glimpflich: Qualitäts- oder Sicherheitsprobleme drangen nur selten an die große Öffentlichkeit. Wenn dies geschah, dann erst wenn Fachjournalisten auf das Thema aufmerksam wurden, es in einem Artikel publiziert wurde, die Print-Ausgabe erschien und die angesprochene Leserschaft es konsumierte. Damit blieb dem Hersteller immerhin eine gewisse Schonfrist um entsprechende ServicePacks vorzubereiten.

Das ist heute anders: Nicht nur Software ist rund um die Uhr weltweit sofort für jeden verfügbar sondern auch das Feedback dazu. Dies gilt in besonderem Maße für den mobilen Bereich der naturgemäß über ganz eigene Denkweisen und Techniken speziell für sofortige Softwareverteilung und Kommunikation verfügt. Und es vergeht kaum ein Tag, wo nicht Mängel (besonders im Bereich Datenschutz oder -sicherheit) quasi in Echtzeit in die öffentliche Berichterstattung gelangen.

Allen an der Produktion eines mobilen Angebots beteiligten Parteien sollte also die eminente Bedeutung von Qualität einleuchten. In diesem Kontext schauen wir jetzt auf Faktor 2.

Faktor 2: Kosten

Entwicklung und Betrieb eines mobilen Angebots unterliegen denselben ökonomischen Gesetzen wie alle anderen Gewerke, Produkte oder Dienstleistungen. Mit anderen Worten: Es kostet. Die Tendenz, möglichst wenig Geld für die Produkion von etwas auszugeben (besonders wenn es, wie viele mobile Angebote, kostenlos erhältlich sein soll) leuchtet selbst dem betriebswirtschaftlichen Laien ein. Da man aber auf Entwickler nicht verzichten kann wenn etwas entwickelt wird, bleibt eigentlich nur noch ein größerer Posten übrig um Kosteneinsparungen zu realisieren: Der Test.

Eine Diskussion, auf welche funktionalen Teststufen oder Testarten (mit entsprechendem Risiko) verzichtet werden kann, endet im mobilen Bereich gewöhnlich mit dem Fazit, dass auf alles verzichtet werden kann – außer dem Acceptancetest. In fast allen kleineren mobilen Projekten an denen ich teilgenommen habe war das sogar die einzige de facto stattfindende Testphase. Da diese Tests aber leider noch immer am Ende der Delivery-Nahrungskette eines Projekts stehen, beginnen sie für gewöhnlich in einem Umfeld das geprägt ist von aufgezehrten Budgets, akkumulierten Verspätungen, gewachsenen „known issues“ …und dem in Stein gemeißelten Releasedatum.

Um es zu verdeutlichen: Beim mobilen Testen reden wir hier grob gesagt von der Testphase in der es darum geht, auf möglichst vielen Geräten aus Endbenutzersicht möglichst viel Funktionalität positiv beurteilen zu können. Und diese Testphase – auf die wie gesagt auch niemand verzichten mag – beginnt also später als geplant, ist von geringerer Dauer und dann auch noch Kandidat für potentielle Einsparungen? Da ist die Schieflage vorprogrammiert.

Wer sich zu Qualität bekennt aber dieser nicht die höchste Priorität einräumt sollte sich der Kurzlebigkeit eines potentiellen Release-Erfolgs bewusst sein. Wer sparen will sollte das nicht beim Test tun – viel effizienter, eleganter und für die Qualität nachhaltiger lässt sich beispielsweise am Funktionsumfang einer ersten Version eines Softwareprodukts „sparen“.

Faktor 3: Methodik

Ich habe den Eindruck (aus vielen Gesprächen und einigen eigenen Projekten), dass der Eindruck der „Komplexität“ des mobilen Testens oft auch dadurch entsteht, dass zeitgleich ein Wechsel der Methodik stattfindet. Das Testen selbst ist im Kern nicht viel anders als bei beliebigen anderen Softwareprojekten, das bestätigen auch die betroffenen Tester. Aber:

Viele Unternehmen, die aktuell im mobilen Bereich Fuß fassen, befinden sich zusätzlich in einer Phase des Umbruchs vom klassischen Wasserfall hin zu agile/SCRUM. Oft dient das Thema „Mobile“ sogar als Anlass, diesen Paradigmenwechsel zu vollziehen. Das stellt die Tester vor die doppelte Herausforderung nicht nur neue Technologien sondern auch neue Methodiken mit geänderten Abläufen einsetzen zu müssen. Dass die meisten Organisationen SCRUM auch noch falsch umsetzen oder agile Augenwischerei aus kleinen Wasserfällen betreiben (was spätestens im dadurch nachgelagerten Test zu Problemen führt) kommt erschwerend hinzu.

Während wir Tester also über mobiles Testen nachdenken und warum der fundamentale Testprozess beim mobilen Testen hakt, kommt nun auch noch „agile“ hinzu, was die Situation nicht einfacher macht. Bildlich gesehen standen wir mit einem Regal voller Testgeräte vor der Spitze unserer Testpyramide und dachten „Hier stimmt was nicht“. Ohne eine abschließende Antwort gefunden zu haben stehen wir schon vor der nächsten Herausforderung: Wie organisiert man die Regressionstests der Iterationen 2 bis n …wieder mit Blick auf das Regal voller Testgeräte. Also Automation auf Endgeräten oder was? Wie schnell bekommen wir das hin?

Fazit: Mobiles Testen findet heute im Kreuzfeuer von Paradigmenwechsel und neuen Technologien statt, die beide ihren Ursprung in der Entwicklung haben. Um also erfolgreich mobil zu testen liegt es nahe, sich Unterstützung bei der Entwicklung zu holen. Interessant an diesem Gedanken ist, dass er den Prinzipien der agilen Teamidee entspricht. Eigentlich sollten sich „mobile“ und „agile“ also hervorragend ergänzen. In der Projektrealität ist dies leider aber noch zu selten der Fall.

Weitere Faktoren

Neben diesen drei Faktoren gibt es noch andere, die eher hausgemacht und organisatorischer Natur sind und nicht zwangsläufig mobile-spezifisch. Allerdings gestalten sich die Auswirkungen bei mobile (aufgrund der höheren Testintensität) drastischer.

– Pi mal Daumen
Wer beispielsweise eine Faustformel wie „1/3 vom Entwicklungsaufwand“ verwendet um den Testbedarf zu schätzen und dann vielleicht einen Tester mit 50%-Allokation einplant darf sich nicht wundern wenn die Testabdeckung bestenfalls bescheiden ist und die meisten Fehler dann vom Endbenutzer nach dem Go-Live gefunden werden. Dann spielt es übrigens auch keine Rolle, ob man agil oder im Wasserfall unterwegs ist.

– Zu Tode automatisieren
Ebenso ist eine Testautomation kein Ersatz für manuelles Testen sondern ergänzt dieses bestenfalls. Genau genommen erlaubt die Automation eine Verlagerung des Fokus des manuellen Testens, wodurch dieses im wahrsten Sinne des Wortes „wertvoller“ wird. Die Automation von End-to-End bzw. Acceptance-Szenarien im mobilen Bereich klingt verlockend (auch dank vollmundiger Versprechen der Toolhersteller) und kann tatsächlich sehr sinnvoll sein. Allerdings wird der Aufwand dafür aber chronisch unterschätzt und lässt sich -selbst bei korrekter Schätzung- so gut wie nie durch ein einzelnes Projekt finanzieren.

– Test statt Qualitätssicherung
Ein weiteres Problem besteht in der falschen Priorisierung von Test versus QA: Wir wissen alle, dass durch das Testen selbst keine Qualitätsverbesserung erzielt werden kann, tendieren im mobilen Bereich wegen der „vielen Endgeräte“ aber dazu, noch mehr Fokus auf Test zu legen und vernachlässigen die proaktiven QS-Prozesse. Eine bessere Qualität und reibungsarme Testphase lässt sich aber eher durch frühes Einbeziehen der QA erzielen, beispielsweise alleine durch eine QA-seitige Prüfung der Anforderungs- oder Designdokumente.

Zusammenfassung

Mobiles Testen ist meiner Meinung nach nicht komplexer sondern intensiver. Ich habe die Erfahrung gemacht, dass durch diese Intensität viele hausgemachte Problemchen zu großen Problemen werden. Es ist wichtiger denn je, dass alle Beteiligten als Team agieren und Silodenken vermieden wird. Aber auch die QA-Abteilung muss ihre Hausaufgaben gemacht haben. Was das bedeutet und wie es funktioniert – darauf werde ich in weiteren Artikeln im Detail eingehen.


Diesen Beitrag teilen:
Facebooktwitterlinkedinmail