Un plan de pruebas es el documento que indica qué se va a comprobar, cómo, quién lo hará, en qué dispositivos y para cuándo. También define qué significa «terminado», de modo que después nadie discuta si las pruebas están hechas o no. Si estás a punto de entregar tu producto a un equipo de QA por primera vez, este documento es lo que mantiene a ambas partes trabajando hacia el mismo resultado.
Un buen plan no es papeleo por el papeleo. Probar sin ese acuerdo tiende a desviarse: el equipo de QA elige lo que le parece importante, los desarrolladores dan por hecho que otra persona cubrió el resto y las lagunas solo salen a la luz después del lanzamiento.
Esta guía recorre qué contiene un plan de pruebas real, cómo planifica QAwerk las pruebas con sus clientes y dónde encajan los casos de prueba. En lugar de repasar una plantilla genérica, usaremos ejemplos de proyectos que hemos ejecutado de verdad. Acordar un plan de pruebas es una de las primeras cosas que nuestro equipo de QA especializado hace con un cliente nuevo.
Qué incluye realmente un plan de pruebas
La mayoría de los planes de pruebas siguen la misma estructura, y por un buen motivo: cada parte responde a una pregunta que alguien acabará haciendo. El temario de nivel Foundation de ISTQB, utilizado para certificar a testers de software en todo el mundo, enumera casi las mismas secciones. La norma internacional de documentación de pruebas, ISO/IEC/IEEE 29119-3, establece una lista equivalente. Esto es lo que entra, en términos claros.
- Objetivos: es lo que las pruebas deben lograr, por ejemplo confirmar que el pago funciona antes de una campaña navideña o que nada se rompió tras un rediseño.
- Alcance: enumera qué funciones se comprueban y, igual de importante, cuáles no. Dejar por escrito lo que queda fuera del alcance evita la discusión más habitual en cualquier proyecto de pruebas.
- Enfoque de pruebas: cubre cómo se van a realizar las pruebas: a mano, con scripts automatizados o combinando ambos. La misma sección indica qué hay que comprobar, como funcionalidad, velocidad o seguridad.
- Recursos: señala quién hace el trabajo, en qué dispositivos y navegadores y con qué herramientas.
- Entorno de pruebas: indica dónde se prueba, normalmente una copia separada de tu producto preparada para que los testers nunca toquen cuentas o datos de clientes reales.
- Calendario: fija cuándo empieza y termina cada ronda de pruebas y cómo encajan esos plazos con tus fechas de lanzamiento.
- Criterios de entrada y salida: son las condiciones para empezar, por ejemplo que la nueva versión esté instalada y que el inicio de sesión funcione. Los criterios de salida marcan después cuándo está hecho el trabajo, como no dejar errores críticos abiertos.
- Riesgos: recoge qué podría descarrilar el trabajo, como una compilación que llega tarde o una cuenta de prueba que falta, y el plan alternativo del equipo para cada caso.
- Informes: explica con qué frecuencia sabrás del avance y de los errores, y en qué formato.
Los criterios de salida funcionan mejor como cifras que cualquiera puede comprobar, como las métricas de pruebas de software en las que los equipos suelen apoyarse para tomar esa decisión.
Piensa en esta lista como una plantilla de plan de pruebas: es lo que deberías esperar de cualquier posible socio de QA, adaptado a tu producto. Si necesitas un ejemplo más detallado, consulta nuestra lista de comprobación de pruebas de aplicaciones móviles.
Ejemplos reales: cómo planifica las pruebas QAwerk
QAwerk crea un plan de pruebas para cada cliente, y así es como funciona el proceso en la práctica:
- Revisión del producto: antes de planificar nada, leemos tus requisitos y exploramos lo que ya está construido para ver dónde se repiten los problemas.
- Alcance acordado: ambas partes aprueban qué se prueba, hasta los dispositivos y navegadores exactos. Por ejemplo, en el proyecto del marketplace Unpakt, la lista nombraba Windows 10 con Chrome y un iPhone X con Safari.
- Prioridades: las pruebas se ejecutan por fases y se comprueban primero las funciones que más importan a tu negocio.
- Escenarios inesperados: parte del esfuerzo, alrededor del 20% en el proyecto de Unpakt, se dedica a qué ocurre cuando los usuarios hacen algo que nadie había previsto.
- Informes: los errores van directamente a tu propio gestor de incidencias y las actualizaciones de avance llegan a diario.
- Cobertura completa: una lista de comprobación compartida registra cada prueba superada y fallida, así no se escapa nada.
Por supuesto, el proceso se ajusta a las necesidades de cada cliente. Estos son algunos casos que exigieron planes muy distintos:
- Un plazo ajustado: con alrededor de un mes por delante, cubrimos todas las funciones, ambos roles de usuario y 7 dispositivos para Escuela Coaching. La aplicación se lanzó en la fecha prevista.
- Sin ningún proceso de QA: para DrAnsay, primero auditamos las aplicaciones web y móvil y orientamos las pruebas hacia los problemas recurrentes que encontramos. Desde entonces, más de 60 errores se han quedado fuera de producción.
- Un producto todavía en desarrollo: ChitChat nos incorporó mientras aún se estaban planificando las funciones, así que diseñamos las comprobaciones función a función a medida que la aplicación tomaba forma. Las pruebas se ejecutaron en 24 teléfonos ajustados al mercado zambiano.
Cómo redactar un plan de pruebas con tu equipo de QA
Cuando contratas un equipo de QA, redactar el plan de pruebas es trabajo de los testers. Tu parte consiste en aportar lo que solo tú sabes:
- Documentos existentes: especificaciones, tickets, diseños e informes de errores anteriores muestran cómo debería comportarse el producto. Que haya lagunas no es problema, porque el plan convierte los detalles que faltan en preguntas abiertas.
- Prioridades: di al equipo qué funciones generan ingresos o cuáles harían más daño si se rompieran, para que las pruebas empiecen por ahí.
- Datos de uso: la analítica sobre los teléfonos y navegadores que usan realmente tus clientes decide la lista de dispositivos.
- Accesos: las cuentas de prueba y una copia separada del producto permiten al equipo trabajar sin acercarse a la versión en producción.
- Fechas de lanzamiento y aprobación: tu calendario marca cuándo se ejecuta cada ronda, y tu visto bueno convierte el plan en definitivo.
Más allá de estas aportaciones, mucho depende de lo que estés construyendo. En un sitio web, el foco recae en la compatibilidad entre navegadores, las pantallas de móvil y la velocidad de carga, como muestra nuestra lista de comprobación de pruebas de sitios web. En cambio, un juego añade comprobaciones de tráfico intenso, revisiones de cumplimiento en las tiendas y rondas beta, todo ello detallado en nuestra lista de comprobación de pruebas de juegos móviles.
Las herramientas de IA ya pueden redactar rápidamente un esquema de plan. Según el informe State of Testing 2026 de PractiTest, la mitad de los equipos pequeños de QA ya usa IA para la planificación de pruebas, mientras que solo el 19,9% de los testers confía en ella para identificar riesgos. Dicho de otro modo, una herramienta acelera la redacción, pero juzgar qué puede dañar de verdad tu negocio sigue exigiendo ingenieros de QA con experiencia.
Si tu producto todavía tiene poco por escrito, nuestros servicios de documentación técnica pueden redactar los casos de prueba y el resto de documentos de QA junto con el plan.
Plan de pruebas y casos de prueba: ¿cuál es la diferencia?
A menudo se confunden los planes de pruebas con los casos de prueba, pero ambos documentos trabajan en niveles muy distintos.
Función
El documento estratégico de todo un proyecto o versión
Instrucciones paso a paso para una comprobación concreta
Pregunta que responde
¿Qué probamos, cómo y para cuándo?
¿Esta acción exacta produce el resultado correcto?
Lectores principales
Clientes, responsables, desarrolladores y testers
Sobre todo testers
Ejemplo
Probar el pago en los teléfonos que más usan los clientes antes de la próxima versión
Introducir una contraseña incorrecta tres veces y confirmar que la cuenta se bloquea
Cuándo se redacta
Antes de que empiecen las pruebas
Después del plan, antes de cada ronda de pruebas
Cuando trabajas con un equipo de QA, los testers redactan y ejecutan los casos de prueba, y lo que llega hasta ti son resultados e informes de errores. Si te interesa la mecánica, explicamos cómo redactar casos de prueba en un artículo aparte.
También puede que oigas hablar de una estrategia de pruebas, que fija el enfoque general para toda una empresa o línea de producto. Un plan de pruebas lleva después esos principios al terreno de un proyecto concreto. Las organizaciones grandes suelen mantener la estrategia como documento separado, mientras que los equipos pequeños normalmente se apañan con un único plan. Para ver más de cerca cómo se reparten el trabajo ambos documentos, lee sobre estrategias de pruebas de software.
Dónde encaja un plan de pruebas y por qué compensa
En el ciclo de vida de las pruebas de software, la planificación de pruebas llega justo después del análisis de requisitos y antes de que nadie escriba casos de prueba. Ese orden importa porque unas especificaciones poco claras producen un plan vago. Nuestro artículo dedicado a los requisitos de pruebas de software explica qué documentos ayudan más. A partir de ahí, la planificación da forma a cada una de las demás etapas de las pruebas de software.
Un plan de pruebas demuestra su mayor valor cuando un proyecto cambia de rumbo, por ejemplo cuando se recorta una función, se mueve un plazo o se añade una plataforma nueva. En lugar de renegociar todo el alcance, ambas partes actualizan solo las partes afectadas y siguen adelante.
Cada colaboración de QAwerk empieza con un plan de pruebas, de modo que el equipo y el cliente acuerdan las prioridades desde el primer día. El documento también ayuda a nuestros testers a ponerse al día rápidamente con un producto nuevo. Por tu parte, el plan sirve además como registro claro de lo que se ha cubierto. Consigue un plan de pruebas hecho para tu producto.
Preguntas frecuentes
¿Qué es un plan de pruebas en las pruebas de software?
Un plan de pruebas en las pruebas de software es un acuerdo escrito entre el equipo de producto y los testers sobre qué se comprueba y cómo. El documento fija objetivos, alcance, dispositivos, un calendario y responsabilidades. Un plan de pruebas también define cuándo pueden empezar las pruebas y qué cuenta como terminado, para que el equipo y los testers compartan una misma definición de listo.
¿Qué debe incluir un plan de pruebas?
Un plan de pruebas completo cubre nueve áreas: objetivos, alcance, enfoque de pruebas, recursos, entorno de pruebas, calendario, criterios de entrada y salida, riesgos e informes. Los detalles importan tanto como los encabezados. Un buen plan enumera las funciones excluidas junto a las incluidas, nombra los dispositivos por modelo exacto y establece condiciones de finalización que cualquiera puede verificar, como cero errores críticos abiertos.
¿Quién redacta el plan de pruebas?
Normalmente lo redacta el responsable del equipo de pruebas. Con una empresa de QA externa, el líder de QA del proveedor prepara una primera versión al inicio y repasa el documento con el cliente antes de empezar el trabajo. El cliente confirma prioridades, comparte fechas de lanzamiento y aprueba el alcance, ya que nadie sabe mejor qué funciones importan más al negocio.
¿Qué extensión debe tener un plan de pruebas?
Un plan de pruebas no tiene una extensión estándar, porque el nivel de detalle adecuado depende de lo complejo que sea el producto. La actualización de una aplicación pequeña puede caber en dos páginas, mientras que una plataforma con varios roles de usuario y conexiones con terceros puede ocupar bastante más. Como regla práctica, cada sección debería resolver algo que la gente del proyecto necesite saber de verdad.
¿Los equipos ágiles siguen necesitando un plan de pruebas?
Los equipos ágiles siguen necesitando un plan de pruebas, solo que en una versión más ligera. En lugar de un documento largo redactado por adelantado, el plan se mantiene breve y se revisa cada sprint, es decir, en cada ciclo corto de desarrollo. Las revisiones cubren alcance, dispositivos, responsables y la definición de terminado. Sin esa referencia compartida, los lanzamientos frecuentes dejan pasar áreas sin probar, porque cada sprint se centra en el trabajo nuevo.
Mira cómo QAwerk verificó 8 portales educativos en Chrome, Edge y Firefox además de 12 dispositivos reales iOS y Android para una plataforma que atiende a 110 millones de visitantes al año
