Actualmente, la industria TIC ha sufrido un crecimiento explosivo producto de la digitalización y globalización; las empresas se mueven en un ambiente altamente competitivo donde el “time-to-market” es fundamental a la hora de implementar nuevas estrategias de crecimiento. En estas condiciones, es imprescindible contar con productos de calidad entregados a tiempo y cuidando los presupuestos.
Dado lo anterior, los departamentos de TI se están convirtiendo en actores fundamentales dentro de las estrategias de las empresas. Esto pone presión sobre todo a las áreas de desarrollo, donde, en ocasiones, para cumplir con los plazos y presupuestos se acortan procesos, lo que hace habitual entregar productos que no satisfacen los requerimientos solicitados por la organización, y brindar una aplicación con falla tiene un alto costo ya que se invierte mucho dinero y tiempo en corregir los defectos. Usualmente el tiempo adicional y los sobrecostos son mayores que los que hubiésemos tenido si se hubiese desarrollado la aplicación bien desde el principio.
Es por esto que aplicar procesos de calidad durante el desarrollo del software es imprescindible y una de las formas de asegurar la calidad es mediante el testing de software.
¿Qué es realmente el testing?
En palabras simples podríamos decir que es ejecutar el software para identificar algún defecto, sin embargo, esta definición es bastante incompleta ya que el desarrollo se ha vuelto cada vez más complejo, hoy en día se construyen sistemas conectados entre sí que deben soportar una gran cantidad de requerimientos. Por ejemplo, si pensamos en un escenario de CiberDay nos damos cuenta que no basta con verificar el comportamiento de la tienda en línea, sino que también se debe comprobar el alto tráfico de usuarios que desean ver y comprar productos, lo que se traduce en aplicar, además, pruebas de carga y estrés.
La primera persona que debe hacer pruebas es el mismo programador. Si al ir programando se van detectando los errores, los podrá ir corrigiendo inmediatamente. Las metodologías de desarrollo actuales, como el TDD, BDD o ATDD, proponen un desarrollo basado en las pruebas haciendo indispensable que los programadores conozcan los frameworks de pruebas unitarias como JUnit, NUnit, PyUnit, etc. Sin embargo, la sicología del testing plantea que esto no basta y es necesario la visión de un tercero que genere una prueba más objetiva, ya que el programador verifica solo el escenario exitoso. Sin ir más lejos, recuerdo una vez que hice clic en el login sin ingresar ningún dato y en otra ocasión llené un formulario web desde abajo hacia arriba, en ambas pruebas los sistemas se cayeron, lo que sorprendió a los equipos de programación quienes comentaron que los usuarios hacen las cosas diferentes, y sí, la perspectiva del área de pruebas es bastante similar a la de un usuario común con la ventaja de que, al ser especialistas, también pueden verificar bases de datos, conexiones, procedimientos, servicios, mensajes, y escenarios complejos, etc.
Se debe entender que las pruebas realizadas por el área de calidad son un proceso en el que es fundamental comprender las necesidades del cliente, el ambiente de producción, los escenarios en que será ejecutado el sistema, analizar si se requieren herramientas para verificar código o rendimiento y considerar la posibilidad de generar pruebas de automatización que faciliten la regresión ahorrando tiempo y esfuerzo. Con todo este análisis se pueden diseñar planes de prueba y casos de pruebas idóneos, base para la ejecución de pruebas y detección de defectos que luego serán corregidos por el equipo de desarrollo.
Distintas experiencias
A través de los años, he visto diferentes procesos de testing, tanto en empresas chilenas como en extranjeras. Así, conocí una compañía de desarrollo que no entendía el testing como un proceso y solo realizaba pruebas exploratorias de “caja negra” justo antes del paso a producción, sin planificación ni preparación. En una ocasión un analista olvidó revisar la mitad del sistema, lo que produjo grandes problemas en producción, y se tuvo que revertir la instalación de la aplicación.
En otro tiempo, trabajé en una empresa en la que el proceso de testing estaba definido, ordenado y era conocido por todos, se manejaban varias planillas de casos de pruebas que se iban actualizando cada vez que aparecía un nuevo requerimiento, y los tiempos de testing eran tan respetados, que si a dos días del paso a producción el software aún tenía defectos la fecha de entrega se postergaba una semana, de esta forma se evitaba que los sistemas fallaran en producción o que se revirtiera alguna entrega.
Por qué no dejar el testing para el final
Otro punto a tener en cuenta, y que he observado a lo largo de mi carrera, es que el proceso de testing se inicia cuando el producto está relativamente terminado, es decir, en las fases finales del proyecto, lo que es absolutamente contraproducente. “Testing temprano” recomienda la ISTQB, y esto significa que ojalá comencemos las revisiones en las etapas de análisis y diseño, verificar requerimientos, casos de uso, planificaciones, costos, etc., ya que la gran mayoría de los defectos viene de las etapas previas a la programación. He visto más de un proyecto que fracasó en producción porque el equipo de desarrollo no hizo un buen análisis del ambiente, el sistema creado funcionó correctamente en desarrollo y en QA, pero una vez instalado en producción tuvo fallas invalidantes, es decir, el software no hacía nada. Después de varias semanas en que se trató de corregir los defectos, se despidieron programadores y se rehízo la aplicación; alguien del equipo se dio cuenta de que el motor de base de datos utilizado en desarrollo no era el mismo que manejaba producción. Es decir, el defecto venía desde el análisis de los requerimientos.
Otra de las razones por la que no es recomendable dejar el testing para el final, es que se tiene la fecha de entrega encima, por lo que se cuenta con poco tiempo para hacerlo, y menos para corregir defectos. Sabemos que al tener poco tiempo se trabaja bajo presión, lo que puede ser contraproducente. Lo recomendable es ir revisando el producto paralelo al desarrollo.
Es importante hacer hincapié en la importancia del trabajo colaborativo entre el área de calidad y la de desarrollo. Basta de creer que se está compitiendo. Resulta crucial entender que ambas áreas buscan el mismo objetivo, un producto de calidad que no supere los costos y sea entregado a tiempo, y para esto, ambas deben trabajar de la mano.
Cuando me inicié como analista de calidad, hace ya bastantes años atrás, no siempre eran bien recibidos los reportes de los defectos. En ese tiempo -tal vez- los desarrolladores interpretaron el reporte como una crítica personal; y yo, por inexperiencia, sostenía una actitud de superioridad.
Con el tiempo aprendí que la búsqueda de la calidad del software es un trabajo colaborativo, que no es una crítica a la persona, tampoco a su trabajo, sino que se ambiciona una mejora continua. Así, hay que reconocer la labor del programador, conversar en buenos términos, buscar la causa de los defectos, y ser meticuloso y detallista en el reporte para facilitar el entendimiento de los defectos. Todas son prácticas que posibilitan el trabajo “codo a codo” con el equipo de desarrolladores, lo que siempre va en el camino de lograr cumplir con aplicaciones de calidad sin retrasar los tiempos de entrega de cada proyecto.
