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:

  1. 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.
  2. 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.
  3. 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.
  4. Si nuestro software necesita escribir en el sistema de ficheros, comprobar que disponemos de los permisos correspondientes.
  5. 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?

3 thoughts on “Tests que no deben faltar

  1. 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

  2. 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.

  3. 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:

    • Baja eficacia (como promedio, se prueba el 46% de las opciones del software)
    • Baja eficiencia (se repiten innecesariamente casos de prueba totalmente equivalentes en valores que oscilan desde un 135% para alta de datos a un 13,8% en pruebas de borrado. el 50% de los casos ejecutaban caminos ya probados por el “tester”)

    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:

    • La presión de calendario de las pruebas como última fase del desarrollo
    • La tentación de recortes en calidad cuando hay problemas económicos o de retrasos
    • La desconexión y falta de aprovechamiento de los productos y diseños de desarrollo para diseñar las pruebas
    • La carencia de formación de directivos (para apreciar el potencial de las pruebas), la de los titulados en cuanto a formación específica en la carrera y la falta de formación a los profesionales en las empresas

    Los factores menos generalizados (50% de acuerdo) para explicar las deficiencias de las pruebas son:

    • Las pruebas constituyen un campo con poco desarrollo y atractivo profesional
    • Es una actividad destructiva, con poco atractivo, un fastidio obligatorio
    • Los puestos en calidad y pruebas son inestables y no es extraño que desaparezcan para integrar a los profesionales en la plantilla de desarrollo cuando hay problemas en la organización

Leave a Reply

Your email address will not be published. Required fields are marked *