Lecciones sobre la fiabilidad de casos de prueba – Aprende cómo mejorar

¡Bienvenidos a «Lecciones Aprendidas», una serie donde compartimos nuestros mayores errores para que no cometan los mismos! Las lecciones de hoy vienen de mis días como desarrollador de sistemas operativos. Un equipo de pruebas había reportado un problema en el cual una de las vistas que mostraba una vista consolidada de diferentes recursos era inconsistente. Por ejemplo, la unidad de red decía que había tres elementos, el controlador del sistema de archivos decía que había seis y el CD decía que había uno. Pero la vista consolidada decía que solo había ocho. Nadie podía reproducir esto a voluntad; era semi-aleatorio.

La búsqueda de la solución

Decidí intentar encontrar el problema a través de la inspección del código. Revisé el código relacionado con esto, buscando fallas lógicas. Presenté una solución, pero inevitablemente, un día o dos después, era rechazada. Este patrón se repitió literalmente durante tres semanas: aplicar una solución, que fuera rechazada, aplicar una solución, que fuera rechazada.

Finalmente, un tester se puso en contacto conmigo y me dijo: «Dan, tengo en el laboratorio ahora mismo un sistema que se encuentra en el estado que hemos estado tratando de aislar. Deberías venir a echar un vistazo». Así que fui allí y utilicé un depurador a nivel de kernel para examinar el estado de la máquina, ya que descubrí que los depuradores regulares alteraban los resultados. Finalmente, después de horas de depuración, descubrí que el problema era tan simple como esto: mientras (x < n). Debió haber sido menor o igual.

Las lecciones aprendidas

Entonces, ¿qué lecciones aprendí de esto? La primera lección que aprendí es que las inspecciones de código tienen sus límites. Es un enfoque realmente útil al principio cuando estás tratando de examinar el problema inicial y tal vez no estás familiarizado con el código. Pero esa utilidad se agota rápidamente. La segunda lección es la importancia de los límites. Puede parecer un problema básico para programadores, pero se deben hacer pruebas de límites más rigurosas, especialmente alrededor del comienzo y fin de un límite. Prueba aquí, aquí, aquí y aquí. Por supuesto, también es necesario probar en otros lugares, pero esas condiciones límite son las que inevitablemente causan problemas.

Otra lección que aprendí es que la expectativa de tener un problema a voluntad simplemente no es realista. Esto comienza porque las personas quieren utilizar herramientas de depuración que sean más eficaces para resolver problemas. Pero en un entorno de producción, las herramientas de depuración que utilizas durante tus pruebas unitarias iniciales no se transfieren bien. Por otro lado, los registros, ya sea que los utilices durante el desarrollo o en producción, te brindan información clave que puede ayudarte a resolver un problema.

Otra cosa que aprendí es que cuando estás haciendo la depuración que implica procesos asíncronos, realmente necesitas enfocarte en tus pruebas de carga. Debido a que es asíncrono, eso significa que la carga afectará lo que ves como resultado, lo que hace más probable que tengas problemas. Por lo tanto, debes realizar pruebas de carga no solo con personas que utilizan el sistema, sino también creando casos de prueba que impulsen el sistema a diferentes niveles de carga en diferentes momentos.

Y finalmente, y probablemente una de las lecciones más importantes que aprendí, es que el equipo de pruebas y el equipo de desarrollo necesitan trabajar en estrecha colaboración. De hecho, lo que recomiendo es que estén en el mismo equipo o, como mínimo, que realicen un recorrido en el rol del otro. De esa manera, pueden aprender de una de estas lecciones y no tener que sufrir como yo lo hice.

Resumen de la información

Preguntas frecuentes

1. ¿Por qué las inspecciones de código tienen límites?

Las inspecciones de código son útiles al principio para examinar el problema inicial y familiarizarse con el código, pero su utilidad disminuye rápidamente a medida que el problema se vuelve más complejo.

2. ¿Por qué los límites son importantes en la programación?

Los límites son importantes porque las condiciones límite suelen ser las que causan problemas, por lo que se deben realizar pruebas rigurosas alrededor del inicio y fin de un límite para evitar errores.

3. ¿Cuál es la importancia de las pruebas de carga en la depuración de procesos asíncronos?

Las pruebas de carga son importantes en la depuración de procesos asíncronos porque la carga puede afectar los resultados y hacer que se produzcan problemas. Por lo tanto, es necesario probar el sistema con diferentes niveles de carga en diferentes momentos para asegurarse de que funcione correctamente en todas las situaciones.

4. ¿Por qué es importante que los equipos de pruebas y desarrollo trabajen en estrecha colaboración?

Es importante que los equipos de pruebas y desarrollo trabajen juntos porque el conocimiento mutuo y la comprensión de los roles de cada uno ayudan a identificar y resolver problemas de manera más eficiente.

Espero que estas lecciones aprendidas te ayuden a evitar cometer los mismos errores. Recuerda siempre mantener límites rigurosos, utilizar registros como herramientas de depuración en entornos de producción, realizar pruebas de carga adecuadas y fomentar el trabajo en equipo entre los equipos de pruebas y desarrollo. ¡No dudes en consultar nuestros artículos relacionados para seguir aprendiendo! ¡Hasta la próxima!

Mila y César

Hola, somos Mila Jiménez y César Sánchez. Dos apasionados de la ciberseguridad con muchos años de experiencia. Hemos trabajado en muchas empresas del mundo TI y ahora nos apetece compartir nuestro conocimiento con cualquiera que lo necesite.

¡Si te gusta nuestro contenido puedes invitarnos a un café AQUÍ!