MODELO PARA LA INTEGRACIÓN DEL TESTING EN LA METODOLOGÍA SCRUM MODEL FOR TESTING ON SCRUM METHODOLOGY INTEGRATION Ing. Andrés Veloso Jardón1, Lic. Deysi Indira Aleaga Bravo2 1 DATYS, Cuba, [email protected], Calle 7 Nro. 48 e/ G y E Rpto. Mármol, Santiago de Cuba, Cuba 2 DATYS, Cuba, [email protected] RESUMEN: Las metodologías ágiles se han convertido en el paradigma del desarrollo de software en el mundo entero, pero para los testers es muy difícil adaptarse a estas metodologías y mucho más establecer una forma de trabajo acorde con los principios que las rigen. Por otro lado, existe literatura que aplica las bases del agilismo al testing de software, sin embargo, siempre mantienen separado el testing del desarrollo de software. El presente artículo propone un modelo que hace uso de la metodología Scrum para el desarrollo de software y usa los mismos principios para la integración de un tester o equipo de testing en un proyecto que haga uso de esta metodología. Palabras Clave: testing; metodologías ágiles; scrum; testing ágil. ABSTRACT: Agile methodologies have become in software development paradigm in the entire world, however, for testers is very difficult to adapt to this methodologies and much more to establish a way according to the principles that govern them. Exists literature which applies the agility principles to the software testing, however, always keep separate the software testing of the software development. The present article propose a model which make use the Scrum methodology for the software development and use the same principles for the integration of a tester or testing team in a project whose make use of this methodology. KeyWords: testing; agile methodologies; scrum; agile testing 1. INTRODUCCIÓN Mucho se habla de la metodología Scrum y de sus disímiles ventajas para el desarrollo de software, sin embargo quien se lea cualquiera de los libros o artículos existentes sobre este tema se llevará la idea de que los testers se han vuelto obsoletos. Solamente hacen referencia a testing unitario, testing unitario automático e integración continua. Muy pocos hacen referencia a un tester incluido en el equipo de desarrollo y muchos menos los que le dan al tester el verdadero valor que tiene y le asignan su auténtico papel dentro del ciclo de desarrollo.

Scrum es un marco de trabajo, o sea, que no es una “fórmula matemática”, donde se suma A más B y se obtiene C. El truco para un buen funcionamiento de las metodologías ágiles, consiste en la interpretación que se haga de sus principios, de la forma en que sea aplicado a una organización concreta y de la forma que los integrantes del equipo lo sepan aceptar y sepan desempeñar sus respectivos papeles en él. Todo aquel que comienza a dar sus primeros pasos en la metodología Scrum lo hace leyéndose uno o varios libros sobre el tema, intentando inmediatamente copiar lo que dicen los libros y ponerlo en práctica: formar equipos de trabajo auto-

“VII Taller Internacional de Calidad en las Tecnologías de la Información y las Comunicaciones”

Veloso, A.; Aleaga, D. | “MODELO PARA LA INTEGRACIÓN DEL TESTING EN LA METODOLOGÍA SCRUM”

