tesina: metodologías Ágiles centradas en la automatización de pruebas - frank escobar

FACULTAD “SAN FRANCISCO” UNIVERSIDAD CATÓLICA ARGENTINA

LICENCIATURA EN SISTEMAS Y COMPUTACIÓN

METODOLOGÍAS ÁGILES CENTRADAS EN LA AUTOMATIZACIÓN DE PRUEBAS

ALUMNO FRANK MARTHY ESCOBAR ARTEAGADIRECTORA DE TESINA Ing. María Antonella Manna

Prof. a Cargo Mg. Jorge Mariotti Prof. Adjunto Mg. Alejandro Vázquez

Presentada ante la Secretaría Académica de la Facultad San Francisco U.C.A. como requisito parcial para optar al título de LICENCIADO EN SISTEMAS Y COMPUTACIÓN Mayo 29 de 2012

ii

TÍTULO DE LA TESINA METODOLOGÍAS ÁGILES CENTRADAS EN LA AUTOMATIZACIÓN DE PRUEBAS Tesina presentada por: Alumno: ESCOBAR ARTEAGA, FRANK MARTHY Aprobada en contenido por: _____________________________________________________________________ Aprobada en estilo por: _____________________________________________________________________ Nombre del profesor, miembro del tribunal _____________________________________________________________________ Nombre del profesor, miembro del tribunal _____________________________________________________________________ Nombre del Director de Carrera _____________________________________________________________________

iii

AGRADECIMIENTOS

A mis excelentes profesores: Gustavo Sabio, Diego Garay, Julieta Suárez, Carlos Troglia, Rolando Conde, Italo Ortiz, Jorge Hidalgo, Jorge Cadoni, Alejandro Vázquez y Jorge Mariotti quienes me transmitieron a través de sus enseñanzas, la voluntad para seguir creciendo y valorarme como profesional.

A mis compañeros de trabajo: Jonathan Ortiz, Antonella Manna y Mariano Giardina quienes a través de su experiencia me ayudaron a desarrollar mis cualidades y habilidades en el área de calidad.

A mi madre Ana Cecilia Arteaga, quien inspiró en mí, ser una persona constante y nunca darme por vencido a pesar de las adversidades.

A mi hermana Annie Escobar y a mi novia Rita Loloy quienes me motivaron y alentaron en cada momento.

A mis amigos y compañeros de facultad Diego Arena y Armando Rosario con quienes aprendí y compartí grandes momentos durante el cursado de la carrera.

iv

RESUMEN TÍTULO DE LA TESINA METODOLOGÍAS ÁGILES CENTRADAS EN LA AUTOMATIZACIÓN DE PRUEBAS FECHA DE LA DEFENSA: 29 de Mayo del 2012 NOMBRE DEL ESTUDIANTE: ESCOBAR ARTEAGA, FRANK MARTHY LICENCIATURA EN SISTEMAS Y COMPUTACIÓN FACULTAD SAN FRANCISCO U.C.A. Dirigida por la Ing. María Antonella Manna.

Existen diversos problemas por los que actualmente atraviesan los proyectos de desarrollo de software que realizan una transición hacia las metodologías ágiles. Los líderes y otros miembros que forman parte del proyecto tienden a darle poca importancia a la calidad del software ya que esta no resulta visible a los ojos del cliente, preocupándose solo por entregar la mayor cantidad de funcionalidad posible sin importarle su buen funcionamiento. Esto implica arduas horas de trabajo para todo el equipo ya que generalmente no se llega con lo pactado cuando se está cerca al plazo de entrega, lo que genera tanto la insatisfacción por parte del equipo de desarrollo por haber realizado esfuerzos extra, como la del cliente por no obtener una calidad considerablemente aceptable.

Con el tiempo, estas malas prácticas se han ido propagando, opacando las funciones y responsabilidades de los profesionales en el área de calidad. Lo que a su vez, ha logrado impactar en las concepciones de los miembros del equipo, promoviendo la idea de que los profesionales del área de calidad no brindan valor agregado al negocio.

Es aquí donde interviene la automatización de pruebas generando un fuerte impacto, ya que a través de esta actividad podemos obtener grandes beneficios como: la reducción de tiempo durante la ejecución de pruebas, disminución de costos, retroalimentación continua, refactorización de código, documentación de las funcionalidades del sistema de forma ágil, cobertura de pruebas, etc. Esta actividad requiere de mayor formación y capacitación técnica por parte de los miembros del equipo de control de calidad, como así también de mayor participación y comunicación con el equipo de programadores, que da como resultado todo un equipo trabajando en conjunto por la calidad del software.

Además de destacar los beneficios de la automatización de pruebas, de este seminario se obtienen propuestas de estrategias de automatización, según el tipo de software que se esté desarrollando. Además se incluyen flujos de trabajo que involucran a todos los miembros del equipo; y por último se expone el proceso ideal de automatización de pruebas junto a sus métricas necesarias para la toma de decisiones en el ámbito gerencial, resaltando el rol fundamental del profesional en el área de calidad y el uso de las herramientas de prueba.

v

ÍNDICE DE CONTENIDO Contenido: Agradecimientos .............................................................................................. iii Resumen........................................................................................................... iv Índice de Tablas .............................................................................................. vii Índice de Ilustraciones o figuras ....................................................................viii Introducción ..................................................................................................................... 1 Capítulo 1. Metodologías ágiles centradas en la automatización de pruebas .................. 2

1.1) Presentación del Problema ....................................................................... 2 1.2) Objetivos .................................................................................................. 2 1.3) Alcance..................................................................................................... 2 1.4) Metas........................................................................................................ 3

Capítulo 2. Metodologías Tradicionales .......................................................................... 4

2.1) Historia..................................................................................................... 4 2.2) Modelo en cascada ................................................................................... 4 2.3) Principales roles del modelo en cascada .................................................. 6 2.4) Ventajas y desventajas ............................................................................. 7

Capítulo 3. Metodologías Ágiles ..................................................................................... 9

3.1) Historia..................................................................................................... 9 3.2) Principios ágiles ..................................................................................... 10 3.3) Scrum ..................................................................................................... 12 3.4) Roles en Scrum ...................................................................................... 16 3.5) Ventajas y desventajas ........................................................................... 18

Capítulo 4. Transición hacia las metodologías ágiles .................................................... 19

4.1) Cultura Organizacional .......................................................................... 19 4.2) Problemas que surgen de la aplicación de las metodologías ágiles ....... 19

vi

Capítulo 5. Automatización de pruebas ......................................................................... 25

5.1) Conceptos erróneos sobre la automatización de pruebas....................... 25 5.2) Tipos de sistemas ................................................................................... 27 5.3) Estrategias de prueba.............................................................................. 30 5.4) Estrategias de automatización de pruebas.............................................. 35 5.5) Metodologías ágiles centradas en la automatización de pruebas ........... 40 5.6) Impedimentos para llevar a cabo la automatización de pruebas ............ 42 5.7) Automatización de pruebas aplicadas en las metodologías ágiles ......... 43 5.8) Selección de casos de prueba a automatizar .......................................... 48 5.9) Selección de herramientas de automatización........................................ 49 5.10) Integración Continua.............................................................................. 50 5.11) Métricas.................................................................................................. 52

Capítulo 6. Profesional del área de calidad.................................................................... 56

6.1) Aseguramiento y Control de la calidad.................................................. 56 6.2) Conocimientos y habilidades técnicas ................................................... 57 6.3) Cualidades humanas, grado de influencia y participación ..................... 58

Conclusión ..................................................................................................................... 60 Glosario .......................................................................................................................... 62 Anexo: Curriculum Vitae............................................................................................... 63 Bibliografía .................................................................................................................... 65

vii

ÍNDICE DE TABLAS

Tabla 1: Ejemplo ROI de Esfuerzo ................................................................................ 52 Tabla 2: Cuadro comparativo de métricas de tres proyectos diferentes......................... 55

viii

ÍNDICE DE ILUSTRACIONES O FIGURAS

Fig. 1: Modelo en Cascada............................................................................................... 5 Fig. 2: Roles del Modelo en Cascada............................................................................... 7 Fig. 3: Reuniones de Scrum ........................................................................................... 12 Fig. 4: Historia de Usuario con criterios de aceptación y dividida en tareas ................. 12 Fig. 5: Actividades del dueño del producto ................................................................... 13 Fig. 6: Actividades del equipo de Scrum ....................................................................... 13 Fig. 7: Scrum diario ....................................................................................................... 14 Fig. 8: Demostración de Sprint ...................................................................................... 14 Fig. 9: Retrospectiva de Sprint....................................................................................... 15 Fig. 10: Sprint Release ................................................................................................... 15 Fig. 11: Equipo del cliente y desarrollo trabajando como un solo equipo..................... 17 Fig. 12: Escasa o nula participación del cliente ............................................................. 20 Fig. 13: Problemas que surgen de la aplicación de las metodologías ágiles.................. 24 Fig. 14: Software que no aplica automatización de pruebas.......................................... 25 Fig. 15: Software que aplica automatización de pruebas inadecuadamente .................. 26 Fig. 16: Arquetipo de una aplicación de cliente enriquecida ......................................... 27 Fig. 17: Arquetipo de una aplicación de Internet enriquecida ....................................... 28 Fig. 18: Arquetipo de una aplicación de servicios ......................................................... 29 Fig. 19: Arquetipo de una aplicación web ..................................................................... 29 Fig. 20: Arquetipo de una aplicación móvil................................................................... 30 Fig. 21: Cuadrantes de las Pruebas Ágiles ..................................................................... 31 Fig. 22: Diagrama de flujo de TDD ............................................................................... 31 Fig. 23: Creando prueba unitaria.................................................................................... 32 Fig. 24: Refactorizando código para que la prueba sea exitosa ..................................... 32 Fig. 25: Historia de usuario junto al prototipo de pantalla............................................. 33 Fig. 26: Caso de prueba verificado por el cliente (UAT)............................................... 34 Fig. 27: Gráfica de tiempo de respuesta y nº de hilos activos de un sistema................. 35 Fig. 28: Pruebas de bajo nivel aplicadas en la capa de negocio..................................... 36 Fig. 29: Pruebas de nivel intermedio aplicadas en la capa de negocio y/o servicios..... 38 Fig. 30: Pruebas de nivel superior aplicadas en la capa de presentación....................... 39 Fig. 31: Metodologías ágiles centradas en la automatización de pruebas...................... 41 Fig. 32: Impedimentos para llevar a cabo la automatización de pruebas....................... 43 Fig. 33: Desarrollo de software sin automatización de pruebas..................................... 43 Fig. 34: Desarrollo de software sin criterios de automatización de pruebas.................. 45 Fig. 35: Desarrollo de software con criterios de automatización de pruebas................. 46 Fig. 36: Diagrama de flujo de ATDD ............................................................................ 47 Fig. 37: Integración Continua ........................................................................................ 51 Fig. 38: Ecuación de porcentaje de pruebas automatizables.......................................... 53 Fig. 39: Ecuación de porcentaje de progreso de automatización ................................... 53 Fig. 40: Ecuación de porcentaje de cobertura de pruebas automatizadas ...................... 54 Fig. 41: Ecuación de eficiencia de eliminación de errores y/o defectos ........................ 54 Fig. 42: Representación de un miembro del equipo frustrado y exitoso........................ 58

1

INTRODUCCIÓN

Las primeras metodologías tradicionales del desarrollo del software presentaban conceptos muy estructurados, burocráticos, lentos y estrictos como es el caso del “Modelo en Cascada”.

En los años 90 las metodologías ágiles aparecían con un proceso de desarrollo

formado por las características de los modelos anteriores, basándose en la experiencia y en un conjunto de principios y valores que tenían como objetivo último la satisfacción del cliente.

En los primeros años del nuevo milenio, estudios realizados revelaron que se

generaban altos costos en la búsqueda por alcanzar una mejor calidad en los softwares, ya que más del 80% del costo de desarrollo se ocupaba detectando y corrigiendo errores y defectos. Esto sumado, a que existía la necesidad de lograr una mejor calidad con menos recursos disponibles; y que cada vez se incrementaba la utilización de sistemas tercerizados, los cuales no brindaban seguridad, integridad y confidencialidad; y el advenimiento de nuevos estándares de calidad, dio como origen a la automatización de pruebas.

Por lo general, si bien la automatización de pruebas ha sido adoptada por una cantidad considerable de proyectos de software, no ha sido implementada de forma adecuada. Es por ello que este seminario intenta generar o recuperar la confianza en la automatización de pruebas, que a través de sus beneficios y la participación de las personas que hacen todo esto posible, dan como resultado una calidad de software progresivamente mejorable.

2

CAPÍTULO I: METODOLOGÍAS ÁGILES CENTRADAS EN LA AUTOMATIZACIÓN DE PRUEBAS

1.1) Presentación del problema:

Los proyectos de desarrollo de software que intentan realizar una transición entre el uso de una metodología tradicional hacia una metodología ágil, que buscan satisfacer las necesidades y expectativas del cliente, tienden a fracasar debido a que los conceptos y prácticas de las metodologías anteriores están fuertemente arraigados y los nuevos conceptos, que son fundamentales para el éxito del proyecto, no son muy bien aceptados y si son aceptados son mal implementados, impactando de esta forma negativamente en la calidad de los software y por ende provocando la pérdida de confianza en las actividades de calidad tanto en el equipo de desarrollo como en el cliente. 1.2) Objetivos:

o Demostrar que la automatización de pruebas es uno de los factores claves

para alcanzar el éxito de todo proyecto de desarrollo de software que aplique metodologías ágiles.

o Destacar la importancia del papel que desempeña un profesional del área de

calidad de software tanto en cualidades humanas, habilidades técnicas como el grado de influencia y participación durante el proceso, que brindan un valor agregado al negocio, teniendo como resultado productos de calidad y equipos de trabajo con un alto grado de motivación.

1.3) Alcance:

Si bien existen diversos problemas que surgen de la transición de las metodologías tradicionales hacia las ágiles, se intentará resolver los problemas con respecto al gerente y al equipo de desarrollo, específicamente los relacionados con la dificultad para medir el progreso del proyecto, escasez de tiempo durante el desarrollo de software y los conceptos erróneos que se tienen sobre los profesionales de control de calidad. A través de la exposición se demostrará los beneficios, estrategias, procesos, flujos de trabajo y métricas de la automatización de pruebas, que se requiere de mayor formación, capacitación técnica, comunicación y participación de parte del profesional de control de calidad para lograr una mejor calidad de software trabajando en equipo.

3

1.4) Metas:

o Exponer las diferencias que existen entre metodologías tradicionales y ágiles.

o Explicar el por qué la automatización de pruebas produce beneficios a

mediano y a largo plazo. o Proponer estrategias de automatización de pruebas según el tipo de software. o Sugerir un proceso de automatización de pruebas que mejor se adapte a un

proceso en el que se implementen las metodologías ágiles.

o Demostrar cómo la automatización de pruebas contribuye a optimizar las pruebas de regresión, realizadas manualmente en las metodologías tradicionales.

o Demostrar que las métricas provenientes de la automatización de pruebas

son fundamentales para la toma de decisiones en el ámbito gerencial.

o Demostrar que se requiere de profesionales del área de calidad con perfiles especializados para llevar a cabo una mejor adaptación en las metodologías ágiles.

4

CAPÍTULO II: METODOLOGÍAS TRADICIONALES

2.1) Historia:

A partir de los años 70, surgieron diversos modelos que seguían los principios de las metodologías tradicionales. Estas metodologías imponían una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Por lo que ponían énfasis en la planificación total de todo el trabajo a realizar y una vez que estaba todo detallado, comenzaban con el ciclo de desarrollo del producto software. Se centraban especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas, notaciones para el modelado y documentación detallada. Entre ellos podemos citar:

o MSF (Microsoft Solution Framework) o Win – Win Spiral Model o Iconix o RUP (Rational Unified Procces). Pero el más representativo de todos los modelos en las metodologías

tradicionales fue el “Modelo en Cascada”. Se cree que este modelo fue el que se introdujo primero y ampliamente en la ingeniería de software. En la década del 70 no había conciencia de la división de desarrollo de software en diferentes fases. Los requisitos eran pocos y los programas eran muy pequeños, por lo que no existía la necesidad de llevar a cabo una adecuada organización.

Como los programas se hicieron cada vez más grandes y complejos, resultó mucho más costoso para los programadores poder capturar los requisitos del producto, así como también diseñarlos, implementarlos y probarlos. Fue así como surgió la necesidad de una metodología de desarrollo de software.

Las diferentes fases de ingeniería de software fueron identificadas y en 1970, Royce propuso lo que actualmente se conoce como el “Modelo en Cascada”, este fue uno de los primeros modelos de ciclo de vida del desarrollo de software. El modelo describe un orden secuencial en la ejecución de los procesos asociados. El modelo de cascada supone, de manera general, que los requisitos del cliente no cambian radicalmente durante el transcurso de desarrollo del sistema.

2.2) Modelo en cascada:

Como se dijo anteriormente el modelo de cascada se estructura en varias fases, especialmente para ayudar a las empresas de desarrollo de software a construir un sistema de forma organizada y alivianando así a todo el proceso.

En este modelo se avanza a la etapa siguiente, una vez que la anterior haya sido

completada. De esta manera uno se va acercando gradualmente a la etapa final y una vez que se alcanza ese punto, no se puede dar marcha atrás. Las fases son las siguientes: o Captura de Requisitos: es el proceso donde se averigua qué es lo que debería hacer

el producto que vamos desarrollar. El sistema tiene que proporcionar valor al negocio para quien lo utiliza y para sus clientes. Esto se logra mediante una

5

