El jueves 25 de Abril realizaremos en el MUG junto con Microsoft una jornada dedicada al ciclo de vida de las aplicaciones.

Horario: 13:30 a 18:15 hs. 

Agenda:

13:30 – Acreditación

14:00 - Continuous Delivery - (Ing. Viviana Chelini)

Así como las industrias han sufrido cambios en su proceso de producción a lo largo del tiempo, en la industria del software estamos ante uno de esos cambios.
Hoy los negocios varían con rapidez, ya sea por modificaciones en sus escenarios específicos, por nuevas regulaciones gubernamentales, por la aparición de nuevos canales de comunicación, etc. El software forma parte de la columna vertebral de las operaciones de una empresa y por ende debe acompañar la velocidad de los cambios con métodos de producción acordes a la época.
La temática del evento está centrada en como transformar el Área de Sistemas, en una herramienta ágil y predecible que acompañe el ritmo del negocio.

14:15 - Contratos Ágiles y Estimaciones - (Mg. Patricia Scalzone)

Todos conocemos los beneficios de las metodologías ágiles. Conocemos al famoso triángulo de hierro. Sabemos que "la única constante del universo es el cambio", etc., etc. pero también sabemos que nuestros clientes hablan de "fixed time" y "fixed money".
En este track veremos cómo, a través de contratos ágiles, podemos lograr satisfacer las demandas de un cliente que prefiere o necesita alcances y costos definidos y no quiere perder los beneficios de una metodología ágil.

15:05 - Continuous Delivery con VS - TFS 2012  (Ing. Andres Stang - Ing. Gustavo Lombardo)

El delivery continuo no es lo mismo que el deployment continuo. Una entrega no es satisfactoria hasta que no se encuentra en producción, sin importar lo que suceda en etapas previas. En un contexto de aplicaciones modernas necesitamos entregar valor con un flujo continuo y constante y eso no siempre es sencillo.
En este track intentaremos detallar las problemáticas actuales, los principios de un delivery continuo y las buenas prácticas que podemos aplicar para lograr el éxito.

15:55  - Intervalo

16:15 - Continuous Testing (Victor Passador)

En los últimos años, a pesar de haber aprendido a desarrollar y probar de manera incremental, el testing a menudo sigue siendo un proceso enorme, que actúa como bloqueo ante el equipo de desarrollo y le dificulta respuestas rápidas a la demanda de los clientes. A los productores de software les cuesta cada vez más afrontar el costo de seguir entregando actualizaciones de valor de forma continua a la vez que se mantiene el up time de la aplicación. En este mundo de aplicaciones modernas es crucial lograr un ciclo de desarrollo-prueba-entrega rápido y predecible. Veremos aquí cómo tratar de integrar el testing a ese ciclo y lograr testing continuo.

17:05 – DevOps (Daniel Levi)

Las organizaciones que usan prácticas y herramientas para integrar el área de desarrollo y operaciones pueden acelerar rápidamente su proceso de ciclo de vida de aplicaciones (ALM) y permitir escenarios de continuous delivery del software para sus clientes, sean internos o externos. Con continuous delivery, los clientes se benefician con el rápido acceso a las nuevas aplicaciones, funcionalidades y fixes – y beneficios para el negocio al incrementar el uso y satisfacción del cliente, como así también tener una alta calidad del software a bajo costo. La filosofía y práctica de una mayor integración entre el equipo de desarrollo y operaciones es lo que conocemos como DevOps.

17:55 – Cierre – (Ing. Viviana Chelini)

Datos del Evento:

Jueves, 25 de Abril del 2013.

en el Auditorio del MUG, Rivadavia 1479, Piso 1°A, Capital Federal.

Para más información e inscripción AQUÍ

TFS 2012 propone gestionar las tareas del desarrollo a través de un Web Access totalmente renovado desde su versión 2010. Utilizando esta herramienta, el PM podrá entre otras cosas, administrar las capacidades del equipo, crear y asignar User Stories, Taks, Bugs, planificar sprints, verificar estado de avance del proyecto a través del Burndown chart, del reporte de salud de los Builds, y varios etcéteras más.

