Problem und Eingrenzung

Mit mehr als 30.000 Geräte- und Betriebssystem-Kombinationen ist Android ein Albtraum für jeden QS-Manager. Apple hat hier mit nur knapp 1.000 Kombinationen die Nase vorn, aber auch hier können nicht alle Betriebssystemversionen und Endgeräte vorgehalten werden. Damit stellt sich sehr schnell die Frage: Wie können Apps und andere Software effizient und kostengünstig auf realen Devices getestet werden?

In diesem Eintrag geht es um Projekte, die eine erhöhte Anforderung an Kosten/Nutzen haben. Es geht nicht um Produkte oder Kernsysteme, die sich ständig weiterentwickeln sollen. Diese Abgrenzung ist wichtig, da Produkte und langfristig angelegte Software anders getestet und geprüft werden müssen als typische Marketing-Websites oder Apps, bei denen es um schnelle Produktion und geringe Kosten geht.

Action

Grundsätzlich stellt sich im Bereich der Qualitätssicherung immer die Frage, was das Ziel sein soll, also wie der Begriff “Qualität” für das Projekt definiert und priorisiert wird. Bereits bei einer mittelgroßen App können nicht mehr alle Funktionen in allen Varianten und auf allen Betriebssystemversionen und Geräten sinnvoll testbar sein. Theoretisch könnten Sie dies natürlich versuchen – aber der Kosten-Nutzen-Aspekt verbietet ein solches Vorgehen eigentlich komplett, insbesondere da Sie die Fehlerfreiheit trotzdem nicht beweisbar erreichen werden.

Bereits frühzeitig sollten Testcases zu den wichtigsten Prozessen und Funktionen geschrieben werden und bei jedem Release entsprechende Tests inklusive Testprotokoll erstellt werden. Unsere Testcases für ein klassisches App-Projekt umfassen häufig Schritt-für-Schritt-Anleitungen, die es einem neuen Tester ermöglichen, den kompletten Test durchzuführen und zu erfassen.

Zusätzlich zu den definierten Testcases sollte das Projekt regelmäßig von neuen Nutzern (z. B. in Zusammenarbeit mit Crowdtesting-Anbietern) im Rahmen von Usertests unter kontrollierter Umgebung genutzt werden. Hier finden sich zum einen schnell Usability-Probleme und zum anderen auch neue Fehlverhalten, die dann als neuer Testcase Eingang in die jeweiligen Releasetests finden sollte.

Ebenfalls empfiehlt es sich, Bewertungen, Social Media-Kommentare und sonstige Rückmeldungen jeweils zu verifizieren und dann als Testcase für alle weiteren Releasetests zu erfassen.

Die 3 wichtigsten Punkte

Unabhängig vom Projektumfang oder dem Website- bzw. App-Thema gibt es 3 zentrale Punkte, die in jedem Fall bedacht werden müssen:

Testcases aufsetzen

Testcases müssen sauber und ausreichend umfangreich dokumentiert werden, z. B. mit Testrail http://www.gurock.com/testrail/ oder www.ranorex.com.

Wichtige Testdevices definieren

Die wichtigsten Testdevices müssen mit dem Kunden auf Basis von bestehenden Kundendaten oder Annahmen aufgrund der Marktverteilung geklärt werden.

Testservices nutzen

Für Devices, die nicht in Hardwareform vorliegen, kann folgender Service genutzt werden: https://appcenter.ms/. Für Websites nutzen wir unter anderem: https://www.browserstack.com.


Ausblick

Keiner der Dienste ersetzt die Tests auf eigenen Devices, wobei diese aber eine sehr gute Ergänzung darstellen. In zukünftigen Einträgen gehen wir dann etwas mehr in die Tiefe und stellen unter anderem den Umgang mit der Software, sinnvolle Testverfahren, wie automatisiertes Testing, und auch das Thema Lasttests vor.

Nehmen sie gern Kontakt auf

Telefon: +49 511 169 299–0
E‑Mail: info@thisisdmg.com