Pruebas automáticas de la calculadora… o cualquier otra aplicación Windows

Tested calculator Siempre que en algún evento o en alguna formación muestro las pruebas web de Team System, surge una pregunta inevitablemente: ¿y esto no lo hay para aplicaciones Windows?… Mi respuesta tradicionalmente ha sido: No, no hay nada… y luego venía la explicación ‘oficial’ habitual: Es que tu aplicación debe tener una capa de interfaz muy fina y claro con las pruebas unitarias debería ser suficiente, no pasa nada porque algo de código de tu aplicación, relacionado con la interfaz de usuario se quede sin probar automáticamente, y bla, bla, bla…

El otro día uno de los desarrolladores de uno de los equipos para los que estoy haciendo mentoring sobre Scrum y Team System me decía lo siguiente: Según lo propugnado por las metodologías ágiles debemos probar todo lo que es susceptible de fallar y debemos automatizar toda prueba que sea automatizable, así que Rodrigo, tu respuesta no me deja contento… y la verdad es que tiene toda la razón. Si bien es cierto que existen herramientas de terceros que permiten grabar pruebas de interfaz de usuario estas son caras o muy caras, así que esta ocasión no nos sirven. Aquí termino la historia…

Es cierto que está respuesta cambiará notablemente con VSTS ‘Rosario’, que integrará de serie la posibilidad de grabar pruebas de interfaz de usuario, pero también es cierto que hasta Rosario nos queda un trecho.

Pero yo no me suelo rendir fácilmente, quien haya jugado conmigo a pelota mano lo sabe, y después de la conversación anterior he estado dándole vueltas al tema y tengo una nueva respuesta… no exenta de complejidades, pero una respuesta al fin y al cabo. La respuesta no pasa por grabar la pruebas al estilo de como se graban las pruebas web de VSTS, sino por escribir código que automatice las pruebas de interfaz de usuario.

Este enfoque es mucho más flexible que el grabar test, pues cuando nuestra interfaz de usuario sufre cambios en mi opinión es mucho más simple modificar código que grabar de nuevo los test. De hecho, los equipos que tienen baterías de pruebas web de tamaño considerable suelen elegir generar el código UI Automation Librariescorrespondiente a la prueba y modificarlo según su interfaz de usuario va cambiando. Aun recuerdo como en una visita a Redmond con ocasión de un MVP Summit, tuve gracias a Ricardo Varela, la posibilidad pasar un rato con un ingeniero de pruebas del equipo de Windows Mobile. Me enseño las pruebas automatizadas de interfaz de usuario que escribía ‘a manele’ y ejecutaba contra una ‘granja’ de diferentes modelos de PDA. Desde ese momento, tuve claro que automatizar pruebas de interfaz de usuario es posible y que escribir código para ello es un camino viable.

Con idea de saber si se puede andar este camino integrando nuestras pruebas con las pruebas unitarias de VSTS y para hacerme idea del la magnitud de esfuerzo que este camino exige he hecho un pequeño piloto. La idea es simple: automatizar el testeo de algunas acciones de la calculadora de Windows. La investigación previa me llevo a este artículo de MSDN Magazine: Test Run: The Microsoft UI Automation Library que me mostro el camino hacia la automatización de las pruebas de interfaz.

Así que vamos usar una útil y desconocida librería de Microsoft: UI Automation Library. Esta librería nos permite automatizar acciones sobre cualquier interfaz Windows sea está Win32, Windows Forms, Web o WPF y está orientada a soportar accesibilidad y las pruebas de interfaz de usuario. Para usarla será necesario añadir una referencia a UIAutomationClient y a UIAutomationTypes y hacer un ‘using’ de System.Windows.Automation. A partir de este momento tendremos acceso a las clases de la librería de automatización de la interfaz de usuario.

Usando esta librería es muy simple crear pruebas unitarias que automaticen nuestras pruebas de interfaz de usuario. Estas pruebas unitarias se pueden ejecutar desde VSTS sin problemas, pero no se podrán ejecutar como parte de una build de TFS, pues necesitan, lógicamente mostrar interfaz de usuario.

Os dejo el código de las pruebas hechas sobre la calculadora, creo que se explican por sí mismas. Son un ejemplo simple de como provocar acciones de interfaz de usuario usando UI Automation Library. También podéis descargar el código si lo deseáis.

using System.Diagnostics;

using System.Windows.Automation;

using Microsoft.VisualStudio.TestTools.UnitTesting;

 

namespace UITestingSample

{

  /// <summary>

 

  /// </summary>

  [TestClass]

  public class UITestSample

  {

