Dokumentenmanagement Blog

Rolf Lang über Software-Testing für ein fehlerfreies DMS

[fa icon="calendar"] 26.06.2019 13:04:45 / by Jonathan Stadelmaier

blog_software_testing_rolf_lang

Rolf Lang ist Geschäftsführer bei agorum und zuständig für die Software-Tests vom Dokumentenmanagement agorum coreWarum manchmal 30 Millionen Dateien getestet werden müssen und weshalb es sinnvoll ist, nicht erst am Release-Tag zu testen, erklärt er hier. 


Tägliche Tests für ein fehlerfreies System

Kein System ist von Beginn an fehlerfrei. Um Bugs und Schwächen vor Release zu finden und zu korrigieren, werden hunderte von Tests durchgeführt. Wie das bei agorum konkret aussieht, erklärt Rolf Lang im Interview. 

 

Was ist das höchste Ziel bei den Software-Tests von agorum core?

Rolf Lang (RL): Natürlich eine fehlerfreie Software. Außerdem muss sie vom Anwender sehr gut bedienbar sein. Dabei muss man auch prüfen, ob die umgesetzte Software allen Ansprüchen entspricht. 

 

Ein neues agorum core Modul kommt frisch aus der Entwicklung - welche Tests hat es jetzt vor sich?

RL: Zuerst einmal muss man prüfen, ob die Software den gestellten Anforderungen genügt. Dann muss getestet werden, ob ein Anwender damit klar kommt und die Oberfläche verständlich ist. Dabei kommt es unter anderem auf das Handling und die Benutzeroberfläche an. Eine wichtige Rolle spielt auch die Zeit, die für die Nutzung der Software benötigt wird. 

Gibt es Eingabemasken, dann müssen gegebenenfalls Grenzwerte geprüft werden. Die Checks sind bestanden, wenn nur das eingegeben werden kann, was auch verlangt wird. Das bedeutet, dass beispielsweise bei einem Eingabefeld für Zahlen auch nur Zahlen eingegeben werden können. 

Je nach Modul kann es sein, dass auch etwas größere Datenmengen für den Test verwendet werden. Auch damit muss die Software zurecht kommen. Wenn also zum Beispiel Dateien im neuen Modul verarbeitet werden sollen, dann darf der Test nicht nur mit drei Dateien durchgeführt werden. Stattdessen muss gegebenenfalls mit 30 Millionen Dateien geprüft werden, ob die Software auch die größere Herausforderung zufriedenstellend meistert. 

Ein weiterer Testdurchlauf kann die Geschwindigkeit sein. Ist die Software so geschrieben, dass alles schnell genug funktioniert? Also wie lange muss ein Anwender auf eine Aktion warten oder wie lange benötigt eine Schnittstelle für die Datenverarbeitung.

 

Wie sieht so ein Test dann ganz konkret aus?

RL: Es wird eine Testumgebung erstellt, die nichts mit der Testumgebung der Entwicklung zu tun hat. Dann müssen je nach benötigter Datenmenge entsprechende Daten vorbereitet werden. 

Oberflächen werden von uns meistens händisch getestet. Bei Automatismen sieht es anders aus, da verwenden wir Testscripte. Diese können auch Dauertests sein, die mehrere Tage laufen. Damit überprüfen wir das Speicherverhalten und die Langzeitstabilität. 

 

Wenn ein Fehler bei den Tests entdeckt wird, wie geht es dann weiter?

RL: Als Erstes müssen wir wissen, ob der Fehler reproduzierbar ist. Können wir den Fehler nachvollziehen, dann wird er in einer Aufgabe für die Entwicklung dokumentiert und mit dem zuständigen Mitarbeiter besprochen. Bei Bedarf werden ihm zusätzlich Testdaten geliefert, die den Fehler belegen. 