La planificación propiamente dicha, se realiza a través del “Board” (un tablero muy útil en daily meetings además de otros momentos) y facilita la administración de tareas ya que no hay que trasladar el cambio de estado de los papelitos en el “tablero de corcho” a la herramienta, sino que se puede hacer directamente desde ésta.

Considero que la herramienta aporta mucho a la agilidad, pero en ciertos escenarios, se queda corta en posibilidades de personalización.

El caso que quiero plantear se da con un Team Project ya creado y migrado desde la versión anterior, con el template MSF for Agile 5.0, donde quisiéramos que aparezcan en ese board los bugs, además de las tareas.

Aquí se explica cómo es que funciona el board y cuáles son los tipos de Work Item que allí aparecen.

Si bien el texto es claro y con ejemplos, no cubre el 100% de la necesidad de nuestro escenario. Describiré más abajo cuáles son los pasos a seguir (tomando los pasos detallados en el link y ampliando con lo que estaba faltando):

Aclaración 1: Cada uno de estos pasos consiste en exportar desde TFS a un directorio local una sección del Process Template con el que fue creado el Team Project, modificar las entradas que sean necesarias y volver a incorporar esa sección modificada en el servidor, todo esto utilizando el comando witadmin

Aclaración 2: Como estamos modificando definiciones en un servidor que probablemente esté en producción, es buena práctica conservar una copia de cada archivo que obtengamos luego de ejecutar un comando “witadmin exportxxx …”. Si las cosas no salen como esperamos, teniendo un backup, siempre será posible volver todo a su estado inicial ejecutando el comando “witadmin importxxx …”

Paso 1: “Bajar” la definición de categorías del template para poder incluir a los bugs dentro de la categoría Task Category (hace un tiempo escribí aquí sobre categorías de Work Items)

witadmin exportcategories
     /collection:CollectionURL
     /p:ProjectName
     /f:"DirectoryPath\categories.xml"

Paso 2: Modificar la sección correspondiente para que quede como se muestra a continuación

<CATEGORY name="Task Category" refname="Microsoft.TaskCategory">
   <DEFAULTWORKITEMTYPE name="Task" />
   <WORKITEMTYPE name="Bug" />
</CATEGORY>

Paso 3: “Subir” la nueva definición

witadmin importcategories
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\categories.xml"

Paso 4: “Bajar” la definición de configuración para agregar los estados (metastates) y así unificar entre Task y Bugs

witadmin exportcommonprocessconfig
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\CommonConfiguration.xml"

Paso 5: Modificar la sección correspondiente para que quede como se muestra a continuación

<TaskWorkItems category="Microsoft.TaskCategory">
    <States>
       <State value="Active" type="Proposed"/>
        <State value="Resolved" type="InProgress"/>
        <State value="Closed" type="Complete"/>
    </States>
</TaskWorkItems>

Paso 6: “Subir” la nueva definición

witadmin importcommonprocessconfig
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\CommonConfiguration.xml"

Atención: En el ejemplo del artículo de MSDN hay una entrada para el estado “New”, pero debemos eliminarla porque no existe ese estado en el template MSF for Agile 5.0.  Si omitimos ese cambio, obtendremos un error al ejecutar el comando witadmin importcommonprocessconfig

Paso 7: “Bajar” la definición de Bug para poder modificar el template y agregar el campo Activity

witadmin exportwitd
    /collection:CollectionURL
    /p:ProjectName
    /n:Bug
    /f:"DirectoryPath\Bug.xml"

Paso 8: Modificar la sección correspondiente para que quede como se muestra a continuación

