¿Y para qué sirve el testing?

Si algo puede salir mal, saldrá mal.

¡Feliz día del tester! Fue un 9 de septiembre cuando Grace Murray Hopper, destacada matemática y licenciada en física, reportó el primer error informático mientras trabajaba en la sala del Mark en Harvard.

Esto sucedió en el año 1947 cuando Grace vio un incidente en una máquina provocado por una polilla que estaba atrapada en el ordenador Mark II, al ver este suceso, pegó la polilla que causó la falla y anotó la frase “First actual case of bug being found” (por eso le llamamos bugs a los errores).

Para poder entender mejor la importancia del testing, imagina que estás construyendo un edificio. Tienes los mejores materiales, mano de obra profesional, está completamente estimado para terminar a tiempo con tu construcción. Te entregan tu edificio, todo de acuerdo a lo prometido, se ve espectacular por dentro y fuera.

Sin embargo, al tiempo, cuando se empiezan a llenar los pisos con personas, tu edificio se derrumba.
¿Qué pasó aquí? ¿Qué no se supone que tenías la mejor mano de obra y materiales?

Podríamos hacer una analogía con el desarrollo de software. Puedes tener a los mejores programadores, un excelente análisis y estimación para tu producto, pero, ¿y el área de calidad de software? ¿Qué lugar le das en tu proyecto? ¿Y en tu empresa? Pareciera que el tester sólo está para destruir o criticar el trabajo de los desarrolladores, y a decir verdad suena molesto saber que esa persona está ahí para señalar tus errores.

Si en nuestra historia hubiese existido un tester, este hubiera dado respuesta a preguntas como:
— ¿Qué pasa si 500 personas suben al piso más alto? ¿El edificio lo soportaría?
— ¿Qué pasa si ocurre un desastre natural?
— ¿Qué tal si llueve mucho durante una temporada?
— ¿Y si en un piso se construye una sala de juegos y hay 200 niños brincando al mismo tiempo?
— ¿Cómo garantizamos la calidad de nuestro producto? ¿Quién o qué determina eso?
— ¿Lo que creamos al final hace realmente lo que planeamos al inicio?
— Si le añadimos un piso más ¿afectará a la versión anterior del edificio?

En nuestra analogía claramente el error fue el exceso de confianza. Al tener a “los mejores” se supuso que nada podría salir mal con la construcción. Que las cosas hayan salido mal no es culpa de los que participaron en la construcción directamente, sino de la persona que gestionó los recursos sin pensar en todos los posibles escenarios.

Así mismo uno de los peores errores es ver el área de calidad (QA) como algo aparte del desarrollo de nuestro proyecto, algo “sin importancia”. Y esa filosofía se transmite a todas las áreas involucradas.

Precisamente uno de los problemas que tuvimos cuando incorporamos el área de QA en la empresa que trabajo, Soluciones Roket, fue que los tester no eran bien recibidos por nadie. Se les veía como el enemigo de los desarrolladores, cuando en realidad estaban ahí para apoyar al equipo. Seguro que sabes que los tester realizan pruebas de funcionalidad, pero en realidad la tarea de este va más allá de “picarle a todo y encontrar errores” .

¿Has escuchado hablar de las pruebas de usabilidad, seguridad, de performance e incluso automatizadas ? No sólo eso, también existen estándares y reglas que rigen a el área de QA. Aquí te explicamos un poco más de estas:

Funcionalidad: la prueba más básica es revisar que tal opera nuestro producto, ¿hace lo que se supone debería?, ¿Realiza todas sus funciones sin errores?

Usabilidad: debemos contemplar al diseñar nuestro producto que todos los elementos funcionen correctamente y vayan de acuerdo a nuestros usuarios.

Seguridad: el famoso “pentesting” a páginas web, que consiste en realizar pruebas para descubrir fallos o vulnerabilidades que podrían comprometer nuestros productos y/o la información de nuestros clientes, es decir prevenimos ataques externos.

Performance: es necesario saber qué tanto soportará nuestra infraestructura, que tan escalable es nuestro sistema. Quizá en desarrollo todo vaya bien, pero con las pruebas de performance podrás saber como será cuando se encuentre en producción (o sea ya se esté usando realmente).

Automatizadas: quizá probar manualmente nuestro producto suene como lo más sencillo, pero cuando es un sistema muy grande, las tareas se vuelven repetitivas y el desarrollo es incremental, realizar una y otra vez las pruebas manuales se vuelve una tarea imposible. Por ello podemos automatizar las pruebas y con un clic realizar esas tareas repetitivas en menor tiempo.

La tecnología está avanzando a una velocidad exagerada y a pesar de que siempre ha sido importante la calidad de nuestros productos, en los últimos años el testing ha tomado más importancia dentro de todos los procesos que conllevan el desarrollo de alguna tecnología o software. Nadie quiere pagar por un producto donde la calidad no se encuentra asegurada.

Por ello ser tester no es tan fácil como suena, además de todos los tipos de pruebas que tienes que aprender a realizar, (las cuales en ocasiones requieren conocimientos avanzados de programación, seguridad o diseño) y las habilidades requeridas como creatividad, facilidad de comunicación oral y escrita o pensamiento crítico; cualquier observación, error, falla o defecto encontrado por nuestro usuario final o cliente será culpa del tester, al no haber sido capaz de detectarlo. De igual manera, como una buena práctica los desarrolladores deben probar sus sistemas y aplicaciones, todos los hacemos; pero la diferencia es cómo las probamos, asegúrate de asesorarte correctamente.

Recuerda que el trabajo de un tester no es hacerte la vida imposible, sino ayudarnos a realizar mejor nuestro trabajo, trabajan en conjunto con todos para mejorar y entregar el mejor producto posible a nuestro cliente. Ya lo decía la ley de Murphy, “si algo puede salir mal, saldrá mal”, es decir cuanto más tiempo y trabajo requiera una tarea, más fácil será que en algún momento surja algún contratiempo.

“Si hay dos o más maneras de hacer algo y una de ellas puede resultar en una catástrofe, alguien se decidirá por esta”. Ing. Edward Aloysius Murphy, 1949.