descripción de los requisitos del sistema para llegar a un acuerdo entre el cliente y los desarrolladores sobre qué debe y qué no debe hacer el sistema.

o Análisis: en esta etapa se refinan y estructuran los requisitos capturados, para tener

una comprensión más precisa. Además se describen los mismos, para que nos ayuden a mantener y estructurar el sistema entero, incluyendo su arquitectura.

o Diseño: en el diseño modelamos el sistema y encontramos su forma, para que

soporte todos los requisitos. El propósito, es adquirir una comprensión en profundidad de los aspectos relacionados con los requisitos no funcionales y restricciones relacionadas con: los lenguajes de programación, componentes reutilizables, sistemas operativos, etc.

o Implementación: construimos el sistema en términos de componentes, es decir,

ficheros código de fuente, scripts, ficheros de código binario, ejecutables y similares.

o Pruebas: en esta fase verificamos el resultado de la implementación ejecutando

cada construcción, incluyendo tanto construcciones internas como intermedias, así como las versiones finales del sistema a ser entregadas a terceros.

o Mantenimiento: es el proceso de optimización del software después de su entrega

al usuario final, es decir, la revisión del programa. Así como también la corrección y prevención de los defectos.

Fig. 1: Modelo en Cascada.

6

2.3) Principales roles del modelo en cascada: Existen distintos roles que se distribuyen a los largo de las fases del modelo en

cascada. Entre los principales roles que pueden existir en un proyecto de desarrollo se encuentran los siguientes:

Cliente: o Conocer las distintas etapas y roles en la construcción del software. o Definir los objetivos del proyecto. o Definir y expresar los requisitos necesarios para desarrollar el sistema. o Revisar y aprobar los documentos en forma responsable. o Entregar los recursos necesarios para la realización del proyecto. Arquitecto: o Definir las vistas de la arquitectura de una aplicación (conjunto de vistas de alto

nivel). o Dar soporte técnico-tecnológico a desarrolladores, clientes y expertos en negocios. o Conceptualizar y experimentar con distintos enfoques arquitectónicos. o Crear documentos de modelos, componentes y especificaciones de interfaces. o Validar la arquitectura de forma de que cumpla con los requisitos. o Garantizar la integridad del modelo de análisis, diseño, implementación y

despliegue de manera de generar modelos correctos, consistentes y legibles en su totalidad.

Analista de Sistemas: o Analizar y comprender que el estado actual del proceso asegure que el contexto y las

implicaciones de los cambios sean comprendidos por el cliente y los miembros del equipo.

o Desarrollar un plan de gestión de requisitos y difundir el plan hacia todos los interesados.

o Describir y documentar los requisitos manifestados por el cliente. o Trabajar con el cliente para priorizar los requisitos. o Delimitar el sistema, encontrando los usuarios que interactúan con el sistema y

asegurándose que los requisitos estén completos y consistentes. Programador/Ing. de Componentes: o Definir y mantener las responsabilidades, atributos, relaciones de uno o varios

componentes, asegurándose de que cada componente implementa la funcionalidad correcta.

o Definir y mantener las operaciones, métodos, atributos, relaciones y requisitos de implementación del código fuente.

o Crear códigos de pruebas para verificar las funcionalidades. o Mantener la integridad de uno o varios subsistemas de implementación. Tester/Ingeniero de Pruebas: o Mantener la integridad del modelo de pruebas, asegurando que el modelo cumple

con su propósito. o Planificar las pruebas, definiendo objetivos de prueba apropiados. o Seleccionar y describir los casos de prueba y los procedimientos de prueba

correspondientes que se necesitan. o Realizar y evaluar las pruebas de integración y de sistema cuando éstas se ejecuten. o Documentar los defectos en los resultados de las pruebas de integración.

7

Diseñador de Interfaz de Usuario: dan forma visual a las interfaces de usuario en base a su experiencia en usabilidad.

ANÁLISIS

DISEÑO

IMPLEMENTACIÓN

PRUEBAS

MANTENIMIENTO

CAPTURA DE REQUISITOS

Analista de SistemasArquitecto Diseñador de IU

ProgramadorArquitecto

Analista de Sistemas ProgramadorArquitecto

ProgramadorArquitecto

ProgramadorTester

Analista de Sistemas

Programador

Cliente

Fig. 2: Roles del Modelo en Cascada.

2.4) Ventajas y desventajas:

Ventajas: o Es útil para sistemas en los cuales los requisitos nunca cambian. o Es un modelo sencillo y disciplinado. o Es fácil aprender a utilizarlo y comprender su funcionamiento. o Está dirigido por los tipos de documentos y resultados que deben obtenerse

al final de cada etapa. o Es muy usado y, por lo tanto, está ampliamente contrastado. o Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas. Desventajas: o Es poco probable que los proyectos sigan un proceso lineal tal como se

definía originalmente el ciclo de vida. o Es difícil que el cliente exponga explícitamente todos los requisitos al

principio. o Es necesario que el cliente tenga paciencia, ya que obtendrá el producto al

final del ciclo de vida. o Contribuye a que el equipo trabaje individualmente, preocupándose solo por

cumplir con sus funciones y responsabilidades, y no por el resultado total del producto, que surge del trabajo en equipo.

o Genera poca comunicación entre los miembros de todo el equipo, ya que solo intervienen en sus respectivas fases.

8

o Impulsa a que las actividades de control de calidad se realicen en las últimas fases, lo que acumula errores y defectos que pueden ser críticos.

o Es complicado regresar a fases anteriores para realizar correcciones. o Es muy probable que el producto final obtenido no refleje todos los

requisitos del usuario.

9

CAPÍTULO III: METODOLOGÍAS ÁGILES

3.1) Historia: En los primeros años de desarrollo de software, la mayoría de las necesidades de

los usuarios eran bastante estables, y los planes de desarrollo a seguir no sufrían grandes cambios. Sin embargo, como el desarrollo de software era más importante y crítico en los proyectos industriales, nuevas dificultades surgieron de acuerdo con el crecimiento de las empresas, las cuales son:

o La evolución de los requisitos: los requisitos de los clientes estaban cambiando,

debido a las necesidades empresariales en evolución o asuntos legislativos. La mayoría de los clientes, no tenían una visión clara acerca de las especificaciones de sus necesidades durante las primeras fases. Algunos clientes se daban cuenta de cuáles eran sus necesidades reales, sólo cuando utilizaban la aplicación, que no satisfacía sus necesidades.

o La participación de los clientes: la falta de participación del cliente durante el

desarrollo del software, conducía al proyecto a mayores posibilidades de fracaso. Muchas empresas, por lo general, no promovían la participación de los clientes.

o Plazos y presupuestos: las compañías solían ofrecer presupuestos bajos con plazos

ajustados, debido a la competencia en los mercados. Lo que resultaba costoso a la hora de llevar a cabo la implementación del sistema, para cumplir con lo pactado con el cliente.

o Falta de comunicación: una de las causas de la falta de comprensión de los

requisitos, era la falta de comunicación entre los desarrolladores y clientes. Por ejemplo, cada parte utilizaba su propio vocabulario, y esto conducía a la incomprensión de las necesidades del cliente.

Debido a esto un equipo de profesionales de TI comenzó a trabajar de forma

individual sobre los nuevos enfoques para el desarrollo de software. Los resultados de sus investigaciones fueron un conjunto de nuevas metodologías que tienen muchas características comunes. Cuando se conocieron en 2001, se creó el llamado: Manifiesto Ágil. Fue así como surgieron numerosas metodologías ágiles como:

o Scrum o XP (Extreme Programming) o Crystal Clear o DSDM (Dynamic Systems Developmemt Method) o FDD (Feature Driven Development) o ASD (Adaptive Software Development) o XBreed o Extreme Modelin

10

3.2) Principios ágiles: Como se explicó en el capítulo anterior, las metodologías ágiles se formaron de

acuerdo al manifiesto ágil, el cual expone los siguientes principios: a. Proveer retroalimentación continua:

La mayor prioridad es satisfacer al cliente mediante entregas tempranas e

iterativas del software. Una de las más importantes contribuciones es ayudar al cliente a especificar los requisitos y las pruebas, luego el equipo logra convertir los requisitos en ejecutables de prueba, que a menudo son guiados por una retroalimentación significativa.

Cuando el equipo se encuentra con obstáculos, la retroalimentación es una de las

maneras para eliminarlos, ya sea mediante los prototipos de interfaces de usuario presentados al cliente, así como también, a través del estado y la cobertura de las pruebas, o de la estabilidad del sistema.

b. Dar valor agregado al cliente:

El desarrollo ágil genera valor agregado en pequeñas iteraciones que proveen los

requisitos definidos y priorizados por el cliente. El cliente participa en las reuniones de planificación realizadas antes de cada iteración, donde se discuten detalles de los requisitos y de como probarlos. Una inocente pregunta puede incrementar la complejidad del requisito.

El equipo de desarrollo debe entregar la mayoría de las funcionalidades críticas

en la iteración actual, si se le da importancia a las funcionalidades que no son críticas o a las nuevas funcionalidades, se corre el riesgo de no llegar con la entrega a tiempo, y por lo tanto no se cumplirá con añadirle valor agregado al negocio. c. Conversación cara a cara:

Se sabe que los equipos no pueden trabajar bien, si no hay una buena

comunicación; más si aún no todos se encuentran geográficamente en el mismo lugar. Se debe visualizar cada requisito desde el punto de vista del cliente, pero además se deben tener en cuenta los aspectos y limitaciones a la hora de implementar esos requisitos. La comunicación no tiene reemplazo, el desarrollo ágil depende de la constante colaboración. d. Tener Coraje:

Se necesita coraje para cometer errores y aprender de ellos, se necesita decisión

para investigar y aplicar tecnologías jamás utilizadas, se necesita valentía para pedir ayuda, sobre todo si esta persona que va a proporcionar esa ayuda se ve cansada o estresada. Hacer una pregunta o señalar un defecto requiere coraje. Los equipos ágiles son abiertos y en general aceptan nuevas ideas. e. Mantener la simpleza:

No tiene ningún sentido construir complicadas estructuras que dificulten la

comprensión y utilización. Es preferible acudir a cosas sencillas y simples que, a primera vista, reflejen lo que se quiere expresar. Las metodologías ágiles, apuestan a la

11

sencillez, en su máxima expresión. Sencillez en el diseño, en el código, en los procesos, en las pruebas, etc. La sencillez es esencial para que todos puedan entender el código, y se trata de mejorar mediante refactorizaciones continuas.

f. Mejora continua:

Es tarea de todo el equipo buscar la mejor manera de hacer un trabajo. Todos los

miembros del equipo participan en las reuniones “retrospectivas” donde se evalúa y analiza que es lo que está haciendo bien y qué es lo que se debería agregar o modificar.

El equipo está en la continua búsqueda de herramientas, habilidades o prácticas

que pueden agregar valor al negocio, y las iteraciones cortas permiten que sea más fácil probar algo nuevo para unas pocas iteraciones y si vale la pena, se podrá adoptar a largo plazo.

g. Responder al cambio:

La pesadilla de todos los desarrolladores de software, es la continua evolución

de las necesidades, debido a la falta de estabilidad que sufre el sistema al aplicar los cambios. Es un asunto complicado, que podría resultar en la pérdida de tiempo si los requisitos se han re priorizado o si han cambiado mucho. Sin embargo se acepta que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

h. Auto - Organizarse:

Cuando un equipo se enfrenta a algún problema, es problema de todos, por lo

que los miembros de todo el equipo deben discutir el asunto de inmediato y decidir cómo y quién lo resolverá. El equipo tiene la autonomía para organizarse para desarrollar en la mejor forma sus resultados.

Para que la auto-organización funcione, un equipo debe tener autonomía, no

deben ser molestados y se debe confiar en ellos. La confianza es difícil cuando los requisitos son vagos, y la autogestión es imposible cuando el equipo experimenta continuas interferencias con respecto a las tecnologías, herramientas y prácticas que se utilizan. i. Centrado en las personas:

Los miembros del equipo deben sentirse seguros y no tener que preocuparse de

ser culpados por los errores o de perder sus puestos de trabajo. Se deben respetar mutuamente y reconocer los logros individuales. Todos en un equipo ágil deben tener oportunidades para crecer y desarrollar sus habilidades. j. Disfrutar de lo que se hace:

Un equipo donde todo el mundo colabora, donde todos están involucrados desde

principio hasta fin, donde los clientes trabajen juntos con los desarrolladores, donde todo el equipo asume la responsabilidad de calidad; son elementos que encaminan a que el trabajo pueda realizarse con mayor satisfacción.

12

3.3) Scrum: De las metodologías ágiles anteriormente nombradas en el capítulo 3, se

seleccionó Scrum porque es una de las metodologías predominantemente utilizadas en el desarrollo de software debido a las prácticas y actividades que impulsa.

Scrum es un marco de trabajo que consiste en entregar parte de un producto en

pequeñas iteraciones que pueden ser entre 2, 4 ó 6 semanas, estas iteraciones son denominadas “Sprint”.

Esta metodología reconoce tres grandes roles: Dueño del Producto, Scrum Master y Equipo de Scrum, quienes participan en un conjunto de reuniones que se realizan en cada Sprint, llamadas: Planificación de Sprint, Scrum Diario, Demostración de Sprint y Retrospectivas de Sprint.

Fig. 3: Reuniones de Scrum.

a. Planificación de Sprint:

El dueño del producto define mediante historias de usuario, un conjunto de

requisitos listos para ser propuestos al equipo de Scrum para que lleven a cabo su desarrollo. A este conjunto de requisitos se los denomina “Pila del Producto”.

Fig. 4: Historia de Usuario con criterios de aceptación y dividida en tareas.

Esta reunión se realiza al principio del Sprint, en donde el dueño del producto

comenta la meta del Sprint y prioriza las historias de usuario de la Pila de Producto para que formen parte de la “Pila del Sprint”. El propósito de esta reunión, es darle al equipo la suficiente información, para que puedan trabajar sin ninguna interrupción. El equipo

13

decide cuántas historias se incluirán en el Sprint de acuerdo al tiempo estimado en base a su experiencia o a estimaciones anteriores. Para realizar una estimación más realista, el dueño del producto define criterios de aceptación para cada historia de usuario, y el equipo de Scrum divide cada historia de usuario en tareas.

Fig. 5: Actividades del dueño del producto.

Pila del SprintPila del Sprint

Historia de Usuario 008- CA001- CA002- CA003






- T001- T002- T003

- T001- T002- T003

- T001- T002- T003

- T001- T002- T003

- T001- T002- T003

- T001- T002- T003

Equipo de Scrum

EstimaDivide en tareas

Planificación de Sprint 32 hrs. 20 hrs. 11 hrs.

10 hrs. 6 hrs. 5 hrs.







- T001- T002- T003

- T001- T002- T003

- T001- T002- T003

- T001- T002- T003

- T001- T002- T003

- T001- T002- T003

Fig. 6: Actividades del equipo de Scrum.

El equipo puede rechazar o no las historias de usuario que formen parte del

Sprint, todo dependerá de la negociación que se genere entre ambos, en donde si al dueño del producto no le agrada que algunas historias queden fuera del Sprint, tendrá que repriorizar las historias de usuario, subdividirlas o reducir el alcance de las mismas.

Como conclusión de la planificación del sprint, el dueño del producto define el alcance e importancia, mientras que el equipo de Scrum realiza la estimación. b. Scrum Diario:

El Scrum Diario es una reunión de 15 minutos máximo, que se realiza todos los

días y participan todos los miembros del equipo de Scrum durante el desarrollo de un Sprint. Durante esta reunión el equipo sincroniza su trabajo, progreso e informa cualquier impedimento que tenga o prevea al Scrum Master. Cada miembro del equipo debe responder a estas preguntas:

14

o ¿Qué hiciste desde el último Scrum Diario? o ¿Qué harás desde ahora y hasta el próximo Scrum diario? o ¿Qué te está impidiendo hacer tu trabajo lo mejor posible?

Fig. 7: Scrum diario.

Esta reunión es de suma utilidad y tiene los siguientes beneficios: o Se identifican los impedimentos prontamente, para poder mantener el ritmo

de desarrollo. o Se disminuye la duplicación de esfuerzo. o Se comparten objetivos y una dirección clara en el equipo. o Se construye confianza y motivación durante el Sprint. o Se conoce sobre qué actividades está trabajando cada miembro del equipo. o Mejora la comunicación del equipo y sus relaciones.

c. Demostración de Sprint:

El objetivo de la demo, es tener las funcionalidades terminadas, probadas, demostrables, y entregables. Esta reunión se hace al final del Sprint y sirve para:

o Obtener el reconocimiento del equipo por sus logros. o Informar a terceros sobre las actividades que realiza el equipo. o Conseguir la retroalimentación vital de los interesados. o Forzar al equipo a terminar realmente las cosas y entregarlas. o Incrementar significativamente las posibilidades de que haya algo útil que

demostrar.

Fig. 8: Demostración de Sprint.

15

d. Retrospectiva de Sprint:

Con el objetivo de mejorar de manera continua la productividad y la calidad del

producto que se está desarrollando, el equipo analiza cómo ha sido su manera de trabajar durante la iteración, para determinar si está alcanzando o no los objetivos a los cuales se comprometió al inicio del Sprint. Esta reunión que se realiza después de la demo de Sprint sirve para saber:

o ¿Qué cosas han funcionado bien? o ¿Qué cosas hay que mejorar? o ¿Qué acciones hay que llevar a cabo para mejorar el trabajo?

Fig. 9: Retrospectiva de Sprint.

Este ciclo iterativo se repite hasta que un conjunto de funcionalidades generen

