[Formación] Introduciendo el testing en nuestros equipos con Microsoft Test Manager

ACTUALIZADO: Ya tenemos fecha y registro para Barcelona.

Hace poco os informaba de día de fomación que vamos a tener en Santander, pues ya tenemos fecha para Madrid y Barcelona:

En este curso veremos, de un modo práctico, como incorporar las pruebas en nuestros equipos, especialmente en equipos ágiles, empezando en las fases tempranas del proyecto y las iteraciones, mediante tests de exploración. Se irá avanzando desde la creación de los tests de exploración, descubrimiento y comunicación de defectos con información rica (Intellitrace, video, etc) al equipo de desarrollo, resolución de defectos y comunicación de impacto a las pruebas según se agrega y corrigen funcionalidades. Así como la automatización de nuestras pruebas, con el objeto de agilizar el proceso de aseguramiento de la calidad.

Para esto, usaremos las herramientas de Microsoft Test Manager, Lab Management, Team Foundation Server y Visual Studio, todos ellos en su versión 2010, así como de la automatización de pruebas mediante Coded UI

Se realizarán hands-on labs.

  • Breve introducción al rol de tester en equipos ágiles

  • Planificación del esfuerzo de pruebas

  • Creación y ejecución manual de pruebas de exploración

  • Creación de defectos de exploración con información rica

  • Comunicación de cambios y reparación de defectos mediante el impacto de tests

  • Creación de pruebas de regresión

  • Repetición rápida de pruebas manuales

  • Automatización de pruebas de interfaz de usuario

  • Ejecución de pruebas en entornos de Laboratorio mediante Lab Management

[Workshop] Introduciendo el testing en nuestros equipos con Microsoft Test Manager

Como ya os anunciamos en el evento del sobre testing en equipos ágiles, del ALM Sessions 2011, vamos a realizar una serie de workshops prácticos, sobre lo que vimos en el evento, y a la espera de iros anunciando siguientes eventos, os anuncio el primero confirmado.

Será en el Centro de Innovación de Santander, y será el 11 de mayo, para inscribiros aquí os dejo el link, y una breve descripción de lo que veremos y de la agenda:

http://www.ciin.es/web/servicios/eventos/Paginas/MTMLabM20110511.aspx?Fecha=11-05-2011

En este curso veremos, de un modo práctico, como incorporar las pruebas en nuestros equipos, especialmente en equipos ágiles, empezando en las fases tempranas del proyecto y las iteraciones, mediante tests de exploración. Se irá avanzando desde la creación de los tests de exploración, descubrimiento y comunicación de defectos con información rica (Intellitrace, video, etc) al equipo de desarrollo, resolución de defectos y comunicación de impacto a las pruebas según se agrega y corrigen funcionalidades. Así como la automatización de nuestras pruebas, con el objeto de agilizar el proceso de aseguramiento de la calidad.

Para esto, usaremos las herramientas de Microsoft Test Manager, Lab Management, Team Foundation Server y Visual Studio, todos ellos en su versión 2010, así como de la automatización de pruebas mediante Coded UI

Se realizarán hands-on labs.

  • Breve introducción al rol de tester en equipos ágiles

  • Planificación del esfuerzo de pruebas

  • Creación y ejecución manual de pruebas de exploración

  • Creación de defectos de exploración con información rica

  • Comunicación de cambios y reparación de defectos mediante el impacto de tests

  • Creación de pruebas de regresión

  • Repetición rápida de pruebas manuales

  • Automatización de pruebas de interfaz de usuario

  • Ejecución de pruebas en entornos de Laboratorio mediante Lab Management

[Slides] Testing en equipos ágiles con Microsoft Test Manager 2010

Espero que toda la gente que vino a la sesión acabaséis contentos, el hecho es que todas  las demos funcionaron a la perfección, y había mucha gente, así que yo estoy contento, mucho interés en torno a MTM, eso es bueno.

