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

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.

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