un producto utilizable para sus usuarios, a esto se le llama “Sprint Release”. Un Sprint Release, no debería ser más largo que un Sprint normal. Es una buena práctica que asegura, que el sistema esté en un estado tal que un sólo Sprint, alcance para ponerlo en producción. Si la respuesta es negativa, entonces el equipo debería mejorar la calidad del código existente y verificar que su concepto de "terminado" es lo suficientemente completo.

DÍA 1 DÍA 1DÍA 2 DÍA 3 DÍA 4 DÍA 5 DÍA 6 DÍA 7

Planificación de Sprint


ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

Demostraciónde Sprint

ScrumDiario

Retrospectivadel Sprint


Planificación de Sprint


ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

ScrumDiario

Demostraciónde Sprint

ScrumDiario

Retrospectivadel Sprint

SPRINT 1 SPRINT 2

SPRINT RELEASE

Fig. 10: Sprint Release.

16

3.4) Roles en Scrum:

Como mencionamos anteriormente existen tres grandes roles en Scrum, los

cuales tienen las siguientes funciones y responsabilidades: Dueño de Producto: o Decidir sobre cuáles funcionalidades y características funcionales tendrá el

producto. o Representar al cliente, usuarios del software y todas aquellas partes interesadas en el

producto. o Canalizar las necesidades del negocio, sabiendo "escuchar" a las partes interesadas

en el producto y transmitirlas en "objetivos de valor para el producto", al equipo de Scrum.

o Maximizar el valor para el negocio con respecto al Retorno de Inversión (ROI), resguardando los intereses del negocio.

o Revisar el producto e ir adaptándole sus requisitos, analizando las mejoras que éstas puedan otorgar un mayor valor para el negocio.

Scrum Master: o Fomentar e instruir sobre los principios ágiles de Scrum. o Garantizar la correcta aplicación de Scrum. o Resolver los conflictos que entorpezcan el progreso del proyecto. o Incentivar y motivar al equipo de Scrum, creando un clima de trabajo colaborativo. o Fomentar la auto-gestión del equipo. o Impedir la intervención de terceros en la gestión del equipo. Equipo de Scrum: o Analizar, evaluar, aceptar o rechazar los requisitos propuestos por el dueño del

producto. o Estimar en tiempo las historias de usuario correspondientes al Sprint. o Entregar el producto a través de desarrollos potencialmente funcionales y

operativos. o Contar con capacidades profesionales de nivel experto o avanzado en su disciplina. o Tener vocación para trabajar en equipo. o Poseer capacidad de auto-gestión. o Conocer la metodología Scrum.

El equipo de Scrum es un “equipo de desarrolladores” multidisciplinario, integrado por programadores, diseñadores, arquitectos, administradores de base de datos, encargados del control de calidad y demás, que en forma auto-organizada, serán los encargados de desarrollar el producto.

Si bien las funciones y responsabilidades que realiza cada miembro del equipo

de desarrollo son similares a las que existen en un modelo en cascada, la gran diferencia es que cada miembro tiene como objetivo principal obtener un software con la máxima calidad posible en sus distintas etapas, y no sólo en la etapa de pruebas, ya que esta etapa, es un componente central del desarrollo ágil de software y debe estar presente en todo momento. En las metodologías ágiles todos tienen que colaborar con la calidad del software.

17

Por esta razón el papel del encargado del control de calidad, es clave para el éxito de todo proyecto, ya que no sólo es el que ejecuta las pruebas sino que también está al tanto de los demás aspectos del software que contribuyen hacia una mejor calidad como: o Reunir, compartir información y trabajar con el dueño del producto con el fin de

ayudarle a expresar sus necesidades de manera adecuada para que pueda obtener las características que necesita, y para proporcionar información sobre los avances del proyecto a todos los miembros del equipo.

o Colaborar con las personas del negocio y profesionales técnicos que comprenden los conceptos de pruebas para documentar requisitos y guiar el desarrollo.

o Saber colaborar con el resto del equipo para tener una visión más detallada del problema que se piensa solucionar con el software.

o Planificar y ejecutar los distintos tipos de pruebas.

Además del equipo de desarrollo, también existe el “equipo del cliente”, este equipo se comunica y colabora con el equipo de desarrollo, respondiendo preguntas, graficando ejemplos y revisando historias de usuarios. Entre los miembros del equipo del cliente pueden estar: los dueños del producto, expertos del negocio, expertos del dominio, analistas de negocio, administradores del producto, etc.

Ambos equipos trabajan juntos todo el tiempo. Ellos son sólo un equipo con un

objetivo en común, este objetivo es darle valor agregado al negocio. El equipo del cliente con el aporte de los desarrolladores priorizará las historias de usuario a desarrollar, y el equipo de desarrollo determinará cuál será el esfuerzo que les demandará.

Valor agregado al

NegocioEquipo de DesarolloEquipo del Cliente

Scrum Master

Fig. 11: Equipo del cliente y desarrollo trabajando como un solo equipo.

18

3.5) Ventajas y desventajas:

Ventajas: o Es más rápido, ya que se obtiene un producto funcional al finalizar cada

Sprint que cumple con los requisitos planificados. o Es flexible, ya que nos permite ajustar las funcionalidades en base a la

necesidad del negocio del cliente. o Permite producir software de una forma consistente, sostenida y competitiva. o Provee visualización del proyecto día a día. o Contribuye a que el equipo trabaje de forma integrada y comprometida. o Mantiene la efectividad del equipo habilitando y protegiendo un entorno

libre de interrupciones e interferencias. o Evita el estancamiento, ya que las reuniones se dedican a inconvenientes

recientes. Desventajas: o Genera poca evidencia o documentación, a comparación de otras

metodologías. o Expone ciertas prácticas que no pueden ser aplicadas por todos los proyectos

de desarrollo de software. o Requiere delegar responsabilidades al equipo, incluso permite fallar si es

necesario. o Causa cierta resistencia en su aplicación para algunas personas.

19

CAPÍTULO IV: TRANSICIÓN HACIA LAS METODOLOGÍAS ÁGILES

4.1) Cultura Organizacional:

Como se vió en el capítulo anterior la razón de la existencia de las metodologías ágiles, se debe a que son metodologías que se adaptan al cambio de los requisitos, ya que al ser iterativas, se puede obtener una mejor retroalimentación con el cliente, y a su vez lograr una mejor calidad en el software.

A pesar de que las nuevas metodologías solucionaron problemas que las

metodologías tradicionales no tuvieron en cuenta. Apareció una gran causante de nuevos problemas a la hora de aplicar una metodología ágil, la “resistencia al cambio”. Es por ello, que la cultura organizacional es un factor clave, ya que puede afectar el éxito de un equipo ágil.

o Resistencia al cambio:

Las organizaciones, al igual que los individuos, tienden a resistirse al cambio, negándose a adaptar a las diferentes transformaciones que suceden en su medio por ser este difícil o costoso. El cambio significa para éstos moverse desde una situación actual y estable, hacia otra situación que genera incertidumbre, debido a que se piensa que este cambio traerá consecuencias negativas. Cuanto más grande sea el cambio, mayor será la resistencia. 4.2) Problemas que surgen de la aplicación de las metodologías ágiles:

Existen diversos problemas que derivan de la resistencia al cambio y la mediocridad; pero los principales y más comunes son: 4.2.1) Con respecto al cliente: a. Escasa o nula participación y comunicación durante el desarrollo del software:

El cliente por lo general tiene un comportamiento muy distinto a lo que sugieren

los principios ágiles, con respecto a su participación. Si bien éste puede participar en las reuniones de planificación, demostración y retrospectiva de Sprint, suele tener muy poca interacción con los miembros del equipo, ya que casi nunca se encuentra disponible durante el transcurso del desarrollo del software.

Esto afecta gravemente a un equipo ágil, ya que las preguntas, dudas o

sugerencias realizadas por el equipo no pueden ser respondidas. Este inconveniente resulta ser un impedimento común en todo equipo, que si no se soluciona rápidamente, reduce la productividad del equipo de desarrollo.

Lo que se suele hacer para solucionar esto, es hacer uso de distintos medios de

comunicación como correos electrónicos, chats, etc. De no mejorar la comunicación por éstos medios, lo que se hace comúnmente, es suponer cuál será la respuesta del cliente, y es aquí donde surgen diversas suposiciones por parte del equipo de desarrollo, lo que perjudica directamente la calidad del software, produciendo así, la disconformidad del cliente.

20

Fig. 12: Escasa o nula participación del cliente.

4.2.2) Con respecto al equipo de desarrollo: a. Escasez de tiempo de desarrollo del software:

Parece poco creíble que la escasez de tiempo sea un problema fundamental en el

uso de las metodologías ágiles, ya que las iteraciones son cortas y es notorio rápidamente si el progreso del desarrollo van encaminado o no.

La escasez de tiempo es un gran desencadenante de problemas que suelen

afectar al equipo, al cliente como también a la calidad del producto y entre estos subproblemas se encuentran:

o Horas de trabajo extra:

A menudo surgen situaciones en las cuales los miembros del equipo como los

líderes, comprometen a todo el equipo a cumplir con el desarrollo de todos los requisitos propuestos por el cliente, sin importarles las opiniones del resto del equipo de desarrollo, que son los que tienen que estimar y aceptar, rechazar, acotar o extender el conjunto de requisitos propuestos a ser desarrollados durante la iteración. Esta actitud es conocida con la frase “Nosotros podemos hacerlo”, logrando como resultado el fracaso de la iteración, ya que siempre se hace el compromiso, la negociación beneficiando al cliente y no de forma equitativa. Cercana a la fecha final de cada iteración se puede ver claramente los esfuerzos extra que realiza cada miembro del equipo por intentar cumplir con lo pactado. o Escasa o nula calidad del software:

No hay tiempo suficiente para programar los requisitos del cliente, mucho

menos para probar el funcionamiento de los mismos. Los programadores solo se ocupan de probar los casos de prueba positivos que nacen de su creatividad y entienden como críticos para dar por terminada la funcionalidad, restándoles importancia a los casos de pruebas negativos y/o alternativos que pueden surgir de la misma.

Cercana a la fecha final de cada iteración, el equipo de programadores entrega la

versión del software desarrollada al equipo de control de calidad, los cuales tienen tiempo solo para llevar a cabo algunas pruebas funcionales, que se creen que son suficientes, para obtener una calidad de software aceptable; dejando de lado otros tipos de prueba, como las pruebas automatizadas, pruebas de exploración, pruebas de usabilidad, pruebas de aceptación de usuario y mucho menos hablar de pruebas de carga, performance y seguridad.

21

Al final las pocas pruebas funcionales que se le aplican al software, realizadas

por el equipo de desarrollo terminan siendo insuficientes, provocando una acumulación de errores y defectos que probablemente serán arreglados, durante alguna iteración futura.

o Acumulación de la deuda técnica:

La misma desesperación por dar como concluida una funcionalidad determinada,

incita al programador a buscar soluciones temporales, que les ayudan a reducir las presiones que están padeciendo.

Poco a poco, durante cada iteración se va perdiendo las buenas prácticas de

programación, como la utilización de convenciones de nombres, comentarios en el código, manejo de errores, uso de variables, etc.; así como también se va perdiendo la arquitectura del software, debido a que los patrones de diseño inicialmente planteados no se están respetando.

La integración del código resulta todavía más costosa, más aún cuando trabajan

varios sub-equipos juntos. Cuando se intenta hacer funcionar el código en conjunto, es común encontrar que el código se rompa fácilmente, ya que este no es seguro ni fiable. Aquí saltan a la luz un conjunto de problemas técnicos acumulados por cada sub-equipo y durante cada iteración. Permaneciendo así, la deuda técnica en la memoria y conciencia de cada uno de los miembros del equipo de desarrollo, ya que reducir esa deuda, es muy costosa, pues no solo porque implica mucho esfuerzo, sino también porque implica tiempo y dinero.

o Nula documentación del sistema:

Si bien las metodologías ágiles enfatizan la comunicación cara a cara, por

encima de la documentación exhaustiva. El manifiesto ágil, no afirma que la documentación no sea necesaria. Este concepto, es casi siempre mal interpretado por el equipo de desarrollo, ya que entienden por equipo ágil, producir rápida y desordenadamente. Evitando así la documentación básica del sistema.

La documentación permite la transferencia del conocimiento, registra la

información histórica, y en muchas cuestiones legales o normativas son obligatorias. Un sistema sin documentación básica y necesaria, es imposible de entender tanto para los usuarios, los clientes, como para los futuros miembros del equipo de desarrollo. Si un nuevo miembro del equipo de desarrollo hace su ingreso ¿cómo entenderá el funcionamiento del sistema?, ¿será suficiente con hablar con el especialista de cada módulo del sistema?

o No se disfruta de lo que se hace:

Durante cada iteración el equipo de desarrollo ha intentado dar lo mejor de sí,

han invertido esfuerzos extras como dedicación y tiempo; pero estos esfuerzos resultan en vano ya que los resultados no son favorables.

¿A quién le gusta trabajar presionado por los tiempos?, ¿a quién le gusta trabajar

en un proyecto que no presenta avances?, ¿a quién le gusta trabajar lleno de incertidumbre?, ¿a quién no le gusta ser reconocido por los logros obtenidos? Todas

22

estas razones producen en los miembros del equipo, que cada vez se trabaje con menos motivación y con menos deseos de seguir siendo parte del equipo.

b. Conceptos erróneos sobre los profesionales de control de calidad:

Debido a que durante el desarrollo de software, se le presta mayor atención a las

actividades de programación, resulta obvio que mayor importancia se les dará a los programadores, ya que a éstos se les procura y exige mayor participación, comunicación, formación y capacitación en las cuestiones del equipo en un amplio sentido. Restándole importancia a los demás miembros del equipo, como es el caso de los profesionales de control de calidad. De este punto también se generan un conjunto de subproblemas:

o Se piensa que el rol del profesional de control de calidad, es el rol de un

usuario del sistema:

Muchas empresas, cometen el error de creer que el profesional de control de calidad, tiene sólo como objetivo verificar si las interfaces de usuario del sistema, realizan las funcionalidades adecuadas.

Con esta mentalidad las empresas, buscan y contratan personas para este tipo de

rol, sin importarles su formación y capacitación; contratando incluso, de esta manera, a personas con estudios que no están relacionados a las ciencias informáticas.

La ventaja que tienen, es que no les es costoso conseguir a una persona que

ocupe este rol. Lo que no tienen en cuenta, es el riesgo que corren al realizar este tipo de acciones.

o El equipo de control de calidad es excluido de las reuniones técnicas y de

negocios:

Contar con profesionales de control de calidad, que no tienen una buena formación profesional, es una gran desventaja.

Por esta desventaja, que se presenta la mayor parte de las veces, comúnmente se

suele excluir al equipo de control de calidad de las reuniones técnicas y de negocios, ya que se considera, que éstos no poseen los conocimientos suficientes para aportar con alguna idea, que le de valor al equipo y al negocio; y que de participar éstos, sería una pérdida de tiempo.

Se piensa erróneamente que los profesionales de control de calidad solo deben

estar enfocados en actividades de pruebas y que solo deben tener contacto con el sistema, una vez que las funcionalidades desarrolladas estén terminadas. o Se genera rivalidad entre el equipo de control de calidad y el equipo de

programación:

Como el equipo de control de calidad, se centra a las actividades de prueba, la única forma de demostrar su progreso, es encontrando la mayor cantidad de defectos y errores en el sistema. Erróneamente, se suele premiar a la persona que lleva a cabo este objetivo con mucha satisfacción.

23

Satisfacción por un lado, insatisfacción por el otro. Ya que los programadores

tienen poco tiempo para desarrollar las funcionalidades y además tienen un listado de errores y defectos que va creciendo a pasos agigantados.

Esta situación genera una profunda rivalidad, por lo que los programadores

suelen dejarle la responsabilidad total de la calidad del software al equipo de control de calidad, con frases conocidas como: “Si hay algún error en el sistema, es porque ellos no lo detectaron a tiempo”. Mientras que el equipo de control de calidad seguirá aumentando el listado de defectos y errores.

Se debe recordar, que este tipo de actitudes no nos llevarán al éxito, ya que en

las metodologías ágiles lo que se busca, es obtener la mejor calidad posible del software y una de las cosas para lograr esto, es el trabajo en equipo.

4.2.3) Con respecto al gerente de desarrollo: a. Dificultad para medir el progreso del proyecto:

El gerente de desarrollo necesita saber el progreso del equipo. Si bien cuenta con

diversas herramientas para medir la velocidad del equipo como es el burndown chart (gráfica de trabajo pendiente), resulta difícil poder controlar y medir la calidad interna del software.

Por este motivo en el inicio del proyecto, es común que se encuentren con

clientes satisfechos con el producto desarrollado, ya que solo éstos pueden percibir la calidad externa del producto y no así la interna. Cuando se intenta trabajar con cuestiones más complejas, como por ejemplo la performance del sistema, es donde notan que la calidad interna del software, no es tan buena como parecía en un principio.

Es por ello que el gerente de desarrollo, más allá de encontrar un cliente

satisfecho, debe verificar si tanto la calidad externa como interna van por buen camino a través de métricas más confiables.

24

Fig. 13: Problemas que surgen de la aplicación de las metodologías ágiles.

De los problemas planteados anteriormente, es difícil intentar solucionar los relacionados con el cliente, ya que depende absolutamente de ellos mejorar la participación y comunicación con el equipo de desarrollo o de reemplazar a la persona encargada de llevar a cabo dicha comunicación, con el objetivo de que finalmente salga todo de acuerdo a lo planificado.

Es por ello que este seminario, tiene como objetivo intentar solucionar los

problemas relacionados con respecto al gerente y al equipo de desarrollo, ya que son fundamentales para contribuir en la calidad del software.

25

