1

Director /EditorC. Marcelo Cusmai

Diseño y DiagramaciónStabilitas

Artículos y redacciones – Agosto Alfonsina MorgaviRicardo Colusso Juan GabardiniEzequiel BazanAlejandro Zuvic

Colaboraciones y FuenteGerardo Prieto

Pablo Rodríguez

Traducciones Sergio E Cusmai

Sitio Webwww.infotesting.com

EditorialPor C Marcelo Cusmai

.

El tester es en su labor profesional un cazador de Bugs por excelencia, y como tal debe ser cuidadoso al momento de seleccionar las herramientas adecuadas. Al igual que el cazador, una mirada oportuna debe permitir al especialista seleccionar con el criterio adecuado y evitar disparar al mosquito con un cañón. La optimización de inversiones también se manifiesta en la certera preparación de herramientas y ambiente de pruebas. Con el paso del tiempo y las especializaciones cada vez mas necesarias, han surgido nuevos elementos que caracterizan al Tester de Software Profesional, y de este modo, un tester especializa su perfil en determinadas actividades.

Entre las distintas especialidades de los testers, en los últimos años, el automatizador ha ocupado un espacio de gran importancia. Como bien sabemos, no todos los aspectos de las pruebas son automatizables sin límites, pero es una realidad que las automatizaciones han llegado al contexto de las pruebas de software para quedarse y evolucionar.

Las automatizaciones se han convertido en especialidades cada vez mas utilizadas, y en muchos casos aunque no se utilicen cotidianamente, conocer y saber automatizar se ha transformado en una capacidad con un gran valor diferenciador para el perfil del tester. En esta entrega recorremos, estilos, estrategias, valores como la credibilidad, automatizaciones, herramientas y eventos internacionales de gran nivel.Espero disfruten de una propuesta escrita que ofrece un espacio de intercambio sin limites para la especialidad de la “Calidad de Software”.

¡¡Muchas gracias por la oportunidad de presentar “Infotesting”!!

2

InfoTesting - Agosto 2012Desarrollo Ágil de Software ……………………………………………………….Pag 6

Jornadas Latinoamericanas de Metodologías Ágiles……………………………………………………………......…………………Pag 15

La credibilidad, un valor insustituible…………………………………………….Pag 18

Una formación Gratuita para Automatizar……………………………………………………………………………Pag 22

Proceso de Automatización...........................................…………………………Pag 24

Conferencia Internacional…………………………………………………….….…Pag 26

3

4

Este artículo contiene los principios básicos del Desarrollo Ágil de Software, y un recorrido por las distintas formas de realizarlo. Esperamos que esta información te permita decidir sobre la aplicabilidad de esta forma de trabajo a tus necesidades y contexto, y a partir de allí, seguir investigando y aprendiendo. Para este caso te indicaremos referencias a material para profundizar en los distintos temas incluidos.

Desarrollo Ágil de SoftwarePor Ricardo Colusso y Juan Gabardini

Desarrollo del SoftwareEl desarrollo de software es una disciplina que todos relacionamos en forma directa con el progreso, las mejoras en la productividad, y mucha gente inteligente trabajando duro y generando importantes beneficios para las empresas y toda la sociedad. Pero al mismo tiempo observamos que muchas veces los proyectos sufren retrasos y no se obtienen los resultados esperados pese al talento y esfuerzo puestos en acción por parte de analistas, programadores y usuarios para que “el nuevo sistema” funcione correctamente en tiempo y forma.¿Por qué tantos proyectos de desarrollo de software no se terminan a tiempo, cuestan más que lo presupuestado originalmente, tienen problemas de calidad serios y generan menor valor que el esperado?Este interrogante fue uno de los que se formularon los 17 profesionales expertos en el desarrollo de software cuando se reunieron en febrero de 2001 para analizar el problema y decidieron redactar un “Manifiesto Ágil”. Se trató de un compromiso público en buscar nuevas y mejores formas de desarrollar software poniendo énfasis en las personas y sus interacciones, la colaboración y la respuesta continua al cambio, explorando nuevas formas de hacer las cosas, y compartiendo experiencias — dando origen a una nueva comunidad de profesionales que explora sistemáticamente nuevas alternativas frente al modo tradicional de desarrollar software. http://agilemanifesto.org/iso/es/

Desarrollo “tradicional” de softwareLa forma tradicional de desarrollar software se basa en procesos predefinidos con documentación muy precisa, y una detallada planificación inicial que debe seguirse estrictamente. Esta forma de trabajar surgió naturalmente hace unos cincuenta años como una adaptación del manejo de proyectos de ingeniería, que era lo más parecido a desarrollar programas que se conocía en ese momento, y funcionó

razonablemente bien en un comienzo. También es necesario tener en cuenta que los ordenadores era enormemente caros, la mayor parte de la inversión informática se la llevaban los equipos y por esta razón los programas se hacían a medida para unas máquinas que se adquirían, no lo olvidemos, para realizar unas tareas muy concretas.Pero los proyectos de desarrollo de software en la actualidad incluyen desafíos muy diferentes a los que se presentan al construir puentes y casas, por lo que no sorprende que los métodos tradicionales de desarrollo de software estén en crisis.Tradicionalmente los proyectos se dividen en etapas bien diferenciadas: Análisis de Factibilidad, Análisis de Requerimientos, Diseño, Programación, y Testeo. Generalmente se trata de que haya retroalimentación (feedback en inglés) entre las etapas contiguas, de tal forma de que, por ejemplo, haya un momento en que se mejoren los Requerimientos en base a comentarios, sugerencias y necesidades de los responsables del Diseño. Sin embargo, esta forma de desarrollar software genera muy serios problemas, debido a que al comienzo del proyecto, que es cuando menos se conocen las características del problema que resolver, se toman las decisiones de mayor relevancia e impacto en el resto del proyecto.Como las chances de tomar decisiones erróneas al comienzo del proyecto son generalmente mayores al principio de un proyecto que cuando ya se ha trabajado un tiempo, suele ocurrir que los proyectos desarrollados siguiendo el método tradicional no cumplen sus objetivos, no se terminan a tiempo, y resultan mucho más caros que lo presupuestado. En particular, esto ocurre con mayor frecuencia en los casos en que el grupo de desarrollo necesita crear algo totalmente nuevo o de características específicas que nadie ha creado aún . . . lo cual es cierto para la mayoría de los proyectos de software! , porque en caso contrario, la organización compraría directamente un producto o sistema ya desarrollado anteriormente por otros.

5

Como propuesta de solución a estos problemas han surgido una serie de “métodos ágiles” de desarrollo de software y manejo de proyectos en general, y cuyas principales características mencionaremos a continuación.

Características del Desarrollo ÁgilEn los proyectos con Desarrollo Agil se busca que todos los esfuerzos se empleen en la creación del mejor software que satisfaga las necesidades del cliente. Esto significa que todos los que forman parte del equipo de trabajo se concentran únicamente en tareas y procesos que agregan valor al cliente del producto que se está creando, mejorando o implementando. Adicionalmente, los usuarios o clientes reciben periódicamente prototipos o versiones en funcionamiento del producto a medida que se va construyendo, lo cual les permite evaluar el trabajo realizado, advertir sobre problemas que se detecten, y sugerir mejoras o funcionalidad valiosa que no se había considerado originalmente (ya sea por olvido, o porque la nueva funcionalidad se inspira en la experiencia de evaluar el producto mientras se está construyendo)La distinción entre las tareas relevantes y los que no agregan valor se consigue a través de la creación de contextos con alto nivel de empowerment y feedback.El empowerment consiste en otorgar autonomía para tomar decisiones al equipo de desarrollo, y genera un clima de sinergia grupal que permite al grupo avanzar a pesar de las complicaciones y dificultades que ocurren habitualmente en los proyectos –de allí que uno de los métodos de trabajo más populares se haya bautizado con el nombre “scrum”, ya que la imagen de los jugadores de rugby empleando su energía en avanzar todos juntos es muy aplicable a los equipos de trabajo que utilizan esta metodología.El feedback constante y presente en varios niveles permite el desarrollo incremental y el crecimiento adaptativo de la programación, así también como una mejora constante en la forma de trabajo de los equipos, lo que permite detectar problemas y resolverlos antes de que desaten crisis que afecten la calidad o el tiempo y costo del desarrollo. Los principales tipos de feedback ocurren a nivel producto, procesos y código.Periódicamente el cliente evalúa el estado real del software que se está creando, lo que asegura que lo entregado al final del proyecto coincidirá con lo esperado. Esto se consigue a través de un desarrollo incremental: el producto puede probarse desde las primeras semanas y meses del proyecto al menos en cuanto a su funcionalidad más básica, que luego va

creciendo y mejorando –es por esto que se dice que desde el comienzo el producto ya tiene dentro su ADN, del mismo modo que ocurre con la gestación de los seres vivos en la Naturaleza.A nivel procesos se realizan frecuentes reuniones retrospectivas donde los integrantes de los equipos comentan y discuten en profundidad tanto sus aciertos (para poder repetirlos y convertilos en hábitos), así también como el trabajo que no se realizó correctamente o no llevó al equipo a obtener los resultados esperados.Adicionalmente los desarrolladores suelen trabajar mucho en equipo y también por parejas, revisando juntos el código y resolviendo problemas en lugar de tratar de cubrirlos, lo que repercute en un producto de mejor calidad, mejor documentado, y simple de mantener.