    static AutomationElement _mainWindow;

 

    /// <summary>

    /// Initilizes objects needed for testing

    /// </summary>

    /// <param name=»testContext»>Test context</param>

    /// <remarks>

    /// Get the calculator’s main window automation element and store

    /// it in a static private field

    /// </remarks>

    [ClassInitialize()]

    public static void ClassInitialize(TestContext testContext)

    {

      Process[] processes = Process.GetProcessesByName(«calc»);

 

      if (processes.Length != 0)

      {

        _mainWindow =

          AutomationElement.FromHandle(processes[0].MainWindowHandle);

      }

      else

      {

        Assert.Inconclusive(«Windows Calculator must be running»);

      }

    }

 

    /// <summary>

    /// Test for sum

    /// </summary>

    [TestMethod]

    public void SumTest()

    {

      InvokeButton(«C»);

      InvokeButton(«1»);

      InvokeButton(«+»);

      InvokeButton(«1»);

      InvokeButton(«=»);

      Assert.AreEqual(GetDisplayText(), «2, «);

    }

 

 

    /// <summary>

    /// Test for square root

    /// </summary>

    [TestMethod]

    public void SqrtTest()

    {

      InvokeButton(«C»);

      InvokeButton(«9»);

      InvokeButton(«sqt»);

      Assert.AreEqual(GetDisplayText(), «3, «);

    }

 

    /// <summary>

    /// This function get the automation element corresponding to a button from its caption

    /// </summary>

    /// <param name=»caption»>Button’s caption</param>

    /// <returns>The automation element corresponding to the button</returns>

    private AutomationElement GetButtonByCaption(string caption)

    {

      return _mainWindow.FindFirst(

        TreeScope.Children,

        new PropertyCondition(AutomationElement.NameProperty, caption));

    }

 

    /// <summary>

    /// This function click a button provided its caption

    /// </summary>

    /// <param name=»caption»>Button’s caption</param>

    private void InvokeButton(string caption)

    {

      AutomationElement ae = GetButtonByCaption(caption);

      ((InvokePattern)(ae.GetCurrentPattern(InvokePattern.Pattern))).Invoke();

    }

 

    /// <summary>

    /// Get the text displayed by the calculator

    /// </summary>

    /// <returns></returns>

    private string GetDisplayText()

    {

      AutomationElement ae =

        _mainWindow.FindFirst(

          TreeScope.Children,

          new PropertyCondition(AutomationElement.ControlTypeProperty, ControlType.Edit));

 

      return (string)ae.GetCurrentPropertyValue(ValuePattern.ValueProperty);

    }

  }

}

La conclusión de mi pequeño piloto es que es plenamente posible escribir pruebas de interfaz de usuario e integrarlas dentro de las pruebas de usuario de VSTS. También es cierto que para que este esfuerzo sea viable, debemos poner mucho enfoque en crear una serie de funciones de ayuda que enmascaren el tener que lidiar con la UI Automation Library. La gran pregunta es ¿merece la pena el esfuerzo?… supongo que todo depende de la cantidad de código que tengamos en nuestra interfaz de usuario. Si logramos minimizar esta variable, como debemos perseguir en toda buena arquitectura, creo que el esfuerzo no merecerá la pena.

Templex: Repositorio de adaptaciones de plantillas metodológicas para TFS

Dos MVPs de VSTS (Martin Danner y Joel Semeniuk) han creado un proyecto en CodePlex destinado a almacenar mejoras a plantillas metodológicas para TFS creadas y aportadas por la comunidad. El proyecto se llama Templex. Sin duda es una excelente idea tener un lugar donde recoger las adaptaciones de plantillas metodológicas que mucha gente está realizando.

El objetivo es, a partir de plantillas existentes, crear una biblioteca de ampliaciones y adaptaciones que puedan se usadas sobre esas plantillas. En teoría esto nos permitirá elegir y utilizar las mejores características de cada plantilla y además compartir las adpataciones que hagamos con la comunidad.

Estararé vigilante a este proyecto para ver cómo va evolucionando y creciendo. La idea me parece excelente.

Evento: Team System, metodologías ágiles y calidad del software… ¿Se puede pedir más?

Banner Team System

El próximo martes, 1 de Julio tendré el placer de participar en un evento sobre los temás que más me apasionan, gestión de proyectos, calidad y Team System en las ofincinas de Microsoft en Madrid. Además de tener un rato para hablar sobre estos temas con una audiencia que siempre demuestra interés este evento es especial pues será el primero que comparta con mi compañero de Plain Concepts, Pablo Alvarez Doval, que nos hablará de calidad del software con Team System. Seguro que su tiempo trabajando en soporte de Microsoft le han hecho gran conocedor de los problemas que la ausencia de calidad en el software genera 😉

