 Ja, hallo, schönen Abend dann zu dem nächsten Talk von Daniel. Der Talk wird sich in dem Spannungsfeld von Software-Tests, der Problematik, dass man immer sich davor drückt, Software-Tests zu machen, Usern dafür irgendwie verbackte Releases zu mutet und darum wird sich es drehen, wie man das besser machen kann, dass die User nicht das Testing für einen machen müssen, sondern dass man vorher saubere Tests hat. Und Daniel wird in Rahmen seines Talks einen Tool vorstellen, mit dem man das vielleicht etwas besser gestalten kann und optimieren kann, dass der Usern am Ende nicht der Testami ist. Ja, Daniel, bitte schön. Dankeschön für die Einführung und herzlich willkommen zu meinem Talk. Der Titel, wie gesagt, Software-Testen, ja bitte, ich habe schon mal so einen ähnlichen Vortrag gehalten über unser System. Da hatte ich dann immer den Produktnamen im Titel drin. Damit konnte keiner so richtig was anfangen. Jetzt habe ich halt gedacht, probieren wir das mal so und wunderbar sind ganz viele Leute da. Kurz zu mir, also mein Name ist Daniel Kulesch. Ich arbeite als Applikationsentwickler, bin aber eher so ein bisschen im DevOps-Umfeld unterwegs, bin auch noch Forscher und Doktorant an der Uni Stuttgart, arbeite noch als Dozent und ja, man hat halt viele Hobbys im Leben. Ich bin auch aktiv in verschiedenen Communities in der free Libre Open Source Szene, unterstütze auch gerne Leute, die freie Software einsetzen möchten. Klassisch irgendwie so die OMA, die irgendwie gehört hat, dass es doch toller sein soll, ein Laptop mit Linux zu betreiben, statt mit Windows 10. Ich bin auch Unterstützer oder Supporter der Free Software Foundation Europe und ich habe einige Open Source Projekte initiiert, unter anderem auch das Systemtest-Portal, über das ich heute sprechen möchte. Ja, so viel zu mir, aber ja, wir haben ja auch ein bisschen Publikum da, deswegen Frage an euch. Ich habe hier mal so schöne Kästchen mitgebracht, und würde einfach mal kurz strecken, bitte, wer sich einer dieser Gruppen zugehörig fühlt. Gut, es wird wahrscheinlich einige geben, die auf jeden Fall in die Gruppe gehören, ich glaube das sind so ziemlich alle, aber überleg mal zu welcher Gruppe ihr euch denn am stärksten zuordnen würdet. Wer würde hier sich so beim Entwickler sehen? Ja, einige, sehr schön, als Manager, ja auch ein paar, als Admin, ja als Pentester, ja sind auch ein paar, ist ja auch eine Art Test, ja, als Anwender, ja schön, auch einige, wunderbar, und als Sonstige, okay, schön, ja, ich hoffe, dass ich euch jetzt ein bisschen was erzählen kann, mit dem so die meisten was anfangen können. Meine Agenda, ich würde gerne das Thema vom Testen noch mal geschwind motivieren, um dann so das Konzept oder die Idee des Community-Unterstützten-Testens vorzustellen, gerade eben das, was dann die Lösung als Werkzeug eben das Systemtest-Portal versucht zu unterstützen, dann würde ich gerne noch ein bisschen über dieses Projekt selbst sprechen, also wir sind ja ein Open Source Projekt und am Ende eine kurze Zusammenfassung liefern. Da wird es natürlich auch eine Demo geben von dem von dem Tool. Ja, starten wir mal mit der Motivation, naja, die erste Frage, warum sollen wir denn überhaupt etwas testen? Ja, wenn ich Leute versuche zu überzeugen, doch bitte ein Open Source Produkt statt irgendeiner proprietaryen Software einzusetzen, kommt halt häufig dieses Vorurteil hoch, ja, das funktioniert nicht so richtig, das ist irgendwie so zusammengefrickelt, ja, und ich denke, das ist auf jeden Fall etwas, was wir versuchen sollten zu verbessern. Es gibt sehr viele, sehr viele gute freie Software, die auch ja nicht dieses Image hat, aber es gibt leider so einige Dinge, die dann halt nicht so gut sind, vor allem, wenn es halt wirklich um Regressionen geht, man hatte etwas, das hat eigentlich immer funktioniert, jetzt kommt die neue Version raus und jetzt tut es nicht mehr, stellt sich raus, ja, keiner hat es getestet, blöd, dass man es dann halt released hat, na, das heißt, gerade als Manager, wenn es denn sowas gibt in so einer Organisation, ja, oder als Entwickler, wollen wir uns natürlich einigermaßen sicher sein, dass das, was wir da releasen, dass das so funktioniert, wie das vorgesehen ist, ja, wir können es im Test nicht beweisen, da gilt ja eben der gute alte Spruch von Dykstra, aber wir können zumindest versuchen, ja, so ein gutes Gefühl dabei zu haben, wenn wir dieses Release rauspushen. Und das naheliegendste ist natürlich, dass wir das mit automatisierten Tests probieren, wer findet automatisierte Tests gut und nützlich, ja, sehr schön, das ist die Mehrheit, ja, habe ich auch schon so vorgesehen hier, ja, das würde ich natürlich auch unterschreiben, aber und das ist eben dieser Punkt mit dem, aber es gibt natürlich auch so die Probleme der Testautomatisierung, ja, zum einen, wenn wir automatisierte Tests einsetzen wollen, ich glaube, nach mir gibt es auch einen Vortrag über automatisierte Tests, ich hoffe, dass der jetzt nicht in diese Kategorie der komplexen Werkzeuglandschaften fällt. Es gibt sehr viele Tools, die einem eigentlich helfen sollen, den Test zu automatisieren, die dann aber eher dazu führen, dass die Entwickler sich hauptsächlich damit beschäftigen, dieses Tool irgendwie zum Laufen zu bekommen oder es hat mal funktioniert und jetzt meldet es irgendwelche Bugs, die aber eigentlich keine sind, sondern das Testtool versagt halt, ja, wenn man automatisiert testet, hat man es eben häufig mit komplexen, komplizierten Werkzeuglandschaften zu tun, die man irgendwie bändigen will. Das zweite Problem sind die dummen Testorakel, also wenn ihr was testet, braucht ihr natürlich immer ein Orakel, ja, ihr testet irgendwas, kriegt ein Ergebnis und jetzt muss ja irgendjemand bewerten, ist dieses Ist-Resultat, ja, entspricht es dem Soll-Resultat, dem was wir erwarten oder tut es das nicht. Und gerade wenn man dann eben automatisierte Tests hat, hat man häufiger dieses Problem, dass es relativ schwierig ist, dieses Testorakel herzustellen und wirklich anzugeben, was denn eigentlich das ist, was man erwartet am Ende von diesem Test, also welches Systemverhalten erwünscht ist. Ja, und dann der nächste Punkt und das ist so bisschen auch das mit den Beispielen, die ich das hier noch weiter motivieren will, ist eben die Frage, ja gut, wie können wir denn auch eingebettete Systeme testen? Ja, und gerade da wird es eben bei automatisierten Tests schwierig. Es gibt ja viele freie Firmen, ja, ich meine, ich freue mich immer sehr, wenn jemand GNU-Linux oder eins der BSDs einsetzt oder wenn jemand Libre-Office, statt Microsoft-Office verwendet zum Beispiel, aber das ist alles nur ein bisschen ein Teil davon sich zu befreien, sage ich mal, ja. Wir haben ja eben auch das Problem von der Firmware und da gibt es ja eben so diese schönen Sachen wie die Intel Management Engine oder diesen Platform Security Processor von AMD. Wir haben es heute mit vielen, ja, propriätären Biosen zu tun beziehungsweise dem Nachfolger OEFI, wo ganz viel propriätäre 5v3 ist, wo es, ja, Ansätze gibt, das ein bisschen zu befreien, so Dinge wie IPMI bei Servern, die meisten Smartphones haben unfreie Bootloader, ja, wir haben Treiber Blobs im Kernel Space und so weiter und für all diese Dinge gibt es auch Ansätze, die versuchen das ein bisschen besser zu machen, hier freie Alternativen zu entwickeln, ja. Wir haben bei Smartphones und Tablets zum Beispiel Postmarket OS, weiß nicht, wer hat das schon mal gehört? Keiner, schade, das ist ein ganz cooles Projekt basierend auf Alpine Linux, die halt versuchen sozusagen ein richtiges Linux auf dem Handy zum Laufen zu bekommen und nicht dieses Android, ja, oder Replicant, die versuchen ein komplett freies Android ohne propriätäre Bestandteile zur Verfügung zu stellen, was halt aktuell leider nur auf sehr wenigen Geräten funktioniert und dann halt auch nicht mit WLAN, weil der mal einen WLAN Blob benötigen würde, sondern man kann dann nur per USB OTG einen speziellen WLAN Adapter einstecken, ist ein bisschen fummelig. Und da gibt es eben noch viele andere wie UB Ports, Linux OS, Omnirom, Malmoleste und so weiter. Wir haben auch viel darum, also viel freie Firmware, wenn es darum geht, Rechner zu befreien, ja, ich habe hier ein Rechner auf dem läuft, Coreboot, es gibt hier wohl auch ein Stand, wo man Coreboot, Libreboot, Linux Boot und so weiter mal sehen und erproben kann. Die meisten kennen wahrscheinlich auch OpenWRT, da hinten habe ich so ein Router gesehen, da läuft glaube ich auch OpenWRT drauf. Wir haben so in der IoT-Welt das Sonoff-Tasmoda, oder wer gerne mit irgendwelchen Gadgets umgeht, also ich habe jetzt mal so eine Uhr da, die ist per Gadget Bridge an mein Smartphone angebunden und dadurch gehen die Daten eben nicht in die Cloud, sondern die bleiben halt auf meinem Smartphone und so ähnliche Dinge gibt es zum Beispiel mit dem OpenScale Projekt, die halt versuchen so was ähnliches für diese Personenwagen, Körperfettwagen und so weiter hinzubekommen. Ja, also da gibt es ganz viele schöne Projekte. Die Frage ist ja eher, wenn man sowas baut, ja, wie kann man denn diese Firmware, wo man ja eben eine alternative freie Firmware dafür entwickelt, wie kann man die denn testen und so richtig Aussage kräftigt wird die ganze Sache natürlich nur, wenn man das auch wirklich auf echter Hardware mal testet. Ja, und da gibt es viele Projekte, gerade zum Beispiel OpenWRT, die auch sehr viele Geräte unterstützen, die bringen auch fortlaufend neue stabile Releases raus und ja, leider bleibt dabei häufig der Test auf der Strecke. Ja, ich habe zum Beispiel mal so ein All-Winner-Board mal ausprobiert mit OpenWRT, auf dem es angeblich unterstützt wird. Ja, nur um festzustellen, dass halt leider der Körnel nicht bootet, was aber auch keinem aufgefallen ist, obwohl es schon seit mehreren Wochen oder Monaten der Fall war. Es wird ein Release rausgebracht für ein Gerät, das theoretisch laufen müsste, faktisch aber nie getestet wurde. Ja, oder auch ärgerlich, wir haben irgendwelche Geräte, die mal funktioniert haben. Ja, ich habe ein Gerät mit, weiß ich nicht, Linux OS, Version 15 und jetzt kommt Version 16 und plötzlich, weiß ich nicht, habe ich immer Verbindungsabbrüche im Bluetooth oder was auch immer und da wäre ich natürlich froh gewesen, hätte das jemand getestet oder es hätte mich wenigstens mal jemand vorgewarnt, dass ich vielleicht damit noch ein bisschen warten soll, das Upgrade zu machen. Ja, das Ganze sorgt dann halt leider bei den Anwendern natürlich für Frust, weil da unterscheiden sich, glaube ich, die sind so ein bisschen so leidensfähiger, die Menschen in der Open Source Szene, dass die sich dann manchmal auch mit so halb funktionierenden Geräten zufrieden geben, aber so richtig glücklich ist halt keiner, wenn er ein Gerät hatte, das vorher funktioniert hat, jetzt ein Update bekommen hat und jetzt funktioniert nur noch die Hälfte. Ja, also das sorgt halt leider für Frust. Und wir haben halt immer so dieses Nachvollziehbarkeitsproblem. Ja, wenn ich mir jetzt ein neues Gerät kaufen will und ich bin irgendwie ein Freund von Linux OS, finde das ganz toll, dann möchte ich ja natürlich schon eins haben, wo das gut funktioniert und da würde ich, aber vielleicht nutze ich ja nicht alle Funktionen, ja, vielleicht nutze ich kein NFC, da interessiert es mich nicht, ob das funktioniert, aber so andere Dinge wie GPS oder WLAN sollten vielleicht schon tun. Und da interessiert es mich ja gut, was davon ist denn überhaupt als Funktionabel deklariert? Ja, wann wurde das dann zum letzten Mal getestet auf diesem Gerät? Mit welchem Ergebnis? Ja, also wurde das für funktionierend befunden oder nicht? Wie ist man dabei vorgegangen? Also wie war der Testablauf? Wie wurde der Test durchgeführt? Ja, wo gucke ich denn da, wenn ich solche Informationen haben möchte? Das letzte Mal, als ich da so ein Gerät kaufen wollte oder jemand dabei beraten habe, eins zu kaufen, ist halt leider so, man geht dann halt ins XDA Forum, wühlt dann so ein Treppen mit 300 Seiten durch, wo es eben um das Rom für dieses Gerät geht und versucht dann zwischen diesen ganzen Kommentaren irgendwie rauszulesen, was davon jetzt einigermaßen funktioniert und was nicht. Ja, oder man abonniert irgendwelche Mailing-Listen und quält sich dadurch und schaut, ob da vielleicht nicht schon vor vier Monaten mal jemand geschrieben hat, es würde auf diesem Gerät nicht funktionieren und keine Antwort mehr bekommen hat, weil dann ist die Gefahr natürlich da, dass es immer noch der Fall ist. Manche Projekte haben auch Wikis oder andere Dokumente, wo sie solche Sachen zur Verfügung stellen. Da kann man natürlich auch immer gucken. PostmarketOS macht das zum Beispiel, das ist da eigentlich ganz schick, also die haben hier so eine Matrix, wo sich hier verschiedene Geräte haben, die sie versuchen zu unterstützen und jetzt haben sie so verschiedene Funktionen dieser Geräte, wo sie eben schreiben, ob das jetzt funktioniert oder ob das nicht funktioniert. Also zum Beispiel das USB-Networking oder ob man das PostmarketOS da überhaupt drauf installieren kann oder ob die Batterieanzeige funktioniert oder ob der Touchscreen funktioniert und so weiter. Und da kann man sich als User an dieser Matrix natürlich orientieren. Die spannende Frage ist natürlich, wie entsteht diese Matrix, wer kann dazu beitragen und so weiter. Damit kommen wir zum Community-Untersstützten-Testen. Das heißt, in Fällen, wo wir eben nicht mit Testautomatisierung zumindest mit endlichem Aufwand, also für Coreboot gibt es zum Beispiel eine Firma, die so einen Flash-Stand haben, wo sie verschiedene ROMs in so ein Bioschip reinflaschen können und dann damit testen können und so weiter. So ähnlich wie so ein Hilfprüfstand in der Automobilindustrie hat halt leider nicht jeder zu Hause. Da besteht einfach die Alternative, darin eben manuell zu testen. Ernsthaft, könnte man sich fragen, ich habe gesehen, es waren ganz viele Freunde der Testautomatisierung hier, wollen wir wirklich manuell testen? Na ja, wie funktioniert das denn da eigentlich? Und ich behaupte mal, in der Flosswelt ist es halt leider so, das will keiner so richtig machen. In der proprietaryen Welt ist es so, da gibt es Leute, die machen das, die werden dann halt eben mit entsprechenden Schmerzensgeld dafür entlohnt, halt irgendwas zu tun, was ihnen vielleicht keinen Spaß macht, was langweilig ist oder was auch immer, aber sie tun es zumindest. Und die praktischen Probleme, die wir ja eigentlich haben, ist zum einen die Entwickler, ich weiß nicht, ob sich die, die sich vorher als Entwickler hier bezeichnet haben, auch so in diese Kategorie zählen würden. Entwickler schreiben doch eigentlich lieber Code und haben eigentlich weder Zeit noch Lust, die Dinge zu testen. Die denken sich, hey mein Beitrag ist doch schon, dass ich diesen komplizierten Code geschrieben habe, dieses Testen ist doch eigentlich ganz easy, soll das doch jemand von den Anwendern machen. Ja, oder die Entwickler entwickeln halt irgendeine Firmware, die theoretisch auf 300 Geräten läuft, aber natürlich hat der Entwickler nicht diese 300 Geräte zu Hause und kann das da selber alles abtesten. Ja, und es gibt eben auch kaum unterstützende Werkzeuge, die jetzt den Entwicklern erlauben würden, irgendwie mit ihrer User-Community in Kontakt zu treten und damit irgendwie ein Testprozess zu koordinieren. Ja, und da gibt es jetzt verschiedene Arten, wie man das testen kann. Ja, also das eine beim manuellen Testen ist so der klassische Laufversuch, das heißt als Entwickler bin ich noch so in meiner IDE und versuch das jetzt mal auszuführen und guck mal, ob das so ungefähr tut. Wunderbar. Sollte man natürlich immer machen, bevor man da andere Leute testen lässt, aber hat natürlich nicht so die Aussagekraft, vor allem, wenn dann das jemand startet, der irgendeine Dev-Bibliothek nicht hat, wo es plötzlich nicht mehr tut. Ja, dann gibt es so den Wegwerftest. Idealerweise schafft man es dann so dieses Prinzip zu leben, dass es eben jemand anders sein sollte, der testet und der entwickelt. Ja, aber beim Wegwerftest ist es halt so, da kriege ich jetzt den Auftrag, was zu testen. Ich führe es mal aus, habe mir vorher aber gar nicht so richtig überlegt, was ich testen will und was ich da erwarte und irgendwelche komplizierten Konstellationen hergestellt. Das heißt, später ist leider so dieser ganze Testaufbau und so, der eher zufällig entstanden ist, leider auch nicht mehr da. Das heißt, wenn ich es noch mal testen will, wird es schwierig. Und man kann das aber eben auch systematisch testen, indem man sich eben vorher tatsächlich überlegt, hey, was will ich da eigentlich testen? Was will ich für Eingaben machen? Was erwarte ich für eine Reaktion vom System? Und wenn ich mir einmal so einen Plan gemacht habe, kann ich den natürlich aus der Schublade holen und dann immer wieder, wenn ich ein Regressionstest machen will, immer wieder diesen Plan ausführen. Ja, und das ist natürlich auch so die Richtung, die wir empfehlen. Die Idee hier ist, dass wir praktisch so eine Art Community-Unterstütz des Testen haben, dass wir eine Plattform schaffen, wo diese verschiedenen Leute, die an so einem Open Source Projekt beteiligt sind, miteinander agieren können. Ja, also wir haben vielleicht ein Testmanager oder ein Release-Manager, der sich eigentlich dafür interessiert, ja gut, welche Funktion laufen, welche nicht, können wir jetzt das Release machen oder soll man damit noch warten? Ja, es gibt vielleicht Leute, die Lust haben, sich so Tests zu überlegen, die besonders kreativ sind oder so ganz spezielle Grenzen und Extremfälle auch sich überlegen. Ja, es gibt eben Leute, die, sagen wir mal, als Tester aktiv werden wollen, die sagen vielleicht, hey, OpenScale finde ich ein ganz cooles Projekt, würde ich gerne unterstützen, leider kann ich nicht so gut programmieren, aber so auf die Waage stellen, das kriege ich noch hin und würde da gerne dem Projekt etwas zurückgeben. Ja, warum nicht? Ja, die Entwickler, die interessieren sich natürlich vor allem dafür, ja gut, was funktioniert denn noch nicht? Wo sind die Bugs? Wann kann ich endlich hier ein bisschen Code schreiben? Und dann gibt es natürlich die End-Anwender, die sich eben dafür interessieren, was funktioniert, was funktioniert nicht, kann ich mir diese Waage jetzt kaufen oder kaufe ich mir da lieber ein anderes Modell. Ja, und die Idee ist, dass wir eben eine Plattform schaffen, wo diese ganzen Leute irgendwie zusammenkommen, miteinander agieren, interagieren können und im Prinzip alle davon auch profitieren. Ja, und das ist eben auch das, was wir versuchen, mit dem Systemtest Portal zu machen, das ich jetzt gern vorstellen würde, also das Systemtest Portal ist eine Web-Anwendung, sie hat so die Grundfunktion, dass man eben eine Test Suite dort organisieren kann, dass man Testfälle ausführen kann, im Sinne von man protokolliert die Ausführung, ja und man kann sich dann diese Protokolle auch angucken, das ganze analysieren. Da gibt es noch so ein paar coolere Features, dass man eben so eine Schritt-für-Schritt-Ausführung machen kann, wo man wirklich begleitet und unterstützt wird in dem Prozess, dass man auch mit so ein bisschen komplexer Geflächten von Versionen und Varianten des System-Undertests, also des Systems, dass wir testen zurechtkommt und es gibt auch so eine Reporting-Funktion, wo man sich eben auf ein Dashboard angucken kann, ja gut, wie sieht es denn aus, welche Tests waren erfolgreich, welche waren nicht erfolgreich und die Testfälle werden auch versioniert, das heißt das ganze bleibt eben nachvollziehbar. Ich kann dann, also wenn ich jetzt jetzt zum Beispiel kommerziell einsetzen möchte und dann kommt jetzt ein Kunde und sagt hey, das was du mir da vor zwei Monaten geliefert hast, das könnt ihr gar nicht gescheit getestet haben, weil das funktioniert ja gar nicht, zeigt mir doch mal, wie ihr das getestet habt, ja und dann kann ich mir da einfach das Protokoll rausziehen, da ist dann dieser ganze Testablauf und so weiter beschrieben, ist auch beschrieben, was der Tester gemacht hat, wer das gemacht hat, man kann es natürlich auch anonym machen und man sieht dann eben okay, was lief da schon, was lief da nicht, welche Schritte wurden ausgeführt, welche Sollergebnis wurde erwartet, welches Ist-Ergebnis gab es, warum wurde das als Abweichung erkannt oder nicht. Das ganze System steht unter einer GPL3-Lizenz, ist eine reine Web-Anwendung, also es gibt keine App dazu oder so, ist dafür aber eben mobile tauglich, ist in Go implementiert, sehr leichtgewichtig, normalerweise so eine kleine Instanz, die schluckt vielleicht so 20, 30 Megabyte RAM, ist plattformunabhängig, läuft auch sehr vielen Architekturen und es gibt auch für Freunde von Testautomatisierung und so weiter so eine Integration mit GitLab, das heißt, wenn man so eine CI-CD Pipeline hat, wo man eigentlich immer automatisiert deployt, kann man sich da einklinken und kann sagen, hey ja, wir deployen immer automatisiert, aber jetzt dieses große fette Release für unseren kritischen Kunden, das wollen wir doch lieber erst deployen, wenn das vorher auch mal manuell getestet wurde, wenn es mal ein Mensch angeschaut hat, der vielleicht ein bisschen besseres Oracle ist, als so ein Test Script, das wir mal geschrieben haben, wo wir nicht sicher waren, ob wir da den Ausdruck richtig formuliert haben. Ja, dann würde ich das gerne mal hier kurz demonstrieren, wie das ganze aussieht. Ich habe hier praktisch schon, also ich werde es gleich installieren, um zu zeigen, wie schwierig das ist. Ich habe hier unser Archiv von der Webseite bei uns schon runtergeladen und dann kann ich jetzt hier ein Terminal öffnen und kann das Ganze einfach mal entpacken. Ja, damit haben wir schon einen der schwierigsten Teile der Installation gemacht. Jetzt muss ich nämlich noch in das Verzeichnis wechseln, wo das entpackt ist und ich starte die Binary, die dann eben den integrierten Web Server mitbringt. Natürlich kann man da irgendein Reverse-Proxy davor schalten und so weiter. Ja, nachdem das Ganze läuft, starte ich jetzt mein Web-Browser und kann das System aufrufen. Standardmäßig, ich weiß, das ist wahrscheinlich ja bei so einem CCC-Event nicht so gern gesehen, dieses Secure by default und so, das haben wir leider noch nicht ganz so umgesetzt, aber es gibt ein Issue dazu. Es gibt so einen hardcodeierten User Admin Admin, Demo Demo, Tester Tester. Wenn ihr es selber installiert, empfehle ich, ändert das bitte vorher, steht aber auch bei uns nochmal in der Doku drin. Ich lande dann auf jeden Fall hier auf diesen Startbildschirm, wo ich jetzt hier eben verschiedene Projekte sehe. Ich habe jetzt hier das Lineage-OS dabei. Ich denke mal, das kennen die meisten, oder? Wer kennt's? Ja, wie vermutet. Also, das ist halt so eine alternative Firmware für Smartphones, die aber auch auf Android basiert. Und Dac-Dac-Go, die doch leicht privacy-freundlichere Suchmaschine im Vergleich zu Google. Und wir haben jetzt hier eben diese zwei Projekte. Und für diese Projekte haben wir hier Testfälle in dem System. Gehen wir gerade mal in dieses Lineage-OS und wir landen dann direkt auf dem Dashboard und wir sehen jetzt hier verschiedene Testfälle. Also, es gibt hier Testfälle für einen Axel-Rometer, also für das Gyroscope oder für Audio-Output über Bluetooth, Audio-Output über Headphone Jack, Audio-Output über Speaker und so weiter. Und wir sehen jetzt hier auch sozusagen den Stand, mit welchem dieser Testfall zuletzt ausgeführt wurde. Ja, also die letzte Ausführung des Testfalls. Es gibt hier so ein Fragezeichen. Das Fragezeichen bedeutet, Testfall wurde ausgeführt. Der Tester hat dann irgendwas gesehen. Hat sich aber nicht so richtig getraut zu bewerten, ob das Fehl geschlagen ist oder nicht, hat lieber gesagt, ja, gucken wir mal, solltet es jemand anders sich noch mal anschauen. Dann gibt es diese Xe, da sind Testfälle, die einfach noch nicht ausgeführt wurden. Dann gibt es dieses gelbe Ausrufezeichen. Das ist ein teilweise erfolgreicher Testfall. Ja, ich soll vielleicht irgendwas machen. Das funktioniert im Prinzip, aber der Bildschirm flackert dabei oder der Ton ist verzerrt oder was auch immer. Dann habe ich eben den grünen Haken. Da war alles gut. Dann habe ich das rote Ausrufezeichen. Da ist der Testfall fehlgeschlagen und ich weiß nicht, ob wir hier das in dem Beispiel sehen. Ich glaube nicht. Es gibt noch ein Minus für Testfälle, die nicht applikabel oder nicht anwendbar sind. Das verwenden wir eben dann, wenn man Testfall definiert, der jetzt zum Beispiel irgend ein neues Feature testet, das erst in Lineage OS 15 reingekommen ist, dann macht es natürlich keinen Sinn, diesen Testfall bei Lineage OS 13 auszuführen und zu sagen, der ist ja fehlgeschlagen, wenn es da dieses Feature natürlich noch nicht gab. Dann wollen wir uns mal so ein Testfall genauer angucken. Ich würde jetzt gerade hier diesen Achsellerometer nehmen. Da sehen wir, wie das Ganze aussieht. Ich lock mich auch schwint ein, damit man nachher noch ein bisschen mehr machen kann. Da sind jetzt halt eben verschiedene Buttons hinzugekommen. Wir sehen jetzt hier eben wieder, wie der Testfall heißt. Es gibt eine Beschreibung. So ein Testfall hat eine Vorbedingung, in der ich eben definiere, was erfüllt sein muss, dass sich diesen Testfall überhaupt sinnvoll ausführen kann. Und dann gibt es eben so einzelne Testschritte, die ich eben machen kann, machen soll. Und jeder von diesen Testschritten hat sozusagen immer eine Anweisung für den Tester. Tue dieses oder tue jenes und ein erwartetes Resultat, wo eben drin steht, so soll sich das System verhalten. Und wenn der Tester das eben später ausführt, soll er eben prüfen, ob das dann tatsächlich der Fall ist. Ja, dann kann man noch so den Testfall ein bisschen kommentieren. Wenn man in diesen Edit-Modus reingeht, kann man eben genau diese Sachen machen, kann diese Schritte hinzufügen und so weiter. Es gibt auch eine Historie. Gut, jetzt haben wir hier den nur einmal angelegt, aber normalerweise, wenn ich die Testfälle ändere, sehe ich auch in der Historie, was wurde da geändert, kann mir auch einen alten Stand von so einem Testfall anschauen. Dann kann ich den natürlich kopieren. Ich kann die Testfälle auch zuweisen. Das heißt, ich kann mir jetzt hier irgendjemanden suchen und ihm sagen, hey, pass auf, führ doch bitte diesen Testfall aus für Version 14 in der Variante irgendwas. Ich habe jetzt hier keine Varianten angelegt, aber das System an der Test könnte ja jetzt verschiedene Varianten haben. Da kann ich eben einen dann auswählen. Und dann bekommt der Tester hier so ein Tudu oder so ein Task, die sieht man auch hier, dass der ihm eben sagt, hey, bitte testet doch mal diese Funktion. Ja, dann wollen wir vielleicht mal so zum spannenderen Teil gehen, zum Ausführen der Testfälle. Also wenn ich jetzt Tester bin, habe ich hier vielleicht auch nicht diese Buttons, also da gibt es so verschiedene Rollen. Ja, ich kann den Testfall nicht editieren, ich kann ihn nur ausführen. Und wenn ich jetzt in diesen Ausführungsmodus gehe, dann sieht das Ganze so aus. Ich habe jetzt hier diesen Testfall und ich muss als erstes bestätigen, dass die Vorbedingungen für diesen Testfall erfüllt ist. Ja, das muss ich als Tester aktiv sagen. Ja, ich habe das geprüft, die Vorbedingungen war erfüllt. Und muss jetzt eben auch angeben, was ich da eigentlich getestet habe. Jetzt angenommen wir testen tatsächlich auf der Version 15. Okay, das war der erste Schritt. Jetzt geht es weiter und jetzt kommen praktisch diese einzelnen Teststabs. Wir haben da auch so eine Mobile Ansicht dafür, die ist noch ein bisschen schmaler. Die Idee ist eben, dass der Tester dann wirklich das System an der Test vor sich hat und jetzt eben diese ganzen Sachen durchgeht. Und ja, stellen wir uns vor, wir haben hier so ein System an der Test, irgendwie unser Smartphone. Was sollen wir machen? Aha, die die Sensors App öffnen. Okay, das hat funktioniert. Wunderbar, zweiter Teil. Aufs Menü klicken. Ja, das hat auch funktioniert. Dann den Axelerometer auswählen. Ja, hat auch funktioniert. Wunderbar. Genau, beim Axelerometer sollten wir prüfen, ob der eben irgendwelche Werte anzeigt, die nicht null sind. Ja, und dann kann ich sagen, haja wunderbar, hat alles geklappt. Ja, idealerweise würde ich jetzt hier natürlich noch irgendein weiteren Test Schritt machen, wie zum Beispiel, keine Ahnung, shake the device oder so, um dann zu gucken, ob sich die Werte auch ändern. Wenn ich jetzt so ein Test ausgeführt habe, kann ich das Ganze hier exportieren in ein PDF. Oder ich kann es auch nach Markdown exportieren, wenn ich das zum Beispiel in irgendein Issue-Trecker reinpasten will, dass da einfach klar ist, wie bin ich vorgegangen, was habe ich da eigentlich ausgeführt und man sieht dann hier eben auch die ganzen Protokolle von den alten Testausführungen. Wir haben ja außerdem so Testsequenzen. Testsequenzen sind nochmal eine Gruppierung für Testfälle. Das heißt, wenn ich jetzt irgendwie einen Testfall habe, weiß ich nicht, leg einen Kunden an und dann gibt es einen Testfall Löscheinenkunden. Dann macht es in der Regel Sinn, den Kunden erst anzulegen, bevor man ihn löscht und nicht anders rum. Und so kann man hier so ganze Testsequenzen sich bauen, wo man dann eben diese ganzen Testfälle in einer sinnvollen Reihenfolge durchführt. Ähnlich wie so ein Testfall kann ich jetzt auch so eine Audio, so eine Testsequenz starten und dann muss ich erst mal die Vorbedingungen für die Testsequenz erfüllen und dann kommen diese ganzen Testfälle, die ich dann ausführ eben einzeln. Was gibt es noch? Es gibt noch so eine Mitgliederverwaltung und man kann irgendwie in den Settings des Projektlogo einstellen und so Kleinigkeiten. Denkt, das ist nicht sonderlich spannend. Man kann in diesem Dashboard halt immer schön navigieren. Wir haben jetzt diesen Testfall ausgewählt. Jetzt sehen wir hier, der war jetzt erfolgreich. Ich sehe dann auch gleich im Dashboard, wer den ausgeführt hat. Wenn ich hier draufklick, lande ich dann auch direkt bei dem Protokoll, kann mir diese ganzen Sachen anschauen. Außer diesem Dashboard gibt es praktisch auch, ich habe gesehen, es gibt ja auch Manager im Publikum, auch so ein Management Dashboard. Falls man eben sich nicht nur für dieses eine Projekt interessiert und das hier so auf einer eher feineren Ebene sehen will, kann man das ganze eben hier auch auf einer etwas groberen Übersicht sehen, wo man eben die Projekte sieht, die man hat und man sieht jetzt eben wie viele Testfälle haben die, wie viele waren erfolgreich, wie viele waren teilweise erfolgreich bei der letzten Ausführung und so weiter. Ja, viel mehr ist es auch nicht. Ja, unser Ziel war auch eben eine kleine überschaubare Anwendung zu schaffen. Deswegen springe ich jetzt auch wieder zum Vortrag zurück und werde gerne auch ein bisschen was über das Projekt erzählen. Also nicht über das Produktsystem des Portals, sondern über das Projekt. Das Ganze ist entstanden in zwei studentischen Projekten an der Uni Stuttgart. Wir hatten zwei Teams mit jeweils 17 Studierenden, die da mitgewirkt haben. Jedes von diesen Teams hat über 3000 Stunden gearbeitet, um das Ding dann eben zu programmieren. Das eine Projekt lief 12 Monate, dann gab es eine Änderung der Prüfungsordnung, das zweite Projekt lief dann sechs Monate, die Leute mussten aber trotzdem den gleichen Aufwand erbringen. Ja, im Prinzip ist das ganze Ding fertig. Ja, das heißt es kann produktiv genutzt werden. Ich habe auch einige Projekte, wo das auch eingesetzt wird. Ja, natürlich zeigen sich hier und da noch irgendwelche kleineren Bugs, aber ich sag mal so im Großen und Ganzen ist das Ganze auf jeden Fall benutzbar. Die Doku ist natürlich noch ein bisschen Work in Progress. Das Ganze wird jetzt auch weiterentwickelt als Community Projekt und da gibt es auch schon viele Ideen für neue Features und natürlich auch für Bug Fixes, die man da beisteuern kann. Das heißt, wenn jemand von euch hier auf der GPN ist und sich denkt, hey, eigentlich bin ich hier ein bisschen was zu koden, aber ich habe noch nicht so das Projekt gesehen, wo ich was beitragen will, dann kommt bitte auf mich zu. Ja, wir haben da im Issue- Trecker auf jeden Fall Screenshot von heute Morgen, 165 offene Issues. Es gibt auch so ein paar kritischere, sag ich mal, dass unser Binary sich unter Windows 10 nicht starten lässt, aber gut, ich glaube nicht so viele Leute benutzen das unter Windows 10. Ja, auf jeden Fall gibt es da noch einiges zu tun, auch eben so Security-Falls und so weiter, oder wer sich gerne als Penetrationstester betätigen will und einfach mal schauen will, ob er in unserem System irgendwelche Sicherheitslücken findet, ob er diese Libraries, die wir da eingesetzt haben, um so Dinge wie SQL Injections zu verhindern, vielleicht doch umgehen kann oder unseren Router, also HTTP-Router irgendwie aushebeln kann oder so, sehr gerne, wir freuen uns über weitere Issues und natürlich auch Beiträge, die schon existierende Issues schließen. Ja, ich denke, ich liege einigermaßen in der Zeit, deswegen würde ich hier noch gerne eine kurze Zusammenfassung am Schluss geben davon. Wir haben gesehen, es gibt viele Probleme, eben auch bei Freier Software und eines davon ist eben das Testen, das Testen eben mit Hardware vor allem, aber auch wenn man mit nur Software testet oder nur eine Web-Anwendung testet, kann es durchaus sinnvoll sein, auch manuelle Tests zu machen. Ich sage nicht als Alternative zu automatisierten Tests, sondern als Ergänzung. Auch wenn die Test Suite alles super durchgelaufen ist, wenn man das Ding jetzt released und man hat irgendwie kein Rolling Release, sondern eben so ein Release, wo man alle drei oder vier Monate mal das große Stable vom neuen Release rausbringt, dann bietet sich es vielleicht auch an da das durchaus mal manuell zu testen und gerade da mangelt es halt sonst ein guter Werkzeug Unterstützung. Ja, die Idee ist eben, dass man so eine Community sich aufbaut, mit der man eben gemeinsam testen kann, dass es eben Leute gibt, die Coden, dass es Leute gibt, die testen, dass es Leute gibt, die es einfach nur benutzen und dass die Leute alle sinnvoll miteinander arbeiten und eben da versuchen wir mit dem Systemtest Portal eine brauchbare Lösung dafür anzubieten. Ja, das wäre es dann auch soweit von mir. Ich würde mich natürlich sehr freuen über Fragen, Anmerkungen, auch Fragen zum Tool oder wenn ihr irgendwas noch sehen wollt in der Demo. Das Ganze ist auf Systemtest Portal Org verfügbar, da könnt ihr es runterladen, ausprobieren. Ja, danke schön. Okay, wenn jemand Fragen hat, bitte kurz warten. Ich komme mit dem Mikro zu euch, damit das auch auf der Aufzeichnung drauf ist. Ja, ich habe jetzt ja nur gesehen, dass man das Portal nutzt, um dann manuelle Tests zu machen. Gibt es auch ein Featurem zum Beispiel irgendwie, wenn es die I-Pipeline automatisierten Tests anzustoßen, also beispielsweise ich habe einen Sensor, das so war es, wo ich eine Firmware verbauer und dann teste ich automatisch, ob der richtig misst und du halt entsprechend dann die Tabellen und alles ausfüllen, ob es funktioniert. Ja, also das Systemtest Portal sieht sich eher nicht so als irgendwie Test-Treiber für andere Systeme, sondern die Integration mit den manuellen Tests funktioniert halt eben genau andersrum. Also man hat diese automatisierten Tests, da hat man wahrscheinlich auch schon irgendein Framework, mit dem man die anstreuert. Ja, und man möchte dann eben noch zusätzlich diese manuellen Tests auch dazu haben und die kann man dann eben so einklinken, also es läuft dann über so Webhooks und die CICD Pipeline wird eben pausiert, wartet dann bis vom Systemtest Portal die Meldung kommt, okay, für diese Version nämlich die, die wir jetzt deployen wollen beim Kunden, da sind jetzt auch die manuellen Tests durchgelaufen und wir können das Ding jetzt da in Betrieb nehmen. Ja, alles klar. Ja, weitere Fragen, ja. Zwei kleine Fragen. Zum einen die Benutzerverwaltung kann ich die an einem vorhandenen LDAP oder so dranhängen oder muss ich die da komplett getrennt machen und die andere Frage wäre, wenn ich jetzt viele, viele, viele Projekte habe, aber immer wieder ähnliche Sachen mach, kann ich Testfälle über mehrere Projekte hinweg kopieren? Mhm, LDAP, da gibt es ein Feature-Request dazu, leider ist noch nicht implementiert, die Idee dazu hatten wir aber natürlich schon lange, ist aber leider aktuell nicht drin. Testfälle über mehrere Projekte wird auch manchmal angefragt, aktuell kann man halt die Projekte kopieren, aber leider da muss man dann praktisch von dem Fog dann da irgendwie dran weiterarbeiten. Wir haben auch so eine Import-Exportfunktion nach JSON, wo man dann halt eben ein Projekt sich rausziehen kann und auf diesem Weg kann man es dann wieder importieren, aber es gibt leider noch keinen Mechanismus, mit dem man sozusagen mal so ähnliche Projekte gut testen kann. Üblicherweise empfehlen wir es dann eher dieses andere Projekt so als Variante anzusehen und es über diesen Mechanismus abzudecken. Weitere Fragen. Alle erschlagen. Okay, wenn es keine weiteren Fragen mehr gibt, dann vielen Dank an Daniel für den Vortrag. Und das war es dann jetzt hier erst mal. Dankeschön.