Wenn der Fehler nicht reproduzierbar ist, dann wird er trotzdem dokumentiert. Wie jetzt weiter verfahren wird, kommt auf den Fehler an. Bei Fehlern, die nie vorkommen dürfen, wird jetzt so lange gesucht, bis der Fehler nachvollzogen werden kann. Zu solchen Fehlern gehören etwa Datenverlust oder der Stillstand des Systems. Anschließend wird der Fehler gefixt und die Software noch einmal getestet. Wenn die Tests mit einem Script durchgeführt wurden, werden diese ebenfalls nochmal mit dem gefixten System laufen gelassen. 
Bei Fehlern, die nur einen geringen Einfluss auf die Stabilität des Systems haben, ist die Priorität nicht ganz so hoch. Dazu kann zum Beispiel gehören, dass die Maske stehen bleibt, aber mit F5 wieder neu gestartet werden kann. Oder das System bringt eine Fehlermeldung, läuft aber trotzdem fehlerfrei weiter, das wäre dann eher ein Schönheitsfehler. Aber auch diese Probleme werden natürlich von uns gefixt und erneut getestet. 

 

Wird die Software nur vor Veröffentlichung getestet oder finden auch nach Release weitere Tests statt?

RL: Unsere Software wird bei jedem nächtlichen Build mit hunderten von Testprogrammen getestet. Die Programme entstehen zum einen durch unsere Entwickler, gleich bei der Entwicklung, zum Anderen durch einmal aufgetretene Fehler, die dann durch ein spezielles Testprogramm kontrolliert wurden. Diese Testscripte nutzen wir dann auch bei neuer Software. 
Damit lässt sich die sehr hohe Qualität der Software laufend verbessern. Es kommen ständig neue Testprogramme hinzu, die unsere Software gleich nach einem Build auf Herz und Nieren testen. Und das für alle von uns unterstützten Datenbanken. 

Vor einem neuen Release wird die Software noch bei uns auf den Liveserver gespielt und von allen agorum Mitarbeitern im laufenden Betrieb getestet. Auf unserem Livesystem laufen immer die Versionen, die dann in nächster Zeit freigegeben werden.

 

Gibt es internationale Standards, die bei den Tests von agorum core berücksichtigt werden?

RL: Wir haben unsere Tests intern für uns erstellt und dokumentiert. Diese liefern für unsere Software und unsere Art der Entwicklung die optimalen Ergebnisse. 

Um sicherzustellen, dass Änderungen an der Software keine ungewollten Nebeneffekte verursachen, verwenden wir die Continuous Integration Software Jenkins. Das bedeutet, dass unsere Builds nicht erst am Tag des Releases erzeugt werden, sondern jede Nacht. Dabei werden automatisch hunderte Testprogramme eingespielt, ohne dass einer unserer Mitarbeiter das aktiv übernehmen muss. 

 

Was ist die größte Herausforderung beim Testen von agorum core

RL: Die Herausforderung ist immer die, dass man eine fehlerfreie Software erreichen möchte. Man muss immer genau überlegen, wie die Software später eingesetzt wird oder eingesetzt werden könnte. 
Eine weitere Herausforderung ist, dass agorum core später unterschiedlich intensiv genutzt werden kann. Wenn viele Systeme später 2 Millionen Dokumente verarbeiten sollen, es aber auch Systeme gibt, die 200 Millionen oder mehr schaffen müssen, dann muss man so testen, dass beides möglich ist. 

 

Vielen Dank für das Interview!

 

 

Sie wollen wissen, wie agorum core bei Ihnen im Unternehmen funktionieren kann? Dann vereinbaren Sie einen Termin zur Online-Demo. Live am System stellen wir Ihnen vor, wie Sie Ihren Arbeitsalltag noch einfach gestalten können. 

 

Diese Beiträge empfehlen wir: 

Oliver Schulze gibt Tipps zum Backup von agorum core

Sofort loslegen und agorum core testen mit dem virtuell Appliance

Themen: Dokumentenmanagement, agorum




Kommentare

Wir freuen uns auf Ihr Feedback!