Juan Gabardini es Ingeniero Electrónico y Licenciado en Sistemas egresado de la Univ. de Buenos Aires (FIUBA), PMP, Certified Scrum Master y Auditor Interno ISO 9000. Es miembro del IEEE (Tesorero de Capítulo Argentino de la Computer Society), Scrum Alliance y Agile Alliance, y miembro del comité organizador de Ágiles 2008 y de los eventos Agile Open (www.agiles.org). Es Jefe de Trabajos Prácticos de Administración y Control de Proyectos Informáticos II en FIUBA, con 10 años de docencia universitaria, y consultor independiente, con 20 años de experiencia en desarrollo de productos de software, administración, enseñanza y consultoría en Tecnologías de la Información, en sector financiero, retail, telecomunicaciones, manufactura y equipos médicos.Como miembro de Agilar realiza capacitaciones, coaching y consultoría de administración, calidad y desarrollo en ambientes de desarrollo de software ágil, ayudando a empresas a generar más valor de negocio a través de la adopción de formas de trabajo ágiles. Recientemente ha dictado charlas, presentación de trabajos y cursos sobre métodos de desarrollo ágil en Intel Argentina, Microsoft Chile, Microsoft Argentina, SEPGLA 2007, IEEE Argentina, INTI Bs As, Córdoba y Mendoza y Polo Tecnológico Rosario, entre otros.

Ricardo Colusso es Licenciado en Sistemas egresado de la Univ. de Buenos Aires, M.B.A. (orientación en Negocios Internacionales) de Lynn University-Estados Unidos, miembro de Agile Alliance, y de la Comunidad de Desarrollo Agil de Latinoamérica (www.agiles.org).Es consultor especializado en Product Management y Manejo Ágil de proyectos, con amplia experiencia en la definición y desarrollo de productos de software. Su trayectoria incluye 10 años de trabajo como Product Planner Internacional en el grupo de desarrollo de MS Office en Microsoft Corporation, y la aplicación de técnicas modernas de investigación de mercado y necesidades de usuarios y sus organizaciones en varios países de Latinoamérica y Europa. También realiza investigaciones y publica trabajos sobre métodos y herramientas para acelerar el nivel de creatividad e innovación en grupos y organizaciones, y coordina talleres de innovación en empresas y pequeñas comunidades.

6

Por qué y cuándo conviene usar Desarrollo Ágil de Software.Entregas incrementales: Producto y ProyectoVamos a comparar la forma en que se planifican los proyectos con la forma en que se planifican los productos, intentando extraer algunas conclusiones.

Cono de la incertidumbreBoehm (COCOMO 2) y Steve McConnell (Rapid Development) indican que cualquier variable x del proyecto, por ejemplo costo o esfuerzo, estimada al principio de un proyecto variará entre 4x y 0,25x. A medida que se avanza en el proyecto, se conoce más y se reduce al error, hasta llegar a la certeza, pero sólo cuando el proyecto finaliza.

Proyectos Los proyectos surgen en la década del ’50 como una manera de organizar los desarrollos contratados por el Departamento de Defensa (DoD) y otros organismos de gobierno de EEUU. Los casos emblemáticos son el desarrollo de los submarinos Polaris y el programa Apollo. De estos ambientes surgieron técnicas como PERT/CPM, y el Earn Value.En general se plantea el proyecto a partir de un pedido de propuesta (en inglés Request for Proposal o RFP) que define con precisión lo que se desea (o intenta hacerlo) y oferentes proponen el costo y tiempo necesario para realizar lo pedido (o intentan hacerlo). Ambos participantes se tratan de proteger de la incertidumbre (ver Cono de Incertidumbre) por medio extensos análisis iniciales de la situación, buffers, contratos. La parte requeriente espera transferir el riesgo al proveedor, por medios contractuales, pero en caso de un proyecto que se excede en sus tiempos o costos, ambas partes pierden (lose-lose), ya que si el cliente realmente necesitaba el resultado del proyecto para su negocio, no lo va a tener en el tiempo y costo estipulado. Esto lleva a una bola de nieve en la que cada vez se dedica más tiempo a la etapa inicial de estimación y negociación de contrato –lo que no aporta valor y ocasiona proyectos más caros.

En general se define a los proyectos como un esfuerzo limitado en el tiempo para lograr un objetivo (producto/servicio) único.

Esto es consistente con el origen, el cliente contrata un desarrollo, y el proveedor cumple con lo solicitado por el cliente en el RFP, no teniendo responsabilidad sobre la operación y mantenimiento del producto.

Debe notarse que el producto del proyecto genera valor de negocio durante su operación, por lo que el cash flow de un proyecto que genere producto sólo al final.

El momento en que mayor conocimiento podemos llegar a obtener es cuando el producto está finalmente siendo usado por el usuario. Para ese momento, el presupuesto ya está completamente consumido, y sólo para recuperar lo invertido necesitamos tres meses de operación.

ProductoLos productos tienen un ciclo de vida que incluye:

Concepto inicial Planificación del producto: investigación

(necesidades de los clientes, competencia, tecnologías disponibles, situación del mercado), visión y funcionalidad.

Definir release(versión): fechas y contenido Construir: programación, prueba,

documentación Vender / operar / soportar Obtener feedback de clientes / operación y

volver a planificar Retirar del mercado

7

Los productos exitosos generan ingresos que permiten desarrollar las siguientes versiones. En caso de un producto no exitoso, se descarta el producto sin haber invertido tanto dinero.

Las empresas, para tener éxito, tienen que desarrollar productos con las características que necesitan sus clientes. Pero las más exitosas son las que continuamente exceden las expectativas de sus clientes, que no incluyen características innecesarias y que liberan producto en forma rápida. Más adelante analizaremos cada uno de estos puntos.

Beneficios de usar Desarrollo ÁgilLas mejoras obtenidas por usar Desarrollo Ágil dependen de la situación. Por ejemplo, Scrum no define prácticas técnicas (cómo hacer las cosas), en cambio los beneficios obtenidos surgen de brindar visibilidad, lo que facilita encontrar las áreas de mejora, y un marco de trabajo de mejora continua, en el que se priorizan las mejoras según la necesidad del negocio.

Pero hay algunas mejoras que típicamente se obtienen con Desarrollo Ágil:

Desarrollo guiado por valor Mejor manejo de riesgos e incertidumbre Mejora de productividad

Desarrollo guiado por valorEn muchas situaciones con los sistemas se presenta una relación de Pareto, en la cual un 20% de la funcionalidad provee un 80% del valor. Si organizamos el proyecto de manera que el cliente reciba ese 20% de funcionalidad lo antes posible, empezará a recibir el valor del resultado del proyecto antes. Esto puede hacer que incluso se replantee la necesidad o cambie la definición del resto del proyecto.Con esta idea en mente, se organiza el proyecto de manera de entregar producto funcionando en intervalos cortos, y modificar la dirección del proyecto basados en lo aprendido. Esta es una de la aplicaciones el concepto de Inspeccionar y Adaptar, que se utiliza también en otras áreas de Scrum. Para lograr estas ventajas se requiere tanto de cambios internos en el equipo (a las funcionalidad menos prioritaria se le dedica muy poco o ningún esfuerzo),

como en el cliente (acepta y promueve una forma contractual que posibilite ajustar el contenido del producto, sin grandes costos para ninguna de las partes). Esta situación es particularmente notoria en caso de proyectos complejos, según la definición de complejo que se da a continuación.

Mejor manejo de riesgos e incertidumbreCuando encaramos proyectos, intentamos planificar la ejecución para lograr minimizar los riesgos y utilizar los recursos de la manera más eficiente posible. Por ejemplo, si estamos desarrollando un producto que será puesto en producción con equipos (servidores) que deben adquirirse, es necesario que dimensionemos el equipo necesario con uno o dos meses de anticipación, para poder asegurar que estará disponible (comprado, entregado, instalado, configurado) para el momento en que se necesite. Esto puede modificar como organizamos el trabajo, ya que sin esa restricción, probablemente lo ideal sea esperar hasta tener una prueba de performance con el producto completamente desarrollado.

Pero la planificación requiere que podamos identificar la lista completa de tareas que debemos realizar, a un nivel suficiente como para ser estimadas con un nivel de confianza suficiente. Esto es difícil en algunos contextos, en los que los requerimientos sean poco conocidos o el ambiente de negocio es nuevo o muy cambiante, o en el caso de tecnología no conocida por el equipo o aún inmadura. En estos casos, estamos en el área marcada como (proyectos) Complicados o Complejos, y en ese caso, el balanceo entre planificar y no planificar se corre hacia menos planificación.