organizados y multifuncionales, donde nadie se especialice en un tipo de tarea, sino que todos sean capaces de ejecutar cualquiera de las tareas necesarias para el cumplimiento del sprint; crear muchas pruebas unitarias automáticas; implantar una herramienta de integración continua que se encargue de la ejecución de la pruebas unitarias automáticas; liberar un producto funcional y sin errores cada 4 semanas; entre otras. Luego de dos o tres Sprint comienzan los problemas: se tiene una enorme cantidad de pruebas unitarias automáticas, sin embargo el producto sigue teniendo una cantidad casi infinita de errores; el equipo no tiene tiempo para implementar nuevas funcionalidades, arreglar los problemas de las funcionalidades implementadas anteriormente y, además, hacer pruebas. Para intentar solucionar estos problemas, el equipo llega a la conclusión de que es una buena idea tener un responsable de pruebas, alguien que se encargue de velar que las funcionalidades que se implementan son las acordadas con el cliente, pero ¿no rompe esto con los principios de auto-organización y multifuncionalidad que plantea la metodología?; después que el equipo de desarrollo termina una funcionalidad el tester o el equipo de pruebas ejecuta una batería de pruebas, se generan no-conformidades, se resuelven, el tester ejecuta pruebas de regresión y se vuelven a generar nuevas no-conformidades en un ciclo casi infinito, ¿esto es agilismo, está siendo mal aplicada la metodología ágil? Se plantea que el objetivo que se persigue con las metodologías ágiles es no escribir con errores en lugar de encontrarlos y corregirlos. Esto no significa que los testers no sean necesarios, sino todo lo contrario, en estas metodologías los testers son más necesarios que en las metodologías tradicionales. Los buenos testers son una pieza clave en los equipos de desarrollo, ya que tienen la habilidad de ver un software desde una perspectiva diferente, así como para encontrar errores y diseñar situaciones imprevistas. 2. SCRUM EN LA LITERATURA “Scrum no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas. Scrum hace patente la eficacia relativa de las prácticas de gestión de producto y de desarrollo, de modo que puedan ser mejoradas” [1]. La metodología Scrum se basa en el principio ágil de desarrollo iterativo e incremental. Al período de trabajo para desarrollar un incremento potencialmente útil y funcional del producto final se lo denomina ‘sprint’ y se recomienda una duración

de entre dos y cuatro semanas. El tiempo de duración de cada sprint debe ir ajustándose tomando como base la propia experiencia y velocidad del equipo de trabajo. Los dos artefactos más importantes que se utilizan en la metodología Scrum son la pila del producto (product backlog), y la pila del sprint (sprint backlog). La pila del producto es una “lista de requisitos de usuario que a partir de la visión inicial del producto crece y evoluciona durante el desarrollo” (Palacio, 2008). A partir de esta se genera la pila del sprint, que no es más que la “lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto” [2]. “En Scrum hay solamente tres roles: El Dueño del Producto, el Equipo, y el ScrumMaster. […] El Dueño del Producto es responsable de representar los intereses de todos los interesados en el proyecto y en los resultados del sistema” [3]. Además es el único responsable de asignarle prioridad a las tareas de la Pila del producto, asegurando de esta forma que las tareas que son más importantes para el cliente sean las que primero se desarrollen, de forma que los clientes obtengan el mayor retorno de la inversión posible. “El Equipo es responsable del desarrollo de las funcionalidades. Los Equipos son auto-gestionados, auto-organizados, y multifuncionales, y son responsables por resolver cómo convertir la Pila del Producto en un incremento de funcionalidad dentro de una iteración” [3]. En las reuniones de planificación de los sprints el equipo debe seleccionar los requisitos que pueden completar en cada iteración, realizando al cliente las preguntas que consideren necesarias con el objetivo de aclarar los requisitos que no hayan sido bien comprendidos. Es muy importante que el equipo sea estable durante el proyecto, o sea, que sus miembros deben cambiar lo menos posible, para de esta forma aprovechar el esfuerzo que les ha costado construir sus relaciones interpersonales, engranarse y establecer su organización del trabajo. “El ScrumMaster es el responsable por el proceso Scrum, por el adiestramiento de todos los involucrados en el proyecto, por la implementación de Scrum de forma que se adapte dentro de la cultura de una organización […] y de asegurarse que cada cual siga las reglas y prácticas de Scrum” [3]. El trabajo primario del ScrumMaster es eliminar los obstáculos que impidan que el equipo alcance el objetivo del sprint. Este rol no es el líder del equipo, puesto que el equipo se auto-organiza, sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga de sus objetivos. Los sprints contemplan varias reuniones del equipo:

“VII Taller Internacional de Calidad en las Tecnologías de la Información y las Comunicaciones”

Veloso, A.; Aleaga, D. | “MODELO PARA LA INTEGRACIÓN DEL TESTING EN LA METODOLOGÍA SCRUM”