CAPÍTULO V: AUTOMATIZACIÓN DE PRUEBAS

La automatización de pruebas surgió en los primeros años del nuevo milenio, con los objetivos de reducir los tiempos de prueba, mejorar la cobertura de pruebas, reducir el número de recursos involucrados en el desarrollo, entre otros. Dicha actividad, consiste en la automatización de un proceso manual de pruebas, a través de la utilización de software para controlar su ejecución, comparar los resultados actuales con los resultados previstos, crear precondiciones de prueba y otros tipos de controles.

Como se ve, la automatización de pruebas no es nada nuevo, pero ¿por qué actualmente no es fuertemente aplicado en los proyectos de desarrollo de software?, ¿por qué las empresas de desarrollo no impulsan la utilización de la misma? 5.1) Conceptos erróneos sobre la automatización de pruebas:

Hay dos tipos de ideas que son usuales en cuanto a la adopción de la

automatización de pruebas:

a. No se aplica la automatización de pruebas porque se piensa que: o Es muy difícil implementar. o Es costoso encontrar recursos con perfiles adecuados para llevar a cabo su

implementación. o Es difícil recuperar el ROI. o Consume mucho tiempo. o Entorpece el trabajo de los programadores. o Es menos importante que el desarrollo de nuevas funcionalidades.

En un proceso de desarrollo, donde no se aplica la automatización de pruebas, el

software poco a poco con el tiempo, tiene la tendencia a acumular errores y defectos, así como también acumular la deuda técnica. Resulta costoso someterlo a pruebas complejas, ya que es fácilmente vulnerable con un mínimo esfuerzo.

Fig. 14: Software que no aplica automatización de pruebas.

26

b. Se aplica la automatización de pruebas porque se piensa que: o Es fácil de implementar. o Es sencillo de crear, ya que el software lo hace automáticamente y se ejecuta. o Es rápidamente el ROI recuperado. o Reemplaza todos los problemas relacionados a las pruebas.

Con esta idea, la automatización de pruebas, es considerada dentro del proceso

de desarrollo de software; pero con el tiempo sienten que dicha actividad resulta costosa, ya que no es tan fácil de implementar como pensaban, se van dando cuenta que la automatización, no resuelve todos los problemas relacionados a las pruebas y que no reemplaza totalmente a los demás tipos de pruebas, les resulta difícil llevar a cabo su mantenimiento y por lo tanto no pueden recuperar el ROI rápidamente como ellos esperaban. Finalmente terminan optando por abandonar esta actividad.

Fig. 15: Software que aplica automatización de pruebas inadecuadamente.

La realidad es que la automatización de pruebas, es una actividad de control de

calidad fundamental en el desarrollo de software, es por ello que debe ser diseñada, implementada y probada.

Para evitar que se generen ideas erróneas, sobre la automatización de pruebas,

debemos dejar en claro que no es tarea fácil; pero tampoco imposible. Se debe tener en cuenta diversas cuestiones a la hora de decidir si es factible o no la implementación de pruebas automatizadas, como por ejemplo:

o ¿Con qué tipo de sistema se va a interactuar? o ¿Qué estrategias de prueba se utilizarán? o ¿Qué estrategias de automatización se utilizarán? o ¿El cliente es consciente del valor que tiene la automatización de pruebas? o ¿Qué impedimentos pueden llegar a presentarse para llevar a cabo una

automatización de pruebas exitosa? o ¿En qué momento de la iteración se debe automatizar? o ¿Qué casos de prueba se automatizarán? o ¿Qué herramientas de automatización se utilizarán?

27

5.2) Tipos de sistemas:

Es necesario saber con que tipo de sistemas se va a interactuar y cuál será el objetivo de este, ya que es necesario, para evaluar qué estrategia de pruebas se implementará, para lograr una calidad de software aceptable.

Restricciones diferentes, requieren diferentes tipos de aplicaciones. Todas las

aplicaciones no son iguales. Cada proyecto tiene diferentes requisitos funcionales y no funcionales, que requieren diferentes tipos de aplicaciones.

a. Aplicaciones de cliente enriquecidas:

También denominadas aplicaciones de escritorio. Son aplicaciones

independientes desarrolladas con una interfaz de usuario rica y gran capacidad de respuesta gráfica. Puede tener distintos escenarios de conectividad: sin conectividad, conectividad ocasional o constante.

Las aplicaciones de cliente enriquecidas pueden beneficiarse de los recursos de

la máquina del cliente, ya que suelen centrarse en una plataforma específica. Para utilizar aplicaciones de cliente enriquecidas se debe plantear si: o La aplicación debe ser compatible con escenarios sin conexión o que solo

dispongan de conexión esporádica. o La aplicación debe ser muy interactiva y con gran capacidad de respuesta. o La interfaz de usuario de la aplicación debe ofrecer una amplia

funcionalidad, con posibilidades como la visualización en 3D y la interacción entre usuarios.

o Las aplicaciones deben aprovechar los recursos del PC cliente.

Componentes de Interfaz de Usuario

Componentes de Procesos de Interfaz de Usuario

Aplicación Fachada

Flujo de Trabajode Negocio

Componentes de Negocio

Entidades de Negocio

Componentes de Acceso a Datos

Servicios de Datos Externos

Agentes de Servicio

Aplicación de Cliente Enriquecida

Datos Locales

Datos Externos

ServiciosFuente: Microsoft Fecha: Octubre 2009

Fig. 16: Arquetipo de una aplicación de cliente enriquecida.

28

b. Aplicaciones de Internet enriquecidas:

Como su nombre lo indica, estas aplicaciones tienen una rica respuesta de interfaz gráfica de usuario (GUI).

Lo único acerca de las aplicaciones ricas de Internet, es que están diseñadas para

ejecutarse en un navegador, por lo que tiene "profundo" alcance. Ya que soporta muchas plataformas y por lo tanto reduce los costos de desarrollo.

Se debe tener en cuenta que las aplicaciones de Internet enriquecida, no pueden

beneficiarse plenamente de los recursos de la máquina cliente.

Aplicación de Internet Enriquecida

Cliente

NavegadorContenedor de Ejecución de UI Enriquecida

Motor de UI Enriquecida

Capa de Presentación

Servidor Web

Capa de Servicio

Capa de Negocio



Capa de Acceso a Datos


Servidor de Base de Datos

Fuente: Microsoft Fecha: Octubre 2009

Fig. 17: Arquetipo de una aplicación de Internet enriquecida.

c. Aplicaciones de Servicios:

También denominado servicios web, es una pieza de software que utiliza un conjunto de protocolos y estándares, que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos.

Con este tipo de aplicación se puede reducir costos y consolidar toda la lógica empresarial en un solo lugar, en donde todas las otras aplicaciones de software pueden acceder y utilizar. Esto también reducirá los errores que se producen de tener la lógica de negocio distribuida por todo el lugar.

29

Segu

ridad

Adm

inis

trac

ión

Ope

raci

onal

Com

unic

ació

n

Cort

e Tr

ansv

ersa

l

Servicios Consumidores

Interfaces de Servicios Tipos de Mensajes

Aplicación Fachada

Flujo de Trabajode Negocio

Componentesde Negocio

Entidadesde Negocio



Agentes de Servicio

Sistemas Externos

Serv

icio

sN

egoc

ioD

atos

Origen de Datos Servicios

Aplicación de Servicios


Fig. 18: Arquetipo de una aplicación de servicios web.

d. Aplicaciones Web: Por lo general el desarrollo de aplicaciones web, es para los casos en que la

aplicación necesita una amplia exposición y/o accesibilidad. Sumado a esto, estas aplicaciones deben tener compatibilidad con múltiples navegadores, sistemas operativos y plataformas.

Las aplicaciones Web requieren conectividad de red permanente. Los tipos de

desarrollo web, van desde un simple sitio web típico a un sistema con funcionalidades complejas.

Segu

ridad

Adm

inis

trac

ión

Ope

raci

onal

Com

unic

ació

n

Cort

e Tr

ansv

ersa

l

Renderizado

Componentes UI

Procesos de Componentes UI

Aplicación Fachada

Flujo de Trabajo de Negocio



ClienteNavegador

Servidor Web

Neg

ocio

Dat

os Componentes de Acceso a Datos


Agentes de Servicio

Servidor de Base de Datos Servicios

Aplicación Web


Fig. 19: Arquetipo de una aplicación web.

30

e. Aplicaciones Móviles: En este tipo de aplicaciones se nos presentan dos opciones. La primera opción es donde el anfitrión del software cliente será típicamente el navegador de Internet, ya existente en el dispositivo móvil y un sitio web específico para móviles. Esto requiere de una conectividad constante a Internet.

La segunda opción consiste en una interfaz gráfica de usuario rica y sensible, que aprovecha de un hardware específico del dispositivo, sistema operativo y la capacidad de marco (como el iPhone). Esta opción requiere de más esfuerzo de desarrollo y por lo tanto es más costosa, ya que podría existir la necesidad de desarrollar una aplicación separada para cada dispositivo. Además requiere una conectividad ocasional a Internet como mínimo.

Fig. 20: Arquetipo de una aplicación móvil.

5.3) Estrategias de prueba: Ya sabemos con qué tipo de sistema se va a interactuar, ahora se debe seleccionar la estrategia de pruebas necesaria, de acuerdo al objetivo y al uso del sistema. Según el libro “Agile Testing” de Lisa Crispin y Janet Gregory, existen diversos tipos de pruebas que cumplen distintas metas, que se representan mediante los “Cuadrantes de las Pruebas Ágiles”.

La figura 21, muestra que en el eje horizontal va desde lo más tecnológico hasta lo más orientado al negocio, desde luego ambas cosas tienen valor y la segunda se funda en la primera. En el eje vertical en cambio hay dos caras, una que apunta a contribuir con pruebas que apoyen de alguna manera las labores de resto del equipo y la otra que se orienta a criticar el producto.

31

Apoyar al equipo con pruebas manuales no siempre, es la forma más efectiva como puede deducirse en este diagrama, las pruebas tienen un gran valor; pero se vuelven aún más valiosas cuando dejan de ser una tarea mecánica y se convierten en una tarea exploratoria tendiente no solo a buscar defectos sino oportunidades de mejora para el software.

Fig. 21: Cuadrantes de las Pruebas Ágiles.

Esta división en cuadrantes, también ayuda a identificar qué parte está siendo

probada y quién realizó esa labor o qué habilidades y herramientas son requeridas para realizar cada tipo de pruebas. a. Primer Cuadrante:

En el primer cuadrante Q1, las “pruebas unitarias” son implementadas por los programadores, con el objetivo de verificar la funcionalidad de un pequeño subconjunto del sistema, como un objeto o método. Para este tipo de prácticas está lo que se conoce como TDD (Test Driven Development – Desarrollo guiado por pruebas), que consiste en:

o Seleccionar un requisito. o Crear la prueba unitaria para el requisito seleccionado de manera tal que

espere un resultado adecuado. o Asegurar de que la prueba falle. o Implementar la funcionalidad. o Ejecutar la prueba unitaria para cerciorarse de que la funcionalidad esté

correctamente implementada; de no ser así se tendrá que refactorizar el código hasta que la prueba unitaria obtenga un resultado exitoso.

Fig. 22: Diagrama de flujo de TDD.

32

El propósito del desarrollo guiado por pruebas, es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará el software, cumple con los requisitos que se han establecido.

Fig. 23: Creando prueba unitaria.

Fig. 24: Refactorizando código para que la prueba sea exitosa.

Las pruebas de componentes verifican el comportamiento de una parte mayor

del sistema, tal como un grupo de clases que proporcionan algún servicio. Ambos tipos de pruebas, suelen ser automatizados. Las pruebas unitarias y de componentes están automatizadas y escritas en el mismo lenguaje de programación como de la aplicación.

Un experto en negocios probablemente, no podría entender mediante la lectura

de las pruebas unitarias lo que se está verificando, pero estas pruebas no están destinadas para uso del cliente. De hecho, la calidad interna no se negocia con el cliente, es definido por los programadores. Las pruebas del programador son normalmente parte de un proceso automatizado que funciona con todos los códigos del sistema, proporcionando al equipo de respuesta inmediata y continua acerca de su calidad interna. b. Segundo Cuadrante:

Las pruebas en el cuadrante Q2 también apoyan el trabajo del equipo de desarrollo, pero a un nivel superior. Estas pruebas definen la calidad externa y las características que desean los clientes.

Con el desarrollo ágil, estas pruebas se derivan de los ejemplos proporcionados

por el equipo del cliente, que describen los detalles de cada historia. Están escritos en una forma que los expertos de negocios puedan entender fácilmente utilizando el lenguaje de dominio del negocio. De hecho, los expertos de negocios, usan estas pruebas para definir la calidad externa del producto. Es posible que este cuadrante, podría duplicar algunas de las pruebas que se realizaron a nivel de unidad, sin embargo, las pruebas de este cuadrante, están orientadas a ilustrar y confirmar el comportamiento deseado del sistema en un nivel superior.

33

Hay otro grupo de pruebas que pertenece a este cuadrante. El uso de maquetas y prototipos para ayudar a validar propuestas de GUI (Graphic User Interface – Interfaz Gráfica de Usuario), los diseños con los clientes y para comunicar los diseños a los programadores antes de que empiecen a codificar.

Fig. 25: Historia de usuario junto al prototipo de pantalla.

c. Tercer Cuadrante:

Los expertos de negocio pueden pasar por alto la funcionalidad, o no entender

del todo bien, si no es su campo de experiencia. El equipo podría simplemente mal interpretar algunos ejemplos. Incluso cuando los programadores escriben código que hace que las pruebas de negocios pasen, no pueden entregar el producto que el cliente realmente quiere.

Las pruebas del cuadrante Q3, determinan que las pruebas de negocio satisfacen

las expectativas del cliente. Cuando se hacen las pruebas críticas del producto, se trata de emular la forma en que un usuario real, va a interactuar con la aplicación. Esta es la prueba manual, que sólo un ser humano puede hacer. Se pueden usar algunos scripts automatizados, para ayudar a configurar los datos que se necesiten, pero se tienen que utilizar los sentidos, el cerebro y la intuición para comprobar si el equipo de desarrollo ha dado el valor de negocio requerido por los clientes.

A menudo, los usuarios y clientes realizan las pruebas de aceptación de usuario

UAT (User Acceptance Tests – Pruebas de Aceptación de Usuario), ya que ofrecen a los clientes la oportunidad de dar nuevas características y ver los cambios que quieran en el futuro, convirtiéndose así en protagonista.

Los usuarios pueden ayudar a definir los posibles escenarios y flujos de trabajo

que pueden imitar el comportamiento del usuario final. Conocimientos del dominio, son fundamentales para crear escenarios precisos. Se quiere poner a prueba el sistema de extremo a extremo, pero no necesariamente como una caja negra.

Las pruebas de usabilidad, es un ejemplo de un tipo de prueba que tiene toda una

ciencia propia. Estas pruebas, pueden incluir la navegación de una página a otra, o incluso algo tan simple como el orden de tabulación. El conocimiento de cómo las personas utilizan los sistemas, es una ventaja en cuanto a las pruebas de usabilidad.

Las pruebas exploratorias, son fundamentales en este cuadrante. Durante estas

pruebas, el encargado de control de calidad al mismo tiempo diseña y realiza las pruebas, utilizando la creatividad, intuición y el pensamiento crítico para analizar los

34

resultados de los escenarios posibles. Esto ofrece una oportunidad mejor para aprender mucho más acerca de la aplicación. No se está hablando acerca de las pruebas ad hoc, que son improvisadas. Las pruebas exploratorias, tienen un enfoque más reflexivo y sofisticado que las pruebas ad hoc. Está guiada por una estrategia y opera dentro de límites definidos. Como resultado, es a través de este tipo de prueba que muchos de los errores más graves se encuentran generalmente.

Fig. 26: Caso de prueba verificado por el cliente (UAT).

d. Cuarto Cuadrante:

Los tipos de pruebas que caen en el cuadrante Q4, son tan fundamentales para el desarrollo ágil, como para cualquier tipo de desarrollo de software. Las pruebas están destinadas a las características del producto, tales como el rendimiento, robustez y seguridad.

Se basa en la premisa de utilizar herramientas, que sirvan para generar

escenarios en los cuales el sistema sea probado con grandes volúmenes de datos o tenga tiempos de respuesta que no pueden pasar de ciertos umbrales. Este tipo de pruebas son valiosas y son claves a la hora de garantizar que un producto puedo escalar de muy pocos usuarios y transacciones hacia volúmenes significativos.

Si se conocen los requisitos de rendimiento, seguridad, interacción con otros

sistemas y otros atributos no funcionales, antes de empezar a programar, es más fácil para el diseño y el código con eso en mente. No se debe dejar este tipo de actividades esenciales, tales como la performance para el final, cuando podría ser demasiado tarde para rectificar los problemas. Se cree que el equipo de desarrollo, tiene la responsabilidad de explicar las consecuencias de no abordar estos requisitos no funcionales.

Los requisitos no funcionales, son los problemas de configuración, seguridad,

rendimiento, gestión de memoria, así como también la fiabilidad, compatibilidad, interoperabilidad y escalabilidad. No todos los proyectos están preocupados por todos estos temas, pero es una buena idea tener una lista de comprobación para asegurarse de que el equipo piensa en ellos y le pide al cliente la importancia de cada uno.

35

Fig. 27: Gráfica de tiempo de respuesta y nº de hilos activos en un sistema.

Hasta aquí se han visto distintos tipos de pruebas, que contribuyen a la calidad

