A los que hacemos desarrollo nos pasó (y nos pasa a diario) el tener que testear las aplicaciones que fabricamos. Está claro y nadie discute que es una tarea que tenemos que realizar a fin de que nuestro trabajo cumpla con los objetivos pactados por un cliente, tu jefe, o ambos (este sería el peor escenario, dado que tenés que tener en cuenta 2 opiniones diferentes).

Pero, honestamente, ¿a quién le gusta realizar el testing? Es decir si sos desarrollador, claramente te gusta generar cosas nuevas y no tener que pasarte, a veces, un 50% del tiempo estimado para un proyecto haciendo testing. Testing que muchas veces al cliente, o bien no le termina de convencer y el mismo dedica otro 20-40% de su tiempo a probar tooooodo de nuevo, con lo cual le van a surgir infinidad de cambios, o bien no le interesa y deja todo como está. En este último caso, la bronca también existe porque vos perdiste tiempo en probar algo que al tipo no le interesaba en lo mas mínimo.

Sumado a esto, tenemos diferentes tests, acordes a las aplicaciones que desarrollemos; y con esto los sucesivos problemas que pueden surgir.

Si desarrollas aplicaciones web, podes tener infinidad de problemas:

• El maquetado se rompe y la página te queda horrible.
• El maquetado no es compatible con algún navegador (IE en el mayor de los casos) y tenés que agregar infinidad de hacks y fixes para que se vea bien. Igualmente, gracias a las nuevas versiones del IE, estos problemas van disminuyendo
• Al cliente se le ocurrió que quiere agregar un botón 20px mas grande que el original, con lo cual tenés que modificar tooooodo, para que quede bien
• Problemas de programación (que debieran ser los menores, en nuestro caso), como ser errores de código, de compilación, de base de datos, etc.

Si desarrollas aplicaciones de escritorio, los errores son variados, pero lo bueno es que casi no vamos a tener problemas en cuanto al diseño. Pueden existir detalles de programación, de compilación, de base de datos; aquí pueden surgir errores en base a las bibliotecas que se usen, frameworks, etc. Siempre te falta algo para que la cosa camine en el primer RUN.

Claramente el caso más raro de los que me tocó, probar aplicaciones de IVR. Imagínense lo pesado que puede ser a veces llamar a algún lugar y que los atienda una maquina que los guíe; peor es tener que probar esa aplicación. Pasar por los menúes 20 veces, probar todas y cada una de las opciones, los audios que se reproducen, los tiempos de respuesta de los WebServices o las Bases de Datos. Es probable que en un proyecto de IVR, el testing te lleve más del 60% del tiempo del proyecto en sí.

Ni hablar si la aplicación tiene que vivir en varios entornos, por restricción del cliente; tenés que probar en más de un entorno, lo cual incrementa el tiempo de testing. Y para peor, que no existe nada visual, en lo que uno pueda ver a simple vista donde están los errores. La llamada se cortó, ¿y por qué? A revisar 20 docenas de archivos de logs, para ver que una sentencia, le falto un “;”. Es increíblemente desgastante.

En la medida de las posibilidades y para intentar evitar estos problemas (digo intentar, porque sabemos que no van a desaparecer, pero si pueden reducirse considerablemente), sugiero algunos tips a tener en cuenta. Pueden existir muchos más, pero creo que son los básicos para empezar:

1. Tener varias reuniones con el cliente, jefe, Project Manager, etc., a cargo del proyecto para evacuar la mayor parte de las dudas
2. De ser posible, ir haciendo testing parciales. Ir probando pequeñas funcionalidades a medida que se desarrolla. No siempre es del todo viable, pero de poderse, está bueno.
3. Ante la mínima duda (de diseño, funcional, etc.), pregunten al encargado del proyecto. No dar nada por sentado. Nuestro punto de vista como desarrollador, tiende a no coincidir con el del cliente.
4. Si trabajan en un equipo, plantear de entrada las reglas de juego. Metodología de desarrollo, entornos, escalabilidad, tiempos. Al ser varios, cuanto más te organices, mejor salen las cosas
5. Antes de arrancar a desarrollar, hacer un breve research de los requisitos para que nuestra aplicación funcione (servidores, base de datos, bibliotecas, frameworks, etc.). De esa manera sabemos que contamos con todo lo necesario para la cosa camine.
6. Algo que nos cuesta a todos es comentar el código que hacemos. Es útil al momento de que otra persona que lea nuestro código, entienda de que se trata.
7. Los logs son molestos, pero a la vez muy útiles. Cuanto más log generemos en el transcurso de la aplicación, mas fácil nos resulta luego hacer el debug de la misma.
8. Al finalizar el desarrollo, siempre hacer un test unitario. Es una buena fuente para encontrar más errores. Aquí podemos probar toda la aplicación, o bien módulos por separado de la misma, a ver como se porta. En general podemos incluir ya las conexiones a las bases de datos y demás, aunque sugiero hacer todo en algún entorno de prueba
9. Hacer test de carga, si lo consideran necesario. Hay aplicaciones que probablemente no lo necesiten, pero si si la aplicación va a tener muchos accesos (una Web grande, por ejemplo) o si la aplicación es algún tipo de servicio que está activo 7×24. No vaya a ser cosa que al momento de ponerlo en producción, el mismo no se banca mucha concurrencia.

Es un pantallazo breve, para que una tarea tan densa como resulta ser el testing, pase a ser amena o al menos, mínima. Es posible que luego una persona encargada de hacer Test o QA, pruebe la aplicación, pero bueno… ¡eso es otro capítulo!

¿Qué otras recomendaciones sugieren?