Jueves, 3 Mayo 2007

Después del almuerzo en el mismo edificio de las Jornadas, han tenido lugar las sesiones de la tarde:

  • Tanja Vos: Técnicas para la especificación de casos de testeo
  • Patricio Letelier: Pruebas de Aceptación como conductor del proceso software
  • José Luis Antón: Maximizar el retorno de las pruebas de rendimiento mediante simulaciones eficientes

Tras las cuales se ha realizado la mesa redonda.

Tanja Vos: Técnicas para la especificación de casos de testeo

Tanja Vos, directora del grupo SQUaC y organizadora de las jornadas, ha centrado su intervención en la fase de diseño de casos de test.

Tanja Vos, durante su exposición

Para empezar, ha dado definiciones de lo que no es testeo; principalmente, deja claro que no se trata de demostrar que el software funciona bien: eso requeriría demostraciones formales o comprobar todos los casos posibles, lo cual no es un objetivo realista con la práctica totalidad del software existente. El objetivo del testeo es encontrar errores, y un buen caso de test es un caso con alta probabilidad de encontrarlos. 

Existen dos escuelas de testeo conocidas como exploratory testing y scripted testing, aunque en la realidad existen aproximaciones híbridas. Pero tanto una como otra se benefician de las técnicas de diseño; lo importante es que esas técnicas son aplicables en función del modelo de software estudiado, que será mental en caso del exploratory testing o estará debidamente documentado en caso del scripted testing.

Con esa premisa, Tanja presenta un par de técnicas para el diseño de casos de test. Por un lado, las particiones equivalentes, basadas en la división de las posibles entradas en conjuntos de valores que se comportarán de modo similar en cuanto a la detección de errores. Y por otro lado, el testeo combinatorio, que puede utilizarse cuando la respuesta del sistema no depende del orden de las entradas ni de su estado anterior. 

Patricio Letelier: Pruebas de Aceptación como conductor del proceso software

Patricio Letelier es profesor de la UPV, y ha dedicado su intervención a explicar cómo las pruebas de aceptación (las que se utilizan para demostrar a un cliente que el sistema desarrollado cumple un determinado requisito) pueden servir para superar las dificultades habituales que existen en la creación de una "cultura de pruebas" en un equipo de desarrollo.

Exposición de Patricio Letelier

Estas dificultades son variadas: no están suficientemente integradas en el desarrollo; se suele sobrevalorar la automatización del testeo; no se estudia suficientemente la rentabilización de las pruebas.

Las pruebas de aceptación tienen una serie de características positivas para el proceso de desarrollo: obligan a definir requisitos verificables; permiten negociar con el cliente el alcance del sistema; ayudan a planificar el desarrollo; sirven de guía a los desarrolladores; y permiten detectar oportunidades de reutilización.

De todas las técnicas habituales a la hora de describir especificaciones (texto, diagramas, plantillas, bocetos), algunas son más útiles que otras para especificar las pruebas de aceptación. El objetivo propuesto por Patricio Letelier es describir los requisitos mediante una combinación de casos de uso, una identificación de las pruebas de aceptación, y bocetos de las interfaces de usuario requeridas. De ese modo, la especificación de requerimientos y la definición de las pruebas de aceptación son realizadas al mismo tiempo.

José Luis Antón: Maximizar el retorno de las pruebas de rendimiento mediante simulaciones eficientes

José Luis Antón ha iniciado su sesión con una breve descripción de las actividades de SOGETI. A continuación, ha planteado las ventajas y características de las simulaciones para realizar las pruebas de rendimiento.

José Luis Antón, durante su ponencia

Las caidas de sistemas cuestan dinero, y ha ofrecido cifras concretas de varias empresas. Así pues, es importante realizar pruebas que prevengan esas caidas, no sólo en aplicaciones web (que habitualmente tienen que soportar un gran número de usuarios), sino también en otro tipo de aplicaciones.

Los diferentes tipos de testeo de rendimiento (carga, stress, estabilidad -o fiabilidad- y volumen de datos) son difíciles de realizar con usuarios reales. Las simulaciones resultan por tanto muy útiles; estas simulaciones deben considerar tanto el sistema real (la simulación más técnica) como los usuarios que lo utilizan; ambas partes deben ser suficientemente exactas como para que los resultados sean útiles.

Algunos detalles a tener en cuenta en la simulación son la concurrencia de usuarios y su think time; es decir el tiempo durante el que los usuarios no interactúan con el sistema (están haciendo otras cosas). Además, la definición de una simulación concreta requiere detallar su parametrización (de literales, cantidades, think times, etc.), su modelo de carga, los escenarios simulados; etc.

Por último, algunas características que permiten maximizar el retorno de las simulaciones y beneficiarse de ellas son: la existencia de un lenguaje de scripting rápido; que permita reutilización y que sea modular; y que la simulación sea monitorizable para hacer un seguimiento de su ejecución.

Mesa redonda

Finalmente, durante la mesa redonda que cerraba la jornada todos los ponentes del día han respondido a las cuestiones aportadas por los asistentes y por Tanja Vos. Algunas de las ideas que han surgido durante las respuestas son las que siguen:

Mesa redonda a la conclusión de la primera jornada
  • El análisis de qué partes se deben testear basándose en riesgos es más útil que hacerlo basándose en los requerimientos, debido a que las empresas están más dispuestas a refinar los primeros, pero difícilmente lo harán con los segundos.
  • Hay muchas herramientas de testeo disponibles; la mejor elección depende de qué se quiere testear exactamente. Por supuesto, es posible testear tanto la interfaz de usuario como el backend del sistema.
  • ¿Un testeador y un programador debe tener perfiles diferentes? En principio, sí, ya que el trabajo de los programadores es crear, mientras que el de los testeadores es, en cierto modo, destruir; además, los segundos deben tener un punto de vista más amplio del sistema. Sin embargo, todo depende del tipo de test del que se trate; al fin y al cabo, el testeo se basa muchas veces en scripts que no dejan de ser programación.
  • El hecho de que el testeo unitario sea realizado por el propio programador tiene sus ventajas y sus inconvenientes; su conocimiento del sistema puede sesgar las pruebas, pero utilizar personas diferentes puede complicar excesivament el proceso de testeo y corrección.
  • En cuanto al test driven development, parece que obligar a los programadores a escribir los test antes de programar aumenta la calidad de su código. Eso sí, el testeo nunca es un escudo que protege al sistema de un modo absoluto, sino un filtro que intenta dejar pasar el mínimo número de errores posibles.
  • Las herramientas open source de testeo existentes pueden ser tan válidas como las propietarias, y merecen ser evaluadas en igualdad de condiciones, siempre que se tenga en cuenta sus especiales características. Son especialmente útiles en el ámbito de las pruebas unitarias, y en las aplicaciones web; no existe tanta variedad para otro tipo de aplicaciones.
  • Por último, han aparecido aspectos que hacen atractivo ("sexy") el mundo del testeo (en contra de lo que pueda parecer): los testeadores se encuentran con multitud de situaciones diferentes, y son muchas veces los primeros en conocer y probar los nuevos desarrollos. Se convierten en los miembros más avanzados del equipo.

Deje un comentario

*
Teclea la palabra del recuadro, por favor, para comprobar que eres una persona y no un proceso de spam. << Anti-Spam Image



Blog del grupo SQUaC. ¿Conoces nuestros servicios? testeo de software; etc.

SQUaC, una web del ITI