Als Backend-Tester habe ich es oft mit Stories zu tun, in denen fachlich nur wenig passiert. Ein typisches Beispiel: Baut einen GET-Endpunkt, der die Adressdaten eines Kunden abruft. Ein fachlicher Test ist unspektakulär: GET-Endpunkt aufrufen, Felder abgleichen, Daten abgleichen – ggf. ergänzt um ein paar Edge-Cases. Spannender sind die Non-functional Requirements (NFR), angeführt von Fehlermeldungen und Log-Statements.
Log-Statements ohne Referenzen
Häufig lese ich Log-Statements, in denen genau die Information fehlt, die bei der Fehleranalyse hilft. Ein solches Log-Statement wäre zum Beispiel: „Unable to read customer data“. Natürlich gibt dieses Statement den ersten Impuls – die Daten eines Kunden konnten nicht gelesen werden. Doch viel hilfreicher wäre es, wenn im Log die entsprechende Eingabe stünde. Wie wäre es mit: „Unable to read data of customer with id 00001“. Im Fehlerfall braucht der Analyst nun nicht mehr mühsam die fehlerhaften Daten suchen, sondern erkennt den Fehler auf den ersten Blick.
Fehlermeldungen ohne Bezug zu den übermittelten Daten
Ein ähnliches Problem begegnet mir täglich mit Fehlermeldungen, die APIs an ihre Konsumenten schicken. Typische Fehlermeldungen sind: „Could not parse json body“, „Missing customer data“, „Invalid Enum provided“. In all diesen Fällen ist der Aufwand gering, die Daten auszugeben, auf denen die Fehlermeldungen basieren. Fehlen die Daten allerdings, ist es dem Konsumenten teilweise unmöglich, den Fehler nachzuvollziehen. Genau wie bei Log-Statements lohnt es sich, den Fehlermeldungen entsprechende Details mitzugeben, um Konsumenten die Fehlersuche zu erleichtern.
Bezogen auf die oberen Beispiele wären mögliche Lösungen zum Beispiel, den vollständigen body oder die fehlenden Felder auszuloggen. Im Falle des Enums könnte man die Liste der validen Enums ausgegeben.
Fazit
Natürlich ist immer der Kontext zu bedenken, in dem eine Fehlermeldung erscheint. Auch dürfen nicht alle Daten in die Hände aller Entwickler, Tester oder Support-Mitarbeiter gelangen. In vielen Fällen handelt es sich aber um unsensible Daten, auf die derjenige ohnehin zugreifen kann, der mit den Fehlermeldungen oder Logs arbeiten muss.
Als Tester halte ich es deshalb für wichtig, nicht nur zu prüfen, ob ein Fehler geloggt wird und das System die korrekten Status-Codes zurückgibt. Es ist ebenfalls wichtig, die für Menschen bestimmten Informationen hinsichtlich Aussagekraft und Vollständigkeit zu prüfen.
Schreibe einen Kommentar