Una pregunta muy común entre los programadores que se inician en el camino de calidad en sus proyectos es: ¿cuántas pruebas necesito para garantizar la calidad?. La respuesta es la más molesta que puedes recibir de un programador: depende. No hay un número mágico de cobertura o número de pruebas que garantice que tu sistema está libre de bugs. A continuación te explico como abordo esta problemática.
¿Por dónde empiezo?.
La codificación de pruebas inicialmente busca asegurar el estado de los flujos críticos de tu aplicación. El primer paso antes de codificar, es conocer tu código. Debes de poder diferenciar que error es costeable y que error no. Por ejemplo:
Eres el encargado de mantener la página de ventas de la empresa. Los posibles clientes se registran en la web, crean y editan su perfil, después hacen sus compras. Tanto el registro exitoso de un nuevo cliente, como el finalizar la compra, son flujos críticos para la empresa. El fallo en alguno de estos dos se refleja en perdidas. ¿Qué pasaría si falla la edición de perfil del usuario?, digamos que no pueden cambiar la imagen de perfil o que se pierde el día registrado de la fecha de nacimiento del cliente. Si bien, son errores, hay que repararlos y asegurarnos que funcionen. Estos no son objetos de tanto interés. Podríamos omitir o postergar la codificación de pruebas, probar con menos frecuencia o simplemente revisarlo más adelante.
Ya conozco los flujos críticos, ¿y luego?.
Es necesario que sepas que cualquier tipo de pruebas que quieras codificar debe ser parte de una estrategia integral. Una matriz de pruebas solo de un tipo será ineficaz, lo que necesitas es diversidad. Si no conoces todos los tipos de pruebas que puede haber, puedes leer el Bestiario de pruebas automatizadas que estaré preparando próximamente. La idea de tener mucha variedad de pruebas en nuestro arsenal es atrapar cada tamaño de bug. Imagina que los errores en nuestra aplicación son peces, de diversas formas y tamaños. Para atraparlos tienes a tu disposición una serie de redes, cada uno pensado para atrapar algo en particular. La única estrategia viable para atraparlos a todos, es usar todas tus herramientas.
- Peces pequeños (Pruebas unitarias): Las pruebas unitarias, la unidad básica de pruebas, te sirve para atrapar los bugs más pequeños. La mayoría de estos errores ocurren en tiempo de codificación.
- Peces medianos (Pruebas de Integración): Los bloques de código en nuestro sistema se conocen y se comunican entre sí. Muchos errores ocurren en la mala interacción de estos componentes. Este tipo de bugs son más fuertes, es un poco más difícil atraparlos. Por eso necesitamos redes más grandes y firmes llamadas pruebas de integración. Estas son más difíciles de producir y de operar, requieren de más tiempo por parte del programador en turno.
- Peces grandes (Pruebas de estrés, pruebas de aceptación, pruebas de regresión, pruebas de concurrencia). Siempre existirá la posibilidad de que bugs más difíciles de reproducir o detectar se te cuelen, es inevitable. Al igual que con las pruebas de integración, si el pez crece, entonces también lo harán nuestras armas. Vas a requerir de un set especial de pruebas, que validen distintos aspectos de tu aplicación (estrés, concurrencia, regresión y aceptación). No es necesario ejecutarlas siempre, quizá no llegues a necesitarlas. Es bueno que sepas que existen.
- Ballenas(Pruebas manuales). Las pruebas automatizadas no quitan la necesidad de probar manualmente, es el último recurso a tu disposición. Probar manualmente es caro, toma tiempo y no es una acción repetible. No es algo que se quiera hacer siempre, la labor del Tester debe ser para localizar grandes errores que otros mecanismos no pudieron atrapar. Estamos hablando de bugs muy gordos y complicados.
Concéntrate en la calidad de tus pruebas, no en la cantidad.
El número de pruebas en tus proyectos no es importante, con que tengas un puñado de pruebas fiables en las que puedas confiar siempre, con eso es suficiente. Claro, el número ira variando. Las pruebas no son estáticas, dependiendo del flujo de tus sistemas el total subirá o bajará. Algunas pruebas se romperán, tendrán que ser reescritas o simplemente dejaran de tener importancia. Por lo general, a partir de los flujos críticos de tus pruebas ira surgiendo la necesidad de construir pruebas adicionales o complementarias. Imagina los tallos de un árbol. Un pequeño tallo surge de un tronco grueso y con el tiempo este va creciendo hasta llegar al grueso del original. Así sucederá con tus sistemas.
Conclusiones.
No tengas miedo en mejorar la calidad de tus programas. Cualquier intento por producir mejor código, es mejor que ningún intento. Esto es un ensayo error, algunas cosas te van a funcionar, otras no. Todo es cuestión de seguir intentándolo. Cuéntame, ¿cuál ha sido tu experiencia con el testing?.
Autor Imagen: Tony Alter
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