El Desarrollo Ágil Scrum permite planifica con dos niveles de detalle, en el alto nivel (Releases), planteamos necesidades de negocio, pero no podemos comprometer alcance detallado, mientras que en el bajo nivel (Iteraciones / Sprint) comprometemos alcance, pero fijamos algunas condiciones de contexto. Adicionalmente, el concepto de Inspeccionar y Adaptar, presente en el punto anterior, también aporta para manejar mejor los riesgos existentes en los contextos Complejos.

8

Mejora de productividadDesde hace tiempo se sabe que distintos equipos pueden tener diferencias de productividad de 10 a 1 o incluso más. Entre las empresas de peor productividad y el promedio de la industria hay un orden de magnitud de diferencia, mientras que entre el promedio y los más productivos hay dos órdenes de magnitud de diferencia.Analizando las razones de estas diferencias, autores como [DeMarco&Lister] o Watts Humprey han encontrado que la forma de trabajo (cultura, entorno físico, forma de liderazgo y toma de decisiones, etc) tiene un papel preponderante. En el Desarrollo Ágil se incorpora la autoorganización, el liderazgo facilitador, el trabajo en equipo, la transparencia, los grupos pequeños y otras condiciones que habilitan al equipo para mejorar su productividad. Ejemplos como el equipo de Borland Quattro (anterior al desarrollo de Scrum y XP), un caso bien documentado de alta productividad, indican el techo de mejora (si existe) es alto. [Coplien&Harrison]

Aplicabilidad del Desarrollo Ágil

Una duda que surge cuando se evalúa utilizar Scrum es si aplica en el contexto particular del interesado.Con las consideraciones indicadas arriba sobre contextos más o menos favorables para la implementación de Scrum, se puede afirmar que Scrum ha sido aplicado con éxito tanto en empresas o equipos pequeños (con dos ejemplos comentados más abajo) como en equipos medianos (Primavera) y grandes (SAP, Google, Yahoo!).Con respecto a los tipos de aplicaciones, ha sido aplicado en equipos médicos con riesgo de vida que requieren aprobación de FDA (Rayos X, MRI), como en manejo de pagos electrónicos, sistemas de alta disponibilidad, de alto volumen, etc.Aunque lo más recomendado es que los equipos

trabajen en un único lugar físico, Scrum ha sido usado por equipos distribuidos y con subcontrataciones.Scrum ayuda en la obtención de un nivel 3 de CMMI, y produce mejoras aún en niveles superiores. Habiendo sido aplicado a una empresa CMMI nivel 5 se duplicó la productividad y se disminuyó en un 38% la cantidad de defectos detectados en el test final.

Comparación entre la visión de Producto y la de ProyectoMuchas empresas han tomado el modelo de procesos como la forma en que se comunican los sectores internos, cada uno de ellos tomando el rol de cliente o proveedor, con una comunicación entre ellos más asociada el modelo contractual de los Proyectos que

al la forma evolutiva y focalizada en el cliente de las empresas de desarrollo de producto.Es frecuente que estas empresas tengan áreas que son optimizadas localmente, y que se relacionan con otras áreas a través de “contratos llave en mano”.

Una forma alternativa de trabajar para desarrollo interno usando el modelo de desarrollos de productos, considerando que el mismo equipo se mantiene a lo largo de varias versiones, teniendo que dar soporte al usuario actual. Esto podría ayudar a que el equipo obtenga feedback del cliente y que incorpore ese feedback en próximas versiones.

Métodos, Prácticas y Herramientas

ScrumScrum es un de los métodos ágiles más

populares en todo el mundo ya que funciona muy bien en situaciones en que las necesidades no están definidas completamente y sabemos que pueden cambiar. Su éxito ha llevado a extender su aplicación fuera del ámbito del software. En su aplicación al desarrollo de software se suele complementar con XP.Para esta introducción, nos pareció lo más apropiada la breve descripción que hace Tobias Mayer.

En el Desarrollo Ágil se incorpora la autoorganización, el

liderazgo facilitador, el

trabajo en equipo, la transparencia, los grupos pequeños y otras condiciones que habilitan al

equipo para mejorar su

productividad.

9

Scrum Simple [Tobias1]Creo en Scrum como algo casi imposiblemente simple que con frecuencia se vuelve complicado. Es el exceso de complicación que tiende a causar tanto mal entendido, lo que lleva a una aplicación deficiente. La siguiente descripción de Scrum intenta capturar el espíritu de la simplicidad.Scrum es un marco para mejorar la forma en que las personas realizan su trabajo, o como se define en el sitio Scrum Alliance “un marco basado en el equipo para desarrollar sistemas y productos complejos”. Scrum utiliza un proceso iterativo donde se mantiene cada iteración (también conocido como Sprint) lo más corta posible, manteniendo a un ritmo parejo en el paso por la planificación, la ejecución y la reflexión. El aspecto estricto, rítmico y de tiempo fijo de Scrum proporciona una extraña habilidad para descubrir la disfunción de la organización.Scrum especifica tres roles (Scrum Master, Dueño del Producto y Equipo), requiere de un conjunto priorizado de objetivos, un compromiso en cada iteración, y una forma sencilla de medir el progreso.Se mantiene una distinción clara entre el “Qué hay que hacer” (el objetivo) y el “Cómo hacerlo” (el camino). Scrum requiere foco, compromiso y transparencia a todo nivel; adopta y enfatiza entre otros los valores humanos de la confianza, la integridad, el coraje y el respeto.RolesEl Scrum Master es un líder servicial para el equipo, y un agente de cambio dentro de la organización. El Dueño del Producto es la voz del cliente, establece una visión sólida y prioriza continuamente para para alcanzar dicha visión. El equipo es un grupo auto-organizados, multi-disciplinario y con autonomía que hacen el trabajo. ArtefactosSe mantiene una lista de pedidos u objetivos pendientes. Contiene todas las cosas que (pensamos) el producto o servicio tiene que hacer, actualizada en todo momento. Es una lista “viva” que constantemente es revisada y priorizada. Sus ítems siempre se centran en el “Qué”. El compromiso de la iteración es un subconjunto de esa lista, a veces dividida en las tareas que describen el “Cómo” del producto. Scrum require métricas simples, tales como medir el trabajo que resta hacer, o el valor de negocio que ya fue entregado. Estas métricas deben usarse para medir lo que realmente ocurrió –sin medir éxito o fracaso. Caso contrario, las métricas pueden llevar al equipo a realizar arreglos rápidos

pero no efectivos para el futuro.CeremoniasEl Equipo y el Dueño del Producto se reúnen antes del inicio de cada iteración para planificar el trabajo. El Equipo se compromete a los temas prioritarios de trabajo que tienen “los resultados bien formado” (el objetivo) y se espera que entreguen el producto que cumpla dichos objetivos al final de la iteración. Cómo hacen su trabajo (el camino) solo les incumbe a ellos. Cada día los miembros del equipo se reúnen alrededor de un tablero de indicadores visuales (por ejemplo un tablero de tareas) para alinearse entre ellos, pedir y ofrecer ayuda. Al final de cada iteración el trabajo realizado es examinado por los interesados y los consumidores, y se sugieren adaptaciones. Tras la revisión, los miembros del equipo reflexionan sobre su proceso, buscando formas de mejorar y toman compromisos para cambiar. Cada iteración produce un producto o servicio mejor y un equipo mejor y más feliz.Esto es más o menos la descripción de Scrum que estada desde que el primer libro de Scrum se publicó en 2003. Lo he sacado de su contexto de software, abandoné algunos términos con el fin de mantener la atención en los principios subyacentes y tratado de condensar a su esencia. No agregué ni quita nada.

Roles [Tobias2]Hace poco escribí un artículo titulado Scrum Simple en el que intento describir Scrum de forma independiente de la industria. No estaba satisfecho reteniendo los nombres de los roles de Scrum, ya que parecen ser demasiado específicos de la industria o al menos están cargados de significado específico al uso (a menudo insuficiente) actual. Al considerar Scrum totalmente agnóstico de la industria, llego a la esencia de los roles.

Roles en el Scrum agnóstico1. La Voz del QuéUna sola voz, posiblemente canalizando muchas voces, con el objetivo de definir los “resultados bien formados” y priorizar para lograr el valor más elevado posible en el contexto dado. La Voz del Qué es también responsable de los gastos y cualquier decisión sobre seguir o no.

10

2. La Tribu del CómoUn grupo multidisciplinario de 3-7 personas que entre todos poseen todos los habilidades necesarias para resolver los problemas planteados por la Voz del Qué. Los miembros de la Tribu tienen autonomía en la toma de decisiones sobre como hacer el trabajo, pidiendo claridad y apoyo de la Voz del Qué cuando es necesario.3. El AnimadorUn facilitador neutral con respecto a los resultados, ocupado en fomentar un entorno de colaboración, guiando a la tribu hacia la auto-mejora y auto-suficiencia, y cuestionando a la organización que los contiene para liderar a través de la libertad y el honor, en lugar del control y la desconfianza. El Animadoractúa como un servidor para el equipo, y un agente de cambio dentro de la organización en general.Estos tres roles constituyen el Equipo Scrum, es el empuje en tres direcciones diferentes: beneficio, maestría y el bien mayor, que genera el conflicto saludable y la tensión necesaria para alcanzar niveles nunca antes imaginadas de la innovación y la creatividad, y permite a los equipos Scrum entregar verdadero valor.Hay un cuarto rol en Scrum, fuera del equipo, pero involucrado a intervalos regulares. El rol es esencialmente todos los demás a quienes les importa.

