Un plan de pruebas explica qué se probará, por qué, cómo, quién lo hará y en qué condiciones. Su valor procede de una comprensión compartida del enfoque y los límites, no de la longitud del documento.
Cuándo resulta útil un plan de pruebas
- →La funcionalidad es amplia, arriesgada o implica a varios equipos.
- →El alcance, las prioridades, los entornos, los roles y los criterios de preparación requieren un acuerdo explícito.
- →Las expectativas externas incluyen auditorías, cumplimiento, regulación o informes formales.
- →Sin un plan acordado, el equipo puede interpretar de forma distinta la profundidad y los límites de las pruebas.
Qué incluye un buen plan
- →Los objetivos de las pruebas y los principales riesgos.
- →El alcance incluido y excluido.
- →Los tipos y niveles de prueba aplicables.
- →Los entornos, datos de prueba y dependencias.
- →Los roles, responsabilidades, plazos y criterios de finalización.
Qué evitar
- →Plantillas genéricas desconectadas del producto.
- →Información excesiva que nadie utiliza.
- →Un documento estático que se redacta una vez y nunca se actualiza.
- →Sustituir el análisis real de riesgos y estrategia por trámites documentales.
Recomendación práctica
Un buen plan responde a preguntas reales: qué es crítico, dónde están los riesgos, qué queda fuera de las pruebas, qué falta para alcanzar la calidad y qué evidencias respaldarán la entrega. Si no facilita las decisiones, es demasiado complicado o abstracto.
Ejemplo completado: una pequeña entrega de un formulario de pago
Todo este plan parte de supuestos didácticos ficticios. No es un informe sobre un banco, un cliente ni una versión publicada. La aplicación acepta tokens de pago ficticios y llama a un stub local del proveedor que devuelve approved, declined o timeout. No hay datos de tarjetas, cuentas ni dinero reales. Los importes son céntimos enteros de una única moneda de demostración configurada explícitamente.
ID del plan: PAY-DEMO-1; versión: 1; responsable: ingeniero de QA
Objetivo: validar el formulario de pago y evitar pagos exitosos duplicados.
Objeto de prueba: una versión de demostración congelada; registrar su commit y configuración reales antes de ejecutar.
Incluido: envío, validación, resultados del proveedor, repetición de solicitud, repetición de callback, actualización de la página de resultado, teclado y diseño de 375 px.
Excluido: proveedor real, liquidación real, reembolsos, suscripciones, 3-D Secure, otras monedas y certificación de carga/seguridad.
Entorno: aplicación local desechable + stub del proveedor + base de datos con datos de prueba.
Datos: cliente/pedido sintético nuevo por caso; restablecer el registro del stub entre casos.
Observación: IDs de solicitud, registro de pagos del stub y registros de pedidos de solo lectura.
Personas: un ingeniero de QA; desarrollador disponible para correcciones; responsable de producto decide sobre el riesgo residual aceptado.
Estimación, no compromiso: dos días laborables de 6 horas de QA cada uno; 2 horas de apoyo del desarrollador y 1 hora de revisión del responsable.
Entregables: correspondencia entre requisitos y casos, registro de ejecución, evidencias sin datos sensibles, defectos y recomendación de entrega.Alcance basado en riesgos con resultados observables
Los casos C01–C08, C11 y C12 son de alto riesgo en este ejemplo: los pagos duplicados, los importes incorrectos, los falsos éxitos o los errores de repetición pueden corromper el estado financiero. C09–C10 son comprobaciones de usabilidad y también forman parte del alcance. Las expectativas siguientes son requisitos de la demostración, no comportamientos universales de una API de pagos.
ID Escenario Esperado
C01 token approved Un pedido confirmado por 1999 céntimos; un pago aceptado
C02 token declined Mensaje de rechazo; ningún pedido pagado ni pago exitoso
C03 token timeout Se muestra pendiente/desconocido; ningún segundo pago automático
C04 misma clave y mismo cuerpo dos veces Mismo resultado registrado; un pago y un pedido
C05 misma clave e importe modificado Se informa de conflicto; ningún pago ni pedido nuevo
C06 token de pago ausente Error de campo; ninguna solicitud de pago
C07 el servidor recibe importe cero La API lo rechaza; ningún pago ni pedido
C08 callback approved duplicado Una transición a pagado; el registro de pagos contiene un éxito
C09 solo teclado Todos los controles son accesibles; envío y errores operables sin ratón
C10 ventana de 375 px Sin desbordamiento horizontal; total y control de envío visibles
C11 actualizar página de resultado Se muestra el pedido existente; no se reenvía el pago
C12 inspeccionar transacción de 1999 céntimos UI, solicitud y pedido guardado coinciden en importe y monedaCriterios de entrada, suspensión y salida
Entrada: los 12 resultados esperados están revisados; el identificador de compilación está registrado; los modos approved/declined/timeout del stub están verificados; existe un cliente de prueba; el registro de pagos es legible; las pruebas smoke del entorno se superan. Si falla algún criterio de entrada, registra el bloqueo en lugar de dar por completamente probada la compilación.
Suspende las pruebas si el registro no está disponible, no puede restablecerse el fixture o los pagos duplicados observados ponen en duda la validez de los casos posteriores. Conserva las evidencias. Reanuda cuando se haya corregido la causa, se supere el smoke del entorno y se restablezcan y repitan los casos afectados.
Salida para emitir una recomendación: los 12 casos se han ejecutado con evidencias; los 10 de alto riesgo se superan; C09 y C10 se superan o tienen una excepción documentada con un responsable identificado; no hay defectos abiertos que causen éxitos duplicados, importes incorrectos o estados de pago falsos; cada defecto de alto riesgo corregido se ha vuelto a probar y se superan las comprobaciones de regresión afectadas. Indica explícitamente cualquier funcionalidad excluida. Un plazo por sí solo no satisface estos criterios.
Ejemplo de calendario: día 1 — revisión de requisitos 1 h, entorno y datos 1 h, preparación de casos 2 h, ejecución 2 h. Día 2 — ejecución restante 2 h, correcciones y pruebas de confirmación 2 h, regresión afectada 1 h, resumen 1 h. Si cambia el comportamiento del proveedor o se sustituye la compilación, vuelve a estimar y ejecutar las comprobaciones afectadas; no conserves silenciosamente los estados anteriores de «superado».
Plantilla de plan para copiar
Plan / versión / responsable:
Cambio y objetivo de negocio:
Objeto de prueba / versión / configuración:
Requisitos y riesgos principales:
Incluido / excluido:
Entorno / datos sintéticos / procedimiento de restablecimiento:
Mecanismos de observación y evidencias:
IDs de casos vinculados a riesgos y resultados esperados:
Roles / capacidad / estimación / dependencias:
Criterios de entrada:
Criterios de suspensión / reanudación:
Criterios de salida y responsable de la decisión:
Riesgos residuales / excepciones / próxima fecha de revisión:
Enlace al informe de ejecución:Este documento especifica trabajo pendiente; no afirma que los doce casos se hayan superado en una aplicación de pagos real. Durante la ejecución, añade a cada caso el resultado obtenido, el estado, las evidencias y los enlaces a defectos. Entrega a quien decide sobre la publicación tanto la cobertura como el riesgo restante, no solo un porcentaje de casos superados.
Seguir aprendiendo
Relacionar el plan de una entrega con la estrategia de pruebas
Organizar las pruebas de una entrega