automatisiertes Testen einer Anwendung

[wasd123]

Moin!
Meine Firma entwickelt eine Business-App auf iOS-Basis. Äußerst umfangreich. Diese ist im Prinzip für ein iPad vorgesehen, ist aber auf dem Mac ebenfalls lauffähig.

Wie es halt so ist: fixt man einen Fehler, baut man dadurch wohl möglich drei neue ein....
Es gibt so gut wie täglich mehrere neue Testbuilds der App.

Wir haben im Unternehmen auch jemanden der ausschließlich zum Testen der App eingestellt ist. Dennoch würde ich diese Person dahingehend entlasten wollen, zumindest die absoluten Basics unserer App automatisiert durchlaufen zu lassen, welche sich vom Prinzip her nie ändern sollten und man daher genau ein Ergebnis zu erwarten hat. Treten dabei Fehler auf = doof!
Auch das sind dann schon mehrere hunderte kleine Einzeltests, wenn man es drauf anlegen will.

Ich habe mich mit solchen Automationen noch nie groß beschäftigt, daher wollte ich mich mal umhören wer hier dahingehend Erfahrungen hat und mich mal auf die richtigen Tools stoßen könnte.

 

[Tornhoof]

Das kommt extrem auf den Techstack der App an, native, PWA usw.
Eins der Standardframeworks für Apps ist z.b. Appium https://github.com/appium/appium

Was dir bewusst sein muss, ist dass du die Automated Tests warten musst. Wie sehr die gewartet werden müssen, kommt auf das Appkonzept und die Testsoftware an.

Ich kann nur von WebApps berichten, da hat der Umstieg von Selenium auf Playwright, den notwendigen Wartungsaufwand auf fast 0 reduziert.

 

[MaliByte]

Schau mal nach Ranorex. Damit kann man wohl auch iOS Apps prüfen. Ranorex Studio selbst läuft aber nur auf Windows.

 

[iamahumanbeing]

Schau dir dafür mal Robotframework und Appium an.
Du solltest aber auch nicht den Aufwand für die Entwicklung und Wartung der Testautomatisierung unterschätzen.

Edit: Die Form von Tests die du dir vorgestellt hast heißen Regressionstests.

 

[BeBur]

Wie es halt so ist: fixt man einen Fehler, baut man dadurch wohl möglich drei neue ein....

Tests sind ein wesentliches Fundament für Softwareprojekte.

Auch das sind dann schon mehrere hunderte kleine Einzeltests, wenn man es drauf anlegen will.

Du meinst mehrere Tausend. Mehrere hundert schaffe ich bei einem Hobbyprojekt an dem ich alleine arbeite.

Das ihr bisher keine Tests schreibt sollte dich extremst besorgt stimmen, je nachdem, in welcher Position du bist und wie wichtig dir ist, dass das Projekt erfolgreich sein wird.
Unit-Tests prüfen, dass Funktionen (weiterhin) das machen, was sie sollen. Ohne diese werdet ihr auf Dauer regelmäßig Fehler produzieren. Integrationtests sichern das Zusammenspiel mehrere Komponenten (z.B. Backend und Datenbank) ab, auch diese sind absolut essenziell. E2E tests mit den hier schon genannten Frameworks sichern dann die wichtigsten Usecases ab.

Du solltest aber auch nicht den Aufwand für die Entwicklung und Wartung der Testautomatisierung unterschätzen.

Insgesamt verringern Tests den Gesamtaufwand für ein Projekt.

 

[wasd123]

ich danke für die Antworten und schaue mir die Sachen mal an

 

[_killy_]

Am Ende solltet ihr auch eure Entwicklung umstellen. Bevor ein neues Feature entwickelt wird oder ein bestehendes Feature angepasst wird, werden zuerst die Tests entwickelt. Danach macht man dann den Code Change.

 

[BeBur]

@_killy_ Das macht so kaum jemand und du wirst Entwickler schwerlich dazu bekommen das ernsthaft so zu machen, wenn diese das nicht von sich aus machen wollen.

 

[_killy_]

@BeBur

Ich gebe dir Recht. Ich kenne es auch nur von einer Anwendung, die Hochverfügbar sein müsste. Da haben dann die Analysten die Test Cases vorgegeben und die Entwickler haben zuerst die Tests dann aufgenommen und danach ihren Code Change.

 

[sandreas]

@wasd123
Bevor du etwas "machst" solltest du zunächst einmal Qualitätsziele festlegen, denn automatisierte Tests dienen der Qualitätssicherung. Die Qualitätsziele dienen dazu, den Aufwand abschätzen zu können.

Dabei solltest du dich an die Testpyramide halten, sprich:
Viele Unit-Tests,
Mittelviele Integrationstests,
Wenige E2E / Akzeptanztests

Für den Anfang würde ich dir raten, erst einmal Unit-Tests für die Kernklassen / Funktionen zu schreiben, um dich einzufinden. Dann ein paar Integrationstests und erst ganz zum Schluss die wesentlichen "Workflows" als Akzeptanztests (das ist das, was du sicher mit automatisiertem Testen meinst - also die App automatisch "durchklicken").

Da ihr gar nichts an automatisierten Tests zu haben scheint und es euch auch an den nötigen Skills fehlt, schlage ich vor, dass ihr in gemeinsamen Coding-Dojos erstmal etwas Know-How aufbaut (Stichwort: FizzBuzz), bevor ihr wild drauf los testet. Vielleicht mag sich der ein oder andere auch mal mit Jenkins, SonarQube oder anderen Qualtitätssicherungstools beschäftigen, als optionale Ergänzung versteht sich.

Hier kommen wieder die Qualitätsziele vom Anfang ins Spiel, da das alles Kosten verursacht und viel Zeit kostet - ihr solltet das also auf jeden Fall auch mit den Chefs klären, was ihr für technische Schulden aufgebaut habt und wie ihr die am besten langfristig abtragt. Am Anfang stehen die Unit-Tests, die kosten euch nicht so viel und bringen euch wirklich weiter. Jede Woche ein Coding-Dojo von 60 Minuten ist da schon aufwändiger, aber so verteilt ihr das Know-How im Team und es ist zusätzlich noch eine Teambuilding-Maßnahme. Achtet dabei aber darauf, das wenn ihr introvertierte Entwickler habt, diese nicht zu zwingen, mit zu machen.