del software; pero la realidad indica, que no se pueden aplicar todos los tipos de prueba a todos los softwares, ya que cada sistema presenta distintas realidades y distintos objetivos. Existen casos en donde por ejemplo, las pruebas de usabilidad no se realizarán, ya que se trata de un servicio web; o se le dará menor importancia a la riqueza visual de la interfaz gráfica, ya que será una aplicación de uso interno; o también puede darse el caso en donde se dejarán sin efecto las pruebas de performance, carga y compatibilidad de navegadores, ya que se trata de una aplicación de escritorio con muy pocos usuarios.

Lo más importante para destacar, es que existen algunos tipos de pruebas que no

podemos obviar, ya que si se ignoran compromenten gravemente la calidad general de todo el sistema desarrollado. Entre estas pruebas se encuentran las pruebas unitarias y de componentes del cuadrante 1, que buscan mejorar la calidad interna del sistema, junto con las pruebas funcionales y pruebas exploratorias del cuadrante 2 y 3 que buscan mejorar la calidad externa. Con esto no se afirma, que el resto de pruebas no sean importantes. Lo que se quiere resaltar es, que si no se trabaja por la calidad interna primero, seguramente se acercarán a las pruebas del cuadrante 2 y 3, pero jamás podrán acercarse a las pruebas del cuadrante 4, ya que requieren de un mejor estado del sistema. 5.4) Estrategias de automatización pruebas:

Como se dijo anteriormente, primero se debe trabajar por la calidad interna del sistema; pero para hacer esto posible, se debe llevar a cabo una estrategia adecuada de automatización de pruebas, donde es fundamental que el sistema posea una arquitectura en capas.

Una arquitectura en capas, divide el código en partes horizontales, que contienen una funcionalidad similar, a menudo relacionados con una tecnología. Donde las capas superiores, se alimentan de las capas inferiores, como por ejemplo la arquitectura en tres capas que presenta las siguientes divisiones: la interfaz de usuario, la lógica de negocio y acceso a datos.

36

Las capas tienen ventajas para las pruebas, pero sólo si el mecanismo de conectar las partes proporciona flexibilidad. Si se posee un código estrechamente unido a través de mecanismos, tales como dependencias directas de clases concretas y los métodos estáticos, es difícil aislar una unidad de pruebas, a pesar de la estratificación. Esto hace que la mayoría de las pruebas automatizadas en las pruebas de integración, resulten ser complicadas; es por ello que se recomienda implementar las pruebas unitarias a través de TDD. Contraste con esto, con un código, donde las capas están separadas por interfaces. Las dependencias en las interfaces son fáciles de satisfacer con las pruebas.

Con la automatización de pruebas podemos satisfacer tres niveles de prueba:

pruebas unitarias y/o de componentes, pruebas de API (Application Programming Interface) y/o servicios web; y pruebas de GUI (Graphics User Interface) a. Pruebas unitarias y de componentes:

Estas pruebas, representan el nivel más bajo de pruebas que se pueden realizar,

es la base que soporta todo el resto de las demás pruebas. Esta capa, representa la mayor parte de las pruebas automatizadas. Son por lo general, códigos en el mismo lenguaje con el que se hizo el sistema bajo prueba. Después de que un equipo de programadores ha dominado el arte de TDD, estas pruebas son mucho más rápidas y menos costosas de escribir. Estas proporcionan la forma más rápida de retroalimentación, que las hace altamente valiosas. Ellas tienen el mayor retorno de la inversión de cualquier tipo de prueba. En el desarrollo ágil, se deben tratar de hacer tantas pruebas como sea posible en esta capa.

El equipo de programación, es el encargado y responsable de realizar este tipo

de pruebas, y para llevarlas a cabo se deben basar en los criterios de aceptación de las historias de usuario definidas por el equipo del cliente en conjunto con el equipo de control de calidad. Una historia de usuario, se considerará como terminada siempre y cuando estén creadas todas las pruebas unitarias y/o de componentes correspondientes a cada criterio de aceptación.

Componentes UI


Aplicación Fachada



Entidades de NegocioN

egoc

ioDa

tos



Agentes de Servicio



Tipos de Mensajes

Sistemas Externos

Serv

icio

s

Interfaces de Servicios

Pres

enta

ción

Users

Aplicación Fachada




egoc

io

Pruebas unitarias y/o de componentes

Fig. 28: Pruebas de bajo nivel aplicadas en la capa de negocio.

37

Con las pruebas unitarias, se aseguran que los programadores hayan implementado la funcionalidad adecuada, de acuerdo a la historia de usuario y además se cerciorarán de que las validaciones de interés para el cliente, se encuentren presentes en la base del código, se puede tener cierta seguridad, que si existiera algún error de regla de negocios en el sistema, fácilmente estas pruebas, lo encontrarían.

Las pruebas unitarias y/o de componentes, siempre deben ser consideradas a la

hora de estimar el tiempo de cada historia de usuario, ya que si se dejan en el olvido este tipo de pruebas, rápidamente se irán acumulando errores y defectos, que después serán difíciles de corregir. De lo contrario, cuando nuevos programadores, se sumen al equipo o cuando se herede el sistema a otro equipo de programadores, realizar grandes cambios será toda una hazaña para ellos, ya que al agregar o modificar funcionalidades, es muy probable que alteren las funcionalidades ya existentes y empiecen a funcionar incorrectamente lo que antes lo hacia correctamente.

Como conclusión podemos decir que estas pruebas: o Están en el más bajo nivel del sistema. o Son las que se deben de automatizar la mayor parte posible. o Están hechas en el mismo lenguaje de programación del sistema a prueba. o Son mucho más útiles, si las implementamos mediante TDD. o Brindan una retroalimentación rápida. o Tienen el mayor ROI de todas las pruebas automatizadas. o Son encargados y responsables de realizarlas, el equipo de programadores. o Son realizadas en base a los criterios de aceptación de las historias de

usuario, ya que nos asegura que están incluidas las verificaciones propuestas por el cliente.

o Son más fáciles de localizar los errores y/o defectos. o Brinda confianza al equipo de programadores, a la hora de realizar cambios

importantes que impacten al resto de las funcionalidades. b. Pruebas de API y/o Servicios Web: Las pruebas de API y de servios web, se encuentran en el nivel intermedio, representan las pruebas funcionales que trabajan directamente con el código de producción, sin una capa de interfaz gráfica de usuario o de otro tipo en el medio. Estas pruebas también deben ser automatizadas en su mayoría, ya que la capa intermedia representa una especie de portal al sistema, es la entrada principal al sistema y por lo tanto capturar un error en esta capa, sería clave para evitar un error o defecto crítico en la funcionalidad. Si bien este tipo de pruebas realizan algo muy similar a las pruebas de bajo nivel, son distintas, ya que aquí se prueba la integración de los componentes anteriormente probados a nivel de unidad. Cuando los programadores conectan cada componente, es muy común que aparezcan nuevos casos de prueba que no se hayan tenido en cuenta, a través de las pruebas unitarias y/o de componentes. Aquí el equipo de control de calidad, es el encargado y responsable de realizar este tipo de pruebas, ya que deben tomar el papel de un usuario o sistema que interactúa con el sistema a prueba. En esta etapa primero deben encargarse de verificar que todo funcione de acuerdo a lo especificado a los criterios de aceptación. Una vez que todas esas pruebas estén automatizadas, se pueden sugerir nuevos casos de pruebas, que surgen de las pruebas exploratorias.

38

Componentes UI


Aplicación Fachada




egoc

ioDa

tos



Agentes de Servicio



Tipos de Mensajes

Sistemas Externos

Serv

icio

s


Pres

enta

ción

Users

Aplicación Fachada




egoc

io

Tipos de Mensajes

Serv

icio

s


Pruebas de API y/o Servicios Web

Fig. 29: Pruebas de nivel intermedio aplicadas en la capa de negocio y/o servicios.

Como se dijo anteriormente, esta capa representa el portal del sistema y es por ello que además de pruebas automatizadas, también se le pueden realizar pruebas de performance, carga y seguridad. Aunque no son tan baratas para automatizar como las pruebas de bajo nivel, proporcionan información un poco más despacio, pero con las herramientas adecuadas se puede obtener un buen ROI. Existen diversas herramientas para este tipo de pruebas, que pueden estar desde herramientas de bajo nivel realizadas en el mismo lenguaje de programación que el sistema a prueba, hasta softwares de prueba especializados.

Como conclusión podemos decir que estas pruebas: o Están en el nivel intermedio del sistema. o Trabajan directamente con el código de producción. o Son las que se deben de automatizar la mayor parte posible. o Son las que se pueden realizar con herramientas de bajo nivel, realizadas en

el mismo lenguaje de programación del sistema a prueba o softwares especializados.

o Brindan una retroalimentación más lentamente que las pruebas unitarias y/o componentes.

o Recuperan el ROI más lentamente que las pruebas de bajo nivel. o Son encargados y responsables de realizarlas, el equipo de control de

calidad. o Son realizadas primero en base a los criterios de aceptación. Luego se le

pueden añadir nuevos casos de pruebas. o Generan nuevos casos de pruebas que descubren errores y defectos que no

fueron planteados con anterioridad.

39

c. Pruebas de Interfaz Gráfica de Usuario: Las pruebas de interfaz gráfica de usuario se encuentran en el nivel superior, estas simulan la interacción con el sistema, como si fuese un usuario que ejecuta acciones sobre los componentes gráficos para llevar a cabo una determinada funcionalidad. Estas pruebas deben ser automatizadas en menor parte, ya que la interfaz gráfica, es lo que más comúnmente suele estar sujeta a continuos cambios, debido a que esta parte, es la cara del sistema y siempre hay nuevas sugerencias tanto de parte del cliente como de los usuarios.

Componentes UI


Aplicación Fachada






Agentes de Servicio



Tipos de Mensajes

Sistemas Externos


Users

Componentes UI


Pruebas de Interfaz Gráfica de Usuario

Fig. 30: Pruebas de nivel superior aplicadas en la capa de presentación.

En arquitecturas cliente – servidor, como las aplicaciones web, el equipo de

programadores suele hacer validaciones de negocio del lado del cliente, como es el caso del ingreso de datos en un formulario. De esta forma, se evitan las peticiones al servidor con datos erróneos. Es por ello, que una vez que realizan todas las validaciones en el cliente, a través de la interfaz gráfica, recién la petición, es solicitada al servidor para que siga con el proceso. Estoy es muy bueno a nivel de performance; pero no se deben olvidar que las validaciones también deberían de estar de lado del servidor.

Se afirma esto, porque generalmente los programadores olvidan hacer las

validaciones en el servidor, pensando en que no habrá un usuario malintencionado, que intente vulnerar la seguridad de la aplicación, pasando por alto la interfaz gráfica. Esto es muy fácil de hacer, y no es necesario que ese usuario, sea un experto en seguridad de sistemas. Además, es importante tener en cuenta esto, porque como la interfaz gráfica, es constantemente alterada, al ser modificada se perderán las validaciones de negocio, y por lo tanto se dejarán de cumplir con los criterios de aceptación de las historias de usuario, que ya estaban consideradas como terminadas. Si se tiene en cuenta esto, se van a encontrar con validaciones de negocio, que están presentes tanto del lado del servidor como del cliente; del lado del cliente, por cuestiones de performance y del lado del servidor, por cuestiones de seguridad. Si bien, se consume más tiempo durante el desarrollo de estas validaciones, quizás las cuestiones de performance no sean

40

importantes para ciertos proyectos; pero las validaciones de lado del servidor, el negocio, no se deben pasar por alto, ya que es el corazón del sistema.

Los encargados y responsables de realizar este tipo de pruebas, también son los

miembros del equipo de control de calidad, con el objetivo de cumplir con los criterios de aceptación. Automatizando solo lo que es estable, ya que estas pruebas por lo general tienen el menor ROI, porque son caros de mantener; pero son necesarios. Solo debemos automatizar lo que es simple, y que nos ayude con las pruebas de regresión, el resto es mejor que lo pruebe la inteligencia humana.

Aquí también se utilizan diversas herramientas, que pueden estar desde

herramientas de bajo nivel realizadas en el mismo lenguaje de programación que el sistema a prueba, hasta softwares de prueba especializados.

Como conclusión podemos decir que estas pruebas: o Están en el nivel superior del sistema. o Son los que se deben de automatizar la menor parte posible. o Simulan la interacción con los componentes gráficos del sistema como si

fuese un usuario. o Son encargados y responsables de realizarlas, el equipo de control de

calidad. o Son los que se deben aplicar a los módulos simples y estables del sistema. o Recuperan el ROI muy lentamente. o Son los que se pueden realizar con herramientas de bajo nivel realizadas en

el mismo lenguaje de programación del sistema a prueba o softwares especializados.

5.5) Metodologías ágiles centradas en la automatización de pruebas:

Hasta aquí se ha visto, con qué tipo de sistema vamos trabajar, se sabe qué tipos

de prueba aplicaremos, y también se conoce, qué criterios tener en cuenta cuando se empiece a implementar la estrategia de automatización de pruebas. Como se verá, la implementación correcta de las pruebas automatizadas, nos trae consigo muchas ventajas que queríamos recalcar para que no haya alguna duda:

o Reduce los tiempos de prueba. o Disminuye errores y defectos, ya que son encontrados a tiempo. o Evita que las pruebas manuales repetitivas sean propensas a errores. o Permite mayor enfoque en pruebas de más complejidad. o Genera mayor confianza a la hora de realizar refactorizaciones de código. o Reduce la deuda técnica. o Brinda retroalimentación inmediata y continua. o Obliga al equipo a trabajar en conjunto por la calidad del software. o Documenta las funcionalidades del sistema. o Brinda un buen ROI. Se le debe recordar al cliente, que todos los tipos de pruebas de los cuadrantes,

son importantes para lograr una calidad del sistema aceptable; pero haciéndole énfasis, que sin calidad interna, es casi imposible que haya calidad externa.

41

Fig. 31: Metodologías ágiles centradas en la automatización de pruebas.

Como se mencionó anteriormente, las pruebas automatizadas se dividen en pruebas de capa inferior, que representa la calidad interna, y pruebas de capa intermedia y superior, que representa parte de la calidad externa. Tener estas pruebas implementadas permitirá al equipo de desarrollo, trabajar por la calidad externa del producto. De lo contrario, de qué serviría trabajar con pruebas exploratorias, pruebas de usabilidad, pruebas de aceptación de usuario, sin nombrar aún, las pruebas de performance, carga, seguridad y otros tipos de pruebas de mayor complejidad; si aún el sistema presenta errores y defectos básicos, que ni siquiera cumplen con los criterios de aceptación.

Un sistema con alta calidad interna puede, aun así, tener una baja calidad externa; pero un sistema con baja calidad interna, difícilmente tendrá buena calidad externa. Es difícil construir algo sobre cimientos débiles. En algunos casos puede tener sentido, desde el punto de vista del negocio, liberar una versión del producto que tenga muy baja calidad externa, y más tarde liberar una versión mejorada. Esa es decisión del dueño del producto, ya que él, es el responsable de definir el alcance. Sin embargo, la calidad interna, es algo que no debería ser discutido. Es responsabilidad del equipo de desarrollo, mantener la calidad del sistema, bajo toda circunstancia y simplemente no debería ser negociable.

Son comunes los casos, donde el dueño del producto intenta reducir las

estimaciones de tiempo y/o esfuerzo realizadas por el equipo de desarrollo, intentando usar como una variable de cambio, la calidad interna del producto. Sacrificar la calidad interna del producto, es algo muy crítico por todo lo mencionado anteriormente. Si se permite, que el código comience a deteriorarse, será muy difícil volver hacia atrás. En lugar de reducir la calidad interna, se debería convencer al cliente de reducir el alcance de las historias de usuario; de lo contrario se pagará un alto precio.

Con lo expuesto, el cliente junto con todo su equipo, y el equipo de desarrollo, sabrán que esperar de las pruebas automatizadas, y que no. Además tendrán en cuenta, a la hora de realizar la estimación de tiempo y/o esfuerzo de cada historia de usuario, el tiempo que lleva la automatización de pruebas, que es algo que no se debe tomar muy a la ligera. Es por todo esto, que se puede afirmar que toda metodología ágil de desarrollo de software, debería tener su foco de atención en la automatización de pruebas, en la calidad interna del producto.

42

5.6) Impedimentos para llevar a cabo la automatización de pruebas: Una de las ventajas de impulsar el desarrollo de las pruebas, es que el código

está escrito con la intención expresa de hacer pasar las pruebas. El equipo tiene que pensar, desde el principio, acerca de cómo se va a ejecutar y automatizar las pruebas para cada historia de usuario que codifica.

Escribir “código comprobable”, es un concepto simple, pero no es una tarea

fácil, especialmente si se está trabajando con el código de un sistema heredado, que no tiene pruebas automatizadas, y no está diseñado para la capacidad de prueba. Los sistemas heredados a menudo, tienen la base de datos, la lógica de negocio, y la interfaz de usuario fuertemente relacionados. No hay una independencia suficiente como para automatizar una prueba de bajo nivel o nivel intermedio.

Los sistemas heredados, que no están cubiertos por pruebas unitarias automatizadas, presentan un enorme desafío. Es difícil escribir pruebas unitarias de código, que no está diseñado para la capacidad de prueba, y es difícil cambiar el código, que no está garantizado con las pruebas unitarias. No es imposible, pero habría que migrar el sistema con una nueva arquitectura, lo que resultaría muy costoso tanto en tiempo, dinero como en esfuerzo. Quizás esto, represente el mayor impedimento para la implementación de pruebas automatizadas de bajo nivel; pero entre otras alternativas se podría automatizar pruebas de los otros dos niveles restantes para aplacar esta debilidad, todo depende del estado actual del sistema. El mejor de los casos, es cuando se trata de un sistema completamente nuevo, o cuando se trata de un sistema heredado, que posea una buena arquitectura, o en donde ya se estaban aplicando pruebas automatizadas con anterioridad.