4. La AudienciaTodos los que financian, usan o se benefician del producto, servicio o idea que se está creando. La Audiencia da comenta a intervalos regulares y debe contener entre ellos un puñado de críticos serios.

El Qué es el destino, el Cómo es el caminoLlamar al primer rol la Voz del Qué y al segundo la Tribu del Cómo al instante separa los dos aspectos de la creación. Para que la auto-organización funcione un equipo (o tribu) debe tener autonomía, no ser molestados y se debe confiar en ellos. La confianza es difícil cuando los requerimientos son vagos, y la autonomía es imposible cuando la tribu experimenta continuas interferencias con respecto a las tecnologías, herramientas y prácticas que se utilizan.Necesitamos una clara separación entre lo que se pide – esencialmente un objetivo: un resultado de valor- y el camino que tomará para llegar allí. La gente en el final del negocio del proceso creativo necesidad de definir objetivos claros, que describen la audiencia y el valor. Ya que no probablemente no estén desarrollo las soluciones ellos mismos, necesitan salirse del medio del camino de la

solución, salvo que se los invite explícitamente.Viendo a los roles de Scrum de esta manera agnóstico nos permite ver los principios y valores en los que los roles deben operar para tener éxito. Es muy fácil quedar atrapado en las decisiones del día a día de la implementación, y perder de vista el propósito general.

XP (Extreme Programming)Es uno de los procesos ágiles más populares. A diferencia de Scrum y Kanban, incluye prácticas y recomendaciones técnicas, por lo que no es fácilmente aplicable fuera del software.En muchos casos se considera que las prácticas de XP son un complemento necesario para cualquier equipo que utiliza Scrum para el desarrollo de software.

ObjetivoDado que las necesidades y requerimientos cambian siempre, no es razonable organizar nuestro desarrollo de software tratando de minimizar los cambios. La única razón por la que tratamos de minimizarlos, es debido al costo creciente de los mismos.Un objetivo de XP es lograr que el costo de cambios sea constante en cualquier momento del desarrollo del software. Esto nos permite acepta más fácilmente los cambios, y lograr mejores productos.

DescripciónFue inicialmente descripto por Kent Beck por medio de 5 valores: simplicidad, comunicación, retroalimentación, coraje y respeto, y 12 prácticas: Reunión de Planificación#, Pequeñas entregas, Pruebas de Aceptación del Cliente, Diseño Simple, Programación de a Pares, Desarrollo guiado por las pruebas (TDD), Refactoreo, Integración continua, Propiedad compartida del código, estándares de codificación, Metáfora y Ritmo sostenible.Hay puntos fuertes de contacto con Scrum, tanto en los valores, como en las prácticas no técnicas. Por ejemplo, Reunión de Planificación, Pequeñas entregas, Pruebas de Aceptación del Cliente y Ritmo sostenible son prácticas utilizadas en Scrum.Las prácticas se complementan unas a otras, por lo que aunque se empiece con alguna de las prácticas, hay una tendencia a ir incorporando las faltantes. Algunas de las prácticas han sido aceptadas como buenas prácticas de la industria, por lo que se describen por separado (Desarrollo de a Pares, TDD e Integración continua).

11

Desarrollo de software LeanMétodo ágil propuesto por Mary y Tom Poppendieck por primera vez en 2003, el desarrollo de software Lean consiste en aplicar al desarrollo de software los principios del sistema de producción que la empresa Toyota introdujo con gran éxito en la industria automotriz durante las décadas de 1970 y 1980.

En este modo de desarrollar software toda tarea apunta a la entrega de valor, y no debe hacerse nada que no añada valor al proyecto o producto. Para esto se le da al equipo la autoridad para evitar y eliminar cualquier “desperdicio” tal cómo funcionalidad o arquitectura innecesarias, reuniones redundantes, líneas de código que no se ejecutan, retrasos y burocracia en general.

Adicionalmente se propone una forma de trabajo enfocada a la calidad total del software entregado y la mejora continua de los procesos. Para esto se aplican los principios just-in-time (JIT) a la toma de decisiones y todos los integrantes del equipo de desarrollo comparten una visión global e integral del sistema que están creando.

KanbanEs un método de gestión ágil de proyectos que propone reducir el trabajo en proceso o WIP (Work In Progress) para obtener en el equipo de desarrollo de software un estado de flujo que maximice la productividad del equipo y calidad del software entregado. Además permite detectar problemas, impedimentos y demoras muy rápidamente, estimulando la mejora continua.

Pair Programming (Programación de a Pares)Es una técnica ágil en la que se programa de a dos: mientras uno escribe el código, el otro observa, comenta, revisa y propone ideas –y luego de algunos minutos ambos intercambian posiciones.

El trabajo de a pares generalmente mejora la calidad del código, aumenta el sentido de cohesión del equipo la responsabilidad compartida en el resultado final. Además permite elevar el nivel de todo el equipo cuando profesionales experimentados comparten tareas de programación con otros.

También se ha comprobado que al utilizar Pair Programming correctamente se reducen las interrupciones y los programadores tienen mayores lapsos de tiempo de alta productividad (estado de flujo).

TDD – Test-Driven DevelopmentEste método ágil da vuelta al desarrollo tradicional, ya que el trabajo a realizar es especificado iterativamente por la forma en que se lo va a probar, teniendo que superar tests cada vez más detallados y completos.

De esta forma, el equipo de desarrollo debe escribir en cada iteración el código necesario para superar as pruebas que se definieron para esa iteración –y ni una línea más!– reduciendo en la práctica la complejidad del código, y eliminando desperdicio.

Proceso continuoLos procesos actuales de desarrollo del software incluyen la idea de iteración (RUP, TSP, Ágil). Una buena práctica para lograrlo es construir de una versión diaria del producto (Daily build [McConnell]), pero ¿por qué hacerlo una vez al día? Esto implica que el equipo recibe información sobre la salud del producto y de la integración sólo una vez al día.Podemos hacerlo mejor:

Integración Continua: el código es integrado y probado cada vez que se modifica el repositorio de código. Esto implica que tenemos pruebas automatizadas (lo tenemos como subproducto de TDD) y un fuerte foco en que el producto siempre esté en estado estable. También debems tener automatizada la creación de la versión (compilación si corresponde) y la instalación.

Pequeñas entregas: estar siempre estable se logra con el Diseño Simple, y construyendo por pequeños incrementos o pasos de bebé. Esto habilita y es requerido por la idea de entregar frecuentemente al usuario versiones continuamente mejoradas del producto.

Refactoreo: considerando la necesidad Pequeñas Entregas y Diseño Simple, en poco tiempo podemos tener un producto con un arquitectura caótica e inmantenible. Esto debe ser evitado con reescritura del código para mejorar el diseño, por ejemplo reusando partes comunes, eliminando código redundante o no usado, aplicando patrones de diseño que simplifiquen, o que agreguen flexibilidad sólo cuando es necesaria. Esta práctica es posible gracias a la existencia de pruebas automatizadas. Las prácticas relacionadas con el proceso continuo han excedido el Desarrollo Ágil y se utilizan actualmente en cualquier entorno de desarrollo de software.

12

Transparencia y visibilidadEn un equipo de Desarrollo Ágil se debe lograr que todos tengan acceso fácil a la información que necesitan para tomar decisiones. Una de las formas de lograr estos objetivos es implementar tableros con información visual que estén en el ámbito de trabajo del equipo, de manera que no se deba hacer una acción especial para acceder a la información. La construcción de estos tableros es sencilla, pero por otro lado, dedicándoles un poco de tiempo se los puede mejorar mucho. Una fuente de ideas para esto se pueden buscar en el blog de [Xavier Quesada Allue]

¿Cómo seguir?

ComunidadLa Comunidad Latinoamericana de Desarrollo Ágil de software organiza eventos y actividades destinados a difundir las prácticas y métodos ágiles en Universidades, Polos Tecnológicos y Empresas. También sus integrantes forman parte de grupos virtuales y escriben en blogs y wikis acerca de sus experiencias.

Para mayor información, visitar el sitio de la Comunidad Latinoamericana de Desarrollo de Software en www.agiles.org, en particular la página de Sitios Relacionados.La lista de correos ‘oficial’ de la comunidad es http://tech.groups.yahoo.com/group/foro-agiles

BibliografíaMaterial utilizadoEl material incluido, salvo que sea explícitamente indicado, fue desarrollado por los autores,en algunos casos fueron escritos para otros contextos:

