Después de mis artículos previos, más teóricos, acerca de prácticas con metodologías ágiles, quería haceros una introducción a Microsoft Test Manager, la herramienta de gestión, y ejecución de casos de prueba que se usa en conjunto con Team Foundation Server 2010.
Lo que necesitamos para poder empezar a usar Microsoft Test Manager, es alguna de estas dos versiones de Visual Studio:
-
Visual Studio 2010 Test Professional: esta es la versión dedicada puramente a Testing, y que incluye Microsoft Test Manager
-
Visual Studio 2010 Ultimate: esta es la versión más completa de Visual Studio 2010, incluye todas las herramientas, y por supuesto, Microsoft Test Manager.
Así como Team Foundation Server 2010 (inglés), que entre otras muchas cosas, será nuestro almacén de casos de prueba y requerimientos (o historias de usuario).
En el primer arranque de Microsoft Test Manager nos conectaremos a un proyecto contenido en Team Foundation Server, por lo que tened en cuenta que no podréis usar esta herramienta sin tener antes TFS, así como algún proyecto creado.
Los casos de prueba
Los casos de prueba en Microsoft Test Manager se representan como un elemento de trabajo más de Team Foundation Server (Work Items).
Estos casos de prueba, los organizaremos en un primer nivel de jerarquía en planes de pruebas, que podrán ser por iteración, o según la organización que nosotros queramos crear.
Aunque su estructura en detalle depende de la plantilla de proceso que usemos, nos vamos a fijar en tres partes principales de su estructura a alto nivel.
Propiedades generales
En estas propiedades, nos encontramos cosas como el título, quién se va a encargar de ejecutarlo, a que iteración pertenece, su prioridad.
Como veis son propiedades bastante generales que bien podrían ser de cualquier otro elemento de trabajo, pero que nos permiten organizar nuestros casos de prueba a lo largo de nuestros proyectos.
Pasos de prueba
Los casos de prueba funcionales, habitualmente, constan de una serie de pasos que la persona responsable de su ejecución irá ejecutando y observando el comportamiento de la aplicación.
Por supuesto, dependiendo del tipo de prueba tendremos más o menos detalle en estos pasos, por ejemplo un caso de prueba exploratorio, tendrá pasos con menos detalle que un caso de prueba totalmente definido.
En ciertos pasos además tendremos el resultado esperado, esto es importante a la hora de ejecutar las pruebas, que sepamos qué podemos esperar después de realizar algunas acciones, y saber así si la aplicación se comporta correctamente.
Seguro que la mayor parte de vuestras aplicaciones tienen formularios de entrada de datos que nos interesa probar con distintas combinaciones, esto también lo podemos representar en los casos de prueba mediante el uso de parámetros, tanto en los pasos, como en los resultados esperados. Durante la ejecución de los casos de prueba, veremos que esto se representa como iteraciones del propio caso de prueba.
No es necesario decir que estos pasos son algo que es susceptible de cambio, y que deberemos de revisar en las planificaciones de la iteración y durante la iteración con el equipo y el Product Owner para asegurar que nuestras pruebas son las adecuadas para completar el objetivo de la iteración.
Enlaces a otros elementos de trabajo
Como todos los elementos de trabajo en Team Foundation Server, se pueden establecer relaciones jerárquicas o de iguales, entre ellos.
Con estos enlaces, en Microsoft Test Manager, podemos representar la composición de pruebas para una determinada historia de usuario o requerimiento, pudiendo de este modo realizar el seguimiento y trazabilidad de que pruebas tenemos para cada uno de estos elementos dentro de nuestro proyecto, y más concretamente en una iteración, y saber así cuál es su estado.
También es de especial importancia estas relaciones con los defectos o bugs. En el caso ideal, los defectos los descubriremos cuando estemos realizando las pruebas, asignando el nuevo defecto que creemos (como elemento de trabajo), al caso de pruebas con el que lo hayamos descubierto conseguimos varios objetivos.
El primero, asegurarnos que a la hora de arreglar el defecto tengamos información para reproducirlo, y que a la hora de haberlo corregido, tengamos la certeza, ejecutando la prueba de nuevo, que lo hemos corregido efectivamente.
En el caso contrario esto es de gran utilidad así mismo, ya que cuando detectemos un defecto, lo primero que tenemos que hacer es crear un caso de prueba que lo demuestre, para conseguir los objetivos que comentábamos.
La ejecución
Una vez que tenemos definidos los casos de prueba, los ejecutaremos manualmente, usando también Microsoft Test Manager.
En este artículo estoy simplemente haciendo una introducción a la ejecución manual, pero espero poder cubrir las automatizaciones de pruebas en otros artículos más adelante.
La herramienta de ejecución de pruebas, Test Runner, nos irá mostrando cada uno de los pasos a ejecutar, y podremos ir marcando cada paso como correcto o como fallido dependiendo del resultado de la ejecución. Además, los pasos que en su definición tienen un resultado esperado concreto, nos mostrarán esa información, para que podamos estar seguros de que esperar durante la ejecución.
Durante esta ejecución, y es una de las cosas que más me gustan, dependiendo de los datos de diagnóstico que hayamos configurado, recogeremos información, que puede ir desde los eventos registrados en el sistema, vídeo de las acciones, hasta una tecnología, válida para .NET, llamada Intellitrace (en inglés), que recoge, a modo de caja negra de avión, la pila de ejecución de la aplicación que estamos probando, incluidas excepciones, llamadas a métodos, contenido de parámetros.
Estos datos de diagnóstico son especialmente interesantes a la hora de crear un defecto, ya que cuando creamos el defecto desde aquí, además de enlazarse con el caso de pruebas, se añade, automáticamente, toda esta información de diagnóstico, creando lo que llamamos un bug accionable, que permite al equipo de desarrollo tener la máxima cantidad de información a la hora de reproducirlo y solucionarlo.
Por último, dependiendo de si todos los pasos se han marcado como correctos, o por el contrario tenemos alguno fallido, podremos comprobar a posteriori si la prueba se ejecutó con éxito o detectamos algún error, pudiendo consultar toda esta información desde la herramienta.
Conclusión
Como veis, desde esta herramienta tenemos todo lo necesario para poder definir nuestras pruebas, ejecutarlas, dar de alta los defectos con información de diagnóstico, y hacer el seguimiento de las pruebas.
Me he dejado muchas cosas fuera, como son la automatización de pruebas, gestión automática del ciclo construir-desplegar-probar mediante entornos virtuales, seguimiento en detalle de casos de prueba.
Pero el objetivo era una pequeña introducción a esta nueva herramienta incluida en Visual Studio 2010, y de la que espero seguir hablándoos en el futuro
Luis Fraile lleva trabajando en entornos Microsoft desde más de 10 años, empezando con Visual Basic 6, y posteriormente desde la primera versión del .NET Framework, habiendo participado en multitud de proyectos relacionados con estas tecnologías.
En los últimos años, a parte de desarrollar, también se ha dedicado a ayudar a equipos a la hora de abordar procesos de metodologías ágiles, especialmente en entornos Microsoft con tecnologías como Team Foundation Server. También es colaborador habitual de la revista Dotnetmania, así como ponente en eventos, a nivel nacional, relacionados con gestión de ciclo de vida y Team Foundation Server.
Puedes seguirlo en Twitter: @lfraile
Sus blogs son: lfraile.net y geeks.ms/blogs/lfraile