Si se está tratando con un proyecto, con un ciclo de desarrollo de corto plazo, en

donde el sistema tendrá una o dos versiones, como se puede dar en el caso de las aplicaciones móviles, la automatización de pruebas, se puede llegar a transformar en un impedimento para el desarrollo de software, ya que al ser corto el tiempo, no será necesario ejecutar pruebas de regresión. De lo contario se perderá tiempo implementando la automatización de pruebas; pruebas que fácilmente se podrían realizar manualmente.

Otras de las cosas por la que puede a llegar a peligrar, la decisión de

implementar la automatización de pruebas, es la capacidad técnica del equipo de programadores como el equipo de control de calidad. Si uno o ambos equipos, no están capacitados para desarrollar pruebas automatizadas, por no poseer conocimientos del lenguaje de programación u otras herramientas existentes, será casi imposible llevar a cabo este tipo de prácticas. Nada que no se solucione con capacitaciones relacionadas al tema.

Anteriormente se había planteado, que se suelen dar los casos en donde el cliente

intenta negociar tratando de reducir la calidad interna del software a cambio de una mayor velocidad del equipo. Lamentablemente, a veces este tipo de ideas, no solo provienen del cliente, sino también es común que provenga de la gerencia de la empresa que desarrolla al software. Si los fundamentos que estamos exponiendo, defendiendo la automatización de pruebas, no son claros tanto como para el cliente, como para la gerencia, difícilmente podremos llevar a cabo una automatización de pruebas exitosa.

43

Fig. 32: Impedimentos para llevar a cabo la automatización de pruebas.

5.7) Automatización de pruebas aplicadas en las metodologías ágiles:

¿En qué momento de la iteración debemos automatizar? Es la pregunta que comúnmente surge. Y que de no tomar una decisión adecuada, puede llevarnos al fracaso del proyecto. Se pueden dar los siguientes casos: a. Caso A - Desarrollo de software sin automatización de pruebas:

El equipo de desarrollo de software, se siente convencido de que las pruebas

funcionales manuales y las pruebas de aceptación de usuario, son suficientes para tener una calidad aceptable del software.

Fig. 33: Desarrollo de software sin automatización de pruebas.

Con este tipo de mentalidad el equipo de control de calidad, al principio de la iteración, se encarga de ayudar a definir los criterios de aceptación de las historias de usuario, junto al cliente a través de ejemplos y prototipos. Luego, durante el transcurso de la iteración el equipo de programadores, trabaja con la implementación de las historias de usuario. Al final de la iteración, cuando se termina con la implementación, el equipo de programadores, libera la primera versión (versión 1.0), para que sea verificada por el equipo de control de calidad y usuarios finales a través de pruebas funcionales manuales y pruebas de aceptación de usuarios. La demo se realiza “exitosamente”, ya que el equipo mostró el camino feliz de las funcionalidades requeridas. El equipo de control de calidad, logró verificar los criterios de aceptación; pero no tuvieron tiempo para realizar pruebas mucho más profundas.

44

Ya dimos por terminada la primera iteración, ahora el equipo de desarrollo, encarará las historias de usuarios de la segunda iteración. Todo se comporta tal como la primera iteración, excepto que aparece un nuevo inconveniente. Los usuarios finales y el equipo de control de calidad encuentran defectos y errores críticos que no habían percatado con anterioridad, por lo que informan al equipo de programadores para que sean solucionados inmediatamente. Los programadores, trabajan por eliminar los errores y defectos detectados, consumiendo tiempo de la segunda iteración. Al poco tiempo liberan una segunda versión (versión 1.1) con las funcionalidades corregidas para que sean verificadas nuevamente. El equipo de programadores, ya se ocupó de solucionar los errores y defectos de la primera iteración, ahora pueden ocuparse de seguir con el desarrollo de las funcionalidades de la iteración actual; pero hay otro inconveniente. Ahora el tiempo con el que contaban se ha reducido drásticamente, así que tendrán que optar por buscar soluciones temporales que les permitan salir de la presión de entrega. Los programadores logran liberar una versión con los requisitos desarrollados de la segunda iteración (versión 2.0); pero ahora la presión fue transmitida al equipo de control de calidad, debido a que el tiempo que utilizaban para realizar las pruebas, también ha sido afectado por los errores y defectos de la iteración anterior. Finalmente la calidad del software de la última versión, es muy baja, ya que no logra ni siquiera cumplir con los criterios de aceptación planteados, no había tiempo. Todo esto sumado a que todavía no se sabe, si los defectos y errores “solucionados” en la segunda versión han sido correctamente corregidos.

Con esto podemos ver claramente, que sin la implementación de automatización de pruebas, es muy fácil que se produzca la acumulación de errores y defectos, como también la acumulación de la deuda técnica. ¿Qué situación positiva podemos llegar a esperar, si es que se presenta esta misma situación; pero con acumulaciones de nueve o diez iteraciones de desarrollo? b. Caso B - Desarrollo de software sin criterios de automatización de pruebas:

Existen equipos de desarrollo, que subestiman la implementación de automatización de pruebas, es por ello que lo ponen en práctica, sin tener en cuenta los criterios como para llevarlo a cabo exitosamente.

Similar al caso anterior, todo comienza cuando el equipo de control de calidad al principio de la iteración, se encarga de ayudar a definir los criterios de aceptación de las historias de usuario, junto al cliente a través de ejemplos y prototipos. Luego, durante el transcurso de la iteración el equipo de programadores, no solo trabaja con la implementación de las historias de usuario, sino también con la implementación de pruebas automatizadas de bajo nivel, de acuerdo a su propio criterio y no a los criterios de aceptación planteados. Posteriormente el equipo de programadores, pasa a liberar la primera versión (versión 1.0) y el equipo de control de calidad, se encarga de automatizar las pruebas funcionales de nivel superior, pensando que este tipo de pruebas reemplaza todo tipo de pruebas manuales. Con el transcurrir de la iteración, se dan cuenta que no es muy fácil automatizar en esta capa, y terminan automatizando una parte y ejecutando pruebas manuales por otra, juntos a los usuarios finales. La demo se realiza “exitosamente”, ya que el equipo mostró el camino feliz de las funcionalidades requeridas. El equipo de control de calidad, logró verificar los criterios de aceptación; pero nuevamente no tuvieron tiempo para realizar pruebas mucho más profundas.

45

Versión 1.0

Versión 1.1

Versión 2.0

- Pruebas funcionales de nivel superior automatizadas- Pruebas funcionales manuales- Pruebas UAT

- Ejemplos- Prototipos

Equipo de control de calidad Usuarios finales

Errores y defectos

encuentran

afectan

generan

generan generan

probado por

Equipo de programadores

realizada por

- Pruebas automatizadas de capa inferior- Ejemplos- Prototipos

- Pruebas automatizadas de capa inferior- Pruebas funcionales de nivel superior automatizadas- Pruebas funcionales manuales- Pruebas UAT

Desarrollo de historias de usuario Desarrollo de historias de usuario

ITERACIÓN Nº1 ITERACIÓN Nº2

Fig. 34: Desarrollo de software sin criterios de automatización de pruebas.

Las funcionalidades de la primera iteración se terminaron, ahora el equipo de desarrollo, encarará las historias de usuarios de la segunda iteración. Pero aquí aparece el mismo inconveniente que el caso anterior. Los usuarios finales y el equipo de control de calidad encuentran defectos y errores críticos, que no habían percatado con anterioridad; pero aquí debido a que las pruebas automatizadas de bajo nivel no estaban implementadas, de manera que cumplan los criterios de aceptación. Se informa al equipo de programadores, para que esto sea solucionado inmediatamente. Los programadores, trabajan por eliminar los errores y defectos detectados, consumiendo tiempo de la segunda iteración y como poseen pruebas automatizadas de bajo nivel, las ejecutan; pero estas al no cubrir los criterios de aceptación, no son de mucha utilidad. Son conscientes de esto; pero no hay tiempo para crear más pruebas automatizadas, ya que están consumiendo tiempo valioso de la segunda iteración. Al poco tiempo liberan una segunda versión (versión 1.1) con las funcionalidades corregidas para que sean verificadas nuevamente.

El equipo de programadores, ahora tiene que enfocarse en el desarrollo de las

funcionalidades de la iteración actual; pero ahora el tiempo con el que contaban se redujo, y por lo tanto al igual que en el caso anterior, tendrán que buscar soluciones temporales, que les permitan salir de la presión de entrega. Así estos, logran liberar una nueva versión (versión 2.0), y ahora el equipo de control de calidad, es el que tiene que entrar en acción. Aquí este equipo se da cuenta, de que las pruebas automatizadas realizadas no son de mucha utilidad, y no sólo porque quizás no se cumplan con los criterios de aceptación, sino también, porque la interfaz gráfica de usuario en su nueva versión, ha sufrido cambios, y por lo tanto las pruebas no son estables, por lo que deben ser refactorizadas; pero ellos tampoco tienen tiempo para eso, así que prefieren llevar a cabo las pruebas manualmente.

Todos estos hechos desalientan totalmente al equipo de desarrollo, y generan en ellos la idea, de que las pruebas automatizadas, solo les harán perder más tiempo, que necesitan para llevar a cabo la ejecución de las pruebas manuales.

46

c. Caso C - Desarrollo de software con criterios de automatización de pruebas:

Para llevar a cabo la implementación de pruebas automatizadas de forma adecuada, se debe saber en qué momento de la iteración, se va a llevar a cabo cada tipo de pruebas.

Versión 1.0

Versión 1.1

Versión 2.0

- Ejecución de pruebas funcionales de nivel intermedio automatizadas- Pruebas funcionales manuales- Pruebas exploratorias- Pruebas UAT


Equipo de control de calidad Usuarios finales

Errores y defectos

encuentran

afectan

generan

generan generan

probado por

Equipo de programadores

realizada por


- Pruebas automatizadas de capa inferior- Creación de pruebas funcionales de nivel intermedio automatizadas

- Pruebas funcionales manuales- Ejecución de pruebas funcionales de nivel intermedio - Pruebas de nivel superior automatizadas- Pruebas de performance y carga- Pruebas de seguridad- Pruebas de usabilidad

- Pruebas automatizadas de capa inferior- Creación de pruebas funcionales de nivel intermedio automatizadas

Desarrollo de historias de usuario Desarrollo de historias de usuario

ITERACIÓN Nº1 ITERACIÓN Nº2

Fig. 35: Desarrollo de software con criterios de automatización de pruebas. En este caso, el equipo de control de calidad, al principio de la iteración, se encarga de ayudar a definir los criterios de aceptación de las historias de usuario, junto al cliente a través de ejemplos y prototipos. En la etapa de desarrollo de historias de usuario, el equipo de programadores, implementa las funcionalidades solicitadas de acuerdo a los criterios de aceptación, y se aseguran de que esto sea así, implementando las pruebas automatizadas de bajo nivel. A diferencia de los casos anteriores el equipo de control de calidad, se encarga de realizar las pruebas automatizadas de nivel intermedio; pero ¿cómo implementarán estas pruebas, sin aún no tienen la API o el servicio web programado? Esto es posible, porque se pueden crear estas pruebas de manera tal, que esperen los resultados adecuados, sin importar que fallen, ya que las funcionalidades, aún no han sido implementadas. Una vez que el equipo de programadores liberó la primera versión (versión 1.0), las pruebas automatizadas de nivel inferior e intermedio son ejecutadas, verificando inmediatamente si los criterios de aceptación, se han cumplido correctamente. Aquí se suman las pruebas funcionales manuales, probando todo lo relacionado con la interfaz gráfica, junto a las pruebas exploratorias y pruebas de aceptación de usuario. La demostración ha sido exitosa, se ha logrado cumplir con los criterios de aceptación y el cliente está satisfecho. Se dio por finalizada la primera iteración; pero no podemos negar que siempre se encontrarán errores y defectos por los cuales trabajar, la diferencia será que está vez el esfuerzo será mucho menor, debido a que los errores y defectos son mínimos. Es por ello que en cada iteración, además de estimar pensando en el tiempo que se le asignará a las pruebas, también se debe pensar en el tiempo que se le asignará a la corrección de errores y defectos.

47

La nueva iteración, será muy similar a la anterior, excepto que contará con un breve lapso de tiempo, en el cual los programadores, se dedicarán a la corrección de errores y defectos. Esto no significa, que tendremos a todo un equipo de programadores enfocados en esta tarea, sino que también podemos optar por designar uno o dos programadores dedicados a esta tarea por cada iteración, de manera que el resto pueda continuar con el desarrollo de nuevas funcionalidades. De esta forma se libera la segunda versión (versión 1.1) con los errores y defectos corregidos, simultáneamente desarrollando las funcionalidades de la segunda iteración, junto con sus respectivas pruebas automatizadas de bajo nivel e intermedio, sin problemas de tiempo. Finalmente se libera la nueva versión (versión 2.0), en donde el equipo de control de calidad además de realizar las pruebas exploratorias y de UAT, podrá ejecutar las pruebas automatizadas, que no solo servirán para verificar si los criterios de aceptación se están cumpliendo, sino también servirán, para saber si las funcionalidades que fueron desarrolladas en iteraciones anteriores, no se vieron afectadas por algún cambio realizado en la iteración actual, esto es lo que se conoce como pruebas de regresión. Con el transcurrir de las iteraciones las funcionalidades, se irán haciendo cada vez más estables, por lo que podremos ir agregando algunas implementaciones de pruebas automatizadas de nivel superior. Además, según sea la necesidad del sistema podremos ir agregando otros tipos de pruebas, como las pruebas de usabilidad, seguridad, performance y carga; pero para ello quizás debamos agregarle tiempo a la etapa de pruebas, o agregar recursos que realizan este tipo de tareas, según sea el caso.

Con lo expuesto anteriormente, se quiere dejar en claro, que los criterios de aceptación de las historias de usuario, son claves, y a la hora de automatizar pruebas, no debemos olvidarlos, de lo contrario no será posible satisfacer las necesidades del cliente. Esto es lo que se conoce como el proceso ATDD (Acceptance Test Driven Development – Desarrollo guiado por Pruebas de Aceptación), esta práctica que es muy similar a TDD consiste en:

o Seleccionar una historia de usuario. o Crear los criterios de aceptación junto con el cliente. o Crear un conjunto de casos de prueba de aceptación que satisfagan los

criterios de aceptación. o Automatizar los casos de prueba de aceptación, sin importar que fallen. o Implementar historia de usuario. o Ejecutar casos de prueba de aceptación hasta que los resultados sean

satisfactorios y refactorizar la funcionalidad y/o las pruebas de ser necesario. o De arrojar las pruebas un resultado satisfactorio, el cliente dará la

conformidad de que la historia de usuario fue correctamente implementada.

Fig. 36: Diagrama de flujo de ATDD.

Con esto podemos ver que TDD se ocupa de la calidad interna, mientras que ATDD se ocupa de la calidad externa del software.

48

5.8) Selección de casos de prueba a automatizar:

En la sección anterior, se dio a conocer los motivos necesarios, del por qué las pruebas automatizadas, deben tener el objetivo de cumplir con los criterios de aceptación de las historias de usuario. Esto es muy útil; pero también hay que tener en cuenta otros criterios para determinar el orden, en que vamos a automatizar las pruebas: a. ¿Las pruebas son sencillas de automatizar?

Cuando se empiece a seleccionar los casos de prueba a automatizar, se debe

primero verificar, si la prueba no es tan costosa de implementar. Si implica construir muchos componentes de automatización, solo para un caso de prueba en particular, no convendría automatizarlo; otra opción sería darle la mínima prioridad, para que cuando haya tiempo, se realice su implementación. Ahora si, esos componentes de automatización, van a ser reutilizados por una buena cantidad de casos de prueba, invertir tiempo ahí sería muy beneficioso.

b. ¿Las pruebas requieren de intervención manual?

Algunas pruebas necesitan de ojos, de oídos y de la inteligencia humana. La

usabilidad y las pruebas exploratorias son dos tipos de prueba, que están dentro de esta categoría y no requieren que sean automatizadas.

c. ¿Las pruebas se han ejecutado y verificado manualmente?

Para que un caso de prueba, sea automatizado a nivel superior, se debe primero

verificar, que cumpla con su objetivo, ya sea que se trate de un caso de prueba positivo o un caso de prueba negativo. Un caso de prueba que no pueda ejecutarse manualmente, implicaría una pérdida de tiempo al momento de automatizarlo.

d. ¿Estamos seguros del cumplimiento de las precondiciones?

Si para ejecutar un caso de prueba, se requiere de precondiciones, al automatizar

el caso de prueba, se debe crear componentes de manera tal, que simulen el estado de los datos, como si las precondiciones se hubiesen ejecutado, o si de ser el caso, ejecutar con anterioridad los casos de prueba, que cumplen con las precondiciones del caso de prueba actual.

e. ¿Puedo confiar en las pruebas automatizadas para probar la funcionalidad

ahora y en un futuro?

Si no se cuenta con un set de datos y/o componentes reutilizables, cada vez que se ejecute la prueba automatizada, difícilmente se tendrán las garantías suficientes, de que se estén ejecutando correctamente. Se debe asegurar, de que las pruebas implementadas servirán ahora y en el futuro, se debe pensar en su mantenimiento. Esto puede implicar mayor tiempo, a la hora de la implementación de las pruebas; pero es mejor consumir ese tiempo, pensando en su mantenimiento desde un principio, que consumir el tiempo durante varias iteraciones, ya que de lo contrario se terminaría haciendo múltiples refactorizaciones, con el riesgo de olvidar cual es el verdadero objetivo de la prueba.