Reunión de planificación del sprint, Reuniones diarias de revisión, Reunión de revisión del sprint y Reunión de retrospectiva del sprint. Al final de cada sprint, el equipo deberá presentar los avances obtenidos mediante la presentación al cliente de un demo. Cada sprint debe comenzar con la reunión de planificación del sprint. En esta reunión se establecen cuáles son los objetivos que se deben cubrir con el sprint, y se define la pila del sprint. Principalmente, se deben dar respuesta a dos preguntas: “¿Qué será entregado en el Incremento resultante del sprint que comienza?, y ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?”[1]. Diariamente se debe efectuar una reunión con todos los miembros del equipo. Esta reunión recibe el nombre de Reunión diaria de revisión. Esta permite llevar un control diario del avance de las tareas y los objetivos del sprint. Durante ella, se deben responder las siguientes preguntas: “¿Qué se ha conseguido desde la última reunión?, ¿Qué se hará antes de la próxima reunión?, y ¿Qué obstáculos se encuentran en el camino?” [1]. La Reunión de revisión del sprint se lleva a cabo al finalizar cada sprint y sirve para inspeccionar el incremento generado durante el sprint. En esta reunión el dueño del producto debe identificar las tareas u objetivos que han sido cumplidos y los que no, así como hacer un análisis del estado actual de la pila del producto y una proyección de la posible fecha de finalización de esta basándose en la velocidad de desarrollo mantenida hasta ese momento por el equipo de proyecto. En esta reunión el equipo de desarrollo demuestra el trabajo realizado durante el sprint, responde preguntas acerca del incremento del producto, hace un análisis de los problemas que ocurrieron durante la realización del sprint, y de cómo estos fueron solucionados. A partir de esta reunión se pueden generar ideas o experiencias que sirvan de base para la planificación o desarrollo de próximos sprints. La Reunión de retrospectiva del sprint se realiza después que ha concluido cada sprint y “es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo, y crear un plan de mejoras que sean abordadas durante el siguiente Sprint” [1]. En esta el equipo debe exponer sus experiencias, tanto positivas como negativas, en lo tocante a interacciones, personas, procesos y herramientas utilizadas; así como proponer posibles mejoras a introducir en el siguiente sprint. 

Esta metodología ventajas:



Beneficios económicos, puesto que equipos

ofrece

entre

otras

ágiles proporcionan un mayor retorno de la inversión (ROI, por sus siglas en inglés) que los equipos tradicionales, en parte debido a que el ciclo de retroalimentación provee de un menor coste en la localización y corrección de errores y, además, porque cuando el beneficio pendiente de obtener es menor que el costo del desarrollo, el cliente puede finalizar el proyecto. 

Mayor satisfacción y motivación del programador, porque las personas se sienten más motivadas cuando pueden decidir cómo organizar su trabajo y se sienten más satisfechas cuando pueden mostrar los logros que han alcanzado.



Mayor facilidad en la aceptación y ejecución de cambios en los requisitos. En cualquier metodología ágil se asume que los cambios son parte natural del proceso de desarrollo, lo cual permite y hace más fácil la aceptación de los cambios que pueda hacer el cliente en función de sus nuevas prioridades, de los cambios en el mercado, entre otros factores.



Mayor productividad, debido a que con cada iteración el equipo realiza una retrospectiva que le permite detectar y corregir problemas que le impiden su buen funcionamiento como equipo, con lo cual se logra un mejoramiento continuo del proceso productivo.



Mayor calidad del producto final y mayor satisfacción del cliente. Esto es debido a que el cliente participa de cada uno de los pasos del ciclo de desarrollo del producto, con lo cual se garantiza que el equipo de desarrollo está elaborando el producto que el cliente desea o necesita.



Reducción del tiempo de desarrollo, pues el equipo trabaja solamente sobre funcionalidades que el cliente necesita y va a utilizar, sin perder tiempo en funcionalidades que no se van a utilizar.