Lo único malo … el evento iba con retraso, y nos “insertaron" otra sesión de 10 minutos en nuestro slot (no comment), por lo que nuestra sesión de 2 horas, terminó con sólo 1h15m, así que no tuve tiempo para mostrar todas las diapositivas y terminar la demo completa como yo quería.

Pero de todos modos, estamos contentos, y os anuncio que estamos planificando un taller deep dive acerca de Microsoft Test Manager y Lab Management 2010,en breve tendremos fecha Y bueno, aquí tenéis las diapositivas, publicadas  en el slideshare de Testhouse:

[Evento] Testing en equipos ágiles

Cuando hablamos acerca de las pruebas en entornos ágiles, rápidamente pensamos en las pruebas unitarias, pruebas de integración, o más pruebas a nivel de código, por supuesto, hay equipos que ya utilizan herramientas como Selenium, o Cucumber para cubrir más pruebas funcionales, pero no siempre son tan completas o nos ayudan tanto como necesitamos.

Desde la llegada de Team Foundation Server 2010 y Visual Studio 2010, tenemos nuevas herramientas que cubren más escenarios de pruebas funcionales de las aplicaciones.

Basándonos en los principios ágiles, veremos cómo utilizar estas herramientas en nuestros equipos,  revisaremos conceptos como la automatización, o los cuadrantes de las pruebas de Brian Marick.

A partir de uno de los conceptos más ágiles como son las pruebas de exploración, vamos a aprender cómo utilizar las herramientas de ejecutar las pruebas y promover la comunicación con los desarrolladores mediante los errores accionables con información rica para resolverlos, hasta descubrir cómo los cambios en el desarrollo en el código afectan a nuestras pruebas.

Vamos a ver cómo las pruebas de Coded UI ayudarán en el proceso de automatización de nuestras pruebas, ocn el fin de ser cada vez más efectivos en la ejecución.

Finalmente veremos cómo automatizar nuestro ciclo de construir-desplegar-probar mediante Lab Management,con el fin de conseguir entregas y pruebas más rápidas de realizar.

Con mi nuevo trabajo en Testhouse (y tal vez este es tema para otro post), como Microsoft ALM Division Manager, me encargaré de dar esta conferencia.

¿Y cuando será esto? será el jueves  miércoles 9, en Madrid, durante el ALM Sessions 2011, que es compartido este año con el Cloud Day, estáis por Madrid ese día, quizás queráis pasaros por allí, podéis registraros y ver más información aquí:

http://www.microsoft.com/spain/destinolanube/alm.aspx

La conferencia será durante el track 2, de 11:30 a 13:30.

Mejoras para testing y el editor de test Coded UI en el Visual Studio 2010 Feature Pack 2

Recientemente, para los suscriptores de MSDN, Microsoft ha lanzado el Visual Studio 2010 Feature Pack 2, que también contiene todas las nuevas características incluidas en la primerFeature Pack. Lo podéis descargar aquí: http://msdn.microsoft.com/en-us/vstudio/ff655021.aspx

Aparte de un montón de mejoras en las herramientas de modelado, hay nuevas características interesantes para la parte de testing. Dos grandes mejoras son el soporte de ser capaz de grabar una prueba de coded UI o prueba manual  con Test Manager en Internet Explorer y  reprodrucirla en Mozilla Firefox,  también han introducido la posibilidad de crear pruebas de coded UI o manuales para aplicaciones Silverlight 4 , interesante ¿verdad?.

Pero hay una nueva herramienta que he estado utilizando en estos días, la herramienta visual de edición de coded UI tests. Si ya habéis trabajado con pruebas de coded UI, ya sabéis que hacer cambios en ellas, a posteriori, de forma manual, es casi un dolor.

Entonces, ¿cómo podemos utilizar esta nueva herramienta? Ok, en el proyectoque tengamos pruebas de este tipo, tenemos un archivo llamado UIMap.uitest hacéis doble clic en este archivo, o con el botón derecho seleccionamos “Abrir”, y se abrirá una ventana como esta:

image_thumb1

