Saltar al contenido
Guía8 min de lectura

Recorrido de revisión de una app de Firebase Studio

Demuestre que la app cumple el encargo con la desplegada, no con el entorno de trabajo.

Dé a un revisor un flujo grabado que demuestre que la app cumple el encargo, usando la app desplegada, no la vista previa del entorno de trabajo.

Ver cómo funcionaLos primeros 60 segundos de vídeo son gratuitos, con marca de agua. Verifique su correo electrónico para descargarlo.

Un recorrido de revisión de Firebase Studio existe para cerrar la brecha entre una actualización de estado que dice que una función está terminada y una prueba real de que funciona. Un revisor que lee "la función de exportación está terminada" no puede saber por esa frase si significa que el botón produce un archivo correcto o que alguien esperaba que lo hiciera. Un vídeo corto de la exportación ocurriendo de verdad, que termine con un archivo que el revisor pueda ver, elimina esa ambigüedad de una forma que una actualización escrita no puede.

GogoScreen produce esto a partir de una URL pública de la app y una indicación de una sola línea, y devuelve un MP4 narrado en aproximadamente dos minutos, con zooms en los clics, suavizado del cursor, silencios muertos eliminados y subtítulos integrados. Si el flujo necesita iniciar sesión, se puede proporcionar una cuenta de demostración: se cifra, se usa para una sola renderización y después se elimina. Si primero se planifica un storyboard, las credenciales se conservan cifradas durante esa sesión y se eliminan como máximo dos horas después de su último uso. Esto es la prueba de un flujo que se comprobó, no una afirmación de que se revisó todo en la app ni de que cualquier renderización tenga garantizado el éxito en el primer intento.

¿Por qué grabar la app desplegada en lugar del entorno de trabajo?

La vista previa del entorno de trabajo dentro de Firebase Studio está ligada a quien tenga acceso al proyecto de Google Cloud subyacente, que a menudo es solo la persona que construye la app, no el revisor que espera aprobarla. Enviarle ese enlace al revisor falla directamente o significa concederle un acceso al proyecto mucho más amplio de lo que exige una revisión. Despliegue la app en su URL pública de Firebase Hosting y grabe desde ahí para que el revisor vea exactamente lo que vería un usuario final.

Esto también tiene un beneficio secundario que vale la pena tener en cuenta. Un flujo que solo se comporta correctamente dentro del entorno de trabajo de desarrollo, apoyándose en variables de entorno o configuración de prueba que no se traslada a la versión desplegada, no está realmente terminado aunque parezca terminado en el entorno de trabajo. Grabar desde la URL desplegada saca a la luz esa brecha antes de que lo haga el revisor.

Requisito de la revisiónPor qué la URL desplegada lo satisfacePor qué la vista previa del entorno de trabajo no lo satisface
El revisor puede verlo sin acceso adicionalLa URL pública de alojamiento no necesita inicio de sesión en el proyectoLa vista previa del entorno de trabajo necesita la misma cuenta de Google que la app
Confirma el comportamiento publicadoMuestra lo que verá de verdad un usuario finalPuede diferir de lo desplegado por diferencias de entorno
Prueba reutilizable para el encargoUn artefacto grabado y duradero ligado a una petición concretaNo es una referencia estable y compartible después

¿Qué debe demostrar exactamente la grabación?

Relea la línea concreta del encargo antes de elegir el flujo, no el conjunto general de funciones de la app. Si el encargo decía "un administrador puede aprobar un envío y este aparece en la lista pública", el recorrido necesita mostrar precisamente eso, empezando por la acción del administrador y terminando con el envío apareciendo públicamente. Cualquier cosa que el recorrido muestre más allá de esa petición concreta es de más, y cualquier cosa que no muestre que el encargo pedía deja la revisión incompleta.

  • Haga coincidir el flujo de la grabación con el texto exacto del encargo.
  • Empiece la grabación en el estado justo antes del disparador descrito.
  • Termine la grabación en cuanto sea visible el resultado descrito, ni antes ni después.
  1. Relea el encargo y elija el único flujo que demuestra que se cumplió la petición concreta.
  2. Prepare la app desplegada en el estado justo antes del disparador, usando datos de demostración seguros.
  3. Grabe el recorrido y anote cualquier cosa del encargo que siga abierta o sin resolver.

Qué flujo demuestra realmente que se cumplió el encargo depende de qué sea la app. Si la app en revisión es un portal de cliente, la guía de vídeo demo de portal de cliente cubre elegir el único estado que un cliente realmente entra a comprobar, que es el mismo tipo de prueba concreta en torno a la que se construye este recorrido. Si es un CRM, la guía de vídeo demo de una app de CRM cubre elegir un trato o un contacto que se mueve a través de una acción real en lugar de recorrer cada pestaña. Si es un panel interno, la guía de vídeo demo de panel interno cubre elegir la única vista de métrica que responde a la pregunta para la que se construyó el panel.

¿Cómo debe prepararse la app antes de grabar?

Ponga la app desplegada en el estado justo antes del disparador descrito, usando datos preparados de antemano en lugar de grabar la propia preparación. Si el flujo depende de que ya exista un registro o de que un usuario ya haya iniciado sesión, organícelo antes de pedir la renderización para que la grabación se abra directamente en el momento relevante. Un revisor no necesita ver la creación de una cuenta antes de ver la función que realmente está revisando.