3. VINCULACIÓN DEL TESTING CON SCRUM La mayoría de la literatura sobre la metodología Scrum coincide en señalar que los equipos deben estar integrados por 7 miembros, más menos 2, los cuales deben ser auto-organizados y multifuncionales. Esta multifuncionalidad le debe garantizar al equipo que cualquier miembro sea capaz de acometer cualquier tarea, abogando porque los miembros de un equipo Scrum no se especialicen en un área o un tipo de tarea. Este planteamiento puede que sea válido para los

“VII Taller Internacional de Calidad en las Tecnologías de la Información y las Comunicaciones”

Veloso, A.; Aleaga, D. | “MODELO PARA LA INTEGRACIÓN DEL TESTING EN LA METODOLOGÍA SCRUM”

desarrolladores, pero no es válido para los testers. El tester requiere de habilidades muy específicas que difieren de las requeridas por los demás miembros de un equipo de proyecto. El tester debe ser un profesional altamente capacitado en lenguajes de programación, métodos y técnicas de pruebas y herramientas especializadas en su campo de acción; además de estar entrenado para la detección de errores. Existen algunas corrientes dentro de los practicantes de Scrum que plantean que no se puede renunciar a las etapas de pruebas, porque en un mundo ideal, en un Sprint se produce una versión potencialmente instalable del producto final, sin embargo, este mundo ideal no existe, la realidad es muy diferente. En la práctica “el promedio de efectividad de la detección y corrección de errores es de un 25 a 30% para las pruebas unitarias” [4], mientras que “las pruebas de sistema hechas por un equipo de pruebas independiente ronda el 85% de efectividad en la detección de defectos” [4]. Estas estadísticas rompen con uno de los mitos más difundidos sobre las metodologías ágiles, que plantea que basta con tener muchas pruebas unitarias automáticas, gestionadas en un ambiente de integración continua, para poder tener un código libre de errores. El uso de una metodología u otra no hace obsoleto al tester, porque los principios que rigen la necesidad de los testers en las organizaciones se mantienen y son los mismos para todas las metodologías: introducción del error humano en todo lo que el ser humano hace, dificultad para detectar los errores propios, falta de entrenamiento de los programadores para la ejecución de pruebas, entre otras tantas. Kniberg, en su libro Scrum y XP desde las trincheras, ofrece un acercamiento un poco más práctico, aunque no del todo real, a lo que es un tester en un equipo Scrum, cuando lo define como “una persona cuya principal habilidad es hacer pruebas y no un tipo cuya única responsabilidad es hacer pruebas” [5]. Este mismo autor traduce la definición anterior en las siguientes tareas: a. Escribir las especificaciones de las pruebas; b. Debe evitar que se produzcan errores; c. Deben enfocarse en adicionar valor al producto mediante las pruebas y no simplemente en reportar errores; d. Nada se considera terminado hasta que él dice que está terminado; e. Preparar el entorno de pruebas; f. Clarificar requisitos; g. Escribir documentos de instalación;

h. Mejorar los scripts de compilación; i. Es el encargado de organizar el Demo del Sprint; j. Hacer todo lo que pueda para ayudar al equipo a alcanzar el objetivo del Sprint. Las tareas a partir de la f, así como la segunda parte de la definición, llevan a pensar que el tester en un equipo de Scrum no tiene trabajo suficiente haciendo pruebas y hace todo lo que el equipo de desarrollo no quiere o no tiene tiempo de hacer. Este enfoque, además de ser muy peligroso, está muy alejado de la realidad. La anterior definición, así como el listado de tareas asociado a dicha definición puede hacer que el tester deje de desempeñar su papel. La siguiente definición de tester puede aclarar un poco las cosas: “El objetivo de un tester de software es encontrar errores, encontrarlos lo antes posible, y asegurarse que sean corregidos” [6]. Otra definición coincidente es la dada por Myers sobre el testing de software: “El testing es el proceso de ejecutar un programa con la intención de encontrar errores” [7]. Estas definiciones no divergen de lo que hace un tester en cualquier equipo de desarrollo, sin importar si la metodología es Scrum, TDD o RUP. La importancia y el rol de los testers se mantienen inalterables sin importar la metodología, lo que cambia es la psicología, la forma de trabajo y las técnicas de testing que son utilizadas para el cumplimiento de los objetivos del tester. Entre los cambios que los testers deben tener en cuenta se podrían citar: 