Proyectos y Productos, por Juan Gabardini para la materia Adminstración y Control de Proyectos II de la Facultad de Ingeniería de la UBA (http://materias.fi.uba.ar/7546).

El siguiente material es usado con permiso[Tobias1] http://agileanarchy.wordpress.com/2009/09/20/simple-scrum/ obtenido el 30 /11/2010[Tobias2] http://agileanarchy.wordpress.com/2009/10/08/scrum-roles-an-abstraction/ obtenido el 30 /11/2010

Material disponible gratis en españolScrum Primer (Pete Deemer, Gabrielle Benefield, Craig Larman and Bas Vodde) traducción Leo Antoli http://assets.scrumtraininginstitute.com/downloads/3/

scrumprimer_es.pdf?1285932063Scrum and XP from the trenches (Henrik Kniberg) traducción Ángel Medinilla http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Otros[McConnell] Rapid Development, Steve McConnel, Microsoft Press, 1996 [Coplien&Harrison] Organizational Patterns of Agile Softwaer Development, Pearson Prentince Hall, 2005.[DeMarco&Lister] Peopleware 2nd Ed, Dorset House, 1999.[Xavier Quesada Allue] http://www.xqa.com.ar/visualmanagement/

GlosarioLa mayoría de la información disponible está en inglés, y las traducciones (como parte de este documento) tienen que seleccionar los términos claves cuidado el balance para, por un lado, mantener el significado y, por el otro, facilitar la búsqueda de información adicional. Para facilitar la búsqueda de material adicional, creemos útil aclarar cómo hemos traducido los siguientes términos:

Product Owner – Dueño de ProductoTeam – EquipoSprint – IteraciónJoker – AnimadorServant Leader – Lider ServicialEmpowered team – equipo con autonomía.Backlog – Lista de pendientesSkill – habilidadesStakeholders – interesadosCeremonies – Ceremonias. Son momentos y actividades particulares del equipo, normalmente reuniones, que se repiten en cada iteración. Las metodologías ágiles se caracterizan por tener “bajo nivel de ceremonia”, significando hay relativamente pocas actividades que no están directamente relacionadas con la construcción del producto.

Artifacts – Artefacto. Son contrucciones que hace el equipo para contruir el producto, pero que no forman parte del producto, como los andamios en la construcción. También un factor común de pérdida de foco del equipo: tomar la generación de artefactos como el objetivo del trabajo, similiar a RAE: “5. m. En los experimentos biológicos, formación producida exclusivamente por los reactivos empleados y perturbadora de la recta interpretación de los resultados obtenidos.”

13

14

15

Este artículo contiene los principios básicos del Desarrollo Ágil de Software, y un recorrido por las distintas formas de realizarlo. Esperamos que esta información te permita decidir sobre la aplicabilidad de esta forma de trabajo a tus necesidades y contexto, y a partir de allí, seguir investigando y aprendiendo. Para este caso te indicaremos referencias a material para profundizar en los distintos temas incluidos.

Nos pusimos en contacto con la organización de La Conferencia Agiles 2012 (5º Jornadas Latinoamericanas de Metodologías Agiles) para interiorizarnos de las novedades que se suman este año en este prestigioso evento. Pablo Rodríguez Facal de la presidencia del evento nos ha aportado una clara visión de esta propuesta que se realizará en Córdoba, Argentina, desde el 24 al 26 de Octubre del corriente año, en instalaciones de la Universidad Tecnológica Nacional - Unidad Regional Córdoba.

El eventoEstas Jornadas se vienen realizando desde el año 2008 y ya se han realizado en Buenos Aires (en 2008 y 2011), Florianopolis (2009) y Lima (2010). Son conferencias sin fines de lucro organizadas por representantes de todas las comunidades ágiles latinoamericanas. En ediciones anteriores han tenido keynotes de la talla de Mary Poppendieck, Jeff Patton, Diana Larsen, Brian Marick, Jim Shore, Lee Devin, entre otros. En cada una ha habido alrededor de 400 participantes de toda america latina (y algunos de Norte América y Europa), y sponsors de la talla de Sabre, Microsofft, Rally, Version One, IBM, ThoughtWorks. Las actividades se desarrollan durante de 2 días de charlas, workshops y un día mas en formato Open Space para compartir todo lo que aprendimos; la concurrencia que se espera este año es de más de 500 ágiles provenientes de diversos países, tanto de Latinoamérica como del resto del mundo; y ya se están tramitando sposors como Google, Taller Technollogies, Ci&T, Kleer, 10Pines, Vates, y otros, ademas de contar con el Apoyo de SADIO y agiles.org, este evento es uno de los mas interesantes del año en lo que a IT y Project Management se refiere, y la iniciativa pretende sumar a todos los integrantes de la comunidad IT.

DisertantesEn esta entrega del evento los principales oradores confirmados son:

David Hussman: Dirige DevJam, una compañía ubicada en Minneapolis conformada por colaboradores ágiles. Desde DevJam, mentores y colaboradores se enfocan en el uso de Agile para ayudar a que personas y compañías perfeccionen sus habilidades de producción de software. Además, desde esta compañía se

proporciona ayuda líderes experimentados en su esfuerzo por coincidir tecnología, personas y procesos, con el fin de crear productos atractivos y de mejor calidad. Para más información, visita el sitio de DevJam www.devjam.com

Martin Salias: Lleva casi treinta años en el desarrollo de software. Ha trabajado en proyectos en varias parte del mundo para organizaciones como la ONU, Microsoft Corp, entidades gubernamentales, compañías de telecomunicaciones, financieras y de otros

rubros. Se enfoca especialmente en la relación entre la dinámica de grupos, la arquitectura de software y los lenguajes de programación. En 2008 formó parte en la organización de Ágiles. Para más información, visita el website de Martin Salias http://CodeAndBeyond.org

El evento se va a llevar a cabo el 24, 25 y 26 de octubre en la Universidad Tecnológica Nacional de Córdoba. En esta 5ta edición, que se realiza una vez más en Argentina se espera una gran actividad con entusiastas y profesionales del desarrollo de software, durante tres jornadas en las que participantes y speakers intercambiarán conocimientos y experiencias enriquecedoras.

Jornadas Latinoamericanas de Metodologías Ágiles

16

17

18

La credibilidad, un valor insustituible

Desarrollar un comportamiento congruente quiere decir, actuar en relación a lo que decimos. Como tester esto significa que si hablamos acerca de la importancia de la calidad, eso debe aplicarse también a nuestro propio trabajo, en caso contrario no seremos creíbles.

Por Alfonsina Morgavi

Durante más de una década he tenido la oportunidad de entrenar testers y mi preocupación, más allá de enseñarles todo aquello que sé y experimenté a lo largo de estos años ha sido y es, lograr transmitirles conocimientos y experiencias útiles que les permitieran realizar trabajos de calidad y que los convirtieran en profesionales “fiables”.

Hasta los mejores testers, los más experimentados, aquellos que han pasado por muchas, pero muchas batallas, necesitan mejorar, ofrecer más y mejor de sí mismos.

Este artículo va dirigido entonces a quienes estén por la labor de mejorar día a día sus habilidades, de convertirse en un mejor tester.

Desarrollar nuestro skill técnicoIndependientemente de la capacitación que pueda darnos la empresa para la cual trabajamos, existen muchos recursos por ejemplo en internet (completamente gratuitos), que nos permiten interiorizarnos… Qué hay de nuevo, sobre qué están trabajando otros? Qué nuevas herramientas open source hay disponibles, revistas, foros, blogs.

En definitiva, las opciones son múltiples y están al alcance de la mano, y en algunos casos, ya ni es necesario entrar en internet para buscar el nuevo número de una revista, con sólo suscribirnos, ¡ella llega a nosotros! Se trata de cultivar el arte de leer, de ser curiosos. Si bien esto está al alcance de todos nosotros, es importante dada la innumerable cantidad de artículos que a diario se publican, ¡estar atento a quién se lee!

Nuestro skill es uno de los factores que nos distingue de otros. Se trata de convertirnos en profesionales

más “atractivos”.

Si bien en la actualidad en nuestro país no hay muchos encuentros de la especialidad, los pocos que se están generando, lamentablemente no tienen afluencia masiva. Es importante aprovechar cada oportunidad de realizar networking con quienes en lo cotidiano enfrentan algunos de los mismos problemas que todos, indefectiblemente todos, atravesamos en nuestro quehacer diario.

A nivel internacional, existen muchos congresos y conferencias de la especialidad, que una vez celebrados, ponen a disposición pública en internet con sólo suscribirse, las presentaciones ó trabajos de

los disertantes.

Desarrollar un comportamiento congruenteCongruente quiere decir, actuar en relación a lo que decimos. Como tester esto significa que si hablamos acerca de la importancia de la calidad, eso debe aplicarse también a nuestro propio trabajo, en caso contrario no seremos creíbles! Como se dice habitualmente walk the talk. Se trata de aplicar a nuestro trabajo el mismo estándar que aplicamos al ajeno.

La comunicación: una poderosa herramienta¡Un correcta, veraz y fluída comunicación mantienen las sorpresas a rayas! Es vital, practicar el pensamiento crítico sobre nuestros propios mensajes.

Exagerar, hace que uno pierda credibilidad. Podrá exagerar una, dos, tres veces, pero en algún momento su interlocutor, reducirá el significado de su mensaje. He sido testigo de situaciones en las cuales se exageran los mensajes, ya sea para captar la atención ó para lograr una rápida acción. Cualquiera de estos objetivos debería ser logrado en términos distintos.

Nuestro skill es uno de los factores que nos distingue de otros. Se

trata de convertirnos

en profesionales

más “atractivos”.

19

“Encontré errores catastróficos cuando testeaba la aplicación”. Sin dudas, la pesadilla de cualquier interlocutor. Al momento siguiente, serán las preguntas: ¿cuántos defectos? ¿De qué tipo? ¿En qué funcionalidades? ¿En qué momento de la prueba?, etc. Una vez que se haya ganado el “mote” de exagerado/a, ó poco preciso, su mensaje ya no será tenido en cuenta en los mismos términos. La información que usted brinde debe ser objetiva; con ella, trabajarán desarrolladores, managers y usuarios. El pesimismo y el optimismo, no son buenos aliados para construir su credibilidad. No es sólo lo que dice ó informa es también el cómo. Lo que vio, comprobó y analizó fehacientemente será la mejor información que podrá brindar a quienes necesiten conocer el status de un proyecto. Hable de lo que sabe, y, en el caso en que se está basando en información provista por terceros, por favor chequee y vuelva a chequear.

La actitud colaborativa¡Como quiera que sea, usted nunca está solo en un proyecto! Como mínimo tendrá un desarrollador que será quien le genere trabajo. Puedo asegurarle que si se tiende un puente de colaboración genuino, el proyecto se beneficiará y por carácter transitivo, la percepción que tendrán los otros de usted y de su trabajo hará que lo requieran para futuros trabajos y lo consulten… Se ha fijado últimamente en cuántas oportunidades fue invitado ó requerido para participar en etapas tempranas de un proyecto… O en cuántas oportunidades durante la ejecución de las pruebas le han consultado, más allá de las métricas formales que se le solicitan, cuántas veces le han pedido su opinión…

Aprender a lidiar con la presión

Si usted ha elegido esta profesión y ha atravesado estoicamente algunas guerras, ya sabe de qué se trata. En el caso de que se esté iniciando, no tenga dudas antes ó después un interlocutor ó varios lo presionarán, y si nadie lo hace, puede empezar a preocuparse. En las arenas del test, nunca hay tiempo suficiente para hacer lo que sabemos que se necesita hacer. Siempre nos pedirán más, con suerte en los mismos tiempos, cuando no, más, en menos tiempo. Mantener la perspectiva, negociar y no prometer más allá de aquello que sea posible desde una perspectiva realista. Si nuestra estimación de esfuerzo inicial

Autor

Alfonsina MorgaviEs socia de la Consultora QActions, empresa dedicada en exclusividad al aseguramiento y control de calidad de software.

Representante de Argentina en el Hispanic America Software Testing Qualification Board – HASTQB.

Está certificada por el Quality Assurance Intitute como Software Test Engineer.

Desde hace más de 15 años está dedicada a la especialidad. Ha sido QA Manager por los últimos 15 años, formando equipos de

trabajo capacitándolos y desarrollándolos. Es impulsora de la mejora continua en la industria del software.

Forma parte de la comisión de calidad de software de la CESSI, como así también de la comisión de calidad de Normas en TI del Instituto IRAM.

Es miembro del TMMI Foundation. Es habitual disertante en Congresos tanto a nivel nacional como Internacional.

20

(ha sido hecha a partir de datos fidedignos y a conciencia) es de una cantidad determinada de horas, y posteriormente decimos que podemos hacer lo mismo en menos tiempo y con los mismos recursos, ¿cuál cree que será la percepción de su interlocutor acerca de sus estimaciones?

Certifique sus conocimientosLa tendencia respecto de las certificaciones en test tanto a nivel local, como a nivel latinoamericano e internacional, crece día a día. Hace algunos años, en la Argentina estas certificaciones eran raras avis. En la actualidad, están mucho más difundidas y vistas como un valor agregado. Estar certificado no significa que usted es un tester genial y fuera de serie. Significa que usted ha demostrado su nivel de conocimientos ante un organismo certificador que acredita esos conocimientos. Para una organización esto significa que usted ha desarrollado determinadas capacidades, que le permitirán hacer las cosas bien, con los mejores métodos posibles para lograr el objetivo, es decir un trabajo más eficaz.

Existen varias certificaciones disponibles en el mercado, sin embargo ISTQB es la más difundida y mayormente adoptada al menos para Latinoamérica. Existen varios niveles: un nivel inicial, un nivel avanzado y un nivel de experto. Y dentro de esos niveles, distintos caminos a recorrer. El nivel inicial es un punto de partida, una foto del estatus de nuestros conocimientos en un determinado momento. Avanzar en el estudio y la certificación en los siguientes niveles, es de alguna manera crearse la propia película de mejora continua, es orquestar una carrera, un camino…

Algunas conclusionesPara ser mejores en lo que hacemos, es necesario: involucrarse y comprometerse en incrementar nuestros conocimientos técnicos. Mejorar nuestra capacidad para comunicarnos, también para negociar. Leer, estudiar. Interactuar con pares y desarrollar nuestra curiosidad para convertirnos en profesionales más “atractivos” para nosotros mismos y para el mercado.

Autor

Alfonsina Morgavi es Representante de Argentina en el Hispanic America Software Testing Qualification Board – HASTQB.

Este comité es una asociación jurídica trans-sectorial y trans-nacional sin fines de lucro fundada por empresas, instituciones, organizaciones y personas especializadas en el campo del testeo y la industria del software. Los Objetivos del HASTQB son:

• Promover un marco de trabajo común en el testeo de software para poder mejorar las técnicas de testeo de software y fomentar el proceso de pruebas de software como una profesión en Hispanoamérica, asegurar la conformidad entre los esquemas de los comités local e internacional el cumplimiento del esquema.

• Fortalecer el intercambio internacional y la cooperación entre los países representados en el comité.

• Expandir el intercambio internacional de talentos y tecnología con el fin de seguir la tendencia mundial en el desarrollo de las pruebas de software.

• Llegar a ser el enlace entre la industria del software y la academia en el área de testeo de software.

El esfuerzo actual de ISTQB está dirigido homologar los términos y conceptos de pruebas, esto se realiza a través del trabajo de diversos comités de los diferentes comités (o boards) del mundo, entre ellos HASTQB. Los boards de cada país o región se encargan de apoyar tanto el trabajo conceptual colaborando con el resto de los comités y en cada país o región encargándose del proceso de certificación, además tratar temas localización en temas de traducción. La certificación, reconocida internacionalmente, es la forma como los profesionales en el tema de pruebas pueden comparar y homologar términos con los de ISTQB. Para unificar temas de lenguaje HASTQB, viene trabajando con el comité español SSTQB (Spanish Software Testing Qualification Board), fortaleciendo esta propuesta de industria a través de la mayoría de los países hispano parlantes.

21

Encontrar formaciones de calidad y apoyadas por instituciones reconocidas es un desafío para los profesionales de cualquier especialidad; pero si ademas, esas formaciones se desarrollan en el formato tradicional, con un docente presente e infraestructura de apoyo y son gratuitas, definitivamente se merecen una observación especial.

Durante el mes de Mayo Gerardo Prieto, QA Area Leader at TeraCode, anunciaba en diferentes comunidades la realización de una formación gratuita denominada “Empezando a Automatizar en Selenium”, y que además la iniciativa podría repetirse en próximas fechas.

La propuesta se desarrolló en dos jornadas en el horario de 19 a 21.30hs y contó con la participación de testers interesados en la temática.

Contactamos a Gerardo para preguntarle como vivió la experiencia y algunas curiosidades de este tipo de formación gratuita referida a una de las herramientas más populares del contexto actual.

IT - ¿Gerardo, podrias contarnos como nació esta iniciativa? ¿Cual ha sido la motivación principal para llevar adelante una propuesta de estas características?

R- La iniciativa surgió básicamente por dos razones: Poder hacer el aporte a la comunidad de Testing en Argentina (dado que hemos estado entrevistando muchos candidatos que nunca se iniciaron en el tema

y que tenían ganas de hacerlo, al igual que otros miembros de la comunidad) y por otro lado mostrar como trabajamos en TeraCode para darnos a conocer un poco mas del lado de testing.

IT- Cualquier propuesta de formación exige a los organizadores tener en cuenta el soporte físico, la elaboración de contenidos, y la convocatoria al destinatario previsto. ¿Quienes apoyan esta propuesta y contribuyen para que todo esto sea posible en un aporte gratuito para la comunidad de testers profesionales en Argentina?

R- TeraCode University (nuestro ente capacitador propio), RRHH y obviamente el departamento de QA de TeraCode.

IT- ¿Cual es el objetivo principal de brindar esta propuesta de conocimiento, ademas de compartir un conocimiento con gran demanda en el mercado con creciente aceptación de la automatización de Testing?

R- Lo explicado en el punto 1 y además poder contribuir/dar un aporte de este conocimiento que cada vez es mas solicitado en el mercado laboral de sistemas.

22

IT - ¿Es una propuesta desarrollada solo para personas que se desempeñen en Software testing o abierta para cualquier profesional relacionado con informática?

R - Inicialmente era una propuesta abierta a toda la comunidad informática pero debido a la gran cantidad de postulantes para la misma y al cupo limitado hemos tenido que hacerlo particularmente para personas que se desempeñan en Software Testing/QA/QC.

IT- ¿Que conocimiento previo debe tener el aspirante a realizar esta formación?

R- Solamente experiencia mínima de 6 meses trabajando en Software Testing.

IT- Que contenidos se abordan en el desarrollo del curso?

R- El Temario es:

Empezando a automatizar (Nociones básicas de automation, planificación, estrategia, puesta en marcha como un proceso formal)

Selenium IDE

Selenium RC

Workflow de trabajo

Selenium 2 (WebDriver)

Sauce Labs

En todos los puntos además de teoría se realizó su práctica correspondiente con ejemplos y se aclaró todas las dudas al respecto.

IT- ¿Se ha pensado en una proyección de tutoriales de descarga y videos en los distintos canales que propone la Web? R - Hemos grabado el curso para poder compartirlo en la Web. Próximamente será publicado el enlace.

IT- ¿La primer propuesta desarrollada en el mes de Mayo ya se ha realizado, como fue la experiencia? Cuantos asistentes respondieron a esta interesante convocatoria?

R- Desde mi lugar como docente del curso la experiencia ha sido mas que satisfactoria. El grupo genial, muy interesado y predispuesto.

IT- Desde tu punto de vista como instructor, quienes a tu juicio responden con mas interés a este tipo de convocatorias? Testers iniciales que intentan enriquecer su conocimiento y desarrollarse profesionalmente, o también, Testers con trayectoria y experiencia que refuerzan sus herramientas adaptándose a nuevos requerimientos del mercado.

R- En mi opinión y por haberlo vivido durante este curso, tanto Testers iniciales como Testers con trayectoria que tienen interés en aprender acerca del tema y/o reforzar sus conocimientos sobre el mismo.

IT- ¿Cual es tu lectura en relacion a la utilización y evolución de este software en un futuro cercano?

R- Como un proceso que se va tornando cada vez mas esencial en el desarrollo de Software yendo de la mano y al mismo nivel del Testing Manual ya que ninguno remplaza ni remplazará al otro.

IT - ¿Donde deben buscar información los interesados para encontrar referencias de las futuras propuestas que se desarrollen?

R – Pueden encontrarse en:

http://university.teracode.com.ar/ tcu@teracode.com

Y también las estaré publicando en mi perfil de LinkedIn:

http://www.linkedin.com/profile/view?id=57152674

23

A continuación se explica el proceso de automatización utilizando las siguientes Herramientas:

• Selenium IDE.• Selenium RC• BlueDuck SRC.• Java (Eclipse IDE).• Excel

Selenium IDE, es el plugin que viene para el navegador Firefox y que nos permite automatizar acciones sobre el navegador, haciendo una grabación de cada paso que realizamos, Selenium lo graba en lenguaje Selenity pero se puede exportar a varios lenguajes, entre ellos Java que es el que utilizaremos.

-Requisitos: Mozilla Firefox instalado, Selenium IDE instalado.

Ejemplo de grabación de una prueba sobre el navegador:Abrimos el navegador Firefox, y luego abrimos Selenium IDE”. Una vez que abre esta listo para comenzar a grabar las acciones sobre el navegador. En este caso se realiza una búsqueda en google y se navega en las páginas que van derivando de la búsqueda.

24

la imagen se pueden en los distintos pasos los comandos que se van completando automáticamente. Una vez que terminamos de grabar presionando el botón con el circulo de color rojo, podemos ejecutar el test con el botón con el símbolo verde “play”, también manejar la velocidad de ejecución con el control deslizante de la izquierda.

Una vez que terminamos la grabación, se puede guardar el archivo de Selenium, este se guardara como un html por defecto. También se puede exportar a cualquier lenguaje de los disponibles, entre se utilizara Java, para ello nos dirigimos a “Archivo” ò “File”-> “Exportar test case como…” ò “Export test case as…”-> “JUnit 4(Remote Control)”.

Una vez allí, guardamos nuestro test case con la extensión .java (ejemplo.java).

Luego de esto, podremos abrir este archivo con Notepad o con algún IDE de Java para editarlo.Cuando se exporta a java, el código se transforma y comienza a utilizar sentencia y lenguaje propiamente de java, también utiliza librerías y drivers de Selenium y librerías de JUnit 4 con las anotations que se utilizan para correr los test (Ej. @Test, @After, @Before).

A continuación se muestra el código que obtuvimos al exportar el test case con Selenium:

Utilización de Selenium RC:Para la poder correr un test que esta escrito en java, se necesitara tener corriendo una instancia de Selenium Remote Control. Para ello tenemos tres opciones por las cuales optar.

*La primera opción es correr el Selenium RC desde la consola con el servicio de ANT, como esta explicado en el manual de Selenium.

25

*La segunda opción es utilizar un plugin de Eclipse IDE que permite levantar de manera automática una instancia de Selenium Grid, y de Selenium RC. (Esta opción se explicara mas adelante).*Por ultimo la opción con la cual se realizo el ejemplo que estamos desarrollando es una aplicación llamada BlueDuck SRC que se instala y al ejecutarlo levanta una instancia de Selenium RC, cuando lo ejecutamos queda en la barra de herramientas minimizado el icono del programa y desde allí podemos ingresar al Log, a las configuraciones, o bien controlar el servidor.

Las funciones que podemos manejar desde aquí comprenden: Start y Stop del SRC.Cuando iniciamos o detenemos el server, se presenta un cartel en la pantalla hincando la situación:

26

Proyecto en Eclipse IDE:

Para desarrollar el ejemplo se opto por la IDE Eclipse para desarrollar el caso de prueba en Java.

Los requerimientos son los siguientes:

Librerías y drivers:-“selenium-remote.control-1.0.1”: este paquete trae todas las librerías y drivers necesarios para el manejo de Selenium con los distintos lenguajes: para java el que se utilizara será: - selenium-java-client-driver-1.0.1

-xlSQL_Y7: esta librería permite el manejo, lectura y escritura del archivo Excel.

-JUnit 4: esta librería permite la ejecución de los test y la utilización de anotations tales como: @RunWith, @Test, @Parametrized que se iran explicando a medida que se muestre el código.

-JRE 1.6: en nuestro ejemplo estamos utilizando esta versión.

-Origen de datos ODBC (.xls): esto se configura en Windows.

Para comenzar debemos crear un nuevo proyecto e incluir todas las librerías y drivers mencionados.

Desde java y usando el driver ojdb, podemos acceder a un fichero Excel como si fuera una base de datos, de forma que podremos leer su contenido o escribir en él.

Configurar la fuente de datos:Lo primero que tenemos que hacer, en Windows, es configurar el fichero Excel como si fuera una fuente de datos.

Nos dirigimos a Inicio->Panel de Control-> Herramientas de Administrativas:

27

Luego entramos en donde dice “Orígenes de Datos”:

Una vez allí vamos a crear un nuevo origen de datos: Clic en “agregar”.

En la pantalla que aparece buscamos en la lista “Driver do Microsoft Excel (*.xls)”, lo seleccionamos y pulsamos finalizar.

28

En la siguiente pantalla que aparece, ponemos el nombre que queremos para identificar el origen de datos y luego en el botón “Seleccionar libro…” buscamos el archivo Excel que vamos a utilizar.

Una vez realizado esto, desde Eclipse y con el driver para Excel incorporado a nuestro proyecto, podremos conectarnos al Excel como si fuese una base de datos.

29

Código java

Simplemente debemos abrir la conexión como si fuera una base de datos normal, usando el Driver sun.jdbc.odbc.JdbcOdbcDriver.

El código puede ser como este:

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");Connection conexion = DriverManager.getConnection("jdbc:odbc: excel");

donde " Excel" es el nombre que elegimos para la fuente de datos cuando la configuramos en el paso anterior.A partir de aquí, el código es el normal para acceso a cualquier base de datos, usando los Statement y ResultSet. Podemos leer o insertar, si al configurar en la fuente de datos desmarcamos el check de "sólo lectura".

Tablas

En un Excel se considera que cada una de las hojas dentro del fichero Excel es una tabla. Las columnas de la tabla serán los nombres que aparecen en la primera fila (no las letras A,B,C...).

Así, por ejemplo, el siguiente trozo de código java:

try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection conexion = DriverManager .getConnection("jdbc:odbc:un_excel");

Statement st = conexion.createStatement();

st.execute("create table kk2 (id NUMBER, nombre TEXT, precio NUMBER)");

st.execute("INSERT INTO kk2 (id,nombre,precio) " + "VALUES (1,'hola',12.52)");

conexion.close(); } catch (Exception e) { e.printStackTrace(); }

