• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Tesina: Metodologías Ágiles Centradas en la Automatización de Pruebas - Frank Escobar
 

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

on

  • 695 views

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

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.

Statistics

Views

Total Views
695
Views on SlideShare
656
Embed Views
39

Actions

Likes
0
Downloads
38
Comments
0

2 Embeds 39

http://www.linkedin.com 38
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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
    • 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_____________________________________________________________________
    • 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.
    • 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.
    • 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
    • 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
    • viiÍNDICE DE TABLASTabla 1: Ejemplo ROI de Esfuerzo................................................................................ 52Tabla 2: Cuadro comparativo de métricas de tres proyectos diferentes......................... 55
    • 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
    • 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.
    • 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.
    • 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.
    • 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
    • 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.
    • 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.
    • 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.
    • 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.
    • 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
    • 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
    • 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.
    • 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
    • 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:
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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
    • 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.
    • 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.
    • 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.
    • 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.
    • 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?
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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
    • 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.
    • 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.
    • 425.6) Impedimentos para llevar a cabo la automatización de pruebas:Una de las ventajas de impulsar el desarrollo de las pruebas, es que el códigoestá escrito con la intención expresa de hacer pasar las pruebas. El equipo tiene quepensar, desde el principio, acerca de cómo se va a ejecutar y automatizar las pruebaspara cada historia de usuario que codifica.Escribir “código comprobable”, es un concepto simple, pero no es una tareafácil, especialmente si se está trabajando con el código de un sistema heredado, que notiene pruebas automatizadas, y no está diseñado para la capacidad de prueba. Lossistemas heredados a menudo, tienen la base de datos, la lógica de negocio, y la interfazde usuario fuertemente relacionados. No hay una independencia suficiente como paraautomatizar una prueba de bajo nivel o nivel intermedio.Los sistemas heredados, que no están cubiertos por pruebas unitariasautomatizadas, presentan un enorme desafío. Es difícil escribir pruebas unitarias decódigo, que no está diseñado para la capacidad de prueba, y es difícil cambiar el código,que no está garantizado con las pruebas unitarias. No es imposible, pero habría quemigrar el sistema con una nueva arquitectura, lo que resultaría muy costoso tanto entiempo, dinero como en esfuerzo. Quizás esto, represente el mayor impedimento para laimplementación de pruebas automatizadas de bajo nivel; pero entre otras alternativas sepodría automatizar pruebas de los otros dos niveles restantes para aplacar esta debilidad,todo depende del estado actual del sistema. El mejor de los casos, es cuando se trata deun sistema completamente nuevo, o cuando se trata de un sistema heredado, que poseauna buena arquitectura, o en donde ya se estaban aplicando pruebas automatizadas conanterioridad.Si se está tratando con un proyecto, con un ciclo de desarrollo de corto plazo, endonde el sistema tendrá una o dos versiones, como se puede dar en el caso de lasaplicaciones móviles, la automatización de pruebas, se puede llegar a transformar en unimpedimento para el desarrollo de software, ya que al ser corto el tiempo, no seránecesario ejecutar pruebas de regresión. De lo contario se perderá tiempoimplementando la automatización de pruebas; pruebas que fácilmente se podríanrealizar manualmente.Otras de las cosas por la que puede a llegar a peligrar, la decisión deimplementar la automatización de pruebas, es la capacidad técnica del equipo deprogramadores como el equipo de control de calidad. Si uno o ambos equipos, no estáncapacitados para desarrollar pruebas automatizadas, por no poseer conocimientos dellenguaje de programación u otras herramientas existentes, será casi imposible llevar acabo este tipo de prácticas. Nada que no se solucione con capacitaciones relacionadas altema.Anteriormente se había planteado, que se suelen dar los casos en donde el clienteintenta negociar tratando de reducir la calidad interna del software a cambio de unamayor velocidad del equipo. Lamentablemente, a veces este tipo de ideas, no soloprovienen del cliente, sino también es común que provenga de la gerencia de la empresaque desarrolla al software. Si los fundamentos que estamos exponiendo, defendiendo laautomatización de pruebas, no son claros tanto como para el cliente, como para lagerencia, difícilmente podremos llevar a cabo una automatización de pruebas exitosa.
    • 43Fig. 32: Impedimentos para llevar a cabo la automatización de pruebas.5.7) Automatización de pruebas aplicadas en las metodologías ágiles:¿En qué momento de la iteración debemos automatizar? Es la pregunta quecomúnmente surge. Y que de no tomar una decisión adecuada, puede llevarnos alfracaso del proyecto. Se pueden dar los siguientes casos:a. Caso A - Desarrollo de software sin automatización de pruebas:El equipo de desarrollo de software, se siente convencido de que las pruebasfuncionales manuales y las pruebas de aceptación de usuario, son suficientes para teneruna calidad aceptable del software.Fig. 33: Desarrollo de software sin automatización de pruebas.Con este tipo de mentalidad el equipo de control de calidad, al principio de laiteración, se encarga de ayudar a definir los criterios de aceptación de las historias deusuario, junto al cliente a través de ejemplos y prototipos. Luego, durante el transcursode la iteración el equipo de programadores, trabaja con la implementación de lashistorias de usuario. Al final de la iteración, cuando se termina con la implementación,el equipo de programadores, libera la primera versión (versión 1.0), para que seaverificada por el equipo de control de calidad y usuarios finales a través de pruebasfuncionales manuales y pruebas de aceptación de usuarios. La demo se realiza“exitosamente”, ya que el equipo mostró el camino feliz de las funcionalidadesrequeridas. El equipo de control de calidad, logró verificar los criterios de aceptación;pero no tuvieron tiempo para realizar pruebas mucho más profundas.
    • 44Ya dimos por terminada la primera iteración, ahora el equipo de desarrollo,encarará las historias de usuarios de la segunda iteración. Todo se comporta tal como laprimera iteración, excepto que aparece un nuevo inconveniente. Los usuarios finales yel equipo de control de calidad encuentran defectos y errores críticos que no habíanpercatado con anterioridad, por lo que informan al equipo de programadores para quesean solucionados inmediatamente. Los programadores, trabajan por eliminar loserrores y defectos detectados, consumiendo tiempo de la segunda iteración. Al pocotiempo liberan una segunda versión (versión 1.1) con las funcionalidades corregidaspara que sean verificadas nuevamente.El equipo de programadores, ya se ocupó de solucionar los errores y defectos dela primera iteración, ahora pueden ocuparse de seguir con el desarrollo de lasfuncionalidades de la iteración actual; pero hay otro inconveniente. Ahora el tiempo conel que contaban se ha reducido drásticamente, así que tendrán que optar por buscarsoluciones temporales que les permitan salir de la presión de entrega. Losprogramadores logran liberar una versión con los requisitos desarrollados de la segundaiteración (versión 2.0); pero ahora la presión fue transmitida al equipo de control decalidad, debido a que el tiempo que utilizaban para realizar las pruebas, también ha sidoafectado por los errores y defectos de la iteración anterior. Finalmente la calidad delsoftware de la última versión, es muy baja, ya que no logra ni siquiera cumplir con loscriterios de aceptación planteados, no había tiempo. Todo esto sumado a que todavía nose sabe, si los defectos y errores “solucionados” en la segunda versión han sidocorrectamente corregidos.Con esto podemos ver claramente, que sin la implementación de automatizaciónde pruebas, es muy fácil que se produzca la acumulación de errores y defectos, comotambién la acumulación de la deuda técnica. ¿Qué situación positiva podemos llegar aesperar, si es que se presenta esta misma situación; pero con acumulaciones de nueve odiez iteraciones de desarrollo?b. Caso B - Desarrollo de software sin criterios de automatización de pruebas:Existen equipos de desarrollo, que subestiman la implementación deautomatización de pruebas, es por ello que lo ponen en práctica, sin tener en cuenta loscriterios como para llevarlo a cabo exitosamente.Similar al caso anterior, todo comienza cuando el equipo de control de calidad alprincipio de la iteración, se encarga de ayudar a definir los criterios de aceptación de lashistorias de usuario, junto al cliente a través de ejemplos y prototipos. Luego, durante eltranscurso de la iteración el equipo de programadores, no solo trabaja con laimplementación de las historias de usuario, sino también con la implementación depruebas automatizadas de bajo nivel, de acuerdo a su propio criterio y no a los criteriosde aceptación planteados. Posteriormente el equipo de programadores, pasa a liberar laprimera versión (versión 1.0) y el equipo de control de calidad, se encarga deautomatizar las pruebas funcionales de nivel superior, pensando que este tipo de pruebasreemplaza todo tipo de pruebas manuales. Con el transcurrir de la iteración, se dancuenta que no es muy fácil automatizar en esta capa, y terminan automatizando unaparte y ejecutando pruebas manuales por otra, juntos a los usuarios finales. La demo serealiza “exitosamente”, ya que el equipo mostró el camino feliz de las funcionalidadesrequeridas. El equipo de control de calidad, logró verificar los criterios de aceptación;pero nuevamente no tuvieron tiempo para realizar pruebas mucho más profundas.
    • 45Versión 1.0Versión 1.1Versión 2.0- Pruebas funcionales de nivelsuperior automatizadas- Pruebas funcionales manuales- Pruebas UAT- Ejemplos- PrototiposEquipo de control de calidad Usuarios finalesErrores ydefectosencuentranafectangenerangeneran generanprobadoporEquipo de programadoresrealizada por- Pruebas automatizadas de capa inferior- Ejemplos- Prototipos- Pruebas automatizadas de capa inferior- Pruebas funcionales de nivelsuperior automatizadas- Pruebas funcionales manuales- Pruebas UATDesarrollo de historias de usuario Desarrollo de historias de usuarioITERACIÓN Nº1 ITERACIÓN Nº2Fig. 34: Desarrollo de software sin criterios de automatización de pruebas.Las funcionalidades de la primera iteración se terminaron, ahora el equipo dedesarrollo, encarará las historias de usuarios de la segunda iteración. Pero aquí apareceel mismo inconveniente que el caso anterior. Los usuarios finales y el equipo de controlde calidad encuentran defectos y errores críticos, que no habían percatado conanterioridad; pero aquí debido a que las pruebas automatizadas de bajo nivel no estabanimplementadas, de manera que cumplan los criterios de aceptación. Se informa alequipo de programadores, para que esto sea solucionado inmediatamente. Losprogramadores, trabajan por eliminar los errores y defectos detectados, consumiendotiempo de la segunda iteración y como poseen pruebas automatizadas de bajo nivel, lasejecutan; pero estas al no cubrir los criterios de aceptación, no son de mucha utilidad.Son conscientes de esto; pero no hay tiempo para crear más pruebas automatizadas, yaque están consumiendo tiempo valioso de la segunda iteración. Al poco tiempo liberanuna segunda versión (versión 1.1) con las funcionalidades corregidas para que seanverificadas nuevamente.El equipo de programadores, ahora tiene que enfocarse en el desarrollo de lasfuncionalidades de la iteración actual; pero ahora el tiempo con el que contaban seredujo, y por lo tanto al igual que en el caso anterior, tendrán que buscar solucionestemporales, que les permitan salir de la presión de entrega. Así estos, logran liberar unanueva versión (versión 2.0), y ahora el equipo de control de calidad, es el que tiene queentrar en acción. Aquí este equipo se da cuenta, de que las pruebas automatizadasrealizadas no son de mucha utilidad, y no sólo porque quizás no se cumplan con loscriterios de aceptación, sino también, porque la interfaz gráfica de usuario en su nuevaversión, ha sufrido cambios, y por lo tanto las pruebas no son estables, por lo que debenser refactorizadas; pero ellos tampoco tienen tiempo para eso, así que prefieren llevar acabo las pruebas manualmente.Todos estos hechos desalientan totalmente al equipo de desarrollo, y generan enellos la idea, de que las pruebas automatizadas, solo les harán perder más tiempo, quenecesitan para llevar a cabo la ejecución de las pruebas manuales.
    • 46c. Caso C - Desarrollo de software con criterios de automatización de pruebas:Para llevar a cabo la implementación de pruebas automatizadas de formaadecuada, se debe saber en qué momento de la iteración, se va a llevar a cabo cada tipode pruebas.Versión 1.0Versión 1.1Versión 2.0- Ejecución de pruebas funcionalesde nivel intermedio automatizadas- Pruebas funcionales manuales- Pruebas exploratorias- Pruebas UAT- Ejemplos- PrototiposEquipo de control de calidad Usuarios finalesErrores ydefectosencuentranafectangenerangeneran generanprobadoporEquipo de programadoresrealizada por- Ejemplos- Prototipos- Pruebas automatizadasde capa inferior- Creación de pruebasfuncionales de nivelintermedio automatizadas- Pruebas funcionales manuales- Ejecución de pruebas funcionales denivel intermedio- Pruebas de nivel superior automatizadas- Pruebas de performance y carga- Pruebas de seguridad- Pruebas de usabilidad- Pruebas automatizadasde capa inferior- Creación de pruebasfuncionales de nivelintermedio automatizadasDesarrollo de historias de usuarioDesarrollo dehistorias de usuarioITERACIÓN Nº1 ITERACIÓN Nº2Fig. 35: Desarrollo de software con criterios de automatización de pruebas.En este caso, el equipo de control de calidad, al principio de la iteración, seencarga de ayudar a definir los criterios de aceptación de las historias de usuario, juntoal cliente a través de ejemplos y prototipos. En la etapa de desarrollo de historias deusuario, el equipo de programadores, implementa las funcionalidades solicitadas deacuerdo a los criterios de aceptación, y se aseguran de que esto sea así, implementandolas pruebas automatizadas de bajo nivel. A diferencia de los casos anteriores el equipode control de calidad, se encarga de realizar las pruebas automatizadas de nivelintermedio; pero ¿cómo implementarán estas pruebas, sin aún no tienen la API o elservicio web programado? Esto es posible, porque se pueden crear estas pruebas demanera tal, que esperen los resultados adecuados, sin importar que fallen, ya que lasfuncionalidades, aún no han sido implementadas. Una vez que el equipo deprogramadores liberó la primera versión (versión 1.0), las pruebas automatizadas denivel inferior e intermedio son ejecutadas, verificando inmediatamente si los criterios deaceptación, se han cumplido correctamente. Aquí se suman las pruebas funcionalesmanuales, probando todo lo relacionado con la interfaz gráfica, junto a las pruebasexploratorias y pruebas de aceptación de usuario. La demostración ha sido exitosa, se halogrado cumplir con los criterios de aceptación y el cliente está satisfecho.Se dio por finalizada la primera iteración; pero no podemos negar que siempre seencontrarán errores y defectos por los cuales trabajar, la diferencia será que está vez elesfuerzo será mucho menor, debido a que los errores y defectos son mínimos. Es porello que en cada iteración, además de estimar pensando en el tiempo que se le asignará alas pruebas, también se debe pensar en el tiempo que se le asignará a la corrección deerrores y defectos.
    • 47La nueva iteración, será muy similar a la anterior, excepto que contará con unbreve lapso de tiempo, en el cual los programadores, se dedicarán a la corrección deerrores y defectos. Esto no significa, que tendremos a todo un equipo de programadoresenfocados en esta tarea, sino que también podemos optar por designar uno o dosprogramadores dedicados a esta tarea por cada iteración, de manera que el resto puedacontinuar con el desarrollo de nuevas funcionalidades. De esta forma se libera lasegunda versión (versión 1.1) con los errores y defectos corregidos, simultáneamentedesarrollando las funcionalidades de la segunda iteración, junto con sus respectivaspruebas automatizadas de bajo nivel e intermedio, sin problemas de tiempo. Finalmentese libera la nueva versión (versión 2.0), en donde el equipo de control de calidadademás de realizar las pruebas exploratorias y de UAT, podrá ejecutar las pruebasautomatizadas, que no solo servirán para verificar si los criterios de aceptación se estáncumpliendo, sino también servirán, para saber si las funcionalidades que fuerondesarrolladas en iteraciones anteriores, no se vieron afectadas por algún cambiorealizado en la iteración actual, esto es lo que se conoce como pruebas de regresión.Con el transcurrir de las iteraciones las funcionalidades, se irán haciendo cada vez másestables, por lo que podremos ir agregando algunas implementaciones de pruebasautomatizadas de nivel superior. Además, según sea la necesidad del sistema podremosir agregando otros tipos de pruebas, como las pruebas de usabilidad, seguridad,performance y carga; pero para ello quizás debamos agregarle tiempo a la etapa depruebas, o agregar recursos que realizan este tipo de tareas, según sea el caso.Con lo expuesto anteriormente, se quiere dejar en claro, que los criterios deaceptación de las historias de usuario, son claves, y a la hora de automatizar pruebas, nodebemos olvidarlos, de lo contrario no será posible satisfacer las necesidades del cliente.Esto es lo que se conoce como el proceso ATDD (Acceptance Test Driven Development– Desarrollo guiado por Pruebas de Aceptación), esta práctica que es muy similar aTDD consiste en:o Seleccionar una historia de usuario.o Crear los criterios de aceptación junto con el cliente.o Crear un conjunto de casos de prueba de aceptación que satisfagan loscriterios de aceptación.o Automatizar los casos de prueba de aceptación, sin importar que fallen.o Implementar historia de usuario.o Ejecutar casos de prueba de aceptación hasta que los resultados seansatisfactorios y refactorizar la funcionalidad y/o las pruebas de ser necesario.o De arrojar las pruebas un resultado satisfactorio, el cliente dará laconformidad de que la historia de usuario fue correctamente implementada.Fig. 36: Diagrama de flujo de ATDD.Con esto podemos ver que TDD se ocupa de la calidad interna, mientras queATDD se ocupa de la calidad externa del software.
    • 485.8) Selección de casos de prueba a automatizar:En la sección anterior, se dio a conocer los motivos necesarios, del por qué laspruebas automatizadas, deben tener el objetivo de cumplir con los criterios deaceptación de las historias de usuario. Esto es muy útil; pero también hay que tener encuenta otros criterios para determinar el orden, en que vamos a automatizar las pruebas:a. ¿Las pruebas son sencillas de automatizar?Cuando se empiece a seleccionar los casos de prueba a automatizar, se debeprimero verificar, si la prueba no es tan costosa de implementar. Si implica construirmuchos componentes de automatización, solo para un caso de prueba en particular, noconvendría automatizarlo; otra opción sería darle la mínima prioridad, para que cuandohaya tiempo, se realice su implementación. Ahora si, esos componentes deautomatización, van a ser reutilizados por una buena cantidad de casos de prueba,invertir tiempo ahí sería muy beneficioso.b. ¿Las pruebas requieren de intervención manual?Algunas pruebas necesitan de ojos, de oídos y de la inteligencia humana. Lausabilidad y las pruebas exploratorias son dos tipos de prueba, que están dentro de estacategoría y no requieren que sean automatizadas.c. ¿Las pruebas se han ejecutado y verificado manualmente?Para que un caso de prueba, sea automatizado a nivel superior, se debe primeroverificar, que cumpla con su objetivo, ya sea que se trate de un caso de prueba positivoo un caso de prueba negativo. Un caso de prueba que no pueda ejecutarse manualmente,implicaría una pérdida de tiempo al momento de automatizarlo.d. ¿Estamos seguros del cumplimiento de las precondiciones?Si para ejecutar un caso de prueba, se requiere de precondiciones, al automatizarel caso de prueba, se debe crear componentes de manera tal, que simulen el estado delos datos, como si las precondiciones se hubiesen ejecutado, o si de ser el caso, ejecutarcon anterioridad los casos de prueba, que cumplen con las precondiciones del caso deprueba actual.e. ¿Puedo confiar en las pruebas automatizadas para probar la funcionalidadahora y en un futuro?Si no se cuenta con un set de datos y/o componentes reutilizables, cada vez quese ejecute la prueba automatizada, difícilmente se tendrán las garantías suficientes, deque se estén ejecutando correctamente. Se debe asegurar, de que las pruebasimplementadas servirán ahora y en el futuro, se debe pensar en su mantenimiento. Estopuede implicar mayor tiempo, a la hora de la implementación de las pruebas; pero esmejor consumir ese tiempo, pensando en su mantenimiento desde un principio, queconsumir el tiempo durante varias iteraciones, ya que de lo contrario se terminaríahaciendo múltiples refactorizaciones, con el riesgo de olvidar cual es el verdaderoobjetivo de la prueba.
    • 495.9) Selección de herramientas de automatización:Se puede contar con una amplia gama y creciente de herramientas para elegir:herramientas de creación propia, herramientas de código abierto, herramientascomerciales o una combinación de cualquiera, son todas las alternativas viables. Contantas opciones, se debe saber, dónde buscar y encontrar el tiempo suficiente, paraprobar las herramientas y así determinar si se ajustan a las necesidades.a. Herramientas de creación propia:Estas herramientas tienen muchas ventajas, ya que son amigables para elprogramador. Si el equipo, está escribiendo su propio framework de automatización,podrá ser adaptado a las necesidades de nuestro sistema.Que sea de creación propia, no significa gratis. El equipo de desarrollo, se veinvolucrado a desarrollar este framework, lo que implica consumir el tiempo dedesarrollo, situación que no muchos clientes están de acuerdo en negociar, ya queconstruir un potente componente de automatización de pruebas, no es lo mismo queautomatizar pruebas.b. Herramientas comerciales:Estas herramientas son percibidas, como una apuesta segura. Es probable quevengan con manuales, soporte e información para los miembros del equipo de controlde calidad u otros usuarios que carezcan de conocimientos técnicos avanzados.Las herramientas comerciales son históricamente hostiles para el equipo dedesarrollo. Tienden a utilizar lenguajes propietarios, que no tiene sentido que semalgaste el tiempo en aprenderlas a utilizar. También tienden a ser pesados y laspruebas, pueden ser frágiles, se rompen fácilmente por los cambios de menorimportancia a la aplicación, y son caros de mantener.c. Herramientas de código abierto:Existen equipos de desarrollo de software externos, que escribieron sus propiasherramientas, debido a que herramientas de terceros, no satisfacían sus necesidades yque generosamente han puesto a disposición de la comunidad del código abierto.Por lo general, estas herramientas son ligeras y adecuadas para el desarrollo ágil.La ventaja, es que han sido previamente probadas y aplicadas en distintos proyectos, ypor lo tanto mejoradas. Son de fácil personalización y son confiables. Estasherramientas cuentan con características útiles para todo el equipo de desarrollo.Para encontrar la herramienta óptima, se debe intentar con una herramienta a lavez, dándole tiempo suficiente para un juicio justo. Lo importante, es resaltar que unaherramienta, es ágil cuando contribuye con los principios ágiles. Por lo tanto serecomienda, el uso de herramientas de código abierto, ya que además de no generarcostos, si se necesita de alguna nueva funcionalidad útil para las pruebas, se podrádesarrollar ese pequeño tramo, y continuar con la automatización del resto de laspruebas. El equipo de desarrollo, debe estar concentrado en el desarrollo de lasfuncionalidades y en las pruebas de las mismas, y no en la construcción de unframework de automatización o hallarse limitados por las herramientas.
    • 505.10) Integración Continua:Hasta aquí se cuenta, con pruebas automatizadas, que se ejecutan con lasherramientas en el entorno de desarrollo, de cada miembro del equipo de desarrollo;pero no se cuenta, con un lugar centralizado que permita saber, si el trabajo de unintegrante del equipo, integrado al trabajo de los demás miembros, se acoplacorrectamente.La integración continua, es una práctica de desarrollo de software, donde losmiembros del equipo integran su trabajo con frecuencia. Cada integración, es verificadapor un sistema automatizado de construcción (incluyendo las pruebas), para detectarerrores de integración. Este enfoque ayuda a reducir los problemas de integración y nospermite desarrollar nuestro producto de forma más rápida.Algunos ven la integración continua, como un proceso que simplemente agrupalos componentes de software. La integración continua, es la pieza central del desarrollode software, ya que garantiza la calidad del software, a través de la ejecución de unaconstrucción (build) con cada cambio que realicemos. Si no se le da importancia aelementos, tales como el entorno de desarrollo, la construcción y el despliegue delsoftware, se verán obligados a realizar tareas de bajo nivel más adelante, y en losmomentos más inoportunos, como por ejemplo el día anterior al plazo de entrega.Las ventajas de implementar la integración continua son:a. Reducir los riesgos:Los errores y defectos se detectan más pronto, porque se integran y ejecutan laspruebas varias veces al día, ya que hay una mayor probabilidad de que se detectencuando son introducidos, en lugar que se detecten durante las pruebas al final de laiteración.La calidad del software es medible, mediante la incorporación de las pruebas yla inspección continua en el proceso de integración automática. Los atributos tales comola complejidad, líneas duplicadas, cobertura de pruebas y otros pueden ser rastreados.Reduce las hipótesis en cuanto a las pruebas, construcción y despliegue y delsoftware en un entorno limpio usando un mismo proceso.b. Reducir los procesos manuales repetitivos:La reducción de los procesos repetitivos ahorra tiempo, costos y esfuerzo. Estosprocesos repetitivos pueden ocurrir en todas las actividades del proyecto, incluyendo lacompilación de código, integración de bases de datos, pruebas, inspección, instalación,y la retroalimentación. Cada vez que se ejecute el proceso, asegura que lo haga de lamisma manera. Lo que facilita la reducción de mano de obra en los procesos repetitivos,liberando a la gente para realizar otro tipo de actividades.c. Generar versiones del software en cualquier en cualquier momento y encualquier lugar:La integración continua, permite liberar versiones del software en cualquiermomento y lugar. Si hay algún problema con la versión liberada, los miembros delproyecto estarán informados y las correcciones se aplican al software de forma
    • 51inmediata. Los proyectos que no siguen esta práctica, esperan hasta inmediatamenteantes de la entrega para integrar todo y probar el software. Esto puede ser el resultadode una demostración al cliente desastrosa, que puede significar la finalización delproyecto, ya que los errores y defectos que se presenten, no solo se deben a lasfuncionalidades recientemente implementadas, sino a la configuración del servidor odispositivo en el que se encuentre funcionando.Además de contar con la posibilidad de realizar un despliegue automático, da laposibilidad de generar diversos ambientes como para realizar otros tipos de pruebas,como es el caso de las pruebas de performance y carga, en donde se requiere de unambiente aislado.d. Permitir una mejor visibilidad del estado del proyecto:La integración continua, proporciona la habilidad de percibir las tendencias ytomar decisiones eficaces, y ayuda a proporcionar el valor de innovar en nuevasmejoras. Las decisiones de un sistema eficaz de integración continua, puedenproporcionar justo a tiempo, la información sobre la reciente situación de construcción ylas métricas de calidad. Podemos percibir las tendencias del proyecto, ya sea del éxito oel fracaso a través de la construcción, calidad general, y otra información pertinente alproyecto.e. Establecer una mayor confianza en el producto por parte del equipo dedesarrollo:Con cada integración, el equipo sabe que las pruebas se ejecutan para verificar elcomportamiento, que la codificación de los proyectos y normas de diseño se cumplen, yque el resultado, es un producto funcional comprobable. Sin integraciones frecuentes, elequipo no puede conocer el impacto de cambio que proviene de sus códigos.Fig. 37: Integración Continua.
    • 525.11) Métricas:Con la automatización de pruebas, se puede controlar la calidad interna y partede la calidad externa del software; pero que sentido tiene controlar, sino se puede medir.El éxito del proyecto, se mide sobre la base de la meta que se proponen llevar a cabo, enrelación con las expectativas de los accionistas y clientes. Las métricas de pruebasautomatizadas, pueden ayudar en la realización de evaluaciones, en cuanto al progresode los objetivos, la productividad y la calidad.De esta forma se pueden contestar preguntas tales como: ¿se justifica todo elesfuerzo que se emplea para que la automatización de pruebas se lleve a cabo?, ¿cuántoscasos de prueba se han automatizado?, ¿cuántos casos de prueba necesitan serautomatizados?, etc. Entre las métricas más importantes se encuentran:a. ROI del Esfuerzo:Esta métrica, ayuda a determinar si el esfuerzo ahorrado como resultado de laautomatización de la prueba, es el suficiente como para justificar el esfuerzo empleadoen la implementación de la misma. En donde si:o El ROI de Esfuerzo es < 1 indica: el esfuerzo ahorrado como resultado de laautomatización de pruebas, no es lo suficientemente alto como para justificar elesfuerzo empleado en la implementación de la automatización.o El ROI de Esfuerzo es = 1 indica: No hay ningún esfuerzo humano ahorrado comoresultado de la automatización de pruebas.o El ROI de Esfuerzo es > 1 indica que: Vale la pena la automatización de las pruebas.Tabla 1: Ejemplo ROI de Esfuerzo.Se observa en la tabla 1, que durante las primeras iteraciones el ROI de esfuerzoes inferior a 1, que es el periodo donde se empieza con la capacitación, diseño creacióne instalación de la automatización de pruebas, y que por lo tanto, consume más tiempollevarlo a cabo.Con el transcurso de las iteraciones, el ROI de esfuerzo va creciendo, debido aque el esfuerzo dedicado a la capacitación, ya no existe o es mínimo, el mantenimientose lleva cada cierto periodo, y el desarrollo de las pruebas se vuelve mucho mássencillo, ya que se cuenta con componentes reutilizables que anteriormente ya se handesarrollado.
    • 53Esto indica que el ROI, es un poco lento de obtener en un principio; pero si semantienen constantes, si se sabe llevar a cabo la mejor estrategia de automatización, y sise utilizan las mejores prácticas, valdrá la pena su implementación por todo lo expuestoanteriormente.b. Porcentaje de pruebas automatizables:Esta métrica, ayuda a determinar el porcentaje de pruebas automatizables de unconjunto de casos de prueba propuestos. Esto puede ser representado con la siguienteecuación:Fig. 38: Ecuación de porcentaje de pruebas automatizables.Algo que puede ser considerado como “no automatizable”, por ejemplo, podríaser un área de aplicación que todavía está en fase de diseño, dado a que no es muyestable. En casos como éste, debemos evaluar si tiene sentido automatizar.c. Progreso de automatización:Esta métrica, ayuda a determinar el número de casos de prueba, que han sidoautomatizados en un periodo de tiempo. Básicamente, ¿qué tan bien se está cumpliendoel objetivo de pruebas automatizadas? Esta métrica, es útil para realizar un seguimientodurante las diversas etapas de desarrollo de pruebas automatizadas.Fig. 39: Ecuación de porcentaje de progreso de automatización.
    • 54d. Porcentaje de cobertura de pruebas automatizadas:Esta métrica, ayuda a determinar la cantidad de funcionalidades del productoque se están cubriendo con las pruebas automatizadas.El tamaño de sistema, es calculado en base a la cantidad de líneas de código opuntos por función. Medir el software a través de puntos por función consiste en lacuantificación de la funcionalidad, que se proporciona al usuario basado en el diseñológico y las especificaciones funcionales.Fig. 40: Ecuación de porcentaje de cobertura de pruebas automatizadas.e. Eficiencia de eliminación de errores y/o defectos:Es una de las métricas más populares para el seguimiento de la calidad. Si bienno es específico a la automatización, es muy útil, cuando lo utilizamos junto con losesfuerzos de automatización. Es una métrica, que nos sirve para determinar laefectividad de los esfuerzos de eliminación de errores y/o defectos. Cuanto mayor sea elporcentaje, mayor impacto positivo sobre la calidad del producto.El valor más alto posible de esta métrica es 1, lo que equivale a "100%". En lapráctica se ha encontrado que una clasificación de eficiencia de 100%, no es probable.Si el porcentaje es bajo durante alguna iteración, esto nos indica, que deberíamosemplear más tiempo en actividades, que nos ayuden a reducir la deuda técnica o reducirel número de errores y/o defectos encontrados.Eficiencia de elminación deerrores y/o defectos(%) =Nº de errores y/odefectos encontradosdurante las pruebasEficiencia deEliminación deerrores y/odefectos (%)1000Fuente: Useful Automated Software Testing MetricsFecha: Octubre 2009Nº de errores y/o defectosencontrados durante las pruebas +Nº de errores y/o defectosencontrados después de las pruebasIteración 1 Iteración 2 Iteración ..nFig. 41: Ecuación de eficiencia de eliminación de errores y/o defectos.
    • 55Existen muchos tipos de métricas, lo que hay que tener en cuenta, es que unamétrica, será útil siempre y cuando sea simple, objetiva, medible, significativa y ayude aidentificar áreas de mejora en la automatización de pruebas.Tabla 2: Cuadro comparativo de métricas de tres proyectos diferentes.En la tabla 2, se puede apreciar las métricas de las primeras cinco iteraciones detres proyectos diferentes:El proyecto A, no implementa la automatización de pruebas. La acumulación deerrores y/o defectos se va incrementando gradualmente durante cada iteración. Si bienen las primeras iteraciones, el porcentaje de eficiencia de eliminación de errores y/odefectos es aceptable. Durante el transcurso de las iteraciones, este valor se vareduciendo, logrando que la calidad del sistema se torne inmanejable.El proyecto B, implementa la automatización de pruebas, sin tener en cuenta loscriterios necesarios para su éxito. Durante las primeras iteraciones, los porcentajes deprogreso de automatización, cobertura de pruebas y eficiencia de eliminación de erroresy/o defectos son bastante aceptables; pero durante el transcurso del tiempo, estosvalores se van reduciendo, debido a que las pruebas automatizadas están siendoignoradas, por motivos tales como: escasez de tiempo, falta de una estrategia deautomatización de pruebas adecuada, falta de capacitación en las herramientas, etc. Loque trae como consecuencia que el ROI de Esfuerzo, nunca sea recuperado y por lotanto, se tienda a abandonar este tipo de actividad.El proyecto C, implementa la automatización de pruebas, teniendo en cuenta loscriterios necesarios para llevarlo a cabo con éxito. Durante las primeras iteraciones, losporcentajes de progreso de automatización, cobertura de pruebas y eficiencia deeliminación de errores y/o defectos son altos. Durante el transcurso del tiempo, estosvalores van estabilizándose, debido a que el sistema cada vez aumenta su tamaño. Adiferencia que el proyecto B, la clave está en mantener el porcentaje de progreso deautomatización en un valor entre el 65% y 80%, ya que esto nos permite tener unamayor cobertura de pruebas, y por lo tanto una mejor eficiencia a la hora de detectarerrores y/o defectos. Trabajar continuamente con la implementación de pruebas, nospermitirá trabajar, en otros tipos de pruebas más profundas y finalmente nos permitirárecuperar el ROI de Esfuerzo.
    • 56CAPÍTULO VI: PROFESIONAL DEL ÁREA DE CALIDADEn el capítulo anterior, se ha fundamentado el por qué la automatización depruebas, es una actividad importante para lograr una calidad del software aceptable;pero esto sería imposible, sin las habilidades técnicas, cualidades humanas, el grado deinfluencia y participación de los profesionales del área de calidad durante el proceso dedesarrollo de software.6.1) Aseguramiento y Control de la calidad:Muchas personas y organizaciones están confundidas acerca de la diferenciaentre el “Aseguramiento de la Calidad” (QA – Quality Assurance) y el “Control deCalidad” (QC – Quality Control). Están estrechamente relacionados, pero sonconceptos diferentes. Dado que los dos son necesarios para gestionar eficazmente losriesgos de desarrollo y mantenimiento de software. Es importante entender estasdiferencias.a. Aseguramiento de la Calidad:Las actividades de aseguramiento de calidad (QA), aseguran que el proceso estédefinido y apropiado. Estas actividades:o Proporcionan la confianza adecuada, de que los requisitos están debidamenteestablecidos y los productos o servicios, cumplen con los requisitosespecificados.o Establecen y evalúan los procesos para producir los productos.o Ayudan a establecer los procesos.o Establecen mediciones para evaluar los procesos.o Identifican las debilidades en los procesos y los mejora.o Evitan la introducción de errores y/o defectoso Evalúan si el control de calidad está trabajando con el objetivo principal dedeterminar si existe o no, una debilidad en el proceso.o Mejoran el proceso que se aplica a múltiples productos.Ejemplos de estas actividades son:o Establecer y mantener un sistema de gestión de calidad.o Establecer y mantener metodologías y estándares de desarrollo.o Revisar las políticas de control de cambios, control de errores y control dela configuración.o Controlar documentos y registros.o Realizar auditorias por proyecto.o Establecer acciones correctivas y preventivas.b. Control de Calidad:Las actividades de control de calidad (QC), están diseñadas para evaluar eltrabajo de desarrollo de un producto. Estas actividades:o Comparan la calidad del producto con las normas aplicables, y las medidasadoptadas cuando se detecta una no conformidad.o Verifican si el producto cumple con los estándares predefinidos.o Implementan el proceso.o Verifican si los atributos específicos se encuentran en un determinadoproducto o servicio.
    • 57o Identifican y reportan errores y/o defectos con el objetivo principal decorregirlos.o Mejoran el desarrollo de un producto o servicio específico.Ejemplos de estas actividades son:o Planificar, crear y ejecutar pruebas.o Detectar y reportar defectos y errores.o Documentar procedimientos (manuales de usuarios, manuales de instalación,manuales de despliegue del sistema), procesos y estrategias.o Montar entornos de prueba.o Planificar, crear y ejecutar pruebas automatizadas.o Realizar revisiones de código.o Realizar el seguimiento de tareas y defectos.o Ayudar al cliente especificar requisitos.o Controlar que el software producido, cumple con los requisitos especificadosy con los atributos de calidad impuestos.o Controlar que se utilicen los estándares en uso, que usualmente considerancomo: la reutilización de código, adopción de estándares y estilos deprogramación, etc.o Controlar que se consideren todos los detalles de la instalación y puesta enmarcha del sistema, así como la migración de datos y posibles problemas deeficiencia que empiezan a aparecer.Tanto las actividades de aseguramiento de calidad y control de calidad songeneralmente necesarios para el desarrollo de software con éxito.6.2) Conocimientos y habilidades técnicas:Muchas de las actividades de control de calidad anteriormente nombradasrequieren de conocimientos y habilidades técnicas para que sean desempeñadas deforma adecuada. Entre las más importantes se encuentran las relacionadas con:o Políticas de calidad.o Procesos y metodologías de desarrollo de software.o Captura de requerimientos.o Análisis de Sistemas.o Diseño de pruebas.o Tipos de pruebas.o Procesos de pruebas.o Automatización de pruebas.o Instalación y configuración de ambientes de prueba.o Instalación y configuración de servidores de integración continua.o Métricas de calidad de software.o Programación.o Arquitectura del software.o Funciones y responsabilidades de un profesional en el área de calidad.o Utilización de herramientas de pruebas.A este conjunto de conocimientos y habilidades técnicas se le suman lasrelacionadas con cada tipo de prueba en particular, como por ejemplo las pruebasexploratorias, pruebas de usabilidad, pruebas de performance y carga, pruebas deseguridad y otros tipos de prueba que requieren de un proceso, flujo de trabajo,estrategia y otros conocimientos y habilidades específicos al tema.
    • 58Con respecto a la automatización de pruebas, se requiere de habilidades yconocimientos específicos, como el tipo de sistema con el que vamos a interactuar, lasestrategias, la importancia, los impedimentos y las herramientas de automatización depruebas entre otros; pero si los miembros del equipo de control de calidad, no aplicanestas habilidades y conocimientos con prudencia, pueden conducir al fracaso de laimplementación de pruebas automatizadas, y probablemente, al fracaso del proyecto.En las empresas de desarrollo de software, a menudo los programadoresobtienen una serie de capacitaciones relacionadas a la parte técnica, mientras que losmiembros del equipo de control de calidad, parecen a menudo no recibir la formaciónadecuada. Muchas organizaciones fallan en reconocer que estas personas, tambiénnecesitan capacitación con respecto a las pruebas, a la captura de requisitos, a laautomatización y al resto de las demás habilidades, que son necesarias. Es muyimportante que el equipo de control de calidad, reciba capacitación y entrenamiento,para que puedan adquirir las habilidades y la comprensión que les ayudarán a conduciral proyecto al éxito.6.3) Cualidades humanas, grado de influencia y participación:El principal motivo por el cual, se mantiene al equipo de control de calidadindependiente del equipo de programadores. Es debido, a que si el equipo de control decalidad trabaja muy de cerca con los programadores, van a empezar a pensar como ellosy perder su punto de vista.Si bien es importante tener un rol de control “independiente”, no quiere decir“separado”. Esto puede llevar a la fricción, la competencia y una actitud de "nosotroscontra ellos". Se pierde tiempo en las reuniones duplicadas, en donde el equipo deprogramadores y el equipo de control de calidad, no tienen un objetivo común.Cada miembro del equipo tiene el mismo valor. Si el equipo de control decalidad u otro miembro del equipo se siente excluido, el enfoque de todo el equipo estácondenado al fracaso. Se debe asegurar, que todos los miembros del equipo dedesarrollo, o por lo menos un representante de cada equipo, estén invitados a todas lasreuniones. Todos los miembros del equipo tienen derecho a pedir y obtener ayuda.Fig. 42: Representación de un miembro del equipo frustrado y exitoso.
    • 59La tendencia en un proyecto de software, donde la calidad es muy baja, donde nisiquiera se tiene implementada la automatización de las pruebas unitarias o laintegración continua; es sentirse frustrado rápidamente. La ejecución de pruebasmanuales para el equipo de control de calidad, se tornan engorrosas y repetitivas, sincontar que el progreso de su trabajo no se ve reflejado en el software, ya que cada vezaparecen más errores y defectos que funcionalidades que funcionen adecuadamente.El encargado de control de calidad, debe involucrar a todo el equipo en lasolución de problemas. Debe manifestarse durante cada reunión de retrospectivaproponiendo prácticas, o algún otro tipo de mejora de procesos. Por ejemplo: “Noestamos terminando las tareas de prueba, antes del final de la iteración”. Es un problemapara todo el equipo. Si una de las razones para no terminar, es el elevado número deerrores, se podría sugerir estimar mejor los tiempos de prueba, para realizar laimplementación de la automatización de pruebas. Siempre se debe dejar al resto delequipo, proponer sus propias maneras de abordar el problema. Se debe alentar al equipo,para intentar un nuevo enfoque para unas pocas iteraciones y ver cómo funciona.Es por ello que el encargado de control de calidad debe contar con las siguientescualidades:o Comunicativo.o Persuasivo.o Perfeccionista.o Disciplinado.o Perseverante.o Optimista.o Creativo.o Modesto.o Honesto.o Planificador.o Analítico.o Ordenado.o Comprensivo.o Enérgico.o Entusiasta.o Emprendedor.o Innovador.o De buen carácter.o Fiable.o Responsable.o Decisivo.o Prudente.o Motivador.o Sociable.o Proactivo.
    • 60CONCLUSIÓNCon todo lo expuesto, se puede concluir que, el tiempo, es el único recurso queno se puede recuperar y por ello se debe hacer un uso adecuado del mismo. De nadaservirá invertir esfuerzos en desarrollar nuevas funcionalidades, si éstas no tienencalidad. Para que un producto sea de calidad, se debe darle máxima prioridad al tiempoque se le asigna a las actividades de control de calidad, ya que solo algunas de estasactividades no serán suficientes para cumplir con los objetivos de calidad.La automatización de pruebas, es una de las actividades más importantes decontrol de calidad, ya que además de reducir los tiempos de prueba, permitirá darlemayor importancia a la realización de otros tipos de pruebas más complejas querequieren de la inteligencia humana.Tener la ventaja de contar con una retroalimentación continua, brindada por laautomatización de pruebas, hará visibles los errores y defectos del sistema cuando serealicen cambios, lo que obligará al equipo de desarrollo a trabajar inmediatamente porlas soluciones de los mismos, sin la necesidad de esperar a la integración del códigototal del sistema, impidiendo de esta forma que la acumulación de la deuda técnica delsistema se torne inmanejable.La automatización de pruebas, permite documentar los casos de prueba másimportantes, ya que están implementados de acuerdo a los criterios de aceptacióndefinidos por el cliente. El conjunto de pruebas automatizadas, son parte del productoentregable y pueden ser ejecutados por cualquier persona. Vale la pena aclarar que conesto no se quiere decir, que otro tipo de documentación no sea necesaria.Reducir la acumulación de deuda técnica y los errores y/o defectos del sistema,le permitirá al equipo de desarrollo, disfrutar de su trabajo, debido a que los avances enel proyecto serán notorios y satisfactorios. Podrán encarar el desarrollo de nuevasfuncionalidades más desafiantes, con el tiempo suficiente y con la ventaja de que notendrán que pensar que lo desarrollado en iteraciones anteriores presenta una bajacalidad.Para que las pruebas automatizadas den valor al negocio, es necesario que elencargado de control de calidad que lo lleve a cabo, posea los conocimientos yhabilidades técnicas necesarias. Involucrar a una persona que no cuente con lacapacitación suficiente para este tipo de actividades, implica correr un grave riesgo.El encargado de control de calidad, se presenta como un intermediario entre elequipo del cliente y el equipo de desarrollo. Poseer dos puntos de vista distintos, noimplicará perder el objetivo por el cual el sistema es desarrollado. Conocer el ladoexterno e interno del sistema, le permitirá trabajar con el objetivo de lograr la calidadtotal del sistema y para ello deberá ser partícipe en todo asunto relacionado al sistema.
    • 61La calidad del sistema, es un asunto que les compete a todos los miembros delequipo de desarrollo. El encargado de control de calidad, debe estar involucrado entodos los detalles que lleve a cabo el equipo para poder sugerir mejoras. Es por ello, quees fundamental que éste posea cualidades humanas que busquen mejorar lacomunicación del equipo.Las métricas expuestas en el cuadro comparativo de la tabla 2, permitencorroborar la veracidad de la aplicación de los puntos tratados en este seminario. Lasmétricas arrojadas por la automatización de pruebas, serán muy útiles para el ámbitogerencial, ya que les permitirá determinar, si la calidad interna del sistema es aceptabley además, los ayudará en las tomas de decisiones relacionadas con acciones quebusquen mejorar la calidad del sistema.Finalmente se puede decir, que se ha demostrado como una actividad de controlde calidad, la automatización de pruebas, es un factor clave para alcanzar el éxito y quede no contar con las habilidades técnicas y cualidades humanas de los profesionales delárea de calidad, lograr la calidad del software sería imposible.
    • 62GLOSARIOAPI (Application Programming Interface) - Interfaz de Programación deAplicaciones.ATDD (Acceptance Test Driven Development) - Desarrollo Guiado por Pruebas deAceptación.GUI (Graphic User Interface) - Interfaz Gráfica de Usuario.QA (Quality Assurance) - Aseguramiento de la Calidad.QC (Quality Control) - Control de Calidad.TDD (Test Driven Development) - Desarrollo Guiado por Pruebas.UAT (User Acceptance Tests) - Pruebas de Aceptación de Usuario.
    • 63ANEXO: CURRICULUM VITAEFRANK ESCOBARFecha de Nacimiento XX/XXX/XXXXNacionalidad PeruanaDNI XXXXXEstado Civil XXXXDirección XXXXX # XXXX,Ciudad – Mendoza – ArgentinaCelular (XXXX) XXXXXTeléfono (XXXX) XXXXXE-mail fescobar.systems@gmail.comPerfil Profesional http://ar.linkedin.com/in/fescobarsystemsCUALIDADES• Trabajar en equipo.• Responsable.• Habilidad para comprender rápido, enseñar y trabajar bajo presión.• Organizado, proactivo y orientado hacia los objetivos.• Emprendedor y creativo.EDUCACIÓN FORMAL• Pontificia Universidad Católica Argentina. Mendoza, Argentina.Lic. en Sistemas y Computación (En progreso – Esperado: Mayo 2012)• Pontificia Universidad Católica Argentina. Mendoza, Argentina.Analista de Sistemas (Graduado 2011)• Pontificia Universidad Católica Argentina. Mendoza, Argentina.Téc. en Programación y Operación de Computadoras (Graduado 2009)EDUCACIÓN ADICIONAL• Java Inicial (Duración 30 hs.)• Java Avanzado (Duración 20 hs.)• .Net Intermedio (Duración 30 hs.)• Introducción - Pruebas Exploratorias & Aplicaciones Web (Duración 8 hs.)• Fundamentos SQL sobre Oracle (Duración 20 hs.)• Introducción – Pruebas Unitarias en C# (Duración 8 hs.)HABILIDADES• Tipos de Pruebas:Pruebas Exploratorias.Pruebas de Aceptación de Usuario.Pruebas de Regresión.Pruebas Funcionales: TestLink & Quality Center.Pruebas de Perfomance: JMeter.Pruebas Automatizadas: Selenium (Webdriver, RC, GRID, Flex API) & WatijPruebas Unitarias, Componentes e Integración: JUnit, TestNG, NUnit & MsUnit.• Integración Continua: Hudson/Jenkins.• Métricas: Sonar.• Sistema de Seguimiento de Tareas: Red Mine, Pivotal Tracker & Jira.• Metodologías Ágiles: SCRUM.• Modelos & Standards: CMMI, ISO 9001:2000.
    • 64• Análisis y Diseño de Sistemas: Diagramas UML & Patrones de Diseño.• Lenguajes de Programación:JAVA Intermedio (4 años).NET Básico (1 año)PHP Básico (1 año)• Base de Datos: Oracle, SQL Server, Mongo DB, MySql & Derby.• IDE Java & PHP: NetBeans 7.0 & Eclipse.• IDE .NET: Visual Studio 2008.• Aplicaciones de Escritorio: Java Swing.• Aplicaciones Web Java: JSP, Servlets, JSTL, AJAX, HTML and JAVASCRIPT.• Herramientas de Construcción de Proyectos: Ant & Maven.• Sistemas Operativos:Linux: Ubuntu 10.04Windows: XP, Seven, Server 2003.• Idiomas:Español Nativo.Inglés Pre Intermedio.EXPERIENCIA• GLOBAL LOGIC – Mendoza, ArgentinaDuración: Febrero 2011 – A la actualidado Proyecto de E-CommerceRol: Analista de CalidadTecnologías y Herramientas: Selenium Webdriver 2.0, Selenium Grid, TestNG,Maven, SoapUI, Sonar, Jenkins, Oracle DB.o Proyecto de Sistema de ReportesRol: Analista de CalidadTecnologías y Herramientas: Groovy & Grails, Flex, SQL Server, Json, WebServices, Unit test.o Proyecto de Sistema de Educación Financiera FamiliarRol: Analista de CalidadTecnologías y Herramientas: Java, Hibernate, Spring, Html, Java Script, Json,JUnit, Selenium Grid, JMeter, Sonar, Jenkins.• BELATRIX SOFTWARE FACTORY – Mendoza, ArgentinaDuración: Junio 2010 – Febrero 2011o Proyecto Sistema ComercialRole: Ingeniero de CalidadTecnologías y Herramientas: Gigaspaces, Spring, Json, Fitnesse, Maven, Hudson,JUnit.o Proyecto de Sistemas de Servicios WebRol: Ingeniero de CalidadTecnologías y Herramientas: Java Web & Desktop, MySQL DB, Mongo DB, Json,Fitnesse, RestClient, Maven.o Proyecto de Sistema de Administración EducacionalRol: Ingeniero de CalidadTecnologías y Herramientas: Java Web, Oracle DB, Watij.• HOSPITAL ESPAÑOL – Mendoza, ArgentinaDuración: Marzo 2009 – Agosto 2009o Sistema de Gestión de AnestesiólogosRol: Analista Funcional & Desarrollador JavaTecnologías y Herramientas: Java Desktop, JPA, MySQL, JFreeChart, IReport,JUnit.
    • 65BIBLIOGRAFÍAArpapress, [en línea]. Metodologías Ágiles. Dirección URL:<http://www.arpapress.com/Volumes/Vol1/IJRRAS_1_01.pdf>. [Consulta: 12diciembre 2011].Cohen Mike (2010). Agile Succeeding with Agile - Software Development UsingScrum. Editorial Addison–Wesley.Crispin Lisa & Gregory Janet (2009). Agile Testing - A Practical Guide for Testers andAgile Teams. Editorial Addison–Wesley.Dos Ideas, [en línea]. Reunión diaria de Scrum. Dirección URL:<http://www.dosideas.com/wiki/Reunion_Diaria_De_Scrum>. [Consulta: 20 enero2011].Duvall Paul M. with Matyas Steve & Glover Andrew (2007). Continuous Integration -Improving Software Quality and Reducing Risk. Editorial Addison–Wesley.Garrett Thom, [en línea]. Useful Automated Software Testing Metrics. Dirección URL:<http://www.idtus.com/img/UsefulAutomatedTestingMetrics.pdf>. [Consulta: 25febrero 2012].Jacobson Ivar, Booch Grady, Rumbaugh James (2001). El proceso unificado dedesarrollo software. Rational Software Corporation. Version 2001A.04.00, Copyright1987-2001.Javerianacali, [en línea]. Desarrollo Ágil con Scrum. Dirección URL:<http://cic.javerianacali.edu.co/wiki/lib/exe/fetch.php?media=materias:sg07.p02.scrum.pdf>. [Consulta: 20 enero 2011].JUnit, [en línea]. JUnit Documentation. Dirección URL:<http://kentbeck.github.com/junit/javadoc/latest/>. [Consulta: 15 marzo 2012].Kniberg Henrik (2007). Scrum and XP from The Trenches – How we do Scrum.Editorial InfoQ.com Enterprise Software Development series of books.Maven, [en línea]. Building a Project with Maven. Dirección URL:<http://maven.apache.org/run-maven/index.html>. [Consulta: 18 marzo 2012].Microsoft, [en línea]. Application Archetypes. Dirección URL:<http://msdn.microsoft.com/en-us/library/ee658107.aspx>. [Consulta: 15 febrero 2012].
    • 66BIBLIOGRAFÍAMosaic Inc., [en línea]. Quality Assurance & Quality Control. Dirección URL:<http://www.mosaicinc.com/mosaicinc/rmThisMonth.asp>. [Consulta: 12 marzo 2012].Mountain Goat Software, [en línea]. Scrum. Dirección URL:<http://www.mountaingoatsoftware.com/topics/scrum>. [Consulta: 20 enero 2011].Seleniumhq, [en línea]. Selenium Webdriver. Dirección URL:<http://seleniumhq.org/docs/03_webdriver.html>. [Consulta: 18 marzo 2012].Spanishpmo, [en línea]. Ciclo de viuda del Modelo en Cascada. Dirección URL:<http://spanishpmo.com/index.php/ciclos-de-vida-modelo-de-cascada>. [Consulta: 12diciembre 2011].The Software Experts, [en línea]. Modelo en Cascada. Dirección URL:<http://www.the-software-experts.de/e_dta-sw-process.htm>. [Consulta: 12 diciembre2011].Waterfall Model, [en línea]. Modelo en Cascada. Dirección URL:<http://://www.waterfall-model.com>. [Consulta: 12 diciembre 2011].Wikispaces, [en línea]. Metodología Tradicional. Dirección URL:<http://tallerinf281.wikispaces.com/file/view/METODOLOG%C3%8DAS+TRADICIONALES.pdf>. [Consulta: 12 diciembre 2011].