Qué es QA (Quality Assurance) en software, explicado fácil

QA (Quality Assurance, aseguramiento de calidad) es el conjunto de prácticas que te dan una forma de saber, antes de publicar, si el software hace lo que prometiste. Esa es la respuesta corta. La respuesta larga es que QA no es el momento en que alguien "prueba a ver si funciona": es el sistema que hace que la calidad sea predecible en lugar de una sorpresa al final.

La imagen popular de QA es la de una persona que rompe cosas justo antes del lanzamiento. Encuentra fallos, los reporta, y todos corren a arreglarlos. Esa persona existe y hace falta, pero confundir eso con QA es como confundir al bombero con la seguridad contra incendios. Apagar el fuego es necesario cuando ya hay fuego. QA, bien entendido, es el trabajo que hace que el fuego sea raro.

01 · la confusiónQA no es "el que rompe cosas al final"

Hay que separar tres palabras que suelen usarse como sinónimos y no lo son: calidad, aseguramiento y prueba. La calidad es una propiedad del producto: qué tan bien hace lo que debe. El aseguramiento (la primera A de QA) es el proceso que trabaja para que esa propiedad se cumpla. Y la prueba (testing) es una de las actividades dentro de ese proceso, no el proceso entero.

El estándar internacional que define qué significa "calidad" en un producto de software se llama ISO/IEC 25010. No habla de "sin bugs". Habla de características medibles: idoneidad funcional, fiabilidad, eficiencia de desempeño, usabilidad, seguridad, compatibilidad, mantenibilidad y portabilidad [1]. Un producto puede no tener un solo error visible y aun así ser de mala calidad si es inseguro, imposible de mantener o incomprensible para quien lo usa.

Probar al final te dice qué se rompió. QA decide, desde el principio, qué no debería poder romperse.

Por eso QA empieza mucho antes de que exista código para probar. Empieza cuando alguien escribe qué debe hacer el software y bajo qué condiciones se considerará correcto. Sin ese acuerdo previo, "probar" es opinar. Con él, probar es verificar.

02 · el sistemaPrevenir es más barato que corregir

La razón económica por la que QA se adelanta al final tiene décadas de evidencia. Un error cuesta más entre más tarde se descubre. Un requisito mal escrito, si se atrapa cuando aún es una frase en un documento, cuesta corregir una frase. El mismo requisito mal escrito, descubierto cuando ya es código en producción que un cliente usa, cuesta rehacer código, datos, comunicación y confianza. La regla de bolsillo que popularizó Barry Boehm es que el costo de arreglar un defecto crece de forma pronunciada conforme avanza el proyecto [2].

De ahí sale la idea central del aseguramiento: mover el cuidado por la calidad hacia el inicio en lugar de dejarlo para el final. En la práctica, eso significa varias actividades que no parecen "probar" y sin embargo son QA pura:

Definir el criterio antes de construir. Antes de escribir código, se escribe qué contará como "hecho" y "correcto". Ese criterio es el oráculo: la referencia contra la cual luego se verifica. Sin oráculo, nadie puede afirmar que algo pasó o falló, solo que "se ve bien".

Revisar, no solo ejecutar. Leer un requisito ambiguo y pedir que se aclare es QA. Revisar un diseño y detectar que no contempla un caso es QA. Nada de eso ejecuta el programa, y aun así previene fallos que costarían mucho más tarde.

Verificar contra el criterio. Aquí entra el testing: ejecutar el software y comparar su comportamiento con lo que se acordó. Esta es la parte visible de QA, la que la gente reconoce, pero es la punta del iceberg apoyada en todo lo anterior.

03 · el enfoque QiravaCalidad es un sistema, no un heroísmo de última hora

Todo esto lleva a una conclusión incómoda para muchos equipos: si la calidad depende de que una persona valiente encuentre los fallos a tiempo la noche antes de lanzar, no tienes calidad, tienes suerte. Y la suerte no escala. Funciona hasta el día que esa persona está de vacaciones, o el producto crece más rápido de lo que un par de ojos puede revisar.

En Qirava tratamos la calidad como un sistema con reglas, no como un acto de heroísmo. Un sistema tiene tres cosas que el heroísmo no: es repetible, es explicable y no depende de quién esté de turno. Cuando un fallo se escapa, la pregunta no es "quién falló en probarlo", sino "qué parte del sistema permitió que llegara hasta aquí sin que nadie lo notara". Esa pregunta arregla el proceso; la otra solo busca un culpable.

Si la calidad depende de que una persona sea heroica la noche antes de lanzar, no tienes calidad: tienes suerte.

Ese sistema descansa en una base que ya cubrimos en otros artículos: escribir la especificación antes que el código, para que exista un criterio contra el cual verificar. Sin especificación no hay QA posible, solo opiniones sobre si algo "se ve bien". Con especificación, cada afirmación de calidad se vuelve comprobable.

04 · en una fraseQué llevarte

QA es la disciplina de saber, antes de publicar, si el software cumple lo que prometiste, y de organizar el trabajo para que ese cumplimiento sea la norma y no el golpe de suerte. Probar al final es una parte, la más visible, pero es la punta de algo más grande: definir el criterio, revisarlo, construir contra él y verificar sin drama.

La imagen del héroe que rompe cosas la última noche es entrañable y engañosa. La calidad de verdad es aburrida en el buen sentido: sistemática, temprana y repetible. Cuando funciona, casi no se nota, porque los incendios que apaga son los que nunca ocurrieron.