Blog

Hay una conversación que se repite en muchas empresas, del estilo:

«Ahora que tenemos un tester, el producto tiene más calidad.»

Y ahí está el error. No en la intención, sino en el concepto.

Confundir testing con calidad no es un problema menor. Es un error de base que condiciona cómo se estructuran los equipos, cómo se distribuyen las responsabilidades y, sobre todo, cómo se gestiona el riesgo en el desarrollo de software.

En este artículo les voy a contar los dos errores más frecuentes que cometen los equipos cuando piensan en testing, y voy a intentar explicar por qué testing, QA y QC no son lo mismo.

Error 1: «Tenemos tester, luego tenemos calidad»

Esta es probablemente la confusión más extendida. Un equipo incorpora un perfil de QA o un tester, y automáticamente asume que el producto ahora es mejor. Que tiene más calidad.

Pero eso no es lo que ocurre.

Lo que ocurre es que ahora el equipo tiene más información. Tiene visibilidad del estado real del producto. Y eso, aunque es enormemente valioso, no es lo mismo que calidad.

Pensalo de esta manera: contratar a alguien para que mida la temperatura de una habitación no hace que la habitación esté más caliente. Lo que hace es que sepás exactamente a cuántos grados está.

El tester no produce calidad. El tester revela el estado actual del producto. Encuentra bugs, identifica comportamientos inesperados, señala inconsistencias. Esa información es crítica para tomar decisiones. Pero la calidad (en términos de defectos, robustez, experiencia de usuario, etc.) depende de lo que el equipo haga con esa información, y de cómo construye el producto desde el principio.

Incorporar testing sin cambiar los procesos de desarrollo es como instalar un detector de humo y creer que ya no puede haber incendios.

Error 2: «Con testing alcanza»

El segundo error es asumir que el testing cubre todo el ciclo. Que si probamos al final del proceso, la calidad está garantizada.

Este pensamiento ignora algo fundamental: la calidad no se testea, se construye.

El testing es una herramienta de detección. Es necesaria, pero es solo una parte de un sistema más amplio. Si los problemas se introducen en la fase de diseño, en los requisitos mal definidos, en las decisiones de arquitectura apresuradas, o en la falta de estándares de código, el testing los va a encontrar —pero ya será tarde, caro y frustrante.

La calidad del software se construye a lo largo de todo el proceso de desarrollo, no al final. Y ahí es donde entran en juego tres conceptos que muchos equipos usan como sinónimos cuando en realidad son muy distintos.

La diferencia entre Testing, QA y QC

Aclarar estos tres términos no es solo ejercicio académico (que lo vemos en el curso de Introducción al testing y en el de Preparación para la certificación Foundationl Level). Es una decisión práctica que cambia cómo se organiza un equipo y dónde se pone el foco.

Testing

Reduciendo mucho el concepto, podríamos decir que el testing consiste en ejecutar el software con el objetivo de encontrar defectos, fallos y errores y proponer mejoras. El testing da información. No garantiza calidad por sí solo.

QC — Quality Control (Control de Calidad)

El QC es más amplio que el testing. Incluye cualquier actividad orientada a verificar que el producto cumple con los estándares definidos. Puede incluir revisiones de código, auditorías, inspecciones, e incluso, testing. El foco sigue siendo el producto: ¿lo que entregamos cumple con lo que se especificó?

QA — Quality Assurance (Aseguramiento de la Calidad)

El QA es una disciplina preventiva. No se enfoca en encontrar defectos en el producto, sino en mejorar los procesos que lo producen. El QA pregunta: ¿por qué aparecen estos bugs? ¿Qué falla en nuestro proceso de definición de requisitos? ¿Cómo podemos evitar que este tipo de error vuelva a ocurrir?

El QA actúa antes, durante y después del desarrollo. Y su objetivo no es el producto en sí, sino el sistema que lo produce.