QA y Pruebas de Software

Hoy quiero tocar un tema que a muchos desarrolladores les da dolor de cabeza, aunque es literalmente lo único que se interpone entre un lanzamiento exitoso y un fin de semana arruinado por llamadas de emergencia: El Aseguramiento de la Calidad (QA) y los Procesos de Pruebas.

Seamos sinceros. A todos nos ha pasado: escribimos una función, la probamos por encima, todo parece funcionar en nuestra máquina local y... ¡BAM! Lo subimos a producción y el sistema colapsa. Para evitar que nuestro código se convierta en una bomba de relojería, necesitamos procesos de pruebas sólidos.

Hoy quiero compartir con vosotros mi visión sobre cómo planificar, estructurar y ejecutar pruebas de software como verdaderos profesionales. ¡Vamos a ello!

1. Planificación y Estrategia de Pruebas

Uno de los mayores errores que he visto es dejar las pruebas para el final del ciclo de desarrollo. El famoso "ya lo probaré cuando termine". Gran error. ❌

Una buena estrategia de pruebas debe nacer al mismo tiempo que los requisitos del proyecto. A esto en la industria le llamamos Shift-Left Testing (mover las pruebas a la izquierda en la línea de tiempo del proyecto).

Para planificar correctamente, siempre se debería intentar definir:

• ¿Qué vamos a probar? (Alcance: frontend, backend, integraciones de terceros).
• ¿Qué NO vamos a probar? (Es vital definir los límites para no agotar recursos).
• ¿Qué entornos usaremos? (Desarrollo, Staging, Producción).
• ¿Cómo gestionaremos los bugs? (¿Usaremos Jira, Trello, GitHub Issues?).

💡 Nota sobre Estándares: Si trabajáis en proyectos muy grandes, os cruzaréis con el estándar ISO/IEC/IEEE 29119. Es un marco de trabajo internacional que define vocabulario, procesos, documentación y técnicas de pruebas. Aunque para proyectos pequeños puede parecer matar moscas a cañonazos, conocer sus fundamentos te da una base increíblemente profesional.

2. Los Niveles de Pruebas

No todas las pruebas son iguales ni cuestan el mismo tiempo. Para estructurarlas, me encanta usar el concepto de la Pirámide de Pruebas.

Aquí os desgloso los niveles, de la base a la cúspide:

1. Pruebas Unitarias (Unit Tests): Son la base de nuestra pirámide. Aquí probamos el componente más pequeño de nuestro software de forma aislada (una función, un método, una clase). Deben ser súper rápidas y estar automatizadas. Si una prueba unitaria falla, el código ni siquiera debería compilarse en nuestro pipeline.
2. Pruebas de Integración: Una vez que las piezas individuales funcionan, ¿qué pasa cuando las juntamos? Aquí verificamos que nuestra base de datos se comunica bien con nuestro backend, o que nuestros microservicios "hablan" el mismo idioma.
3. Pruebas de Sistema: Aquí evaluamos el sistema completo y ensamblado. ¿Cumple la aplicación con los requisitos técnicos y de negocio en su totalidad?
4. Pruebas de Aceptación (UAT): La cima de la pirámide. Normalmente las hacen los usuarios finales o el cliente. Es la prueba de fuego: ¿El software resuelve el problema para el que fue creado?

3. Técnicas de Pruebas

Para diseñar nuestras pruebas, podemos abordar el código desde diferentes perspectivas. Principalmente se dividen en dos enfoques:

• Pruebas de Caja Blanca (White Box): En este caso, vemos el código fuente. Analizamos la estructura interna, los bucles y las condicionales. El objetivo es asegurar que cada línea de código se ejecuta correctamente (lo que llamamos cobertura de código).
• Pruebas de Caja Negra (Black Box): Aquí nos ponemos en la piel del usuario. No nos importa cómo está escrito el código por dentro. Solo nos importa que si metemos un "Input A", el sistema nos devuelva el "Output B" esperado.

Además de esto, no nos podemos olvidar de diferenciar entre pruebas estáticas (revisar el código sin ejecutarlo, como los linters o las revisiones por pares) y las pruebas dinámicas (ejecutar el programa para ver cómo se comporta).

4. Herramientas

El ecosistema de herramientas de QA es gigantesco, pero aquí os dejo una tabla con las más utilizadas y por qué se utilizan:

5. Criterios de Aceptación: ¿Cuándo terminamos realmente?

Por último, pero no menos importante: ¿cómo sabemos que una funcionalidad está lista para ser entregada? Aquí entran en juego los Criterios de Aceptación.

Un error común es decir: "Ya he programado el botón de pago, he terminado". Pero en Tecnoic aplicamos lo que en metodologías ágiles se conoce como Definition of Done (DoD).

Para mí, una tarea no está terminada a menos que cumpla ciertos criterios. Un buen truco es usar el formato BDD (Behavior-Driven Development):

• Dado (Given): Un usuario que tiene artículos en su carrito.
• Cuando (When): Hace clic en "Pagar".
• Entonces (Then): Se procesa el pago y se le redirige a la pantalla de éxito.

Si el código no cumple con cada uno de esos puntos a la perfección y no pasa las pruebas automatizadas... el código no está listo. 🛡️

🗣️ ¡Tu turno!

Implementar un buen proceso de QA no es algo que se logre de la noche a la mañana. Requiere cambiar la cultura del equipo, invertir tiempo en crear buenas bases y, sobre todo, dejar de ver las pruebas como un "gasto de tiempo" para verlas como lo que realmente son: una inversión en tranquilidad. 🧘‍♂️

Me encantaría saber cómo lo gestionáis vosotros.

👇 ¡Dejadme un comentario abajo! ¿Sois de los que tienen un 100% de cobertura de código o de los que rezan un "Padrenuestro" cada vez que suben a producción? ¿Cuál ha sido el bug más catastrófico que se os ha colado por no probar a tiempo?

¡Os leo en los comentarios!