Pruebas automatizadas antes de lanzar: qué cubrir primero con presupuesto limitado

Respuesta corta

Automatizá primero los recorridos que sostienen el negocio. Una base razonable incluye crear una cuenta, iniciar sesión, recuperar acceso, completar una compra, confirmar un pago, registrar un resultado y consultar el estado de una operación. Sobre esa base, agregá pruebas de humo para detectar fallas evidentes, pruebas de regresión para proteger comportamientos ya validados y monitoreo para descubrir problemas que las pruebas previas no pueden anticipar.

No intentes automatizar toda la aplicación desde el primer día. Priorizá por impacto, frecuencia y costo de falla. Dejá para revisión manual los casos visuales, exploratorios, poco frecuentes o difíciles de mantener, salvo que afecten una ruta crítica.

Cómo decidir qué cubrir primero

El presupuesto limitado obliga a elegir. Una forma simple es evaluar cada recorrido con tres preguntas:

• ¿Qué ocurre si esta función falla al momento del lanzamiento?
• ¿Cuántas veces se usa o cuántas áreas dependen de ella?
• ¿Podemos detectar el problema rápidamente si no lo prevenimos?

Las respuestas ayudan a ordenar el trabajo sin inventar porcentajes ni depender de una herramienta específica. Una falla en un botón secundario puede esperar más que una falla que impide pagar, crear una cuenta o guardar información. También importa la frecuencia de los cambios: un módulo que se modifica cada semana necesita una protección más constante que una pantalla estable y poco usada.

La tabla no reemplaza el criterio del equipo. Sirve para iniciar una conversación concreta y evitar que la automatización se distribuya de manera uniforme sobre funciones que no tienen el mismo riesgo.

La base mínima de pruebas de humo

Las pruebas de humo responden una pregunta sencilla: ¿la versión está suficientemente operativa como para seguir evaluándola? Deben ser pocas, rápidas y estables. No buscan cubrir todos los detalles, sino impedir que una versión evidentemente rota avance hacia usuarios o equipos internos.

Un conjunto inicial puede incluir:

• Abrir la aplicación y cargar la pantalla principal.
• Crear una cuenta con datos válidos.
• Iniciar sesión con una cuenta existente.
• Recuperar el acceso con un escenario controlado.
• Llegar al inicio del proceso de pago.
• Completar una operación de prueba y comprobar su resultado.
• Guardar un dato central y volver a consultarlo.
• Cerrar la sesión y confirmar que el acceso quede protegido.

Cada prueba debería tener un resultado observable. No alcanza con comprobar que una pantalla aparece: conviene verificar que la operación haya producido el estado esperado. Por ejemplo, después de confirmar una compra, la aplicación debería mostrar un resultado coherente y registrar la operación de manera consultable.

Qué aporta la regresión

La regresión protege lo que ya funcionaba frente a cambios nuevos. Es especialmente útil cuando una modificación en una parte del sistema puede afectar otra. Un cambio en el registro puede alterar el inicio de sesión. Un ajuste en el cálculo del total puede modificar el pago. Una actualización en el modelo de datos puede romper una consulta existente.

Para empezar, elegí casos que cumplan al menos una de estas condiciones:

• Se ejecutan con mucha frecuencia.
• Se modificaron recientemente.
• Tienen dependencias con otros procesos.
• Su falla sería difícil de detectar por una persona usuaria.
• Requieren repetir pasos largos o tediosos.

La regresión no debería convertirse en una colección de pruebas frágiles. Si un caso falla por un cambio superficial de texto o diseño, el equipo puede perder confianza en el conjunto. Priorizá verificaciones de comportamiento y datos antes que detalles que cambian con frecuencia.

Pagos, registro y datos: el orden recomendado

En una aplicación con operaciones comerciales, el pago merece atención temprana porque combina interacción, reglas, estados e integración. Probá al menos un escenario exitoso, un rechazo controlado y una situación en la que el resultado tarde en confirmarse. La meta no es simular todas las variantes posibles, sino comprobar que la aplicación comunique estados sin ambigüedad y no duplique una operación ante una repetición.

El registro debería cubrir datos válidos, campos obligatorios, credenciales incorrectas y recuperación de acceso. También conviene comprobar que una cuenta recién creada pueda continuar hacia las acciones que realmente necesita realizar. Un registro que funciona de manera aislada, pero deja a la persona atrapada en el paso siguiente, no representa un flujo completo.

En el manejo de datos, verificá que la información se guarde, se lea y conserve una relación coherente con la acción que la originó. Prestá especial atención a estados incompletos, reintentos y actualizaciones. No hace falta automatizar cada consulta desde el inicio, pero sí las operaciones cuya pérdida o duplicación pueda afectar la confianza en el producto.

Ejemplo trabajado: lanzamiento de un flujo de compra

Supongamos que un equipo tiene pocos días para lanzar una mejora en el proceso de compra. El recorrido incluye selección de un producto, carga de datos, confirmación y consulta posterior del estado.

Primero, el equipo identifica el camino principal: seleccionar, continuar, completar los datos, confirmar y verificar el resultado. Ese camino se convierte en una prueba automatizada de humo. Después agrega un caso de rechazo controlado para confirmar que la persona reciba una explicación útil y pueda volver a intentar sin perder información innecesariamente.