Aquí tenemos en el lado izquierdo, las acciones que tenemos grabadas , y, en el lado derecho tenemos los controles que se han trazado en las grabaciones.

Y ¿qué podemos hacer? bueno aquí tenéis un tutorial completo (en inglés) de las posibilidades de estas herramientas: http://msdn.microsoft.com/en-US/library/gg269469.aspx

Esto incluye opciones como eliminar una acción que no queremos , dividir una grabación de lad acciones en varios métodos para ser más fácil de mantener el código, extraer un método completo a otro archivo de clase, cambiar el nombre de método, etc.

Pero aquí vienen algunos problemas de esta herramienta, vamos a imaginar que queremos cambiar el nombre de la acción “Abrirurl” , a “AbrirURL”, estamos acostumbrados a las herramientas de refactorización en Visual Studio, pero esta vez, cuando decidimos cambiar el nombre, lo hará sólo cambió en el archivo UIMap.uitest, así que tendremos que ir manualmente a todas las pruebas que utilicen ese método, y hacer el cambio, una pena, ya que esa funcionalidad (cambiar el nombre de métodos ), lleva mucho tiempo en Visual Studio.

Sucede también cuando nos decidimos a romper una grabación larga en varios métodos, digamos que tenemos este método resultado de una grabación de acciones:

image_thumb3

Casi todo el mundo estará de acuerdo es una grabación de larga, y que puede ser más legible si lo dividimos en varios métodos, para esto, seleccionamos una acción, y pulsando botón derecho, seleccionamos Split into a new method:

image_thumb5

Esto romperá el método en dos, y todas las acciones, a partir de la que hemos seleccionado pasarán a un nuevo método, pero aquí está el problema. En el lugar en el que se utilizaba el método original, tendremos que ir, y de forma manual, agregar la llamada al  nuevo método método.

Este tipo de cosas sucede con algunas opciones más de esta herramienta, pero no os preocupéis demasiado, la herramienta siempre nos avisará de este tipo de cosas, así que, con tener un poco de cuidado al leer cualquier pop-up que aparece cuando se utiliza esta herramienta, problema solucionado

¿Conclusiones? Bueno, me gusta mucho esta nueva herramienta, y todas las nuevas ventajas del Feature Pack 2, pero cuidado al usarlo, ya que implica un trabajo manual en algunos casos, pero eso es todo. Quizás en un futuro Feature Pack, todo esto tipo de cosas se automatizarán.

La necesidad de probar … y el iPhone 4

Últimamente, en varias listas de correo y foros variados, estabamos comentando la necesidad de probar, todo lo que hacemos y desarrollamos desde el principio.

Y cuando decimos desde el principio, decimos desde la primera línea de código, y es que no debería de haber ni una sóla línea de código sin una prueba, no voy a discutir si usar TDD o cualquier otra técnica, da igual, pero no debería de haber ni una sóla línea de código sin una prueba. Con esto nos aseguramos, entre otras muchas cosas, que cuando metamos mano a ese código, podamos estar seguros de que lo dejamos funcionando, y que cuando venga alguien y vea ese código pueda estar seguro de que funciona.

En esta primera categoría entran pruebas unitarias y de integración, y pueden sernos de gran ayuda tanto las propias herramientas de Visual Studio 2010, como los frameworks tipo nUnit o Gallio.Con esto ya tenemos nuestra primera capa de pruebas creada.

OJO, aquí sólo estamos asegurando los componentes y/o su integración entre ellos, aún no estamos asegurando que la aplicación haga lo que tiene que hacer, mucho cuidado, que esto  no es suficiente aún.

Y es que ¿cómo sabemos que cierta característica de la aplicación está terminada? aquí entran las pruebas funcionales y de aplicación, que tienen que describir, para cada caracterísitca, que condiciones se tienen que dar para que aporte valor, y esto es importante, que aporten valor al cliente, este es el objetivo último de lo que quiera que estemos construyendo, que aporte valor, y esto lo tenemos que describir (junto con el cliente), tanto para el sistema completo, como para cada una de sus características, y que no haya duda razonable de cuando está “hecho” algo.