<FIELD name="Activity" reportable="dimension" type="String" refname="Microsoft.VSTS.Common.Activity">
    <HELPTEXT>Type of work involved</HELPTEXT>
    <SUGGESTEDVALUES expanditems="true">
        <LISTITEM value="Development"/>
        <LISTITEM value="Requirements"/>
        <LISTITEM value="Design"/>
        <LISTITEM value="Testing"/>
        <LISTITEM value="Deployment"/>
        <LISTITEM value="Documentation"/>
    </SUGGESTEDVALUES>
</FIELD>

Paso 9: “Subir” la nueva definición

witadmin importwitd
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\Bug.xml"

Aclaración: Si bien estamos agregando este campo a la definición del bug porque el bug ahora pertenece a la categoría TaskCategory (paso 1) y requiere de esta definición, no es necesario modificar el Layout de edición a menos que queramos tener acceso a ese campo al momento de editar un bug.

Conclusión

Como ven en la captura, ahora tenemos visibilidad de los Bugs en el board Agile, y además, se ve una nueva columna (Resolved) que muestra los bugs en ese estado. Por favor no tomen en cuenta el Burndown Chart, es sólo un proyecto para pruebas

 
Si después de realizar todo el proceso, los bugs siguen sin aparecer, por favor revisen que estén vinculados a la respectiva User Story.

Hasta la próxima!

“Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.” ExtremeProgramming.org

Un poco de contexto

Como generalmente sucede en todos los ámbitos, una de las cosas más difíciles de conseguir es el equilibrio, y la creación de Tests Unitarios no queda fuera de esta premisa.

Por un lado es imposible negar los beneficios que aporta contar con pruebas automatizadas, pero por otro lado también se hace difícil contradecir a aquellos que argumentan que es muy costoso su mantenimiento ante cambios en los requerimientos.

No es la idea de este post entrar en un debate interminable defendiendo una postura u otra, sólo me limitaré a decir que no somos fanáticos de los extremos y que si bien consideramos que es indispensable contar con un buen set de pruebas unitarias, tampoco perdemos de vista el costo de su mantenimiento y vamos adaptando el modelo según las necesidades y posibilidades.

Antes de ir directamente a la herramienta, repasemos algunas definiciones.

El ABC de las pruebas unitarias

Toda prueba unitaria que se precie de tal, deberá contar sí o sí con las siguientes características:

• Ejecución rápida
• Ambito limitado
• Automatizable y repetible
• Cualquiera puede ejecutarlo
• Independiente
• Alta cobertura de código

El ABC del TDD

En el Desarrollo Guiado por Pruebas (Test-Driven Development – TDD) se dice que no existe ningún motivo para escribir código salvo alguna prueba que esté fallando. Esto obliga (a modo de resumen) a trabajar con un ciclo de vida que incluye los siguientes pasos:

• Ante cada nuevo requerimiento, escribir un test. El test inevitablemente fallará porque no hay código que implemente ese requerimiento todavía.
• Escribir el código que pase el test. Se deben enfocar los recursos a que el test pase, sin preocuparse por cuestiones “superfluas” (.. del tipo “ya que estamos, agrego una sobrecarga que reciba tal parámetro porque probablemente lo necesite más adelante”). Tampoco por la elegancia del código. El único objetivo es que el test pase.
• Refactorizar: Es aquí donde se modifca el código para mejorar cuestiones como mantenibilidad, limpieza de código duplicado, etc., sin afectar obviamente la funcionalidad. Esto se comprueba corriendo sucesivamente las pruebas (aquí se ve el beneficio de pruebas que se puedan ejecutar en poco tiempo).

Entrando ahora sí de lleno en la herramienta, veamos qué nos aporta en este sentido.

Ayudas en la edición de código

Como soporte a la práctica de TDD, Visual Studio 2010 cuenta con algunas funcionalidades orientadas a la mejora en la productividad en este ámbito:

Code Snippets: permiten rápidamente generar clases de test (“testc”) o métodos de test (“testm”)

Al escribirse primero las pruebas, obviamente fallaran las referencias a las clases a testear, pero con la generación automática de código, se facilita la tarea de crear el esqueleto de esas clases:

Intellisense en modo Suggestion: En el modo al que estábamos acostumbrados a usar Intellisense (modo Completion), era fácil agregar una referencia a un tipo o variable existente, pero esto no es muy “TDD Friendly”. En VS2010 existe también el modo Suggestion (se activa con Ctrl+Alt+Space) que muestra, mientras estamos tipiando, un cuadro de texto sobre la lista de tipos sugeridos sin obligarnos a seleccionar ninguno.

Ejecución de pruebas unitarias

En cuanto a la ejecución de las pruebas unitarias, más allá de nuestro objetivo de ver muchos iconitos verdes, una de las metas buscadas es conseguir una alta cobertura de código. De nada sirve tener toda una batería de pruebas unitarias si estamos cubriendo (probando) menos de la mitad del código escrito.

La cobertura de código (Code Coverage) es una métrica importantísima que deberíamos obtener para poder certificar que nuestros casos de prueba están cubriendo la totalidad (o la mayor parte posible) del código de la aplicación.

Para habilitar los reportes de Code Coverage en VS2010 tenemos que modificar el archivo “Local.testsettings” y dentro de la opción “Data and Diagnostics” marcar el check correspondiente a “Code Coverage”

Una vez ejecutadas las pruebas, en la ventana Code Coverage Results, podremos ver los porcentajes de ese indicador y a su vez, en el editor de código, ver resaltadas las líneas afectadas por la prueba.

Posts anteriores de esta serie:

Para ir calentando motores …

Contribuyendo a la mejora de calidad de software

Algunas referencias más:

http://geeks.ms/blogs/adiazmartin/archive/2010/01/12/m-225-s-r-225-pido-con-visual-studio-2010-intellisense-para-tdd.aspx

http://blogs.msdn.com/b/ukvsts/archive/2010/03/17/test-driven-development-with-visual-studio-2010.aspx

Hasta la próxima!

El pasado 28 de Abril participamos como oradores con Victor Passador en el ALM BootCamp en Microsoft Argentina.

También participaron Juan Pablo Díaz, Maxi Accotto y Eric Delahaye.

Aquí les dejo los videos de las presentaciones y que las disfruten !

Apertura - Juan Pablo Díaz:

Control de Versiones - Daniel Laco:

Versionado de Base de Datos - Maxi Accotto:

Arquitectura - Eric Delahaye:

Testing- Victor Passador:

Como habíamos prometido, daremos inicio con este post a la serie de publicaciones con las que intentaremos mostrar de qué manera se puede incrementar la calidad del software que nuestra empresa produce, mejorando el proceso de testing en las diferentes formas que toma a lo largo del ciclo de vida de la aplicación.

Tipos de testing vs. herramientas de testing

En las primeras etapas del ciclo de vida de la aplicación, en aquellas donde se comienzan a implementar mayormente requerimientos no funcionales (APIs, frameworks, etc.), se requiere de un tipo de tester especializado, con altos conocimientos de programación, que genere casos de pruebas unitarias con un alto grado de automatización (cuando digo alto apunto al 100% de automatización)

A medida que las iteraciones avanzan y se empiezan a obtener las primeras piezas funcionales, aparece la necesidad de un testing totalmente diferente, opuesto, donde el tester necesita altos conocimientos del proceso de negocio y pocos o nulos conocimientos de programación.

Si trazáramos una línea, podríamos decir entonces que tenemos en una punta un testing de tipo “especializado”, con mayoría de casos de test automatizados construidos por expertos en programación, y en la otra punta un testing más “generalista” con gran cantidad de casos de test manuales a cargo de especialistas en el negocio en cuestión, con toda una escala de grises en el medio.

Según algunos estudios, se indica que la mayoría de las herramientas de apoyo al testing apuntan a la parte “especialista”, siendo que el grueso del esfuerzo que realiza la empresa se ubica en la parte “generalista”

VSTS 2010 como solución ALM ante la problemática del testing