30

Dará como resultado la siguiente hoja de Excel

Nombre de las tablasSi el fichero Excel se ha creado con la aplicación Excel en vez de con nuestra aplicación java, desde java veremos los nombres de las hojas (de las tablas) con un $ detrás. Por ejemplo, si el Excel tiene una pestaña etiquetada "Nov2004", desde java la veremos como "Nov2004$". La forma de acceder a ellos con una SQL sin que nos de error por el carácter $, es poniendo el nombre de la tabla con el $ y todo ello entre corchetes, así [Nov2004$]

ResultSet rs = st.executeQuery("select * from [Nov2004$]");

Si la tabla la hemos creado nosotros con un "create table", no es necesario este $ al consultarla.

CatálogosLos catálogos que considera la base de datos son los ficheros Excel. Cuando abrimos nuestra fuente de datos que apunta a un fichero Excel, el catálogo que estamos usando es ese fichero Excel. Sin embargo, tendremos como catálogos accesibles todos los ficheros Excel que haya en el mismo directorio del fichero Excel que hemos elegido.

Y si cambiamos de catálogo y ponemos uno que no existe, estaremos creando un fichero Excel nuevo en ese directorio.

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");Connection conexion = DriverManager.getConnection("jdbc:odbc:un_excel");conexion.setCatalog("nuevoCatalogo");

