Sie können jemanden einstellen, um automatisierte Tests zu schreiben – oder Sie entwickeln kurzerhand sinnvolle Tests mit hoher Abdeckung!
Ist es besser, 300 detailspezifische Tests zu haben oder einen einzigen der die gleiche Effektivität hat? Was ist aufwendiger?
An dieser Stelle ist eine Abgrenzung zwischen des Testens integrierter Datenbanksysteme und dem Testen von Quelldaten erforderlich. Die Quelldaten kommen von „irgendwo“ her und diese Quellen können Sie nicht beeinflussen. Dadurch können Sie sie nicht mit NBi prüfen. Jedoch können Sie in Ihren ETL-Datenflüssen entscheiden, welche Daten Sie akzeptieren. Erwarten Sie in der Produktspalte immer einen Wert, dann akzeptieren Sie leere Werte gar nicht erst. Dieses Zusammenspiel aus Datenprüfung während Sie Daten übernehmen (mit ETL-Werkzeugen) und der Prüfung Ihres Datensystems mit Hilfe von regelmäßigen Integritätstests (NBi) macht die hohe Qualität Ihres Systems aus. Hier konzentriere ich mich auf die Tests mit NBi.
Sollten Sie nicht gerade sowieso einen spezifischen Testfall dank einer Weiterentwicklung fertig haben und möchten einfach nur Ihr BI-System automatisiert prüfen lassen, dann denken Sie bitte groß! Sind die Summen der Umsätze je Monat im operativen System gleich dem analytischen System? Sind die Umsätze je Produkt gleich? Sind Daten in der OLAP-Datenbank? Sind die einfach abgeleiteten Filialeigenschaften identisch?
Wenn Sie diese einfachen Tests geschrieben haben, dann haben Sie bereits eine Abdeckung von 80-90%. Sollte einer dieser Tests fehlschlagen, dann wissen Sie vielleicht noch nicht genau, warum er fehlschlägt. Aber Ihr Ziel ist es zunächst festzustellen, dass etwas nicht korrekt ist.
Wenn Sie den ganz konkreten Fehler kennen, können Sie dafür wiederum einen Test anlegen. Durch die Fehleranalyse haben Sie den Test im Prinzip schon fertig. Diese ganz konkreten Testfälle im Vorfeld zu suchen, ist meist den Aufwand nicht wert.
Und falls Sie mal einen Fehlerfall nicht automatisiert „erwischt“ haben, ergänzen Sie den Fall aus der Vogelperspektive einfach: „Was? Die Kosten sind falsch? Die Umsätze prüfen wir zwar schon, ab sofort aber auch die Kosten!“
Viel Spaß beim effizienten Testfall-Entwickeln!
Weitere Teile der Blogserie:
Automatisiertes Testen von BI-Projekten Teil 1: Warum testen?
Automatisiertes Testen von BI-Projekten Teil 2: Kleine aber feine Fehler
Automatisiertes Testen von BI-Projekten Teil 3: Testframework mit NBi
Automatisiertes Testen von BI-Projekten Teil 5: Ergebnisse zweier Abfragen müssen gleich sein
Automatisiertes Testen von BI-Projekten Teil 6: Ergebnisse zweier Abfragen dürfen innerhalb bestimmter Toleranzen abweichen
Automatisiertes Testen von BI-Projekten Teil 7: Performancetests
Automatisiertes Testen von BI-Projekten Teil 8: Felder sollen nicht mehr als einen bestimmten Anteil eines Werts enthalten
Automatisiertes Testen von BI-Projekten Teil 9: Die referentielle Integrität ist immer gegeben
Automatisiertes Testen von BI-Projekten Teil 10: Namenskonventionen prüfen