Zum Inhalt springen
Leitfaden7 Min. Lesezeit

Firebase Studio App-Review-Rundgang-Video

Belegen Sie mit der ausgelieferten App, nicht dem Workspace, dass der Build passt.

Geben Sie einer prüfenden Person einen Ablauf, der belegt, dass der Build zum Briefing passt, mit der ausgelieferten App statt der Workspace Vorschau.

Ansehen, wie es funktioniertDie ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um es herunterzuladen.

Ein Firebase Studio Review Walkthrough existiert, um die Lücke zwischen einem Statusupdate, das sagt, eine Funktion sei fertig, und dem tatsächlichen Beweis, dass sie funktioniert, zu schließen. Eine prüfende Person, die liest "die Exportfunktion ist fertig", kann aus diesem Satz nicht erkennen, ob er bedeutet, dass der Button eine korrekte Datei erzeugt, oder dass jemand es gehofft hat. Ein kurzes Video des tatsächlich stattfindenden Exports, das mit einer Datei endet, die die prüfende Person sehen kann, entfernt diese Unklarheit auf eine Weise, die ein schriftliches Update nicht kann.

GogoScreen erzeugt das aus einer öffentlichen App URL und einem einzeiligen Hinweis und liefert etwa zwei Minuten später einen erzählten MP4, mit Zooms auf Klicks, geglätteter Cursorbewegung, entfernter Stille und eingebrannten Untertiteln. Wenn der Ablauf einen Login braucht, kann ein Demokonto bereitgestellt werden, das verschlüsselt, für genau einen Renderdurchlauf verwendet und danach gelöscht wird. Wird zuerst ein Storyboard geplant, bleiben die Zugangsdaten für diese Sitzung verschlüsselt und werden spätestens zwei Stunden nach ihrer letzten Verwendung gelöscht. Das ist der Beweis für einen geprüften Ablauf, nicht die Behauptung, dass der ganze Build geprüft wurde oder dass irgendein Render beim ersten Versuch garantiert gelingt.

Warum die ausgelieferte App statt des Workspace aufnehmen?

Die Workspace Vorschau innerhalb von Firebase Studio hängt an dem Google Cloud Projekt, zu dem jemand Zugang hat, was oft nur die Person ist, die die App baut, nicht die prüfende Person, die sie freigeben soll. Diesen Link an eine prüfende Person zu senden scheitert entweder vollständig oder bedeutet, ihr Projektzugang weit über das hinaus zu gewähren, was eine Prüfung erfordert. Liefern Sie den Build an seine öffentliche Firebase Hosting URL aus und nehmen Sie von dort auf, damit die prüfende Person genau das sieht, was eine spätere Endnutzerin sehen würde.

Das hat auch einen Nebennutzen, der es wert ist, im Blick behalten zu werden. Ein Ablauf, der sich nur korrekt innerhalb der Entwicklungs Workspace verhält, weil er auf Umgebungsvariablen oder eine Testkonfiguration angewiesen ist, die sich nicht in die ausgelieferte Version überträgt, ist nicht wirklich fertig, selbst wenn er im Workspace fertig aussieht. Die Aufnahme von der ausgelieferten URL bringt diese Lücke ans Licht, bevor es die prüfende Person tut.

PrüfanforderungWarum die ausgelieferte URL sie erfülltWarum die Workspace Vorschau es nicht tut
Prüfende Person kann ohne zusätzlichen Zugang zusehenÖffentliche Hosting URL braucht keinen Projekt LoginWorkspace Vorschau braucht dasselbe Google Konto wie der Build
Bestätigt das ausgelieferte VerhaltenZeigt, was eine Endnutzerin tatsächlich sehen wirdKann sich vom Workspace durch Umgebungsunterschiede unterscheiden
Wiederverwendbarer Beweis für das BriefingEin dauerhaftes aufgenommenes Artefakt zu einer bestimmten AnfrageDanach keine stabile, teilbare Referenz

Was genau sollte die Aufnahme beweisen?