Debe probar dentro de cada iteración y no al final del ciclo de vida del producto.



Debe determinar qué probar, cuánto y en qué orden cuando el producto está aún sin terminar, para esto debe colaborar con otros miembros del equipo, en lugar de trabajar en solitario.



La fase de análisis comienza al mismo tiempo que para el equipo de desarrollo. En las metodologías tradicionales el equipo de testing comienza su etapa de análisis cuando ya el producto está terminado, sin embargo, en las metodologías ágiles a medida que se va diseñando el producto, el equipo de desarrollo va pensando cómo va a implementar las funcionalidades planeadas para el sprint y el tester va pensando cómo va a probar las funcionalidades que se están diseñando.



Debe representar al cliente en áreas donde el cliente no tiene la habilidad para evaluar el comportamiento del producto. Un buen

“VII Taller Internacional de Calidad en las Tecnologías de la Información y las Comunicaciones”

Veloso, A.; Aleaga, D. | “MODELO PARA LA INTEGRACIÓN DEL TESTING EN LA METODOLOGÍA SCRUM”

tester siempre se pone en la posición del usuario final, y ayuda de esta forma a todo el equipo a aumentar su comprensión de los requerimientos y de las pruebas de aceptación, llamando la atención sobre temas que no siempre se tienen en cuenta en las reuniones de diseño como son rendimiento, carga, concurrencia, validaciones de campos, entre otros. 

Debe lidiar con requerimientos cambiantes y mal documentados, o completamente indocumentados. El tester debe tener en cuenta cuáles técnicas de prueba va a utilizar, pues una buena parte de ellas están basadas en una documentación exhaustiva y comprensible de los requerimientos, necesitando para esto que dichos requerimientos no sean modificados. Para lograr ser efectivo y eficiente en este ambiente cambiante debe buscar individualmente información del producto a través de las pruebas, basándose fundamentalmente en las pruebas exploratorias.

4. PROPUESTA DE MODELO En la Figura 1 se muestra un diagrama de funcionamiento de un equipo de proyecto en el cual está integrado uno o varios testers. En este equipo de proyecto se siguen los pasos establecidos por la metodología SCRUM: se confecciona la pila del producto con los clientes, a partir de ésta se confecciona la pila del sprint y posteriormente se diseñan las historias de usuario y pruebas de aceptación. En la confección de la pila del producto, las historias de usuario y las pruebas de aceptación participa todo el equipo, incluyendo al tester o equipo de testing.

Figura. 1: Modelo de funcionamiento de un equipo de proyecto