49

5.9) Selección de herramientas de automatización: Se puede contar con una amplia gama y creciente de herramientas para elegir: herramientas de creación propia, herramientas de código abierto, herramientas comerciales o una combinación de cualquiera, son todas las alternativas viables. Con tantas opciones, se debe saber, dónde buscar y encontrar el tiempo suficiente, para probar las herramientas y así determinar si se ajustan a las necesidades. a. Herramientas de creación propia: Estas herramientas tienen muchas ventajas, ya que son amigables para el programador. Si el equipo, está escribiendo su propio framework de automatización, podrá ser adaptado a las necesidades de nuestro sistema.

Que sea de creación propia, no significa gratis. El equipo de desarrollo, se ve involucrado a desarrollar este framework, lo que implica consumir el tiempo de desarrollo, situación que no muchos clientes están de acuerdo en negociar, ya que construir un potente componente de automatización de pruebas, no es lo mismo que automatizar pruebas.

b. Herramientas comerciales:

Estas herramientas son percibidas, como una apuesta segura. Es probable que vengan con manuales, soporte e información para los miembros del equipo de control de calidad u otros usuarios que carezcan de conocimientos técnicos avanzados.

Las herramientas comerciales son históricamente hostiles para el equipo de desarrollo. Tienden a utilizar lenguajes propietarios, que no tiene sentido que se malgaste el tiempo en aprenderlas a utilizar. También tienden a ser pesados y las pruebas, pueden ser frágiles, se rompen fácilmente por los cambios de menor importancia a la aplicación, y son caros de mantener. c. Herramientas de código abierto:

Existen equipos de desarrollo de software externos, que escribieron sus propias herramientas, debido a que herramientas de terceros, no satisfacían sus necesidades y que generosamente han puesto a disposición de la comunidad del código abierto.

Por lo general, estas herramientas son ligeras y adecuadas para el desarrollo ágil.

La ventaja, es que han sido previamente probadas y aplicadas en distintos proyectos, y por lo tanto mejoradas. Son de fácil personalización y son confiables. Estas herramientas cuentan con características útiles para todo el equipo de desarrollo.

Para encontrar la herramienta óptima, se debe intentar con una herramienta a la vez, dándole tiempo suficiente para un juicio justo. Lo importante, es resaltar que una herramienta, es ágil cuando contribuye con los principios ágiles. Por lo tanto se recomienda, el uso de herramientas de código abierto, ya que además de no generar costos, si se necesita de alguna nueva funcionalidad útil para las pruebas, se podrá desarrollar ese pequeño tramo, y continuar con la automatización del resto de las pruebas. El equipo de desarrollo, debe estar concentrado en el desarrollo de las funcionalidades y en las pruebas de las mismas, y no en la construcción de un framework de automatización o hallarse limitados por las herramientas.

50

5.10) Integración Continua:

Hasta aquí se cuenta, con pruebas automatizadas, que se ejecutan con las herramientas en el entorno de desarrollo, de cada miembro del equipo de desarrollo; pero no se cuenta, con un lugar centralizado que permita saber, si el trabajo de un integrante del equipo, integrado al trabajo de los demás miembros, se acopla correctamente.

La integración continua, es una práctica de desarrollo de software, donde los miembros del equipo integran su trabajo con frecuencia. Cada integración, es verificada por un sistema automatizado de construcción (incluyendo las pruebas), para detectar errores de integración. Este enfoque ayuda a reducir los problemas de integración y nos permite desarrollar nuestro producto de forma más rápida.

Algunos ven la integración continua, como un proceso que simplemente agrupa

los componentes de software. La integración continua, es la pieza central del desarrollo de software, ya que garantiza la calidad del software, a través de la ejecución de una construcción (build) con cada cambio que realicemos. Si no se le da importancia a elementos, tales como el entorno de desarrollo, la construcción y el despliegue del software, se verán obligados a realizar tareas de bajo nivel más adelante, y en los momentos más inoportunos, como por ejemplo el día anterior al plazo de entrega.

Las ventajas de implementar la integración continua son:

a. Reducir los riesgos:

Los errores y defectos se detectan más pronto, porque se integran y ejecutan las pruebas varias veces al día, ya que hay una mayor probabilidad de que se detecten cuando son introducidos, en lugar que se detecten durante las pruebas al final de la iteración.

La calidad del software es medible, mediante la incorporación de las pruebas y

la inspección continua en el proceso de integración automática. Los atributos tales como la complejidad, líneas duplicadas, cobertura de pruebas y otros pueden ser rastreados.

Reduce las hipótesis en cuanto a las pruebas, construcción y despliegue y del

software en un entorno limpio usando un mismo proceso.

b. Reducir los procesos manuales repetitivos: La reducción de los procesos repetitivos ahorra tiempo, costos y esfuerzo. Estos

procesos repetitivos pueden ocurrir en todas las actividades del proyecto, incluyendo la compilación de código, integración de bases de datos, pruebas, inspección, instalación, y la retroalimentación. Cada vez que se ejecute el proceso, asegura que lo haga de la misma manera. Lo que facilita la reducción de mano de obra en los procesos repetitivos, liberando a la gente para realizar otro tipo de actividades.

c. Generar versiones del software en cualquier en cualquier momento y en

cualquier lugar:

La integración continua, permite liberar versiones del software en cualquier momento y lugar. Si hay algún problema con la versión liberada, los miembros del proyecto estarán informados y las correcciones se aplican al software de forma

51

inmediata. Los proyectos que no siguen esta práctica, esperan hasta inmediatamente antes de la entrega para integrar todo y probar el software. Esto puede ser el resultado de una demostración al cliente desastrosa, que puede significar la finalización del proyecto, ya que los errores y defectos que se presenten, no solo se deben a las funcionalidades recientemente implementadas, sino a la configuración del servidor o dispositivo en el que se encuentre funcionando.

Además de contar con la posibilidad de realizar un despliegue automático, da la

posibilidad de generar diversos ambientes como para realizar otros tipos de pruebas, como es el caso de las pruebas de performance y carga, en donde se requiere de un ambiente aislado. d. Permitir una mejor visibilidad del estado del proyecto:

La integración continua, proporciona la habilidad de percibir las tendencias y tomar decisiones eficaces, y ayuda a proporcionar el valor de innovar en nuevas mejoras. Las decisiones de un sistema eficaz de integración continua, pueden proporcionar justo a tiempo, la información sobre la reciente situación de construcción y las métricas de calidad. Podemos percibir las tendencias del proyecto, ya sea del éxito o el fracaso a través de la construcción, calidad general, y otra información pertinente al proyecto. e. Establecer una mayor confianza en el producto por parte del equipo de

desarrollo: Con cada integración, el equipo sabe que las pruebas se ejecutan para verificar el

comportamiento, que la codificación de los proyectos y normas de diseño se cumplen, y que el resultado, es un producto funcional comprobable. Sin integraciones frecuentes, el equipo no puede conocer el impacto de cambio que proviene de sus códigos.

Fig. 37: Integración Continua.

52

5.11) Métricas:

Con la automatización de pruebas, se puede controlar la calidad interna y parte de la calidad externa del software; pero que sentido tiene controlar, sino se puede medir. El éxito del proyecto, se mide sobre la base de la meta que se proponen llevar a cabo, en relación con las expectativas de los accionistas y clientes. Las métricas de pruebas automatizadas, pueden ayudar en la realización de evaluaciones, en cuanto al progreso de los objetivos, la productividad y la calidad.

De esta forma se pueden contestar preguntas tales como: ¿se justifica todo el

esfuerzo que se emplea para que la automatización de pruebas se lleve a cabo?, ¿cuántos casos de prueba se han automatizado?, ¿cuántos casos de prueba necesitan ser automatizados?, etc. Entre las métricas más importantes se encuentran: a. ROI del Esfuerzo:

Esta métrica, ayuda a determinar si el esfuerzo ahorrado como resultado de la

automatización de la prueba, es el suficiente como para justificar el esfuerzo empleado en la implementación de la misma. En donde si:

o El ROI de Esfuerzo es < 1 indica: el esfuerzo ahorrado como resultado de la

automatización de pruebas, no es lo suficientemente alto como para justificar el esfuerzo empleado en la implementación de la automatización.

o El ROI de Esfuerzo es = 1 indica: No hay ningún esfuerzo humano ahorrado como resultado de la automatización de pruebas.

o El ROI de Esfuerzo es > 1 indica que: Vale la pena la automatización de las pruebas.

Tabla 1: Ejemplo ROI de Esfuerzo.

Se observa en la tabla 1, que durante las primeras iteraciones el ROI de esfuerzo es inferior a 1, que es el periodo donde se empieza con la capacitación, diseño creación e instalación de la automatización de pruebas, y que por lo tanto, consume más tiempo llevarlo a cabo.

Con el transcurso de las iteraciones, el ROI de esfuerzo va creciendo, debido a que el esfuerzo dedicado a la capacitación, ya no existe o es mínimo, el mantenimiento se lleva cada cierto periodo, y el desarrollo de las pruebas se vuelve mucho más sencillo, ya que se cuenta con componentes reutilizables que anteriormente ya se han desarrollado.

53

Esto indica que el ROI, es un poco lento de obtener en un principio; pero si se mantienen constantes, si se sabe llevar a cabo la mejor estrategia de automatización, y si se utilizan las mejores prácticas, valdrá la pena su implementación por todo lo expuesto anteriormente. b. Porcentaje de pruebas automatizables:

Esta métrica, ayuda a determinar el porcentaje de pruebas automatizables de un conjunto de casos de prueba propuestos. Esto puede ser representado con la siguiente ecuación:

Fig. 38: Ecuación de porcentaje de pruebas automatizables.

Algo que puede ser considerado como “no automatizable”, por ejemplo, podría

ser un área de aplicación que todavía está en fase de diseño, dado a que no es muy estable. En casos como éste, debemos evaluar si tiene sentido automatizar. c. Progreso de automatización:

Esta métrica, ayuda a determinar el número de casos de prueba, que han sido automatizados en un periodo de tiempo. Básicamente, ¿qué tan bien se está cumpliendo el objetivo de pruebas automatizadas? Esta métrica, es útil para realizar un seguimiento durante las diversas etapas de desarrollo de pruebas automatizadas.

Fig. 39: Ecuación de porcentaje de progreso de automatización.

54

d. Porcentaje de cobertura de pruebas automatizadas:

Esta métrica, ayuda a determinar la cantidad de funcionalidades del producto que se están cubriendo con las pruebas automatizadas.

El tamaño de sistema, es calculado en base a la cantidad de líneas de código o

puntos por función. Medir el software a través de puntos por función consiste en la cuantificación de la funcionalidad, que se proporciona al usuario basado en el diseño lógico y las especificaciones funcionales.

Fig. 40: Ecuación de porcentaje de cobertura de pruebas automatizadas.

e. Eficiencia de eliminación de errores y/o defectos:

Es una de las métricas más populares para el seguimiento de la calidad. Si bien no es específico a la automatización, es muy útil, cuando lo utilizamos junto con los esfuerzos de automatización. Es una métrica, que nos sirve para determinar la efectividad de los esfuerzos de eliminación de errores y/o defectos. Cuanto mayor sea el porcentaje, mayor impacto positivo sobre la calidad del producto.

El valor más alto posible de esta métrica es 1, lo que equivale a "100%". En la

práctica se ha encontrado que una clasificación de eficiencia de 100%, no es probable. Si el porcentaje es bajo durante alguna iteración, esto nos indica, que deberíamos emplear más tiempo en actividades, que nos ayuden a reducir la deuda técnica o reducir el número de errores y/o defectos encontrados.

Eficiencia de elminación de errores y/o defectos(%) =

Nº de errores y/o defectos encontrados durante las pruebas

Eficiencia de Eliminación de

errores y/o defectos (%)

100

0Fuente: Useful Automated Software Testing MetricsFecha: Octubre 2009

Nº de errores y/o defectos encontrados durante las pruebas +

Nº de errores y/o defectos encontrados después de las pruebas

Iteración 1 Iteración 2 Iteración ..n

Fig. 41: Ecuación de eficiencia de eliminación de errores y/o defectos.

55

Existen muchos tipos de métricas, lo que hay que tener en cuenta, es que una métrica, será útil siempre y cuando sea simple, objetiva, medible, significativa y ayude a identificar áreas de mejora en la automatización de pruebas.

Tabla 2: Cuadro comparativo de métricas de tres proyectos diferentes.

En la tabla 2, se puede apreciar las métricas de las primeras cinco iteraciones de

tres proyectos diferentes: El proyecto A, no implementa la automatización de pruebas. La acumulación de

errores y/o defectos se va incrementando gradualmente durante cada iteración. Si bien en las primeras iteraciones, el porcentaje de eficiencia de eliminación de errores y/o defectos es aceptable. Durante el transcurso de las iteraciones, este valor se va reduciendo, logrando que la calidad del sistema se torne inmanejable.

El proyecto B, implementa la automatización de pruebas, sin tener en cuenta los

criterios necesarios para su éxito. Durante las primeras iteraciones, los porcentajes de progreso de automatización, cobertura de pruebas y eficiencia de eliminación de errores y/o defectos son bastante aceptables; pero durante el transcurso del tiempo, estos valores se van reduciendo, debido a que las pruebas automatizadas están siendo ignoradas, por motivos tales como: escasez de tiempo, falta de una estrategia de automatización de pruebas adecuada, falta de capacitación en las herramientas, etc. Lo que trae como consecuencia que el ROI de Esfuerzo, nunca sea recuperado y por lo tanto, se tienda a abandonar este tipo de actividad.

El proyecto C, implementa la automatización de pruebas, teniendo en cuenta los

criterios necesarios para llevarlo a cabo con éxito. Durante las primeras iteraciones, los porcentajes de progreso de automatización, cobertura de pruebas y eficiencia de eliminación de errores y/o defectos son altos. Durante el transcurso del tiempo, estos valores van estabilizándose, debido a que el sistema cada vez aumenta su tamaño. A diferencia que el proyecto B, la clave está en mantener el porcentaje de progreso de automatización en un valor entre el 65% y 80%, ya que esto nos permite tener una mayor cobertura de pruebas, y por lo tanto una mejor eficiencia a la hora de detectar errores y/o defectos. Trabajar continuamente con la implementación de pruebas, nos permitirá trabajar, en otros tipos de pruebas más profundas y finalmente nos permitirá recuperar el ROI de Esfuerzo.

56

CAPÍTULO VI: PROFESIONAL DEL ÁREA DE CALIDAD

En el capítulo anterior, se ha fundamentado el por qué la automatización de pruebas, es una actividad importante para lograr una calidad del software aceptable; pero esto sería imposible, sin las habilidades técnicas, cualidades humanas, el grado de influencia y participación de los profesionales del área de calidad durante el proceso de desarrollo de software. 6.1) Aseguramiento y Control de la calidad:

Muchas personas y organizaciones están confundidas acerca de la diferencia

entre el “Aseguramiento de la Calidad” (QA – Quality Assurance) y el “Control de Calidad” (QC – Quality Control). Están estrechamente relacionados, pero son conceptos diferentes. Dado que los dos son necesarios para gestionar eficazmente los riesgos de desarrollo y mantenimiento de software. Es importante entender estas diferencias. a. Aseguramiento de la Calidad:

Las actividades de aseguramiento de calidad (QA), aseguran que el proceso esté

definido y apropiado. Estas actividades: o Proporcionan la confianza adecuada, de que los requisitos están debidamente

establecidos y los productos o servicios, cumplen con los requisitos especificados.

o Establecen y evalúan los procesos para producir los productos. o Ayudan a establecer los procesos. o Establecen mediciones para evaluar los procesos. o Identifican las debilidades en los procesos y los mejora. o Evitan la introducción de errores y/o defectos o Evalúan si el control de calidad está trabajando con el objetivo principal de

determinar si existe o no, una debilidad en el proceso. o Mejoran el proceso que se aplica a múltiples productos.

Ejemplos de estas actividades son: o Establecer y mantener un sistema de gestión de calidad. o Establecer y mantener metodologías y estándares de desarrollo. o Revisar las políticas de control de cambios, control de errores y control de

la configuración. o Controlar documentos y registros. o Realizar auditorias por proyecto. o Establecer acciones correctivas y preventivas.

b. Control de Calidad:

Las actividades de control de calidad (QC), están diseñadas para evaluar el

trabajo de desarrollo de un producto. Estas actividades: o Comparan la calidad del producto con las normas aplicables, y las medidas

adoptadas cuando se detecta una no conformidad. o Verifican si el producto cumple con los estándares predefinidos. o Implementan el proceso. o Verifican si los atributos específicos se encuentran en un determinado

producto o servicio.

57

o Identifican y reportan errores y/o defectos con el objetivo principal de corregirlos.

o Mejoran el desarrollo de un producto o servicio específico.

Ejemplos de estas actividades son: o Planificar, crear y ejecutar pruebas. o Detectar y reportar defectos y errores. o Documentar procedimientos (manuales de usuarios, manuales de instalación,

manuales de despliegue del sistema), procesos y estrategias. o Montar entornos de prueba. o Planificar, crear y ejecutar pruebas automatizadas. o Realizar revisiones de código. o Realizar el seguimiento de tareas y defectos. o Ayudar al cliente especificar requisitos. o Controlar que el software producido, cumple con los requisitos especificados

y con los atributos de calidad impuestos. o Controlar que se utilicen los estándares en uso, que usualmente consideran

como: la reutilización de código, adopción de estándares y estilos de programación, etc.

o Controlar que se consideren todos los detalles de la instalación y puesta en marcha del sistema, así como la migración de datos y posibles problemas de eficiencia que empiezan a aparecer.