Lesen Sie die konkrete Zeile im Briefing erneut, bevor Sie den Ablauf wählen, nicht den allgemeinen Funktionsumfang der App. Wenn im Briefing stand "eine Adminperson kann eine Einreichung freigeben und sie erscheint in der öffentlichen Liste", muss der Walkthrough genau das zeigen, beginnend bei der Aktion der Adminperson und endend beim öffentlichen Erscheinen der Einreichung. Alles, was der Walkthrough über diese konkrete Anfrage hinaus zeigt, ist zusätzlich, und alles, was er nicht zeigt, obwohl das Briefing es verlangte, lässt die Prüfung unvollständig.

  • Passen Sie den Ablauf in der Aufnahme genau an den Wortlaut des Briefings an.
  • Starten Sie die Aufnahme im Zustand direkt vor dem beschriebenen Auslöser.
  • Beenden Sie die Aufnahme, sobald das beschriebene Ergebnis sichtbar ist, nicht früher oder später.
  1. Lesen Sie das Briefing erneut und wählen Sie den einen Ablauf, der belegt, dass die konkrete Anfrage erfüllt wurde.
  2. Bereiten Sie die ausgelieferte App im Zustand direkt vor dem Auslöser vor, mit sicheren Demodaten.
  3. Nehmen Sie den Walkthrough auf und vermerken Sie alles aus dem Briefing, das noch offen oder ungelöst ist.

Welcher Ablauf tatsächlich belegt, dass das Briefing erfüllt wurde, hängt davon ab, was der Build ist. Wenn die geprüfte App ein Kundenportal ist, deckt der Client Portal Demo Video Guide ab, wie man den einen Status auswählt, den eine Kundin tatsächlich zum Nachsehen einloggt, dieselbe Art konkreten Beweises, um die dieser Walkthrough gebaut ist. Wenn es ein CRM ist, deckt der CRM Demo Video Guide ab, wie man einen Deal oder Kontakt auswählt, der sich durch eine echte Aktion bewegt, statt jeden Tab zu bereisen. Wenn es ein internes Dashboard ist, deckt der Internal Dashboard Demo Video Guide ab, wie man die eine Kennzahlenansicht wählt, die die Frage beantwortet, für die das Dashboard gebaut wurde.

Wie sollte die App vor der Aufnahme eingerichtet werden?

Bringen Sie die ausgelieferte App in den Zustand direkt vor dem beschriebenen Auslöser, mit im Voraus vorbereiteten Daten statt die Einrichtung selbst aufzunehmen. Wenn der Ablauf davon abhängt, dass ein Datensatz bereits existiert oder eine Nutzerin bereits eingeloggt ist, richten Sie das vor der Anfrage des Renders ein, damit die Aufnahme direkt beim relevanten Moment beginnt. Eine prüfende Person muss die Kontoerstellung nicht sehen, bevor sie die Funktion sieht, die sie eigentlich prüft.

Wenn an dieser Stelle im Ablauf normalerweise echte Kundendaten vorhanden wären, setzen Sie erfundene, aber glaubwürdige Daten ein. Eine prüfende Person, die beurteilt, ob die Logik funktioniert, muss dafür nichts Sensibles sehen, und erfundene Daten vermeiden jede spätere Frage, ob etwas Privates in einer aufgenommenen Datei gelandet ist.

Führen Sie neben den erfundenen Daten eine kurze schriftliche Notiz, die erklärt, was wofür steht, falls später eine zweite prüfende Person hinzukommt und verstehen muss, warum ein Name im Video zu nichts im echten Projekt passt. Das ist eine kleine Gewohnheit, spart aber Wochen später ein verwirrendes Gespräch, wenn sich niemand mehr erinnert, welche Teile eines aufgenommenen Ablaufs für die Prüfung inszeniert waren und welche tatsächlich zum Verhalten der App gehörten.

Was passiert, wenn der Walkthrough ein Problem aufdeckt?

Manchmal deckt die Vorbereitung der Aufnahme das eigentliche Problem auf: Der Ablauf tut nicht ganz das, was das Briefing beschrieb, oder er funktioniert im Workspace, aber nicht auf der ausgelieferten URL. Übertünchen Sie das nicht mit einem Hinweis, der um den defekten Teil herumsteuert. Vermerken Sie die Abweichung klar, zusammen mit was auch immer an teilweisem Beweis existiert, und behandeln Sie die Prüfung als unvollständig statt als freigegeben. Ein Walkthrough, der geschickt wird, um ein Problem kleiner aussehen zu lassen, als es ist, untergräbt das Vertrauen der prüfenden Person in den nächsten.