Es a partir del diseño de las pruebas de aceptación que el trabajo del tester o el equipo de testing diverge de la concepción tradicional del Scrum, pues a partir de estas pruebas de aceptación es que el tester confecciona la pila del producto de testing. Para esto el tester debe analizar todas las pruebas de aceptación diseñadas y seleccionar cuáles son automatizables y cuáles vale la pena automatizar, así como establecer un orden de prioridad para cada una de ellas, tal y como se hace con la pila del producto del equipo de desarrollo. Esta lista de todas las pruebas de aceptación automatizables se convierte en la pila del producto de testing. A partir de la pila del producto de testing se elabora la pila del sprint de testing, la cual es el listado de las pruebas de aceptación que serán automatizadas en el sprint. En caso de que sea un equipo de testing, el jefe de este equipo debe asumir el rol de dueño del producto, o sea, es quien debe encargarse de gestionar la pila del producto de testing y asignarle prioridad a las tareas. A la vez que el equipo de desarrollo trabaja en codificar las historias de usuario, el equipo de testing trabaja en la elaboración de la pila del sprint de testing y luego en la codificación de las pruebas automáticas. En este punto de la codificación de las pruebas se pueden hacer dos variantes: se podrían codificar las pruebas de aceptación automatizables correspondientes a funcionalidades que están siendo implementadas por el equipo de desarrollo, o se pueden codificar las pruebas correspondientes a funcionalidades implementadas en sprint anteriores. La primera de las variantes es la más difícil de llevar a cabo, puesto que esto precisa de una enorme disciplina por parte de los programadores y del tester, pues requiere que ambas partes estén de acuerdo con la forma en que se va a implementar la funcionalidad y ninguna de las partes viole este acuerdo, o sea, que si ambas partes acuerdan un nombre para un componente, no pueden violarlo, de lo contrario el script de pruebas automáticas no va a poder referenciar dicho componente, con lo cual el script es un completo fracaso, y con él fracasa todo el sprint de testing. En esta variante después que han sido codificadas las pruebas automáticas se ejecutan estas pruebas y se garantiza con esto que las funcionalidades implementadas cumplen con los requisitos planteados en el sprint. La segunda variante es un mucho más fácil de poner en práctica, debido a que no se hace necesario un acuerdo previo entre el equipo de

“VII Taller Internacional de Calidad en las Tecnologías de la Información y las Comunicaciones”

Veloso, A.; Aleaga, D. | “MODELO PARA LA INTEGRACIÓN DEL TESTING EN LA METODOLOGÍA SCRUM”

desarrollo y el tester, puesto que este último trabaja con interfaces y componentes ya desarrollados. Después que la pila del sprint de testing ha sido cumplida, se ejecutan manualmente las pruebas de aceptación correspondientes a las nuevas funcionalidades implementadas por el equipo de desarrollo en el sprint. Siguiendo cualquiera de las variantes anteriores, antes de pasar al próximo sprint, se ejecutan las pruebas automáticas creadas en sprint anteriores, con lo cual se garantiza que las funcionalidades implementadas, y que ya se dan por “hechas” no han sido afectadas con la inserción de nuevos errores (pruebas de regresión). A pesar de la cantidad de pruebas automáticas con las que se cuente, la necesidad de las pruebas manuales es incuestionable. Las pruebas de un sistema no se pueden confiar solamente a las pruebas automáticas. Después que se crea un script de pruebas automático, este siempre ejecutará la misma secuencia de pasos en el mismo orden. Se hace indispensable la participación de un ser humano, alguien que cambie el orden de esta secuencia y que haga cosas que a nadie se le había ocurrido hacer. Teniendo en cuenta lo anterior, es que se ha considerado en el modelo un paso donde se ejecuten pruebas manuales, especialmente pruebas exploratorias. Ambas pruebas, las pruebas exploratorias y las automáticas, se llevan a cabo en paralelo, puesto que un tester puede mandar a ejecutar las pruebas automáticas y a la vez puede estar ejecutando pruebas exploratorias. Las pruebas exploratorias para este paso no se han seleccionado al azar, sino que han sido escogidas debido a que esta es una forma particularmente efectiva de detectar errores cuando no se tiene una documentación exhaustiva. En este tipo de pruebas “simultáneamente se aprende del software, se diseñan las pruebas y se ejecutan” [6], y “un efecto secundario muy valioso de las pruebas exploratorias es el conocimiento que se adquiere con él. Se revelan áreas del producto que pueden ser utilizadas para más pruebas automáticas y brinda ideas para características nuevas” [8]. Siguiendo las ideas anteriores, las pruebas exploratorias se utilizan para conocer mejor el producto y para enriquecer la pila del producto de testing; así como también, para optimizar y hacer ajustes en los scripts de pruebas automáticas ya existentes. Durante las pruebas manuales siempre serán detectadas no-conformidades, las cuales son analizadas por todo el equipo asignándoles prioridad en su solución. Algunas no-conformidades muy difíciles de solucionar pueden ser agregadas a la pila del producto con vistas a su solución en próximos sprints.

