Im ersten Teil haben wir bereits dargelegt, dass nicht jede – sogar recht wenige – Funktionen von Geräten automatisiert getestet werden können. Eine große Herausforderung stellen die Sensoren dar, die in jedem Gerät anders sind und Umweltdaten wie Lage und Position messen. Diese können fast gar nicht simuliert und damit auch nicht automatisiert werden. Hier müssen Tester dann selbst Hand anlegen.

Strategisch ist manuelles Testen eigentlich nicht sinnvoll, weil es schlicht zu aufwändig ist. Deswegen holt man sich Automatisierungs-Fachleute ins Haus, die dann bestimmte Testszenarien entwickeln. Doch darüber sprechen wir später noch.

Um das Problem mit der Automatisierung lösen zu können, muss man früher anfangen zu testen.

Meistens muss in einem frühen Stadium bereits intensiv getestet werden. Hier braucht es ein optimales Zusammenspiel von Unittests, Codereviews und den manuellen Verfahren. Solche Tests sind aber auf jeden Fall umfangreicher. Nützliche Werkzeuge sind:

  • Unittests – beispielsweise mit Junit, TestNG, XCTest
  • Statische Codereviews – mit Unterstützung durch Tools wie FindBugs, Checkstyle, Lint oder PMD

Wenn Apps getestet werden, geht es aber nicht nur um Funktionen. Im Mittelpunkt steht heute die Usability. Und bei Apps will man es einfach haben und den Nutzer nicht überfordern. Hinzu kommen Compliance- und Accessibility-Normen die eingehalten werden müssen. Dies alles zu automatisieren ist ebenfalls nicht einfach und in manchen Fällen nicht möglich.

Tipp: Wenn Sie sich für Usability interessieren, schauen Sie sich doch die  „10 Usability Heuristiken für User-Interface-Design“ von Jakob Nielsen einmal an: http://www.nngroup.com/articles/ten-usability-heuristics/

Wie testet man Apps am besten?

Wenn es um Apps und Geräte geht, die sehr komplex sind und Daten von außen aufnehmen, muss man am Gerät selbst testen. Hier würden Simulationen und Emulatoren keine richtigen Ergebnisse bringen. Teilweise sind Emulationen nicht einmal vorhanden. Ganz verzichten muss man aber auf die Simulationen nicht: sie können unter anderem Hinweise darauf geben, wo man noch genauer nachschauen sollte. Außerdem können sie ein hilfreiches Werkzeug in einer CI, sein wenn es um effizientes Feedback geht.

Automatisierung hat viele Vorteile

  • Das kürzere Feedback gibt dem Team mehr Raum zum schnellen Handeln
  • Eine Auswahl an Regressionstests unterstützt Änderungen
  • Das eingebaute Skript sorgt automatisch für die Dokumentation
  • Es gibt eine einheitliche Behandlung der Requirements
  • Man kann mit solchen Tests auch Stress- und Belastungstests durchführen
  • Weil auch diese Tests klar strukturiert und nachvollziehbar sind, werden sie in der Rapid Software Testing als Checks bezeichnet. Das wertet auch manuelle Verfahren etwas auf. Mehr dazu hier: http://www.satisfice.com/blog/archives/856Dennoch sind die automatisierten Tests in den oben genannten Fällen nicht optimal. Sie sind langsam, man hat einen hohen Aufwand und es kommt immer wieder zu Störungen. Aber die Geschwindigkeit könnte man noch hinnehmen, wenn nicht die Analyse so schwierig wäre:
    • Wo gab es den Fehler?
    • War es ein Problem im Backend oder in der App?
    • Waren die Daten fehlerhaft oder ist das Testdesign falsch?

     

    Während man bei den Unittests genau weiß, was defekt ist, wird man bei den automatisierten UI-Tests eher im Dunkeln tappen und muss den Fehler im Code finden. Bei den End-to-End-Verfahren benutzt man auch das gesamte System zum Testen.

    Manche Fachbuchautoren wie Daniel Knott („Hands-On Mobile App Testing“) wollen deshalb die klassische Testpyramide von Mike Cohn umdrehen. Für mobile Apps, so die These, braucht es einen neuen Ansatz.

    So kam es zur Flipped Testing Pyramid. Das diese aber etwas instabil aussieht, hat man sie bildlich umgedreht, die Methoden für mobile Apps aber beibehalten.

    Die manuellen Tests stellen den größten Aufwand dar und bilden deshalb die Basis der Pyramide.  Über ihnen stehen die End-to-End-Tests, die bereits automatisiert sind. Die nächste Stufe bildet der Betatest, der vor allem bei Apps eine wichtige Rolle spielt. Über ihn bekommt man Userfeedback, und das auch früh genug, um noch eingreifen zu können. Ganz oben sind dann die Unit-Tests, die den Code und seine Qualität untersuchen. Sie sind bei mobilen Apps weniger umfangreich als bei klassischer Softwareentwicklung.

Es gibt einige gute Verfahren die zeigen, wie man eine End-To-End-Automatisierung bei Tests einsetzen kann:

    1. Smoketests – man bekommt rasche Rückmeldung und kann die wichtigsten Funktionen testen
    2. Testsuiten – für alles, was sich automatisieren lässt (z. B. Performance, Last)
    3. Routinen – die sich wiederholen oder aber besonders wichtig für die Benutzer sind, zum Beispiel anmelden, registrieren und installieren
    4. Regressionstests – plus die dazugehörigen Skripte

Was soll man automatisieren?

Man sollte sich darüber im Klaren sein, dass nicht die gesamte Anwendung automatisiert getestet werden kann, auch aus wirtschaftlichen Gründen. Je genauer man seine Ziele kennt und je früher man in der Entwicklung anfängt zu testen, umso einfacher hat man es später. Es ist besser, kurze Testphasen zu haben, mit denen man unabhängig ist. Wenig hilfreich sind sehr komplexe Testszenarien, die kein Ende zu finden scheinen.

Mit End-to-end-Tests kann man recht gut den Gesamtüberblick behalten und über APM-Tools Performance-Issues tracken.

Schlussfolgerung: Bei mobilen Apps sollte man eine Teststrategie haben, die sowohl die automatisierten Tests beinhaltet als auch manuelle Tests berücksichtigt.

 

Im 3. Teil unserer Artikelserie werden wir uns den Tools der Testautomatisierung widmen.