Para esto, podemos apoyarnos en herramientas como las nuevas herramientas de testing de Visual Studio 2010, con el Test Manager, y también, usando técnicas como Behaviour Driven Development, que intentan promover la colaboración entre desarrolladores, departamento de QA, y gente de nivel de negocio, y que por ejemplo a nivel técnico, podemos implementar usando MSpec.

Vale, hasta aquí con estas dos capas de pruebas, que no es poco, vamos bien, por supuesto luego hay más pruebas que muchos productos tienen que pasar, como por ejemplo pruebas de accesibilidad para pasar la AAA, pruebas de usabilidad para ver como se adaptan los usarios al software, pruebas de rendimiento, de escalabilidad, etc.

Y ¿por qué saco todo esto sin más?, pues porque recientemente, y gracias a mi operadora, me han regalado un iPhone 4, si ese que si lo agarras “mal” pierde cobertura, y la verdad es que tenía intriga por ener uno entre mis manos y ver la realidad del tema, ya que incluso en foros por ahí, hablan de que Apple, había sacado otro modelo sin el fallo de diseño y sin hacerlo público, claro, como si cambiar una línea de producción fuese rápido y barato, en fin …

Por supuesto, lo primero que hice cuando tuve mi nuevo cacharro en las manos, fue probar el tema del famoso agarre, y sorpresa, es perfectamente reproducible, especialmente en sitios dónde la cobertura no es óptima. Y esto me lleva a preguntarme ¿cómo hacen las pruebas los señores de Apple?, porque está claro que nadie ha probado que un móvil, al ser agarrado, no pierda su principal valor, que es la cobertura o bien dicho la capacidad de llamar con la mejor calidad posible.

Tampoco veo que hayan hecho pruebas de usabilidad en ese sentido, ya que cualquier persona que lo hubiese cogido con ánimo de probarlo, se habría dado cuenta.

¿Entonces?, la verdad es que el iPhone 4, en otros términos es un buen producto, la pantalla es muy buena, la funcionalidad es buena, etc., pero han fallado en algo básico, y esto ha hecho que se desate, y con razón, toda la red con comentarios negativos. si, es cierto que los usuarios  más acérrimos lo negarán, pero es algo que ocurre, que está ahí y que es reproducible, y que pueden dar al traste, y dejar mal sabor de boca, a un producto que no es malo (hasta que venga Windows phone 7 y le de un repaso jejeje).

Por tanto ¿cómo probáis vuestras aplicaciones?¿cumplís con el valor que tienen aportar?¿tenéis claro cúal es ese valor que tienen que aportar? … ahí dejo eso, os dejo que creo que me llaman … vaya al coger el móvil he perdido cobertura Smile

Como funcionan los “Impacted Tests” de VSTS 2010

Una de las nuevas funcionalidades de Visual Studio Team System 2010 (en la versión de Developers), es la de los test “impactados”. Esta pequeña funcionalidad, está destinada a ahorrarnos mucho tiempo a la hora de hacer Test Driven Development en nuestros desarrollos.


Recordemos, que una de las grandes máximas en el TDD, es que los tests se ejecuten rápido, ¿y qué modo más rápido que ejecutar sólo los que se ven afectados por el código que acabamos de tocar?, aqui es dónde entra el análisis de test afectados (queda mejor que impactados) de VS 2010.


Sin embargo, tras hablar con algunos compañeros, parece que no está muy claro como hacer funcionar esta pequeña ayuda, y lo cierto es que está un poco rebuscado, veamos a ver si lo puedo contar aquí.


Antes de nada, decir que doy por supuesto que sabemos crear pruebas unitarias, crear una lista de pruebas, habilitar la cobertura de código (esto ha cambiado un poco en VS 2010), y empezar a crear una Team Build en el Team Explorer, no lo cuento aquí por no hacer un artículo muy largo. Si alguien no conoce este tipo de cosas que lo diga y lo contaremos por aquí. Cualquiera que haya hecho esto en TFS 2008, no debería de tener problemas para seguir estas instrucciones.