Ese trozo de código utilizará el fichero "nuevoCatalogo.xls", independientemente del fichero que hayamos indicado en la fuente de datos "un_excel".

31

Si ese fichero nuevoCatalogo.xls existe, será el que se use. Si no existe, lo creará (debemos nosotros, desde java, crear las tablas correspondientes y las columnas para cada una de ellas).

Luego de que exportamos el código desde Selenium a Java y tenemos nuestro nuevo proyecto en eclipse, incorporaremos la clase java que se genero cuando exportamos y le haremos las modificaciones pertinentes para hacer la ejecución que necesitamos. En este caso se eliminaron las anotaciones @After, @Before, ya que para correr la prueba varias veces, utilizamos las anotaciones @RunWith, @Parameters y @Test para que nuestro test lea datos desde el Excel y valla corriendo el mismo test cambiando los datos.

A continuación ponemos el código de la clase java como quedo modificada:

package clases; import java.util.ArrayList; import java.util.Collection; import org.junit.Test; import org.junit.runner.RunWith; import org.junit.runners.Parameterized; import org.junit.runners.Parameterized.Parameters; import com.thoughtworks.selenium.DefaultSelenium; import com.thoughtworks.selenium.SeleneseTestCase; //Con este comando se indica que la clase utilizara parametros @RunWith(Parameterized.class) public class googleSelenium2 extends SeleneseTestCase { private final Integer num;// = 1; public googleSelenium2(final Integer x) { this.num = x; } @Parameters // Se crea un array que contendra los datos para ejecutar la prueba. public static Collection<Integer[]> init() throws Exception { final Collection<Integer[]> datos = new ArrayList<Integer[]>(); Clase2 c2 = new Clase2(); //el metodo que se invoca aca, devuelve la cantidad de registros que contiene el excel int a = c2.numRegs(); int e = 1; while (e <= a){ datos.add(new Integer[] {e}); e++;} return datos; }

