Tesina: Metodologías Ágiles Centradas en la Automatización de Pruebas - Frank Escobar

1,310 views

Published on

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 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.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,310
On SlideShare
0
From Embeds
0
Number of Embeds
54
Actions
Shares
0
Downloads
64
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tesina: Metodologías Ágiles Centradas en la Automatización de Pruebas - Frank Escobar

  1. 1. FACULTAD “SAN FRANCISCO”UNIVERSIDAD CATÓLICA ARGENTINALICENCIATURA EN SISTEMAS YCOMPUTACIÓNMETODOLOGÍAS ÁGILES CENTRADAS EN LAAUTOMATIZACIÓN DE PRUEBASALUMNO FRANK MARTHY ESCOBAR ARTEAGADIRECTORA DE TESINA Ing. María Antonella MannaProf. a Cargo Mg. Jorge MariottiProf. Adjunto Mg. Alejandro VázquezPresentada ante la Secretaría Académica de la Facultad San Francisco U.C.A. comorequisito parcial para optar al título deLICENCIADO EN SISTEMAS Y COMPUTACIÓNMayo 29 de 2012
  2. 2. iiTÍTULO DE LA TESINAMETODOLOGÍAS ÁGILES CENTRADAS EN LA AUTOMATIZACIÓN DEPRUEBASTesina presentada por:Alumno: ESCOBAR ARTEAGA, FRANK MARTHYAprobada en contenido por:_____________________________________________________________________Aprobada en estilo por:_____________________________________________________________________Nombre del profesor, miembro del tribunal_____________________________________________________________________Nombre del profesor, miembro del tribunal_____________________________________________________________________Nombre del Director de Carrera_____________________________________________________________________
  3. 3. iiiAGRADECIMIENTOSA mis excelentes profesores: Gustavo Sabio, Diego Garay, Julieta Suárez, CarlosTroglia, Rolando Conde, Italo Ortiz, Jorge Hidalgo, Jorge Cadoni, Alejandro Vázquez yJorge Mariotti quienes me transmitieron a través de sus enseñanzas, la voluntad paraseguir creciendo y valorarme como profesional.A mis compañeros de trabajo: Jonathan Ortiz, Antonella Manna y MarianoGiardina quienes a través de su experiencia me ayudaron a desarrollar mis cualidades yhabilidades en el área de calidad.A mi madre Ana Cecilia Arteaga, quien inspiró en mí, ser una persona constantey nunca darme por vencido a pesar de las adversidades.A mi hermana Annie Escobar y a mi novia Rita Loloy quienes me motivaron yalentaron en cada momento.A mis amigos y compañeros de facultad Diego Arena y Armando Rosario conquienes aprendí y compartí grandes momentos durante el cursado de la carrera.
  4. 4. ivRESUMENTÍTULO DE LA TESINAMETODOLOGÍAS ÁGILES CENTRADAS EN LA AUTOMATIZACIÓN DEPRUEBASFECHA DE LA DEFENSA:29 de Mayo del 2012NOMBRE DEL ESTUDIANTE:ESCOBAR ARTEAGA, FRANK MARTHYLICENCIATURA EN SISTEMAS Y COMPUTACIÓNFACULTAD SAN FRANCISCO U.C.A.Dirigida por la Ing. María Antonella Manna.Existen diversos problemas por los que actualmente atraviesan los proyectos dedesarrollo de software que realizan una transición hacia las metodologías ágiles. Loslíderes y otros miembros que forman parte del proyecto tienden a darle pocaimportancia 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 sinimportarle su buen funcionamiento. Esto implica arduas horas de trabajo para todo elequipo ya que generalmente no se llega con lo pactado cuando se está cerca al plazo deentrega, lo que genera tanto la insatisfacción por parte del equipo de desarrollo porhaber realizado esfuerzos extra, como la del cliente por no obtener una calidadconsiderablemente aceptable.Con el tiempo, estas malas prácticas se han ido propagando, opacando lasfunciones y responsabilidades de los profesionales en el área de calidad. Lo que a suvez, ha logrado impactar en las concepciones de los miembros del equipo, promoviendola idea de que los profesionales del área de calidad no brindan valor agregado alnegocio.Es aquí donde interviene la automatización de pruebas generando un fuerteimpacto, ya que a través de esta actividad podemos obtener grandes beneficios como: lareducción de tiempo durante la ejecución de pruebas, disminución de costos,retroalimentación continua, refactorización de código, documentación de lasfuncionalidades del sistema de forma ágil, cobertura de pruebas, etc. Esta actividadrequiere de mayor formación y capacitación técnica por parte de los miembros delequipo de control de calidad, como así también de mayor participación y comunicacióncon el equipo de programadores, que da como resultado todo un equipo trabajando enconjunto por la calidad del software.Además de destacar los beneficios de la automatización de pruebas, de esteseminario se obtienen propuestas de estrategias de automatización, según el tipo desoftware que se esté desarrollando. Además se incluyen flujos de trabajo que involucrana todos los miembros del equipo; y por último se expone el proceso ideal deautomatización de pruebas junto a sus métricas necesarias para la toma de decisiones enel ámbito gerencial, resaltando el rol fundamental del profesional en el área de calidad yel uso de las herramientas de prueba.
  5. 5. vÍNDICE DE CONTENIDOContenido:Agradecimientos ..............................................................................................iiiResumen........................................................................................................... ivÍndice de Tablas ..............................................................................................viiÍndice de Ilustraciones o figuras ....................................................................viiiIntroducción ..................................................................................................................... 1Capítulo 1. Metodologías ágiles centradas en la automatización de pruebas .................. 21.1) Presentación del Problema....................................................................... 21.2) Objetivos .................................................................................................. 21.3) Alcance..................................................................................................... 21.4) Metas........................................................................................................ 3Capítulo 2. Metodologías Tradicionales .......................................................................... 42.1) Historia..................................................................................................... 42.2) Modelo en cascada................................................................................... 42.3) Principales roles del modelo en cascada.................................................. 62.4) Ventajas y desventajas ............................................................................. 7Capítulo 3. Metodologías Ágiles ..................................................................................... 93.1) Historia..................................................................................................... 93.2) Principios ágiles ..................................................................................... 103.3) Scrum ..................................................................................................... 123.4) Roles en Scrum ...................................................................................... 163.5) Ventajas y desventajas ........................................................................... 18Capítulo 4. Transición hacia las metodologías ágiles.................................................... 194.1) Cultura Organizacional .......................................................................... 194.2) Problemas que surgen de la aplicación de las metodologías ágiles ....... 19
  6. 6. viCapítulo 5. Automatización de pruebas ......................................................................... 255.1) Conceptos erróneos sobre la automatización de pruebas....................... 255.2) Tipos de sistemas ................................................................................... 275.3) Estrategias de prueba.............................................................................. 305.4) Estrategias de automatización de pruebas.............................................. 355.5) Metodologías ágiles centradas en la automatización de pruebas........... 405.6) Impedimentos para llevar a cabo la automatización de pruebas............ 425.7) Automatización de pruebas aplicadas en las metodologías ágiles......... 435.8) Selección de casos de prueba a automatizar .......................................... 485.9) Selección de herramientas de automatización........................................ 495.10) Integración Continua.............................................................................. 505.11) Métricas.................................................................................................. 52Capítulo 6. Profesional del área de calidad.................................................................... 566.1) Aseguramiento y Control de la calidad.................................................. 566.2) Conocimientos y habilidades técnicas ................................................... 576.3) Cualidades humanas, grado de influencia y participación..................... 58Conclusión ..................................................................................................................... 60Glosario.......................................................................................................................... 62Anexo: Curriculum Vitae............................................................................................... 63Bibliografía .................................................................................................................... 65
  7. 7. viiÍNDICE DE TABLASTabla 1: Ejemplo ROI de Esfuerzo................................................................................ 52Tabla 2: Cuadro comparativo de métricas de tres proyectos diferentes......................... 55
  8. 8. viiiÍNDICE DE ILUSTRACIONES O FIGURASFig. 1: Modelo en Cascada............................................................................................... 5Fig. 2: Roles del Modelo en Cascada............................................................................... 7Fig. 3: Reuniones de Scrum ........................................................................................... 12Fig. 4: Historia de Usuario con criterios de aceptación y dividida en tareas................. 12Fig. 5: Actividades del dueño del producto ................................................................... 13Fig. 6: Actividades del equipo de Scrum ....................................................................... 13Fig. 7: Scrum diario ....................................................................................................... 14Fig. 8: Demostración de Sprint ...................................................................................... 14Fig. 9: Retrospectiva de Sprint....................................................................................... 15Fig. 10: Sprint Release................................................................................................... 15Fig. 11: Equipo del cliente y desarrollo trabajando como un solo equipo..................... 17Fig. 12: Escasa o nula participación del cliente............................................................. 20Fig. 13: Problemas que surgen de la aplicación de las metodologías ágiles.................. 24Fig. 14: Software que no aplica automatización de pruebas.......................................... 25Fig. 15: Software que aplica automatización de pruebas inadecuadamente.................. 26Fig. 16: Arquetipo de una aplicación de cliente enriquecida......................................... 27Fig. 17: Arquetipo de una aplicación de Internet enriquecida ....................................... 28Fig. 18: Arquetipo de una aplicación de servicios......................................................... 29Fig. 19: Arquetipo de una aplicación web ..................................................................... 29Fig. 20: Arquetipo de una aplicación móvil................................................................... 30Fig. 21: Cuadrantes de las Pruebas Ágiles..................................................................... 31Fig. 22: Diagrama de flujo de TDD ............................................................................... 31Fig. 23: Creando prueba unitaria.................................................................................... 32Fig. 24: Refactorizando código para que la prueba sea exitosa..................................... 32Fig. 25: Historia de usuario junto al prototipo de pantalla............................................. 33Fig. 26: Caso de prueba verificado por el cliente (UAT)............................................... 34Fig. 27: Gráfica de tiempo de respuesta y nº de hilos activos de un sistema................. 35Fig. 28: Pruebas de bajo nivel aplicadas en la capa de negocio..................................... 36Fig. 29: Pruebas de nivel intermedio aplicadas en la capa de negocio y/o servicios..... 38Fig. 30: Pruebas de nivel superior aplicadas en la capa de presentación....................... 39Fig. 31: Metodologías ágiles centradas en la automatización de pruebas...................... 41Fig. 32: Impedimentos para llevar a cabo la automatización de pruebas....................... 43Fig. 33: Desarrollo de software sin automatización de pruebas..................................... 43Fig. 34: Desarrollo de software sin criterios de automatización de pruebas.................. 45Fig. 35: Desarrollo de software con criterios de automatización de pruebas................. 46Fig. 36: Diagrama de flujo de ATDD ............................................................................ 47Fig. 37: Integración Continua ........................................................................................ 51Fig. 38: Ecuación de porcentaje de pruebas automatizables.......................................... 53Fig. 39: Ecuación de porcentaje de progreso de automatización................................... 53Fig. 40: Ecuación de porcentaje de cobertura de pruebas automatizadas...................... 54Fig. 41: Ecuación de eficiencia de eliminación de errores y/o defectos........................ 54Fig. 42: Representación de un miembro del equipo frustrado y exitoso........................ 58
  9. 9. 1INTRODUCCIÓNLas primeras metodologías tradicionales del desarrollo del software presentabanconceptos 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 desarrolloformado por las características de los modelos anteriores, basándose en la experiencia yen un conjunto de principios y valores que tenían como objetivo último la satisfaccióndel cliente.En los primeros años del nuevo milenio, estudios realizados revelaron que segeneraban 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 erroresy defectos. Esto sumado, a que existía la necesidad de lograr una mejor calidad conmenos recursos disponibles; y que cada vez se incrementaba la utilización de sistemastercerizados, los cuales no brindaban seguridad, integridad y confidencialidad; y eladvenimiento de nuevos estándares de calidad, dio como origen a la automatización depruebas.Por lo general, si bien la automatización de pruebas ha sido adoptada por unacantidad considerable de proyectos de software, no ha sido implementada de formaadecuada. Es por ello que este seminario intenta generar o recuperar la confianza en laautomatización de pruebas, que a través de sus beneficios y la participación de laspersonas que hacen todo esto posible, dan como resultado una calidad de softwareprogresivamente mejorable.
  10. 10. 2CAPÍTULO I: METODOLOGÍAS ÁGILES CENTRADASEN LA AUTOMATIZACIÓN DE PRUEBAS1.1) Presentación del problema:Los proyectos de desarrollo de software que intentan realizar una transiciónentre el uso de una metodología tradicional hacia una metodología ágil, que buscansatisfacer las necesidades y expectativas del cliente, tienden a fracasar debido a que losconceptos y prácticas de las metodologías anteriores están fuertemente arraigados y losnuevos conceptos, que son fundamentales para el éxito del proyecto, no son muy bienaceptados y si son aceptados son mal implementados, impactando de esta formanegativamente en la calidad de los software y por ende provocando la pérdida deconfianza en las actividades de calidad tanto en el equipo de desarrollo como en elcliente.1.2) Objetivos:o Demostrar que la automatización de pruebas es uno de los factores clavespara alcanzar el éxito de todo proyecto de desarrollo de software que apliquemetodologías ágiles.o Destacar la importancia del papel que desempeña un profesional del área decalidad de software tanto en cualidades humanas, habilidades técnicas comoel grado de influencia y participación durante el proceso, que brindan unvalor agregado al negocio, teniendo como resultado productos de calidad yequipos de trabajo con un alto grado de motivación.1.3) Alcance:Si bien existen diversos problemas que surgen de la transición de lasmetodologías tradicionales hacia las ágiles, se intentará resolver los problemas conrespecto al gerente y al equipo de desarrollo, específicamente los relacionados con ladificultad para medir el progreso del proyecto, escasez de tiempo durante el desarrollode software y los conceptos erróneos que se tienen sobre los profesionales de control decalidad. 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 mayorformación, capacitación técnica, comunicación y participación de parte del profesionalde control de calidad para lograr una mejor calidad de software trabajando en equipo.
  11. 11. 31.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 amediano 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 unproceso en el que se implementen las metodologías ágiles.o Demostrar cómo la automatización de pruebas contribuye a optimizar laspruebas de regresión, realizadas manualmente en las metodologíastradicionales.o Demostrar que las métricas provenientes de la automatización de pruebasson fundamentales para la toma de decisiones en el ámbito gerencial.o Demostrar que se requiere de profesionales del área de calidad con perfilesespecializados para llevar a cabo una mejor adaptación en las metodologíaságiles.
  12. 12. 4CAPÍTULO II: METODOLOGÍAS TRADICIONALES2.1) Historia:A partir de los años 70, surgieron diversos modelos que seguían los principios delas metodologías tradicionales. Estas metodologías imponían una disciplina de trabajosobre el proceso de desarrollo del software, con el fin de conseguir un software máseficiente. Por lo que ponían énfasis en la planificación total de todo el trabajo a realizary una vez que estaba todo detallado, comenzaban con el ciclo de desarrollo del productosoftware. Se centraban especialmente en el control del proceso, mediante una rigurosadefinición de roles, actividades, artefactos, herramientas, notaciones para el modelado ydocumentación detallada. Entre ellos podemos citar:o MSF (Microsoft Solution Framework)o Win – Win Spiral Modelo Iconixo RUP (Rational Unified Procces).Pero el más representativo de todos los modelos en las metodologíastradicionales fue el “Modelo en Cascada”. Se cree que este modelo fue el que seintrodujo primero y ampliamente en la ingeniería de software. En la década del 70 nohabía conciencia de la división de desarrollo de software en diferentes fases. Losrequisitos eran pocos y los programas eran muy pequeños, por lo que no existía lanecesidad 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ó lanecesidad 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 fueuno de los primeros modelos de ciclo de vida del desarrollo de software.El modelo describe un orden secuencial en la ejecución de los procesosasociados. El modelo de cascada supone, de manera general, que los requisitos delcliente 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 unsistema 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 sidocompletada. De esta manera uno se va acercando gradualmente a la etapa final y unavez 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 hacerel producto que vamos desarrollar. El sistema tiene que proporcionar valor alnegocio para quien lo utiliza y para sus clientes. Esto se logra mediante una
  13. 13. 5descripción de los requisitos del sistema para llegar a un acuerdo entre el cliente ylos 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 teneruna comprensión más precisa. Además se describen los mismos, para que nosayuden 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 quesoporte todos los requisitos. El propósito, es adquirir una comprensión enprofundidad de los aspectos relacionados con los requisitos no funcionales yrestricciones relacionadas con: los lenguajes de programación, componentesreutilizables, 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 ysimilares.o Pruebas: en esta fase verificamos el resultado de la implementación ejecutandocada 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 entregaal usuario final, es decir, la revisión del programa. Así como también la corrección yprevención de los defectos.Fig. 1: Modelo en Cascada.
  14. 14. 62.3) Principales roles del modelo en cascada:Existen distintos roles que se distribuyen a los largo de las fases del modelo encascada. Entre los principales roles que pueden existir en un proyecto de desarrollo seencuentran 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 altonivel).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 ydespliegue de manera de generar modelos correctos, consistentes y legibles en sutotalidad.Analista de Sistemas:o Analizar y comprender que el estado actual del proceso asegure que el contexto y lasimplicaciones de los cambios sean comprendidos por el cliente y los miembros delequipo.o Desarrollar un plan de gestión de requisitos y difundir el plan hacia todos losinteresados.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 yasegurándose que los requisitos estén completos y consistentes.Programador/Ing. de Componentes:o Definir y mantener las responsabilidades, atributos, relaciones de uno o varioscomponentes, asegurándose de que cada componente implementa la funcionalidadcorrecta.o Definir y mantener las operaciones, métodos, atributos, relaciones y requisitos deimplementació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 cumplecon su propósito.o Planificar las pruebas, definiendo objetivos de prueba apropiados.o Seleccionar y describir los casos de prueba y los procedimientos de pruebacorrespondientes 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.
  15. 15. 7Diseñador de Interfaz de Usuario: dan forma visual a las interfaces de usuario en basea su experiencia en usabilidad.ANÁLISISDISEÑOIMPLEMENTACIÓNPRUEBASMANTENIMIENTOCAPTURA DE REQUISITOSAnalista de SistemasArquitecto Diseñador de IUProgramadorArquitectoAnalista de Sistemas ProgramadorArquitectoProgramadorArquitectoProgramadorTesterAnalista de SistemasProgramadorClienteFig. 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 obtenerseal 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 sedefinía originalmente el ciclo de vida.o Es difícil que el cliente exponga explícitamente todos los requisitos alprincipio.o Es necesario que el cliente tenga paciencia, ya que obtendrá el producto alfinal del ciclo de vida.o Contribuye a que el equipo trabaje individualmente, preocupándose solo porcumplir con sus funciones y responsabilidades, y no por el resultado total delproducto, que surge del trabajo en equipo.o Genera poca comunicación entre los miembros de todo el equipo, ya quesolo intervienen en sus respectivas fases.
  16. 16. 8o Impulsa a que las actividades de control de calidad se realicen en las últimasfases, 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 losrequisitos del usuario.
  17. 17. 9CAPÍTULO III: METODOLOGÍAS ÁGILES3.1) Historia:En los primeros años de desarrollo de software, la mayoría de las necesidades delos usuarios eran bastante estables, y los planes de desarrollo a seguir no sufrían grandescambios. Sin embargo, como el desarrollo de software era más importante y crítico enlos proyectos industriales, nuevas dificultades surgieron de acuerdo con el crecimientode 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. Lamayoría de los clientes, no tenían una visión clara acerca de las especificaciones desus necesidades durante las primeras fases. Algunos clientes se daban cuenta decuáles eran sus necesidades reales, sólo cuando utilizaban la aplicación, que nosatisfacía sus necesidades.o La participación de los clientes: la falta de participación del cliente durante eldesarrollo 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 plazosajustados, debido a la competencia en los mercados. Lo que resultaba costoso a lahora de llevar a cabo la implementación del sistema, para cumplir con lo pactadocon el cliente.o Falta de comunicación: una de las causas de la falta de comprensión de losrequisitos, era la falta de comunicación entre los desarrolladores y clientes. Porejemplo, cada parte utilizaba su propio vocabulario, y esto conducía a laincomprensión de las necesidades del cliente.Debido a esto un equipo de profesionales de TI comenzó a trabajar de formaindividual sobre los nuevos enfoques para el desarrollo de software. Los resultados desus investigaciones fueron un conjunto de nuevas metodologías que tienen muchascaracterísticas comunes. Cuando se conocieron en 2001, se creó el llamado: ManifiestoÁgil. Fue así como surgieron numerosas metodologías ágiles como:o Scrumo XP (Extreme Programming)o Crystal Clearo DSDM (Dynamic Systems Developmemt Method)o FDD (Feature Driven Development)o ASD (Adaptive Software Development)o XBreedo Extreme Modelin
  18. 18. 103.2) Principios ágiles:Como se explicó en el capítulo anterior, las metodologías ágiles se formaron deacuerdo al manifiesto ágil, el cual expone los siguientes principios:a. Proveer retroalimentación continua:La mayor prioridad es satisfacer al cliente mediante entregas tempranas eiterativas del software. Una de las más importantes contribuciones es ayudar al cliente aespecificar los requisitos y las pruebas, luego el equipo logra convertir los requisitos enejecutables de prueba, que a menudo son guiados por una retroalimentaciónsignificativa.Cuando el equipo se encuentra con obstáculos, la retroalimentación es una de lasmaneras para eliminarlos, ya sea mediante los prototipos de interfaces de usuariopresentados al cliente, así como también, a través del estado y la cobertura de laspruebas, o de la estabilidad del sistema.b. Dar valor agregado al cliente:El desarrollo ágil genera valor agregado en pequeñas iteraciones que proveen losrequisitos definidos y priorizados por el cliente. El cliente participa en las reuniones deplanificación realizadas antes de cada iteración, donde se discuten detalles de losrequisitos y de como probarlos. Una inocente pregunta puede incrementar lacomplejidad del requisito.El equipo de desarrollo debe entregar la mayoría de las funcionalidades críticasen la iteración actual, si se le da importancia a las funcionalidades que no son críticas oa las nuevas funcionalidades, se corre el riesgo de no llegar con la entrega a tiempo, ypor 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 buenacomunicació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 sedeben tener en cuenta los aspectos y limitaciones a la hora de implementar esosrequisitos. La comunicación no tiene reemplazo, el desarrollo ágil depende de laconstante colaboración.d. Tener Coraje:Se necesita coraje para cometer errores y aprender de ellos, se necesita decisiónpara investigar y aplicar tecnologías jamás utilizadas, se necesita valentía para pedirayuda, sobre todo si esta persona que va a proporcionar esa ayuda se ve cansada oestresada. Hacer una pregunta o señalar un defecto requiere coraje. Los equipos ágilesson abiertos y en general aceptan nuevas ideas.e. Mantener la simpleza:No tiene ningún sentido construir complicadas estructuras que dificulten lacomprensión y utilización. Es preferible acudir a cosas sencillas y simples que, aprimera vista, reflejen lo que se quiere expresar. Las metodologías ágiles, apuestan a la
  19. 19. 11sencillez, 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, yse trata de mejorar mediante refactorizaciones continuas.f. Mejora continua:Es tarea de todo el equipo buscar la mejor manera de hacer un trabajo. Todos losmiembros del equipo participan en las reuniones “retrospectivas” donde se evalúa yanaliza 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ácticasque pueden agregar valor al negocio, y las iteraciones cortas permiten que sea más fácilprobar algo nuevo para unas pocas iteraciones y si vale la pena, se podrá adoptar a largoplazo.g. Responder al cambio:La pesadilla de todos los desarrolladores de software, es la continua evoluciónde las necesidades, debido a la falta de estabilidad que sufre el sistema al aplicar loscambios. Es un asunto complicado, que podría resultar en la pérdida de tiempo si losrequisitos se han re priorizado o si han cambiado mucho. Sin embargo se acepta que losrequisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágilesaprovechan 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 loque los miembros de todo el equipo deben discutir el asunto de inmediato y decidircómo y quién lo resolverá. El equipo tiene la autonomía para organizarse paradesarrollar en la mejor forma sus resultados.Para que la auto-organización funcione, un equipo debe tener autonomía, nodeben ser molestados y se debe confiar en ellos. La confianza es difícil cuando losrequisitos son vagos, y la autogestión es imposible cuando el equipo experimentacontinuas interferencias con respecto a las tecnologías, herramientas y prácticas que seutilizan.i. Centrado en las personas:Los miembros del equipo deben sentirse seguros y no tener que preocuparse deser culpados por los errores o de perder sus puestos de trabajo. Se deben respetarmutuamente y reconocer los logros individuales. Todos en un equipo ágil deben teneroportunidades 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 desdeprincipio hasta fin, donde los clientes trabajen juntos con los desarrolladores, dondetodo el equipo asume la responsabilidad de calidad; son elementos que encaminan a queel trabajo pueda realizarse con mayor satisfacción.
  20. 20. 123.3) Scrum:De las metodologías ágiles anteriormente nombradas en el capítulo 3, seseleccionó Scrum porque es una de las metodologías predominantemente utilizadas enel 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 enpequeñas iteraciones que pueden ser entre 2, 4 ó 6 semanas, estas iteraciones sondenominadas “Sprint”.Esta metodología reconoce tres grandes roles: Dueño del Producto, ScrumMaster y Equipo de Scrum, quienes participan en un conjunto de reuniones que serealizan en cada Sprint, llamadas: Planificación de Sprint, Scrum Diario, Demostraciónde 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 derequisitos listos para ser propuestos al equipo de Scrum para que lleven a cabo sudesarrollo. 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 productocomenta la meta del Sprint y prioriza las historias de usuario de la Pila de Producto paraque formen parte de la “Pila del Sprint”. El propósito de esta reunión, es darle al equipola suficiente información, para que puedan trabajar sin ninguna interrupción. El equipo
  21. 21. 13decide cuántas historias se incluirán en el Sprint de acuerdo al tiempo estimado en basea 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 elequipo de Scrum divide cada historia de usuario en tareas.Fig. 5: Actividades del dueño del producto.Pila del SprintPila del SprintHistoria deUsuario 008- CA001- CA002- CA003Historia deUsuario 003- CA001- CA002- CA003Historia deUsuario 011- CA001- CA002- CA003Historia deUsuario 001- CA001- CA002- CA003Historia deUsuario 009- CA001- CA002- CA003Historia deUsuario 012- CA001- CA002- CA003- T001- T002- T003- T001- T002- T003- T001- T002- T003- T001- T002- T003- T001- T002- T003- T001- T002- T003Equipo de ScrumEstimaDivide en tareasPlanificaciónde Sprint 32 hrs. 20 hrs. 11 hrs.10 hrs. 6 hrs. 5 hrs.Historia deUsuario 008- CA001- CA002- CA003Historia deUsuario 003- CA001- CA002- CA003Historia deUsuario 011- CA001- CA002- CA003Historia deUsuario 001- CA001- CA002- CA003Historia deUsuario 009- CA001- CA002- CA003Historia deUsuario 012- CA001- CA002- CA003- T001- T002- T003- T001- T002- T003- T001- T002- T003- T001- T002- T003- T001- T002- T003- T001- T002- T003Fig. 6: Actividades del equipo de Scrum.El equipo puede rechazar o no las historias de usuario que formen parte delSprint, todo dependerá de la negociación que se genere entre ambos, en donde si aldueñ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 elalcance 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 losdías y participan todos los miembros del equipo de Scrum durante el desarrollo de unSprint. Durante esta reunión el equipo sincroniza su trabajo, progreso e informacualquier impedimento que tenga o prevea al Scrum Master. Cada miembro del equipodebe responder a estas preguntas:
  22. 22. 14o ¿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 ritmode 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 quedemostrar.Fig. 8: Demostración de Sprint.
  23. 23. 15d. Retrospectiva de Sprint:Con el objetivo de mejorar de manera continua la productividad y la calidad delproducto que se está desarrollando, el equipo analiza cómo ha sido su manera detrabajar durante la iteración, para determinar si está alcanzando o no los objetivos a loscuales se comprometió al inicio del Sprint. Esta reunión que se realiza después de lademo 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 generenun producto utilizable para sus usuarios, a esto se le llama “Sprint Release”. Un SprintRelease, no debería ser más largo que un Sprint normal. Es una buena práctica queasegura, que el sistema esté en un estado tal que un sólo Sprint, alcance para ponerlo enproducción. Si la respuesta es negativa, entonces el equipo debería mejorar la calidaddel código existente y verificar que su concepto de "terminado" es lo suficientementecompleto.DÍA 1 DÍA 1DÍA 2 DÍA 3 DÍA 4 DÍA 5 DÍA 6 DÍA 7Planificaciónde SprintDÍA 8 DÍA 1DÍA 9 DÍA 10 DÍA 11 DÍA 12 DÍA 13 DÍA 14ScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioDemostraciónde SprintScrumDiarioRetrospectivadel SprintDÍA 1 DÍA 1DÍA 2 DÍA 3 DÍA 4 DÍA 5 DÍA 6 DÍA 7Planificaciónde SprintDÍA 8 DÍA 1DÍA 9 DÍA 10 DÍA 11 DÍA 12 DÍA 13 DÍA 14ScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioScrumDiarioDemostraciónde SprintScrumDiarioRetrospectivadel SprintSPRINT 1 SPRINT 2SPRINT RELEASEFig. 10: Sprint Release.
  24. 24. 163.4) Roles en Scrum:Como mencionamos anteriormente existen tres grandes roles en Scrum, loscuales tienen las siguientes funciones y responsabilidades:Dueño de Producto:o Decidir sobre cuáles funcionalidades y características funcionales tendrá elproducto.o Representar al cliente, usuarios del software y todas aquellas partes interesadas en elproducto.o Canalizar las necesidades del negocio, sabiendo "escuchar" a las partes interesadasen el producto y transmitirlas en "objetivos de valor para el producto", al equipo deScrum.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 éstaspuedan 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 delproducto.o Estimar en tiempo las historias de usuario correspondientes al Sprint.o Entregar el producto a través de desarrollos potencialmente funcionales yoperativos.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 dedatos, encargados del control de calidad y demás, que en forma auto-organizada, seránlos encargados de desarrollar el producto.Si bien las funciones y responsabilidades que realiza cada miembro del equipode desarrollo son similares a las que existen en un modelo en cascada, la gran diferenciaes que cada miembro tiene como objetivo principal obtener un software con la máximacalidad posible en sus distintas etapas, y no sólo en la etapa de pruebas, ya que estaetapa, es un componente central del desarrollo ágil de software y debe estar presente entodo momento. En las metodologías ágiles todos tienen que colaborar con la calidad delsoftware.
  25. 25. 17Por 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énestá al tanto de los demás aspectos del software que contribuyen hacia una mejorcalidad como:o Reunir, compartir información y trabajar con el dueño del producto con el fin deayudarle a expresar sus necesidades de manera adecuada para que pueda obtener lascaracterísticas que necesita, y para proporcionar información sobre los avances delproyecto a todos los miembros del equipo.o Colaborar con las personas del negocio y profesionales técnicos que comprenden losconceptos 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 delproblema 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”, esteequipo se comunica y colabora con el equipo de desarrollo, respondiendo preguntas,graficando ejemplos y revisando historias de usuarios. Entre los miembros del equipodel cliente pueden estar: los dueños del producto, expertos del negocio, expertos deldominio, analistas de negocio, administradores del producto, etc.Ambos equipos trabajan juntos todo el tiempo. Ellos son sólo un equipo con unobjetivo en común, este objetivo es darle valor agregado al negocio. El equipo delcliente con el aporte de los desarrolladores priorizará las historias de usuario adesarrollar, y el equipo de desarrollo determinará cuál será el esfuerzo que lesdemandará.Valoragregado alNegocioEquipo de DesarolloEquipo del ClienteScrum MasterFig. 11: Equipo del cliente y desarrollo trabajando como un solo equipo.
  26. 26. 183.5) Ventajas y desventajas:Ventajas:o Es más rápido, ya que se obtiene un producto funcional al finalizar cadaSprint que cumple con los requisitos planificados.o Es flexible, ya que nos permite ajustar las funcionalidades en base a lanecesidad 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 entornolibre de interrupciones e interferencias.o Evita el estancamiento, ya que las reuniones se dedican a inconvenientesrecientes.Desventajas:o Genera poca evidencia o documentación, a comparación de otrasmetodologías.o Expone ciertas prácticas que no pueden ser aplicadas por todos los proyectosde desarrollo de software.o Requiere delegar responsabilidades al equipo, incluso permite fallar si esnecesario.o Causa cierta resistencia en su aplicación para algunas personas.
  27. 27. 19CAPÍTULO IV: TRANSICIÓN HACIA LAS METODOLOGÍAS ÁGILES4.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, yaque al ser iterativas, se puede obtener una mejor retroalimentación con el cliente, y a suvez lograr una mejor calidad en el software.A pesar de que las nuevas metodologías solucionaron problemas que lasmetodologías tradicionales no tuvieron en cuenta. Apareció una gran causante denuevos 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 sereste difícil o costoso. El cambio significa para éstos moverse desde una situación actualy estable, hacia otra situación que genera incertidumbre, debido a que se piensa que estecambio traerá consecuencias negativas. Cuanto más grande sea el cambio, mayor será laresistencia.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 lamediocridad; 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 sugierenlos principios ágiles, con respecto a su participación. Si bien éste puede participar en lasreuniones de planificación, demostración y retrospectiva de Sprint, suele tener muypoca interacción con los miembros del equipo, ya que casi nunca se encuentradisponible durante el transcurso del desarrollo del software.Esto afecta gravemente a un equipo ágil, ya que las preguntas, dudas osugerencias realizadas por el equipo no pueden ser respondidas. Este inconvenienteresulta 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 decomunicació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 queperjudica directamente la calidad del software, produciendo así, la disconformidad delcliente.
  28. 28. 20Fig. 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 eluso de las metodologías ágiles, ya que las iteraciones son cortas y es notoriorápidamente si el progreso del desarrollo van encaminado o no.La escasez de tiempo es un gran desencadenante de problemas que suelenafectar al equipo, al cliente como también a la calidad del producto y entre estossubproblemas se encuentran:o Horas de trabajo extra:A menudo surgen situaciones en las cuales los miembros del equipo como loslíderes, comprometen a todo el equipo a cumplir con el desarrollo de todos losrequisitos propuestos por el cliente, sin importarles las opiniones del resto del equipode desarrollo, que son los que tienen que estimar y aceptar, rechazar, acotar o extenderel conjunto de requisitos propuestos a ser desarrollados durante la iteración. Estaactitud es conocida con la frase “Nosotros podemos hacerlo”, logrando comoresultado el fracaso de la iteración, ya que siempre se hace el compromiso, lanegociación beneficiando al cliente y no de forma equitativa. Cercana a la fecha finalde cada iteración se puede ver claramente los esfuerzos extra que realiza cadamiembro 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, muchomenos para probar el funcionamiento de los mismos. Los programadores solo seocupan de probar los casos de prueba positivos que nacen de su creatividad yentienden como críticos para dar por terminada la funcionalidad, restándolesimportancia a los casos de pruebas negativos y/o alternativos que pueden surgir de lamisma.Cercana a la fecha final de cada iteración, el equipo de programadores entrega laversión del software desarrollada al equipo de control de calidad, los cuales tienentiempo solo para llevar a cabo algunas pruebas funcionales, que se creen que sonsuficientes, para obtener una calidad de software aceptable; dejando de lado otrostipos de prueba, como las pruebas automatizadas, pruebas de exploración, pruebas deusabilidad, pruebas de aceptación de usuario y mucho menos hablar de pruebas decarga, performance y seguridad.
  29. 29. 21Al final las pocas pruebas funcionales que se le aplican al software, realizadaspor el equipo de desarrollo terminan siendo insuficientes, provocando unaacumulación de errores y defectos que probablemente serán arreglados, durantealguna 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 laspresiones que están padeciendo.Poco a poco, durante cada iteración se va perdiendo las buenas prácticas deprogramación, como la utilización de convenciones de nombres, comentarios en elcódigo, manejo de errores, uso de variables, etc.; así como también se va perdiendo laarquitectura del software, debido a que los patrones de diseño inicialmente planteadosno se están respetando.La integración del código resulta todavía más costosa, más aún cuando trabajanvarios sub-equipos juntos. Cuando se intenta hacer funcionar el código en conjunto, escomún encontrar que el código se rompa fácilmente, ya que este no es seguro nifiable. Aquí saltan a la luz un conjunto de problemas técnicos acumulados por cadasub-equipo y durante cada iteración. Permaneciendo así, la deuda técnica en lamemoria y conciencia de cada uno de los miembros del equipo de desarrollo, ya quereducir esa deuda, es muy costosa, pues no solo porque implica mucho esfuerzo, sinotambié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, porencima de la documentación exhaustiva. El manifiesto ágil, no afirma que ladocumentación no sea necesaria. Este concepto, es casi siempre mal interpretado porel equipo de desarrollo, ya que entienden por equipo ágil, producir rápida ydesordenadamente. Evitando así la documentación básica del sistema.La documentación permite la transferencia del conocimiento, registra lainformació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 paralos usuarios, los clientes, como para los futuros miembros del equipo de desarrollo. Siun nuevo miembro del equipo de desarrollo hace su ingreso ¿cómo entenderá elfuncionamiento del sistema?, ¿será suficiente con hablar con el especialista de cadamó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 esfuerzosresultan en vano ya que los resultados no son favorables.¿A quién le gusta trabajar presionado por los tiempos?, ¿a quién le gusta trabajaren un proyecto que no presenta avances?, ¿a quién le gusta trabajar lleno deincertidumbre?, ¿a quién no le gusta ser reconocido por los logros obtenidos? Todas
  30. 30. 22estas razones producen en los miembros del equipo, que cada vez se trabaje conmenos 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 lasactividades de programación, resulta obvio que mayor importancia se les dará a losprogramadores, 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 ampliosentido. Restándole importancia a los demás miembros del equipo, como es el caso delos profesionales de control de calidad. De este punto también se generan un conjuntode subproblemas:o Se piensa que el rol del profesional de control de calidad, es el rol de unusuario del sistema:Muchas empresas, cometen el error de creer que el profesional de control decalidad, 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 derol, 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 queocupe este rol. Lo que no tienen en cuenta, es el riesgo que corren al realizar este tipode acciones.o El equipo de control de calidad es excluido de las reuniones técnicas y denegocios:Contar con profesionales de control de calidad, que no tienen una buenaformación profesional, es una gran desventaja.Por esta desventaja, que se presenta la mayor parte de las veces, comúnmente sesuele 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 aportarcon alguna idea, que le de valor al equipo y al negocio; y que de participar éstos, seríauna pérdida de tiempo.Se piensa erróneamente que los profesionales de control de calidad solo debenestar enfocados en actividades de pruebas y que solo deben tener contacto con elsistema, una vez que las funcionalidades desarrolladas estén terminadas.o Se genera rivalidad entre el equipo de control de calidad y el equipo deprogramació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 yerrores en el sistema. Erróneamente, se suele premiar a la persona que lleva a caboeste objetivo con mucha satisfacción.
  31. 31. 23Satisfacción por un lado, insatisfacción por el otro. Ya que los programadorestienen poco tiempo para desarrollar las funcionalidades y además tienen un listado deerrores y defectos que va creciendo a pasos agigantados.Esta situación genera una profunda rivalidad, por lo que los programadoressuelen dejarle la responsabilidad total de la calidad del software al equipo de controlde calidad, con frases conocidas como: “Si hay algún error en el sistema, es porqueellos 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 enlas metodologías ágiles lo que se busca, es obtener la mejor calidad posible delsoftware 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 condiversas 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 internadel software.Por este motivo en el inicio del proyecto, es común que se encuentren conclientes satisfechos con el producto desarrollado, ya que solo éstos pueden percibir lacalidad externa del producto y no así la interna. Cuando se intenta trabajar concuestiones más complejas, como por ejemplo la performance del sistema, es dondenotan 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 clientesatisfecho, debe verificar si tanto la calidad externa como interna van por buen camino através de métricas más confiables.
  32. 32. 24Fig. 13: Problemas que surgen de la aplicación de las metodologías ágiles.De los problemas planteados anteriormente, es difícil intentar solucionar losrelacionados con el cliente, ya que depende absolutamente de ellos mejorar laparticipación y comunicación con el equipo de desarrollo o de reemplazar a la personaencargada de llevar a cabo dicha comunicación, con el objetivo de que finalmente salgatodo de acuerdo a lo planificado.Es por ello que este seminario, tiene como objetivo intentar solucionar losproblemas relacionados con respecto al gerente y al equipo de desarrollo, ya que sonfundamentales para contribuir en la calidad del software.
  33. 33. 25CAPÍTULO V: AUTOMATIZACIÓN DE PRUEBASLa 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. Dichaactividad, consiste en la automatización de un proceso manual de pruebas, a través de lautilización de software para controlar su ejecución, comparar los resultados actuales conlos 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 laautomatizació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 suimplementació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, elsoftware 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 pruebascomplejas, ya que es fácilmente vulnerable con un mínimo esfuerzo.Fig. 14: Software que no aplica automatización de pruebas.
  34. 34. 26b. 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 procesode desarrollo de software; pero con el tiempo sienten que dicha actividad resultacostosa, ya que no es tan fácil de implementar como pensaban, se van dando cuenta quela automatización, no resuelve todos los problemas relacionados a las pruebas y que noreemplaza totalmente a los demás tipos de pruebas, les resulta difícil llevar a cabo sumantenimiento y por lo tanto no pueden recuperar el ROI rápidamente como ellosesperaban. 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 decalidad 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 encuenta diversas cuestiones a la hora de decidir si es factible o no la implementación depruebas 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 unaautomatizació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?
  35. 35. 275.2) Tipos de sistemas:Es necesario saber con que tipo de sistemas se va a interactuar y cuál será elobjetivo de este, ya que es necesario, para evaluar qué estrategia de pruebas seimplementará, para lograr una calidad de software aceptable.Restricciones diferentes, requieren diferentes tipos de aplicaciones. Todas lasaplicaciones no son iguales. Cada proyecto tiene diferentes requisitos funcionales y nofuncionales, que requieren diferentes tipos de aplicaciones.a. Aplicaciones de cliente enriquecidas:También denominadas aplicaciones de escritorio. Son aplicacionesindependientes desarrolladas con una interfaz de usuario rica y gran capacidad derespuesta gráfica. Puede tener distintos escenarios de conectividad: sin conectividad,conectividad ocasional o constante.Las aplicaciones de cliente enriquecidas pueden beneficiarse de los recursos dela 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 solodispongan 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 ampliafuncionalidad, con posibilidades como la visualización en 3D y lainteracción entre usuarios.o Las aplicaciones deben aprovechar los recursos del PC cliente.Componentes de Interfaz de UsuarioComponentes de Procesos de Interfaz de UsuarioAplicación FachadaFlujo de Trabajode NegocioComponentesde NegocioEntidades deNegocioComponentes deAcceso a DatosServicios deDatos ExternosAgentes deServicioAplicación de ClienteEnriquecidaDatos LocalesDatos ExternosServiciosFuente: MicrosoftFecha: Octubre 2009Fig. 16: Arquetipo de una aplicación de cliente enriquecida.
  36. 36. 28b. Aplicaciones de Internet enriquecidas:Como su nombre lo indica, estas aplicaciones tienen una rica respuesta deinterfaz gráfica de usuario (GUI).Lo único acerca de las aplicaciones ricas de Internet, es que están diseñadas paraejecutarse en un navegador, por lo que tiene "profundo" alcance. Ya que soportamuchas plataformas y por lo tanto reduce los costos de desarrollo.Se debe tener en cuenta que las aplicaciones de Internet enriquecida, no puedenbeneficiarse plenamente de los recursos de la máquina cliente.Aplicación de InternetEnriquecidaClienteNavegadorContenedor de Ejecución de UI EnriquecidaMotor de UI EnriquecidaCapa de PresentaciónServidor WebCapa de ServicioCapa de NegocioComponentes deNegocioEntidades deNegocioCapa de Acceso a DatosComponentes de Acceso a DatosServidor de Base de DatosFuente: MicrosoftFecha: Octubre 2009Fig. 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 unconjunto de protocolos y estándares, que sirven para intercambiar datos entreaplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes deprogramación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar losservicios web para intercambiar datos en redes de ordenadores como Internet. Lainteroperabilidad 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ógicaempresarial en un solo lugar, en donde todas las otras aplicaciones de software puedenacceder y utilizar. Esto también reducirá los errores que se producen de tener la lógicade negocio distribuida por todo el lugar.
  37. 37. 29SeguridadAdministraciónOperacionalComunicaciónCorteTransversalServicios ConsumidoresInterfaces de Servicios Tipos de MensajesAplicación FachadaFlujo de Trabajode NegocioComponentesde NegocioEntidadesde NegocioComponentes deAcceso a DatosServicios deDatos ExternosAgentes deServicioSistemas ExternosServiciosNegocioDatosOrigen deDatos ServiciosAplicación de ServiciosFuente: MicrosoftFecha: Octubre 2009Fig. 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 laaplicación necesita una amplia exposición y/o accesibilidad. Sumado a esto, estasaplicaciones deben tener compatibilidad con múltiples navegadores, sistemas operativosy plataformas.Las aplicaciones Web requieren conectividad de red permanente. Los tipos dedesarrollo web, van desde un simple sitio web típico a un sistema con funcionalidadescomplejas.SeguridadAdministraciónOperacionalComunicaciónCorteTransversalRenderizadoComponentes UIProcesos de Componentes UIAplicación FachadaFlujo de Trabajode NegocioComponentesde NegocioEntidadesde NegocioClienteNavegadorServidor WebNegocioDatosComponentes deAcceso a DatosServicios deDatos ExternosAgentes deServicioServidor deBase de DatosServiciosAplicación WebFuente: MicrosoftFecha: Octubre 2009Fig. 19: Arquetipo de una aplicación web.
  38. 38. 30e. Aplicaciones Móviles:En este tipo de aplicaciones se nos presentan dos opciones. La primera opción esdonde el anfitrión del software cliente será típicamente el navegador de Internet, yaexistente en el dispositivo móvil y un sitio web específico para móviles. Esto requierede 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 lacapacidad de marco (como el iPhone). Esta opción requiere de más esfuerzo dedesarrollo y por lo tanto es más costosa, ya que podría existir la necesidad de desarrollaruna aplicación separada para cada dispositivo. Además requiere una conectividadocasional 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 debeseleccionar la estrategia de pruebas necesaria, de acuerdo al objetivo y al uso delsistema.Según el libro “Agile Testing” de Lisa Crispin y Janet Gregory, existen diversostipos 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 hastalo más orientado al negocio, desde luego ambas cosas tienen valor y la segunda se fundaen la primera. En el eje vertical en cambio hay dos caras, una que apunta a contribuircon pruebas que apoyen de alguna manera las labores de resto del equipo y la otra quese orienta a criticar el producto.
  39. 39. 31Apoyar al equipo con pruebas manuales no siempre, es la forma más efectivacomo puede deducirse en este diagrama, las pruebas tienen un gran valor; pero sevuelven aún más valiosas cuando dejan de ser una tarea mecánica y se convierten enuna tarea exploratoria tendiente no solo a buscar defectos sino oportunidades de mejorapara el software.Fig. 21: Cuadrantes de las Pruebas Ágiles.Esta división en cuadrantes, también ayuda a identificar qué parte está siendoprobada y quién realizó esa labor o qué habilidades y herramientas son requeridas pararealizar cada tipo de pruebas.a. Primer Cuadrante:En el primer cuadrante Q1, las “pruebas unitarias” son implementadas por losprogramadores, con el objetivo de verificar la funcionalidad de un pequeño subconjuntodel sistema, como un objeto o método. Para este tipo de prácticas está lo que se conocecomo TDD (Test Driven Development – Desarrollo guiado por pruebas), que consisteen:o Seleccionar un requisito.o Crear la prueba unitaria para el requisito seleccionado de manera tal queespere 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 elcódigo hasta que la prueba unitaria obtenga un resultado exitoso.Fig. 22: Diagrama de flujo de TDD.
  40. 40. 32El propósito del desarrollo guiado por pruebas, es lograr un código limpio quefuncione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuandolas pruebas pasen se garantizará el software, cumple con los requisitos que se hanestablecido.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 mayordel sistema, tal como un grupo de clases que proporcionan algún servicio. Ambos tiposde pruebas, suelen ser automatizados. Las pruebas unitarias y de componentes estánautomatizadas 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 lecturade las pruebas unitarias lo que se está verificando, pero estas pruebas no estándestinadas 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 partede un proceso automatizado que funciona con todos los códigos del sistema,proporcionando al equipo de respuesta inmediata y continua acerca de su calidadinterna.b. Segundo Cuadrante:Las pruebas en el cuadrante Q2 también apoyan el trabajo del equipo dedesarrollo, pero a un nivel superior. Estas pruebas definen la calidad externa y lascaracterísticas que desean los clientes.Con el desarrollo ágil, estas pruebas se derivan de los ejemplos proporcionadospor el equipo del cliente, que describen los detalles de cada historia. Están escritos enuna forma que los expertos de negocios puedan entender fácilmente utilizando ellenguaje de dominio del negocio. De hecho, los expertos de negocios, usan estaspruebas 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 comportamientodeseado del sistema en un nivel superior.
  41. 41. 33Hay otro grupo de pruebas que pertenece a este cuadrante. El uso de maquetas yprototipos para ayudar a validar propuestas de GUI (Graphic User Interface – InterfazGráfica de Usuario), los diseños con los clientes y para comunicar los diseños a losprogramadores 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 entenderdel todo bien, si no es su campo de experiencia. El equipo podría simplemente malinterpretar algunos ejemplos. Incluso cuando los programadores escriben código quehace que las pruebas de negocios pasen, no pueden entregar el producto que el clienterealmente quiere.Las pruebas del cuadrante Q3, determinan que las pruebas de negocio satisfacenlas expectativas del cliente. Cuando se hacen las pruebas críticas del producto, se tratade emular la forma en que un usuario real, va a interactuar con la aplicación. Esta es laprueba manual, que sólo un ser humano puede hacer. Se pueden usar algunos scriptsautomatizados, para ayudar a configurar los datos que se necesiten, pero se tienen queutilizar los sentidos, el cerebro y la intuición para comprobar si el equipo de desarrolloha dado el valor de negocio requerido por los clientes.A menudo, los usuarios y clientes realizan las pruebas de aceptación de usuarioUAT (User Acceptance Tests – Pruebas de Aceptación de Usuario), ya que ofrecen a losclientes la oportunidad de dar nuevas características y ver los cambios que quieran en elfuturo, convirtiéndose así en protagonista.Los usuarios pueden ayudar a definir los posibles escenarios y flujos de trabajoque pueden imitar el comportamiento del usuario final. Conocimientos del dominio, sonfundamentales para crear escenarios precisos. Se quiere poner a prueba el sistema deextremo a extremo, pero no necesariamente como una caja negra.Las pruebas de usabilidad, es un ejemplo de un tipo de prueba que tiene toda unaciencia propia. Estas pruebas, pueden incluir la navegación de una página a otra, oincluso algo tan simple como el orden de tabulación. El conocimiento de cómo laspersonas utilizan los sistemas, es una ventaja en cuanto a las pruebas de usabilidad.Las pruebas exploratorias, son fundamentales en este cuadrante. Durante estaspruebas, el encargado de control de calidad al mismo tiempo diseña y realiza laspruebas, utilizando la creatividad, intuición y el pensamiento crítico para analizar los
  42. 42. 34resultados de los escenarios posibles. Esto ofrece una oportunidad mejor para aprendermucho 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 ysofisticado que las pruebas ad hoc. Está guiada por una estrategia y opera dentro delímites definidos. Como resultado, es a través de este tipo de prueba que muchos de loserrores 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 eldesarrollo ágil, como para cualquier tipo de desarrollo de software. Las pruebas estándestinadas a las características del producto, tales como el rendimiento, robustez yseguridad.Se basa en la premisa de utilizar herramientas, que sirvan para generarescenarios en los cuales el sistema sea probado con grandes volúmenes de datos o tengatiempos de respuesta que no pueden pasar de ciertos umbrales. Este tipo de pruebas sonvaliosas y son claves a la hora de garantizar que un producto puedo escalar de muypocos usuarios y transacciones hacia volúmenes significativos.Si se conocen los requisitos de rendimiento, seguridad, interacción con otrossistemas y otros atributos no funcionales, antes de empezar a programar, es más fácilpara el diseño y el código con eso en mente. No se debe dejar este tipo de actividadesesenciales, tales como la performance para el final, cuando podría ser demasiado tardepara rectificar los problemas. Se cree que el equipo de desarrollo, tiene laresponsabilidad de explicar las consecuencias de no abordar estos requisitos nofuncionales.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 todosestos temas, pero es una buena idea tener una lista de comprobación para asegurarse deque el equipo piensa en ellos y le pide al cliente la importancia de cada uno.
  43. 43. 35Fig. 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 calidaddel software; pero la realidad indica, que no se pueden aplicar todos los tipos de pruebaa todos los softwares, ya que cada sistema presenta distintas realidades y distintosobjetivos. Existen casos en donde por ejemplo, las pruebas de usabilidad no serealizarán, ya que se trata de un servicio web; o se le dará menor importancia a lariqueza visual de la interfaz gráfica, ya que será una aplicación de uso interno; otambié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 escritoriocon muy pocos usuarios.Lo más importante para destacar, es que existen algunos tipos de pruebas que nopodemos obviar, ya que si se ignoran compromenten gravemente la calidad general detodo el sistema desarrollado. Entre estas pruebas se encuentran las pruebas unitarias yde 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 quebuscan mejorar la calidad externa. Con esto no se afirma, que el resto de pruebas nosean importantes. Lo que se quiere resaltar es, que si no se trabaja por la calidad internaprimero, seguramente se acercarán a las pruebas del cuadrante 2 y 3, pero jamás podránacercarse a las pruebas del cuadrante 4, ya que requieren de un mejor estado delsistema.5.4) Estrategias de automatización pruebas:Como se dijo anteriormente, primero se debe trabajar por la calidad interna delsistema; pero para hacer esto posible, se debe llevar a cabo una estrategia adecuada deautomatización de pruebas, donde es fundamental que el sistema posea una arquitecturaen capas.Una arquitectura en capas, divide el código en partes horizontales, que contienenuna funcionalidad similar, a menudo relacionados con una tecnología. Donde las capassuperiores, se alimentan de las capas inferiores, como por ejemplo la arquitectura en trescapas que presenta las siguientes divisiones: la interfaz de usuario, la lógica de negocioy acceso a datos.
  44. 44. 36Las capas tienen ventajas para las pruebas, pero sólo si el mecanismo deconectar las partes proporciona flexibilidad. Si se posee un código estrechamente unidoa través de mecanismos, tales como dependencias directas de clases concretas y losmé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 pruebasunitarias a través de TDD. Contraste con esto, con un código, donde las capas estánseparadas por interfaces. Las dependencias en las interfaces son fáciles de satisfacer conlas pruebas.Con la automatización de pruebas podemos satisfacer tres niveles de prueba:pruebas unitarias y/o de componentes, pruebas de API (Application ProgrammingInterface) 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 mayorparte de las pruebas automatizadas. Son por lo general, códigos en el mismo lenguajecon el que se hizo el sistema bajo prueba. Después de que un equipo de programadoresha dominado el arte de TDD, estas pruebas son mucho más rápidas y menos costosas deescribir. Estas proporcionan la forma más rápida de retroalimentación, que las hacealtamente valiosas. Ellas tienen el mayor retorno de la inversión de cualquier tipo deprueba. En el desarrollo ágil, se deben tratar de hacer tantas pruebas como sea posibleen esta capa.El equipo de programación, es el encargado y responsable de realizar este tipode pruebas, y para llevarlas a cabo se deben basar en los criterios de aceptación de lashistorias de usuario definidas por el equipo del cliente en conjunto con el equipo decontrol de calidad. Una historia de usuario, se considerará como terminada siempre ycuando estén creadas todas las pruebas unitarias y/o de componentes correspondientes acada criterio de aceptación.Componentes UIProcesos deComponentes UIAplicación FachadaFlujo de Trabajode NegocioComponentesde NegocioEntidadesde NegocioNegocioDatosComponentes deAcceso a DatosServicios deDatos ExternosAgentes deServicioServidor deBase de DatosServiciosServiciosConsumidoresTipos de MensajesSistemas ExternosServiciosInterfaces de ServiciosPresentaciónUsersAplicación FachadaFlujo de Trabajode NegocioComponentesde NegocioEntidadesde NegocioNegocioPruebas unitarias y/ode componentesFig. 28: Pruebas de bajo nivel aplicadas en la capa de negocio.
  45. 45. 37Con las pruebas unitarias, se aseguran que los programadores hayanimplementado la funcionalidad adecuada, de acuerdo a la historia de usuario y ademásse cerciorarán de que las validaciones de interés para el cliente, se encuentren presentesen la base del código, se puede tener cierta seguridad, que si existiera algún error deregla de negocios en el sistema, fácilmente estas pruebas, lo encontrarían.Las pruebas unitarias y/o de componentes, siempre deben ser consideradas a lahora de estimar el tiempo de cada historia de usuario, ya que si se dejan en el olvido estetipo de pruebas, rápidamente se irán acumulando errores y defectos, que después serándifíciles de corregir. De lo contrario, cuando nuevos programadores, se sumen al equipoo cuando se herede el sistema a otro equipo de programadores, realizar grandes cambiosserá toda una hazaña para ellos, ya que al agregar o modificar funcionalidades, es muyprobable que alteren las funcionalidades ya existentes y empiecen a funcionarincorrectamente 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 deusuario, ya que nos asegura que están incluidas las verificaciones propuestaspor 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 cambiosimportantes 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 deproducció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 capaintermedia representa una especie de portal al sistema, es la entrada principal al sistemay por lo tanto capturar un error en esta capa, sería clave para evitar un error o defectocrítico en la funcionalidad. Si bien este tipo de pruebas realizan algo muy similar a laspruebas de bajo nivel, son distintas, ya que aquí se prueba la integración de loscomponentes anteriormente probados a nivel de unidad. Cuando los programadoresconectan cada componente, es muy común que aparezcan nuevos casos de prueba queno 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 realizareste tipo de pruebas, ya que deben tomar el papel de un usuario o sistema que interactúacon el sistema a prueba. En esta etapa primero deben encargarse de verificar que todofuncione de acuerdo a lo especificado a los criterios de aceptación. Una vez que todasesas pruebas estén automatizadas, se pueden sugerir nuevos casos de pruebas, quesurgen de las pruebas exploratorias.
  46. 46. 38Componentes UIProcesos deComponentes UIAplicación FachadaFlujo de Trabajode NegocioComponentesde NegocioEntidadesde NegocioNegocioDatosComponentes deAcceso a DatosServicios deDatos ExternosAgentes deServicioServidor deBase de DatosServiciosServiciosConsumidoresTipos de MensajesSistemas ExternosServiciosInterfaces de ServiciosPresentaciónUsersAplicación FachadaFlujo de Trabajode NegocioComponentesde NegocioEntidadesde NegocioNegocioTipos de MensajesServiciosInterfaces de ServiciosPruebas de API y/oServicios WebFig. 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 porello que además de pruebas automatizadas, también se le pueden realizar pruebas deperformance, carga y seguridad. Aunque no son tan baratas para automatizar como laspruebas de bajo nivel, proporcionan información un poco más despacio, pero con lasherramientas adecuadas se puede obtener un buen ROI.Existen diversas herramientas para este tipo de pruebas, que pueden estar desdeherramientas de bajo nivel realizadas en el mismo lenguaje de programación que elsistema 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 enel mismo lenguaje de programación del sistema a prueba o softwaresespecializados.o Brindan una retroalimentación más lentamente que las pruebas unitarias y/ocomponentes.o Recuperan el ROI más lentamente que las pruebas de bajo nivel.o Son encargados y responsables de realizarlas, el equipo de control decalidad.o Son realizadas primero en base a los criterios de aceptación. Luego se lepueden añadir nuevos casos de pruebas.o Generan nuevos casos de pruebas que descubren errores y defectos que nofueron planteados con anterioridad.
  47. 47. 39c. 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 ejecutaacciones sobre los componentes gráficos para llevar a cabo una determinadafuncionalidad.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 estaparte, es la cara del sistema y siempre hay nuevas sugerencias tanto de parte del clientecomo de los usuarios.Componentes UIProcesos deComponentes UIAplicación FachadaFlujo de Trabajode NegocioComponentesde NegocioEntidadesde NegocioComponentes deAcceso a DatosServicios deDatos ExternosAgentes deServicioServidor deBase de DatosServiciosServiciosConsumidoresTipos de MensajesSistemas ExternosInterfaces de ServiciosUsersComponentes UIProcesos de Componentes UIPruebas de InterfazGráfica de UsuarioFig. 30: Pruebas de nivel superior aplicadas en la capa de presentación.En arquitecturas cliente – servidor, como las aplicaciones web, el equipo deprogramadores suele hacer validaciones de negocio del lado del cliente, como es el casodel ingreso de datos en un formulario. De esta forma, se evitan las peticiones al servidorcon datos erróneos. Es por ello, que una vez que realizan todas las validaciones en elcliente, a través de la interfaz gráfica, recién la petición, es solicitada al servidor paraque siga con el proceso. Estoy es muy bueno a nivel de performance; pero no se debenolvidar que las validaciones también deberían de estar de lado del servidor.Se afirma esto, porque generalmente los programadores olvidan hacer lasvalidaciones en el servidor, pensando en que no habrá un usuario malintencionado, queintente vulnerar la seguridad de la aplicación, pasando por alto la interfaz gráfica. Estoes muy fácil de hacer, y no es necesario que ese usuario, sea un experto en seguridad desistemas. 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, ypor lo tanto se dejarán de cumplir con los criterios de aceptación de las historias deusuario, que ya estaban consideradas como terminadas. Si se tiene en cuenta esto, se vana encontrar con validaciones de negocio, que están presentes tanto del lado del servidorcomo del cliente; del lado del cliente, por cuestiones de performance y del lado delservidor, por cuestiones de seguridad. Si bien, se consume más tiempo durante eldesarrollo de estas validaciones, quizás las cuestiones de performance no sean
  48. 48. 40importantes para ciertos proyectos; pero las validaciones de lado del servidor, elnegocio, 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 losmiembros del equipo de control de calidad, con el objetivo de cumplir con los criteriosde aceptación. Automatizando solo lo que es estable, ya que estas pruebas por lo generaltienen el menor ROI, porque son caros de mantener; pero son necesarios. Solo debemosautomatizar lo que es simple, y que nos ayude con las pruebas de regresión, el resto esmejor que lo pruebe la inteligencia humana.Aquí también se utilizan diversas herramientas, que pueden estar desdeherramientas de bajo nivel realizadas en el mismo lenguaje de programación que elsistema 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 sifuese un usuario.o Son encargados y responsables de realizarlas, el equipo de control decalidad.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 enel mismo lenguaje de programación del sistema a prueba o softwaresespecializados.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é tiposde prueba aplicaremos, y también se conoce, qué criterios tener en cuenta cuando seempiece a implementar la estrategia de automatización de pruebas. Como se verá, laimplementación correcta de las pruebas automatizadas, nos trae consigo muchasventajas 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.
  49. 49. 41Fig. 31: Metodologías ágiles centradas en la automatización de pruebas.Como se mencionó anteriormente, las pruebas automatizadas se dividen enpruebas de capa inferior, que representa la calidad interna, y pruebas de capa intermediay superior, que representa parte de la calidad externa. Tener estas pruebasimplementadas permitirá al equipo de desarrollo, trabajar por la calidad externa delproducto. De lo contrario, de qué serviría trabajar con pruebas exploratorias, pruebas deusabilidad, pruebas de aceptación de usuario, sin nombrar aún, las pruebas deperformance, carga, seguridad y otros tipos de pruebas de mayor complejidad; si aún elsistema presenta errores y defectos básicos, que ni siquiera cumplen con los criterios deaceptación.Un sistema con alta calidad interna puede, aun así, tener una baja calidadexterna; pero un sistema con baja calidad interna, difícilmente tendrá buena calidadexterna. Es difícil construir algo sobre cimientos débiles. En algunos casos puede tenersentido, desde el punto de vista del negocio, liberar una versión del producto que tengamuy baja calidad externa, y más tarde liberar una versión mejorada. Esa es decisión deldueño del producto, ya que él, es el responsable de definir el alcance. Sin embargo, lacalidad interna, es algo que no debería ser discutido. Es responsabilidad del equipo dedesarrollo, mantener la calidad del sistema, bajo toda circunstancia y simplemente nodebería ser negociable.Son comunes los casos, donde el dueño del producto intenta reducir lasestimaciones de tiempo y/o esfuerzo realizadas por el equipo de desarrollo, intentandousar como una variable de cambio, la calidad interna del producto. Sacrificar la calidadinterna del producto, es algo muy crítico por todo lo mencionado anteriormente. Si sepermite, que el código comience a deteriorarse, será muy difícil volver hacia atrás. Enlugar de reducir la calidad interna, se debería convencer al cliente de reducir el alcancede 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, ala hora de realizar la estimación de tiempo y/o esfuerzo de cada historia de usuario, eltiempo que lleva la automatización de pruebas, que es algo que no se debe tomar muy ala ligera. Es por todo esto, que se puede afirmar que toda metodología ágil de desarrollode software, debería tener su foco de atención en la automatización de pruebas, en lacalidad interna del producto.

×