Tanto las actividades de aseguramiento de calidad y control de calidad son

generalmente necesarios para el desarrollo de software con éxito. 6.2) Conocimientos y habilidades técnicas:

Muchas de las actividades de control de calidad anteriormente nombradas

requieren de conocimientos y habilidades técnicas para que sean desempeñadas de forma adecuada. Entre las más importantes se encuentran las relacionadas con:

o Políticas de calidad. o Procesos y metodologías de desarrollo de software. o Captura de requerimientos. o Análisis de Sistemas. o Diseño de pruebas. o Tipos de pruebas. o Procesos de pruebas. o Automatización de pruebas. o Instalación y configuración de ambientes de prueba. o Instalación y configuración de servidores de integración continua. o Métricas de calidad de software. o Programación. o Arquitectura del software. o Funciones y responsabilidades de un profesional en el área de calidad. o Utilización de herramientas de pruebas.

A este conjunto de conocimientos y habilidades técnicas se le suman las

relacionadas con cada tipo de prueba en particular, como por ejemplo las pruebas exploratorias, pruebas de usabilidad, pruebas de performance y carga, pruebas de seguridad y otros tipos de prueba que requieren de un proceso, flujo de trabajo, estrategia y otros conocimientos y habilidades específicos al tema.

58

Con respecto a la automatización de pruebas, se requiere de habilidades y conocimientos específicos, como el tipo de sistema con el que vamos a interactuar, las estrategias, la importancia, los impedimentos y las herramientas de automatización de pruebas entre otros; pero si los miembros del equipo de control de calidad, no aplican estas habilidades y conocimientos con prudencia, pueden conducir al fracaso de la implementación de pruebas automatizadas, y probablemente, al fracaso del proyecto.

En las empresas de desarrollo de software, a menudo los programadores obtienen una serie de capacitaciones relacionadas a la parte técnica, mientras que los miembros del equipo de control de calidad, parecen a menudo no recibir la formación adecuada. Muchas organizaciones fallan en reconocer que estas personas, también necesitan capacitación con respecto a las pruebas, a la captura de requisitos, a la automatización y al resto de las demás habilidades, que son necesarias. Es muy importante que el equipo de control de calidad, reciba capacitación y entrenamiento, para que puedan adquirir las habilidades y la comprensión que les ayudarán a conducir al proyecto al éxito. 6.3) Cualidades humanas, grado de influencia y participación:

El principal motivo por el cual, se mantiene al equipo de control de calidad independiente del equipo de programadores. Es debido, a que si el equipo de control de calidad trabaja muy de cerca con los programadores, van a empezar a pensar como ellos y perder su punto de vista.

Si bien es importante tener un rol de control “independiente”, no quiere decir

“separado”. Esto puede llevar a la fricción, la competencia y una actitud de "nosotros contra ellos". Se pierde tiempo en las reuniones duplicadas, en donde el equipo de programadores y el equipo de control de calidad, no tienen un objetivo común.

Cada miembro del equipo tiene el mismo valor. Si el equipo de control de

calidad u otro miembro del equipo se siente excluido, el enfoque de todo el equipo está condenado al fracaso. Se debe asegurar, que todos los miembros del equipo de desarrollo, o por lo menos un representante de cada equipo, estén invitados a todas las reuniones. Todos los miembros del equipo tienen derecho a pedir y obtener ayuda.

Fig. 42: Representación de un miembro del equipo frustrado y exitoso.

59

La tendencia en un proyecto de software, donde la calidad es muy baja, donde ni siquiera se tiene implementada la automatización de las pruebas unitarias o la integración continua; es sentirse frustrado rápidamente. La ejecución de pruebas manuales para el equipo de control de calidad, se tornan engorrosas y repetitivas, sin contar que el progreso de su trabajo no se ve reflejado en el software, ya que cada vez aparecen más errores y defectos que funcionalidades que funcionen adecuadamente.

El encargado de control de calidad, debe involucrar a todo el equipo en la

solución de problemas. Debe manifestarse durante cada reunión de retrospectiva proponiendo prácticas, o algún otro tipo de mejora de procesos. Por ejemplo: “No estamos terminando las tareas de prueba, antes del final de la iteración”. Es un problema para todo el equipo. Si una de las razones para no terminar, es el elevado número de errores, se podría sugerir estimar mejor los tiempos de prueba, para realizar la implementación de la automatización de pruebas. Siempre se debe dejar al resto del equipo, proponer sus propias maneras de abordar el problema. Se debe alentar al equipo, para intentar un nuevo enfoque para unas pocas iteraciones y ver cómo funciona.

Es por ello que el encargado de control de calidad debe contar con las siguientes

cualidades: o Comunicativo. o Persuasivo. o Perfeccionista. o Disciplinado. o Perseverante. o Optimista. o Creativo. o Modesto. o Honesto. o Planificador. o Analítico. o Ordenado. o Comprensivo.

o Enérgico. o Entusiasta. o Emprendedor. o Innovador. o De buen carácter. o Fiable. o Responsable. o Decisivo. o Prudente. o Motivador. o Sociable. o Proactivo.

60

CONCLUSIÓN

Con todo lo expuesto, se puede concluir que, el tiempo, es el único recurso que no se puede recuperar y por ello se debe hacer un uso adecuado del mismo. De nada servirá invertir esfuerzos en desarrollar nuevas funcionalidades, si éstas no tienen calidad. Para que un producto sea de calidad, se debe darle máxima prioridad al tiempo que se le asigna a las actividades de control de calidad, ya que solo algunas de estas actividades no serán suficientes para cumplir con los objetivos de calidad.

La automatización de pruebas, es una de las actividades más importantes de

control de calidad, ya que además de reducir los tiempos de prueba, permitirá darle mayor importancia a la realización de otros tipos de pruebas más complejas que requieren de la inteligencia humana.

Tener la ventaja de contar con una retroalimentación continua, brindada por la

automatización de pruebas, hará visibles los errores y defectos del sistema cuando se realicen cambios, lo que obligará al equipo de desarrollo a trabajar inmediatamente por las soluciones de los mismos, sin la necesidad de esperar a la integración del código total del sistema, impidiendo de esta forma que la acumulación de la deuda técnica del sistema se torne inmanejable.

La automatización de pruebas, permite documentar los casos de prueba más

importantes, ya que están implementados de acuerdo a los criterios de aceptación definidos por el cliente. El conjunto de pruebas automatizadas, son parte del producto entregable y pueden ser ejecutados por cualquier persona. Vale la pena aclarar que con esto no se quiere decir, que otro tipo de documentación no sea necesaria.

Reducir la acumulación de deuda técnica y los errores y/o defectos del sistema,

le permitirá al equipo de desarrollo, disfrutar de su trabajo, debido a que los avances en el proyecto serán notorios y satisfactorios. Podrán encarar el desarrollo de nuevas funcionalidades más desafiantes, con el tiempo suficiente y con la ventaja de que no tendrán que pensar que lo desarrollado en iteraciones anteriores presenta una baja calidad.

Para que las pruebas automatizadas den valor al negocio, es necesario que el

encargado de control de calidad que lo lleve a cabo, posea los conocimientos y habilidades técnicas necesarias. Involucrar a una persona que no cuente con la capacitación suficiente para este tipo de actividades, implica correr un grave riesgo.

El encargado de control de calidad, se presenta como un intermediario entre el

equipo del cliente y el equipo de desarrollo. Poseer dos puntos de vista distintos, no implicará perder el objetivo por el cual el sistema es desarrollado. Conocer el lado externo e interno del sistema, le permitirá trabajar con el objetivo de lograr la calidad total del sistema y para ello deberá ser partícipe en todo asunto relacionado al sistema.

61

La calidad del sistema, es un asunto que les compete a todos los miembros del equipo de desarrollo. El encargado de control de calidad, debe estar involucrado en todos los detalles que lleve a cabo el equipo para poder sugerir mejoras. Es por ello, que es fundamental que éste posea cualidades humanas que busquen mejorar la comunicación del equipo.

Las métricas expuestas en el cuadro comparativo de la tabla 2, permiten

corroborar la veracidad de la aplicación de los puntos tratados en este seminario. Las métricas arrojadas por la automatización de pruebas, serán muy útiles para el ámbito gerencial, ya que les permitirá determinar, si la calidad interna del sistema es aceptable y además, los ayudará en las tomas de decisiones relacionadas con acciones que busquen mejorar la calidad del sistema.

Finalmente se puede decir, que se ha demostrado como una actividad de control

de calidad, la automatización de pruebas, es un factor clave para alcanzar el éxito y que de no contar con las habilidades técnicas y cualidades humanas de los profesionales del área de calidad, lograr la calidad del software sería imposible.

62

GLOSARIO API (Application Programming Interface) - Interfaz de Programación de Aplicaciones. ATDD (Acceptance Test Driven Development) - Desarrollo Guiado por Pruebas de Aceptación. GUI (Graphic User Interface) - Interfaz Gráfica de Usuario. QA (Quality Assurance) - Aseguramiento de la Calidad. QC (Quality Control) - Control de Calidad. TDD (Test Driven Development) - Desarrollo Guiado por Pruebas. UAT (User Acceptance Tests) - Pruebas de Aceptación de Usuario.

63

ANEXO: CURRICULUM VITAE FRANK ESCOBAR Fecha de Nacimiento XX/XXX/XXXX Nacionalidad Peruana DNI XXXXX Estado Civil XXXX Dirección XXXXX # XXXX, Ciudad – Mendoza – Argentina Celular (XXXX) XXXXX Teléfono (XXXX) XXXXX E-mail [email protected] Perfil Profesional http://ar.linkedin.com/in/fescobarsystems CUALIDADES

• Trabajar en equipo. • Responsable. • Habilidad para comprender rápido, enseñar y trabajar bajo presión. • Organizado, proactivo y orientado hacia los objetivos. • Emprendedor y creativo.

EDUCACIÓN FORMAL

• Pontificia Universidad Católica Argentina. Mendoza, Argentina. Lic. en Sistemas y Computación (En progreso – Esperado: Mayo 2012)

• Pontificia Universidad Católica Argentina. Mendoza, Argentina. Analista de Sistemas (Graduado 2011)

• Pontificia Universidad Católica Argentina. Mendoza, Argentina. Téc. en Programación y Operación de Computadoras (Graduado 2009)

EDUCACIÓN ADICIONAL

• Java Inicial (Duración 30 hs.) • Java Avanzado (Duración 20 hs.) • .Net Intermedio (Duración 30 hs.) • Introducción - Pruebas Exploratorias & Aplicaciones Web (Duración 8 hs.) • Fundamentos SQL sobre Oracle (Duración 20 hs.) • Introducción – Pruebas Unitarias en C# (Duración 8 hs.)

HABILIDADES

• Tipos de Pruebas: Pruebas Exploratorias. Pruebas de Aceptación de Usuario. Pruebas de Regresión. Pruebas Funcionales: TestLink & Quality Center. Pruebas de Perfomance: JMeter. Pruebas Automatizadas: Selenium (Webdriver, RC, GRID, Flex API) & Watij Pruebas Unitarias, Componentes e Integración: JUnit, TestNG, NUnit & MsUnit.

• Integración Continua: Hudson/Jenkins. • Métricas: Sonar. • Sistema de Seguimiento de Tareas: Red Mine, Pivotal Tracker & Jira. • Metodologías Ágiles: SCRUM. • Modelos & Standards: CMMI, ISO 9001:2000.

64

• Análisis y Diseño de Sistemas: Diagramas UML & Patrones de Diseño. • Lenguajes de Programación:

JAVA Intermedio (4 años) .NET Básico (1 año) PHP Básico (1 año)

• Base de Datos: Oracle, SQL Server, Mongo DB, MySql & Derby. • IDE Java & PHP: NetBeans 7.0 & Eclipse. • IDE .NET: Visual Studio 2008. • Aplicaciones de Escritorio: Java Swing. • Aplicaciones Web Java: JSP, Servlets, JSTL, AJAX, HTML and JAVASCRIPT. • Herramientas de Construcción de Proyectos: Ant & Maven. • Sistemas Operativos:

Linux: Ubuntu 10.04 Windows: XP, Seven, Server 2003.

• Idiomas: Español Nativo. Inglés Pre Intermedio.

EXPERIENCIA

• GLOBAL LOGIC – Mendoza, Argentina Duración: Febrero 2011 – A la actualidad o Proyecto de E-Commerce

Rol: Analista de Calidad Tecnologías y Herramientas: Selenium Webdriver 2.0, Selenium Grid, TestNG, Maven, SoapUI, Sonar, Jenkins, Oracle DB.

o Proyecto de Sistema de Reportes

Rol: Analista de Calidad Tecnologías y Herramientas: Groovy & Grails, Flex, SQL Server, Json, Web Services, Unit test.

o Proyecto de Sistema de Educación Financiera Familiar

Rol: Analista de Calidad Tecnologías y Herramientas: Java, Hibernate, Spring, Html, Java Script, Json, JUnit, Selenium Grid, JMeter, Sonar, Jenkins.

• BELATRIX SOFTWARE FACTORY – Mendoza, Argentina

Duración: Junio 2010 – Febrero 2011 o Proyecto Sistema Comercial

Role: Ingeniero de Calidad Tecnologías y Herramientas: Gigaspaces, Spring, Json, Fitnesse, Maven, Hudson, JUnit.

o Proyecto de Sistemas de Servicios Web

Rol: Ingeniero de Calidad Tecnologías y Herramientas: Java Web & Desktop, MySQL DB, Mongo DB, Json, Fitnesse, RestClient, Maven.

o Proyecto de Sistema de Administración Educacional

Rol: Ingeniero de Calidad Tecnologías y Herramientas: Java Web, Oracle DB, Watij.

• HOSPITAL ESPAÑOL – Mendoza, Argentina

Duración: Marzo 2009 – Agosto 2009 o Sistema de Gestión de Anestesiólogos

Rol: Analista Funcional & Desarrollador Java Tecnologías y Herramientas: Java Desktop, JPA, MySQL, JFreeChart, IReport, JUnit.

65

BIBLIOGRAFÍA Arpapress, [en línea]. Metodologías Ágiles. Dirección URL: <http://www.arpapress.com/Volumes/Vol1/IJRRAS_1_01.pdf>. [Consulta: 12 diciembre 2011]. Cohen Mike (2010). Agile Succeeding with Agile - Software Development Using Scrum. Editorial Addison–Wesley. Crispin Lisa & Gregory Janet (2009). Agile Testing - A Practical Guide for Testers and Agile Teams. Editorial Addison–Wesley. Dos Ideas, [en línea]. Reunión diaria de Scrum. Dirección URL: <http://www.dosideas.com/wiki/Reunion_Diaria_De_Scrum>. [Consulta: 20 enero 2011]. Duvall Paul M. with Matyas Steve & Glover Andrew (2007). Continuous Integration - Improving Software Quality and Reducing Risk. Editorial Addison–Wesley. Garrett Thom, [en línea]. Useful Automated Software Testing Metrics. Dirección URL: <http://www.idtus.com/img/UsefulAutomatedTestingMetrics.pdf>. [Consulta: 25 febrero 2012]. Jacobson Ivar, Booch Grady, Rumbaugh James (2001). El proceso unificado de desarrollo software. Rational Software Corporation. Version 2001A.04.00, Copyright 1987-2001. Javerianacali, [en línea]. Desarrollo Ágil con Scrum. Dirección URL: <http://cic.javerianacali.edu.co/wiki/lib/exe/fetch.php?media=materias:sg07.p02.scrum.pdf>. [Consulta: 20 enero 2011]. JUnit, [en línea]. JUnit Documentation. Dirección URL: <http://kentbeck.github.com/junit/javadoc/latest/>. [Consulta: 15 marzo 2012]. Kniberg Henrik (2007). Scrum and XP from The Trenches – How we do Scrum. Editorial InfoQ.com Enterprise Software Development series of books. Maven, [en línea]. Building a Project with Maven. Dirección URL: <http://maven.apache.org/run-maven/index.html>. [Consulta: 18 marzo 2012]. Microsoft, [en línea]. Application Archetypes. Dirección URL: <http://msdn.microsoft.com/en-us/library/ee658107.aspx>. [Consulta: 15 febrero 2012].

66

BIBLIOGRAFÍA Mosaic Inc., [en línea]. Quality Assurance & Quality Control. Dirección URL: <http://www.mosaicinc.com/mosaicinc/rmThisMonth.asp>. [Consulta: 12 marzo 2012]. Mountain Goat Software, [en línea]. Scrum. Dirección URL: <http://www.mountaingoatsoftware.com/topics/scrum>. [Consulta: 20 enero 2011]. Seleniumhq, [en línea]. Selenium Webdriver. Dirección URL: <http://seleniumhq.org/docs/03_webdriver.html>. [Consulta: 18 marzo 2012]. Spanishpmo, [en línea]. Ciclo de viuda del Modelo en Cascada. Dirección URL: <http://spanishpmo.com/index.php/ciclos-de-vida-modelo-de-cascada>. [Consulta: 12 diciembre 2011]. The Software Experts, [en línea]. Modelo en Cascada. Dirección URL: <http://www.the-software-experts.de/e_dta-sw-process.htm>. [Consulta: 12 diciembre 2011]. Waterfall Model, [en línea]. Modelo en Cascada. Dirección URL: <http://://www.waterfall-model.com>. [Consulta: 12 diciembre 2011]. Wikispaces, [en línea]. Metodología Tradicional. Dirección URL: <http://tallerinf281.wikispaces.com/file/view/METODOLOG%C3%8DAS+TRADICIONALES.pdf>. [Consulta: 12 diciembre 2011].

tesina: metodologías Ágiles centradas en la automatización de pruebas - frank escobar

Education