32

public void coreTest(int i) throws Exception { Clase2 cl2 = new Clase2(); //el metodo que utilizamos aqui lee el dato del indice del registro indicado String a = cl2.datos(i); String c1 = "\""; String error = ""; //aqui se comienza a utilizar el lenguaje y comandos de Selenium try{ selenium.open("http://www.google.com.ar/"); selenium.type("id=gbqfq", c1 + a + c1); selenium.click("id=gbqfb"); assertEquals("Google", selenium.getTitle()); //System.out.println("Busqueda: " + a); //Estos métodos escriben el estado y detalle del test ejecutado en el Excel. cl2.escribirEstadoOK(a, i); cl2.escribirDetalleOK("NO HAY ERRORES", a, i); } catch(Error e){ error = e.getMessage(); System.out.println(e); cl2.escribirEstadoNoOk(a,i); cl2.escribirDetalleOK(error, a, i); //este metodo toma el mensaje de error y lo agrega en el Excel }}

@Test public void testGoogleSelenium2() throws Exception { selenium = new DefaultSelenium("localhost", 4444, "*chrome", "http://www.google.com.ar/"); selenium.start(); coreTest(this.num); selenium.stop(); }

}

33

package clases;import java.sql.Connection;import java.sql.DriverManager;import java.sql.ResultSet;import java.sql.Statement;

public class Clase2 { public int numRegs() { String r = null; try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection conexion = DriverManager.getConnection("jdbc:odbc:excel"); Statement st = conexion.createStatement(); ResultSet rs = st.executeQuery("select COUNT(DATOS) from [datos1$]"); while ( rs.next() ) { r = rs.getObject(1).toString(); } } catch ( Exception e ) { // System.out.println("Algun error en algun sitio"); } return Integer.parseInt(r); }public String datos(int i){ String DATO = ""; try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection conexion = DriverManager.getConnection("jdbc:odbc:excel"); Statement st = conexion.createStatement(); ResultSet rs = st.executeQuery("select DATOS from [datos1$]WHERE INDICE = " + i); while ( rs.next() ) { DATO = rs.getObject(1).toString(); System.out.println(DATO); i++; } conexion.close(); } catch ( Exception e ) { System.out.println("No hay datos para la busqueda"); } return DATO;}

34

public void escribirEstadoOK(String a, int i){ try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection conexion = DriverManager .getConnection("jdbc:odbc:excel");

Statement st = conexion.createStatement(); st.execute("UPDATE [datos1$]SET ESTADO= 'OK' WHERE DATOS = '"+ a +"'and INDICE =" +i );

conexion.close(); } catch (Exception e) { e.printStackTrace(); } }public void escribirEstadoNoOk(String a, int i){ try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection conexion = DriverManager .getConnection("jdbc:odbc:excel");

Statement st = conexion.createStatement(); st.execute("UPDATE [datos1$]SET ESTADO= 'NO OK' WHERE DATOS = '"+ a +"'and INDICE =" +i );

conexion.close(); } catch (Exception e) { e.printStackTrace(); } }public void escribirDetalleOK(String ER,String a, int i){ try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection conexion = DriverManager.getConnection("jdbc:odbc:excel");

Statement st = conexion.createStatement(); st.execute("UPDATE [datos1$]SET DETALLE= '"+ ER +"' WHERE DATOS = '"+ a +"'and INDICE =" +i ); conexion.close(); } catch (Exception e) { e.printStackTrace(); } } }

35

Una vez que tenemos listo el código, la ejecución se hace con Junit4, a la izquierda se mostraran los test que se van ejecutando.

En el Excel se irán completando las columnas:

Alejandro Zuvic y Ezequiel Bazan forman parte del equipo de automatizaciones de QAustral. En esta actividad han llevado adeltante tareas en firmas como HP, Motorla

36

QA&TEST® es una conferencia única que reúne conjuntamente a profesionales y expertos de diferentes sectores, tales como: ferrocarril, aeronáutica, medicina , dispositivos electrónicos, banca, seguros o telecomunicaciones.

Es intención de los organizadores de este evento difundir los últimos avances y desarrollos tecnológicos en Testing y Calidad de Software en sistemas embebidos, así como mostrar las prácticas más exitosas, que pueden ayudarte a tomar parte en los mercados globales más competitivos. El éxito de la última edición demuestra que lafórmula cubre de forma exitosa una demanda que plantea el mercado en la mejora de la productividad.

En 2012, QA&TEST® tendrá lugar los días 17, 18 y 19 de octubre en el corazón de la ciudad de Bilbao, España, en el Palacio de Congresos y de la Música Euskalduna Jauregia.

Esta propuesta se dirige principalmente a directores, jefes de proyecto, directores de programa, así como a profesionales del mundo del Testing que trabajen en el ámbito de la Calidad de Software y Testing.

Este evento cuenta con colaboraciones de primer nivel como la que ofrece IEEE, una organización sin ánimo de lucro, es una autoridad en áreas que comprenden desde los sistemas aeroespaciales, los ordenadores y las telecomunicaciones para la ingeniería biomédica, hasta la energía eléctrica y la electrónica de consumo, entre otros. Otra entidad que aporta conocimiento e interviene es Gasq (Global Association for Software Quality), en este caso se

trata de una organización internacional sin ánimo de lucro, basada en la actividad de sus miembros. Es una organización no gubernamental que actualmente, no recibe ningún tipo de ayudas económicas por parte del Gobierno. Los miembros fundadores de Gasq son fundamentalmente europeos, pero también americanos y asiáticos. El principal objetivo es apoyar la calidad de software en el ámbito de la investigación, la enseñanza y la industria. Gasq mantiene redes de trabajo internacionales y apoya y desarrolla programas vinculados al software testing. Además, Gasq es proveedor de servicios para grupos y asociaciones que trabajan en el ámbito de la calidad de software, también apoyan la iniciativa numerosas organizaciones como TestNet, Belgian Testintg, ATI y Fedit entre otras. El principal Sponsor es Innovalia, una alianza estratégica de empresas de base tecnológica, que permite aprovechar las sinergias de sus miembros para beneficio de todos.

Sin lugar a dudas este evento se posiciona entre las mejores propuestas que pueden encontrarse en la actualidad en relación a la “Calidad de Software”.

37

38

39

40