Cuando contratas un equipo de QA, el proceso de QA es el verdadero producto por el que pagas. Los testers siguen seis pasos para asegurarse de que tu software funcione para los clientes desde el primer día: análisis de requisitos, planificación de pruebas, diseño de pruebas, ejecución de pruebas, reporte de defectos y aprobación del lanzamiento. Repetido con cada nueva versión, el ciclo detecta los bugs mientras corregirlos todavía es rápido y barato.
Para tu negocio, un buen proceso significa menos sorpresas. El equipo de pruebas encuentra los bugs antes de que lleguen a tu producto en producción y arruinen la experiencia de tus clientes. Mientras tanto, los desarrolladores pueden centrarse en nuevas funcionalidades, porque QA mantiene cada lanzamiento en marcha. Un equipo de QA dedicado de QAwerk se pone al día con tu proyecto rápidamente y trabaja con las herramientas que ya utilizas, así que los reportes de bugs empiezan a llegarte desde la primera ronda de pruebas.
Qué ocurre en cada paso del proceso de QA
La mayoría de los equipos de QA siguen la misma secuencia básica, conocida como fases de las pruebas de software o ciclo de vida de las pruebas de software, según a quién preguntes. Como comprador, la pregunta útil es qué te aporta cada uno de los pasos del proceso de QA de software:
Análisis de requisitos
Lee las especificaciones y los diseños, pregunta cómo debe comportarse cada funcionalidad
Detalles poco claros resueltos antes de programar, para no tener que rehacer nada
Planificación de pruebas
Acuerda el alcance, los dispositivos, las prioridades y las fechas
Un acuerdo por escrito sobre qué se prueba, dónde y cuándo
Diseño de pruebas
Redacta comprobaciones paso a paso para cada funcionalidad
Comprobaciones listas que puedes volver a ejecutar en cada lanzamiento futuro
Ejecución de pruebas
Ejecuta las comprobaciones a mano y después con automatización
Bugs detectados poco después de que llegue el código nuevo, cuando corregirlos es fácil
Reporte de defectos
Registra cada bug con los pasos para reproducirlo
Reportes de bugs claros que los desarrolladores pueden corregir rápido
Aprobación del lanzamiento
Resume los resultados y el riesgo pendiente
Un resumen de resultados que muestra si la versión es segura para lanzarse
Cada paso evita una corrección costosa más adelante o te da datos para una decisión que, de otro modo, tomarías por intuición. A continuación te explicamos cómo todo ese trabajo técnico se convierte en un valor que tu negocio puede notar de verdad.
Antes de las pruebas: aclarar los detalles y acordar qué se prueba
Nuestros testers pueden incorporarse al proceso de QA incluso antes de que nadie escriba código, empezando por tus requisitos. Esos documentos y diseños describen cómo debe comportarse cada funcionalidad, y el equipo señala todo lo que no está claro o falta. Resolver esas lagunas en esta fase evita que tus desarrolladores tengan que rehacer trabajo más adelante. En la mayoría de los casos, todo lo que necesitan los testers ya existe en tu empresa en forma de especificaciones, diseños o historias de usuario.
Después llega el plan de pruebas, un único documento que fija qué se comprueba, en qué dispositivos y navegadores, quién lo hace y para cuándo. Como ambos equipos acuerdan el plan desde el principio, nadie descubre después del lanzamiento que se ha pasado por alto un navegador importante.
Durante las pruebas: comprobaciones reutilizables y bugs detectados a tiempo
En el paso de diseño, los ingenieros de QA convierten cada requisito en casos de prueba, instrucciones breves que indican qué hacer y qué resultado esperar. Las comprobaciones bien redactadas siguen siendo útiles mucho después del primer lanzamiento, porque cualquiera del equipo puede volver a ejecutarlas en la siguiente versión.
En cuanto una nueva versión de tu producto está lista, el equipo de QA recorre esos casos de prueba en dispositivos y navegadores reales. Así, tus desarrolladores reciben los reportes de bugs mientras todavía tienen el código nuevo fresco en la memoria. Las funcionalidades nuevas siempre se prueban primero a mano. Más adelante, las comprobaciones que se repiten en cada nueva versión, por ejemplo una búsqueda de productos o la actualización de un perfil, pueden automatizarse.
Después de las pruebas: reportes de bugs claros y un resumen para lanzar con seguridad
Cada bug que encuentra el equipo de QA se registra en un sistema de seguimiento compartido, donde los desarrolladores pueden recogerlo, corregirlo y devolverlo para una nueva comprobación. Un buen reporte de bug incluye los pasos para reproducir el problema, qué ha fallado y cómo debería ser el resultado correcto. Con todos los detalles a mano, un desarrollador puede corregir el problema sin una ronda de preguntas adicionales. Puedes ver ejemplos reales de reportes de bugs en nuestro Bug Crawl semanal, donde probamos una aplicación popular y publicamos los problemas que encontramos.
Antes de cada lanzamiento, el equipo de QA cierra el ciclo actual del proceso de QA con un breve resumen de lo que ha pasado, lo que ha fallado y los riesgos que quedan. Las métricas de pruebas, como el número de bugs críticos todavía abiertos, convierten ese resumen en cifras que puedes comparar con versiones anteriores. Así tienes una base sólida para decidir si lanzar según lo previsto o retrasar el lanzamiento hasta que estén listas las correcciones pendientes.
Por qué las pruebas manuales van antes que la automatización
La automatización de pruebas consiste en escribir scripts que vuelven a ejecutar las comprobaciones por ti, para que nadie tenga que recorrer la aplicación a mano cada vez. Empezar por ahí parece eficiente, pero lanzarse demasiado pronto hace perder dinero. Mientras una funcionalidad sigue cambiando, cada ajuste de diseño rompe los scripts y añade horas de reparación.
Por eso, nuestro proceso de QA empieza con comprobaciones manuales, y los testers exploran cada nueva funcionalidad a mano hasta que su comportamiento se estabiliza. Solo entonces el equipo decide qué merece la pena automatizar. Así se tomó esa decisión con tres clientes:
- Elegir según el beneficio: Para Penpot, una herramienta de diseño de código abierto, automatizamos las comprobaciones más importantes y más rápidas de preparar. El registro y la recuperación de contraseña siguieron siendo manuales, porque ambos flujos dependen de servicios de correo externos y no compensaba el esfuerzo de automatizarlos.
- Ganarse primero la confianza: Empezamos con pruebas manuales para Arctype, una herramienta de bases de datos. Tras comprobar lo minucioso que era ese trabajo, el cliente nos confió también la automatización, empezando por el registro y el inicio de sesión.
- Reservar el esfuerzo manual para los escenarios complicados: Para Granola, un bloc de notas con IA, automatizamos funcionalidades básicas y estables como el onboarding y la gestión de notas. Los escenarios que dependen del hardware y los pagos se quedaron con los testers manuales, lo que mantuvo los scripts rápidos y fiables.
Eso sí, la automatización solo compensa en las comprobaciones que repites a menudo. Si tu producto lanza versiones unas pocas veces al año, un proceso manual bien organizado puede servirte mejor. En cambio, si lanzas cada semana, la automatización de pruebas se convierte en la forma práctica de volver a comprobarlo todo a tiempo.
Cómo es el flujo de trabajo del proceso de QA en un proyecto real
Pusimos en marcha el flujo de trabajo del proceso de QA para Kazidomi, una tienda online sostenible que hace envíos a 17 países europeos. Al principio, los reportes de bugs llegaban del equipo de atención al cliente de la tienda y a menudo les faltaban los detalles que necesitaban los desarrolladores. El trabajo se desarrolló después en cinco pasos:
- Arreglar primero los reportes de bugs. Completamos cada reporte con las condiciones y las acciones exactas que provocan el bug, para que los desarrolladores pudieran ver qué había fallado.
- Crear la biblioteca de pruebas. Cada funcionalidad lista para probar recibió sus propios casos de prueba, 587 en total, actualizados a medida que cambiaba el producto.
- Automatizar el trabajo repetitivo. Los scripts asumieron 284 de esos casos de prueba, incluidas las comprobaciones de regresión, que confirman que las funcionalidades antiguas siguen funcionando cuando llega código nuevo.
- Comprobar cada cambio. Tras cada actualización del código se lanzaban ejecuciones automatizadas, con un conjunto rápido de unas 30 pruebas que cubrían las acciones de compra principales de la tienda.
- Proteger el flujo de ingresos. Los pagos con PayPal y Adyen recibieron una atención especial, porque un checkout roto hace perder ventas directamente.
Para Kazidomi, el resultado fue un ciclo de desarrollo más rápido y bugs detectados antes de llegar a los compradores. El flujo de trabajo cubrió las dos caras de las pruebas de calidad del software. Unos reportes de bugs más claros y una biblioteca de pruebas completa ayudaron a prevenir problemas, que es la tarea del aseguramiento de la calidad. Las ejecuciones automatizadas periódicas detectaron los bugs que aun así se colaban, que es la tarea del control de calidad.
Por qué el proceso de QA funciona como un ciclo continuo
Las guías suelen describir los seis pasos del proceso de QA en un orden fijo. En los proyectos reales, toda la secuencia se repite con cada lanzamiento y las fases a menudo se solapan. El ISTQB, el organismo internacional que certifica a los testers de software, lo dice claramente: las actividades de prueba a menudo se implementan de forma iterativa o en paralelo.
Este ritmo encaja con el desarrollo Agile, en el que el software se entrega en ciclos cortos. Un proceso de QA continuo suele incluir estas prácticas:
- Probar pronto: Los testers revisan los requisitos de la siguiente funcionalidad mientras los desarrolladores construyen la actual, un enfoque conocido como pruebas shift left.
- Volver a comprobar cada lanzamiento: Las pruebas de regresión vuelven a ejecutar comprobaciones sobre funcionalidades que ya funcionaban, para que sepas que una nueva actualización no ha roto nada de lo que usan tus clientes. Por ejemplo, repetimos esta rutina cada semana para Unfold, una aplicación para contar historias. Los resultados de cada ronda deciden qué funcionalidades salen a producción.
- Aprovechar la diferencia horaria: Para Arctype, nuestros ingenieros probaban mientras el equipo de California dormía. Cada mañana, los desarrolladores encontraban los nuevos bugs ya registrados en Jira.
Un hueco en las pruebas puede afectar incluso a las mayores empresas tecnológicas. En junio de 2025, una caída de Google Cloud duró unas tres horas después de que llegara a producción un cambio de código con una ruta de error que nunca se ejecutó durante el despliegue. En su informe del incidente, Google se comprometió a mejorar sus prácticas de pruebas para que los errores se gestionen correctamente.
Qué papel tiene la IA en el proceso de QA
La IA ya acelera varios pasos del proceso de QA. Por ejemplo, los testers usan herramientas de IA para redactar casos de prueba a partir de los requisitos, clasificar los bugs recién encontrados y elegir qué volver a comprobar tras un cambio. Aun así, la adopción es desigual: el World Quality Report concluyó que solo el 15% de las organizaciones ha escalado la IA generativa en QA a toda la empresa, mientras que el 43% sigue experimentando.
Una de las razones de esa diferencia aparece en el informe DORA 2025 de Google, que estudia el rendimiento de los equipos de software. Los autores describen la IA como un amplificador de las fortalezas y debilidades que ya tiene una organización. Para QA, eso significa que la IA acelera un proceso bien organizado, pero también multiplica las carencias de uno desordenado.
En QAwerk, nuestros ingenieros de QA usan la IA como asistente. Con la generación de casos de prueba con IA a partir de requisitos, por ejemplo, un modelo convierte la descripción de cada funcionalidad en un borrador de lista de casos de prueba. Después, un especialista en QA revisa la lista y añade los escenarios poco habituales que solo se le ocurrirían a alguien que conoce tu negocio.
Cómo QAwerk lleva el proceso de QA con tu equipo
Las pruebas funcionan mejor como una rutina estable con la que tus desarrolladores puedan contar: primero comprobaciones manuales, automatización donde compensa y un resumen claro antes de cada lanzamiento. Para crear esa rutina, nuestros ingenieros de QA se unen a las reuniones y los chats de tu equipo y planifican las pruebas en función de tus fechas de lanzamiento. Tanto si lanzas cada mes como cada semana, el proceso se adapta a tu ritmo. Nuestro equipo también puede incorporarse en cualquier fase, desde los primeros requisitos hasta un producto que ya está en producción.
Pon en marcha tu proceso de QA antes de tu próximo lanzamiento.
Preguntas frecuentes
¿Cuáles son los pasos del proceso de QA de software?
Un proceso de QA de software suele tener seis pasos agrupados en tres fases. La preparación abarca el análisis de requisitos y la planificación de pruebas. Las pruebas abarcan el diseño y la ejecución de pruebas, en los que los ingenieros de QA escriben y ejecutan comprobaciones sobre el producto. El reporte abarca el seguimiento de defectos y una revisión final del lanzamiento que indica al equipo si la versión está lista para salir. Todo el ciclo se repite con cada actualización.
¿Cuánto se tarda en implantar un proceso de QA?
El plazo depende sobre todo del tamaño de tu producto. En un proyecto pequeño, un equipo de QA puede empezar a reportar bugs en los primeros días. Los productos más grandes necesitan más preparación, como la planificación, la redacción de casos de prueba y el acceso a dispositivos y cuentas de prueba, antes de que las pruebas lo cubran todo. Después, la cobertura y la automatización siguen ampliándose con cada nueva versión.
¿Cuándo debe empezar QA en un proyecto de software?
Lo ideal es que QA empiece en la fase de requisitos, antes de que exista código. En ese momento, un detalle que falta o una contradicción en las especificaciones se corrige con una edición rápida, mientras que el mismo problema detectado después del lanzamiento puede obligar a rehacer una funcionalidad. Aun así, empezar más tarde también compensa, porque un equipo de QA puede incorporarse a mitad del desarrollo o cuando el producto ya está en producción y construir el proceso a partir de lo que ya existe.
¿Qué va primero, las pruebas manuales o las automatizadas?
Las pruebas manuales van primero en todo lo que es nuevo o sigue cambiando. Hasta que una funcionalidad se comporta igual de una versión a la siguiente, los scripts se romperían con cada actualización y su reparación costaría más que las horas ahorradas. Cuando el comportamiento se estabiliza, tiene sentido automatizar las comprobaciones repetitivas. La mayoría de los productos maduros acaban combinando ambos enfoques: los scripts cubren el trabajo rutinario y las personas se ocupan del resto.
Mira cómo construimos y mantuvimos más de 1.100 casos de prueba para Granola, un bloc de notas de IA, y automatizamos el 76% de su suite de regresión