Si en este punto del flujo normalmente estarían presentes los datos de un cliente real, sustitúyalos por datos inventados pero creíbles. Un revisor que evalúa si la lógica funciona no necesita ver nada sensible para llegar a ese juicio, y usar datos inventados evita cualquier duda posterior sobre si algo privado acabó en un archivo grabado.

Guarde una nota breve escrita junto a los datos inventados que explique qué sustituye a qué, por si un segundo revisor se une al proceso más adelante y necesita entender por qué un nombre en el vídeo no coincide con nada del proyecto real. Es un hábito pequeño, pero evita una conversación confusa semanas después, cuando ya nadie recuerda qué partes de un flujo grabado se prepararon para la revisión y cuáles formaban genuinamente parte del comportamiento de la app.

¿Qué ocurre cuando el recorrido revela un problema?

A veces preparar la grabación saca a la luz el problema real: el flujo no hace exactamente lo que describía el encargo, o funciona en el entorno de trabajo pero no en la URL desplegada. No disimule eso con una indicación que rodee la parte rota. Anote la discrepancia con claridad, junto con cualquier prueba parcial que exista, y trate la revisión como incompleta en lugar de aprobada. Un recorrido enviado para que un problema parezca más pequeño de lo que es socava la confianza del revisor en el siguiente.

Aproximadamente una de cada cinco renderizaciones necesita un segundo intento, independientemente de si la app subyacente funciona correctamente, así que incorpore un pequeño margen a cualquier plazo de revisión en lugar de asumir que la primera renderización siempre volverá utilizable.

Trate una renderización fallida o repetida como una parte normal del proceso, no como una señal de que algo va mal con la app. Las dos cosas no están relacionadas. Un flujo que funciona perfectamente todavía puede necesitar un segundo intento de renderización, y un flujo genuinamente roto en ocasiones puede renderizarse limpiamente y mostrar igual el desajuste. Juzgue la app por lo que realmente muestra el vídeo una vez que vuelve, no por cuántos intentos hicieron falta para llegar hasta ahí.

¿Dónde encaja esto con el resto del proceso de revisión?

Este recorrido suele llegar después de una comprobación interna y antes de que la app llegue a un cliente o al público. La guía de vídeo demo de Softr, la guía de vídeo demo de página de destino de Softr, la guía de vídeo de lanzamiento de Softr en Product Hunt, la guía de compartir Softr con un cliente y la guía de demo de portafolio de Softr cubren las etapas equivalentes en otra plataforma de creación, útiles para ver qué etapa de revisión cumple un vídeo concreto, ya que una entrada de portafolio, un traspaso a un cliente y un recorrido de revisión interno son tres trabajos distintos aunque la app subyacente sea la misma. La guía de demo README de un agente de IA es un activo de documentación relacionado para un revisor técnico que quiera un complemento escrito al vídeo. Para una app construida en gran parte por un agente de código autónomo en lugar de por una persona trabajando directamente en el editor, la guía de recorrido de función de un agente de IA cubre la prueba equivalente para una sola capacidad, y la guía de vídeo demo de traspaso de un agente cubre la grabación que llega después de que un revisor haya dado el visto bueno y el trabajo pase a quien lo posea a continuación.

Si la app en cuestión viene de una indicación generada en lugar de trabajo manual en el editor, la guía de vídeo demo de una app construida con una indicación y la guía de demo de página de destino de un agente de IA cubren ese enfoque de forma más directa. Para un flujo que solo existe detrás de un inicio de sesión, la guía de vídeo demo de una app con sesión iniciada cubre los detalles de esa configuración, y la guía de la indicación de vídeo demo de un agente de IA cubre cómo escribir la indicación de una sola línea con la precisión suficiente para que coincida con lo que el revisor realmente está comprobando. Compare GogoScreen con una herramienta de grabación dedicada en GogoScreen frente a Loom, consulte los precios para conocer los planes y las recargas, explore la biblioteca completa de guías y las páginas de comparación, o empiece por la página de inicio de GogoScreen para el flujo de trabajo de URL e indicación en sí.

Aclaraciones

Antes de empezar

¿Un recorrido de revisión de Firebase Studio debe grabarse desde el entorno de trabajo o desde la app desplegada?

Grábelo desde la URL pública desplegada siempre que sea posible. La vista previa del entorno de trabajo normalmente requiere el mismo acceso de cuenta de Google que la propia app, algo que el revisor puede no tener y no debería necesitar para una revisión.

¿Qué debe demostrar el recorrido?

Que el flujo de trabajo concreto descrito en el encargo se ejecuta de principio a fin y produce el resultado que describía el encargo, no que la app en general parezca terminada.

¿Un recorrido de revisión sustituye la lectura del código?

No. Sustituye pedirle a un revisor no técnico que lea el código o que recorra la app por sí mismo. Un revisor técnico puede seguir queriendo mirar la implementación por separado.

Pegue una URL, describa un flujo y obtenga un vídeo de demostración de su aplicación web.

Los primeros 60 segundos de vídeo son gratuitos, con marca de agua. Verifique su correo electrónico para descargar el vídeo.