Pruebas y verificación

Definir el éxito antes del cambio

Dé a Amazi un criterio de aceptación observable. "Agregar un formulario de contacto" es menos específico que "guardar una solicitud válida, mostrar confirmación después de guardar y permitir que el personal vea la nueva solicitud".

Elija la página, la función, el estado de los datos, la acción y el resultado esperado. Para errores, incluya pasos reproducibles y lo que debe permanecer sin cambios.

Comprender los diferentes controles

• Las comprobaciones de formato, pelusa y tipo encuentran problemas particulares en el código fuente.
• Pruebas automatizadas verifican los casos que realmente cubren.
• Una compilación exitosa muestra que la aplicación se puede compilar con esa configuración.
• Una respuesta de salud muestra que un criterio de valoración específico respondió.
• Verificación del navegador comprueba la interacción representada y el resultado visible.
• Verificación de producción comprueba la versión activada en su dirección pública.

Estos controles se complementan entre sí. Una compilación exitosa o HTTP 200 no prueba que un formulario se guarde, que una ruta protegida aplique permisos o que se pueda acceder a la vista previa pública.

Amazi trata las tareas sin escritura o cambios de código, y los cambios de código que suman aproximadamente 100 líneas o menos, como simples. Estima el código que espera agregar, cambiar o eliminar; No es necesario contar líneas ni clasificar la tarea. El tamaño del proyecto existente no determina la cantidad de trabajo. Para estas tareas, el formato, la revisión de código, la pelusa, las comprobaciones de tipo, la escritura o ejecución de pruebas y las compilaciones son opcionales; Amazi elige pasos útiles y puede completar la tarea sin ellos. Si necesita un cheque en particular, solicítelo explícitamente. Los cambios de código más importantes requieren una verificación relevante. Una verificación que no se ejecutó no debe reportarse como aprobada.

Amazi puede continuar el trabajo independiente mientras se ejecuta una compilación o verificación y luego leer su resultado. Para comandos de proyecto más largos, puede permitir hasta cinco minutos. Un comando iniciado no es una verificación exitosa: espere el resultado real antes de considerarlo verificado.

Revisar el recorrido completo del usuario

Abra la página afectada en Vista previa. Verifique la ruta normal y un caso de falla relevante. Para un formulario, pruebe con entradas válidas, entradas no válidas y el resultado después de recargar. Para la navegación, verifique las URL directas de las páginas y el comportamiento hacia adelante y hacia atrás del navegador en lugar de solo hacer clic entre vistas.

Revise el diseño del teléfono y el escritorio. Confirme que los controles sigan siendo accesibles y que el contenido no se desborde. Para flujos de trabajo con sesión iniciada, verifique el rol apropiado usando Usuarios de la aplicación y autenticación.

Utilice datos sintéticos. La vista previa puede escribir en la misma base de datos administrada que la producción, por lo que las acciones de prueba no son automáticamente inofensivas.

Antes de publicar

Confirme qué versión de origen se lanzará, que las conexiones requeridas y los valores del entorno estén configurados y que los flujos de trabajo afectados hayan pasado las comprobaciones previstas. Publicar código y cambiar el estado de la base de datos son preocupaciones separadas.

Solicite a Amazi que informe qué se verificó realmente y qué queda sin verificar. No interprete "implementado" como "publicado" o "publicado" como "cada flujo de trabajo verificado".

Después de la publicación, abra la dirección de producción y repita una prueba de humo enfocada en el comportamiento modificado. Si la implementación falla, inspeccione el diagnóstico de producción antes de volver a intentarlo. Consulte Publicación y dominios.

Cuando un cheque está bloqueado

Registre el bloqueador exacto y el escenario afectado. Si la Vista previa devuelve un error de puerta de enlace, utilice Solución de problemas de vista previa. Una vista previa no disponible debe informarse como un resultado del navegador no verificado, no disfrazada como una prueba aprobada.