Lo primero que tenemos que tener en cuenta, es que, para que VS 2010 se de cuenta de que tests están afectados, necesita información de que tests ejecutan el código que estamos modificando, ¿lógico no?. ¿y de dónde lo saca?, pues de las builds de Team Build, si, necesitamos resultados previos de una Team build.


¿Y que datos necesita de la Team Build?, pues lo primero necesitamos, que las pruebas que se ejecuten durante la Team Build, publiquen información de cobertura de código (code coverage). Esta es la primera base para esta información. Además, con las nuevas Team Build (basadas en WorkFlow), necesitamos ejecutar un paso más, que es la publicación del análisis de test afectados, que por defecto está DESACTIVADA. Vayamos al grano.


Una vez que ya tenemos nuestro proyecto, con sus listas de pruebas y la cobertura de código habilitada para el ensamblado que estamos probando, hmmm vale, si estoy dando por supuesto que todos sabéis hacer esto, si no sabéis, dejadme un comentario y lo cuento otro día. Vamos a crear una nueva Team Build.


Y aquí ya empezamos con VS 2010, una vez que estamos en la pantalla de crear una nueva Build, tenemos una sección “Process”, si pulsamos en ella veremos lo siguiente:


image


Lo primero, pulsaremos el primer link (“Select solutions …”), que nos llevará aquí:


image 


Dónde con el botón de los “…” seleccionaremos los proyectos que queremos compilar. Después, seleccionamos el link de “Select tests”, y nos llevará de nuevo a la sección anterior pero esta vez a TestProjects, volvemos a pulsar los puntos suspensivos, y se nos mostrará la ventana para seleccionar el fichero “.vsmdi” que corresponde con los tests que queremos ejecutar (y sus correspondientes listas).


Y ahora viene la magia para los impacted tests, ya que tenemos que activar unas cuantas opciones del proceso.


La primera es esta:


image Vamos desplegando el proceso de este modo: “Select an agent …”, “Compile and test”, “Get Impacted tests”, y ohhhh, vemos que está a false (a la derecha), pues la ponemos a true.


Seguimos desplegando por la rama “Test All Projects”, “Test a Project”, “Run MSTest …”, y llegamos aquí:


image


Ohhh, segunda sorpresa, la actividad (a la derecha) “PublishTestImpactInformation” está a false, pues nada, la ponemos a true.


Y seguimos adelante, y en la sección “Publish the Test Impact Data”:


image


Ohhh, tercera sorpresa, también a false, pues nada, la ponemos a true.


Con esto (y el resto de propiedades de la Team Build habituales), ya tenemos la Build preparada para tener información de los test afectados.


Pero hay más trucos, debemos de ejecutarla al menos DOS veces antes de tener información, la primera vez, se establece la línea base de código, y la segunda ya tenemos la información necesaria para el análisis.


Una vez que la hemos ejecutado dos veces (y que haya funcionado con información de cobertura incluida), ya estamos en disposición de probar esta funcionalidad.


Para ello, abrimos la solución de nuevo (en caso de haberla cerrado), y seleccionamos el menú “Test”, “Windows”, “Test Impact view”.


Y más “trucos”, tenemos que seleccionar en esta vista, el proyecto al que pertenece, y la build de la que queremos obtener la información de tests:


image Con esto, y si hemos seguido todos los pasos, una vez que empecemos a modificar código, y grabemos los cambios (sin necesidad de hacer check-in), veremos como en la sección de Impacted Tests, nos van apareciendo los tests a los que afectan estos cambios.


En fin, es un poco lioso, lo se, y espero que para la versión final esto cambie (ya les he dado el feedback), pero por ahora, eso es todo lo que tenéis que hacer :)


Y bueno, para cualquier duda aquí (http://www.lfraile.net) me tenéis.




Este post es cross-posting desde http://www.lfraile.net  y estoy muy interesado en tu opinión. ¿te vienes por aquí y me dejas un comentario?