La agenda no puede ser más prometedora, en mi opinión. Además una vez puestos, podéis asistir a las dos sesiones, la primera sobre metodologías ágiles y Team System y la segunda sobre calidad con Team System.

Sesión: Metodologías ágiles y Team System en el mundo real

Cada vez más empresas necesitan encontrar el equilibrio entre control de los proyectos y productividad de sus equipos de desarrollo, las metodologías ágiles proponen un marco de trabajo que nos permite gestionar los proyectos y mejorar la productividad de nuestros equipos de desarrollo sin caer en la temida burocracia. Team System es un marco de trabajo ideal que proporciona de manera integrada todas las herramientas que un equipo ágil puede necesitar. En este evento veremos cómo un equipo de desarrollo puede usar metodologías ágiles junto a Team System para dar un salto importante en su productividad.

Agenda:


09:00    Registro y bienvenida
09:30    Metodologías ágiles ¿qué son? ¿cómo nos ayudan?
10:00    Introducción a MSF Agile
10:45    Introducción a Scrum
11:00    Café
11:30    Scrum y Team System en el mundo real
12:00    Team System: la herramienta perfecta para el desarrollo ágil
13:30    Comida


Sesión: Calidad del software con Team System


La manera más rápida de desarrollador software es hacerlo con la calidad requerida desde el principio. Team System propone la calidad del software como pieza central del desarrollo de software moderno. Team System proporciona una serie de herramientas que facilitan enormemente que los desarrolladores y los testers hagan de las actividades orientadas a asegurar y mantener la calidad durante todo el ciclo de desarrollo. En este evento veremos cuáles son estas herramientas, cómo se pueden utilizar en nuestros proyectos y qué ventajas obtendremos de su uso.

Agenda:


14:30    Testeo unitario
15:00    Pruebas web  y de carga
15:45    Optimización y monitorización del rendimiento de aplicaciones durante el desarrollo
16:15    Refrescos
16:45    Test de aceptación
17:15    Integración de la calidad en el proceso de desarrollo: métricas de calidad
19:00    Fin del evento

¿Cómo hacer funcionar Scrum? ¿Cómo saber si Scrum está funcionando?

Broken bridge Uno de los lectores de mi blog me planteaba estas cuestiones hace poco. La verdad es que Scrum es simple, pero caminar también es simple y a menudo tropezamos. Que algo sea simple no implica automáticamente que sea fácil de llevar a cabo. Todas las actividades, incluso las más simples, necesitan un periodo de aprendizaje. Muchos equipos de desarrollo fracasan al implementar una metodología y esto no es ajeno a Scrum. Ya he hablado en alguna otra ocasión de las tácticas que podemos tomar para para implantar una metodología. Pero hoy voy a hablar sobre las dificultades que he visto en los equipos en los que he intentado implatar Scrum y como saber si Scrum está funcionando, desde el punto de vista de saber si estamos usando adecuadamente Scrum o no.

Las principales dificultades que encuentran los equipo que tratan de implementar Scrum tienen que ver con:

La falta de atención a los detalles: Muchas equipos fracasan en la implantación de Scrum porque desatienden los detalles. Los detalles son vitales en Scrum. Sin Daily Scrum, no hay Scrum. Sin Product Backlog, no hay Scrum. Sin Product Owner, sin Equipo y sin Scrum Master, no hay Scrum. Sin Sprint Planning Meeting, no hay Scrum. Sin Sprint Review, no hay Scrum. En definitiva, sin seguir a rajatabla las liturgias y las reglas de Scrum, no hay Scrum. El antídoto para este problema es claro: seguir con disciplina monacal las reglas de Scrum. Es fácil caer en hacer ‘adaptaciones’ a Scrum para ‘pulir’ los aspectos que no nos gustan, pero siempre que he visto este comportamiento en algún equipo sin mucha experiencia en Scrum, ha sido contraproducente. No hagáis adaptaciones, la probabilidad de dañar Scrum, sin no se tiene experiencia, es mucha.

Entender y formar el equipo multidisciplinar: Construir un equipo es muy difícil y construir uno multidisciplinar aun más. Es más una meta, un proceso que algo que se logra en un momento. Pero la recompensa es muy jugosa. Un equipo multidisciplinar es sumamente productivo y además minimiza los riesgos asociados a la rotación de personal y las ‘parcelitas’ de conocimiento, por todos conocidos. Hace casi treinta años se escribió Peopleware, la obra definitiva en lo que se refiere a comprender como funciona un buen equipo.

