Qué tipos de errores buscar

Una lista de los tipos de errores que conviene probar, con títulos de caso y prioridades de ejemplo, y cómo decidir qué automatizar primero.

Esta página es una guía general de QA, no una función de Qably. Úsela como lista de verificación al planificar una funcionalidad: recorra los tipos de errores siguientes y escriba un caso para cada uno que pueda perjudicar a sus usuarios.

Los tipos de errores que conviene buscar

Tipo	Qué buscar	Título de caso de ejemplo	Prioridad sugerida
Funcional (camino feliz)	El flujo principal hace lo que promete la funcionalidad, con datos corrientes.	Crea un pedido a partir de un carrito válido	Crítico
Validación de entradas y límites	Campos obligatorios, longitudes mínimas y máximas, el valor justo dentro y justo fuera de cada límite.	Rechaza una contraseña de 7 caracteres	Alto
Caminos negativos y manejo de errores	Contraseña incorrecta, sesión vencida, un servicio que no responde.	Muestra un error cuando el servicio de pagos agota el tiempo de espera	Alto
Estado y flujo	Pasos fuera de orden, la misma acción dos veces, volver atrás, reintentar.	Cobra un pedido una sola vez cuando se selecciona Pagar dos veces	Crítico
Permisos y roles	Cada rol ve y hace solo lo que le corresponde; una cuenta no puede acceder a los datos de otra.	Niega el acceso a la factura de otra cuenta	Crítico
Integraciones y contratos	Respuestas de API, webhooks y llamadas a terceros: códigos de estado, campos, formatos y comportamiento cuando el otro lado es lento o responde mal.	Devuelve 404 para un pedido que no existe	Alto
Datos	Valores vacíos, valores muy grandes, caracteres especiales, fechas, zonas horarias y redondeos.	Guarda un nombre con tilde y apóstrofo	Medio
Regresiones	Cada error que corrige. Agregue un caso para que no vuelva sin que nadie lo note.	Aplica un cupón una sola vez por pedido	La del error original

Las prioridades son un punto de partida. El mismo tipo de error cambia de prioridad según la funcionalidad: validar el monto de un pago es Crítico; validar la biografía de un perfil es Bajo.

Redacte cada título como en nombrar las pruebas: un verbo en presente más la condición esperada, y un comportamiento por caso. "Rechaza una contraseña de 7 caracteres" puede fallar por una sola razón; "valida la contraseña" puede fallar por diez.

De una funcionalidad a una lista de casos

Restablecer una contraseña por correo parece algo pequeño, pero recorrer la tabla produce al menos seis casos:

Funcional: envía un enlace de restablecimiento a un correo registrado.
Validación: rechaza un correo con formato inválido.
Camino negativo: muestra un error cuando el servicio de correo no está disponible.
Estado: rechaza un enlace de restablecimiento que ya se usó.
Tiempo: rechaza un enlace de restablecimiento vencido.
Datos: acepta un correo escrito con mayúsculas.

No todos los tipos aplican a todas las funcionalidades. Omita los que no apliquen y escriba el resto.

Qué automatizar primero

No se puede automatizar todo a la vez. Empiece donde un fallo cuesta más o donde ocurre con más frecuencia:

Flujos críticos. Iniciar sesión, pagar y las acciones que mueven dinero o datos.
Zonas que ya fallaron. Un módulo que tuvo tres errores el trimestre pasado probablemente tendrá un cuarto.
Comportamiento estable. Una prueba sobre una pantalla que se rediseña cada semana cuesta más mantener de lo que ahorra.

Deje como casos manuales las revisiones exploratorias, las revisiones visuales puntuales y las funcionalidades que todavía se rediseñan. Qably mantiene los casos manuales y automatizados en la misma suite, de modo que ambos quedan documentados en un solo lugar.

Qué hace Qably después

Su CI envía cada reporte a Qably, así que cada caso automatizado acumula un historial de resultados. Las señales de un caso indican cuáles necesitan atención. Cuando un caso que antes pasaba empieza a fallar, leer una regresión explica cómo Qably compara dos ejecuciones y qué commits son candidatos. Para redactar los casos y elegir su prioridad, consulte cómo escribir un caso de prueba.