Como siguiente paso, se prueba la consulta posterior. La operación confirmada debe aparecer con un estado coherente. También se agrega una verificación contra duplicaciones cuando se repite la acción de confirmación. El equipo no automatiza todavía todas las combinaciones visuales, textos alternativos ni variaciones poco frecuentes del catálogo. Esas revisiones quedan para una sesión manual enfocada.

El resultado no es una cobertura total. Es una red pequeña que protege el ingreso al proceso, la confirmación de la operación y la consulta del estado. Si una prueba falla, el lanzamiento se detiene o se revisa según el impacto definido previamente.

Checklist antes de lanzar

• Identificamos las rutas que sostienen ingresos, acceso o datos.
• Definimos un escenario exitoso para cada ruta crítica.
• Cubrimos al menos un error relevante por ruta crítica.
• Verificamos estados pendientes, reintentos o respuestas incompletas cuando correspondan.
• Ejecutamos una prueba de humo sobre la versión candidata.
• Ejecutamos la regresión de los casos afectados por los cambios.
• Comprobamos que los datos principales se guarden y puedan consultarse.
• Definimos qué fallas bloquean el lanzamiento.
• Dejamos asignada una persona responsable de revisar resultados.
• Configuramos señales de monitoreo para detectar problemas posteriores.
• Documentamos qué queda fuera de la automatización y por qué.
• Preparamos una revisión manual para los casos de mayor incertidumbre.

Qué dejar para revisión manual

La revisión manual sigue siendo valiosa. Puede descubrir comportamientos inesperados, problemas de comprensión, inconsistencias visuales y obstáculos que una prueba automatizada no interpreta bien. También es adecuada para explorar una funcionalidad nueva cuando todavía no se conoce el conjunto de escenarios importantes.

Podés dejar para revisión manual los detalles visuales no críticos, las combinaciones poco frecuentes, el tono de los mensajes y los recorridos exploratorios. Sin embargo, no conviene usar la revisión manual como sustituto permanente de una prueba repetitiva sobre una ruta esencial. Si una persona debe repetir el mismo proceso en cada lanzamiento, probablemente exista una oportunidad de automatización.

Monitoreo después del lanzamiento

Las pruebas previas muestran lo que el equipo esperaba que ocurriera. El monitoreo ayuda a detectar lo que sucede en uso real. Para las rutas críticas, definí señales que permitan observar disponibilidad, errores, estados pendientes y diferencias entre una operación iniciada y una operación completada.

El monitoreo debe tener una respuesta asociada. Una alerta sin responsable ni criterio de acción agrega ruido. Es mejor contar con pocas señales claras que con muchos avisos imposibles de priorizar. Revisá también si los datos observados permiten distinguir una falla técnica de una confusión de uso.

Limitaciones y supuestos

Esta guía supone que el equipo puede identificar sus rutas críticas y dispone de un entorno controlado para ejecutar pruebas. No define herramientas, arquitectura ni una cantidad universal de casos. La prioridad puede cambiar según el tipo de producto, la frecuencia de uso, la sensibilidad de los datos y el costo operativo de una falla.

Automatizar una prueba no garantiza que el comportamiento sea correcto en todos los contextos. Las pruebas pueden quedar desactualizadas, omitir escenarios o validar una implementación equivocada. Por eso conviene revisar periódicamente los casos y comparar sus resultados con lo que realmente necesita la operación.

En temas regulados o con información sensible, esta orientación no reemplaza una evaluación específica del contexto aplicable. El equipo debería documentar sus decisiones y consultar a las áreas responsables cuando corresponda.

Preguntas frecuentes

¿Conviene automatizar antes de lanzar o después?

Conviene automatizar antes las rutas cuyo fallo tendría un impacto alto y cuya verificación se repite. No es necesario esperar a que toda la aplicación esté terminada. Una base pequeña y estable puede aportar valor desde el primer lanzamiento.

¿Cuántas pruebas automatizadas hacen falta?

No existe una cantidad universal. El objetivo inicial es cubrir los recorridos críticos con casos comprensibles, mantenibles y capaces de detectar fallas relevantes. La calidad de la selección importa más que el volumen.

¿Las pruebas de humo reemplazan a la regresión?

No. El humo confirma que la versión puede evaluarse. La regresión comprueba que los cambios no hayan roto comportamientos existentes. Cumplen funciones distintas y pueden compartir algunos escenarios.

¿Qué hago si una prueba falla justo antes del lanzamiento?

Clasificá la falla por impacto, posibilidad de repetición y alcance. Si afecta una ruta crítica o genera un estado incierto, tratala como un bloqueo hasta comprenderla. Si es un problema aislado y conocido, documentá la decisión y definí una revisión posterior.

¿Vale la pena automatizar la interfaz completa?

No siempre. La interfaz completa puede cambiar con frecuencia y generar pruebas costosas de mantener. Empezá por los comportamientos críticos y combiná automatización con pruebas de componentes, datos o servicios cuando resulte más estable.

Próximo paso

Elegí una ruta crítica, escribí su resultado esperado y automatizá primero el camino que más protege la operación. Después sumá un error relevante, una verificación de datos y una señal de monitoreo. Para ordenar el trabajo y consultar recursos relacionados, visitá /guias, revisá /catalogo o coordiná una conversación desde /contacto.