Etwa einer von fünf Renderdurchläufen braucht einen erneuten Versuch, unabhängig davon, ob die zugrunde liegende App korrekt funktioniert, also bauen Sie einen kleinen Puffer in jede Prüffrist ein, statt anzunehmen, der erste Render komme immer sofort nutzbar zurück.

Behandeln Sie einen fehlgeschlagenen oder wiederholten Render als normalen Teil des Prozesses, nicht als Zeichen, dass mit dem Build etwas nicht stimmt. Die beiden sind unabhängig voneinander. Ein perfekt funktionierender Ablauf kann trotzdem einen zweiten Renderversuch brauchen, und ein wirklich defekter Ablauf kann gelegentlich sauber rendern und die Abweichung trotzdem zeigen. Beurteilen Sie die App nach dem, was das Video tatsächlich zeigt, sobald es zurückkommt, nicht danach, wie viele Versuche es dafür brauchte.

Wie fügt sich das in den Rest des Prüfprozesses?

Dieser Walkthrough kommt meist nach einer internen Prüfung und bevor der Build eine Kundin oder die Öffentlichkeit erreicht. Der Softr Demo Video Guide, der Softr Landing Page Video Guide, der Softr Product Hunt Launch Video Guide, der Softr Share with a Client Guide, und der Softr Portfolio Demo Guide decken die vergleichbaren Stufen auf einer anderen Builder Plattform ab, nützlich, um zu sehen, welche Prüfstufe ein bestimmtes Video bedienen soll, da ein Portfolio Eintrag, eine Kundenübergabe und ein interner Review Walkthrough drei verschiedene Aufgaben sind, selbst wenn die zugrunde liegende App dieselbe ist. Der AI Agent README Demo Guide ist ein verwandtes Dokumentationsasset für eine technische prüfende Person, die ein schriftliches Gegenstück zum Video möchte. Für einen Build, der größtenteils von einem autonomen Coding Agent statt einer Person direkt im Editor erstellt wurde, deckt der AI Agent Feature Walkthrough Guide den entsprechenden Beweis für eine einzelne Fähigkeit ab, und der Agent Handoff Demo Video Guide deckt die Aufnahme ab, die folgt, sobald eine prüfende Person freigegeben hat und die Arbeit zu wem auch immer sie als nächstes besitzt weitergeht.

Wenn der Build in Frage aus einem generierten Prompt statt aus manueller Arbeit im Editor stammt, decken der Prompt Built App Demo Video Guide und der AI Agent Landing Page Demo Guide diesen Rahmen direkter ab. Für einen Ablauf, der nur hinter einem Login existiert, deckt der Logged In App Demo Video Guide die Einzelheiten dieser Einrichtung ab, und der AI Agent Demo Video Prompt Guide deckt ab, wie man den einzeiligen Hinweis präzise genug schreibt, um zu dem zu passen, was die prüfende Person tatsächlich kontrolliert. Vergleichen Sie GogoScreen mit einem dedizierten Aufnahmetool unter GogoScreen gegen Loom, prüfen Sie die Preise für Pläne und Aufladungen, durchsuchen Sie die vollständige Guides Bibliothek und die Vergleichsseiten, oder starten Sie bei der GogoScreen Startseite für den URL und Hinweis Arbeitsablauf selbst.

Klarstellungen

Bevor Sie beginnen

Sollte ein Firebase Studio Review Walkthrough aus dem Workspace oder der ausgelieferten App aufgenommen werden?

Nehmen Sie ihn wenn möglich von der öffentlichen, ausgelieferten URL auf. Die Workspace Vorschau verlangt meist denselben Google Konto Zugang wie der Build selbst, den die prüfende Person eventuell nicht hat und für eine Prüfung auch nicht braucht.

Was sollte der Walkthrough beweisen?

Dass der im Briefing beschriebene Ablauf durchgängig funktioniert und das im Briefing beschriebene Ergebnis liefert, nicht dass die App allgemein fertig wirkt.

Ersetzt ein Review Walkthrough das Lesen des Codes?

Nein. Er ersetzt die Bitte an eine nicht technische prüfende Person, den Code zu lesen oder sich selbst durch die App zu klicken. Eine technische prüfende Person möchte sich die Umsetzung möglicherweise trotzdem separat ansehen.

Fügen Sie eine URL ein, beschreiben Sie einen Ablauf und erhalten Sie ein Demovideo Ihrer Webanwendung.

Die ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um das Video herunterzuladen.