Crear y mantener un product backlog: Construir el product backlog y estimarlo es algo complejo. Se trata de capturar los requisitos del sistema y esto siempre ha sido problemático para los implicados en el desarrollo de software. Pero por mi experiencia, la mayor dificultad no surge de construir el product backlog. La mayor dificultad surge a la hora de mantenerlo actualizado e ir refinándolo de manera continua. Casi todos los Product Owner con los que me he cruzado desatienden su obligación. Aquí el antídoto pasa por que el Scrum Master ‘persiga’ al Product Owner para conseguir su implicación total en el mantenimiento del Product Backlog.

Recursos no dedicados: Muchas empresas no son capaces de mantener recursos dedicados a un proyecto. Si no mantenemos recursos dedicados, a un número finito y relativamente bajo, la productividad se ve dañada por los continuos cambios de contexto. Muchas organizaciones sistemáticamente obvian el coste de los cambios de contexto excluyéndolo de sus planificaciones . Los cambios de contexto son el problema silencioso de muchos equipos de desarrollo. Cuando un equipo es sometido a continuos cambios de contexto, a continuos cambios de enfoque, difícilmente será productivo. En este caso el antídoto es difícil de aplicar, pues pasa a menudo por un cambio de cultura en la empresa, a menudo acostumbrada a tratar todas las tareas de manera prioritaria, atendiendo en cada momento el asunto que más ‘ruido’ provoca y renunciando con este comportamiento a la posibilidad de establecer una planificación razonable. La ausencia de una planificación razonable siempre lleva a mermas de productividad relacionadas con la ausencia de objetivos a corto plazo.

Integración de las tareas de soporte y mantenimiento: Muchos equipos tienen dificultad a la hora compaginar las tareas de mantenimiento de versiones o productos anteriores con el desarrollo de nuevos proyectos. La problemática es similar a la comentada para los recursos no dedicados. La idea es, en este caso también, perseguir el minimizar los cambios de contexto. En esta línea la mejor táctica es que sean equipos diferentes los que hacen mantenimiento y los que desarrollan nuevos productos. Pero esto no es siempre posible. Otra táctica habitual es repartir el día entre actividades, por ejemplo utilizar las mañanas para desarrollar un nuevo producto y las tardes para las tareas de mantenimiento o soporte de versiones o productos anteriores. Evidentemente a la hora de planificar un Sprint tendremos que restar de la capacidad de nuestro equipo el esfuerzo que estimamos que tendremos que dedicar a tareas de mantenimiento y soporte.

Estimación: Que la estimación es un aspecto complicado del desarrollo del software es por todos conocido y un tema que he tratado recurrentemente en este blog. En Scrum la estimación es aspecto central. Estimamos el Product Backlog y estimamos las tareas de cada Sprint. La estimación es el primer paso para todo el proceso de planificación tanto a medio como a corto plazo. Aquí el principal problema con el que me suelo encontrar es que los equipos no tienen experiencia en estimar, y por lo tanto se les hace difícil. Esta dificultad hace que muchos equipos recorten las actividades relacionadas con la estimación que Scrum propone. Es imposible hacer una planificación realista sin realizar las actividades de estimación. Además el realizar los procesos de estimación explicita que Scrum propugna conseguimos no solo una estimación realista sino que además aprovechamos el propio proceso de estimación para lograr información sobre qué debemos construir. Una obra indispensable para comprender la estimación y la planificación en las metodologías ágiles es Agile Estimating and Planning de Mike Cohn.

Si bien Scrum tiene sus dificultades a menudo es fácil diagnosticar si estamos funcionando en el marco de Scrum o no. Basta con comprobar, una a una, si estamos siguiendo las reglas de Scrum:

Las reglas de Scrum (I)- El Sprint Planning Meeting
Las reglas de Scrum (II)- Durante el Sprint
Las reglas de Scrum (III)- El Sprint Review Meeting
Las reglas de Scrum (y IV)- El Sprint Retrospective Meeting

Además de esto, las retrospectivas son un excelente momento en el que podemos averiguar si Scrum está funcionando o no: basta con escuchar al equipo para saber si Scrum les ayuda o no. Cuando Scrum no ayuda al equipo es que no está funcionando. Toda metodología que no ayude al equipo de desarrollo a trabajar mejor y con más facilidad, sufrira el rechazo de los desarrolladores. Con el rechazo de los desarrolladores, el grupo más numeroso en cualquier proyecto, ninguna metodología llega para quedarse, por mucho que alguien la empuje.