Con este paso de pruebas se cierra el ciclo, todo el equipo se pone en función de analizar la pila del producto y planificar qué se va a hacer en el sprint, o sea, a elaborar la pila del sprint repitiendo nuevamente todos los pasos anteriormente descritos. 5. CONCLUSIONES Existe una enorme cantidad de bibliografía relacionada con las metodologías ágiles y sus muchas ventajas, no obstante, ninguna metodología es un “traje a la medida”, cualquiera sea la metodología elegida, debe ser modificada y ajustada al contexto de la organización donde vaya a ser implantada. El modelo propuesto en el presente trabajo vincula los conceptos de desarrollo ágil de software, testing ágil y de tester insertado en un equipo Scrum. Conceptos que siempre han sido vistos como disjuntos, aquí se presentan como un único modelo integrado, permitiendo complementar las ventajas de cada uno de ellos, dando como resultado un modelo más versátil y fácil de aplicar a organizaciones practicantes de la metodología Scrum y a la vez interesadas en mantener testers o equipos de testing para la validación de sus productos. Este modelo propuesto se aplicó durante 3 años a varios proyectos de la División Santiago de la empresa DATYS1, demostrando buenos resultados en su facilidad de implantación y efectividad en la detección y corrección temprana de errores. 6. REFERENCIAS BIBLIOGRÁFICAS 1. Schwabert, K. y Sutherlan, J: "La Guía de Scrum", [En línea]. 2011. [Consultado el: 7 de mayo de 2013]. Disponible en: http://www.scrum.org/Portals/0/Documents/Scrum% 20Guides/Scrum_Guide%202011%20%20ES.pdf#zoom=100 2. Palacio, J.: "ScrumManager: Gestión de Proyectos", [En línea]. 2008. [Consultado el: 18 de abril de 2013]. Disponible en: http://www.lulu.com/content/3671394. 3. Schwabert, K.: "Agile Project Management with Scrum", Ed. Microsoft Press, 2004. 4. Black, R.: "How Agile Methodologies Challenge Testing", Agile Record, No. 1, pp. 20-25, 2010. 5. Kniberg, H.: "SCRUM y XP desde las trincheras", [En línea], 20007. [Consultado el: 6 de mayo de 2013]. Disponible en: 1

http://www.datys.cu

“VII Taller Internacional de Calidad en las Tecnologías de la Información y las Comunicaciones”

Veloso, A.; Aleaga, D. | “MODELO PARA LA INTEGRACIÓN DEL TESTING EN LA METODOLOGÍA SCRUM”

http://www.infoq.com/minibooks/scrum-xp-fromthe-trenches. 6. Patton, R.: "Software Testing", Ed. Sams Publishing, 2005. 7. Myers, G.: "The art of software testing (3ra Edición)", Ed. John Wiley & Sons, Inc., New Jersey, 2011. 8. Crispin, L. y Gregory, J.: "Agile Testing: A Practical Guide for Testers and Agile Teams", Ed. Addison-Wesley, Indiana, 2009. 7. SÍNTESIS AUTORES

CURRICULARES

DE

LOS

Nacido el 13 de abril de 1981 en la ciudad de Santiago de Cuba. Se graduó en el año 2005 de Ingeniero en Automática en el Instituto Superior Politécnico “Julio Antonio Mella” (ISPJAM) de Santiago de Cuba. Desde su graduación trabaja en la División Santiago de Cuba de la Empresa para el Desarrollo de Aplicaciones, Tecnologías y Sistemas (DATYS) como tester de software. Actualmente se desempeña como jefe del Grupo de Pruebas y Calidad de la mencionada división de DATYS.

Andrés Veloso Jardón:

“VII Taller Internacional de Calidad en las Tecnologías de la Información y las Comunicaciones”