Cómo y Porqué probamos nuestro Software para Empresas

Todos en algún momento hemos comprado nuevo software: Software ECM, bases de datos, correo electrónico, gestores documentales, la lista es casi infinita. ¿Alguna vez te has preguntado cómo se asegura la calidad en estas herramientas? La respuesta es simple: Probándolas antes de que tú las uses.

Estamos asombrados de la cantidad de energía, trabajo duro e imaginación que se aplica al software que usamos, razón por la cual es frustrante encontrar una parte del software que no funciona como debería. Estos errores tienen muchos nombres, pero los fabricantes de software solemos llamamos “bugs” (bichos en inglés).

Los bugs son el resultado de muchas cosas, pero normalmente son el resultado de pequeños cambios en las nuevas versiones o actualizaciones. Digamos que agregas una nueva placa a tu armadura, pero al hacerlo, separas otra placa en otro lugar de la misma, ¡no está bien! La mayoría de las veces nosotros los creadores del Software ni siquiera nos damos cuenta de que estos errores aparecen y es por eso que probamos.

Las pruebas son un proceso llevado a cabo por muchas personas en las factorías de software, desde pequeñas hasta poderosas, y sucede de muchas maneras. Algunas factorías de software usan una lista  anticuada de pruebas (ese Excel…) que han utilizado durante años sin actualizarlo y recoge sólo las funcionalidades básicas (su “pan y mantequilla” de todos los días), y algunos incluso van al estilo libre probando aleatoriamente diferentes áreas (lo que se llama “pruebas de humo”).  Ambos ejemplos darán un resultado a veces positivo y a veces negativo.

Sin embargo, poniéndose en el lugar de nuestros clientes ¿Cómo sienta encontrar un bug en un software que se ha probado con una batería de pruebas obsoleta o sabiendo que solo se ha probado el 50% de toda la funcionalidad del software? Creo que sabemos la respuesta.

Aquí en R2 Docuo adoptamos un enfoque mucho más profesional porque no queremos que nuestros clientes se paren porque “se nos pasó” algo. No sólo probamos las características nuevas  sino que también probamos el funcionamiento básico cada vez (pruebas regresivas), las acciones básicas y repetitivas que nosotros y nuestros clientes utilizamos a diario en R2 Docuo para ayudarnos en el día a día. Esto es algo especialmente importante cuando se utilizan las llamadas metodologías ágiles de desarrollo (como SCRUM).

Esto lleva tiempo porque somos perfeccionistas y queremos hacerlo todo lo bien que sea posible. Por ejemplo, cuando empezamos a probar la última versión de R2 Docuo hace algunas semanas, se necesitó un equipo de dos personas trabajando durante siete días hábiles completos para completar las pruebas.

Siempre hemos utilizado software para gestionar nuestro proceso de pruebas pero hace poco dimos un salto cualitativo nos asociamos con TestRail de Gurock, una heramienta profesional que nos permite crear baterías de pruebas personalizadas y detalladas específicas para nuestro software, desde los principios básicos de la instalación hasta las funciones más complejas y más profundas que ofrece, siempre enfocando las pruebas en las nuevas funciones.

Hacemos que los desarrolladores, las personas que construyen y mantienen nuestro software y que lo conocen de arriba a abajo, creen lo que se llama “casos de prueba”, estos casos de prueba nos muestran qué y cómo probar y buscar, incluido el resultado esperado que buscan. Muchos probadores prueban esperando lo que ellos piensan que debería suceder y no lo que debe suceder por diseño.

Estos casos de prueba nos dan la versatilidad de cambiarlos y mejorarlos a medida que evolucionamos nuestro software manteniendo el objetivo principal en mente, que es garantizar que el resultado final sea lo más perfecto posible. Los casos de prueba permiten definir con una claridad del 100% lo que se espera y también nos da información mucho más valiosa sobre el proceso.

En todo momento tenemos un porcentaje desglosado de las pruebas pasadas, fallidas y listas para volver a probar. También registramos el tiempo que lleva completar una prueba, lo que significa que obtenemos una escala de tiempo general de la fase de pruebas para anticiparnos en el futuro. La herramienta se integra perfectamente con nuestro Software ECM R2 Docuo, que usamos para administrar el workflow de todos los defectos encontrados (bugs) con el fin de volver a probarlos cuando se solucionen.

Los casos de prueba documentados también permiten a todo el equipo brindar a nuestros clientes una mayor comprensión del software y sus habilidades de forma homogénea, sin interpretaciones.

Las pruebas son una parte vital de nuestro trabajo y encontrar un error no es el fin del mundo, nosotros simplemente lo aplastamos y sacamos una nuva versión! Pero preferimos encontrarlos nosotros a que los encuentre el usuario final (aunque alguno se nos pasará siempre…) . Así que, como usuario,  usa tu software y no tengas miedo del resultado. Alguien lo habrá probado antes por tí! o al menos debería…

¡Nos vemos en la nube!

James Storey

Suscríbete para recibir noticias de R2 Docuo en tu email: