Licencia Creative Commons

i

MEJORAMIENTO DE LA METODOLOGÍA DE PRUEBAS ÁGILES EN GREENSQA, APOYADO EN LA GESTIÓN DEL CONOCIMIENTO

DIANA CAROLINA GUTIÉRREZ CONTRERAS

Universidad Cooperativa de Colombia

Facultad de ingeniería

Programa de Ingeniería de sistemas

Cali - 2019

ii

MEJORAMIENTO DE LA METODOLOGÍA DE PRUEBAS ÁGILES EN GREENSQA, APOYADO EN LA GESTIÓN DEL CONOCIMIENTO

DIANA CAROLINA GUTIÉRREZ CONTRERAS

INFORME DE DESARROLLO DE PRÁCTICA EMPRESARIAL

Orientadores de practica

JHON HAIDE CANO BELTRAN

Asesor de practica UCC

JOSEFINA MAYRA DE LLANO FELIÚ

Docente Universidad Cooperativa de Colombia

EUGENIA PATRICIA HOYOS CARVAJAL

Directora de servicios Green SQA S.A

Universidad Cooperativa de Colombia

Facultad de ingeniería

VICTOR DAVID MOSQUERA

Decano

Programa de Ingeniería de sistemas

Cali - 2019

iv

AGRADECIMIENTO

Al finalizar este trabajo quiero utilizar este espacio para agradecer a Dios por las bendiciones y por generosidad que siempre ha tenido conmigo, a mi Madre Ernestina Contreras, que ha sido un ejemplo de perseverancia, de humildad y honradez y a mi esposo Cristian Hoyos por su apoyo y paciencia en mi proyecto de vida.

Agradezco a los profesores de la Universidad Cooperativa de Colombia, Facultad de Ingeniería, por haber compartido sus conocimientos a lo largo de la preparación de nuestra profesión, de manera especial, a la profesora Josefina María de Llano Feliu quien me ha guiado en esta práctica, a GreenSQA por permitirme aportar el conocimiento adquirido en mis estudios y si mismo permitirme la adquisición de experiencias profesionales.

v

CONTENIDO

pág.

INTRODUCCIÓN .........................................................................................................................................

1. DEFINICÓN DEL PROBLEMA .................................................................................................... 2

1.1. PLANTEAMIENTO DEL PROBLEMA .................................................................................................... 2 1.2. FORMULACIÓN DEL PROBLEMA ........................................................................................................ 3 1.3. SISTEMATIZACIÓN DEL PROBLEMA ................................................................................................... 3

2. JUSTIFICACIÓN ........................................................................................................................... 5

3. OBJETIVOS .................................................................................................................................. 6

3.1. OBJETIVO GENERAL ........................................................................................................................... 6 3.2. OBJETIVOS ESPECIFICOS .................................................................................................................... 6

4. MARCO DE REFERENCIA ......................................................................................................... 7

4.1. MARCO CONTEXTUAL ....................................................................................................................... 7 4.2. MARCO TEÓRICO ............................................................................................................................... 8 4.2.1. ¿Qué es Aseguramiento de la Calidad del Software (SQA)? ..................................................... 8 4.2.2. Objetivos de las Pruebas de Software ...................................................................................... 9 4.2.3. Beneficios de las Pruebas de Software (SG Buzz, 2019). .......................................................... 9 4.2.4. Las Metodologías Ágiles ........................................................................................................... 9 4.2.5. El manifiesto ágil .................................................................................................................... 10 4.2.6. Practicas ágiles más usadas ................................................................................................... 11 4.2.7. Scrum ...................................................................................................................................... 11 4.2.8. XP (Extreme Programming) .................................................................................................... 12 4.2.9. KanBan ................................................................................................................................... 15 4.2.10. ¿Qué son las pruebas Ágiles? ................................................................................................. 16 4.2.11. Objetivo de las pruebas Ágiles ............................................................................................... 17 4.2.12. Gestión del conocimiento ....................................................................................................... 17 4.2.13. GC en el desarrollo de Software ............................................................................................. 17

5. DISEÑO METODOLÓGICO ....................................................................................................... 20

5.1. INVESTIGACIÓN APOYADA DE G+ (GESTIÓN DE CONOCIMIENTO GREENSQA) ............................... 20

6. RESULTADOS Y DISCUSIÓN DE LA PRACTICA ................................................................. 21

6.1. INSPECCIÓN DE METODOLOGÍAS ACTUALES PARA LOS PROCESOS DE PRUEBAS EN GREENSQA S.A.

21 6.1.1. Inspección de la Metodología de pruebas Funcionales .......................................................... 21 6.1.2. Inspección de la Metodología de pruebas No Funcionales..................................................... 23 6.1.3. Inspección de la Metodología de automatización de pruebas ............................................... 25 6.1.4. Presentación e inspección de la metodología actual de pruebas ágiles................................. 26 6.1.5. presentación de las mejores prácticas de agilismo en el sector ............................................. 29 6.2. MEJORAS SUGERIDAS APLICABLES A LA METODOLOGÍA DE PRUEBAS ÁGILES EN GREENSQA ........ 32 6.3. ASPECTOS METODOLÓGICOS QUE SE ESPERAN SE FORTALECER CON LAS MEJORAS SUGERIDAS .. 36 6.4. CAMBIOS A LA METODOLOGÍA APROBADOS POR GREENSQA ........................................................ 37

vi

7. CONCLISIONES ......................................................................................................................... 42

8. RECOMENDACIONES .............................................................................................................. 43

9. REFERENCIAS BIBLIOGRAFICAS ......................................................................................... 44

vii

LISTA DE FIGURAS

Ilustración 1: Maco de trabajo de Scrum .................................................................................... 12

Ilustración 2: Ciclo de vida de proyectos con metodología XP ............................................... 14

Ilustración 3 Esquema del documento de metodología de pruebas Versión 2 .................... 39

Ilustración 4 Esquema de trabajo Ágil en GreenSQA ............................................................... 40

Ilustración 5 Esquema del documento de metodología de pruebas Versión 3 .................... 41

viii

LISTA DE TABLAS

Tabla 1 Inspección de la Metodología de pruebas Funcionales ............................................. 23

Tabla 2 Inspección de la Metodología de pruebas No Funcionales ....................................... 24

Tabla 3 Inspección de la Metodología de automatización de pruebas .................................. 26

Tabla 4 Presentación e inspección de la metodología actual de pruebas ágiles ................. 29

Tabla 5 Mejores prácticas de Agilismo en el sector .................................................................. 32

Tabla 6 Mapeo de metodologías de prueba GreenSQA en ciclo ágil .................................... 33

Tabla 7 Aprobaciones planificación de la versión ............................................................. 38

Tabla 8 Aprobaciones planificación del sprint .................................................................. 38

Tabla 9 Aprobaciones ejecución de Sprint ....................................................................... 38

Tabla 10 Aprobaciones de inclusión retrospectiva ........................................................... 39

ix

ANEXOS

Anexo A. GSQA-PropuestaMejoraMAV2.pdf Anexo B. GSQA-ActaAprobacionMejorasMA.pdf Anexo C. MejoraMPA.jpeg Anexo D. GSQA-MetodologiaPruebasSoftwareAgileV2.pdf Anexo E. GSQA-MetodologiaPruebasSoftwareAgileV3.0.pdf

x

GLOSARIO

• TESTING: El testing es una actividad desarrollada para evaluar la calidad del producto, y para mejorarlo al identificar defectos y problemas (Cristián, 2009).

• BRANCHING: El BRANCHING es un concepto básico en informática. Significa una instrucción que le dice a una computadora que ejecute una parte especifica de un programa, en lugar de ejecutar las instrucciones una por una (Techopedia.com,2019). Este proceso es usado en integración continua

• MERGING: Es el proceso de tomar dos o más grupos de datos o archivos y combinar los datos en un solo conjunto unificado. La fusión genérica toma uno o más archivos y los combina en un solo archivo. Los comandos y programas de fusión más avanzados solo pueden combinar datos que son nuevos o actualizados en un archivo (Computerhope.com,2019). Este proceso es usado en integración continua.

• REFACTORING: La refactorización es el proceso de alterar el código fuente de una aplicación sin cambiar su comportamiento externo. El propósito de la refactorización del código es mejorar algunas de las propiedades no funcionales del código, como la legibilidad, la complejidad, la facilidad de mantenimiento y la extensibilidad (Techopedia.com,2019).

• PRUEBAS ALFA: Pruebas operacionales simuladas o reales por usuarios /clientes potenciales o por un equipo de pruebas independientes en el sitio de los desarrolladores, pero fuera de la organización del desarrollo (ISTQB, Business Innovations, RBCS, 2014).

• PRUEBAS BETA: Pruebas operacionales por usuarios/ clientes potenciales y/o existentes en un sitio externo sin involucrar de alguna forma a los desarrolladores, para determinar si un componente o sistema satisface las necesidades del usuario/ cliente y se ajusta a los procesos de negocio (ISTQB et al., 2014).

• HU: historias de usuario

• TDD: Desarrollo de dirigidos por pruebas.

• ATDD: Desarrollo de dirigidos por pruebas de aceptación de usuario.

• UAT: Pruebas de aceptación de usuario

• SQA: Por sus siglas en ingles aseguramiento de calidad de software.

xi

• PHVA: Planear, hacer, verificar, actuar.

• MDF (Matriz de descomposición funcional): Artefacto de GreenSQA para identificación de procesos y funcionalidades de un producto de software sujeto a pruebas.

• ATM: Automatización.

• MCP: Matriz de casos de prueba

• OAT: Por sus siglas en inglés, pruebas de aceptación operacional.

xii

RESUMEN

El propósito de este documento es presentar los resultados del desarrollo del conocimiento para generar una nueva versión de la metodología de pruebas ágiles en GreenSQA. El desarrollo de la nueva versión de metodología se hizo en el marco de la gestión del conocimiento organizacional, el cual es una guía para la identificación y desarrollo de una unidad de conocimiento que mejores los procesos organizacionales. Para llegar al documento final se analizaron cuatro de las metodologías estables de GreenSQA y las referencias de la industria del desarrollo y del aseguramiento de la calidad del de software, con el fin de consolidar las mejores prácticas de testing y agilismos en la nueva versión de metodología de pruebas ágiles, las cuales están representadas en un nuevo esquema de trabajo con etapas y actividades demarcadas, con entregables aplicables a todo proyecto de desarrollo de software.

INTRODUCCIÓN Este documento pretende presentar el proceso realizado para identificar y documentar las oportunidades de mejora aplicables a la metodología de pruebas Ágiles de GreenSQA, a partir de inspecciones realizadas a métodos de la compañía y mejores prácticas en la industria del desarrollo de software y del aseguramiento de la calidad del software. Las oportunidades de mejora identificadas obedecen a la necesidad y el interés de adoptar ampliamente el esquema de trabajo ágil, alineado a los proyectos de los clientes y a las estrategias de entregas oportunas y continuas, sin dejar de lado los estándares de calidad. Para llegar a la descripción de oportunidades de mejoras y aplicación en la metodología de pruebas ágil de GreenSQA, de realizo la inspección de las metodologías más estables que apoyan el proceso de pruebas en GreenSQA como lo son la metodología de pruebas funcionales, no funcionales y de Automatización, que a su vez sirven como apoyo para entender los procesos de la organización. En base a las inspecciones y a la investigación de las mejores prácticas de la industria del desarrollo y del aseguramiento de calidad, se de justifican los cambios en la metodología, en las etapas Análisis y diseño de pruebas. Con las cambios definidos y aprobados a la metodología, se construyó el nuevo documento de metodología de pruebas Agiles, el cual se ajusta a los lineamientos organizacionales y al servicio prestado.

2

1. DEFINICÓN DEL PROBLEMA

1.1. PLANTEAMIENTO DEL PROBLEMA

GreenSQA es una empresa de aseguramiento de calidad de software que participa en proyecto donde se desarrolla sistemas de información para organizaciones, que por lo general implementan productos de software con metodologías de desarrollo estandarizados por la industria. Estas metodologías tradicionales, se basan en procesos secuenciales en los cuales se cumplen las etapas de planteamiento, análisis, diseño, programación y pruebas. Los modelos tradicionales más conocidos son el Modelo en Cascada, Modelo en espiral, Desarrollo iterativo e incremental, entre otros. Actualmente en las empresas donde se desarrolla software se busca adoptar metodologías ágiles para el desarrollo de los proyectos en los cuales GreenSQA gana participación. Estas metodologías ágiles se fundamentan en, conceptos de entregas tempranas de software que agreguen valor a los clientes, planeadas por Sprint y a partir de historias de usuario (HU), sin esperar que la totalidad del producto esté terminado para tener software en producción. Las metodologías de trabajo ágiles se implementan actualmente en una gran cantidad de empresas, por los tanto los equipos de trabajo que intervienen en desarrollo de productos de software se deben adaptar a este tipo de esquemas. La empresa de aseguramiento de calidad GreenSQA nació con una metodología basada en metodologías estandarizadas (Modelos en Cascada, Modelos en espiral, Desarrollo iterativo e incremental, entre otros), por lo tanto, sus equipos de prueba están separados de los equipos de desarrollo de software formando lo que se denomina QA (Quality Assurance). Teniendo en cuenta este modelo de trabajo, el equipo de QA se dedican a la búsqueda de bugs en la etapa final del ciclo del desarrollo de un producto de software, planteando desde el análisis y el diseño escenarios de pruebas que garanticen el correcto funcionamiento del software, maximizando así la identificación y corrección de errores antes de su salida en ambiente de producción. Este esquema de QA busca ser adaptado a las diferentes metodologías de desarrollo de software que maneje el cliente, incluyendo las metodologías ágiles (Scrum, XP y/o Kanban). La metodología de pruebas de GreenSQA está conformada por cuatro fases estructuradas: Análisis & Planeación, Diseño, Ejecución, seguimiento y control. La metodología de pruebas ágiles de GreenSQA define lineamientos para las cuatro fases. Sin embargo, se identifica una oportunidad de mejora en el detalle procedimental para abordar la fase de análisis y diseño de pruebas. Está fase tiene como objetivo identificar los casos de prueba, en esta ocasión utilizando como insumos los entregables y dinámica generada como parte de un desarrollo Ágil. Por lo antes expuesto y teniendo en cuenta que la metodología de pruebas ágiles de GreenSQA tiene oportunidad de mejora en fases de análisis y diseño de pruebas,

3

es importante que se plantee un marco de trabajo estándar en proyectos en los cuales se implementa Agile Testing. Como propuesta de práctica empresarial para obtener el grado de Ingeniería de Sistemas de la Universidad Cooperativa de Colombia y para aportar en el mejoramiento de la ejecución de proyectos desde los procesos ágiles, se quiere realizar en la organización GreenSQA una nueva versión de la metodología de pruebas Ágiles, de modo que se pueda aplicar la fase de análisis, diseño y ejecución de pruebas con un enfoque ágil, planteando artefactos, métricas del proceso y procedimientos de control que permitan fortalecer esta línea de servicio. Esta nueva versión de la metodología se quiere desarrollar desde la gestión del conocimiento en la organización e involucrando al personal de la compañía. Para esta práctica se busca combinar las mejores prácticas agiles de industria y de los proyectos ejecutados hasta el momento para la compañía, en el ajuste de la metodología ágil de prueba de GreenSQA y las de la gestión de conocimiento, con el fin de que la metodología este dentro de la filosofía de entregas tempranas que agreguen valor, sin dejar de lado la capitalización de conocimiento organizacional e información de QA que se puede dejar al cliente como parte del servicio (Información de su producto de software que le permita toma de decisiones).

1.2. FORMULACIÓN DEL PROBLEMA

¿Cómo mejorar la metodología de pruebas ágiles de GreenSQA con ayuda de la gestión del conocimiento, en sus fases de análisis y diseño, de modo que se estandarice el método en los proyectos que trabajan bajo un marco Ágil?

1.3. SISTEMATIZACIÓN DEL PROBLEMA

¿Cómo debe estar enfocada la planeación del proceso de pruebas en proyectos que usen metodologías ágiles? ¿Qué formación y conocimiento debe tener el equipo de testing para la participación en procesos de desarrollo ágil? ¿En qué etapas o aspectos del desarrollo ágil debe participar GreenSQA para lograr un análisis y diseño de pruebas que aseguren la calidad de los productos de software orientados por este modelo de desarrollo? ¿Cómo debe ser la comunicación del equipo de prueba con el equipo de desarrollo y el representante del cliente para que se logre la calidad no solo del producto de desarrollo sino del ciclo de vida del desarrollo ágil?

4

¿Cuáles deben ser los entregables del equipo de pruebas para lograr evidenciar la calidad del producto de desarrollo?

5

2. JUSTIFICACIÓN

La motivación de actualizar la metodología Ágil estándar de GreenSQA es identificar y aplicar las oportunidades de mejora que permita una evolución del proceso de pruebas ágil en proyectos que implementen software con métodos de desarrollo ágil, de tal forma que los clientes encuentren en GreenSQA una organización que los apoye en el aseguramiento de calidad en cada entrega del equipo de desarrollo para la salida a producción. Se busca que el equipo de prueba tenga un mejor acople a la metodología ágil usada por el cliente, a fin de que brinde respuestas acordes en cada etapa del proyecto y así mismo le proporcione indicadores que permitan la toma de decisiones de las entregas. Como beneficio al cliente y a la compañía, el equipo de pruebas tendrá una mejoría en su participación en un proyecto ágil, en las actividades que debe ejecutar, como debe usar los artefactos en cada etapa del proceso de pruebas ágiles, con quienes debe interactuar y cuáles deben ser sus entregables para que así haya una fluidez e interacción oportuna en las actividades y con cada integrante del proyecto (desarrollo y cliente). Lo anterior mejora la experiencia del servicio de los usuarios, además de permitir que el equipo de pruebas y la organización tengan una reacción apropiada y cómoda en este tipo de proyectos.

6

3. OBJETIVOS

3.1. OBJETIVO GENERAL

Mejorar la metodología de pruebas ágiles que tiene GreenSQA en sus fases de Análisis y diseño, haciendo uso del modelo de gestión del conocimiento de GreenSQA.

3.2. OBJETIVOS ESPECIFICOS

• Inspeccionar las actividades actuales de pruebas de GreenSQA, las actividades estándares de la metodología ágil e identificar oportunidades de mejora aplicables a la metodología de pruebas Ágil de la compañía, en el marco de la gestión del conocimiento. • Definir los aspectos de la metodología a los que serán aplicables las oportunidades de mejora identificadas. • Justificar al comité de mejoramiento GreenSQA la propuesta de ajustes a la metodología de pruebas ágiles, aplicables a las etapas de planeación, el análisis y diseño de pruebas. • Producir desde la gestión del conocimiento de GreenSQA, las mejorar a la metodología de pruebas, según lo aprobado por el comité de mejoramiento de GreenSQA.

7

4. MARCO DE REFERENCIA Las metodologías ágiles resuelven los problemas surgidos, posteriormente, a la masificación del uso del computador personal, dado que las expectativas y necesidades por parte de los usuarios se hicieron más urgentes y frecuentes. Fue así como a comienzo de los 90 surgieron propuestas metodológicas para lograr resultados más rápidos en el desarrollo de software sin disminuir su calidad. Después de casi una década de esfuerzos aislados, en febrero de 2001 en Utah-EE. UU., se reunieron 17 empresarios de la industria del software1 y como resultado del debate respecto a las metodologías, principios y valores que deben regir el desarrollo de software de buena calidad, en tiempos cortos y flexible a los cambios, se aceptó el término ágil para hacer referencia a nuevos enfoques metodológicos en el desarrollo de software. En esta reunión se creó “The Agile Alliance”, organización sin ánimo de lucro dedicada a promover los conceptos relacionados con el desarrollo ágil de software y acompañar a las organizaciones para que adopten dichos conceptos. Como punto de partida o base fundamental de las metodologías ágiles se redactó y proclamó el Manifiest for Agile software development, © 2001. Por su parte, el testing ágil refiere un enfoque dinámico de las pruebas de software. Dicho enfoque supone que los requerimientos no son estables, sino que se incrementan de forma continua o se encuentran en constante cambio, de acuerdo a las necesidades expresadas por el cliente. Asimismo, el cliente también juega un rol muy importante manteniendo una comunicación cercana y continua con el equipo de desarrollo; la obtención de sus necesidades (requerimientos) no se considera como una fase separada del desarrollo del software, sino una parte integral del mismo. Mientras que en las metodologías tradicionales las actividades de prueba normalmente se pueden iniciar hasta que la especificación de requisitos se encuentre completa, en el caso del testing ágil dichas tareas quedan inmersas dentro de cada iteración (SG Buzz, 2019

4.1. MARCO CONTEXTUAL

GreenSQA es una empresa inicio como emprendimiento en ParqueSoft desde octubre de 2002. Hoy en día tiene más de 120 empleados altamente calificados, con más de 10.000 proyectos exitosos y con experiencia nacional e Internacional (USA, Panamá, Guatemala, México, Bolivia). GreenSQA cuenta con 3 Certificados de derechos de autor del Ministerio del Interior y de Justicia.

Por otro lado, GreenSQA hace parte de Grupos Internacionales ISO como lo son ISO29110 Software Life Cycle Profiles for Very Small Entities (VSEs) y ISO29119

8

Software Testing, Además de tener Membresías Internacionales en Working Committee of TMMi® Foundation, HASTQB – Hispanic America Software Testing Qualification Board, Member of I. Association for Computerized Adaptive Testing, IACAT y ASQ Global community members. Hoy en día en la metodología de GreenSQA se define los enfoques de planeación, análisis, diseño y ejecución de pruebas, detallando ampliamente como se debe aplicar cada una de estas etapas a los proyectos de software. A hoy, la metodología está en la versión número 18, ya que año a año la ha ido mejorando para adaptarse al mundo cambiante de la ingeniería de software. Desde el enfoque de desarrollo Ágil, GreenSQA ha identificado por su parte la necesidad de adaptarse a este marco de trabajo, por lo que desde el presente año ha empezado a levantar un esquema de trabajo general que le permita la participación en proyectos ágiles, haciendo uso de su metodología actual. Adicional a esto, inicio proceso de capacitaciones a una selección de su equipo de trabajo para la comprensión y certificación en las mejores prácticas de pruebas desde el enfoque de las metodologías ágiles, además de tener participación y experiencia en este tipo de proyectos (http://greensqa.com, 2018).

4.2. MARCO TEÓRICO

4.2.1. ¿Qué es Aseguramiento de la Calidad del Software (SQA)? En la actualidad, la calidad es un factor determinante del éxito de los proyectos de software por lo cual se ha vuelto centro de atención de muchos organismos que se han dedicado a producir estándares con el objetivo de realizar productos que realmente cumplan con los requerimientos exigidos por los usuarios. Pero realmente ¿qué es lo que garantiza que una aplicación de software cumpla con los requisitos exigidos por los estándares de calidad?, el Aseguramiento de Calidad, que es un conjunto de actividades planificadas que se realizan durante todo el ciclo de desarrollo del mismo, con el propósito de prevenir, detectar, y controlar las no conformidades funcionales del producto y tomar correctivos en el momento adecuado evitando costos de reproceso y brindando satisfacción integral al usuario final cuando reciba el producto (SG Buzz, 2019). El aseguramiento de calidad de software posee unos pasos o grupos de actividades bien definidos. Entre ellos encontramos: • Controlar la aplicación correcta y efectiva de procedimientos y prácticas existentes, en los proyectos de desarrollo de software. • Medir la calidad del producto de software y determinar su liberación. • Mejorar los procesos para reducir la posibilidad de incorporación de no conformidades en futuros productos.

9

Para medir la calidad de un software de tamaño considerable, es prácticamente imposible probar todos los diferentes caminos lógicos y todas las combinaciones de datos de entrada, por lo tanto, unos de los principales objetivos de los probadores de software es determinar un subconjunto representativo de aquel número infinito de opciones.

4.2.2. Objetivos de las Pruebas de Software Los principales objetivos de las pruebas de software:

• Detectar no conformidades antes de que el producto sea instalado en el cliente o usuario final.

• Garantizar la aceptación de los productos por parte de los clientes o usuarios finales.

• Asegurar que el producto (Sistema) esté listo para ser utilizado desde el punto de vista operacional.

• Mostrar que cada una de las partes del producto funciona correctamente. • Mejoramiento en la satisfacción de clientes o usuarios finales.

Adicionalmente, las pruebas de software tienen objetivos de fortalecimiento interno para el equipo de desarrollo como:

• Optimización del esfuerzo de reproceso de producto. • Apropiación de la cultura de calidad por parte del equipo humano. • Equipo humano entrenado en las áreas claves del proceso de aseguramiento

de calidad de software (SG Buzz, 2019).

4.2.3. Beneficios de las Pruebas de Software (SG Buzz, 2019). • Incrementan la productividad del equipo de desarrollo. • Facilitan la detección temprana de no conformidades. • Ser un mecanismo objetivo para asegurar que los requerimientos de los

productos se cumplen. • Ser una evaluación objetiva de los resultados.

4.2.4. Las Metodologías Ágiles Las metodologías ágiles son flexibles, pueden ser modificadas para que se ajusten a la realidad de cada equipo y proyecto.

De acuerdo a la metodología pruebas de software, GreenSQA – versión: 18.0, los proyectos ágiles se subdividen en proyectos más pequeños mediante una lista

10

ordenada de características. Cada proyecto es tratado de manera independiente y desarrolla un subconjunto de características durante un periodo de tiempo corto, de entre dos y seis semanas. La comunicación con el cliente es constante al punto de requerir un representante de él durante el desarrollo. Los proyectos son altamente colaborativos y se adaptan mejora los cambios; de hecho, el cambio en los requerimientos es una característica esperada y deseada, al igual que las entregas constantes al cliente y la retroalimentación por parte de él. Tanto el producto como el proceso son mejorados frecuentemente (Gomez & Hoyos, 2015(.

4.2.5. El manifiesto ágil Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, El manifiesto ágil es un documento que resume en cuatro valores y doce principios con las mejores prácticas para el desarrollo de software según los autores, basados en la experiencia de 17 industriales del software, en procura de desarrollos más rápidos conservando su calidad. Los 4 valores y 12 principios se presentan a continuación.

Valores

Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. Manifiest for Agile software development, © 2001. Principios:

• Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

• Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

• Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

• Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

• Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

11

• El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

• El software funcionando es la medida principal de progreso. • Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

• La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

• La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

• Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.

• A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

4.2.6. Practicas ágiles más usadas

4.2.7. Scrum En La Guía Definitiva de Scrum: Las Reglas del Juego, Desarrollado y soportado por Ken Schwaber y Jeff Sutherland, Julio de 2013, se presenta a Scrum como un marco de trabajo por el cual las personas pueden acometer problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente. Scrum es:

• Ligero

• Fácil de entender

• Extremadamente difícil de llegar a dominar Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo. Tres pilares soportan toda la implementación del control de procesos empírico: transparencia, inspección y adaptación. El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo de Desarrollo (Development Team) y un Scrum Máster. Los Equipos Scrum son autoorganizados y multifuncionales. Los equipos autoorganizados eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo. Los equipos multifuncionales tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la

12

creatividad y la productividad. Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación. Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.

Ilustración 1: Maco de trabajo de Scrum

En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo (time-boxes), de tal modo que todos tienen una duración máxima. Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse. Los demás eventos pueden terminar siempre que se alcance el objetivo del evento, asegurando que se emplee una cantidad apropiada de tiempo sin permitir desperdicio en el proceso. Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos de Scrum constituye una oportunidad formal para la inspección y adaptación de algún aspecto. Estos eventos están diseñados específicamente para habilitar las vitales transparencia e inspección. La falta de alguno de estos eventos da como resultado una reducción de la transparencia y constituye una oportunidad perdida para inspeccionar y adaptarse.

4.2.8. XP (Extreme Programming) En la Universidad ORT Uruguay se presentan a XP como una metodología ágil para pequeños y medianos equipos, desarrollando software cuando los requerimientos son ambiguos o rápidamente cambiantes. A diferencia de los procesos tradicionales para desarrollar software, XP asume el cambio como algo natural, y que,

13

indefectiblemente, en alguna etapa de un proyecto sucede. En XP se realiza el software que el cliente solicita y necesita, en el momento que lo precisa, alentando a los programadores a responder a los requerimientos cambiantes que plantea el cliente en cualquier momento. Esto es posible porque está diseñado para adaptarse en forma inmediata a los cambios, con bajos costos asociados, en cualquier etapa del ciclo de vida. En pocas palabras, XP “abraza” el cambio (Calabria & Píriz, 20013). Para poder implementar las prácticas que presenta XP hay que conocer cuáles son los valores principales que hacen a esta mitología. Estos valores son:

• Comunicación: En XP se trata de mantener una buena comunicación mediante un conjunto de prácticas que no se pueden realizar sin tener una buena comunicación en el equipo.

• Simplicidad: XP apuesta a realizar algo simple hoy y destinar un poco más de esfuerzo para realizar un cambio en el futuro, a realizar algo más complicado hoy y no utilizarlo nunca.

• Feedback: Brindar un feedback correcto y preciso hace que se pueda mantener una buena comunicación y conocer el estado actual del proyecto.

• Coraje: Simplicidad y el feedback forman el coraje, el cual se convierte en el objetivo de XP. El coraje también es poder realizar cambios cuando algo no funciona del todo bien, diseñar e implementar solo lo necesario para el presente, pedir ayuda o reducir el alcance de una entrega si el tiempo no alcanza

Los cuatro valores mencionados anteriormente – comunicación, simplicidad, feedback y coraje – nos brindan un estándar para obtener buenos resultados. Sin embargo, los valores son muy vagos a la hora de ayudarnos a decidir que prácticas utilizar. Para ello se necesita destilar estos valores en principios que puedan ser utilizados. A continuación, se detallan los principios más importantes de XP.

• Rápida retroalimentación

• Asumir la simplicidad

• Cambios incrementales

• Aceptar el cambio

• Trabajo de calidad Para lograr los objetivos del proyecto siendo fieles a la filosofía XP, se ha planteado un ciclo de vida que da respuesta a esto.

14

Ilustración 2: Ciclo de vida de proyectos con metodología XP

El ciclo de vida de XP consiste básicamente de seis fases: Exploración, Planificación, Iterations to Release, Producción, Mantenimiento y Muerte.

✓ Exploración: En esta fase los clientes realizan las story cards que desean que estén para la primera entrega. Cada story describe una de las funcionalidades que el programa tendrá. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, la tecnología y las prácticas a ser utilizadas durante el proyecto. En algunos casos se utiliza un prototipo para testear la nueva tecnología y explorar algunos aspectos de la arquitectura a ser implementada. La duración de esta fase puede extenderse desde unas pocas semanas a varios meses dependiendo de la adaptación del equipo de desarrollo.

✓ Planificación: El objetivo de esta fase es fijar la prioridad de cada una de las stories y se establece cual va a ser el contenido de la primera entrega. Los programadores estiman cuanto esfuerzo requiere cada story y se establece el cronograma. La duración del calendario para la entrega del primer release no suele superar los dos meses. Duración de la fase de planificación en sí no toma más de dos días.

✓ Iteraciones por entregas: Esta fase incluye varias iteraciones del sistema antes de la entrega del primer release. El calendario es dividido en un número iteraciones de tal manera de que cada iteración tome de una a cuatro semanas de implementación. En la primera iteración se crea un sistema que abarca los aspectos más importantes de la arquitectura global. Esto se logra seleccionando las stories que hagan referencia a la construcción de la estructura de todo el sistema. El cliente decide que stories van a ser implementadas para cada iteración. Además, se realizan los test funcionales,

15

realizados por el cliente, al final de cada iteración. Al final de la última iteración el sistema está listo para ser puesto en producción.

✓ Producción: La fase de producción requiere realizar muchos más chequeos y testing antes que el sistema sea entregado al cliente. En esta fase aparecen nuevos cambios y se tiene que decidir si serán incorporados o no en dicha entrega. Durante esta fase suele suceder que las iteraciones se aceleren de tres a una semana. Las ideas pospuestas y las sugerencias son documentadas para luego ser implementadas más adelante, por ejemplo, en la fase de mantenimiento. Luego que el primer release es creado, el proyecto debe mantener el sistema en producción corriendo mientas se trabaja en las nuevas iteraciones.

✓ Mantenimiento: En esta fase por lo general se necesita un esfuerzo extra de los programadores para satisfacer los requerimientos del cliente. Por este motivo la velocidad de desarrollo suele disminuir una vez que el sistema es puesto en producción. A raíz de esto se requiere incorporar nuevos integrantes al equipo y cambiar la estructura del equipo.

✓ Muerte: Esta última fase se acerca una vez que el cliente no tiene ninguna story a ser implementada. Los requerimientos del sistema deben ser satisfechos en otros aspectos como ser la performance o la confiabilidad de este. Esta es la etapa en la cual no hay más cambios en la arquitectura, el diseño o el código y aquí es cuando se realiza la documentación correspondiente. Esta fase aparece también, cuando el sistema no da los resultados deseados o se vuelve demasiado caro para seguir siendo desarrollado.

4.2.9. KanBan En el Manual de Metodologías Ágiles, Versión 1 - agosto de 2016, el término KanBan viene del japonés: “Kan”, visual, y “ban”, tarjeta. Kanban permite visualizar el flujo de trabajo en una barra de tareas a través de tarjetas. Nos propone distribuir las mismas en una serie de columnas. Kanban trabaja con tableros que pueden ser tanto físicos como digitales y permite una visualización clara de todas las tareas a realizar, en qué etapa está cada una y quién es el encargado de estas. Los nombres que les asignemos a cada columna son arbitrarios, lo importante es que sean funcionales a nuestros objetivos como organización y que nos resulten claros.

✓ Tareas: En esta columna van todas aquellas tareas que deben ser realizadas

(es muy importante para que no se nos olvide ninguna). Luego, se van a ir priorizando estas tareas según su nivel de urgencia e importancia y van a cambiar de columna.

16

✓ Pendiente: En esta columna colocamos aquellas tareas que van a pasar a la columna “En curso” en cuanto ésta se despeje.

✓ En curso: Aquí van las tareas que estamos realizando en el momento presente. Es muy importante no sobrecargarla ya que si lo hiciéramos esta sistematización pierde sentido (volveríamos a tener una lista interminable de tareas sin ningún tipo de jerarquización ni organización).

✓ Terminado: Una vez finalizadas las tareas de la columna anterior pasan a ésta. Si bien una vez terminadas se podría descartar la tarjeta, Kanban nos propone esta cuarta columna para que el equipo pueda visualizar los logros y sentirse motivado a continuar.

Se puede agregar una 5ta columna: “Algún día/Tal vez”. En la misma podemos depositar todas las ideas que no son urgentes, pero nos gustaría llevar a cabo algún día cuando tengamos más tiempo o más recursos. Kanban nos ofrece una mejora considerable en lo referente a la comunicación interna de nuestra organización ya que con sólo mirar el tablero podemos saber quién está trabajando en qué cosa. Otro de los aspectos claves de esta metodología es la limitación de las tareas en curso. Todo el tiempo nuevos proyectos están ingresando a nuestras organizaciones lo cual puede generar un estado de caos. Tener una lista enorme de tareas por hacer no nos deja priorizar ni enfocar nuestra concentración en lo que es importante o urgente. Al tener un número limitado de tareas asignadas en la columna “En curso” permite una concentración mayor y ayuda a gestionar mejor el ritmo de trabajo. Dentro de las practicas Kanban se establecen reuniones rápidas de todo el equipo alrededor del tablero, para que cada miembro cuente en qué está trabajando y en qué etapa se encuentra. En este breve encuentro se reenfocan las prioridades. Estas reuniones no deben tener una duración mayor a 15 minutos y pueden realizarse diariamente o de manera más espaciada (dependiendo de las necesidades y posibilidades de cada organización).

4.2.10. ¿Qué son las pruebas Ágiles?

Las pruebas ágiles hacen referencia a un enfoque dinámico de las pruebas de software. Este enfoque supone que los requerimientos del producto de software no son estables y estáticos desde el inicio del proceso, sino que se incrementan de forma continua, de acuerdo a las necesidades expresadas por el cliente. En este tipo de pruebas, el cliente también representa un rol muy importante y mantiene una comunicación cercana y continua con el equipo de desarrollo de software; la obtención de requerimientos hace parte integral del proceso. Es el modelo de pruebas que considera planeación, diseño y ejecución de pruebas durante la etapa de desarrollo de software, considerando iteraciones cortas, refactorizaciones e integraciones continuas (SG Buzz, 2019).

17

4.2.11. Objetivo de las pruebas Ágiles

Las pruebas ágiles tienen como objetivo principal guiar el desarrollo del software, sustituyendo de esta manera la definición formal de requisitos. Como consecuencia natural de este objetivo se logra un producto de software de calidad alineado con las necesidades requeridas por el cliente (SG Buzz, 2019).

4.2.12. Gestión del conocimiento

Peter Drucker (1993) decía que el conocimiento, por encima del capital o la mano de obra, es el único recurso económico con sentido en la Sociedad de Conocimiento y Peter Senge (1990) advertía que muchas organizaciones no podrían funcionar como organizaciones de conocimiento porque no podían aprender (learning disablilties).

En la actualidad nos encontramos en una era denominada la “Sociedad del Conocimiento” caracterizada principalmente por la aparición continua de nuevo saber, con amplias posibilidades de divulgación y donde la empresa pasa a ser concebida desde la idea de un “conjunto de activos tangibles organizados en un determinado proceso productivo para lograr unos objetivos concretos”, hasta su consideración actual como “conjunto de activos intangibles, generadores de un capital intangible o capital intelectual” E. Bueno, La Gestión del Conocimiento nuevos perfiles profesionales, junio 1999. La GC es un proceso a través del cual las organizaciones logran descubrir, utilizar y mantener el conocimiento que poseen, con la idea de alinearlo con las estrategias de negocio para la obtención de ventajas competitivas. La gestión de los recursos intangibles tiene como objetivo convertir el capital humano (habilidades, conocimientos, etc.) en capital estructural (conocimiento organizacional o lo que queda cuando los empleados se van a sus casas), reduciendo el riesgo de perder valioso conocimiento si la gente deja la organización. De esta, manera lo importante no es retener a las personas, sino que mantener y mejorar los sistemas de manera de poder continuar generando conocimiento (Crawford, 2018).

4.2.13. GC en el desarrollo de Software La Ingeniería de Software es un proceso intensivo de conocimiento, donde interactúan usuarios y desarrolladores. El usuario brinda una concepción de la funcionalidad esperada y el desarrollador especifica esta funcionalidad a partir de esta primera concepción mediante aproximaciones sucesivas. Este ambiente de interacción motiva la búsqueda de estrategias robustas para garantizar que los requisitos del usuario sean descubiertos con precisión y que además sean expresados en una forma correcta y sin ambigüedad, y que sea verificable, trazable y modificable. El crear y compartir conocimiento son relevantes para cualquier

18

enfoque de desarrollo de software, los enfoques de desarrollo tradicionales han facilitado el compartir conocimiento a través de documentación intensiva, pero actualmente se puede observar numerosos métodos que valoran más el uso de fuertes interacciones con usuarios (Crawford, 2018). Los métodos, herramientas y las actuales implementaciones de GC en muchas compañías han seguido también estos dos caminos: documentación intensiva e interacciones. En GC estos enfoques se han denominado Enfoque Centrado en el Producto y Enfoque Centrado en el Proceso. El Enfoque Centrado en el Proceso, al igual que los Métodos Agiles, principalmente considera la GC como un proceso de comunicación y colaboración. Donde el conocimiento está estrechamente relacionado con la persona que lo desarrolla y es compartido con otros a través de contactos personales (Crawford, 2018). Cuando se compara métodos ágiles y tradicionales, hay autores que sugieren utilizar el término enfoques Taylorianos para referirse a las metodologías tradicionales, (Chau & Maurer,2004). Argumentando que otros términos también utilizados para referenciarlos, como métodos planificados o disciplinados, no son los más adecuados. Ya que los métodos ágiles también son disciplinados e involucran tareas de planificación, la diferencia radica en el alcance de esta planificación, no en su inexistencia. Las metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo de software, con el objetivo de asegurar que el producto que se obtenga satisfaga los requerimientos del usuario y reúna estándares aceptables de calidad. El trabajo de planificación es riguroso, aun cuando en la práctica muchas veces estas planificaciones no se respetan. En contraposición, las metodologías ágiles aportan nuevos métodos de trabajo que apuestan por una cantidad apropiada de procesos. Es decir, no se desgastan con una excesiva cantidad de cuestiones administrativas (planificación, control, documentación) ni tampoco defienden la postura extremista de total falta de proceso. Ya que se tiene conciencia de que se producirán cambios, lo que se pretende es reducir el costo de rehacer el trabajo (Manifesto for Agile Software Development, 2001).

Las metodologías ágiles son adaptativas más que predictivas. Una metodología tradicional potencia la planificación detallada y de largo alcance de prácticamente todo el desarrollo de software (ejem. Modelo Cascada). En contraste, las metodologías ágiles proponen procesos que se adaptan y progresan con el cambio, llegando incluso hasta el punto de cambiar ellos mismos. Las metodologías ágiles están orientadas más a los desarrolladores que a los procesos de desarrollo. Intentan entonces trabajar con la naturaleza de las personas (desarrolladores y usuarios) asignadas a un proyecto, más que contra ellos, de tal forma que permiten que las actividades de desarrollo de software se conviertan en una actividad de colaboración grata e interesante (Fowler, 2018). Se presentan algunas limitaciones a la aplicación de los procesos ágiles en algunos tipos de proyectos.

19

Los agilistas y sus críticos focalizan la discusión en torno a temas como la documentación y codificación. Por un lado, se sostiene que el código es el único entregable que realmente importa, desplazando el rol del análisis y diseño en la creación de software. Los críticos precisan que el énfasis en el código puede conducir a la pérdida de la memoria corporativa o conocimiento organizacional, porque hay poca documentación y modelos para apoyar la creación y evolución de sistemas complejos. (Bozo & Crawford, 2003)

20

5. DISEÑO METODOLÓGICO

5.1. INVESTIGACIÓN APOYADA DE G+ (GESTIÓN DE CONOCIMIENTO GREENSQA)

Green SQA busca aprovechar el conocimiento que se genera en la ejecución de sus proyectos y las ideas que surgen para resolver las cuestiones que llevan a desarrollar ideas innovadoras que dan solución. Con este fin motiva a sus colaboradores a que den a conocer sus ideas y así capitalizar y divulgar las píldoras de conocimiento y estrategias que permitan que todos los proyectos reutilicen las soluciones y las experiencias, para que así la posibilidad de éxito sea mayor. Para lograr esto GreenSQA ha venido trabajando con su equipo de colaboradores la gestión de conocimiento estructurando y su generación de conocimiento a partir de un modelo llamado G+, apoyado con prácticas académicas para desarrollar una metodología de generación de conocimiento y con la cual se espera se trabaje como proceso metodológico en este proyecto. El conocimiento, a partir del método experimental se aplica en secuencia sucesivas así:

✓ Identificación de unidad de conocimiento: identificación de conocimiento que quiero desarrollar en la organización.

✓ Capsula de conocimiento: planteamiento de capsula de conocimiento la cual se transformar una idea en potencial prototipo de conocimiento. Esta capsula se aplica, se comparte y se aprueba.

✓ Generación de artefactos de conocimiento: métodos, artefactos y /o herramientas aplicables en el ámbito de la organización que generan valor en el modelo de Negocio GreenSQA. Estos métodos, artefactos y /o herramientas puedes ser creados o propuestos durante esta fase o pueden identificarse ajustes o cambios en el proceso de gestión del conocimiento.

Para mayor detalle de metodología a aplicar, ver anexos II, III.

21

6. RESULTADOS Y DISCUSIÓN DE LA PRACTICA

6.1. INSPECCIÓN DE METODOLOGÍAS ACTUALES PARA LOS PROCESOS DE PRUEBAS EN GREENSQA S.A.

Para poder presentar una propuesta de mejora, se evaluaron cuatro de las metodologías definidas en GreenSQA y así tomar de ellas las mejores prácticas, de la naturaleza de procesos de la organización para incorporarla en la nueva versión de la Metodología de pruebas Ágiles. A continuación, se presentan las oportunidades de mejora aplicables a la nueva versión de metodología Ágil en las etapas de análisis y diseño de pruebas, esquematizadas asó:

• Etapa: Corresponde a la etapa de aplicación de la metodología actual y sujeta a inspección.

• Actividad: Corresponde a cada una de las tareas realizada dentro de las etapas.

• Utilidad en el negocio: Corresponde a la definición actual de la metodología de GreenSQA.

• Oportunidad de Mejora: Corresponde a las modificaciones propuestas como resultado del trabajo de inspección.

6.1.1. Inspección de la Metodología de pruebas Funcionales Etapa Actividad Utilidad en el negocio Oportunidades de mejora en las

pruebas Ágiles

ANÁLISIS Recolección de

información

Esta etapa tiene como objetivo reconocer funcional y técnicamente el alcance del producto de software e identificar la estrategia de pruebas necesarias para definir el plan de pruebas que permite su evaluación.

Esta actividad se puede involucrar en el proceso de pruebas ágiles en la actividad de planeación de la versión o sprint 0 de los proyectos de tal forma que apoye la definición del alcance, aspectos técnicos del (los) productos, los niveles de prueba, el método de pruebas y el plan de pruebas. Involucrar esta etapa además permitirá reconocer el alcance macro de los desarrollos de software y la arquitectura de estos. Dentro de esta planeación de la versión se sugiere se definan las herramientas de gestión de configuración para los diferentes entregables de pruebas (documentos, scripts, robots de prueba ATM, líneas base de diseño de pruebas y estructuras de almacenamiento en repositorios). Esta actividad también se puede llevar a cabo en la planeación de la iteración, teniendo en cuenta que

22

se planeen las actividades de acuerdo con los métodos ágiles.

Análisis de información

Permite definir el alcance de pruebas. Permite definir la estrategia de pruebas a realizar mediante la definición de los siguientes aspectos: • Alcance funcional de las pruebas • Alcance técnico de pruebas

Esta actividad se puede involucrar en el proceso de pruebas ágiles en la actividad de planeación de la versión de tal forma que apoye la definición del alcance, aspectos técnicos del (los) productos, los niveles de prueba, el método de pruebas y el plan de pruebas. Esta actividad también se puede llevar a cabo en la planeación de la iteración, teniendo en cuenta que se planeen las actividades de acuerdo con los métodos ágiles. Dentro de esta planeación se sugiere se definan las herramientas de gestión de configuración para los diferentes entregables de pruebas (documentos, scripts, robots de prueba ATM, líneas base de diseño de pruebas y estructuras de almacenamiento en repositorios).

Planeación y estrategia de

pruebas Estimación

Permite definir la estrategia de pruebas a realizar mediante la definición de los siguientes aspectos: • Estrategia de pruebas: o Tipos de pruebas o Automatización de pruebas o Reutilización de diseño de pruebas o Mecanismo de población de datos de pruebas • Estructura del equipo de trabajo • Herramientas de apoyo utilizadas • Necesidades de formación identificadas • Estimación de esfuerzo y cronograma

Esta actividad se puede involucrar en el proceso de pruebas ágiles en la actividad de planeación de la versión de tal forma que apoye la definición del alcance, aspectos técnicos del (los) productos, los niveles de prueba, el método de pruebas y el plan de pruebas. Esta actividad también se puede llevar a cabo en la planeación de la iteración, teniendo en cuenta que se planeen las actividades de acuerdo a lo métodos ágiles. Dentro de esta planeación se sugiere se definan las herramientas de gestión de configuración para los diferentes entregables de pruebas (documentos, scripts, robots de prueba ATM, líneas base de diseño de pruebas y estructuras de almacenamiento en repositorios).

DISEÑO Validación de técnicas de

prueba

Permite identificar la técnica más apropiada para la selección de casos de prueba para las funcionalidades del producto a asegurar.

Esta actividad se puede involucrar en la planeación de la Iteración/ Sprint y en la etapa de Diseño de pruebas funcionales (incremental)

23

Diseño de prueba

El ingeniero de pruebas guiado por la lógica funcional del modelo de negocio que soporta el software, consignado en la Matriz de descomposición funcional, y utilizando las técnicas de Diseño de pruebas como parte de sus instrumentos de diseño de pruebas, identifica el conjunto de requerimientos de prueba que garantiza mayor eficiencia en la fase de ejecución de estas.

Esta actividad se puede detallar en la en la etapa de Diseño de pruebas funcionales (incremental) que serán usados durante la iteración y las regresiones planeadas. Esta actividad se sugiere sea invocada en la planeación del sprint 0 y demás sprint planeados en el ciclo del proyecto. En las instancias de esta actividad se debería tener presentes las líneas base existentes y los casos de prueba generados en sprint anteriores.

Construcción de

instrumentos

Construcción de MCP Esta actividad se puede detallar en la en la etapa de Diseño de pruebas funcionales (incremental) en las cuales se deben instanciar las herramientas definidas en el sprint 0, haciendo mención especial a las herramientas colaborativas propias de GreenSQA como lo es el Ktree (herramienta aceleradora del diseño de pruebas)

Tabla 1 Inspección de la Metodología de pruebas Funcionales

6.1.2. Inspección de la Metodología de pruebas No Funcionales Etapa Actividad Utilidad en el negocio Oportunidades de mejora

en pruebas Ágiles

ANÁLISIS Recolección de

información

En esta fase se da inicio al proyecto mediante una reunión con el personal directamente involucrado en las pruebas, por parte del cliente y el personal responsable de las pruebas de GreenSQA, con el objetivo de levantar la información necesaria para la definición y realización del plan de pruebas.

Esta actividad se puede definir como parte de las actividades de la planeación de la versión

Análisis de información

Con la documentación e información necesaria, el equipo de pruebas no funcionales de GreenSQA procede a analizar e identificar la estrategia de pruebas no funcionales a seguir y los recursos necesarios para llevar a cabo el proceso de pruebas no funcionales.

Esta actividad se puede definir como parte de las actividades de la planeación de la versión y la planeación de la iteración de pruebas

24

Planeación y estrategia de

pruebas Estimación

Permite definir formalmente la estrategia de pruebas no funcionales mediante la definición de los siguientes aspectos: Alcance de las pruebas no funcionales. Alcance técnico del producto. Estrategia de pruebas no funcionales: * Tipo de pruebas. * Escenarios de pruebas. * Variables de entrada. * Variables resultados. Estructura del equipo de trabajo. Herramientas de apoyo. Estimación de esfuerzo y cronograma. GAPNF – Guía de Análisis de Pruebas No Funcionales: Guía para la selección de aspectos de pruebas no funcionales.

Esta actividad se puede definir como parte de las actividades de la planeación de la versión y la planeación de la iteración de pruebas

DISEÑO Identificación de aspectos de pruebas

Con el tipo de pruebas no funcionales, las variables y los escenarios de pruebas identificados en la planeación, se procede a especificar las variables de entrada y salida necesarias para la construcción del diseño de pruebas


Diseño de prueba

Una vez se han identificado las variables de entrada y salida, se construyen los requerimientos de pruebas no funcionales enfocados y guiados con las variables de diseño identificadas en la actividad anterior.


Generación de script

Tomando como entrada el diseño de pruebas no funcionales y la herramienta a utilizar, se procede a generar los scripts de pruebas, es decir las secuencias de pasos automáticos o simulación de procesos en condiciones técnicas que permitirán llevar a cabo las pruebas no funcionales.

Esto se puede incluir como una actividad en la actividad de proceso ágil de Automatización de pruebas Se debe indicar el manejo que se debe tener si dentro de un sprint se identifican script o robots de prueba ya construidos que requieran o no ajustes y/o preparación de fuentes de datos.

Tabla 2 Inspección de la Metodología de pruebas No Funcionales

25

6.1.3. Inspección de la Metodología de automatización de pruebas Etapa Actividad Utilidad en el negocio Oportunidades de

mejora en las pruebas Ágiles

ANÁLISIS Preparación de ambiente

Indica una lista de actividades que se deben realizar previo al inicio de las labores de arquitectura y desarrollo de automatización de pruebas de software, realizar estas actividades adelantan el camino para que en el desarrollo del sprint 0 sea más eficiente. - Selección de herramientas de automatización. - Selección de casos de prueba funcionales a automatizar.

Esta actividad se debe involucrar en el Sprint 0 de pruebas y en la etapa de diseño incremental de pruebas y de ser necesario en sprint sucesivos donde se involucre mejoras identificadas en las “Retrospectivas”

Definir estrategia de Branching &

Meging

Solicitar al cliente la explicación de la estrategia de administración del código fuente con que actualmente cuentan, de tal forma que se determine en que rama de código fuente será puesto el proyecto de pruebas automáticas

Esta actividad se debe involucrar en la definición del srpint 0 de pruebas, en la etapa de diseño incremental de pruebas y de ser necesario en sprint sucesivos donde se involucre mejoras identificadas en las “Retrospectivas”.

DISEÑO Construir el Product Backlog

Un análisis consensuado entre el cliente y los ingenieros de pruebas de GreenSQA, determina y prioriza los primeros PBIs (Product backlog ítems) que serán automatizados, se debe realizar la redacción utilizando la sintaxis Gherkin (Dado, cuando, entonces). Estos PBIs sufrirán modificaciones (Inserciones, cambios, eliminaciones) en el tiempo por lo que es importante gestionarlos en una herramienta de administración de workitems.

Esta actividad se debe involucrar en la planeación de la iteración de pruebas y en la etapa de diseño incremental de pruebas. Se debe tener en cuenta lo definido en esta actividad en las actividades de análisis de pruebas funcionales que de describan en las diferentes etapas de la metodología de pruebas ágiles.

Desarrollo Sprint 0 Creación de la arquitectura del framework de pruebas.

Esta actividad debe hacer parte del Sprint 0 en un modelo de metodologías agiles.

26

Sprint 0 /

Selección de la herramienta de automatización

De acuerdo a la tecnología involucrada en el proyecto, se debe seleccionar y/o investigar cual es o cuales son las herramientas de automatización adecuadas, para el caso de las pruebas de interfaz de usuario, las herramientas deben ser capaces de localizar y ejecutar acciones sobre los controles desplegados en pantalla.

Estas etapas se deben involucrar en la planeación de la iteración, en el diseño de pruebas incremental y en el proceso de automatización de pruebas.

Sprint 0 / Definir

estrategia de Branching &

Meging

Solicitar al cliente la explicación de la estrategia de administración del código fuente con que actualmente cuentan, de tal forma que se determine en que rama de código fuente será puesto el proyecto de pruebas automáticas.

Estas etapas se deben involucrar en el diseño de pruebas incremental y en el proceso de automatización de pruebas.

Sprint 0 / Arquitectura y Framework de

pruebas

Solicitar la conexión con un servidor de control de código fuente y luego crear la arquitectura estática (Esto es diagrama de componentes y/o diagrama de paquetes) que permita estructurar las componentes de código fuente (orientado a pruebas) dentro del proyecto de automatización.

Estas etapas se deben involucrar en el diseño de pruebas incremental y en el proceso de automatización de pruebas.

Tabla 3 Inspección de la Metodología de automatización de pruebas

6.1.4. Presentación e inspección de la metodología actual de pruebas ágiles

Hoy en día GreenSQA tiene documentada una metodología de pruebas Ágiles basada en el ciclo PHVA la cual tiene un enfoque hacia la planificación y estrategia de pruebas flexibles y adaptables al alcance de cada iteración de desarrollo (Sprint).

La metodología busca que el papel del Tester sea adaptable nuevas situaciones y adquiere más valor integrado en el equipo de desarrollo, para que testers y desarrolladores puedan aportar su experiencia. Pese a este enfoque se han visto oportunidades de mejora y las etapas planteadas en esta metodología.

A continuación, se presentan las etapas y actividades actuales de la metodología y sus puntos sujetos a oportunidad de mejora.

27

Etapa Actividad Utilidad en el negocio Oportunidades de mejora en las pruebas Ágiles

PLANEACION Definición del ambiente de

pruebas

Esta etapa tiene como objetivo reconocer el alcance del producto de software e identificar la estrategia de pruebas necesarias para definir una primera versión del plan de pruebas que permite su verificación. El plan de pruebas permite definir la estrategia de pruebas a realizar mediante la definición de los siguientes aspectos: Alcance general de las pruebas Alcance técnico de pruebas (Software base y Navegadores) Tipos de pruebas Estrategia de Automatización de pruebas Definición de modelo de preparación de datos Herramientas de apoyo utilizadas (Gestión, Automatización)

Se deben evaluar la inclusión de estas actividades en la planeación de la versión del proceso de pruebas ágiles

Estrategia de ejecución

Se deben evaluar la inclusión y el detalle de estas actividades en la planeación de la versión del proceso de pruebas ágiles

Estrategia de planeación de

datos


Estrategia de automatización


ANALISIS Análisis de fuentes - MDF

En la fase de análisis se genera una nueva versión de la MDF, mediante el análisis de las historias de usuario incluidas en el Sprint Backlog. En esta fase se verifica inicialmente que las pequeñas liberaciones sean

Se deben evaluar la inclusión de estas actividades en la planeación de la versión y en la planeación de la iteración del proceso de pruebas ágiles.

28

“funcionalmente” estables. En esta etapa se identifican los escenarios de pruebas de aceptación que deben ser generados para cada uno de los procesos de la MDF. Adicionalmente, se identifica el alcance de las pruebas de integración y regresión, tomando en cuenta las historias de usuario asociadas al impacto de los sistemas existentes. Diseñar una serie de casos pruebas iníciales para cada historia de usuario y realizar entrega formal al equipo de desarrollo. Esto es válido para las pruebas unitarias y componente. El equipo de software desarrolla código necesario para pasar” o “aprobar” los casos de pruebas. Se verifican funcionalmente los casos de prueba y se marcan como aprobados. Se realiza inspección de código de manera automatizada. De la verificación funcional pueden surgir nuevos casos de prueba producto del refinamiento de la definición del producto, adicionalmente, se incluyen pruebas de nuevas funcionalidades recibidas del dueño de producto. El equipo de software desarrolla más código o refactorizar el existente para pasar los casos de prueba adicionales.

Para las pruebas funcionales y de sistema el diseño de pruebas se sugiere sega siendo por funcionalidad, detallando el diseño para cada funcionalidad en la medida que las HU, afectan las funcionalidades. “Para las pruebas funcionales y de sistema. el diseño de pruebas debería seguir siendo por funcionalidad. lo que se debe hacer es detallar el diseño para cada funcionalidad en la medida que las HU, afectan las funcionalidades”

29

Definición de escenarios de

aceptación

Se deben evaluar la inclusión y el detalle de estas actividades en la planeación de la versión y en la planeación de la iteración del proceso de pruebas ágiles. Para la planeación de los sprint de pruebas se sugiere enfatizar el uso de las HU. Los diseños de pruebas de escenarios de aceptación se realizan utilizando como referencia los criterios de aceptación de las HU.

Estrategia de pruebas de

sprint (reúso - regresión)

Se deben evaluar la inclusión y el detalle de estas actividades en la planeación de la versión y en la planeación de la iteración del proceso de pruebas ágiles

Tabla 4 Presentación e inspección de la metodología actual de pruebas ágiles

6.1.5. presentación de las mejores prácticas de agilismo en el sector

Las metodologías Ágiles son un buen marco de trabajo para el aprovechamiento del tiempo, la pronta satisfacción de las necesidades del cliente y mejorar la administración y el rendimiento del trabajo en equipo. Para lograr este aprovechamiento, las metodologías tienen una serie de prácticas o actividades que permiten orientar a los equipos hacia el logro de sus objetivos.

En los procesos de pruebas, las practicas ágiles son aplicable teniendo en cuenta el método de equipo completo, en el cual se incluyen miembros a proyecto donde todos tiene conocimientos y capacidades necesarias para llevar a cabo las tareas que se puedan desarrollas durante el proyecto. Las practicas más comunes se presentan a continuación:

Actividad Descripción de la practica

Planificación de la versión

Define Backlog del producto (Historias de usuario para la versión) que identifica el alcance.

Dividir las HU por sprint Base para el método de pruebas y planificación de pruebas para la versión.

Identificar los riesgos del proyecto / calidad, estimación de esfuerzos Crear estrategia inicial de pruebas para todos los niveles de pruebas. Plan de pruebas para la versión y definición de niveles de prueba necesarios.

30

Se define las historias de usuario comprobables con criterios de aceptación.

Definición de métricas y definir criterios de "Terminado" y de salida.

Elaboración de historias de usuario

Técnicas existentes: Invest (para asegurar la calidad en la escritura de historias de usuario), los elementos 3C (Tarjeta (Card), la Conversación (Conversation) y Confirmación (Confirmation)). Estos son los requisitos del negocio

Planificación de la iteración / sprint

Define Backlog del sprint, Evaluar plan de pruebas, Selección y elaboración de HU, Análisis de riesgo de las HU, División de las HU en tareas, Estimación de HU, Clarificación de HU con Product owner

Escritura de código

“Hacer algo que funcione de la manera más sencilla”.

Implementar lo suficiente para hacer que la prueba pase. Seguir el estándar de codificación. Producción del código del sistema en base a HU / requisitos. El programador escribe las pruebas unitarias y produce el código del sistema. Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo.

La refactorización es una actividad constante de reestructuración del código con el objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. La refactorización mejora la estructura interna del código sin alterar su comportamiento externo.

Es posible que la producción de código se realizarse con trabajo en parejas de programadores.

Revisión de Código

Los testing unitarios son tan importantes como los tests de aceptación. Son realizados desde el punto de vista del programador y sirven, además de testear el código, para poder realizar el refactoring del mismo. Cada programador, antes de comenzar a programar, debe preparar los tests unitarios. Esto hace que dichas pruebas estén preparadas para ser corridos durante la codificación y, además hace que al programador le surjan dudas y pueda evacuarlas con el cliente antes de empezar con la codificación.

Pruebas unitarias

Pruebas ejecutadas por Desarrollo y a menudo son automatizadas.

Los testing unitarios son tan importantes como las pruebas de aceptación. Son realizados desde el punto de vista del programador y sirven, además de testear el código, para poder realizar el refactoring del mismo. Cada programador, antes de comenzar a programar, debe preparar las pruebas unitarias. Esto hace que dichas pruebas estén preparadas para ser corridos durante la codificación y, además hace que al programador le surjan dudas y pueda evacuarlas con el cliente antes de empezar con la codificación.

31

Diseño de pruebas funcionales

(incremental)

Los tester ayudan a los clientes a escribir las pruebas funcionales del sistema.

En el plan de iteraciones, el cliente selecciona las HU a ser implementadas, y se detallan las pruebas de aceptación para cada HU.

Los programadores establecen todos los casos de prueba posibles antes de comenzar con la implementación

Automatización de pruebas

• Debe poderse repetir en múltiples ocasiones

• Debe ser fácil de implementar y mantener.

• Una vez escrita debe poder reutilizarse en el futuro.

• Cualquier desarrollador del equipo debe estar en capacidad de ejecutarla.

• Debe poderse ejecutar ante una única acción.

• Debe ser de rápida utilización siempre y cuando sea posible.

Diseño/ desarrollo de pruebas TDD/ ATDD

La producción de código está dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas constantemente ante cada modificación del sistema. Los clientes escriben las pruebas funcionales para cada historia de usuario que deba validarse. En este contexto de desarrollo evolutivo y de énfasis en pruebas constantes, la automatización para apoyar esta actividad es crucial.

Ejecución de pruebas funcionales

Manuales y automáticas

Pruebas de aceptación Alfa, beta, UAT, OAT, regulatoria y contractual, al final de cada iteración o después de una serie de iteraciones.

Integración continua

Unir los cambios e integrar todos los códigos diariamente o amenudeo, permite descubrir defectos tempranamente. Son automatizadas.

Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en un mismo día. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea incorporado definitivamente. La integración continua a menudo reduce la fragmentación de los esfuerzos de los desarrolladores por falta de comunicación sobre lo que puede ser reutilizado o compartido.

Daily Reunión diaria acerca del estado del Sprint / proyecto. Es un punto de Transferencia de conocimiento dentro del equipo

Retrospectiva

Reunión al final de cada iteración donde se comenta que funciono y que no, como mejorar y como conservar el éxito.

Temas que tratar: procesos, personas, organizaciones, herramientas, Quién, qué, cuándo, Dónde, Cómo

32

Revisión por pares

Toda la producción se realiza en pares.

El encargado de escribir piensa tácticamente, su pareja piensa estratégicamente.

Se rotan los roles periódicamente.

Pruebas de aceptación de características / pruebas estáticas

verificación de características de desarrollo. Son manuales.

Pruebas de regresión A lo largo de la iteración a través de las pruebas

Pruebas de sistema

Las Pruebas del sistema tienen su foco principal en las no conformidades que se presentan en el nivel más alto de la integración. La pruebas del sistema incluye típicamente muchos tipos de prueba: funcionalidad, usabilidad, seguridad, internacionalización y localización, confiabilidad y disponibilidad, capacidad, funcionamiento, recuperación, portabilidad y otros, sin embargo en GreenSQA nos ocupamos principalmente de la pruebas de la funcionalidad y es deber de los Ingenieros de pruebas plantear requerimientos de pruebas orientados a hacer las validaciones mínimas de rendimiento, concurrencia y recuperación que apliquen a cada caso.

Tabla 5 Mejores prácticas de Agilismo en el sector

La inspección de metodologías de pruebas de GreenSQA y los estándares de la

industria, permitieron identificar varios aspectos a tener en cuenta en el nuevo

documento de metodología de pruebas agiles. Así mismo, con el apoyo de la gestión

del conocimiento se logró la evaluación de las actividades actuales y la

retroalimentación de estas, para lograr un compilado de información que finalmente

dieron paso a las mejoras sugeridas.

6.2. MEJORAS SUGERIDAS APLICABLES A LA METODOLOGÍA DE PRUEBAS ÁGILES EN GREENSQA

GreenSQA® propone un Proceso de Pruebas que está estructurado en cuatro etapas, ANALISIS, DISEÑO, EJECUCIÓN y RETROALIMENTACION. Cada una de las etapas está formada por una o más actividades, sin embargo, estas etapas no se acoplan bien a los métodos ágiles por lo que durante es revisión se hicieron algunas recomendaciones a ser tomadas en cuenta para la nueva versión de metodología de pruebas Ágil de GreenSQA.

A continuación, se presentan las oportunidades de mejora identificadas:

• Inicialmente se recomienda adoptar en la nueva versión de la metodología Ágil de GreenSQA una estructura que incorpore a sus fases estándar las siguientes actividades de procesos ágiles: Planificación de la versión, Elaboración de historias de usuario, Planificación de la iteración / sprint, Escritura de código,

33

Revisión de Código, Pruebas unitarias, Diseño de pruebas funcionales (incremental), Automatización de pruebas, Diseño/ desarrollo de pruebas TDD/ ATDD, Ejecución de pruebas funcionales, Pruebas de aceptación, Integración continua, Daily, Retrospectiva, Revisión por pares, Pruebas de aceptación de características / pruebas estáticas, Pruebas de regresión, Pruebas de sistema, Evaluación basada en la experiencia. A continuación, se muestra el ciclo ágil propuesto de acuerdo con las mejores prácticas identificadas y el mapeo general de acuerdo a los resultados de inspección. A continuación, se presenta tabla con mapeo de las actividades de las metodologías y las mejores prácticas ágiles en las fases propuestas para la nueva versión de la metodología ágil.

Tabla 6 Mapeo de metodologías de prueba GreenSQA en ciclo ágil

34

• Las actividades Recolección de información, Análisis de información, Planeación y estrategia de pruebas y Estimación correspondientes a la etapa de análisis de la prueba Funcionales, se puede involucrar en los procesos de pruebas ágiles en la actividad de planeación de la versión de tal forma que apoye la definición del alcance, aspectos técnicos del (los) productos, los niveles de prueba, el método de pruebas y el plan de pruebas, involucrando persona, herramienta y proceso.

• Las actividades de Planeación y estrategia de pruebas y Estimación, correspondientes a la etapa de análisis de la prueba Funcionales, se puede llevar a cabo en la planeación de la iteración, teniendo en cuenta que se planeen las actividades de acuerdo con los estándares de métodos ágiles.

• La actividad de validación de técnicas de prueba correspondientes a la etapa de Diseño de las pruebas Funcionales se puede involucrar en la planeación de la Iteración/ Sprint y en la etapa de Diseño de pruebas funcionales (incremental).

• Las actividades de Diseño de prueba, Construcción de instrumentos correspondientes a la etapa de Diseño de la prueba Funcionales se puede adaptar en la etapa de Diseño de pruebas funcionales (incremental) aplicando el concepto y estándares identificados en los métodos ágiles y haciendo uso de las herramientas dispuestas por GreenSQA “Ktree”.

• La actividad de Recolección de información de prueba, correspondiente a la etapa de Análisis de las pruebas NO Funcionales se puede definir como parte de las actividades de la planeación de la versión, buscando relacionar la parte técnica y funcional a la revisión de los requisitos sujetos a pruebas, teniendo en cuenta el método de equipo completo en las practicas ágiles.

• Las actividades de Análisis de información, Planeación y estrategia de pruebas y Estimación correspondiente a la etapa de Análisis de las pruebas NO Funcionales se puede definir como parte de las actividades de la planeación de la versión y la planeación de la iteración de pruebas.

• Las actividades de Identificación de aspectos de pruebas y Diseño de prueba correspondiente a la etapa de Diseño de las pruebas NO Funcionales se puede involucrar en la planeación de la Iteración/ Sprint y en la etapa de Diseño de pruebas funcionales (incremental).

• Se propone la definición de una estrategia de preparación de los datos de pruebas desde la fase de planeación del sprint, en la que se enfatice el almacenamiento de las herramientas o SQL de preparación de datos como parte de los casos de prueba definidos.

35

• La actividad de Generación de script de prueba correspondiente a la etapa de Diseño de las pruebas NO Funcionales Esto se puede incluir como una actividad en la actividad de proceso ágil de Automatización de pruebas.

• Las actividades de Preparación de ambiente, Definir estrategia de Branching & Meging, correspondiente a la etapa de Análisis de la metodología de automatización de pruebas se propone involucrar en la planeación de la iteración de pruebas y en la etapa de diseño incremental de pruebas.

• La actividad de Construir el Product Backlog correspondiente a la etapa de Diseño de la metodología de automatización de pruebas se propone involucrar en la planeación de la iteración de pruebas y en la etapa de diseño incremental de pruebas.

• La actividad de Sprint 0 / Selección de la herramienta de automatización correspondiente a la etapa de Diseño de la metodología de automatización de pruebas se propone involucrar en la planeación de la iteración, en el diseño de pruebas incremental y en el proceso de automatización de pruebas.

• Las actividades Sprint 0 / Definir estrategia de Branching & Meging y Sprint 0 / Arquitectura y Framework de pruebas correspondiente a la etapa de Diseño de la metodología de automatización de pruebas se propone involucrar en el diseño de pruebas incremental y en el proceso de automatización de pruebas.

• Se recomienda evaluar la inclusión y el detalle de las actividades Definición del ambiente de pruebas, Estrategia de ejecución, Estrategia de planeación de datos, Estrategia de automatización en la planeación de la versión del proceso de pruebas ágiles.

• Se recomienda evaluar la inclusión de la actividad de Análisis de fuentes - MDF en la planeación de la versión y en la planeación de la iteración del proceso de pruebas ágiles.

• Se recomienda evaluar la inclusión y el detalle de las actividades Definición de escenarios de aceptación y Estrategia de pruebas de sprint (reúso - regresión) en la planeación de la versión y en la planeación de la iteración del proceso de pruebas ágiles.

• Se recomienda incluir en la metodología de pruebas lineamientos que permitan al ingeniero de pruebas involucrarse en la definición de las historias de usuario de acuerdo con los estándares de metodología ágil como el método de equipo completo y la retroalimentación temprana y frecuente acerca de la calidad que se busca en los proyectos ágiles.

36

• Se propone que para la definición de los sprint se incluya dentro de la metodología la definición del alcance de los componentes o flujos de proceso que se van a automatizar.

• Se sugiere incluir como un estándar de la metodología de pruebas agiles de GreenSQA, la recomendación a realizar durante el sprint 0, de que la herramienta de gestión de la configuración seleccionada incluya lo necesario para la gestión de un proceso de pruebas:

o Configuración de línea base de pruebas o Configuración de reglas para inspección de código o Configuración de almacenamiento y ejecución de pruebas automatizadas o Configuración de indicadores de calidad de producto

Los aspectos de mejora planteados a partir de las inspecciones realizadas

permitieron restructuran las actividades generales de la metodología, enfocándose

especial mente en la evaluación del análisis y el diseño de pruebas presentes en la

versión sujeta a cambios, definiendo una nueva metodología con actividades

propias de los estándares que se manejan los marcos ágiles en la industria, sin

perder los esquemas internos de las actividades de GreenSQA.

6.3. ASPECTOS METODOLÓGICOS QUE SE ESPERAN SE FORTALECER CON LAS MEJORAS SUGERIDAS

• La planificación de la versión y la elaboración de historias de usuario permitirán a GreenSQA incorporarse de manera temprana en las actividades de análisis dentro de la planeación del proyecto y aportar en la construcción de criterios de aceptación y en la calidad del producto.

• La planificación de la iteración / sprint le permitirán a GreenSQA incorporarse de manera temprana en las actividades de análisis dentro de la planeación del proyecto y la planeación de la iteración, permitiendo alinearse con las actividades de los demás integrantes equipo de trabajo y aportar en la construcción de criterios de aceptación y en la calidad del producto, haciendo más asertiva la calidad del producto.

• La Revisión de código permitirá incorporarse de manera técnica a los proyectos y aportar con este tipo de prueba en el análisis de código como una de las actividades que aporten a calidad en los proyectos.

37

• La inclusión en el proceso de pruebas unitarias permitirá a GreenSQA un mayor alcance en los proyectos de automatización, ya que entra en el esquema de equipo completo al apoyo del equipo de desarrollo en la planeación, diseño y ejecución de las pruebas unitarias, permitiendo además el reúso de este conocimiento en otros tipos de pruebas requeridas dentro del proyecto.

• El Diseño de pruebas funcionales - incremental, se complementa con el proceso que existe hoy en día en GreenSQA, para el cual se mejora desde la perspectiva del modelo iterativo, permitiendo enriquecer la base de casos de prueba a medida que avanza en iteraciones.

• La automatización de pruebas Apoya bidireccionalmente la metodología de pruebas de automatización de GreenSQA fortaleciendo la metodología de pruebas Ágiles y el recurso humano organizacional, al incluirlo en diferentes enfoques de pruebas.

• El Diseño/ desarrollo de pruebas TDD/ ATDD incorpora al producto diferentes niveles de pruebas, agrandando el alcance de la automatización de pruebas, diseño de pruebas y ejecución de pruebas (unidad, funcionales, sistema, de usuario y es posible aplicar en el proceso de pruebas no funcionales).

Los aspectos metodológicos por mejorar, presentados en este documento y en un documento formal de propuesta, permitieron a GreenSQA evaluar los resultados de inspección y las sugerencias de mejora, para finalmente aprobar los cambios en la nueva versión del documento metodológico en las actividades de Análisis y diseño de pruebas presentes en la versión sujeta a modificación.

6.4. CAMBIOS A LA METODOLOGÍA APROBADOS POR GREENSQA

Con el fin de presentar a la organización los resultados de la inspección y las mejoras identificadas, se entregó a las directivas de GreenSQA un documento oficial con las mejoras sugeridas a la versión 2 de la metodología de pruebas Ágiles (ver Anexo A.).

A raíz del documento con las propuestas de mejora se programó una reunión de validación de estas propuestas con el fin de que se aprobaran y se procediera al ajuste del documento y generación de la versión 3 del método de pruebas ágiles. De esta reunión se generó un el esquema definitivo de la metodología de acuerdo con lo prepuesto y a las mejoras aprobadas. Estos resultados quedaron consignados en un acta (Anexo B), en la cual se referencia la tabla siguiente y que además queda como Anexo C:

38

Tabla 7 Aprobaciones planificación de la versión

Tabla 8 Aprobaciones planificación del sprint

Tabla 9 Aprobaciones ejecución de Sprint

39

Tabla 10 Aprobaciones de inclusión retrospectiva

Las tablas 8, 9, 10 y 11 presentan el esquema aprobado para la nueva versión de la metodología ágil, que se compone de las macro actividades: Planeación de la versión (Sprint backlog), Planeación del sprint (Sprint planning), desarrollo del Sprint y Retrospectiva.

Teniendo en cuenta lo que fue definido en la reunión de aprobación, se iniciaron los ajustes al documento de metodología, impactando las fases de análisis y diseño como se planteó en el objetivo de esta práctica.

Para presentar los ajustes cambios en la metodología se presentan los esquemas del documento Versión 2 (Anexo D) y Versión 3:

Ilustración 3 Esquema del documento de metodología de pruebas Versión 2

40

En el esquema de la ilustración 3, se evidencia una estructura de metodologías convencionales de los procesos de desarrollo a pesar de que en el contenido se quiere informar un método ágil.

En búsqueda del nuevo esquema de trabajo y teniendo en cuenta lo aprobado por la organización se diseñó un gráfico que representa el esquema de trabajo que permitiera orientar tanto la reestructuración del documento metodológico como a los lectores de este.

En la ilustración 4 se presenta el grafico diseñado para la metodología de pruebas ágiles de GreenSQA en el cual se presenta de forma resumida el esquema y las actividades principales se esperan sean desarrollada en los proyectos. Este grafico está incluido en la metodología Versión 3.

Ilustración 4 Esquema de trabajo Ágil en GreenSQA

Con el propósito del que el documento de que el documento rubiera este esquema de trabajo, se restructuro quedando de la siguiente forma:

41

Ilustración 5 Esquema del documento de metodología de pruebas Versión 3

En el esquema presentado en la ilustración 5, se puede evidenciar un enfoque metodológico ágil, el cual conserva algunos elementos de la versión anterior y que fueron restructurados para ser acoplados a esta nueva versión.

Se debe tener en cuenta que la fase de ejecución de la versión 2 por estar asociada al desarrollo del sprint en los modelos agiles, fue integrado a la actividad macros.

Lo anterior respondió a lo planteado en los objetivos planteados al inicio del proyecto, desarrollando actividades que permitieran plantear las mejoras, validarlas e implementarlas en un nuevo documento de metodología. Es resultado de los justes realizados a la metodología generaron la nueva versión en el documento del Anexo E.

Con estos cambios la organización tendrá un método acoplado a la naturaleza de la organización y a las mejores prácticas agiles, que guie los proyectos internos y externos que busquen resultados tempranos.

42

7. CONCLISIONES

• La inspección de metodologías de pruebas de GreenSQA y los estándares de la industria, realizada con el apoyo de la gestión de conocimiento, permitieron identificar los aspectos de mejora propuestos a la compañía para fortalecer la metodología de pruebas ágiles.

• Los aspectos de mejora planteados a partir de las inspecciones realizadas se orientaron a la restructuración de las actividades generales de la metodología, enfocándose especial mente en las actividades del análisis y el diseño, definiendo actividades dentro de los estándares de marcos ágiles en la industria, sin perder los esquemas organizacionales.

• Los aspectos metodológicos por mejorar presentados a partir de inspección y las sugerencias de mejora, permitieron a GreenSQA evaluar y aprobar los cambios a realizar en la nueva versión del documento metodológico, especialmente para las actividades de Análisis y diseño de pruebas presentes en la versión sujeta a modificación.

• Con cambios propuestos y aprobados, la organización tendrá un método acoplado al esquema organizacional y a las mejores prácticas ágiles, que guiaran los proyectos internos y externos desarrollados en un marco ágil.

• El proceso llevado a cabo es el presente trabajo, dio lugar la versión tres de la metodología de pruebas ágiles en GreenSQA, la cual fue aprobada y publicada a todos los miembros de la organización.

43

8. RECOMENDACIONES

• Se recomienda dar continuidad al ajuste de la metodología, especialmente en las etapas posteriores al diseño de pruebas para que toda la metodología ágil quede dentro de los estándares (etapas de ejecución de pruebas, seguimiento y cierre de los proyectos).

• Se recomienda que en una nueva versión de la metodología se identifiquen una estrategia de sistematización de la información generada en cada una de las etapas de método ágil, incorporando herramientas de gestión con el fin de que las definiciones mantengan en cada ciclo de los proyectos, además de que queden como base de información para la gestión del conocimiento organizacional.

• Se recomienda que próximas versiones se tengan en cuenta en la etapa de inspección o identificación de oportunidades de mejora, marcos agiles emergentes y fuertes en la industria como por ejemplo SAFe (Scaled Agile Framework).

44

9. REFERENCIAS BIBLIOGRAFICAS

a) Manifiest for Agile software development, © 2001, http://agilemanifesto.org/iso/es/manifesto.html

b) Ruiz Berenice Autor - Publicado en SG #38 – Sección Temas especiales: https://sg.com.mx/revista/46/marcando-la-pauta-para-las-pruebas-agiles#.WgplArKLTIU

c) Gómez Liliana, Hoyos Patricia, metodología pruebas de software, GreenSQA – versión: 18.0

d) Ghosh, S. (2012). Systemic comparison of the application of EVM in traditional and agile software project [Internet]. Disponible desde http://pm.umd.edu/files/public/ documents/student-papers/2011/EVM%20in%20Waterfall%20and%20Agile%20Software%20Project%20by%20 Sam%20Ghosh.pdf [Acceso Junio 1, 2013].

e) La Guía Definitiva de Scrum: Las Reglas del Juego, Desarrollado y soportado por Ken Schwaber y Jeff Sutherland, Julio de 2013.

f) Universidad ORT Uruguay, Cátedra de Ingeniería de Software, Metodología XP, octubre del 2003, Autores: Luis Calabria – 122919, Pablo Píriz – 123348

g) Manual de Metodologías Ágiles, Versión 1 - agosto de 2016, por WINGU - Tecnología sin fines de lucro - /www.winguweb.org, apoyo Vamos Buenos Aires.

h) E. Bueno, La Gestión del Conocimiento nuevos perfiles profesionales, junio 1999. http://www.sedic.es/bueno.pdf

i) B Crawford Labrin, Gestión del Conocimiento en Enfoques de Desarrollo de Software Tradicional y Agilista, [email protected], 2018

j) T. Chau y F. Maurer, Knowledge Sharing un Agile Software Teams, http://sern.ucalgary.ca/~milos/papers/2004/ChauMaurer2004.pdf/

k) F. Taylor, The Principles of Scientific Management, Dover Pubns, 1998 l) K. Beck et al, Manifesto for Agile Software Development,

http://agilemanifesto.org/ m) U. Kelter et al, Do we Need ‘Agile’ Software Development Tools?,

http://pi.informatik.uni-siegen.de/ n) M. Fowler, The New Methodology,

http://www.programacionextrema.org/articulos/newMethodology.html/ o) J. Bozo y B. Crawford, Métodos Ágiles como Alternativa al Proceso de

Desarrollo Web, IX Congreso Argentino

http://www.sedic.es/bueno.pdf

mailto:[email protected]

http://agilemanifesto.org/

http://pi.informatik.uni-siegen.de/

http://www.programacionextrema.org/articulos/newMethodology.html/

Licencia Creative Commons - UCC

Documents

Transcript of Licencia Creative Commons - UCC