In der Testautomatisierung mit QF-Test und den Testdaten steht man irgendwann auch vor der Frage: „Kann man das auch mit Excel machen?“
Im folgendem Blogbeitrag geht es außerdem noch um diese Themen:
– Braucht man immer eine echte Datenbank für Testdaten?
– Wohin sonst mit den Testdaten, wenn man keine DB hat?
– Was genau sind eigentlich Testdaten?
Bevor die Antworten auf Excel erfolgen, möchte ich hier noch ein paar grundlegende Hinweise/Definitionen in diesem Zusammenhang geben, denn in der Testautomatisierung steht man irgendwann genau vor diesen Entscheidungen.
Testdaten sind die Daten, die man für das Testen verwendet. Hier wird hauptsächlich zwischen Eingabedaten und Ausgabedaten unterschieden. Testdaten sind häufig in einem bestimmten Definitionsbereich angesiedelt. Eingabedaten verwendet man direkt, z.B. als Eingabewert in einem Feld einer zu testenden Software (in Folge als „SUT“ = „System Under Test“ abgekürzt). Ausgabedaten dienen entweder als Wert, den man gegen vordefinierte Vergleichsdaten gegenprüft (Modell: Erhalten vs. Erwartet) oder schlicht als Information für Testverlaufsprotokolle bzw. Berichte. Die Eingabedaten werden direkt als Datenwerte in den Testschritten verwendet, während die Ausgabedaten als Vergleichswerte (Erwartet) mit ausgelesenen Daten des SUT (Erhalten) dienen. So viel in Kurzform zu den Testdaten. Später wird es hier im Blog auch noch einen ausführlicheren Beitrag zu Testdaten bzw. Testdatenqualität geben. Das Thema würde jetzt in diesem Beitrag zu Excel den Rahmen sprengen.
Insgesamt gilt: Testdaten in der Testautomatisierung sind ein kritisches Thema.
Wohin gehören die Testdaten in der Testautomatisierung?
Insgesamt gibt es drei Möglichkeiten:
– Variante 1: Die Testdaten stehen als fester Wert im jeweiligen Testschritt eines Testfalls
– Variante 2: Die Testdaten befinden sich innerhalb von QF-Test (unter bestimmten Knoten, z.B. einem Datentreiber als Datentabelle oder als globale Variablen)
– Variante 3: Die Testdaten befinden sich nicht in QF-Test, sondern in Excel, einer CSV-Datei oder in einer Datenbank etc.
Für welche der drei Möglichkeiten man sich in der QF-Testsuite-Entwicklung entscheidet, hängt von vielen Faktoren ab, z.B. der Anzahl der unterschiedlichen Testdaten, der Anzahl der Testfälle, Stabilität der Testdaten etc.
Die ersten beiden Varianten kann man durchaus in Betracht ziehen, wenn man insgesamt weiß, dass die Anzahl der Testfälle überschaubar bleibt und/oder keine Prozessänderungen innerhalb der Testfallschritte und der Testdaten zu erwarten sind bzw. nicht sehr häufig vorkommen werden.
Immer dann, wenn man viele Testfälle entwickeln wird und/oder die Testdaten häufiger geändert werden müssen, sollte man sich für die dritte Variante entscheiden. Natürlich sind die Formulierungen „viele Testfälle“ und „häufige Änderungen der Testdaten“ ziemlich dehnbare Begriffe, die sich nur schwer in klaren Größen definieren lassen, als Faustformel sollte aber insgesamt gelten: Die Testdaten an einem zentralen Ort außerhalb von QF-Test zu „sammeln“, ist eigentlich in jedem Projekt sinnvoll. Die Vorteile überwiegen hier schlicht und einfach.
Wenn ich im Gegensatz zum Projektstart schon wüsste, dass am Ende nur so max. 20-40 „normale“ Testfälle entwickeln werden mit vielleicht 10 bis 20 unterschiedlichen Testdaten, dann würde ich sicherlich Variante 1 oder 2 wählen. Natürlich nur dann, wenn die Testprozesse sich nicht ständig verändern. Hier gilt aber auch: In Zukunft könnte es ja sein, dass das Projekt deutlich größer werden könnte, als bei Projektstart kalkuliert wurde.
Am Ende landet man hier in einer Kalkulationsfalle, die sich entweder in eine positive oder eine negative Richtung entwickeln kann. Die Umsetzung über die Variante 3 birgt auf mittlere und längere Sicht das geringste Risiko und kostet so oder so auch nicht wirklich mehr Zeit bei der Entwicklung, wenn man weiß, wie man solche Fragen passend umsetzt in QF-Test.
Excel Ja oder Nein? Diese Frage hat sich sicherlich schon jeder gestellt in der Testautomatisierung.
Am Ende arbeitet im Grunde die ganze Welt (zumindest die IT-Welt) ständig immer wieder mit Excel. Manche machen in Excel ja alles, z.B. auch Dinge, die man eigentlich besser in Word machen sollte, Dokumentation schreiben etc.
Was wir hier festhalten können: Die Arbeitswelt (also die User) wissen mit Excel umzugehen, es liegt genügend praktisches Wissen vor.
Was ich immer wieder mal in Projekten höre: “Excel?! Das macht doch keinen Sinn, nehmen wir lieber CSV-Dateien!“.
Irgendwie stimmt das sicherlich, denn Daten in CSV-Dateien könnte man überall verwenden. Hier trifft jetzt aber die „praktische Welt“ auf die „theoretische Welt“. Wir müssen definitiv unterscheiden, für welches Umfeld die QF-Testautomatisierung umgesetzt wird. Befindet man sich zu quasi 100% in einem Entwicklerumfeld (z.B. Hersteller einer Software etc.), dann sollten durchaus CSV-Dateien bevorzugt werden. Befindet man sich hingegen in einem „normalem Userumfeld“, z.B. eine Fachabteilung die auch Tests durchführt, dann ist Excel die bessere Wahl.
Es gilt bei CSV vs. Excel ein paar Dinge in den üblichen Fachabteilungen zu berücksichtigen: Die durchschnittlichen User kennen sich meistens mit Excel im täglichen Arbeitsumfeld aus. CSV Dateien werden im Durchschnitt mit Doppelklick geöffnet, der Anwender macht dies automatisch mit Excel. CSV Dateien sind als Textdateien schwer zu lesen, gerade wenn sie komplex sind. Nachdem ohnehin mit Excel gearbeitet wird in diesem Umfeld, aus besagten Gründen auch mit CSV-Dateien, gibt es eine neue Hürde zu betrachten. Verändert man Daten in einer durch Excel geöffneten CSV-Datei, dann muss man beim Speichern dieser CSV-Dateien auf ein paar Dinge achten, z.B. Formatierung von großen Zahlen. Weiß man das nicht, dann ist die CSV-Datei im Durchschnitt unbrauchbar geworden für QF-Testläufe.
Da die CSV-Dateien so oder so mit Excel geöffnet, betrachtet, verändert und gespeichert werden, kann man hier an der Stelle auch die passende Frage stellen: „Warum nimmt man dann nicht gleich Excel?“.
Meiner Meinung nach sind das noch irgendwelche Relikte aus der Vergangenheit, als viele User auch dachten, dass Excel eine „Datenbank“ wäre. Was natürlich nicht der Fall ist. In diesem Kontext wurde Excel nachvollziehbar gemieden, weil Excel eben keine Datenbank ist.
Das spielt für unsere Überlegungen aber nicht wirklich eine Rolle, denn unseren Testdaten ist es egal, wo sie gespeichert werden und das Gute ist, auch QF-Test ist es egal, woher die Testdaten kommen. In sehr vielen QF-Projekten konnte ich feststellen, dass QF-Test vorzüglich mit Testdaten aus Excel umgehen kann. Da gibt es keinerlei Instabilitäten zu befürchten. Man kann Excel-Dateien sowohl als Datentreiber in QF-Test integrieren:
-Datentreiber:
– Excel Datei: „XYZ.xlsx“, Tabelle XY
Ein Aufruf der Inhalte wird dann über die Variable „$(Spaltenname)“ in einem Testlauf umgesetzt.
Darüber hinaus kann man auch einzelne Zellen einer Exceldatei an anderer Stelle gezielt verwenden, z.B. nur die Zelle A1 oder G5 etc., dafür gibt es in der qfs.qft Datei (liegt in jeder QF Auslieferung im Verzeichnis „..qftest-x.x.x/include..“) eine passende Prozedur.
In der qfs.qft Testsuite befindet sich die Prozedur „readExcelFile“ in „Prozeduren.qfs.utils.files“ (weitere Infos sind dort zu finden). Ein Aufruf einzelner Werte aus einer Excel-Zelle erfolgt dann über „${resultGroupName:cellReference}“, Beispiel: „${testdaten:A1}“.
Die Testdaten außerhalb von QF-Test „aufzubewahren“ sollte natürlich nicht als Pflicht angesehen werden, es ist eher ein Rat, weil man die Testdaten so später einfacher und schneller pflegen kann. Das Mittel der Wahl „Excel“ sollte man auch nicht falsch interpretieren.
Excel ist hier nicht als DB-Ersatz anzusehen, sondern einfach nur als ein Hilfsmittel, um Testdaten zentralisiert außerhalb von QF-Test aufzubewahren. Darüber hinaus wird den Fachbereichen die spätere Pflege und anstehende Anpassungen der Testdaten via Excel einfacher möglich sein. Wenn man sich zwischen CSV-Dateien oder Excel-Dateien entscheiden muss, sollte man sich, wenn keine anderen Gründe dagegensprechen, eher für Excel entscheiden, weil man dadurch eine Fehlerquelle weniger ins Spiel bringt.
Wer extrem viele Testdaten „beherrschen“ muss, kann sich auch für eine Datenbanklösung entscheiden. Dann sollte man aber das Umfeld genauer betrachten, denn arbeiten am Ende „normale User“ mit den Daten, dann steht eben auch wieder zusätzlicher Schulungsbedarf an, um diesen normalen Usern die Pflege und nötigen Anpassungen in der Datenbank zu ermöglichen.
Insgesamt gibt es hier keine „eindeutige“ Antwort zur Frage des Speicherformats der Testdaten, also Excel, Datenbank, QF-Intern oder CSV (es gibt auch noch Properties-Dateien, würde hier aber den Rahmen sprengen). Was aber eindeutig beantwortet werden kann: QF-Test kann mit allen Lösungen absolut reibungslos, fehlerfrei und stabil arbeiten. Es liegt also eher am Umfeld (normale User vs. Entwickler) und auch an der Gesamtmenge der Testdaten.
Aus meinen eigenen Erfahrungen kann ich sagen: Excel passt perfekt für das Umfeld, in dem ich mich mit der QF-Testautomatisierung bewege. CSV-Dateien sind zu sperrig und „unbequem“ im täglichen Arbeitsalltag und haben darüber hinaus auch das Potential eine neue Fehlerquelle zu sein, z.B. bei 13stelligen EAN Nummern.
Excel macht durchaus Sinn, weil viele Prozesse relativ schnell vereinfacht werden können, bis hin zur Einbindung der Fachabteilungen in die Testautomatisierungsprozesse. Gerade mit den Testdaten und deren Qualität steht und fällt so ein Automatisierungsprojekt. Bei sich schnell wandelnden Prozessen unter Einbeziehung von Fachabteilungen kommt man ohne Excel, als Hilfsmittel, auch kaum aus. Müssten Fachabteilungen erst Änderungswünsche an Datenbank-Admins via z.B. Jira-Ticket stellen und im Durchschnitt dann länger auf diese Anpassungen warten, wären an dieser Stelle die potentiellen Möglichkeiten, die QF-Test bietet, eingeschränkt, also verlangsamt worden.
Versuchen Sie ruhig mal QF-Test in Kombination mit der Auslagerung der Testdaten in Excel. Sie werden sehen, wie Gut diese Symbiose funktioniert und dadurch auch viele Prozesse deutlich agiler/schneller macht.
Weiterführende Informationen zur Prozedur „readExcelFile“ sind auch im QFS-Blog zu finden: Link
Falls Sie mit uns über ähnliche Herausforderungen sprechen wollen, kontaktieren Sie uns unter service@die-gute-it.de.