Was Softwaretests für Nicht-Entwickler finden und Code-Reviews nicht
Die Lüge
Eine Erfolgsmeldung, aber nichts wurde gespeichert. Der Code zeigt die Absicht, nicht das Ergebnis.
Die Verwirrung
Ein Ablauf, der technisch funktioniert und den niemand zu Ende bringt. Das merkt nur ein Mensch.
Die Annahme
Funktioniert für das Konto, mit dem gebaut wurde, und scheitert bei allen anderen.
Für diejenigen, die dieses erste Konto nutzen, unsichtbar.
Vier Prüfungen, die ohne Code auskommen
Machen Sie es und laden Sie dann neu. Das trennt „die Anzeige hat sich aktualisiert“ von „es wurde gespeichert“. Die ergiebigste Prüfung überhaupt.
Machen Sie es als jemand anderes. Ein zweites Konto deckt Annahmen über Berechtigungen sofort auf.
Machen Sie es absichtlich falsch. Schicken Sie etwas Ungültiges ab und prüfen Sie, ob die Anwendung das klar meldet, statt stillschweigend zu scheitern.
Machen Sie es ganz ohne Daten. Leerzustände werden zuletzt gebaut und am wenigsten getestet.
Einen Fehlerbericht schreiben, der auch behoben wird
Drei Sätze, ganz ohne Fachvokabular. Was Sie getan haben, der Reihe nach. Was Sie erwartet haben. Was stattdessen passiert ist. „Ich habe das Formular ausgefüllt und auf Speichern geklickt, ich habe den Eintrag in der Liste erwartet, die Liste war leer, bis ich neu geladen habe“ zeigt direkt auf den Fehler und braucht keine Deutung.
Das ist zugleich eine Prüfung. Einmal aufgeschrieben, kann sie nach jeder künftigen Änderung laufen.
Was tun, wenn niemand auf Ihren Bericht reagiert
Die häufigste Frustration in dieser Rolle: Man findet einen echten Fehler und sieht dann zu, wie nichts passiert. Meist liegt es nicht daran, dass Ihnen niemand glaubt, sondern daran, dass der Bericht zu wenig enthält, um damit anzufangen.
Drei Angaben schließen diese Lücke. Nennen Sie Konto und Umgebung, denn ein Fehler, der nur bei einer bestimmten Art von Nutzern auftritt, ist ein anderer Fehler. Sagen Sie, ob er jedes Mal auftritt oder nur manchmal, denn sporadische und durchgängige Fehler haben völlig unterschiedliche Ursachen, und diese Angabe spart eine Stunde. Und sagen Sie ausdrücklich, was Sie erwartet haben, denn in der Hälfte der Fälle geht die Uneinigkeit am Ende um die Anforderung und nicht um den Code – und das gehört früh auf den Tisch.
Nichts davon erfordert Fachvokabular. Es ist der Unterschied zwischen einem Bericht, der nur einsortiert wird, und einem, der behoben wird.
Prüfungen, die Sie überdauern
Die Grenze von Tests ohne Programmierkenntnisse war nie das Können, sondern dass ein Mensch nur eine begrenzte Menge erneut prüfen kann. Wenn Sie den Ablauf in einfacher Sprache beschreiben und ihn automatisch laufen lassen, fällt diese Grenze – ohne dass jemand ein Framework lernen muss.
Dafür brauchen Sie kein Terminal. Legen Sie im TestSprite-Dashboard ein Projekt an, beschreiben Sie die Prüfung in einfacher Sprache und richten Sie sie auf Ihre Anwendung. Entwickler in Ihrem Team können dasselbe bei Bedarf über die Kommandozeile steuern – zu finden im CLI-Repository.
Zwei Wege, und die Wahl hängt eigentlich davon ab, wer die Pipeline verantwortet. Die Anbindung der GitHub App über das Dashboard erfordert keinerlei Änderung an Ihrem Repository, denn sie reagiert auf das Deployment, das Ihr Build ohnehin erzeugt. Ein zusätzlicher GitHub Actions -Schritt verankert die Prüfung im Repository, wo sie wie der Rest des Builds im Review landet.
Wie TestSprite Ihre Prüfungen dauerhaft macht
Sie beschreiben einen Ablauf so, wie Sie ihn einem Kollegen erklären würden, und TestSprite führt ihn gegen die Anwendung aus. Kein Testcode, kein Framework, kein Terminal. Legen Sie im Dashboard ein Projekt an, richten Sie es auf Ihr Produkt und schreiben Sie die drei Sätze: was Sie getan haben, was Sie erwartet haben und was danach zutreffen sollte.
Von da an läuft die Prüfung bei jeder Änderung. Die vier Prüfungen auf dieser Seite sind dann nichts mehr, was Sie von Hand wiederholen, sondern werden zu etwas Festgehaltenem, das weiterarbeitet, während Sie sich um anderes kümmern.
Der Nutzen ist konkret: Ihr Wissen darüber, was passieren soll, steckt nicht mehr nur in Ihrem Kopf. Genau das macht Ihren Beitrag für alle anderen sichtbar – und haltbar, wenn Sie längst an der nächsten Sache arbeiten.
Muss ich programmieren lernen?
Nein. Beschreiben Sie den Ablauf in einfacher Sprache. Ihr Beitrag besteht darin, zu wissen, was passieren soll, und das ist keine Programmierfähigkeit.
Woher weiß ich, ob meine Prüfung wirklich greift?
Machen Sie die Sache absichtlich kaputt und vergewissern Sie sich, dass die Prüfung fehlschlägt. Eine Minute Aufwand, und es ist der einzige Beweis, dass sie überhaupt mit etwas verbunden ist.
Was, wenn Entwickler meinen Bericht abtun?
Nutzen Sie die drei Sätze. Eine konkrete Abfolge mit einer Erwartung lässt sich weit schwerer abtun als „es ist kaputt“.
Soll ich vor oder nach einer Änderung testen?
Beides. Die Prüfung, die es schon vorher gab, zeigt Ihnen, ob die Änderung etwas kaputt gemacht hat – und das ist die wertvollere Richtung.
Was ist die eine wichtigste Prüfung?
Machen Sie etwas und laden Sie dann neu. Hier scheitern mehr Produkte als an jeder anderen Stelle, und es dauert fünf Sekunden.
Den Code nicht zu lesen ist hier ein Vorteil.
Softwaretests für Nicht-Entwickler finden die Lüge, die Verwirrung und die Annahme – drei Dinge, die ein Code-Review strukturell nicht sehen kann. Neu laden, ein zweites Konto verwenden, absichtlich falsch machen, ganz ohne Daten probieren – und die Prüfungen aufschreiben, damit sie die Sitzung überdauern.