Jun 09
Tests que no deben faltar
Después de 8 años vinculado al desarrollo de software tengo que reconocer que cualquier instalación de una nueva versión de un software supone un reto y no está exento de sorpresas.
El diseño e implementación de tests son actividades muy importantes y necesarias en el ciclo de vida de un proyecto software. Estas actividades forman parte de una disciplina denominada aseguramiento de calidad del software. Recientemente he llegado a la conclusión de que son esos pequeños detalles, que normalmente se dejan pasar por alto, los que más tiempo nos hacen perder a la hora de realizar un paso a producción. Realizar un paso a producción tiene sus connotaciones, y una de ellas es que normalmente o se realizan en las instalaciones del cliente o las realiza el propio cliente. Podríamos considerar en lugar del cliente, al usuario final para así dejar a un lado la parte empresarial de la profesión.
Con intención de recoger esos tests que nos adviertan de esos pequeños detalles, he preparado el siguiente listado de tests que incluiré por regla general en mi plan de tests para proyectos Java:
- Comprobar que la JVM que hay configurada en el sistema operativo es válida según el catálogo de requisitos no funcionales. Eso no evitará que si nuestra aplicación se despliega sobre un contenedor o servidor de aplicaciones, éste esté configurado con una JVM distinta a la del S.O., pero esta situación es menos frecuente.
- Si nuestra aplicación necesita una base de datos, comprobar que la configuración es correcta y que la versión y base de datos están recogidas en el catálogo de requisitos no funcionales.
- Realizar una comprobación como la anterior para servicios como directorio activo, correo electrónico, etc. De esta forma, podremos descartar problemas de integración con sistemas externos a nuestro software.
- Si nuestro software necesita escribir en el sistema de ficheros, comprobar que disponemos de los permisos correspondientes.
- Si nuestro software necesita acceder a internet o fuera de una red de área local, realizar la correspondiente comprobación.
Estos tests son muy simples pero nos ayudarán a detectar posibles problemas de integración con el entorno donde nuestro software se tiene que instalar. ¿Alguna sugerencia para añadir a estas pruebas de carácter muy básico?
June 11th, 2008 at 19:23
Pues yo añadiría:
6. Procedimiento para dar “marcha atrás” por si la actualización no funciona como se esperaba.
7. Configurar el log4j para que los primeros días “nos cuente muchas cosas” y que cuando pasados esos días veamos que la cosa funciona bien, bajar el nivel de depuración.
8. Comprobar (mediante algún sistema automático) que la nueva versión no cambie a peor sustancialmente el funcionamiento de los sistemas (uso de memoria, carga de procesador, entrada/salida, generación de temporales/logs…)
9. Avisar claramente a los usuarios que hay una versión nueva, por si hubiera alguna incongruencia/cambio sea fácilmente detectado. Además, si la nueva versión “cambia algo de sitio” el usuario no se vuelve loco buscándolo, al menos sabe que se ha cambiado de versión.
10. Celebrar con cerveza que todo ha ido bien
//nunca llego a este punto
Gufete
June 11th, 2008 at 20:51
Hola Gufo:
Lo que propones son de todo menos test básicos, concretamente algunos de los puntos son complicados de llevar a cabo. Entiendo que son necesarios, pero se escapan del alcance de lo que entiendo por test unitarios, de sistemas y de integración.
El punto 8 sí lo veo realmente interesante y factible. Para eso están las pruebas de rendimiento y escalabilidad. Algunas de ellas fácilmente automatizables y otras no tanto.
Con respecto al punto 7 nada mejor que un manual de buenas prácticas.
Sin embargo, es el punto 10 el que yo definiría en integración continua.
Mucha alegría verte por aquí.
Un abrazo.
September 13th, 2008 at 19:16
El tema de las pruebas de software anda flojo en España. Los estudios sobre pruebas de software que han publicado desde el grupo de Calidad del Software de ATI (www.ati.es/gtcalidadsoft) que aparecen en Baquia (http://www.baquia.com/noticias.php?id=14106) y me han llegado ayer por su lista de distribución (https://mail.ati.es/mailman/listinfo/reicis).
No hay ningún pdf colgado pero dicen que lo que presentarán esto en las jornadas que organizan en Madrid los días 24 y 25 pero los detalles que pongo abajo parece que no hacen pintar bien el panorama.
Os pongo el resumen que mandaron:
Sobre un total de 20 prácticas clave para la realización madura de pruebas de software, como media las organizaciones implantan 8.
Sólo un 26% de los encuestados afirmaba haber recibido formación específica sobre pruebas. Al diseñar pruebas, los profesionales tienen tendencia a la falta de sistemática provocando:
Desestimar la priorización (tras valorar la importancia y prioridad de los casos, sólo aparece 1 de los más prioritarios entre los 10 caminos más ejecutados y entre los 10 menos probados aparecen 3 de los 10 más prioritarios)
Los factores que más influyen (más del 85% de acuerdo) en que pueda existir una situación mejorable de las pruebas en España son:
Los factores menos generalizados (50% de acuerdo) para explicar las deficiencias de las pruebas son: