Eine Demo zeigt, dass eine Idee auf einem bestimmten Weg funktionieren kann. Sie hilft Ihnen, das Produkt zu erklären und herauszufinden, ob der Ablauf sinnvoll ist. Bevor sich Kunden darauf verlassen, müssen wir aber auch verstehen, was mit anderen Nutzern, echten Daten und Unterbrechungen passiert.
Das gilt unabhängig davon, ob der Prototyp aus einer Vorlage, einem KI-Werkzeug, einem internen Team oder von einem früheren Entwickler stammt. Ich würde bewerten, was schon brauchbar ist, die Lücken benennen und die Arbeit nach den Risiken planen, die für dieses Produkt zählen.
Halten Sie fest, was echt ist und was simuliert
Ein Prototyp zeigt vielleicht Beispieldaten, simuliert eine Zahlung oder geht davon aus, dass jede Anfrage gelingt. Listen Sie diese Annahmen auf. Ein Bildschirm, der eine erfolgreiche Buchung anzeigt, braucht womöglich noch Verfügbarkeitsregeln, eine Zahlungsanbindung und einen verlässlichen Eintrag der Reservierung.
Behalten Sie die brauchbaren Teile der Demo. Die Analyse sollte erklären, was bleiben kann, was sich ändern muss und was noch nicht geprüft wurde. Welcher Teil wohin gehört, sieht man an den Bildschirmen allein nicht.
Prüfen Sie, was jede Person tun darf
Beschreiben Sie die Rollen in Ihrem Produkt und was jede Rolle sehen oder ändern darf. Einen Admin-Button in der Oberfläche auszublenden ist nur ein Teil davon; geschützte Aktionen und Daten müssen auch auf dem Server abgesichert sein.
In einem Kundenportal testen Sie zum Beispiel, dass ein Kunde nicht die Daten eines anderen abrufen kann und dass das Entfernen eines Mitarbeiterzugangs die gewünschte Wirkung hat. DerOWASP Application Security Verification Standard ist eine Referenz, um Sicherheitsprüfungen einer Anwendung zu strukturieren. Welche Prüfungen Sie für Ihr Produkt auswählen, sollte sich nach seinen Daten und Risiken richten.
Spielen Sie Fehler und wiederholte Aktionen durch
Ein Kunde verliert vielleicht die Verbindung, lädt eine Seite neu, sendet etwas doppelt ab oder kommt zurück, nachdem eine Integration in ein Timeout gelaufen ist. Für solche Situationen brauchen wir ein vereinbartes Ergebnis, besonders wenn es um Geld, Lagerbestand oder wichtige Daten geht.
Was soll passieren, wenn eine Zahlung aussteht oder fehlschlägt?
Kann jemand eine Anfrage gefahrlos wiederholen, ohne ein Duplikat zu erzeugen?
Was sehen Nutzer, wenn ein Upload oder eine Benachrichtigung fehlschlägt?
Wie findet und löst Ihr Team einen unvollständigen Vorgang?
Im Buchungsbeispiel dürfen wiederholte Klicks nicht zu mehreren Reservierungen für einen beabsichtigten Kauf führen. Die passende Umsetzung hängt vom Zahlungsanbieter und den Buchungsregeln ab; dieses Verhalten gehört in Umfang und Tests.
Arbeiten Sie mit realistischen Daten und Abläufen
Testen Sie lange Namen, leere Listen, längere Verläufe, fehlende Felder und die Geräte, die Menschen nutzen werden. Ein Dashboard mit fünf Beispielzeilen zeigt nicht, wie jemand einen Datensatz unter Tausenden findet. Verwenden Sie geeignete Testdaten, statt private Kundendaten in eine ungeschützte Vorschau zu kopieren.
Wenn bestehende Daten ins Produkt übernommen werden müssen, planen Sie die Zuordnung, einen Probeimport und die Prüfungen. Legen Sie fest, wie doppelte oder unvollständige Datensätze behandelt werden und was mit Änderungen während der Umstellung passiert.
Machen Sie den Release- und Wiederherstellungsplan ausdrücklich
Klären Sie, wem die Hosting- und Dienstkonten gehören, welche Konfiguration nötig ist und wie das Release in die richtige Umgebung kommt. Bevor eine Änderung live geht, vereinbaren Sie die Prüfungen und den Weg zurück, falls sie Probleme verursacht.
Wiederherstellung kann mehr bedeuten, als eine ältere Version des Codes einzuspielen. Eine Änderung an gespeicherten Daten braucht ein eigenes Vorgehen. Das Team sollte wissen, welche Backups es gibt, wie man sie wiederherstellt und welche Prüfungen bestätigen, dass das Produkt danach funktioniert.
Starten Sie, um zu lernen, mit einer klaren Zuständigkeit für den Dienst
Ein kontrollierter Start mit einer passenden Gruppe kann Probleme aufdecken, bevor mehr Menschen Zugang bekommen. Legen Sie fest, wie Feedback und Fehler gesammelt werden, wer reagiert und was Sie dazu bringen würde, die Einführung zu pausieren oder zurückzunehmen. DieHinweise von GOV.UK zur Beta-Phase beschreiben, wie man mit einem begrenzten Start lernt und verbessert, bevor ein Dienst breiter geöffnet wird.
Den Kernablauf hat geprüft: …
Berechtigungen und wichtige Fehlerfälle hat geprüft: …
Die verbleibenden Einschränkungen sind: …
Die Schritte für Release und Wiederherstellung sind dokumentiert unter: …
Für Feedback und Störungen zuständig ist: …
Wir erweitern den Zugang, wenn: …
Das sind Fragen für die Planung, keine Sicherheitszertifizierung. Wie viel geprüft wird, sollte zum Produkt und zu den Folgen eines Ausfalls passen. Wenn Sie einen Prototyp haben,erzählen Sie mir, was schon funktioniert und was Sie starten möchten. Ich gehe die nächsten Schritte gern mit Ihnen durch.