Con este enfoque como guía, iremos mostrando en sucesivas entregas, de qué manera VSTS 2010 contribuye a la mejora del proceso de testing en todo el espectro.

Comenzaremos mostrando las herramientas que propone la solución de MS desde el extremo más especialista, hasta llegar al punto opuesto, abarcando los siguientes tópicos:

• Testing unitario y las mejoras para aplicación de técnicas de TDD (Test Driven Development)
• Intellitrace
• Coded UI Test
• Lab Management
• Integración Continua

Hasta la próxima !

El 28 de abril estarán participando Daniel Laco junto a Victor Passador como oradores en el evento que organiza Microsoft sobre la nueva versión de Visual Studio Team Foundation Server 2010, aplicado a todas las actividades de ALM.

Compartirán una tarde completa recorriendo las principales características de la última versión de Visual Studio Team Foundation Server 2010: Novedades Project Management, Version Control, nuevas herramientas de Testing, entre otras.

Este evento va a contar principalmente de Tracks Prácticos los cuales vas a poder seguir desde tu Notebook.

En http://bit.ly/fzKgTV pueden encontrar toda la agenda y el link de registración.

En la búsqueda diaria de la solución absoluta y definitiva a los problemas de gestión del código fuente, di con un post de El Bruno donde plantea algo muy simple pero efectivo:

1. Formación

    1.1 Conocer las capacidades de la herramienta

    1.2 Conocer la problemática del negocio

2. Tomar una decisión para comenzar a trabajar

3. Cada 6 semanas/meses ajustar la forma de trabajo

4. Goto 2

Según El Bruno, esto surge como conclusión de una Mesa Redonda con la gente de MadridDotNet donde se compartieron experiencias de administración de código fuente en cuestiones de branching, merge, archivos históricos, la maldición del checkout exclusivo y otras cuestiones.

Recomiendo su lectura, es un post cortito y ameno.

Hasta la próxima !

Ayer 2 de Marzo realizamos exitósamente el evento de ALM (Application Lifecycle Management) sobre TFS.

La jornada se desarrolló en las instalaciones del MUG.

La sala estaba completa, y la inscripción se completo varios días antes de las charlas.

Se pueden bajar las presentaciones aquí

Estamos preparando una serie de post dedicados a testing con VSTS 2010 en las diferentes variantes en que se presenta a lo largo del ciclo de vida de la aplicación, y para ir introduciendo el tema quisiera dejarles unos links para que tengan a mano.

Se trata del blog de Mathew Aniyan, PM de Microsoft. En su blog, Mathew ha estado publicando una serie de Tips relacionado a lo que se conoce como Coded UI Test (Pruebas programáticas de Interfaz de Usuario).

Al momento de publicar este post, llegó hasta el N° 8, posteado con fecha enero/2010. Esperamos que retome la iniciativa y siga publicando más trucos.

Pueden ver la serie de tips aquí.

Saludos !

ALM Day 1 – Buenos Aires

El 2 de Marzo se realizará en el auditorio del MUG la primera jornada de ALM (Application Lifecycle Management), donde Vemn Sistemas participará como orador.

El evento es organizado por el MUG y Microsoft, donde el objetivo es exponer ante la comunidad técnica el uso de Team Foundation Server (TFS) 2010 como solución ALM para la integración de roles. Está dirigida a Analistas de negocios, Analistas Funcionales, Arquitectos, DBAs, Desarrolladores, Testers, etc.

Temario:

\      ¿Cómo cambiar la cultura de una organización? (Patricia Scalzone)           

\      Administración de Proyectos con TFS 2010 (Eric Delahaye)

\       Integración de proyectos de Base de Datos al desarrollo (Maximiliano Accotto)

\       Mejora de la calidad del software con manejo de versiones en TFS 2010 (Guadalupe Casuso – Juan Pablo Díaz)

\      QA & Testing (Victor Passador)

\      Administración de Requerimientos usando Sharepoint (Alan Sheinkman)

Es una jornada gratuita.

Más información e inscripción en MUG