Camarotta plaverocai
Upcoming SlideShare
Loading in...5
×
 

Camarotta plaverocai

on

  • 436 views

 

Statistics

Views

Total Views
436
Views on SlideShare
436
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

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

Camarotta plaverocai Camarotta plaverocai Document Transcript

  • ´ UNIVERSIDAD DE LA REPUBLICA Facultad de Ingenier´ - Instituto de Computaci´n ıa o Reestructura del Testing Funcional en ASSE e implantaci´n de Automatizaci´n de Pruebas o o Funcionales Informe de Proyecto de Grado presentado al Tribunal Evaluador como requisito de graduaci´n de la carrera Ingenier´ en o ıa Computaci´n o Michel Camarotta Christian Pla Rodolfo Verocai Tutores Ariel Sabiguero & M´nica Wodzislawski o TRIBUNAL Carlos Mart´ ınez Leandro Scasso Jorge Tri˜ anes n Montevideo, Mayo de 2012
  • ii
  • Resumen La Administraci´n de los Servicios de Salud del Estado (ASSE) cuenta con una o variedad de sistemas de software que se corresponden con diversos tipos de dominios, con diferentes niveles de complejidad. Para el desarrollo de los sistemas, ASSE involucra a varios proveedores y funcionarios, generando un ´rea de sisa temas muy heterog´nea mayoritariamente residiendo en la organizaci´n. e o Las necesidad de verificaci´n y validaci´n de los productos sobrepasa la capao o cidad de los recursos disponibles del ´rea de testing. Consecuentemente gran a parte de los desarrollos no pasan por testing y a lo sumo son validados por los usuarios funcionales expertos en el dominio. Existe en ASSE una preocupaci´n por la mejora de la calidad de sus sistemas o y procesos, planteando particular inter´s en la automatizaci´n de pruebas. e o En el contexto del presente proyecto de grado, se estudia la organizaci´n y el o estado del arte en testing funcional, para generar una propuesta metodol´gica o flexible, y que sea practicable en los proyectos de desarrollo de ASSE. La metodolog´ se pone en pr´ctica en un proyecto piloto para observarla y extraer ıa a conclusiones, simulando una reestructura del ´rea de testing de ASSE. a Como trabajos anexos importantes, se presenta un informe de an´lisis y a diagn´stico inicial sobre el estado de la organizaci´n frente al testing funcional; o o y un apartado que supone contextos organizacionales y propone estrategias de c´mo utilizar los procesos propuestos. o Palabras Claves Testing, Testing Funcional, Sistemas de Software, Automatizaci´n de Pruebas, o Procesos de Testing Funcional, Herramientas de Automatizaci´n. o iii
  • iv RESUMEN
  • Agradecimientos Deseamos expresar nuestro agradecimiento a todos aquellos que directa o indirectamente estuvieron involucrados en el desarrollo de este proyecto de grado. Agradecemos al personal de ASSE. Por la direcci´n de ASSE agradecemos a o Paola Su´rez el apoyo brindado. A Carlos Guti´rrez y Fernando Pereira, ina e tegrantes del ´rea de testing de ASSE, quienes colaboraron activamente en el a transcurso del proyecto, brindando su mejor disposici´n. A Marcelo Lemos y o Ariel Sabiguero, quienes colaboraron con la configuraci´n de entornos y herrao mientas necesarias. A los diferentes desarrolladores del ´rea de sistemas, tanto a los funcionarios como los pertenecientes a empresas residiendo en ASSE. Agradecemos tambi´n a nuestros compa˜eros y amigos del Centro de Ensayos de e n Software, quienes siempre se pusieron a las ´rdenes para colaborar con nosotros. o En especial agradecer a nuestro gran amigo y compa˜ero Federico Toledo, por n su constante preocupaci´n, invaluables sugerencias y revisiones de este trabajo. o A la Universidad de la Rep´blica, m´s precisamente a la Facultad de Ingenier´ u a ıa y el Instituto de Computaci´n, por todo el arduo trabajo que desemboca en o nuestra formaci´n en esta carrera por la cu´l hemos generado vocaci´n. o a o A nuestros tutores Ariel Sabiguero y M´nica Wodzislawski, quienes nos apoo yaron y guiaron en el transcurso del proyecto, siempre respetando y valorando nuestras preferencias e ideas a la hora de plasmar el conocimiento. A nuestras familias y amigos, quienes nos apoyaron y entendieron en las diferentes etapas de este proyecto de grado, y en el transcurso en s´ de toda ı nuestra formaci´n acad´mica. En particular a Gustavo, Mary, Florencia, Glac´ o e ı, Fabian, “Los Larvas”, Silvia, Mendex y los diferentes integrantes de “ACME Labs”. v
  • vi AGRADECIMIENTOS
  • ´ Indice general Resumen III Agradecimientos V 1. Introducci´n o 1.1. Contexto y motivaci´n . . . . . . . . . . . . o 1.2. Objetivos . . . . . . . . . . . . . . . . . . . 1.3. Enfoque del Trabajo . . . . . . . . . . . . . 1.4. Aportes del Trabajo . . . . . . . . . . . . . 1.5. Precisi´n de Algunos T´rminos Presentes en o e 1.6. Estructura del documento . . . . . . . . . . . . . . . . 1 1 2 2 3 4 5 2. Estado del arte 2.1. Modelos de Mejora de Procesos de Testing . . . . . . . . . . . . . 2.1.1. TMMi: Testing Maturity Model Integration . . . . . . . . 2.1.2. TPI: Test Process Improvement . . . . . . . . . . . . . . . 2.2. Procesos de Testing Funcional . . . . . . . . . . . . . . . . . . . . 2.2.1. ProTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 2.2.2. Testing Agil . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Incorporaci´n Temprana del Testing . . . . . . . . . . . . . . . . o 2.3.1. Modelo V . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Modelo W . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Estrategias de Testing Funcional Manual . . . . . . . . . . . . . . 2.4.1. Testing Dise˜ado . . . . . . . . . . . . . . . . . . . . . . . n 2.4.2. Testing Exploratorio . . . . . . . . . . . . . . . . . . . . . 2.4.3. Discusi´n: Testing Exploratorio Vs. Testing Dise˜ado. . . o n 2.4.4. Otro enfoque complementario . . . . . . . . . . . . . . . . 2.5. Testing Automatizado . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1. Selecci´n de Casos de Prueba a Automatizar . . . . . . . o 2.5.2. Criterios de Selecci´n de Herramientas de Automatizaci´n o o 2.5.3. Tipos de Herramientas Para Apoyar al Testing . . . . . . 2.5.4. Limitaciones del Testing Automatizado . . . . . . . . . . 2.6. Testeabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1. Concepto de Testeabilidad . . . . . . . . . . . . . . . . . . 7 8 8 12 13 13 16 18 18 20 21 22 22 26 28 32 32 34 37 40 41 42 vii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . el Documento . . . . . . . . . . . . . . . . . . . . .
  • viii ´ INDICE GENERAL 2.6.2. Dise˜ar para la Testeabilidad . . . . . . . . . . . . . n 2.6.3. Dise˜ar para la Testeabilidad de la Automatizaci´n n o 2.6.4. Discusiones sobre Testeabilidad . . . . . . . . . . . . 2.7. Discusi´n: Testing Manual y Automatizado . . . . . . . . . o 2.7.1. Relaci´n entre Testing Manual y Automatizado . . . o 2.8. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 45 45 48 48 50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 51 51 52 52 52 53 53 53 54 54 54 54 54 55 55 55 56 56 56 57 57 58 58 59 4. Framework Instanciable de Testing 4.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.2. Justificaci´n de M´dulos y Procesos . . . . . . . . . . . . . . o o 4.3. FIT M´dulo I . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.3.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. FIT M´dulo II . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.4.1. Etapas del Proceso de Testing Manual . . . . . . . . . 4.4.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. FIT M´dulo III . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.5.1. Etapas de Proceso de Testing Funcional Automatizado 4.5.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Relevancia y profundidad de la documentaci´n . . . . . . . . o 4.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 61 61 65 67 68 68 105 107 108 126 126 127 3. Informe de An´lisis y Diagnostico Inicial a 3.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . . . o 3.2. Actividades desarrolladas . . . . . . . . . . . . . . . . . . 3.2.1. Entrevistas . . . . . . . . . . . . . . . . . . . . . . 3.2.2. An´lisis . . . . . . . . . . . . . . . . . . . . . . . . a 3.3. Diagn´stico . . . . . . . . . . . . . . . . . . . . . . . . . . o 3.3.1. Estado Actual del Testing . . . . . . . . . . . . . . 3.3.2. Control y alcance de las pruebas . . . . . . . . . . ´ 3.3.3. Area de testing . . . . . . . . . . . . . . . . . . . . 3.3.4. Proceso de testing . . . . . . . . . . . . . . . . . . 3.3.5. Procesos de desarrollo . . . . . . . . . . . . . . . . 3.3.6. Especificaci´n y documentaci´n de requerimientos o o 3.3.7. Diversas fuentes de requerimientos . . . . . . . . . 3.3.8. Requerimientos de calidad para tercerizaci´n . . . o 3.3.9. Problemas en el sistema SGS . . . . . . . . . . . . 3.4. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. Control y alcance de las pruebas . . . . . . . . . . ´ 3.4.2. Area de testing . . . . . . . . . . . . . . . . . . . . 3.4.3. Proceso de testing . . . . . . . . . . . . . . . . . . 3.4.4. Procesos de desarrollo . . . . . . . . . . . . . . . . 3.4.5. Especificaci´n y documentaci´n de requerimientos o o 3.4.6. Diversas fuentes de requerimientos . . . . . . . . . 3.4.7. Requerimientos de calidad para tercerizaci´n . . . o 3.4.8. Problemas en el sistema SGS . . . . . . . . . . . . 3.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  • ´ INDICE GENERAL ix 5. Proyecto piloto 5.1. Introducci´n . . . . . . . . . . . . . . . . . . . . o 5.2. Descripci´n de la Metodolog´ adoptada . . . . o ıa 5.3. Propuesta de proyecto piloto . . . . . . . . . . 5.4. Proyectos Candidatos . . . . . . . . . . . . . . 5.5. Proceso de Testing aplicado a Escritorio Cl´ ınico 5.5.1. Introducci´n a la aplicaci´n . . . . . . . o o 5.5.2. Tipo de aplicaci´n . . . . . . . . . . . . o 5.5.3. Contexto de desarrollo . . . . . . . . . . 5.5.4. Proceso de testing . . . . . . . . . . . . 5.5.5. Conclusiones . . . . . . . . . . . . . . . 5.6. Proceso de Testing aplicado a OpenSIH . . . . 5.6.1. Introducci´n a la aplicaci´n . . . . . . . o o 5.6.2. Tipo de aplicaci´n . . . . . . . . . . . . o 5.6.3. Contexto de desarrollo . . . . . . . . . . 5.6.4. Proceso de testing . . . . . . . . . . . . 5.6.5. Conclusiones . . . . . . . . . . . . . . . 5.7. Cuestionario para los Integrantes de ASSE . . . 5.7.1. Respuestas de Carlos Guti´rrez . . . . . e 5.7.2. Respuestas de Fernando Pereira . . . . . 5.8. Herramientas de Automatizaci´n de Pruebas . o 5.9. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 129 129 131 131 133 133 133 133 135 137 137 137 138 138 139 141 142 142 143 144 147 6. Conclusiones 6.1. Conclusiones del diagn´stico actual o 6.2. Conclusiones generales del proyecto 6.3. Trabajo a futuro . . . . . . . . . . 6.4. Conclusiones generales del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 149 149 150 150 . . . . piloto . . . . . . . . . . . . . . . . . . . . A. Sistema de Seguimiento de Incidentes B. Instrumentaci´n de la Metodolog´ o ıa B.1. Criterios para clasificar los contextos . . . . . . . . . B.1.1. Frecuencia de liberaciones . . . . . . . . . . . B.1.2. Proceso seguido por desarrollo . . . . . . . . B.1.3. Necesidad de evidencia de pruebas . . . . . . B.1.4. Complejidad del SUT . . . . . . . . . . . . . B.1.5. Criticidad del SUT . . . . . . . . . . . . . . . B.1.6. Conocimiento Previo del Dominio . . . . . . B.1.7. Complejidad del Dominio . . . . . . . . . . . B.1.8. Plazos establecidos externamente . . . . . . . ´ B.2. Testing Agil . . . . . . . . . . . . . . . . . . . . . . . B.2.1. Estrategia . . . . . . . . . . . . . . . . . . . . B.2.2. Instanciaci´n de FIT . . . . . . . . . . . . . . o B.2.3. Representaci´n gr´fica del roadmap . . . . . o a B.3. Testing Independiente con Interrelaci´n con Equipos o 153 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 156 156 156 156 157 157 157 158 158 158 159 160 160 172
  • ´ INDICE GENERAL x B.3.1. Estrategia . . . . . . . . . . . . . . . . . . . . . . . . B.3.2. Instanciaci´n de FIT . . . . . . . . . . . . . . . . . . o B.3.3. Representaci´n gr´fica . . . . . . . . . . . . . . . . . o a B.4. Desarrollo en Cascada con proceso r´ ıgido auditable . . . . . B.4.1. Estrategia . . . . . . . . . . . . . . . . . . . . . . . . B.4.2. Instanciaci´n de FIT . . . . . . . . . . . . . . . . . . o B.5. Testing Independiente a modo de Testing Factory . . . . . . B.5.1. Estrategia . . . . . . . . . . . . . . . . . . . . . . . . B.5.2. Instanciaci´n de FIT . . . . . . . . . . . . . . . . . . o B.6. Testing en Organizaci´n preocupada por la Mejora continua o B.6.1. Estrategia . . . . . . . . . . . . . . . . . . . . . . . . B.6.2. Instanciaci´n de FIT . . . . . . . . . . . . . . . . . . o Glosario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 173 173 184 185 185 185 186 187 188 189 189 191
  • ´ Indice de figuras 2.1. 2.2. 2.3. 2.4. 2.5. Etapas de ProTest . . . . . . . . . . . . . . . . . . . . . . . . Modelo V simplificado. . . . . . . . . . . . . . . . . . . . . . . Posible caso del Modelo W. . . . . . . . . . . . . . . . . . . . Ejemplo de hoja de reporte de sesi´n de testing exploratorio. o Modelo V y los diferentes tipos de herramientas relacionadas. . . . . . . . . . . 14 18 21 25 38 4.1. FIT con sus m´dulos. . . . . . . . . . . . . . . . . . . . . . . o 4.2. FIT con sus m´dulos y representaci´n gr´fica del roadmap. . o o a 4.3. FIT M´dulo II: Proceso de Testing Funcional Manual . . . . o 4.4. Etapa Planificaci´n Inicial . . . . . . . . . . . . . . . . . . . . o 4.5. Etapa An´lisis de Requerimientos . . . . . . . . . . . . . . . . a 4.6. Etapa Dise˜o de Pruebas del Testing Planificado . . . . . . . n 4.7. Etapa Dise˜o de Pruebas del Testing Exploratorio . . . . . . n 4.8. Etapa Alcance y An´lisis de Riesgo . . . . . . . . . . . . . . . a 4.9. Etapa Preparaci´n de Ejecuci´n . . . . . . . . . . . . . . . . . o o 4.10. Etapa Ejecuci´n de Pruebas . . . . . . . . . . . . . . . . . . . o 4.11. Etapa Seguir y Actualizar el Plan . . . . . . . . . . . . . . . . 4.12. Etapa Informar Resultados . . . . . . . . . . . . . . . . . . . 4.13. Etapa Verificaci´n de Documentos . . . . . . . . . . . . . . . o 4.14. Etapa An´lisis de Defectos . . . . . . . . . . . . . . . . . . . . a 4.15. FIT M´dulo III: Proceso de Testing Funcional Automatizado o 4.16. Etapa Seleccionar Herramientas . . . . . . . . . . . . . . . . . 4.17. Etapa Preparaci´n de Automatizaci´n . . . . . . . . . . . . . o o 4.18. Etapa Implementaci´n de Prueba Automatizada . . . . . . . o 4.19. Etapa Ejecuci´n de Pruebas Automatizadas . . . . . . . . . . o 4.20. Etapa Mantenimiento de Testware de Automatizaci´n . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 64 69 73 80 84 85 87 90 93 96 98 101 103 109 112 116 119 121 124 . . . . . . . . . . . . . . 159 161 162 163 163 164 164 B.1. B.2. B.3. B.4. B.5. B.6. B.7. Contexto de organizaci´n que adopta una metodolog´ Agil. o ıa ´ ´ Proceso de Testing Funcional Manual para Testing Agil . . ´ Etapa Planificaci´n Inicial para Testing Agil . . . . . . . . . o ´ Etapa An´lisis de Requerimientos para Testing Agil . . . . a ´ Etapa Dise˜o del Testing Exploratorio para Testing Agil . . n ´ Etapa Dise˜o del Testing Planificado para Testing Agil . . . n ´ Etapa Preparaci´n de Ejecuci´n para Testing Agil . . . . . o o xi . . . . . . .
  • xii ´ INDICE DE FIGURAS ´ B.8. Etapa Ejecuci´n de Pruebas para Testing Agil . . . . . . . . . . . 165 o ´ B.9. Etapa Alcance y An´lisis de Riesgo para Testing Agil . . . . . . 165 a ´ B.10.Etapa Informar Resultados para Testing Agil . . . . . . . . . . . 166 ´ B.11.Etapa Seguir y Actualizar el Plan para Testing Agil . . . . . . . 166 ´ B.12.Etapa An´lisis de Defectos para Testing Agil . . . . . . . . . . . 167 a ´ B.13.Proceso de Testing Funcional Automatizado para Testing Agil . . 168 ´ B.14.Etapa Seleccionar Herramientas para Testing Agil . . . . . . . . 169 ´ B.15.Etapa Preparaci´n de Automatizaci´n para Testing Agil . . . . . 170 o o ´ B.16.Etapa Implementaci´n de Automatizaci´n para Testing Agil . . . 170 o o ´ B.17.Etapa Ejecuci´n de Pruebas Automatizadas para Testing Agil . . 171 o ´ B.18.Etapa Mantenimiento de Testware para Testing Agil . . . . . . . 171 B.19.Contexto de organizaci´n con Testing Independiente integrado. . 172 o B.20.Proceso de Testing Funcional Manual para Testing Independiente 174 B.21.Etapa Planificaci´n Inicial para Testing Independiente . . . . . . 175 o B.22.Etapa An´lisis de Requerimientos para Testing Independiente . . 176 a B.23.Etapa Dise˜o del Testing Exploratorio para Testing Independiente176 n B.24.Etapa Dise˜o del Testing Planificado para Testing Independiente 176 n B.25.Etapa Preparaci´n de Ejecuci´n para Testing Independiente . . . 177 o o B.26.Etapa Ejecuci´n de Pruebas para Testing Independiente . . . . . 177 o B.27.Etapa Alcance y An´lisis de Riesgo para Testing Independiente . 178 a B.28.Etapa Informar Resultados para Testing Independiente . . . . . . 178 B.29.Etapa Seguir y Actualizar el Plan para Testing Independiente . . 179 B.30.Etapa Verificaci´n de Documentos para Testing Independiente . 179 o ´ B.31.Proceso de Testing Funcional Automatizado para Testing Agil . . 180 ´ B.32.Etapa Seleccionar Herramientas para Testing Agil . . . . . . . . 181 B.33.Etapa Preparar Automatizaci´n para Testing Independiente . . . 182 o B.34.Etapa Implementar Automatizaci´n para Testing Independiente . 182 o B.35.Etapa Ejecuci´n de Automatizaci´n para Testing Independiente . 183 o o B.36.Etapa Mantenimiento de Testware para Testing Independiente . 183 B.37.Contexto de organizaci´n que usa desarrollo en Cascada. . . . . . 184 o B.38.Contexto de organizaci´n interactuando con una Testing Factory. 186 o B.39.Contexto de organizaci´n preocupada por la Mejora Continua. . 188 o
  • ´ Indice de cuadros 2.1. Ejemplo de retorno de la inversi´n de pruebas automatizadas. . . o 4.1. Documentos del Proceso de Testing Funcional Manual. . . . . 4.2. Roles en el Proceso de Testing Funcional Manual. . . . . . . . 4.3. Etapa de Planificaci´n Inicial . . . . . . . . . . . . . . . . . . o 4.4. Etapa de An´lisis de Requerimientos . . . . . . . . . . . . . . a 4.5. Etapa Dise˜o de Pruebas . . . . . . . . . . . . . . . . . . . . n 4.6. Etapa Alcance y An´lisis de Riesgo . . . . . . . . . . . . . . . a 4.7. Etapa Preparaci´n de Ejecuci´n . . . . . . . . . . . . . . . . . o o 4.8. Etapa Documentaci´n de Ejecuci´n . . . . . . . . . . . . . . . o o 4.9. Etapa Seguir y Actualizar el Plan . . . . . . . . . . . . . . . . 4.10. Etapa Comunicar Avances y Obst´culos . . . . . . . . . . . . a 4.11. Etapa Verificaci´n de Documentos . . . . . . . . . . . . . . . o 4.12. Etapa An´lisis de Defectos . . . . . . . . . . . . . . . . . . . . a 4.13. Documentos del Proceso de Testing Funcional Automatizado. 4.14. Etapa Seleccionar Herramientas . . . . . . . . . . . . . . . . . 4.15. Etapa Preparaci´n de Automatizaci´n . . . . . . . . . . . . . o o 4.16. Etapa Implementaci´n de Pruebas Automatizadas . . . . . . o 4.17. Etapa Ejecuci´n de Pruebas Automatizadas . . . . . . . . . . o 4.18. Etapa Mantenimiento de Testware de Automatizaci´n . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 70 71 72 79 84 87 90 92 96 98 101 103 110 111 116 119 122 124 5.1. Sistemas candidatos a incluirse en el Proyecto Piloto. . . . . . . . 132 5.2. Comparaci´n de herramientas de automatizaci´n de pruebas . . . 146 o o xiii
  • xiv ´ INDICE DE CUADROS
  • Cap´ ıtulo 1 Introducci´n o En este cap´ ıtulo se introduce y motiva el trabajo, se plantean objetivos y se describe el enfoque adoptado. Se hace adem´s menci´n a los aportes del trabajo, a o los t´rminos utilizados, y la forma en que esta organizado el documento. e 1.1. Contexto y motivaci´n o La Administraci´n de Servicios de Salud del Estado (en adelante ASSE), basa o su pr´ctica del testing de software en expertos funcionales que ejecutan pruebas a manuales y de forma ad hoc, ante solicitudes de cambio, nuevas funcionalidades y reparaci´n de incidentes. El conocimiento adquirido en el proceso de verificao ci´n se pierde cuando el equipo se encarga del testing de nuevas tareas. o Inicialmente ASSE manifiesta el inter´s de mejorar la metodolog´ de testing e ıa funcional e incorporar el uso de herramientas de automatizaci´n de pruebas o funcionales. Los estudiantes que integramos este proyecto de grado, hemos trabajado en diversos proyectos dentro del Centro de Ensayos de Software (CES) [CES10], en diferentes actividades dentro del testing y por lo tanto consideramos apropiado abordar esta propuesta de proyecto de grado. Muchos de los conceptos presentados fueron madurados y desarrollados en varios contextos de trabajo en la industria. 1
  • ´ CAP´ ITULO 1. INTRODUCCION 2 1.2. Objetivos Entre los objetivos fundamentales del proyecto se encuentran: Estudio del estado del arte de los procesos de testing y modelos de mejora de procesos de testing. Estudio del estado del arte en automatizaci´n de testing funcional. o Investigaci´n de herramientas para apoyar la automatizaci´n de testing o o funcional acordes a la plataforma de ASSE. Propuesta metodol´gica en base a la situaci´n inicial de ASSE o o Seguimiento de la metodolog´ propuesta para incorporar testing manual ıa y automatizado en un proyecto piloto. El proyecto busca sentar las bases tecnol´gicas para contar con una ejecuci´n o o autom´tica de test de conformidad de componentes centrales de la plataforma a de ASSE. Uno de los objetivos centrales del proyecto, es prototipar testing automatizado en alguno de los sistemas relevantes de la organizaci´n. o Resultados alcanzados: Estudio del estado del arte en testing funcional. Propuesta de la nueva metodolog´ de trabajo. ıa Implementaci´n de la propuesta de trabajo en un proyecto piloto. o Informe de an´lisis y diagnostico inicial del estado de la organizaci´n frente a o al testing, incluyendo sugerencias de acciones a tomar. Selecci´n de herramienta e implementaci´n de casos de prueba testigos. o o An´lisis de caracter´ a ısticas de desarrollo que simplifiquen el testing. 1.3. Enfoque del Trabajo Este trabajo es una investigaci´n general en el ´rea del testing de software. o a Est´ nutrido de diversas fuentes que van desde los libros cl´sicos en el ´rea, a a a hasta los trabajos y tendencias m´s actuales en cuanto a procesos, metodoa log´ mejoras de proceso, buenas pr´cticas y otras producciones1 de autores ıas, a relevantes. La meta perseguida es la aplicaci´n del marco de trabajo propuesto o partiendo de un contexto real inicial de la organizaci´n, y transitar hacia un o 1 Estas producciones referidas, son las que est´n presentes en medios digitales como lo son a blogs y foros.
  • 1.4. APORTES DEL TRABAJO 3 estado donde es posible implantar testing funcional manual y automatizado. La propuesta metodol´gica deber´ entenderse en el contexto de la realidad de o a la organizaci´n de estudio (ASSE), pero se busca que sea lo suficiente flexible o como para que aplique a otras realidades. Dejamos abierta la posibilidad de mejorar la metodolog´ y trabajar a futuro para lograr otros tipos de testing, ıa, mejorando el proceso de testing de la organizaci´n. o 1.4. Aportes del Trabajo Entre los resultados que consideramos aportes, queremos destacar el enfoque adoptado, el marco de trabajo elaborado (al que llamaremos framework instanciable de testing, o simplemente por su sigla FIT ) y el valor agregado de entrenamiento en testing de los integrantes de ASSE. La elaboraci´n del marco de trabajo apunta a construir un producto flexible, o adaptable, y de uso pr´ctico, poniendo el foco en las particularidades del contexa to. En el estudio del estado del arte, adem´s de las fuentes b´sicas, se investigan a a las nuevas tendencias del testing relacionadas con el manejo de realidades cambiantes. El framework definido organiza los conceptos que formar´n parte de la configua raci´n o instanciaci´n particular para cada contexto. La flexibilidad necesaria o o para adaptarse a un proyecto dado se encuentra en la posibilidad de marcar un camino entre las etapas y actividades de la propuesta, incluso incorporando pr´cticas avanzadas de testing de software y automatizaci´n de pruebas. a o Seguir las actividades propuestas en el contexto de un proyecto, colabora al entrenamiento de los integrantes del ´rea de testing de la organizaci´n, en la a o disciplina del testing. Este marco metodol´gico esta dise˜ado para que apoye la o n maduraci´n del ´rea de calidad de ASSE en torno al testing funcional y conseo a cuentemente sus integrantes se encuentren en mejores condiciones de seguir un proceso de testing m´s completo, como lo es por ejemplo ProTest [P´r06]. a e La propuesta es implementada en ASSE en un proyecto piloto, comprobando su aplicabilidad en un contexto de la industria nacional.
  • ´ CAP´ ITULO 1. INTRODUCCION 4 1.5. Precisi´n de Algunos T´rminos Presentes o e en el Documento En este apartado, pretendemos justificar el uso de ciertos t´rminos, que pueden e necesitar aclaraci´n en cuanto al significado en este trabajo, y su uso se deriva o de la jerga cotidiana en la tem´tica tratada por este informe. Muchos de estos a t´rminos, no corresponden al idioma espa˜ol, o no est´n reconocidos oficialmente e n a por la Real Academia Espa˜ola2 , por lo tanto es conveniente precisar la intenn ci´n y significado al utilizarlos en este trabajo. La definici´n de cada t´rmino o o e debe ser entendida en el contexto de este trabajo, esto es, qu´ significa (para los e autores de este informe) el t´rmino al ser utilizado, m´s all´ de m´ ltiples otras e a a u acepciones que pueda tener. Estos y otros t´rminos est´n especificados adem´s e a a en el glosario, al final de este documento. Como en otras disciplinas en el ´rea de inform´tica, muchos t´rminos son exa a e tra´ ıdos del idioma ingl´s, y adem´s, algunos no poseen una traducci´n biun´ e a o ıvoca en el idioma espa˜ol, cayendo muchas veces en ambig¨edades, o perdiendo signin u ficado al traducirse. Este es el caso del t´rmino testing, que proviene del verbo en e ingl´s to-test que se puede traducir como probar. Probar, en idioma espa˜ ol, tiee n ne un significado ambiguo, y puede entenderse como demostrar. A menos que se haga una demostraci´n formal, o una prueba exhaustiva, no podemos demostrar o que el software no contiene defectos. Dada la complejidad del software, es poco probable que se pueda realizar una prueba formal, y las pruebas exhaustivas son pr´cticamente imposibles3 . La Real Academia Espa˜ ola define test como a n una “Prueba destinada a evaluar conocimientos o aptitudes, en la cual hay que elegir la respuesta correcta entre varias opciones previamente fijadas” y como “Prueba psicol´gica para estudiar alguna funci´n”; en el presente trabajo no se o o utilizar´ el t´rmino test de ninguna de estas dos formas. a e El significado de testing se manejar´ en el documento para referirse a la activia dad, o el conjunto de actividades involucradas en ensayar diferentes componentes de un sistema con la intenci´n de encontrar defectos [Mye04a]. Se encontrar´ en o a el documento tambi´n acompa˜ado del art´ e n ıculo “el” para referirse tambi´n a lo e mencionado como testing. De todas formas se utilizar´ en ocasiones el t´rmino prueba, indistintamente paa e ra referirse a la acci´n de probar, o a un caso de prueba; y nunca se utilizar´ en o a su acepci´n de demostrar. Para referirnos a un caso de prueba se podr´ ver el uso o a del termino “test”, o “tests” en plural. En plural, se encontrar´ en el documento a tambi´n el t´rmino pruebas, para referirse a un determinado conjunto de casos e e de prueba, y en ocasiones para referirnos a alg´n subconjunto de actividades u durante el transcurso del proyecto de verificaci´n (por ejemplo, podr´ usarse o ıa “durante las pruebas...” para hablar de actividades que ocurren en el proyec2 Ver http://rae.es. en la secci´n 2.7.1 o 3 Discusi´n o
  • 1.6. ESTRUCTURA DEL DOCUMENTO 5 to de testing). A las pruebas, tambi´n se les tratar´ como “testing” o “el testing”. e a Para referirnos a la persona que toma algunos de los roles espec´ ıficos de las actividades de testing, utilizaremos tester, y testers, cuando es en plural. De lo contrario, tendr´ ıamos que referirnos a estas personas como “probadores” o quiz´ “verificadores y validadores”, y no son, a nuestro entender, los t´rminos a e m´s comunes en las organizaciones actualmente. a 1.6. Estructura del documento El documento esta organizado en cap´ ıtulos y ap´ndices. Al inicio encontrara e un resumen del trabajo, y a continuaci´n, el cap´ o ıtulo 1, que es la introducci´n o al trabajo y a este informe. Luego en el cap´ ıtulo 2, se encuentra el estado del arte en testing funcional manual y automatizado, el cu´l trata desde temas m´s a a generales, como modelos de madurez de procesos de testing, hasta temas m´s a espec´ ıficos en amplitud, como ser procesos de testing, estrategias, y otros. El informe prosigue en el cap´ ıtulo 3, que es una rese˜a del estudio de la organizaci´n n o a modo de diagn´stico inicial de ASSE frente al testing funcional (presentando o adem´s algunas recomendaciones). En el cap´ a ıtulo 4 se encuentra la propuesta metodol´gica y contin´a con la documentaci´n de la experiencia piloto llevada o u o adelante en ASSE en el cap´ ıtulo 5. El ultimo cap´ ´ ıtulo es el 6 que resume el documento y discute alternativas de trabajo a futuro. Como anexos al informe se encuentran el ap´ndice A con comentarios acerca de e las caracter´ ısticas deseables de una herramienta de seguimiento de incidentes, y el ap´ndice B con ejemplos de instrumentaci´n de la metodolog´ en diferentes e o ıa supuestos de contextos organizacionales. Al final del documento se encuentran el glosario, conteniendo t´rminos relevantes al trabajo, y un apartado con e referencias bibliogr´ficas. a
  • 6 ´ CAP´ ITULO 1. INTRODUCCION
  • Cap´ ıtulo 2 Estado del arte “Lo que sabemos es una gota de agua; lo que ignoramos es el oc´ano” e Isaac Newton Este cap´ ıtulo presenta el estudio de los temas del testing de software que consideramos relevantes a la elaboraci´n de una propuesta acorde a los requisitos o del proyecto. Se define un conjunto de conceptos relevantes para el contexto bajo estudio, y a partir de all´ se selecciona, en base a nuestra experiencia, el ı, material m´s apropiado de las fuentes para cada concepto. Los temas tratados a en las primeras secciones son amplios y conforme avanza el cap´ ıtulo, se abarcan temas m´s espec´ a ıficos; ya sobre el final, se abordan los temas m´s transversales. a En la secci´n 2.1 presentamos una rese˜a sobre los m´s relevantes modelos de o n a mejora de procesos de testing de software. Luego en la secci´n 2.2 indagamos o en procesos de testing de software. Proseguimos adentr´ndonos en temas a m´s particulares en la secci´n 2.3, donde se estudian algunos modelos de a o incorporaci´n temprana del testing en el proceso de desarrollo de software. La o secci´n 2.4 trata de las estrategias del testing funcional, destacando los enfoques o m´s importantes; mientras que la secci´n 2.5 cita los puntos m´s importantes a o a en cuanto a la automatizaci´n de testing. Para finalizar, presentamos un o informe sobre testeabilidad en la secci´n 2.6 y una discusi´n en la secci´n 2.7 o o o contrastando el testing manual con el automatizado. 7
  • CAP´ ITULO 2. ESTADO DEL ARTE 8 2.1. Modelos de Mejora de Procesos de Testing Los temas tratados en este cap´ ıtulo se abordan con un enfoque descendente, por lo tanto iniciamos con una rese˜a a los modelos de mejora de procesos de n testing, por ser el tema m´s amplio. a Un modelo de mejora de procesos, provee de cierta categorizaci´n y descripci´n o o de puntos clave sobre los cuales se debe trabajar para conseguir la mejora en la manera que recomienda el modelo. Generalmente est´n dise˜ ados para que a n una autoridad certificadora pueda evaluar si una organizaci´n cumple con los o puntos marcados por el modelo y a qu´ nivel, para posteriormente considerar a e la organizaci´n en cierto nivel o determinada etapa seg´n el modelo y otorgarle o u una certificaci´n. Estos modelos son populares en al disciplina de desarrollo de o software, y como consecuencia del avance del ´rea del testing de software, surgen a entonces los modelos para mejoras de procesos de testing. 2.1.1. TMMi: Testing Maturity Model Integration El TMMi [Fou11] es un modelo detallado de mejora del proceso de testing, que nace como complemento del CMMi [Kne08] (CMMi es usado muchas veces en la industria como modelo est´ndar de mejora de los procesos de desaa rrollo de software). TMMi define una jerarqu´ de cinco niveles (al igual que ıa CMMi), que van desde una etapa con pr´cticas b´sicas y no gestionadas de a a testing, hasta una etapa con testing gestionado, definido, medido y optimizado. Los niveles definidos por TMMi y sus respectivas ´reas de proceso son: a Nivel 1: Inicial Nivel 2: Gestionado • Pol´ ıtica de Testing y Estrategia • Plan de Testing • Seguimiento y Control de Testing • Dise˜o y Ejecuci´n de Pruebas n o • Ambiente de Testing Nivel 3: Definido • Organizaci´n de las Pruebas o • Programa de entrenamiento • Ciclo de vida del Testing e Integraci´n o • Testing no-Funcional • Revisi´n por pares o Nivel 4: Medido
  • 2.1. MODELOS DE MEJORA DE PROCESOS DE TESTING 9 • M´tricas de testing e • Evaluaci´n de la calidad del software o • Revisi´n por pares avanzada o Nivel 5: Optimizado • Prevenci´n de defectos o • Optimizaci´n del proceso de testing o • Control de calidad Nivel 1: Inicial En este nivel, el testing es ca´tico, no existen procesos definidos y no se jeo rarquiza la actividad de testing (por ejemplo, las organizaciones en este nivel, suelen confundir testing con depuraci´n de c´digo). Los casos de ´xito a esta o o e altura suelen asociarse a actos notables de integrantes de la organizaci´n y no o al resultado de la aplicaci´n de un proceso, por lo cual, la situaci´n de ´xito no o o e es repetible. La aspiraci´n de calidad m´s com´n en las organizaciones en nivel inicial de o a u TMMi es lograr liberar productos que puedan funcionar sin errores de gravedad alta. Generalmente los productos, no cubren las expectativas de calidad ya sea en rendimiento, estabilidad, disponibilidad, pobreza y ausencia de funcionalidades, nivel de incidentes remanentes, entre otros. Es com´n que las organizaciones en este nivel, no dediquen recursos a crear u departamentos de pruebas, entornos o ambientes dedicados a pruebas, as´ como ı herramientas, o personal capacitado (incluida la falta de entrenamiento). Nivel 2: Gestionado Para el nivel dos de TMMi, el testing es un proceso gestionado y diferenciado de las actividades de depuraci´n de c´digo. En las organizaciones que adoptan o o la disciplina del nivel dos, se suele ver que se mantienen las pr´cticas a´ n en a u momentos de presi´n y estr´s. De todas formas, el testing sigue siendo percibido o e por los interesados (o “stakeholders”) como una etapa posterior a la implementaci´n. o Se cuenta con requerimientos escritos y se construyen planes de testing describiendo las actividades de testing, c´mo ser´n llevadas a cabo y por qui´n. El o a e plan de testing incluye el enfoque adoptado y an´lisis de riesgo. Es com´ n utia u lizar t´cnicas para la gesti´n del riesgo, dise˜o y selecci´n de casos de prueba e o n o en base a los requerimientos documentados. El testing se aplica a varias etapas, como ser pruebas de integraci´n, de sistemas, de componentes y aceptaci´n. Las o o actividades de control y seguimiento del testing est´n presentes en este nivel, a
  • 10 CAP´ ITULO 2. ESTADO DEL ARTE pudi´ndose aplicar medidas correctivas al enfrentar desviaciones. e El objetivo del testing es verificar que el producto cumple con sus requerimientos, por lo cual, es com´n que los defectos en los requerimientos se propaguen u al sistema, a medida que el testing se incluye en etapas tard´ en el ciclo de ıas vida del desarrollo. Nivel 3: Definido En el nivel tres de TMMi, el testing deja de ser considerado como una etapa posterior a la implementaci´n y pasa a estar integrado totalmente en el proceso o de desarrollo. Existe planificaci´n temprana de testing, y se considera la profesi´n de Tester. o o Las revisiones formales son valoradas, y los testers muchas veces son incluidos en la especificaci´n de los requerimientos, permitiendo que se puedan prestar o atenci´n adem´s a requerimientos no funcionales como la usabilidad, confiabilio a dad, entre otros. El nivel tres de TMMi es una refinaci´n de las ´reas de proceso del nivel dos, o a donde adem´s los procesos, conjunto de est´ndares de testing, y procedimientos a a son definidos con mayor rigurosidad. Aplicar ´reas de proceso del nivel tres a a un proyecto particular, involucra tomar del conjunto de est´ndares de la orgaa nizaci´n los que mejor apliquen al contexto dado. o Nivel 4: Medido El nivel cuatro implica que el proceso de testing es cuidadosamente definido, bien fundado y medible. Se considera al testing como una evaluaci´n, concerniente a o todas las actividades del desarrollo del producto y sistemas en funcionamiento relacionados. Se incorporan m´tricas para controlar y evaluar el rendimiento del proceso de e testing. La calidad del producto es definida en t´rminos de atributos medibles e cuantitativamente, identificando las necesidades de calidad y las m´tricas a utie lizar. Las revisiones e inspecciones cobran importancia y son consideradas como parte del proceso de testing, sobre todo las revisiones por pares. Adem´s, se utilizan a para medir la calidad del producto, con criterios cuantitativos de aspectos como confiabilidad, usabilidad y mantenibilidad; as´ como tambi´n como apoyo a la ı e construcci´n de los planes de testing, establecimiento de la estrategia y enfoque o del testing.
  • 2.1. MODELOS DE MEJORA DE PROCESOS DE TESTING 11 Nivel 5: Optimizado El nivel cinco de TMMi tiene como objetivos la prevenci´n de defectos y la meo jora continua. Consta de tres ´reas de proceso fuertemente relacionadas: control a de calidad, prevenci´n de defectos, y mejora del proceso de testing. o Al alcanzar todos los niveles previos, la organizaci´n se supone que cuenta con o un proceso de testing, medible y definido, y con una s´lida infraestructura orgao nizacional que apoya al testing. La organizaci´n es capaz de mejorar su proceso o de testing, incorporando mejoras incrementales en tecnolog´ innovaci´n, nueıa, o vas herramientas, y metodolog´ El foco est´ en el ajuste continuo y mejora ıas. a del proceso con apoyo de herramientas, evaluando la reutilizaci´n de la docuo mentaci´n generadas en las pruebas, y derivando nuevos ajustes al proceso. o La prevenci´n de defectos juega un papel fundamental identificando y anao lizando causas comunes, para establecer acciones que prevengan defectos similares que puedan ocurrir. Parte de la prevenci´n de defectos tamo bi´n es el an´lisis de algunos resultados del proceso de control de calie a dad, evaluando el rendimiento del proceso y encaminando acciones correctivas para el futuro. El proceso de testing es gestionado de forma est´tia ca por medio del ´rea de proceso de control de calidad, mediante media ciones cuantitativas de aspectos como nivel de confianza y confiabilidad. En el nivel 5 de TMMi se espera que el proceso de testing: Sea gestionado, definido, medido, eficiente y efectivo. Sea controlado est´ticamente y predecible. a Tenga foco en prevenci´n de defectos. o Sea apoyado por automatizaci´n siempre y cuando se de un uso efectivo o de los recursos. Contribuya a la transferencia de tecnolog´ desde la industria a la ıa organizaci´n. o Facilite la reutilizaci´n del testing. o Est´ enfocado en cambios de proceso para lograr la mejora continua. e Resumen TMMi es consecuencia del seguimiento de las pr´cticas de CMMi y como ´ste, a e cuenta con niveles de madurez. Las recomendaciones de los niveles de TMMi son amplias (desde planificaci´n, dise˜o y ejecuci´n de pruebas; hasta revisiones o n o y prevenci´n de defectos) y son referidas en diferentes procesos. Un posible o contexto de aplicaci´n de TMMi, ser´ una empresa que est´ certificada en o ıa e alg´n nivel de CMMi y se interese por mejorar sus procesos de testing. Esto u
  • CAP´ ITULO 2. ESTADO DEL ARTE 12 puede resultar muy costoso para peque˜as empresas que quieran incorporar o n mejorar sus actividades de testing, y por lo tanto no es el caso m´s com´ n. a u 2.1.2. TPI: Test Process Improvement El modelo de mejora de procesos de testing, TPI [Sog09] es derivado de la experiencia de la aplicaci´n del proceso de testing TMap [vdABR+ 08] de la empresa o SOGETI, definiendo pasos de mejora incrementales y controlables. Abarca diferentes aspectos del proceso de testing desde el uso de herramientas, t´cnicas de e dise˜o de casos de prueba as´ como aspectos de comunicaci´n y gesti´n, entre n ı o o otros. A estos aspectos se les denomina ´reas clave. a Las ´reas clave a TPI se basa en 20 ´reas clave, y diferentes niveles para cada ´rea. Se pasa de a a un nivel A a un nivel B, de un B a un C, a mayor eficiencia y efectividad en esa ´rea. El nivel superior representa que se alcanz´ la madurez requerida para a o el nivel actual y todos los niveles inferiores. Para cada ´rea clave se establecen a metas o “checkpoints” para pasar de nivel. Las 20 ´reas clave1 : a Test strategy Life-cycle model Moment of involvement Estimating and planning Test specification techniques Static test techniques Metrics Test automation Test environment Office environment Commitment and motivation Testing functions and training Scope of methodology 1 No se traducen aqu´ los nombres de las ´reas clave porque algunos t´rminos pierden su ı a e verdadera sem´ntica. a
  • 2.2. PROCESOS DE TESTING FUNCIONAL 13 Communication Reporting Defect management Testware management Test process management Evaluation Low-level testing Resumen TPI es construido como modelo de mejora inspirado en el proceso estructurado TMap. Es interesante destacar que entre las ´reas clave existen muchos aspectos a de los procesos de testing y desde ese punto de vista, se pueden ver como una enumeraci´n de los elementos com´nmente presentes en los procesos. Adem´s, o u a cuenta con ´reas claves que refieren a aspectos no siempre contemplados en a los procesos como ser testing automatizado (Test automation), compromiso y motivaci´n (Commitment and motivation), o capacitaci´n (Testing functions o o and training). 2.2. Procesos de Testing Funcional Continuando con el enfoque descendente, tratamos a continuaci´n los procesos o de testing funcional. Un proceso de testing funcional se refiere a que el testing del producto ser´ desa de el punto de vista de las funcionalidades, acorde con sus requerimientos, en lugar de medir su rendimiento u otras cualidades para-funcionales. De los procesos existentes, se presentan a continuaci´n dos ejemplos que o contrastan bastante. Uno de ellos es un proceso precisamente definido en etapas, y el otro es una tendencia que surge en a partir de la adopci´n de metodolog´ o ıas a ´giles en el desarrollo de software. 2.2.1. ProTest ProTest [P´r06] es un proceso de testing funcional independiente, orientae do a ciclos de prueba y basado en an´lisis del riesgo del producto. a La independencia indica que es posible aplicar y adaptar este proceso de testing independientemente del proceso de desarrollo que siga la organizaci´n, o aportando una visi´n objetiva, y pudi´ndose incorporar a cualquier altura del o e proyecto de desarrollo (tanto en etapas tempranas, como con el producto ya
  • CAP´ ITULO 2. ESTADO DEL ARTE 14 construido). Los ciclos de prueba son el eje del proceso, e implican la ejecuci´n de las o pruebas planificadas para una versi´n dada del producto. Cada ciclo de prueba, o se corresponde con una versi´n del producto, la cual no debe sufrir alteracioo nes durante la ejecuci´n de las pruebas. Paralelamente, se mejora el producto o o arreglan los incidentes detectados en un ambiente separado. Una nueva versi´n o del producto conteniendo los arreglos de los incidentes y eventualmente nuevas funcionalidades, puede ser liberada para la ejecuci´n de un nuevo ciclo de prueo ba. El an´lisis del riesgo del producto hace que ProTest tome en cuenta las a realidades de la organizaci´n. En t´rminos generales, se utilizan las t´cnicas o e e b´sicas de an´lisis de riesgo, elaborando una lista de riesgos priorizada, tratana a do de mitigar cada uno de ellos, revis´ndola peri´dicamente, y manejando la a o incorporaci´n de nuevos riesgos. Un riesgo es tal, si lo es para el producto, la o organizaci´n, el negocio, los interesados, o compromete el desarrollo del proyeco to. La lista de riesgos puede ser elaborada e identificada por los encargados de llevar adelante el testing, pero siempre debe ser validada y alimentada con la opini´n el resto de los actores del proyecto. o ProTest consta de cuatro etapas principales: Estudio Preliminar Planificaci´n o Ciclos de Prueba Evaluaci´n o En el siguiente diagrama, vemos c´mo se relacionan las diferentes etapas. o Figura 2.1: Etapas de ProTest
  • 2.2. PROCESOS DE TESTING FUNCIONAL 15 Estudio Preliminar: consiste en el estudio de las caracter´ ısticas del producto y sus funcionalidades con el prop´sito de definir el alcance de las pruebas y o elaborar una primera estimaci´n de los ciclos de prueba. El siguiente paso es el o de calcular la cotizaci´n del proyecto de testing. Si la cotizaci´n es aceptada la o o siguiente etapa es la de Planificaci´n, de lo contrario, se da paso a la etapa de o Evaluaci´n de los posibles problemas, y se archiva el proyecto para consultarlo o a futuro. Planificaci´n: tiene por objetivo planificar el proyecto de testing luego de que o se acord´ con el cliente seguir adelante con el proyecto. En esta etapa se analizan o y mejoran los requerimientos, se definen los ciclos de prueba y es elaborado el Plan de Testing considerando las funcionalidades a probar y haciendo ´nfasis en e el riesgo de de cada parte del sistema. Ciclo de Prueba: etapa en la que se construyen pruebas y son ejecutadas. Un ciclo de prueba se corresponde con una versi´n dada del sistema. Los ciclos o de prueba gu´ al proyecto de testing. ıan El ciclo de prueba se compone de: Seguimiento del ciclo: se trata del seguimiento y control del ciclo de prueba. Consiste de la revisi´n de la planificaci´n, la planificaci´n o o o detallada de las actividades del ciclo de prueba y ajustes al plan derivados de las estimaciones y mediciones llevadas a cabo en ciclos de prueba anteriores. Al t´rmino de la configuraci´n del entorno, dise˜ o de las e o n pruebas y ejecuci´n de las pruebas, se vuelve a seguimiento y control o con el fin de evaluar la finalizaci´n del ciclo, o la continuaci´n con el ciclo, o o agregando m´s pruebas. a Configuraci´n del entorno: los entornos y ambientes de testing o son configurados, y la versi´n del producto es instalada, as´ como las o ı herramientas a utilizar. Se apunta a lograr un ambiente de testing separado del ambiente de desarrollo. Dise˜ o de pruebas: consiste en la construcci´n de un conjunto de casos n o de prueba acordes a los requerimientos. Estos casos de prueba pueden ser derivados de la aplicaci´n de una o varias t´cnicas de dise˜o de pruebas. o e n Ejecuci´n de las pruebas: es la actividad de interactuar con el producto, o ejecutando los casos de prueba dise˜ados. La realidad se compara con los n resultados esperados, y se reportan los posibles incidentes, consultas u observaciones al producto. Evaluaci´n: a modo de cierre, en esta etapa se elabora el informe final y se o eval´a el proceso de testing para identificar puntos donde se puede mejorar. En u la evaluaci´n se busca conocer el grado de satisfacci´n del cliente. Finalmente, o o
  • CAP´ ITULO 2. ESTADO DEL ARTE 16 se archiva el proyecto y sus elementos relacionados para recurrir a ´l en futuros e proyectos a modo de consulta. 2.2.2. ´ Testing Agil Esta secci´n, trata el tema desde la visi´n de un art´ o o ıculo muy interesante publicado en la revista Avances en Sistemas e Inform´tica [Zap10] por la Universidad a Nacional de Colombia, sede Medell´ ın. ´ ¿Qu´ son las Pruebas Agiles? e El testing ´gil es una pr´ctica (o conjunto de pr´cticas de testing), que se ha ido a a a consolidando como propuesta de complemento a las metodolog´ ´giles y en resıas a puesta a la necesidad de las organizaciones de adaptar el testing a estos m´todos. e Como sucede con otros procesos de desarrollo, a la hora de incorporar testing en el ciclo de vida de los m´todos ´giles de desarrollo, es com´ n encontrar obst´cue a u a los y limitaciones, como la mala comunicaci´n entre los equipos y dentro de los o equipos, y la carencia de automatizaci´n de las pruebas en diferentes fases del o ciclo de vida de desarrollo. El testing ´gil, sigue los principios del manifiesto ´gil2 , teniendo prioridad de a a satisfacer al interesado por medio de las entregas tempranas de software. Como otras metodolog´ de testing, tambi´n promueve la colaboraci´n continua ıas e o entre equipo interesado y equipo desarrollador y se procura la mejora continua en el proceso, respondiendo al cambio y a las nuevas expectativas del interesado. Adoptar metodolog´ ´giles requiere un cambio cultural, que algunas organiıas a zaciones no son capaces de afrontar. Las organizaciones m´s adecuadas para a implantar metodolog´ ´giles suelen tener integrantes con un pensamiento inıas a dependiente, no tienen estructura jer´rquica establecida y por sobre todo ponen a ´nfasis en pol´ e ıticas de calidad. El testing ´gil es una de las metodolog´ que apunta a un entorno colaborativo, a ıas con fuertes interacciones interpersonales. Hace foco en la auto-gesti´n y la inteo graci´n de usuarios, programadores y desarrolladores en el proceso de testing, o instaurando una responsabilidad por la calidad de todo el equipo, en lugar de que sea vista como pertenencia exclusiva del ´rea de testing. a Dentro de un equipo ´gil, debe existir comunicaci´n continua entre los desarroa o lladores e interesados, definiendo los requisitos, las pruebas y el comportamiento esperado del producto. Adem´s se manifiesta el concepto de roles, sugiriendo a 2 Se puede acceder a la versi´n en espa˜ ol del Manifiesto por el Desarrollo Agil de Software ´ o n en http://http://agilemanifesto.org/iso/es/, accedido en ultima oportunidad en marzo de 2011 ´
  • 2.2. PROCESOS DE TESTING FUNCIONAL 17 que cada miembro asuma varios roles para eliminar la dependencia entre individuos, y favoreciendo la proactividad. Tanto como otras metodolog´ el testing ´gil tiene entre sus pr´cticas recoıas, a a mendadas las pruebas por pares (par tester y desarrollador, tester y usuario, o dos testers trabajando juntos), pruebas de regresi´n automatizadas, y la utilio zaci´n de herramientas adecuadas (como un sistema de reporte y seguimiento o de incidentes). Tambi´n recomienda como buena pr´ctica, considerar la impore a tancia del rol del usuario o cliente en la elaboraci´n y ejecuci´n de pruebas de o o aceptaci´n del producto. o Conceptos alrededor del testing ´gil a Tester: persona que puede desempe˜ar varios roles en un proyecto de n software. Tiene habilidades t´cnicas y destrezas para el desarrollo y e ejecuci´n de pruebas. o Interesado: se apoya en un analista con el fin de proponer una soluci´n o al problema. Tiene conocimiento del negocio, y es quien es entrevistado para descubrir los requisitos, los cuales encaminan la soluci´n. o Equipo ´gil: expertos en ´reas t´cnicas de software y en el dominio del a a e negocio, que trabajan orientados hacia un mismo fin en peque˜ os ciclos n de tiempo, llamados iteraciones. Metodolog´ ´gil: proceso de desarrollo de software que busca construir ıa a aplicaciones de manera r´pida teniendo en cuenta en todo momento al a interesado. Estas metodolog´ enfatizan las comunicaciones cara a cara ıas en vez de la documentaci´n. o Prueba: procedimiento para validar una funcionalidad de un determinado software. X-Unit: entorno utilizado para automatizar las pruebas unitarias. Bug Tracking System: herramienta utilizada para el reporte y seguimiento de los incidentes. Como sugieren la mayor´ de las metodolog´ para el rol del tester, un tester ıa ıas a ´gil, se caracteriza por contar con habilidades t´cnicas en testing, y cumplir un e rol articulador entre las necesidades del interesado y el equipo desarrollador. El tester est´ en la posici´n adecuada para lograr la colaboraci´n de todas las a o o partes. Por ultimo, dentro de las pr´cticas m´s importantes recomendadas en el testing ´ a a a ´gil, se encuentra la automatizaci´n. Contar con pruebas de regresi´n o o automatizadas, e incluso pruebas de aceptaci´n automatizadas, es o fundamental para el ´xito del testing ´gil. El ritmo de desarrollo supera e a r´pidamente la capacidad de ejecuci´n de pruebas manuales, por lo tanto, la a o estrategia debe estar enfocada a la automatizaci´n. o
  • CAP´ ITULO 2. ESTADO DEL ARTE 18 2.3. Incorporaci´n Temprana del Testing o Comenzar las actividades de testing en etapas tempranas del desarrollo de un producto, tiene muchas consecuencias positivas3 . Los modelos a continuaci´n, o discuten cu´ndo hacer qu´ tipo de testing, seg´n la informaci´n disponible en a e u o cierta etapa del proceso de desarrollo. 2.3.1. Modelo V El modelo V (o vee) [IAB97] es un modelo de proceso que se opone a la idea de que el testing puede comenzar solamente cuando el producto est´ terminado. a Es l´gico pensar que no se puede testear algo que no existe, pero, tratar as´ al o ı testing es desconocer que el conjunto de actividades relacionadas va m´s all´ de a a s´lo la ejecuci´n de las pruebas. o o Tomando en cuenta el modelo V simplificado de la figura 2.2, podemos ver c´mo o cada actividad de desarrollo se corresponde con una actividad de testing. Las diferentes organizaciones pueden nombrar a las etapas de diferentes maneras, pero seg´n el modelo V, cada actividad de la parte izquierda, se corresponde, y aliu menta de informaci´n, a una actividad de testing en la parte derecha del modelo. o Figura 2.2: Modelo V simplificado. 3 Por ejemplo, sabemos que el costo de arreglar un error en la definici´n es siempre mucho o m´s bajo que hacer cambios en el producto ya elaborado. a
  • ´ 2.3. INCORPORACION TEMPRANA DEL TESTING 19 Si tomamos las actividades de testing y de desarrollo, vemos como avanzan de forma opuesta las etapas de construcci´n del producto y convergen en el v´rtice o e del modelo. Este es precisamente el gran aporte del modelo V que sostiene que las actividades de testing correspondientes a las actividades de desarrollo, cuentan con la informaci´n suficiente para dise˜ar las pruebas correspondientes. De o n esta manera, estas etapas est´n incorporando testing de manera temprana en el a ciclo de vida del desarrollo del software, encontrando defectos en etapas iniciales del producto, impidiendo que dichos errores se propaguen a etapas posteriores, donde es mucho m´s costoso corregirlos. a A modo de ejemplo consideremos un proceso de desarrollo con las etapas de la figura 2.2, un proyecto en s´ o una iteraci´n dentro de un ciclo de vida de ı o un producto. En las etapas m´s tempranas, se definen los requerimientos, esta a informaci´n es suficiente para dise˜ar y negociar pruebas de aceptaci´n con o n o los usuarios finales. M´s adelante, se especificar´ funcionalmente el an´lisis de a a a forma m´s detallada, con una visi´n funcional; de esta manera la actividad de a o testing correspondiente est´ en condiciones de dise˜ar pruebas de aceptaci´n. Al a n o llegar a un dise˜o detallado de la soluci´n, para cierto requerimiento, estamos en n o condiciones de dise˜ar pruebas de integraci´n entre los diferentes componentes n o a construir. Por ultimo, en el punto de convergencia del modelo, la construcci´n ´ o de las pruebas unitarias, se alimenta del mismo dise˜o o especificaci´n (o partes n o de ´l) que requieren las unidades o m´dulos. e o Cr´ ıticas al modelo V El modelo V presentado, hace foco en la inclusi´n temprana del testing en el o ciclo de vida del producto, lo cual es siempre m´s efectivo que incluirlo en etapas a tard´ La base del modelo V, es que hay una correspondencia entre cada etapa ıas. del modelo en la parte izquierda, y las actividades de la parte derecha. Seg´n algunos autores, hay algunos problemas con el modelo V. La experiencia u pr´ctica indica que la correspondencia entre las etapas a la izquierda del modea lo y las actividades de testing no siempre se da. Por ejemplo, la especificaci´n o funcional muchas veces no est´ completa, o no provee la suficiente informaci´n a o para elaborar pruebas de sistema. En una situaci´n del mundo real, el testing se o nutre de diversas fuentes de requerimientos, considerando aspectos del negocio, de la arquitectura, o del dise˜o f´ n ısico de la soluci´n inclusive. o Otra cr´ ıtica hacia el modelo V, es que no toma en cuenta el potencial valor agregado de las pruebas est´ticas (inspecciones, revisiones de documentos, a an´lisis est´ticos de c´digo, entre otros). Esta se puede considerar una de las a a o grandes omisiones del modelo; adem´s de tratar a las actividades de testing a solamente como actividades anexas a las actividades de desarrollo.
  • CAP´ ITULO 2. ESTADO DEL ARTE 20 2.3.2. Modelo W El modelo W intenta subsanar los puntos d´biles del modelo V. Introducido e por Paul Herzlich en 1993 [Her93], el modelo W intenta establecer actividades intermedias entre las correspondientes etapas en ambas ramas del modelo V, en vez de hacer hincapi´ en actividades espec´ e ıficas del testing din´mico; logrando a productos en s´ mismos. ı Cada actividad de desarrollo es acompa˜ada por una actividad de testing, la n cual busca determinar si la actividad de desarrollo alcanz´ sus objetivos, y los o entregables asociados satisfacen sus requerimientos de entrada. Cada entregable de desarrollo (por ejemplo documento de an´lisis), tiene su actia vidad de testing espec´ ıfica (siguiendo con el ejemplo, ser´ testear el documento ıa de an´lisis). Si las etapas de desarrollo son m´s o menos, la unica adaptaci´n a a ´ o necesaria, es agregar una actividad de testing que se encargue de verificar los entregables. Como contraparte a la debilidad del modelo V ante las t´cnicas de e testing est´tico, el modelo W acepta el uso gran cantidad de ellas; como ser a inspecciones de documentos, revisiones, an´lisis de escenarios, an´lisis est´ticos, a a a animaci´n de requerimientos y por supuesto, se puede avanzar con el dise˜ o de o n casos de prueba de forma temprana. El modelo W sugiere focalizar en aquellos puntos m´s riesgosos, d´nde el testing a o temprano (est´tico y dise˜o de testing din´mico) puede ser m´s efectivo. a n a a En cuanto a las etapas de testing din´mico, existen diferentes tipos que se a pueden aplicar (pruebas unitarias, pruebas de integraci´n, pruebas de sistema, o pruebas de aceptaci´n); esta parte del modelo V se conserva en el W. o El modelo W, no exige contar con la misma cantidad de etapas de testing din´mico que etapas de desarrollo, ni restringe a que el testing deba contar con a determinado documento; sino que permite obtener informaci´n de varias etao pas, y de diferentes ´reas de la informaci´n. Por ejemplo, si hay cinco etapas de a o desarrollo para la definici´n, dise˜o y construcci´n del producto, entonces puede o n o que alcance con tener solamente tres etapas de testing din´mico; y se podr´ a ıa lograr un buen dise˜o de pruebas combinando la informaci´n adquirida desde n o un manual de usuario, conocimiento te´ricos acumulados en t´cnicos funcionales o e y la experiencia acumulada en usuarios que utilicen el sistema en la pr´ctica. a Una posible forma aplicar el modelo W ser´ ıa: Identificar los riesgos relevantes. Especificar los componentes, productos y entregables que se van a testear. Seleccionar t´cnicas est´ticas de testing, y los tipos de pruebas din´micas e a a a llevar a cabo para tratar los riesgos.
  • 2.4. ESTRATEGIAS DE TESTING FUNCIONAL MANUAL 21 Planificar las actividades de testing lo m´s cercanas posibles a las a actividades de desarrollo que generen alg´n producto verificable. u Figura 2.3: Posible caso del Modelo W. 2.4. Estrategias de Testing Funcional Manual Una estrategia de testing consiste en la forma en la que se llevar´ adelante el a testing para determinado producto. Define de qu´ manera y en qu´ momento e e se analizar´n requerimientos y funcionalidades del software, c´mo y cu´ndo se a o a dise˜ar´n y ejecutar´n las pruebas. n a a Las estrategias m´s comunes son la de testing exploratorio (que confiere un a aprendizaje simult´neo del producto a la vez que se ejecutan pruebas) y la de a testing planificado (donde se analiza el producto y los requerimientos, se dise˜ a n casos de prueba y luego se ejecutan). La estrategia puede incluir la decisi´n de o contar con pruebas automatizadas. Existen estrategias m´s, o menos complejas. Con la experiencia en el manejo a de las estrategias de testing, es posible formular nuevas estrategias, como ser h´ ıbridas, tratando de tomar lo mejor de cada una en un determinado contexto, sin encasillar la prueba a los l´ ımites de unas u otras.
  • CAP´ ITULO 2. ESTADO DEL ARTE 22 2.4.1. Testing Dise˜ ado n El testing dise˜ado (o planificado) est´ fuertemente relacionado con el an´lisis n a a de los requerimientos. Formalmente, depende en gran medida de que estos requerimientos est´n construidos con un grado de avance cercano al final. e El objetivo es logar un conjunto est´tico de casos de prueba que luego de esa pecificados (con datos de prueba), puedan ser ejecutados por cualquier tester. En organizaciones donde es primordial la negociaci´n del alcance de las o pruebas, la validaci´n de producciones intermedias y las auditorias; el dio se˜o aporta un gran valor, dado que a partir del conjunto de casos de pruen ba generado, se pueden apoyar las instancias de validaci´n, priorizaci´n y o o negociaci´n del alcance de las pruebas, con una visi´n objetiva y discreta. o o Seg´n ProTest [P´r06], el testing dise˜ ado involucra: u e n An´lisis de requerimientos: estudio de las funcionalidades documena tadas en requerimientos con el fin de obtener conocimiento en el dominio. Dise˜ o de casos de prueba: a partir de los requerimientos analizados, n se aplican diversas t´cnicas de testing funcional para derivar un conjunto e de casos de prueba. Selecci´n y priorizaci´n de casos de prueba: en conjunto con o o las t´cnicas, se seleccionan y priorizan los casos de prueba bas´ndose e a en diferentes criterios, como ser la criticidad de la funcionalidad, la complejidad de implementaci´n o uso de la funcionalidad, el riesgo o asociado al producto, el tiempo disponible para la ejecuci´n de las pruebas, o entre otros. Ejecuci´n de pruebas: es la interacci´n con el sistema siguiendo los o o casos de prueba especificados en el dise˜o, luego de ser priorizados y n seleccionados. La ejecuci´n se considera finalizada cuando el conjunto de o casos negociados y validados fueron ensayados en el sistema. 2.4.2. Testing Exploratorio El testing exploratorio es una estrategia que supone un aprendizaje simult´neo a a la ejecuci´n de las pruebas. Es ampliamente utilizada, sobre todo en contextos o a ´giles donde el foco est´ en cubrir la mayor cantidad de funcionalidades posibles, a en lugar de contar con documentaci´n estructurada y detallada. o Es posible llevarlo adelante de diferentes formas, como ser el testing exploratorio conocido como estilo libre y el testing exploratorio basado en sesiones. Esto no quiere decir que no existan otras maneras, ni que no puedan desarrollarse nuevos estilos en el futuro. Una rese˜a de otros estilos de testing se puede encontrar en n el libro “Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design”, de James A. Whittaker [Whi09a].
  • 2.4. ESTRATEGIAS DE TESTING FUNCIONAL MANUAL 23 Se considera al testing exploratorio en s´ como una estrategia muy poderosa a la ı, hora de encontrar incidentes r´pidamente. Uno de los objetivos (y muchas veces a virtud) del testing exploratorio se puede considerar en justamente encontrar los incidentes m´s importantes de forma temprana en el transcurso de las pruebas a [Bac02]. Un punto particular a tener en cuenta, es que el testing exploratorio depende fuertemente de las habilidades del tester, su experiencia, su capacidad de tomar decisiones en el acto, manejo de la l´gica y capacidad de crear modelos o mentales del funcionamiento del sistema. Por lo tanto, es importante para los testers incrementar las habilidades mediante la pr´ctica y la incorporaci´n de a o nuevas t´cnicas, y nuevas habilidades en diferentes ´reas, como ser el dise˜ o de e a n casos de prueba, la comunicaci´n, relaciones interpersonales, capacidad t´cnica, o e auto-gesti´n, entre otras. o Testing Exploratorio Estilo Libre El estilo libre implica la exploraci´n ad hoc del sistema sin necesariamente tener o que dejar trazas o documentaci´n explicita de la ejecuci´n de las pruebas. Es en o o ocasiones utilizado para familiarizarse con el producto, aprender de ´l e invese tigarlo, as´ como tambi´n para las “pruebas de humo” 4 . El estilo libre no sigue ı e ning´n patr´n espec´ u o ıfico ni reglas. No es recomendable utilizar este estilo como la unica implementaci´n de la estrategia de testing exploratorio, dado que las ´ o pruebas resultantes no dejan evidencia, se suelen ejecutar en cualquier orden, y se pierde el control sobre la cobertura de las funcionalidades [Whi09b]. Seg´n James Bach en su art´ u ıculo “Exploratory Testing Explained” [Bac02] la gesti´n del testing estilo libre pude ser llevada adelante de manera delegante, o o de forma participativa. Gestionar en la forma delegante: implica que el l´ ıder tendr´ que tener en a cuenta el caudal de responsabilidad que est´ depositando en los testers y a la a vez saber que esta comprometiendo parte del ´xito del proyecto de testing. La e relaci´n con el equipo debe ser muy estrecha para que se comprenda que cada o integrante es due˜o y gestor de su tiempo, y responde por el ´xito de su parte. El n e l´ ıder, en este caso, se limita a establecer los charters, dividir el trabajo y hacer el seguimiento; debe ser capaz de reconocer a quienes delegar los trabajos m´s a importantes, m´s riesgosos seg´n el dominio, o m´s triviales. A los testers m´s a u a a habilidosos y comprometidos, se les suelen encargar las tareas m´s importantes a y complejas, en tanto al resto se les asocian tareas m´s cortas y controlables. a 4 Las pruebas de humo tienen por objetivo encontrar incidentes graves r´pidamente. Se a aplican generalmente para saber si un producto est´ lo suficientemente estable para practicarle a testing m´s riguroso. a
  • 24 CAP´ ITULO 2. ESTADO DEL ARTE Gestionar por participaci´n: es la modalidad de gesti´n del testing o o exploratorio estilo libre en la cu´l, los l´ a ıderes de testing trabajan muy apegados a los testers, inclusive como un tester m´s. La situaci´n pr´ctica deseable, a o a es que los l´ ıderes tengan sus responsabilidades administrativas y reuniones, delegadas en otras personas. Dirigir el equipo de testing por participaci´n, o permite que el l´ ıder establezca en todo momento los ajustes a la estrategia, explicitando el comportamiento esperado del equipo. Un l´ ıder es responsable por el desempe˜o de su equipo, y apoyarse en este estilo de direcci´n lo ubica n o en una posici´n favorable a la hora de lograr sus objetivos. Los mitos que rodean o a la ineficiencia del testing exploratorio, tienden a desaparecer cuando un l´ ıder est´ estrechamente vinculado al resto del equipo y al transcurso del proyecto de a testing. Reporte del testing exploratorio estilo libre: adem´s de las herramiena tas con la que se gestionen los incidentes, la coordinaci´n del equipo de testing o se hace de forma verbal en reuniones, que seg´n las recomendaciones, deber´ u ıan ser al menos semanales. Bach comenta en el mismo art´ ıculo [Bac02] que Cem Keaner5 , sugiere reuniones regulares con testers para discutir sus procesos al ´ menos una vez por semana. El encuentra util abrir la reuni´n con una pregun´ o ta est´ndar del estilo: “¿Cu´l es el bug m´s interesante que han encontrado a a a recientemente?. Muestrenmel´!”. o Testing Exploratorio Basado en Sesiones El testing exploratorio basado en sesiones, es un enfoque del testing exploratorio ideado por los hermanos James y Jonathan Bach, quienes han escrito varios art´ ıculos, y han colaborado en diversos libros sobre testing de software, haciendo foco en la ense˜anza e investigaci´n del testing; particularmenn o te, se los considera referentes en el testing exploratorio. Este enfoque incluye directivas de organizaci´n, gesti´n de las pruebas e incidentes, as´ como cono o ı trol de la cobertura y tipos de testing. En el art´ ıculo “Session-Based Test Management” [Bac00], Jonathan Bach considera que el grado en que se involucra el tester con el producto es mayor, al encontrarse en la din´mica de a aprender del dominio, dise˜ar y ejecutar pruebas simult´neamente. Como conn a secuencia, se consiguen mejores resultados en una menor cantidad de tiempo. Sesiones en el Testing Exploratorio Con el fin de gestionar el testing exploratorio, nace de la necesidad de separar el testing de todo lo que no lo es. Para este objetivo, se utiliza el concepto de sesi´n. La sesi´n es un intervalo de tiempo dedicado a practicar testing explorao o torio, sin interrupciones (por ejemplo mail, chat, celulares), con el foco puesto en el testing. La duraci´n recomendada de una sesi´n seg´ n el art´ o o u ıculo puede 5 Otro gran referente en testing, m´s informaci´n en su web personal, http://kaner.com/ a o (accedida en diciembre de 2010)
  • 2.4. ESTRATEGIAS DE TESTING FUNCIONAL MANUAL 25 ser: short (una sesi´n “corta” de aproximadamente 45 minutos), normal (una o sesi´n de duraci´n “normal” de aproximadamente 90 minutos) o long (equivale o o a una sesi´n “larga” de dos horas de duraci´n aproximadamente). o o La sesi´n puede registrarse en texto plano, siguiendo la plantilla de la figura 2.46 . o Figura 2.4: Ejemplo de hoja de reporte de sesi´n de testing exploratorio. o Las secciones que componen el reporte de la sesi´n son: o Session Charter: se puede traducir como “hoja de ruta”. Es una descripci´n verbal de lo que se pretende en la sesi´n. Puede indicar algunos o o elementos deseables, ideas, o mencionar heur´ ısticas a utilizar durante la exploraci´n. Es com´n que contenga algunos pasos generales de las pruebas o u y documentaci´n util para la ejecuci´n de la sesi´n. Esta “hoja de ruta”, es o ´ o o generalmente escrita por el tester que est´ gestionando las actividades de e testing exploratorio, o bien por el mismo tester que ejecutar´ la prueba. a Aqu´ se encuentra la Misi´n, que es la descripci´n verbal del objetivo ı o o de una prueba. Puede consistir en probar una funcionalidad, o conjunto 6 La ventaja de seguir este formato, es que se puede utilizar una herramienta de Bach para recopilar la informaci´n, y obtener m´tricas interesantes, informaci´n sobre la cobertura, entre o e o otros. M´s informaci´n de este y otros recursos en http://www.satisfice.com/sbtm/ a o
  • CAP´ ITULO 2. ESTADO DEL ARTE 26 de funcionalidades relacionadas, as´ como tambi´n cumplir determinados ı e criterios o situaciones por las cuales transitar durante la prueba. Tester name(s): el nombre del tester o los testers que ejecutar´n la a sesi´n. o Date and time started: fecha y hora en que comienza la sesi´n de testing o exploratorio Task breakdown: incluye la duraci´n de la sesi´n, y tres porcentajes o o relacionados que expresan la porci´n de tiempo dedicada a dise˜ o y o n ejecuci´n de pruebas, investigaci´n de bugs y reporte, y configuraci´n o o o (preparaci´n) de la sesi´n. Luego, una relaci´n de porcentaje que indica o o o qu´ porci´n del tiempo fue dedicado a la misi´n en s´ y qu´ porci´n e o o ı, e o se dedic´ a otros temas por fuera de la misi´n. A esto ultimo se le o o ´ llama “oportunidad”, como en el caso de la analog´ del tour,7 es todo ıa aquello que exploramos por afuera de nuestra “ruta” trazada, pero luego, volviendo a enfocarnos en la misi´n. o Data files: eventuales archivos relacionados con la sesi´n (de cualquier o ´ ındole, como im´genes, archivos conteniendo datos de prueba anexos, entre a otros). Test notes: esta secci´n puede contener anotaciones varias, como o ser los pasos ejecutados para la prueba, alg´n comentario detallando u particularidades de las funcionalidades, o cualquier otro comentario que resulte interesante para la ejecuci´n y documentaci´n de la sesi´n. o o o Issues: incidentes de menor porte, consultas, sugerencias y observaciones varias. Bugs: aqu´ se documentan los errores encontrados durante la sesi´n. ı o 2.4.3. Discusi´n: Testing Exploratorio Vs. Testing Dio se˜ ado. n As´ como manifiestan muchos de los autores referenciados, no hay buenas pr´ctiı a cas en general, sino una mejor pr´ctica dado un contexto. No ser´ correcto por a ıa lo tanto, contraponer dos estrategias de testing, esperando sacar la conclusi´n o de que una es mejor que la otra. Inclusive separar el mundo de las estrategias entre exploratorio y dise˜ado, ser´ un enfoque bastante arbitrario que dejar´ n ıa ıa por fuera gran parte de la realidad a la que se enfrenta cualquier tester profesional. ¿Por qu´ entonces presentamos esta discusi´n?, por el motivo de que e o 7 La analog´ se trata de una recorrida tur´ ıa ıstica, en la cual planificamos pasar por ciertos puntos, esta ser´ nuestra “misi´n”. Cuando algo nos llama la atenci´n de la ciudad, ıa o o nos apartamos moment´neamente para explorar ese lugar no planificado, esto ser´ la a ıa oportunidad”. Luego, regresar´ ıamos a nuestra ruta trazada desde un principio, volviendo a hacer foco en la misi´n. o
  • 2.4. ESTRATEGIAS DE TESTING FUNCIONAL MANUAL 27 son dos grandes y renombradas estrategias base en el testing de software en las cuales se suelen catalogar los enfoques. Otras estrategias y heur´ ısticas no entran en la discusi´n por considerarse complementarias desde un principio, o por no o ser tan populares. Una estrategia que incluye testing exploratorio, suele ser m´s flexible, a adapt´ndose al cambio m´s r´pidamente que el testing dise˜ado. Un conjunto a a a n dise˜ado de casos de prueba, se vuelve m´s “d´bil” conforme cambia el contexto n a e y el producto. Es necesario re-planificar y dise˜ar nuevos casos de prueba, conn templando el nuevo estado del producto, si queremos mantener o incrementar la efectividad y la probabilidad de encontrar errores. El testing exploratorio, est´ en permanente cambio, y supone un dise˜o y ejecuci´n de pruebas sia n o mult´neos, irremediablemente tomando en cuenta el estado actual del software a y del contexto en cada instante. En l´ ıneas generales; el testing exploratorio es recomendable cuando el objetivo es dejar trazas de ciclos funcionales, encontrar gran cantidad de errores en poco tiempo, no se cuenta con buena documentaci´n de requerimientos y no es o necesario contar con la validaci´n de los casos de prueba generados por el equipo o de testing. En cambio, el testing dise˜ado, es m´s recomendable cuando se est´n n a a siguiendo procesos m´s r´ a ıgidos y estructurados, se cuenta con documentaci´n o de requisitos aceptable (o es posible reconstruirla a partir de distintos referentes expertos del dominio), se puede planificar y estimar el proyecto de testing, se debe solicitar y negociar la validaci´n de los casos de pruebas con autoridades o o expertos en el dominio, y relacionado con lo anterior, se desea dejar evidencia de la negociaci´n concreta de la cobertura espec´ o ıfica de la ejecuci´n de las pruebas. o La idea no es encasillar las estrategias de testing en dos unicas versiones. La ´ complejidad del software actualmente, y la potencialmente infinita cantidad de casos de prueba posibles para una aplicaci´n, nos ubica indefectiblemente en la o situaci´n de tener que verificar desde m´ltiples estrat´gicas b´sicas, o inclusive o u e a con una combinaci´n de diferentes estrategias. Adoptar una mezcla de estrateo gias incluyendo ideas de an´lisis del riesgo y sectores cr´ a ıticos del negocio, puede enriquecer enormemente las actividades de testing, salvando la posible p´rdie da de informaci´n derivada de tener una perspectiva desde una sola estrategia. o Dentro de las habilidades deseables del tester, est´ la de conocer las ventajas a y desventajas de cada estrategia, y sacar lo mejor de cada una para reunir la informaci´n necesaria. o
  • CAP´ ITULO 2. ESTADO DEL ARTE 28 2.4.4. Otro enfoque complementario: Testing Basado en Riesgo En el art´ ıculo “Heuristic Risk-Based Testing” [Bac99], James Bach describe la heur´ ıstica del testing basado en riesgo, que consta de: Crear una lista priorizada de riesgos Llevar adelante pruebas que exploren cada riesgo Ajustar el esfuerzo de testing para mantener el foco en los riesgos actuales; los riesgos anteriores son mitigados y se identifican nuevos. El riesgo siempre esta asociado al testing, pero llevar adelante testing basado en riesgo implica centrar las actividades en los riesgos identificados, manejarlos, identificar nuevos riesgos y direccionar las actividades de testing a su mitigaci´n. o El art´ ıculo menciona dos enfoques para el an´lisis, “de adentro hacia afuera”, a y “de afuera hacia adentro”. Ambos enfoques son complementarios y tienen distintas fortalezas. De adentro hacia afuera, situaci´n: o identificando los riesgos asociados a cada Vulnerabilidades: ¿Qu´ debilidades o posibles fallas hay en estos compoe nentes?. Amenazas: ¿Qu´ entradas o situaciones pueden haber que puedan explotar e una vulnerabilidad y lanzar una falla en este componente?. V´ ıctimas: ¿Qui´n, o qu´ puede ser impactado por potenciales fallas, y cu´n e e a malo puede ser?. En una sesi´n con desarrolladores, se obtiene informaci´n sobre el funcionamieno o to del sistema, luego, el tester va conociendo el comportamiento esperado del sistema y formulando interrogantes acerca de las diferentes partes del sistema y sus interacciones. Se recomienda estar muy atento al tono de voz, la seguridad con que se contestan ciertas preguntas, o se demuestra dominio sobre determinados puntos; todo puede ser una pista para encontrar incidentes. A modo de ejemplo, en una supuesta sesi´n con desarrolladores, se cuenta con un pizarr´n o o donde se esquematiza el funcionamiento del producto en diagramas informales (con cuadros y flechas), luego el tester formular´ preguntas del estilo: ıa ¿Qu´ sucede si la funci´n en este cuadro falla? (se˜ alando cierto cuadro e o n en el diagrama). ¿Esta funci´n puede ser siempre invocada en un momento incorrecto?. o ¿Qu´ chequeo de errores se hacen aqu´ (apuntando alg´ n lugar del e ı? u diagrama).
  • 2.4. ESTRATEGIAS DE TESTING FUNCIONAL MANUAL 29 ¿Qu´ significa esta flecha? (se˜alando una flecha) ¿Qu´ suceder´ si se e n e ıa corta?. Si los datos en esta direcci´n, se corrompen, ¿C´mo lo identificar´ o o ıa? ¿Qu´ pasar´ (se˜alando un flujo de datos). e ıa? n ¿Cu´l es la mayor carga que puede soportar este proceso?. a ¿De qu´ componentes externos, servicios, estados o configuraciones e depende este proceso?. ¿Puede alg´n otro recurso o componente diagramado aqu´ ser manipulado u ı o influenciado por alg´n otro proceso?. u ¿Este es el panorama general? ¿Qu´ no se ha representado en el diagrama?. e ¿C´mo probar´ esto si lo juntamos con esto otro?. o ıas ¿Qu´ es lo m´s preocupante? ¿Qu´ piensa que debo testear?. e a e De afuera hacia adentro: En esta forma de proceder con el an´lisis de riesgo, a se consulta una lista predefinida de riesgos decidiendo si aplican o no. Este es un enfoque relativamente m´s sencillo que el anterior. a Bach menciona algunos tipos de listas de riesgo que utiliza com´nmente, cou mo ser: “Categor´ de criterios de Calidad”, “Lista Gen´rica de Riesgos” y ıas e “Cat´logos de Riesgos” a Categor´ de criterios de calidad ıas Estas categor´ se ajustan con diferentes tipos de requerimientos, investigando ıas qu´ podr´ pasar si el requerimiento asociado a las diferentes categor´ no se e ıa ıas alcanzara. Capacidad: ¿Puedo efectuar las funciones requeridas?. Fiabilidad: ¿Funcionar´ bien y resistir´ fallas en todas las situaciones a a requeridas?. Usabilidad: ¿Cu´n f´cil es para un usuario real usar el producto?. a a Performance: ¿Cu´n veloz debe ser y responder el sistema?. a Instalabilidad: ¿Cu´n f´cil puede ser instalado en la plataforma objetivo?. a a Compatibilidad: ¿Qu´ tan bien trabaja con componentes y configuraciones e externas?. Soportabilidad: ¿Cu´n econ´mico resulta proveer soporte?. a o Testeabilidad: ¿Qu´ tan efectivamente puede ser testeado el producto?. e
  • CAP´ ITULO 2. ESTADO DEL ARTE 30 Mantenibilidad: ¿Cu´n econ´mico ser´ construir, reparar y mejorar el a o a producto?. Portabilidad: ¿Cu´n econ´mico ser´ trasladar o reutilizar el producto?. a o a Localizabilidad: ¿Qu´ tan econ´mico ser´ publicar el producto en otro e o a idioma?. Lista gen´rica de riesgos e Este tipo de lista es universal para cualquier sistema. Algunos riegos: Complejidad: cualquier elemento desproporcionalmente largo, intricando y complicado. Nuevo: todo lo que no tiene antecedentes en el producto. Cambiado: cualquier elemento que haya sido manipulado o mejorado. Dependencia de flujo ascendente: elementos cuya falla puede causar fallas en cascada al resto del sistema. Dependencia de flujo descendente: algo que es especialmente sensible a las fallas del resto del sistema. Cr´ ıtico: todo que al fallar pueda causar un da˜o de importancia. n Preciso: cualquier elemento del cual podamos conocer sus requerimientos exactamente. Popular: algo que ser´ muy usado. a Estrat´gico: cualquier cosa que tenga especial importancia en el negocio, e como ser una funcionalidad que distingue al producto de los competidores. De terceros: algo que se utilice en el producto que halla sido desarrollado fuera del proyecto. Distribuido: cualquier elemento que est´ repartido en el tiempo o espacio; e tambi´n elementos que deben trabajar juntos. e Con errores: algo que es sabido que tiene muchos errores. Falla reciente: cualquier cosa que tenga una historia de fallas recientes. Cat´logos de riesgos a Los cat´logos de riesgos son punteos de riesgos que pertenecen a un dominio a particular. Derivan de la experiencia de interactuar con determinadas circunstancias frecuentemente. Se deben interpretar como si comenzaran: “hemos tenido problemas con...”. Algunos ejemplos que formar´ parte de una cat´logo de riesgos de instalaci´n: ıan a o
  • 2.4. ESTRATEGIAS DE TESTING FUNCIONAL MANUAL 31 Archivos instalados incorrectamente. • Archivos temporales no se borran. • Archivos viejos no se eliminan despu´s de una actualizaci´n e o • Se instalan archivos innecesarios. • No se instalan archivos necesarios. • Un archivo correcto se instala en un lugar incorrecto. Archivos afectados. • Archivo viejo reemplaza un archivo m´s reciente. a • Se afectan datos del usuario durante la instalaci´n o Otras aplicaciones afectadas. • Un archivo compartido con otra aplicaci´n es afectado. o • Archivos pertenecientes a otro producto son eliminados. Hardware configurado incorrectamente. • El hardware es afectado por otras aplicaciones. • El hardware no es suficiente para las aplicaciones instaladas El protector de pantalla interrumpe la instalaci´n. o No detecci´n de aplicaciones incompatibles. o • Aplicaciones ejecutando actualmente. • Aplicaciones ya instaladas. Instalador reemplaza o modifica archivos cr´ ıticos o par´metros sin avisar. a El proceso de instalaci´n es demasiado lento. o El proceso de instalaci´n requiere seguimiento constante del usuario. o El proceso de instalaci´n es confuso o A partir del uso de las listas de riesgo se puede decidir qu´ componentes analizar, e reuniendo informaci´n y haciendo un seguimiento a los riesgos prioriz´ndolos y o a as´ mantenerlos bajo control e incorporando nuevos. ı Con el fin de organizar el testing basado en riesgo, se proponen en el art´ ıculo algunas formas, como ser el seguimiento peri´dico de la lista de riesgos, o o vinculado los riesgos a tareas espec´ ıficas para atacarlos, as´ como tambi´n reı e lacionando los riesgos a diferentes componentes, como ser partes de c´digo, o o cualquier otro elemento que pueda ser testeado.
  • CAP´ ITULO 2. ESTADO DEL ARTE 32 2.5. Testing Automatizado Esta secci´n tiene como fundamental referencia el libro “Software Test o Automation” [FG99a] de Mark Fewster y Dorothy Graham. Las siguientes subsecciones abarcan diferentes partes del texto de Fewster y Graham, y se mencionar´ como referencia la parte del libro que trata el tema, indic´ndolo al a a inicio de cada subsecci´n. o 2.5.1. Selecci´n de Casos de Prueba a Automatizar o Si tenemos un conjunto de casos de prueba, algunos ser´n automatizables y a otros no. Incluso si todos son automatizables, hay que decidir cu´les de ellos a conviene automatizar primero. Se debe considerar si el esfuerzo de automatizar ser´ redituable frente a la ejecuci´n manual de una prueba [FG99b]. a o Supongamos estos costos para un determinado caso de prueba: Manual Costo de prueba 10 minutos Automatizado 10 horas Testing Frecuencia de ejecuci´n o Una vez al mes Una vez al mes Costo primer a˜ o n Dos horas Costo en 5 a˜ os n 10 horas 120 horas Al menos 10 horas Cuadro 2.1: Ejemplo de retorno de la inversi´n de pruebas automatizadas. o Tendr´ que correrse esta prueba al menos cinco a˜os a una frecuencia de una vez ıa n por mes, para empezar a igualar los costos de la automatizaci´n. Por otra parte, o supongamos que el caso de prueba fuera muy dif´ de correr manualmente. ıcil Aunque se ejecute en diez minutos, es propenso a errores (por ejemplo, un formulario extenso con campos y validaciones complejas), y por lo tanto ese tiempo de ejecuci´n empieza en la pr´ctica a ser mucho mayor. En este caso, o a s´ valdr´ la pena automatizar. ı ıa Automatizaci´n de Diferentes Tipos de Pruebas o Cada tipo de prueba tiene ciertas particularidades que la hacen m´s o menos a recomendable de automatizar en cada contexto. Es necesario evaluar para un proyecto particular, los pros y contras de automatizar cierto tipo de prueba acorde a las caracter´ ısticas de los diferentes tipos de requisitos. Funcionalidades: son uno de los objetivos principales para el testing manual y automatizado. Las pruebas de funcionalidades consisten generalmente en interactuar con una interfaz gr´fica, proporcionarle entradas y esperar un a
  • 2.5. TESTING AUTOMATIZADO 33 resultado claro y visible; por lo tanto suelen ser las m´s f´ciles de automatizar a a (de contar con las herramientas adecuadas). Performance: este tipo de pruebas eval´an aspectos no funcionales de la u calidad del sistema, incluyendo la correcta respuesta del sistema frente a determinados vol´menes de carga, ejecutando sobre cierta infraestructura, u plataforma y configuraci´n. Simulan el uso real del sistema para verificar o que tanto el hardware, las configuraciones y el sistema en si, soporten el uso estimado. Son candidatas directas a la automatizaci´n8 . o Cualidades para-funcionales: a´n cuando los sistemas respondan correcu tamente acorde a sus requerimientos funcionales, puede ser que otro tipo de requerimientos no se est´n satisfaciendo: performance, mantenibilidad, portae bilidad, testeabilidad, usabilidad, entre otros9 . Muchos de estos requerimientos pueden apoyarse en pruebas automatizadas, pero otros requieren de la opini´n o de los usuarios, o de la inspecci´n manual. Por ejemplo, en usabilidad, un test o automatizado puede responder si el color que se muestra en la pantalla es el “#E1E4F2”, pero no puede decir si el color “#E1E4F2” se ve “desagradable” en determinado monitor. ¿Qu´ automatizar primero? e El objetivo sigue siendo obtener los mejores beneficios de la automatizaci´n. o Algunos de los factores a tomar en cuenta la hora de decidir cu´les pruebas se a van a automatizar: Las pruebas m´s importantes, de mayor prioridad. a Una muestra en amplitud del sistema. Pruebas de las funcionalidades m´s importantes. a Las pruebas m´s f´ciles de automatizar. a a Las pruebas que retornen la inversi´n m´s r´pidamente. o a a Pruebas que se ejecutar´n m´s frecuentemente. a a A la hora de automatizar es mejor ir de a peque˜as ´reas manejables, a la n a vez que se consolida la experiencia, obteniendo buenos resultados en corto per´ ıodo. Tratar de iniciar un gran proyecto de automatizaci´n sin tomar estas o precauciones, ni contar con la experiencia y los ajustes necesarios, puede tornar al proyecto en inmanejable, conduci´ndolo a un posible fracaso. e 8 Ver “performance”, “performance requeriment”, “performance specification” y “performance testing” en [IEE91] 9 Para m´s informaci´n, ver en el glosario de IEEE [IEE91], los t´rminos “performance”, a o e “maintainability”, “portability”, “testability” y “usability”.
  • 34 2.5.2. CAP´ ITULO 2. ESTADO DEL ARTE Criterios de Selecci´n de Herramientas de Automao tizaci´n o Elegir una herramienta de automatizaci´n de pruebas funcionales, es uno de los o puntos neur´lgicos para que un proyecto de automatizaci´n de testing tenga a o ´xito. No hay herramientas que solucionen todos los problemas, ni herramientas e perfectas para cualquier proyecto. El proceso de selecci´n puede ser tan formal o y detallado como lo requiera la dimensi´n del proyecto, y en todos los casos el o objetivo es llegar a la herramienta apropiada para la organizaci´n, que ser´ usao a da en forma efectiva y con el menor costo posible [FG99c]. En primer lugar, es necesario evaluar los requerimientos propios de la organizaci´n y no basarse en las recomendaciones del mercado. La forma en que la o herramienta es elegida es muy importante. Si se opta por la herramienta equivocada o que no cumple las expectativas, entonces se pueden enfrentar serios problemas al intentar hacerla funcionar en la organizaci´n. o Adem´s de elegir la herramienta correcta, se debe elegir en la forma correca ta. Esto es, puede ser que determinada herramienta cumpla con los requisitos t´cnicos y econ´micos, pero si las personas que la van a utilizar no participan e o en su proceso de selecci´n, entonces, puede suceder que se genere cierta resiso tencia a utilizarla, porque desde sus perspectivas, no se eligi´ la herramienta o correcta en definitiva. Por lo tanto, incluir a las personas que van utilizar´n la a herramienta en el equipo de selecci´n, es un factor muy importante a considerar. o Seleccionar la herramienta de automatizaci´n es un proyecto en s´ mismo, y o ı como tal se le debe asignar recursos humanos y materiales. No debe ser un proyecto de gran escala10 , pero puede afectar los cronogramas de otros proyectos, por tal motivo, no se recomienda encaminarlo cuando los tiempos de desarrollo y testing est´n muy comprometidos. a Para seleccionar la herramienta, se debe formar un equipo espec´ ıfico que trabajar´ en el proyecto de selecci´n y estar´ compuesto por un l´ a o a ıder y representantes de diferentes ´reas. a El l´ ıder es el responsable de gestionar el proceso de evaluaci´n y selecci´n. Debe o o contar con habilidades de gesti´n y ser capaz de construir un equipo de gente o de diferentes ´reas de la organizaci´n. Es ideal que sea alguien que tenga una a o visi´n global de la organizaci´n y sus integrantes; y que adem´s sea respetado. o o a Esta persona deber´ ser qui´n est´ m´s motivado con la incorporaci´n de la ıa e e a o automatizaci´n en la organizaci´n. o o 10 La bibliograf´ ıa menciona que un proyecto de selecci´n de herramienta para una o organizaci´n mediana, t´ o ıpicamente toma de cuatro a seis semanas/persona de esfuerzo, y puede involucrar de tres a diez personas.
  • 2.5. TESTING AUTOMATIZADO 35 El resto del equipo debe incluir representantes de cada ´rea que quiea ran automatizar sus pruebas. Puede contar con desarrolladores interesados en automatizar pruebas unitarias, usuarios que quieran automatizar pruebas de aceptaci´n. Entre los integrantes tambi´n pueden haber testers funcionales que o e quieran automatizar sus pruebas de regresi´n, automatizadores de testing, e o incluso l´ ıderes de proyecto, auditores internos de testing y coordinadores de testing, entre otros. Identificar los requerimientos de la organizaci´n implica reconocer los proo blemas a solucionar. Muchos inconvenientes pueden tener que ver con el testing, o pueden ser restricciones tecnol´gicas y no tecnol´gicas a la decisi´n de la heo o o rramienta a elegir. Un primer paso es elaborar una lista de problemas, los cuales pueden ser solucionados (o f´cilmente manejables) con la incorporaci´n de una herramiena o ta. Lograr una especificaci´n de los problemas, asegura que los integrantes del o equipo est´n alineados en el camino de la automatizaci´n y que son capaces de a o detallar sus requerimientos de automatizaci´n (si no se pueden especificar las o necesidades, es poco probable que se puedan solucionar por el mero hecho de incorporar una herramienta). Algunos ejemplos de ´ ıtems que podr´ estar presentes en una lista de problemas ıan a solucionar: 1. Problemas de testing manual: lleva mucho tiempo, es una tarea repetitiva y fatigante o acarrea muchos errores humanos (en comparar resultados por ejemplo). 2. No hay tiempo para pruebas de regresi´n: por ejemplo, al tener o muchos cambios en el producto, o tiempos de desarrollo muy inferiores a los de la ejecuci´n de pruebas de regresi´n. o o 3. Configuraci´n de datos de pruebas o casos de prueba es muy o propenso a errores. 4. La documentaci´n no es adecuada para el testing. o 5. Se carece de informaci´n acerca del software a probar. o 6. El testing no es efectivo Luego de elaborada la lista, habr´ que ordenarlos por importancia y cuanto ıa cuestan para la organizaci´n. Todos estos problemas no tiene por qu´ ser soluo e cionables por herramientas de automatizaci´n de pruebas, pero puede ser que se o trate mejor con ellos al contar con las adecuadas. Por otra parte, es importante tener alternativas a la automatizaci´n, explorar diferentes soluciones, dado o que para determinados contextos puede ser que una soluci´n que no incluya o
  • CAP´ ITULO 2. ESTADO DEL ARTE 36 herramientas, sea m´s efectiva y menos costosa. Inclusive, los problemas deteca tados indican que en realidad son necesarios ajustes a ciertas ´reas, en lugar de a automatizar pruebas. Identificar las restricciones de la organizaci´n es el paso siguiente. A´ n o u cuando se tengan claros los problemas y las posibles soluciones, no vale la pena invertir recursos en investigar herramientas que ser´n descartadas en primera a instancia. Posibles restricciones: 1. Restricciones de ambientes: hardware disponible, y necesario para la herramienta; software de base (sistemas operativos libres y propietarios, manejadores de bases de datos). 2. Integraci´n e interacci´n con el software a probar: si la herramienta o o debe convivir con el software en el mismo ambiente, puede ser necesario prestar atenci´n al nivel de intrusi´n de la herramienta en el uso de los o o recursos. 3. Restricciones de proveedores comerciales: el soporte comercial de la herramienta ante cualquier problema puede ser un factor decisivo a la hora de seleccionar una. Pesan elementos como la experiencia de otras organizaciones con la herramienta, la permanencia en el mercado del proveedor, la historia de la herramienta. 4. Restricciones de costo: estas restricciones van desde el costo de la herramienta por licencia, por equipo, por uso, costo del soporte t´cnico e adicional, hasta el costo de aprendizaje de la herramienta para los futuros usuarios. 5. Restricciones pol´ ıticas: puede ser que existan restricciones de este tipo, que suelen estar por encima de las otras en ocasiones. Por ejemplo, se puede tener cierta restricci´n a adquirir herramientas creadas por partners o o en determinada regi´n geogr´fica, o pertenecientes a cierta asociaci´n. o a o Descuidar los factores pol´ ıticos es un grave error. 6. Restricciones de calidad: pueden ir desde requerimientos funcionales, hasta aspectos no funcionales. Facilidad de uso, facilidad de aprendizaje, cantidad de usuarios simult´neos que soporta, frecuencia de fallas, a confiabilidad en el manejo de los datos, interoperabilidad con otras herramientas; son algunos de los atributos que pueden requerirse. Habiendo cumplido las restricciones, es aconsejable elaborar una lista de caracter´ ısticas que las herramientas deben cumplir. Al menos deber´ ser ıa una lista con dos categor´ ıas: caracter´ ısticas excluyentes, y caracter´ ısticas no excluyentes. Para evaluar las caracter´ ısticas de las herramientas, se pueden usar categor´ como: ıas
  • 2.5. TESTING AUTOMATIZADO 37 1. Caracter´ ısticas Excluyentes: la herramienta seleccionada debe contar con estas caracter´ ısticas para ser considerada. 2. Caracter´ ısticas Deseables: esta categor´ puede ser usada para ıa comparar entre herramientas que cubren las funcionalidades esperadas. 3. Caracter´ ısticas que no interesan: muchas herramientas pueden incluir buenas caracter´ ısticas desde el punto de vista del marketing, pero que realmente aportan poco a la funcionalidad en s´ o simplemente no aplican ı, a la realidad de las necesidad de automatizaci´n de la organizaci´n. o o 4. Caracter´ ısticas que cambian de categor´ en el proceso de selecci´n ıa: o de herramientas puede suceder que la lista de caracter´ ısticas cambie, que surjan nuevas, o que algunas categor´ cambien de una a otras. ıas 5. Tipos de caracter´ ısticas: existen caracter´ ısticas que pueden estar ausentes o no; y de ser necesaria su presencia en la herramienta, se puede descartar en el proceso. Pero otras caracter´ ısticas pueden estar presentes en mayor o menor medida. Atributos como la facilidad de uso o aprendizaje, pueden ser expresados en alguna escala. No es dif´ conseguir una gran lista de proveedores y herramientas. El ıcil siguiente trabajo consiste en considerar las restricciones y controlar la lista de caracter´ ısticas para construir una lista corta de herramientas candidatas. Cada herramienta de la lista candidata es evaluada frente a las dem´s. Las a herramientas de lista corta son comparadas una contra otra en detalle. Es de ayuda contar con reportes de evaluaci´n y sitios de referencia, para tener una o idea de las experiencias de otras personas con las herramientas. Si es apropiado, se organizan demostraciones in situ con cada vendedor. Las herramientas deben ser testeadas con casos de pruebas realistas, debe ser tenido en cuenta el manteamiento de los casos de prueba para cuando el software cambia y si se necesita se puede evaluar y contrastar las dos herramientas identificadas con mejores prestaciones. La decisi´n de compra debe ser basada en un caso de o negocio, desde una relaci´n de costo beneficio previamente estimada. o 2.5.3. Tipos de Herramientas Para Apoyar al Testing En la figura 2.5, vemos un modelo V simplificado, que adem´s est´ subdividido y a a relacionado con las diferentes clases de herramientas que pueden brindar apoyo a las actividades de testing [FG99d].
  • 38 CAP´ ITULO 2. ESTADO DEL ARTE Figura 2.5: Modelo V y los diferentes tipos de herramientas relacionadas. Herramientas de dise˜ o: ayudan a derivar entradas o datos para el testing n a trav´s del modelado de las diferentes partes o funcionalidades del sistema. e Herramientas de dise˜ o l´gico: son tambi´n conocidas como generadores n o e de casos de prueba, y logran derivar casos de prueba a partir de cierta especificaci´n l´gica, una interfaz, o desde c´digo. Un ejemplo ser´ una o o o ıa herramienta que dada una especificaci´n, nos genere entradas para testear dicha o l´gica. o Herramientas de dise˜ o f´ n ısico: manipulan datos existentes o generan datos para las pruebas. Por ejemplo, una herramienta que pueda extraer registros aleatorios de una base de datos, o poblar autom´ticamente con datos de prueba a generados con alg´n criterio. u Herramientas de gesti´n de testing: van desde las herramientas para o asistir en la planificaci´n, hasta las que mantienen una trazabilidad entre o requerimientos, casos de prueba ejecutados, e incidentes detectados. Entre los ejemplos m´s comunes, est´n las herramientas de gesti´n en prop´sito general, a a o o y las m´s espec´ a ıficas como las de reporte y seguimiento de defectos, mejorando la trazabilidad de las pruebas a requerimientos, dise˜o y c´digo. n o Herramientas de an´lisis est´ticos de c´digo: este tipo de herramientas a a o detectan cierto tipo de defectos en el c´digo fuente, mucho m´s efectivamente o a que otros tipos de ejecuci´n. o
  • 2.5. TESTING AUTOMATIZADO 39 Herramientas de cobertura: responden cuanto ha sido probado el software dado un conjunto de casos de prueba. Son com´nmente usadas a nivel de testing u unitario. Por ejemplo, dado un caso de prueba en x-Unit, y un criterio de cobertura de decisi´n, la herramienta nos puede decir si nuestros casos de prueba o satisfacen dicho criterio para el c´digo ensayado. A nivel de requerimientos, hay o herramientas que pueden apoyar el seguimiento de las diferentes funcionalidades alcanzadas en un determinado momento por el equipo de prueba11 . Herramientas de depuraci´n: permiten ir paso a paso dentro del c´digo o o controlando la ejecuci´n, inclusive sentencia a sentencia; permitiendo controlar o el estado de las variables. No son realmente herramientas de testing, dado que la depuraci´n no es parte del testing12 . Sin embargo, estas herramientas son o utilizadas en testing en ciertas ocasiones, por ejemplo, cuando se intenta aislar un defecto a muy bajo nivel. Herramientas de an´lisis din´mico: inspeccionan el sistema en tiempo a a de ejecuci´n, recopilando informaci´n acerca de utilizaci´n de los recursos o o o (memoria, procesador, y caracter´ ısticas especiales del sistema operativo). Por ejemplo, herramientas que detectan memory leaks 13 en tiempo de ejecuci´n. o Simuladores: son herramientas que habilitan probar partes de sistemas de maneras que no ser´ posible en el mundo real, o ser´ muy dif´ de lograr. ıa ıa ıcil Por ejemplo, la ejecuci´n simult´nea de cientos de usuarios concurrentes en un o a sistema web. Herramientas de testing de performance: miden el tiempo tomado por un conjunto de eventos. Por ejemplo pueden medir la respuesta de un sistema ante condiciones t´ ıpicas o extremas. Herramientas de carga: generan tr´fico en el sistema. Por ejemplo, pueden a generar un n´mero de transacciones que representen una cantidad promedio, o u picos m´ximos. Pueden ser usadas para pruebas de estr´s14. a e Herramientas de ejecuci´n y comparaci´n: Comparaci´n los resultados o o o obtenidos con los esperados autom´ticamente. Este tipo de herramientas aplican a para ejecuci´n de testing a cualquier nivel. o 11 Una herramienta para gestionar y obtener mediciones acerca de la cobertura de las pruebas se encuentra en la web de satisfice http://www.satisfice.com/sbtm/sessions.exe 12 Testing identifica los defectos, y la depuraci´n los remueve. Por este motivo, la depuraci´n o o es una actividad de desarrollo y no de testing. 13 Memory leak sucede cuando un programa no libera los bloques de memoria cuando debe. En un caso extremo, si el programa se apodera de toda la memoria libre, no quedar´ espacio ıa disponible para la carga de otros programas, causando que el sistema se bloquee. 14 Seg´ n [IEE91], las pruebas de estr´s (“stress testing”) es el testing que eval´ a el sistema u e u al l´ ımite, o m´s de los l´ a ımites especificados en los requerimientos.
  • CAP´ ITULO 2. ESTADO DEL ARTE 40 2.5.4. Limitaciones del Testing Automatizado Es importante tener en cuenta que la automatizaci´n no es la soluci´n perfecta o o para todas las situaciones. Incluso hay situaciones donde ser´ dificultoso a recuperar la inversi´n en automatizaci´n. A continuaci´n se nombran alguna o o o limitaciones de la automatizaci´n [FG99e]. o La Automatizaci´n no Reemplaza al Testing Manual o No es posible ni deseable, automatizar todas las actividades de testing. Siempre habr´ algo que es mucho m´s f´cil de hacer manualmente que autom´ticamente. a a a a O que es muy dif´ de automatizar, y en definitiva implica que no es redituable ıcil econ´micamente encarar la automatizaci´n. o o Es probable que algunas pruebas no deban ser automatizadas: 1. Pruebas que correr´n raramente una vez. Por ejemplo si una prueba se a corre una vez al a˜o; probablemente no valga la pena automatizarla n 2. Cuando el software es muy vol´til. Por ejemplo, si la interfaz gr´fica y la a a funcionalidad cambia m´s all´ de lo que se puede reconocer de una versi´n a a o a la siguiente, entonces el esfuerzo de cambiar las pruebas automatizadas correspondientes probablemente no sea redituable en cuanto a costo. 3. Cuando los resultados son f´cilmente verificables por un humano, pero es a dif´ ıcil, o cercano a imposible de automatizar. Por ejemplo, la correctitud de un esquema de colores, la apariencia est´tica de una distribuci´n de e o la pantalla, o cuando el sonido correcto se escucha cuando un objeto es seleccionado. 4. Pruebas que involucren interacci´n f´ o ısica, tales como deslizar una tarjeta a trav´s de un lector, desconectar alg´n equipo, interactuar con dispositivos e u electromec´nicos. a No todo el testing manual debe automatizarse, solo los mejores, o aquellos que se van a correr frecuentemente. Cuando el software es inestable, el testing manual encuentra m´s defectos que a el testing automatizado. El Testing Manual Encuentra m´s Defectos que el Testing Automaa tizado Es m´s probable que una prueba manual encuentre defectos la primera vez que a se corre. En cambio, una prueba automatizada tendr´ que ejecutarse varias a veces para verificar su correctitud. La prueba automatizada, esta destinada a permanecer dentro de ciertos par´metros fijos, o a lo sumo, consumir diversas a fuentes de datos.
  • 2.6. TESTEABILIDAD 41 Gran Dependencia de la Calidad de las Pruebas Una herramienta s´lo puede identificar diferencias entre la salida actual y la o esperada. Por lo tanto, se debe invertir en la tarea de verificar la correctitud de las salidas esperadas en el testing automatizado. Es decir, la calidad de las pruebas automatizadas tiene que ser confiable. Las pruebas automatizadas pueden ser revisadas e inspeccionadas para asegurar su calidad. La inspecci´n es o la forma de revisi´n m´s poderosa y es muy efectiva al usarse en documentaci´n o a o de testing. La Automatizaci´n no Mejora la Efectividad o Automatizar un conjunto de pruebas no las hace m´s efectivas (o ejemplares) que a aquellos mismos tests corridos manualmente. La automatizaci´n puede mejorar o la eficiencia de los tests, es decir, cu´nto cuesta correrlos o cu´nto tiempo toma a a correrlos. La Automatizaci´n Puede Limitar el Desarrollo de Software o El testing automatizado es m´s fr´gil que el testing manual. Las pruebas aua a tomatizadas pueden ser afectadas por cambios inocuos en el software. Requiere mucho m´s trabajo configurar las pruebas automatizadas que las manuales y a el esfuerzo en mantenimiento es mucho mayor tambi´n. Muchas veces, esto se e vuelve una restricci´n a cambiar o mejorar el sistema bajo pruebas. o En ocasiones es conveniente desalentar a la inclusi´n en el software de cambios o con alto impacto en la automatizaci´n, por razones econ´micas. o o Las Herramientas no Tienen Imaginaci´n o Una herramienta es s´lo software, y por lo tanto lo unico que puede hacer es o ´ ejecutar instrucciones obedientemente. Ambas, herramientas y tester, pueden seguir instrucciones para ejecutar un conjunto de casos, pero una persona puede comportarse diferente para una misma tarea, por ejemplo derivando nuevos casos de prueba dada una situaci´n, aplicando la creatividad, evaluando o la conveniencia de ejecutar cierta parte del sistema en el momento mismo de la ejecuci´n (lo cual es un comportamiento muy dif´ de modelar para o ıcil una herramienta, sino imposible). Por ejemplo, los humanos pueden decidir y reaccionar ante situaciones inesperadas de una secuencia de pasos definida. 2.6. Testeabilidad Uno de los t´rminos menos utilizados en las actividades que involucran desarrollo e de software y testing, es “testeabilidad” (“testability”). ¿C´mo construir un software, pensando en que alguien lo tiene que probar? o
  • CAP´ ITULO 2. ESTADO DEL ARTE 42 ¿Cu´l es la probabilidad de que un software falle?, ¿Cu´l es la probabilidad a a de que este software falle si contiene un defecto? ¿Qu´ tipo de testing puedo mejorar? e ¿Hay alguna medida relativa a la testeabilidad?, por ejemplo, ¿Se puede medir el aumento de la testeabilidad? ¿Hay factores que obstaculizan el testing? Estas interrogantes, entre otras, est´n relacionadas con el aporte que nos puede a dar manejar el concepto de testeabilidad en sus diferentes acepciones. 2.6.1. Concepto de Testeabilidad Podemos interpretar a la testeabilidad como la facilidad con la que un software es probado. O asistiendo a la terminaci´n -bilidad [Aca01], del idioma o espa˜ol, ser´ la capacidad con la que un software puede ser probado, en un den ıa terminado contexto15 . La IEEE aporta una definici´n bastante estricta, [IEE91] o que refiere a la facilidad con la que un software nos permite establecer criterios de testing, y c´mo se pueden ejecutar los casos de prueba, y as´ medir si o ı se han alcanzado esos criterios. La discusi´n se mover´ al plano entonces, de o ıa cu´les ser´ estos criterios y c´mo establecer la medici´n. El est´ndar SQuaRE a ıan o o a ISO/IEC 25000(SQuaRE) [20005], define el t´rmino testeabilidad 16 como una e sub-caracter´ ıstica del atributo de calidad referente a la facilidad de mantenimiento17 . En t´rminos m´s pr´cticos, otro grupo de autores est´n alineados con la idea e a a a de que todo aquello que hace m´s f´cil la tarea de testear un software, ya sea a a porque es m´s f´cil dise˜ar los casos de prueba, o podemos testar de forma m´s a a n a eficiente; favorece la testeabilidad [Bol09]. En definitiva, mediante estos enfoques, podemos decir que: Testeabilidad es la capacidad que tiene un software de ser probado, en un determinado contexto. Acorde con estas ideas, diremos que un software con mejor capacidad de ser probado en un contexto, es m´s testeable. Y como consecuencia, un software a m´s testeable, requiere menos esfuerzo de testing. a 15 Se esta tomando la palabra testeabilidad, dado que es el t´rmino que se usa coloquialmente, e aunque no exista en el idioma espa˜ol. n 16 Referido en [20005] como “testability” 17 Referido en [20005] como “maintainability”
  • 2.6. TESTEABILIDAD 43 Testeabilidad como Visibilidad y Control Otro enfoque de otro de los autores, dice que hablar de testeabilidad es hablar en t´rminos de visibilidad y control sobre el software [Pet09]. e Visibilidad, es la capacidad de observar los estados, salidas, recursos usados y otros efectos secundarios del sistema que estamos probando, y Control es la capacidad que tenemos de poder darle entradas al sistema o situarlo en diferentes estados conocidos. Para concretizar, supongamos que tenemos un proceso batch, con cierta oscuridad hacia el testing, es decir, no sabemos mucho acerca de las entradas, las salidas, ni los diferentes estados. Supongamos que existen adem´s, c´lculos a a complejos. Entonces, algunos ejemplos de testeabilidad, como visibilidad y control: Visibilidad “Hago visible” cierta parte de c´digo asegur´ndonos que el testing o a est´ ejecut´ndola. a a “Hago visible” los resultados, valores de diferentes variables, campos relevantes. “Hago visible” las variables de entrada de cierto c´digo. o “Hago visible” los datos que tomar´, o sobre los que actuar´ el proceso a a (puede ser mediante una grilla que representa el estado actual de cierta tabla, o cierto conjunto de datos). Control Puedo ejecutar el proceso. Puedo controlar los diferentes estados del proceso, ya sea modificando valores en tiempo de ejecuci´n o cambiando el contexto. o Puedo pasar par´metros al proceso, simulando condiciones espec´ a ıficas de ejecuci´n. o Puedo dar entradas, o modificar las entradas, de donde el proceso va a tomar los datos. En el entendido anterior, podemos pensar en la testeabilidad desde el dise˜ o, lo n que favorecer´ la interrelaci´n del equipo y adem´s reducir´ los costos. ıa o a ıa
  • CAP´ ITULO 2. ESTADO DEL ARTE 44 Ejecuci´n, Defectos y Propagaci´n o o Voas & Miller, definen la testeabilidad en t´rminos probabil´ e ısticos[Mil95], motivados por la experiencia ante la interacci´n con sistemas cr´ o ıticos, donde se tiene que hacer ´nfasis en la confiabilidad de los sistemas. Por ejemplo, sistee mas de misiones espaciales, que comanden un transbordador, o similar. Como en el est´ndar sobre Reliability de IEEE [IEE06], se busca predecir, dada las a caracter´ ısticas del sistema, cu´l es el tiempo para que ocurra una pr´xima falla, a o el tiempo medio entre fallas, tratando de predecir que la falla no ocurra dentro del tiempo destinado a una misi´n. Tal rigurosidad se aplica, en general, a este o tipo de sistemas cr´ ıticos. Estos autores se han estudiado y modelado c´mo los errores se “esconden del o testing”, manejando t´rminos de “enmascarado de errores” (error masking en e la bibliograf´ y la p´rdida de informaci´n en el transcurso de la ejecuci´n de ıa), e o o los casos de prueba. Se refiere a que, en ocasiones, un software es ejecutado, el software contiene defectos, pero como consecuencia de ello, no se manifiesta una falla u error observable en el sistema. Es decir, como caracter´ ıstica conjunta del software con defecto, el contexto y determinado conjunto de casos de prueba, no se manifiesta una falla. Aumentar la testeabilidad, es aumentar la probabilidad de dado un conjunto de casos de prueba, un contexto y un software con defecto, dicho defecto se propague una falla. En los art´ ıculos referenciados, se cita el ejemplo de la divisi´n entera, donde o claramente se pierde informaci´n, dado que la divisi´n de cuatro entre dos, da o o el mismo resultado que cinco entre dos. 2.6.2. Dise˜ ar para la Testeabilidad n En el art´ ıculo “Design for Testability” [Pet09] que hemos estado citando, se maneja adem´s c´mo se puede relacionar la testeabilidad y el dise˜ o del a o n producto, desde dos perspectivas: “desde dentro” y “por fuera”. Dise˜ ar para la Testeabilidad desde Dentro. n Dise˜ar para la testeabilidad, es construir el software pensando que alguien n tiene que probarlo. Aportar visibilidad y control desde el dise˜ o, identificando n las necesidades del testing, construyendo puntos de verificaci´n, trazas y log de o eventos, monitoreos, interfaces de testing en general. Dise˜ ar para la Testeabilidad por Fuera n El no tener presente la testeabilidad desde la concepci´n o desde el dise˜ o o n del producto, no es impedimento para obtener beneficios de este concepto. Es posible brindar visibilidad y control con construcciones externas al software, ya sea mediante interfaces gr´ficas que controlen ciertas variables, o que a muestren resultados o diferentes estados de las variables. Pero, no solamente
  • 2.6. TESTEABILIDAD 45 es necesario contar con complejas piezas de software, sino que muchas veces los desarrolladores en sus pruebas de integraci´n o modulares elaboran sus o propias herramientas que les hacen m´s f´cil la tarea de probar sus c´digos, a a o y ese material puede ser en muchas ocasiones reutilizado por el tester. Incluso, los usuarios suelen construirse herramientas para apoyar sus tareas diarias, en planillas electr´nicas por ejemplo; informaci´n que es de extrema utilidad al o o tester, dado que puede llegar a motivar nuevas pruebas, enriquecer los or´culos a y en definitiva facilitar la tarea de testear el software. 2.6.3. Dise˜ ar para la Testeabilidad de la Automatizaci´n n o Verificar software que no ha sido dise˜ado para que sea f´cil de testear requiere n a mucho m´s esfuerzo. Por ejemplo, si el sistema genera un conjunto complejo de a datos, hace validaciones de las entradas de usuarios y chequeo cruzado de valores, antes de ingresar un conjunto de datos a la base o alg´n sistema, entonces u puede ser util verificar esos datos justo antes de que sean enviados. Es decir, es ´ m´s f´cil verificar estos datos justo en la salida, que cuando ya est´n ingresados a a a en diferentes lugares en la base de datos [FG99f]. Acceder a datos intermedios es una forma de colocar “test hooks” (“arn´s” o e “gancho” de testing podr´ ser posibles traducciones)18 . de donde se puede serıan vir la automatizaci´n para simplificar la verificaci´n. La cantidad de estos test o o hooks y su granularidad, determinan cu´n testeable es el sistema. Adem´s, estos a a puntos de acceso a datos intermedios aportan informaci´n. Un testing carente o de informaci´n se torna poco eficiente y poco efectivo. o El software bajo prueba, tambi´n puede ser mejorado en pro de la automatizae ci´n. Por ejemplo, si la aplicaci´n incluye un “modo testing” o similar, donde o o se pueda consumir datos desde un archivo en lugar de la pantalla, entonces la aplicaci´n puede configurarse incluso para adelantar camino en la automatizao ci´n, como si se “testease a si misma” mediante configuraciones especiales en o un archivo. El mejor camino para aportar testeabilidad es pensar acera de c´mo va a ser o verificado el software desde los inicios, desde el dise˜o y en la implementaci´n. n o Pensar qu´ debe ser testeado y c´mo puede ser testeado puede resultar en e o mejores dise˜os y mejores aplicaciones, y adem´s ayudar´ a las tareas de n a a depuraci´n de c´digo. o o 2.6.4. Discusiones sobre Testeabilidad A continuaci´n mencionamos brevemente c´mo se relacionan testeabilidad y o o seguridad, y luego discutiremos algunos beneficios que nos puede brindar la testeabilidad. 18 Una definici´n m´s precisa en [IEE91], bajo “test harness” o “test driver”. o a
  • 46 CAP´ ITULO 2. ESTADO DEL ARTE Interfaces de Testing y Seguridad Un tema importante, es que las interfaces de testing pueden transformarse en baches de seguridad. Es necesario prestar especial atenci´n a las construcciones o espec´ ıficas de testing, que aportan m´s informaci´n que la que las pol´ a o ıticas de seguridad de una organizaci´n quiere o debe revelar, para que no lleguen o finalmente a producci´n, y que adem´s, su no inclusi´n, u ocultaci´n no ocasione o a o o nuevos incidentes, ni sea f´cil de “quebrar”. Imaginemos que contamos con una a interfaz de testing que monitorea los estados de una transacci´n bancaria, y o por alg´n motivo la ocultamos en producci´n, y alg´n atacante puede tomar su u o u control; claramente, estamos ante un muy grave agujero de seguridad que puede evitarse f´cilmente teniendo control sobre cu´les son las interfaces de testing y a a c´mo y cu´ndo est´n disponibles. o a a Beneficios de la Testeabilidad Del an´lisis de la bibliograf´ y derivado de la experiencia, podemos concluir a ıa, un conjunto interesante de beneficios relacionados con la testeabilidad. Como ser la obtenci´n de productos m´s testeables o m´s f´ciles de probar, o a a a en un determinado contexto, redundando en que es posible enfocar el trabajo en encontrar los errores m´s importantes, presumiblemente, de manera m´s a a temprana. Logramos interfaces m´s f´ciles de automatizar y guionar, m´s a a a puntos de verificaci´n, m´s lugares de donde la automatizaci´n se pueda o a o servir, mejorando en eficiencia. Los testers encuentran un buen camino para incrementar sus habilidades t´cnicas, y poder crear sus propias herramientas. e La comunicaci´n y la colaboraci´n mejoran, lo que favorece la consolidaci´n o o o del equipo. Los documentos y reportes de incidentes se vuelven m´s certeros a y claros, as´ como tambi´n aquellos interesados, o l´ ı e ıderes, quienes tengan que tomar decisiones basados en informes de testing, obtienen mejor y m´s relea vante informaci´n. o Podr´ ıamos incluso, hasta llegar a hablar de requerimientos de testeabilidad, por ejemplo, para que las organizaciones incluyan en sus licitaciones19 . En definitiva, estamos logrando un mejor compromiso con la calidad, reforzando el fin com´n de tener un mejor producto. u 19 Es cada vez m´s com´ n que las organizaciones adquieran productos adaptables, en lugar a u de soluciones llave en mano, dada la complejidad de los dominios actuales. Sobre todo para complejos productos de gran porte. Usualmente la implementaci´n de estos productos en una o organizaci´n es un proceso largo y costoso, que involucra desarrollo particular. Contar con o requerimientos de testeabilidad puede ayudar al desarrollo del proceso de implantaci´n. o
  • 2.6. TESTEABILIDAD 47 Enumerando algunos de los beneficios (categorizados por actor implicado) podemos mencionar: Para los Testers • Obtener productos m´s testeables o m´s f´ciles de testear. a a a • Enfocar su trabajo en encontrar los errores m´s importantes. a • Poder automatizar una interfaz m´s f´cilmente. a a • Desarrollar sus habilidades t´cnicas, crear. e • Mejor comunicaci´n con el equipo de desarrollo entendiendo el dise˜ o o n del software revisando dando a conocer las funcionalidades que necesita. Para los Desarrolladores • No reciben reportes de incidentes triviales. • Mejor comunicaci´n con los t´cnicos de testing. o e • Mejores reportes de incidentes, reportes m´s claros, con m´s a a informaci´n, m´s detallados. o a • Considerando la testeabilidad en el dise˜o. n • Compartiendo conocimiento. ◦ C´digo. o ◦ Documentos de dise˜o. n ◦ Cat´logos de error, entre otros. a L´ ıderes de Proyecto • Equipo m´s s´lido y colaborativo. a o • Un mejor compromiso con la calidad del producto, reforzando el fin com´n. u • Informaci´n m´s relevante para la toma de decisiones en cuanto a los o a incidentes, coberturas, entre otros.
  • 48 2.7. CAP´ ITULO 2. ESTADO DEL ARTE Discusi´n: Testing Manual y Automatizado o “Lo mejor de los dos mundos” Presentamos en esta secci´n algunas consideraciones entre el testing manual y o automatizado. Analizando qu´ relaci´n existe entre la calidad de un caso de e o prueba y su automatizaci´n, y qu´ consecuencias tiene esto para el testing. o e 2.7.1. Relaci´n entre Testing Manual y Automatizado o Antes de contrastar ambos conceptos, hablaremos de los Atributos de Calidad de un Caso de Prueba, [FG99g], lo que aportar´ precisi´n a la comparaci´n. a o o Ya sea un caso de prueba rigurosamente derivado de la aplicaci´n de alguna o t´cnica, sea generado autom´ticamente por alg´n algoritmo, o provenga de e a u la creatividad de un tester aplicando estrategias exploratorias; en t´rminos e generales, podemos definir la calidad de un caso de prueba en los siguientes cuatro atributos: Efectividad para encontrar defectos. Es uno de los m´s importantes a atributos, y refiere a si el test encuentra o no defectos, o al menos si tiene alguna probabilidad de encontrar defectos. Atributo de Ejemplaridad. Este atributo habla de cuando un caso de prueba abarca m´s de un aspecto del software a la vez, lo cual favorece a que el a conjunto de casos de prueba final tenga menos elementos. Atributo econ´mico de un caso de prueba. Mediante este atributo se o expresa que tan econ´mico es ejecutar, analizar y depurar un caso de o prueba. Caso de prueba Evolucionable. Por ultimo, este atributo nos dice en ´ qu´ medida el caso de prueba es mantenible, adaptable, evolucionable e acorde a los cambios del software. Hay autores que manifiestan que un caso de prueba que no cambia con las sucesivas versiones de un producto, pierde efectividad, dado que a lo sumo encontrar´ la misma clase de incidentes a que encontr´ en un principio [Bac02]20 . o Si bien la calidad es un concepto de dif´ medici´n; para un contexto dado, ıcil o se busca seleccionar un conjunto de casos de prueba que balancee estos cuatro atributos, en pro de encontrar la mayor cantidad de defectos a un costo razonable. Como es sabido, es imposible o cercanamente imposible ejercitar todos los casos de prueba a´n para una pieza muy sencilla de c´digo [Mye04b]21 . Con los a˜ os, u o n 20 Bajo la secci´n “Exploratory Testing is a Profoundly Situational Practice”, p´gina cuatro o a de la versi´n 1.3 del art´ o ıculo. 21 Myers muestra la discusi´n un ejemplo muy sencillo de un tri´ngulo, que tiene una o a cantidad inabarcable de casos de prueba.
  • ´ 2.7. DISCUSION: TESTING MANUAL Y AUTOMATIZADO 49 el software se ha vuelto cada vez m´s complejo, y la cantidad de combinaciones, a situaciones, y en definitiva, casos de prueba es pr´cticamente infinita para un a software dado en determinado contexto. El testing manual, tiene gran parte de su ´xito comprometido en la habilidad de seleccionar de ese universo de e casos de prueba, el subconjunto m´s adecuado; que detecte la mayor cantidad a de defectos posible en el software, dadas las circunstancias (consideraciones del negocio, cobertura, tiempo disponible, entre otros). En definitiva, la destreza en el testing manual radica en balancear los cuatro atributos de calidad de un caso de prueba (caso de prueba efectivo, ejemplar, econ´mico, evolucionable), logrando que los casos de prueba a ejecutar encueno tren una gran proporci´n de defectos a un costo “razonable”. o La habilidad requerida para el testing automatizado, y su aporte difiere enormemente del testing manual. Es f´cil notar que el costo de automatizar una a prueba, es bastante m´s alto que el costo de ejecutarlo manualmente; simplea mente desde el hecho de que alguien se tiene que dedicar a especificar los pasos y los detalles de la ejecuci´n de las pruebas, puntos de verificaci´n, resultados o o esperados, entre otros; y ese costo es al menos igual o mayor que el costo de ejecutarlo una vez manualmente. La experiencia indica que el costo de automatizar, es bastante alto, por lo tanto las pruebas a automatizar deben ser elegidas cuidadosamente. El punto a dejar en claro es que la calidad de la automatizaci´n, es indeo pendiente de la calidad de las pruebas. Es decir, un caso de prueba que no es efectivo, al ser automatizado, no cambiar´ este atributo, solamente se a ejecutar´ m´s r´pido; pero seguir´ siendo pobre en efectividad. a a a a La gran diferencia de peso es que, una vez automatizado, un caso de prueba se vuelve mucho m´s econ´mico. Es de esperar, naturalmente, que con las a o sucesivas pruebas, el costo de correr el caso de prueba automatizado, sea extremadamente menor al de correr la misma prueba manualmente. Por otra parte, es mucho m´s costoso crear, mantener y evolucionar las pruebas automatizadas. a Es conveniente que se dedique esfuerzo a las primeras etapas de la automatizaci´n, seleccionando los casos de pruebas adecuados, con el fin de abaratar costos o de mantenimiento en el futuro. Las pruebas automatizadas tambi´n son softwae re, por lo tanto implican verificaci´n y mantenimiento. Si este trabajo se vuelve o muy costoso, la prueba automatizada empieza a perder fuerza como alternativa a la prueba manual. El insumo fundamental para conseguir un buen conjunto de pruebas automatizadas, es partir de “buenos casos de prueba” 22 . 22 Por ejemplo en el entendido de los cuatro atributos de calidad de un caso de prueba, antes mencionados.
  • CAP´ ITULO 2. ESTADO DEL ARTE 50 El encargado de implementar y mantener las pruebas automatizadas, es el “automatizador de pruebas” o “tester automatizador”. Inclusive, este rol puede ser llevado adelante por una persona con habilidades t´cnicas de desarrollo, dae do que, si est´ bien especificada la prueba, pueden implementar el c´digo de la a o prueba automatizada sin grandes inconvenientes. Inclusive, si los testers carecen de conocimiento t´cnico, de todas formas, se puede trabajar en esta din´mica e a conjunta de definici´n de los casos de prueba desde la perspectiva del negocio o e implementaci´n de los mismos desde el punto de vista de la programaci´n de o o las pruebas automatizadas. Como conclusi´n, la buena o mala calidad del testing automatizado, es o independiente de la buena o mala calidad de la automatizaci´n. Si el o automatizador de testing logra pruebas f´ciles de mantener y consigue que a sea posible agregar nuevas pruebas a las suites con facilidad; entonces la automatizaci´n brindar´ mejores beneficios (atributo econ´mico, y atributo o a o evolucionable), lo cual no quiere decir nada acerca de cuan ejemplares, y efectivos sean los casos de prueba. 2.8. Resumen En este cap´ ıtulo hemos presentado una s´ ıntesis del estado del arte del testing funcional, mostrando modelos de mejora de procesos de testing, procesos de testing, estrategias y otros temas. Inspirados en estos temas y en el marco de la reestructura del ´rea de testing de ASSE; planteamos el desafi´ de crear a o una metodolog´ particular que se ajuste a las necesidades de ASSE en cuanto a ıa testing funcional. El cap´ ıtulo siguiente, muestra un informe de diagn´stico inicial o de la situaci´n de ASSE en cuanto al testing funcional. Luego en el cap´ o ıtulo 4 se detalla la metodolog´ desarrollada a partir del estado del arte en testing ıa funcional y el diagn´stico inicial de la organizaci´n. o o
  • Cap´ ıtulo 3 Informe de An´lisis y a Diagnostico Inicial 3.1. Introducci´n o En este cap´ ıtulo se detallan las tareas desarrolladas y las conclusiones obtenidas para estudiar el departamento de pruebas de ASSE en relaci´n con los proyeco tos de desarrollo, tomando como caso de estudio el Sistema de Gesti´n de Salud o (SGS) principalmente. Para estudiar la organizaci´n se desarrollaron reuniones con personal involucrao do con el SGS, lo que aporta informaci´n para profundizar en el an´lisis, obo a teniendo adem´s propuestas por parte de los integrantes de ASSE, trabajando a en conjunto para entender la problem´tica y generar ideas de c´mo solucionarlas. a o Se estudi´ tambi´n documentaci´n entregada por ASSE de los diferentes sisteo e o mas y documentos que definen la forma de trabajo a la que apunta el ´rea de a testing. En este documento se presentan los inconvenientes detectados y sugerencias para solucionarlos. Las recomendaciones se construyen en base a las sugerencias de los integrantes de ASSE y el an´lisis hecho por el grupo de estudiantes de a este proyecto de grado. 3.2. Actividades desarrolladas En una primera etapa se llevaron a cabo las siguientes actividades para evaluar el estado de la organizaci´n desde el punto de vista del testing: o 1. Entrevistas con los responsables de ´reas estrat´gicas. a e 51
  • ´ CAP´ ITULO 3. INFORME DE ANALISIS Y DIAGNOSTICO INICIAL 52 2. An´lisis de los casos de las funcionalidades m´s usadas. a a 3. An´lisis de la documentaci´n existente a o 4. An´lisis de fortalezas y debilidades a Se cont´ con alrededor de cinco instancias de reuni´n con modalidad entrevista o o guionada1 , con los distintos actores involucrados al SGS. Participaron adem´s, a en su mayor´ Carlos Guti´rrez y Fernando Pereira con motivo de seguir y ıa, e aprovechar el avance del testing de este proyecto e involucrarse con la interna del desarrollo de estos sistemas. 3.2.1. Entrevistas Se mantuvo entrevistas con Carlos Guti´rrez y Fernando Pereira, ambos e involucrados directamente en la formaci´n del departamento de testing; Homero o Mu˜oz, referente funcional del SGS; Diego Lorenzo, l´ n ıder de desarrollo por parte de la empresa Hexa y Ariel Sabiguero como apoyo general del proyecto. 3.2.2. An´lisis a Complementando la informaci´n obtenida de las entrevistas, se analiz´ una serie o o de documentos y una herramienta, que fueron puestos a nuestra disposici´n. o Los documentos vistos y la herramienta analizada son: 1. Documento de casos de uso del sistema SGS 2. Planilla con ranking de casos de uso m´s ejecutados en el sistema SGS a 3. Documento de Arquitectura Simplificado del sistema SGS 4. Mantis, usada para seguimiento de incidentes y pedidos de los requerimientos 5. Propuesta de Proceso de Testing en etapa de elaboraci´n, por parte de los o testers de ASSE. 6. Manual de Usuario del sistema SGS. 3.3. Diagn´stico o En esta secci´n presentamos los resultados obtenidos del an´lisis de la o a organizaci´n. Se quiere destacar que el ´nfasis se puso en detectar las dificultades o e y proponer alternativas para sortearlas, m´s que en destacar el trabajo ya a avanzado y logrado en ASSE. 1 La entrevista guionada se basa en la elaboraci´n para cada reuni´n de un gui´n con o o o los puntos fundamentales a tratar, sin perder el aporte libre de cada participante. De esta manera se logra un productivo intercambio de ideas. En todos los casos se solicit´ previamente o informaci´n documentada para estudiarla y lograr un mejor entendimiento de la realidad. o
  • ´ 3.3. DIAGNOSTICO 3.3.1. 53 Estado Actual del Testing La divisi´n inform´tica de ASSE est´ enfrent´ndose a cambios, habi´ndose ino a a a e corporado y redistribuido recursos. Tambi´n est´ teniendo un aumento impore a tante en la cantidad de usuarios finales de su principal sistema, el SGS. ASSE tiene la preocupaci´n de instrumentar y mejorar sus actividades de teso ting, dado que lo considera como un elemento importante en el desarrollo para mejorar la calidad de los productos y lograr m´s confianza en el software al a momento de salir a producci´n. o Durante el desarrollo se hacen pruebas b´sicas a diferentes niveles (unitarias, a pruebas de integraci´n y de sistema), pero no muy frecuentemente. La o informaci´n de las pruebas de desarrollo es a menudo consultada por el equipo o de testing para mitigar la falta de requerimientos y especificaci´n. o 3.3.2. Control y alcance de las pruebas En el desarrollo de las aplicaciones, es poco frecuente la incorporaci´n de nuevo o c´digo, dado que se re-utiliza cierta funcionalidad ya implementada y se hacen o los cambios pertinentes. Por la parte de testing, no se lleva un control de lo que se prob´ y es dificultoso identificar las versiones del producto. No se exige a los o equipos de desarrollo un m´ ınimo de pruebas, quedando en ultima instancia a ´ criterio del desarrollador. 3.3.3. ´ Area de testing En un principio y debido a los limitados recursos, solamente se asignan a desarrollo. Luego ASSE asume la responsabilidad del testing y crea el ´rea a de testing, integrada por dos personas con perfil t´cnico-inform´tico. Este e a equipo se encarga de todas las actividades de verificaci´n, lo cual representa o una sobrecarga de trabajo y trae como consecuencia que muchos proyectos de desarrollo no cuenten con las pruebas necesarias antes de salir a producci´n. De o los sistemas que son verificados, en muchas oportunidades las pruebas se reducen a una leve verificaci´n de usuarios funcionales destinatarios de la aplicaci´n. El o o rol de los testers est´ muy diluido entre actividades de soporte a usuarios, ya a sea por el conocimiento acumulado en los productos como otras actividades no vinculadas con el testing en s´ ı. Capacitaci´n t´cnica en testing o e En nuestro an´lisis, no detectamos antecedentes de instancias de capacitaci´n o a o talleres en la tem´tica del testing funcional ni testing funcional automatizado. a El conocimiento residente en los integrantes es merito propio, a ra´ de inter´s ız e y motivaci´n personal. o
  • 54 ´ CAP´ ITULO 3. INFORME DE ANALISIS Y DIAGNOSTICO INICIAL 3.3.4. Proceso de testing A la hora de efectuar las pruebas, se sigue un proceso de testing ad hoc no documentado. Con la inclusi´n de recursos espec´ o ıficos para testing, se inicia la tarea de documentaci´n de la metodolog´ seguida y algunas propuestas con o ıa las actividades deseables a seguir; con el fin de explicitarlas y mejorarlas. Esta formalizaci´n todav´ est´ en curso y en etapas iniciales por parte de ASSE. o ıa a 3.3.5. Procesos de desarrollo El desarrollo de los sistemas est´ distribuido entre varios proveedores, y a desarrollo interno a la organizaci´n. A los efectos, muchas de las empresas que o tienen a su cargo desarrollos parciales de los diferentes sistemas, funcionan como parte ´ ıntegra de un equipo de desarrollo heterog´neo y ligeramente gestionado. e Cada proveedor decide y lidera sus actividades de testing, y resulta dificultoso identificar las diferentes actividades como un unico proceso. ´ 3.3.6. Especificaci´n y documentaci´n de requerimientos o o En cuanto a los requerimientos, no est´ especificado qu´ interesa documentar a e y hasta qu´ punto. Se generan pedidos en la herramienta de seguimiento de e incidentes (Mantis), que oficia a estos efectos, de repositorio de requerimientos; en general es la unica documentaci´n de requerimientos con la que se cuenta. ´ o Existe documentaci´n bastante avanzada sobre la arquitectura; adem´s de casos o a de uso, con los flujos t´ ıpicos, y en ocasiones cuentan con flujos alternativos. Entre los temas relacionados, detectamos inter´s en mantener trazabilidad entre e casos de uso, m´dulos y objetos. o 3.3.7. Diversas fuentes de requerimientos Dependiendo del destino de los sistemas, existen distintos tipos de requerimientos de diversas y m´ltiples fuentes. Por ejemplo, los hospitales del interior y u capital pueden tener diferencias de funcionamiento. Por lo tanto se debe personalizar adem´s, una misma funcionalidad para cada ubicaci´n. Esto dificulta a o tener una versi´n unica y que los cambios ocurridos no impacten sobre el sistema o ´ de otros hospitales. 3.3.8. Requerimientos de calidad para tercerizaci´n o A la hora de licitar y contratar empresas para implementar los diferentes sistemas; no se establecen par´metros claros de calidad; esto es, no se incluye en a las licitaciones temas que especifiquen en qu´ estado deben estar los entregables, e qu´ tiempo deben cumplir las entregas, c´mo se negocian y se encargan los e o desarrollos. En definitiva, cu´les son los atributos de calidad de inter´s, y qu´ se a e e considera satisfactorio.
  • 3.4. RECOMENDACIONES 3.3.9. 55 Problemas en el sistema SGS Del an´lisis de la informaci´n relevante al sistema SGS, se identifican los a o siguientes puntos como destacables: 1. Los datos, tanto de la base local del SGS como los del padr´n est´n o a corruptos. Esto se debe mayormente al poco control en la interfaz de ingreso. 2. El sistema de seguridad es muy d´bil. Se quiere avanzar sobre esto, e encriptaci´n de contrase˜as, pol´ o n ıtica de contrase˜a, etc.. n 3. En el caso de la farmacia, la complejidad del negocio es muy alta, tanto sea para modelarla en software, como para testearla. a) El VadeMecum es una tabla que indica cuales medicamentos son cr´nicos y cu´les no. Pero esto es un problema ya que en distintas o a instituciones el mismo medicamento puede ser cr´nico o no. o b) La presentaci´n de los medicamentos es variable, dependiendo del o laboratorio que lo produzca. 3.4. Recomendaciones En esta secci´n, mostramos las recomendaciones de acciones a tomar para los o temas identificados en el diagn´stico inicial. Cada punto del diagn´stico cuenta o o con una o m´s recomendaciones, compuestas por un t´ a ıtulo y una descripci´n. o 3.4.1. Control y alcance de las pruebas Establecer una pol´ ıtica de gesti´n de la configuraci´n. o o Como punto de partida se deber´ poder identificar los productos y sus versiones, ıa para poder tener noci´n de qu´ versiones est´n instaladas en los diferentes o e a ambientes, y en qu´ estado est´n, es decir, si se puede ejecutar pruebas sobre e a ellas. Generar contratos entre testing y desarrollo para la entrega de los productos Exigir a los diferentes equipos de desarrollo como parte de su entrega la ejecuci´n o de pruebas de humo, implementaci´n de pruebas unitarias y de integraci´n con o o el fin de asegurar la integridad del producto y reducir los ciclos de consultas y respuestas entre testing y desarrollo al evitar los incidentes m´s b´sicos. a a
  • 56 ´ CAP´ ITULO 3. INFORME DE ANALISIS Y DIAGNOSTICO INICIAL 3.4.2. ´ Area de testing Incorporaci´n de recursos para testing o Para reforzar el ´rea de testing se recomienda incorporar personal capacitado. a Es necesario contar con personal fijo, adem´s de brindarles capacitaci´n permaa o nente y eventual apoyo de especialistas que puedan guiar en temas puntuales. Se recomienda como m´ ınimo integrar un Tester L´ ıder, con experiencia en gesti´n o de proyectos, un Tester Automatizador, y dos Testers de Profesi´n. o Capacitaci´n en Testing o Incorporar programas de capacitaci´n e incluso certificaci´n de los todo el equio o po de testing para asegurar su continua evoluci´n en la disciplina. o Los beneficios de la capacitaci´n son conocidos, pero es de destacar que o promueve la nivelaci´n de los integrantes en los conocimientos y conceptos, o manejo de vocabulario com´n e incorporaci´n de nuevas habilidades. u o Dedicaci´n total de los integrantes al testing o Las actividades que no est´n relacionadas con la disciplina se deben delegar a e otras personas fuera del ´rea de testing. Diversificar las tareas de los integrantes a reduce a´n m´s los recursos disponibles y desv´ el foco del testing. u a ıa 3.4.3. Proceso de testing Definici´n de proceso de testing o Contar con una consultor´ en testing que defina una forma de trabajo acorde a ıa la organizaci´n que integre a los equipos de desarrollo, usuarios funcionales y a o los diferentes actores involucrados. Reutilizar el material iniciado por los testers de ASSE como insumo para la propuesta de la forma de trabajo. 3.4.4. Procesos de desarrollo Definir forma de trabajo entre equipos Con el fin de organizar el proceso de desarrollo y su integraci´n con el proceso o de testing a seguir, se sugiere el modelado de un flujo de trabajo que involucre la gesti´n de los cambios solicitados, los diferentes proyectos, los incidentes relao cionados y la incorporaci´n gradual de una herramienta capaz de integrar este o flujo de trabajo para que sea f´cil de seguir, gestionar, y mantener. a Ante la realidad de varios proveedores con diferentes formas de trabajar, se recomienda definir un proceso est´ndar que deben seguir los equipos de a desarrollo e incluir esto en las licitaciones y contratos. Para este fin, se
  • 3.4. RECOMENDACIONES 57 recomienda contar con una consultor´ en temas relacionados a ingenier´ de ıa ıa software. 3.4.5. Especificaci´n y documentaci´n de requerimientos o o Definir el nivel de inter´s de la organizaci´n por la documentaci´n e o o Llegar a un entendido de qu´ tipo de informaci´n se requiere documentar, para e o que los productos ganen en mantenibilidad y a su vez la organizaci´n pueda o auditar y controlar sus procesos. Esta definici´n puede ser que no interesa contar o con documentaci´n detallada, pero no se recomienda que quede a criterio de cada o equipo. Es importante tener en cuenta que la documentaci´n requiere una carga o trabajo importante, por lo tanto la documentaci´n exigida y el nivel de detalle o debe ser estudiado detenidamente por la organizaci´n. o Exigir los niveles de documentaci´n acordados o Establecer con los diferentes equipos (y de ser tercerizados, en sus contratos) la obligatoriedad de presentar la documentaci´n definida por la organizaci´n junto o o con los productos construidos. Participaci´n de Testers en definici´n de requerimientos o o Se sugiere incorporar a los integrantes del equipo de testing en etapas tempranas de definici´n de requerimientos siempre que sea posible y esto no obstaculice o otras actividades. La visi´n de los encargados de las pruebas es enriquecedora, o dado que difiere del punto de vista de quienes tienen que construir un producto. Es com´n que se disipen ambig¨edades, zonas grises, y se encuentren errores u u en la definici´n en estas etapas, s´lo por el hecho de contar con la opini´n del o o o equipo de testing. Herramientas espec´ ıficas para modelar pedidos de cambio y asignaci´n de tareas o Contar con herramientas espec´ ıficas para determinado fin, (o una herramienta capaz de modelar fielmente toda la realidad). Las herramientas de seguimiento de incidentes, pueden compartir informaci´n o con otras herramientas de asignaci´n de tareas y control de cambios, pero no es o recomendable utilizar el flujo de trabajo y los conceptos definidos para un fin, con otro fin diferente. 3.4.6. Diversas fuentes de requerimientos
  • 58 ´ CAP´ ITULO 3. INFORME DE ANALISIS Y DIAGNOSTICO INICIAL Documentaci´n de las configuraciones particulares o Registrar la personalizaci´n particular de los sistemas distribuidos y sus o funcionalidades; validar dicha informaci´n con las autoridades pertinentes. o Exigir sistemas configurables Exigir a los proveedores que sus sistemas sean dise˜ados para que sean f´cilmente n a configurables y extensibles, mitigando el riesgo de que una configuraci´n o particular afecte a los sistemas ya implantados. 3.4.7. Requerimientos de calidad para tercerizaci´n o Definir atributos de calidad e incluirlos en licitaciones y contratos La organizaci´n deber´ identificar cu´les son los par´metros de calidad que o ıa a a necesita a la hora de aceptar un entregable y qu´ nivel se acepta de cada uno. e Esto debe ser claramente especificado en licitaciones y contratos. Algunos atributos y sus valores podr´ ser: ıan 1. Tiempo de entrega: en fecha, fuera de fecha, rango de tolerancia. 2. Estado de las funcionalidades y el producto: en desarrollo, inestable, estable, cerrado y verificado. 3. Documentaci´n: cumplir con el m´ o ınimo exigido, no se exige documentaci´n, manuales de usuario y requerimientos, documentaci´n de las pruebas o o ejecutadas, y muchas otras combinaciones de documentos que se puedan requerir. 4. Soporte: requisitos de disponibilidad de soporte, asistencia a usuarios, etc. 5. Antecedentes: por ejemplo si se requiere experiencia en proyectos similares o no. 3.4.8. Problemas en el sistema SGS Revisar la pol´ ıtica de entrega de software Establecer y negociar la pol´ ıtica de entrega de software mediante la definici´n o de atributos de calidad. Exigir que las funcionalidades complejas cuenten con documentaci´n detallada de su funcionamiento. o
  • 3.5. CONCLUSIONES 59 Definir los atributos de seguridad y de uso del software La organizaci´n debe tener claro los requerimientos de uso (usabilidad, facilidad o de uso) y los atributos de seguridad deseados acorde a la informaci´n que se o maneja. Para este fin se puede contar con profesionales que estudien el sistema desde este punto de vista, identificando problemas en el uso e interacci´n con el o producto, as´ como tambi´n baches de seguridad. ı e Contar con equipo de Testing dedicado a sistemas cr´ ıticos Es deseable que por un per´ ıodo de tiempo prolongado se cuente con recursos de testing dedicados a la verificaci´n de los sistemas cr´ o ıticos y complejos, dado que implica una ventaja contar con m´s integrantes que conozcan el comportamiento a del sistema. De ser posible, que se puedan incorporar en etapas tempranas del proceso de desarrollo. 3.5. Conclusiones El ´rea de desarrollo de ASSE presenta una alta heterogeneidad, los sistemas a act´an sobre dominios complejos, y el ´rea de testing cuenta con muy reducidos u a recursos para afrontar la responsabilidad de llevar adelante el testing de todos los productos. El software construido es generalmente propenso a errores y no existen procesos definidos en cuanto a desarrollo y testing de software. Las recomendaciones se basan en atacar los problemas relativos a la carencia de personal en el ´rea de testing, definici´n y mejora de los procesos de testing y a o desarrollo, as´ como tambi´n acuerdos de calidad que mitiguen el riesgo de conı e tar con entregables de software demasiado inestables, tanto para las empresas proveedoras como los equipos internos de ASSE. En el siguiente cap´ ıtulo se detalla la metodolog´ desarrollada para ASSE a ıa partir del estado del arte y la conclusiones extra´ ıdas del diagn´stico inicial de o la organizaci´n frente al testing funcional. o
  • 60 ´ CAP´ ITULO 3. INFORME DE ANALISIS Y DIAGNOSTICO INICIAL
  • Cap´ ıtulo 4 Framework Instanciable de Testing “La perfecci´n es una pulida colecci´n de errores” o o Mario Benedetti 4.1. Introducci´n o La metodolog´ propuesta estar´ contenida en el Framework Instanciable de ıa a Testing, (tambi´n referido en adelante por su sigla FIT ). Este marco de e trabajo, o framework esta dividido en diferentes m´dulos. Estos m´dulos o o tratan temas estrechamente relacionados. El m´dulo inicial, corresponde a la o identificaci´n del estado de la organizaci´n en cuanto al testing. Los siguientes o o m´dulos definen procesos de testing funcional manual y automatizado. Se puede o extender esta forma de organizar los conceptos en nuevos m´dulos. A modo o de discusi´n, se proponen algunos de los posibles m´dulos que pueden ser o o agregados, involucrando tareas de gesti´n e integraci´n de procesos globales o o de desarrollo y testing. 4.2. Justificaci´n de M´dulos y Procesos o o El Framework Instanciable de Testing, est´ organizado en m´dulos. Los m´dua o o los tienen diferentes caracter´ ısticas. El primero supone una identificaci´n del o estado inicial de la organizaci´n, no cuenta con actividades en s´ mismo, sino o ı que es un punto de partida simb´lico. Los restantes m´dulos contienen procesos o o espec´ ıficos, es decir una secuencia de pasos llevados adelante con un prop´sito o dado 1 . 1 Ver process (1) en [IEE06]. 61
  • 62 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING En esta propuesta es posible transitar por los diferentes m´dulos, involucrando o algunas etapas y actividades de los procesos definidos, sin tener que necesariamente cumplir con todas ellas. Cada proyecto particular motiva un camino a seguir entre las etapas y actividades. Este camino es la instancia del marco de trabajo propuesto y es llamado “roadmap”. Cada organizaci´n que ponga en o pr´ctica el FIT, podr´ por ejemplo, definir un roadmap gen´rico a modo de a ıa e plantilla para proyectos de similares caracter´ ısticas. La instanciaci´n de la metodolog´ en un roadmap se puede ejemplificar en dos o ıa dimensiones, una dimensi´n se puede interpretar como las etapas que se van o a ejecutar, y dentro de esas etapas cu´les actividades; otra dimensi´n, puede a o entenderse como la rigurosidad o profundidad con la que se ejecuta esa etapa o actividad, esto es, si se sigue su prop´sito detalladamente y se documenta estrico tamente el proceso, o si se transitan las etapas y actividades tomando en cuenta su punto central, sin detenerse a registrar el proceso abordado. En el ap´ndice e B de instrumentaci´n se muestran algunos ejemplos de qu´ tipo de factores cono e siderar para construir el roadmap dadas ciertas caracter´ ısticas y restricciones de un proyecto dentro de una organizaci´n. En esta ultima dimensi´n, adem´s de o ´ o a las exigencias del contexto (por ejemplo decisiones de la organizaci´n, externas o al alcance de testing) depende tambi´n del conocimiento y experiencia del tese ter, dado que como entrenamiento, el proceso puede aplicarse de manera formal, hasta hacerlo m´s laxo, d´nde las etapas y actividades se interpretan m´s como a o a una lista de tareas en las cuales es necesario pensar a la hora de encarar un proyecto de testing. Los m´dulos definidos para organizar el marco de trabajo son: o FIT M´dulo I: Testing Ad-Hoc o FIT M´dulo II: Proceso de Testing Funcional Manual o FIT M´dulo III: Proceso de Testing Funcional Automatizado o Esta forma de organizar la propuesta metodol´gica est´ pensada para que sea o a posible extender el marco de trabajo con otros m´dulos. o Como se discute en el cap´ ıtulo 6 se podr´ agregar nuevos m´dulos, a modo de ıan o ejemplo, en la figura 4.1 se muestran en rect´ngulo punteado dos de los posibles: a FIT M´dulo IV: Proceso de Testing Gestionado o FIT M´dulo V: Proceso de Desarrollo y Testing Integrados o
  • ´ ´ 4.2. JUSTIFICACION DE MODULOS Y PROCESOS 63 La figura 4.1 ejemplifica c´mo debe interpretarse la divisi´n en m´dulos del o o o FIT2 . Figura 4.1: FIT con sus m´dulos. o Un roadmap consiste en las actividades y etapas correspondientes a los procesos de los diferentes m´dulos, que aplican para un proyecto de testing particular en o un contexto dado. El objetivo es llegar a un camino que conduzca al ´xito del e proyecto. En la figura 4.2, se muestra una representaci´n conceptual de un cao mino que parte del m´dulo inicial y atraviesa los m´dulos II y III (en el gr´fico, o o a se muestra con una flecha quebrada atravesando los rect´ngulos etiquetados con a el nombre de cada m´dulo). o 2 Los m´dulos definidos tienen borde s´lido, mientras que los ejemplos de futuros m´dulos o o o est´n delimitados con borde punteado. a
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 64 Figura 4.2: FIT con sus m´dulos y representaci´n gr´fica del roadmap. o o a Cada proceso cuenta con diferentes etapas las cuales contienen actividades. Las actividades constan de un identificador, un t´ ıtulo y una descripci´n. Hay o ciertas actividades que son requeridas en su etapa, esto significa que la actividad debe ser ejecutada, aunque no sea en detalle; por ejemplo, como se ve en la secci´n 4.4.1, en la actividad “Seleccionar estrategia y enfoque” se puede optar o por no hacer testing dise˜ado, o por no tomar una estrategia exploratoria para n el transcurso de las pruebas, pero es expl´ ıcito que se debe ejecutar la actividad, y definir una estrategia. Algunas etapas tienen precedencia con otras, as´ como algunas actividades denı tro de una etapa. De ser necesario para aportar claridad, se especifica con diagramas la precedencia de las etapas, y de las actividades entre s´ Las etapas ı. y actividades se indican con rect´ngulos. Una actividad o etapa que pueda ser a ejecutada en paralelo a las dem´s, se indica con un rect´ngulo que no est´ en la a a a precedencia sino que est´ presente a la izquierda o derecha del diagrama, cuyo a largo abarca todos los elementos que se ejecutan en paralelo. Cada elemento en el diagrama est´ etiquetado por su identificador y su t´ a ıtulo. Una flecha con direcci´n desde un elemento A hacia un elemento B, indica que o el elemento A debe (o se sugiere) ser completado antes que el elemento B3 . Las actividades y etapas requeridas tendr´n un asterisco junto a su identificador a (ejemplo, SEE* en la etiqueta de un elemento, indica que la actividad de identificador SEE es requerida). 3B podr´ necesitar como entrada resultados generados en A. ıa
  • ´ 4.3. FIT MODULO I 4.3. 65 FIT M´dulo I: Punto de Partida o Es com´n que las organizaciones tengan diferentes percepciones del testing, por u ejemplo, a menudo suele tomarse como una actividad secundaria, anexa al desarrollo y muchas veces es confundido con depuraci´n de c´digo. Tambi´n sucede o o e que se desconocen los diferentes niveles en los cuales se puede implementar testing, y c´mo hacerlo. Algunas organizaciones recurren a los usuarios del sistema o y expertos del dominio para colaborar con el testing, pero son involucrados de forma tard´ y muchas veces es el unico testing que se pr´ctica sobre el sistema. ıa ´ a Este es el m´dulo inicial, y su alcance es muy amplio. El objetivo del m´dulo es o o establecer un punto de partida a trav´s de la identificaci´n de las caracter´ e o ısticas y restricciones de la organizaci´n y el proyecto particular. El an´lisis de cada o a contexto pone en manifiesto cu´les los puntos fuertes y las carencias en la forma a en que el testing es llevado a cabo hasta ese momento. Usualmente, el punto de partida detecta que el testing funcional se da en un contexto donde no est´n claras las actividades, los pasos no son repetitivos o mea dibles, los roles y las responsabilidades est´n d´bilmente delimitadas y el testing a e es tomado como una actividad posterior al desarrollo y no como un proyecto o disciplina en s´ misma. ı Si bien las organizaciones pueden estar preocupadas por la calidad, y aunque puedan tener la intenci´n de hacer testing, es com´n que al no seguir un proo u ceso se presenten carencias, por ejemplo, no saber c´mo implementar tareas de o testing, c´mo organizarse, c´mo controlar las pruebas ejecutadas y el avance, y o o conocer qu´ funcionalidades fueron cubiertas. e En el m´dulo inicial, se debe conocer c´mo trabaja actualmente la organizaci´n, o o o con la intenci´n de rescatar las buenas pr´cticas y tareas actuales que se ajustan o a con los procesos de testing funcional manual y automatizado, potenciando su uso. Es importante detectar las carencias o ausencia de actividades, as´ como ı tambi´n pr´cticas no deseadas. e a
  • 66 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING La identificaci´n del contexto inicial, consta de: o Identificar actividades existentes • Pr´cticas de desarrollo: la forma en que se lleva adelante el a desarrollo y mantenimiento de los sistemas. • Ingenier´ de requerimientos: c´mo se elaboran los requerimienıa o tos en la organizaci´n, c´mo se definen, qui´n los valida, quienes o o e participan. • Pr´cticas de testing: en qu´ manera se ejecuta la verificaci´n y a e o validaci´n de los productos, qui´nes participan, qu´ peso tiene en la o e e organizaci´n. o • Forma de trabajo en general: aspectos de c´mo interaccionan o los diferentes actores y equipos, c´mo se comunican, qu´ jerarqu´ o e ıas impl´ ıcitas y expl´ ıcitas existen en la organizaci´n. o Identificar restricciones del proyecto • T´cnicas: cierto producto puede requerir la interacci´n con determie o nado componente, condicionar a las herramientas de automatizaci´n o de pruebas o determinada plataforma base e infraestructura. • Recursos disponibles: se trata de la inversi´n destinada al proyeco to, tanto en recursos materiales, hardware, software, como recursos humanos dedicados, como ser personal t´cnico y especialistas. e Identificar restricciones de la organizaci´n o • Pol´ ıticas: la organizaci´n puede tomar la decisi´n de apoyar ciertos o o proyectos, trabajar o no con determinado proveedor, o requerir seguimiento especial de los procesos. • Econ´micas: se trata de los recursos materiales y humanos o dedicados al proyecto espec´ ıfico, y al testing en general. • Temporales: es el margen de tiempo destinado al proyecto, o plazos exigidos para cumplir con los objetivos pautados. Con la informaci´n recopilada, se elabora una visi´n de la organizaci´n en o o o cuanto al testing y se elabora un documento que informe los resultados de este an´lisis. Este documento esta enfocado al testing particularmente aunque a puede identificar otros problemas. Se identifican los inconvenientes y se sugieren acciones para lidiar con ellos. Un ejemplo elaborado para el caso de estudio del proyecto de grado, esta presente en el cap´ ıtulo 3.
  • ´ 4.3. FIT MODULO I 4.3.1. 67 Roles Es com´n encontrar patrones muy diversos en la forma en que las personas u asumen diferentes tareas. En un proyecto de desarrollo de software de mediano porte, con alguna intenci´n de incluir testing, existen al menos un referente para o cada ´rea involucrada. A continuaci´n se destacan los roles m´s comunes que a o a suelen estar presentes para lograr implantar alg´n tipo de testing. u Tester Este rol lleva adelante las pruebas de piezas de software o documentos solicitadas por otros actores de la organizaci´n, ya sea encargados de desarrollo, usuarios o funcionales particulares, u otro actor designado por una determinada autoridad. Reportan los incidentes al encargado o referente de desarrollo. Usuarios Funcionales Son los encargados de concretar pruebas de aceptaci´n de los productos. Puede o ser en conjunto con los testers o no. Son los clientes internos, y quienes deciden si un producto o determinado cambio cumple con sus expectativas. Tambi´n e ofician de or´culo, al ser expertos en el dominio; poseen el conocimiento del a negocio, y muchas veces, son los destinatarios finales del producto. Encargado o referente de desarrollo En relaci´n al testing funcional, notifican al tester de un nuevo producto, o cambio o liberaci´n para que reciban pruebas. Coordinan la reparaci´n de los o o incidentes. Toman decisiones a partir de las pruebas de los testers o de los usuarios funcionales.
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 68 4.4. FIT M´dulo II: Proceso de Testing Funcioo nal Manual Entre los objetivos de este m´dulo se encuentra el de otorgar importancia a o la pr´ctica del testing de software, aportando un m´ a ınimo de metodolog´ y un ıa conjunto de conceptos que hagan del testing una actividad repetible, justificada y profesional. Este m´dulo define un proceso de testing funcional manual, con etapas y o actividades que acercan a la organizaci´n a seguir una metodolog´ En el o ıa. proceso definido los testers son capaces de analizar los requerimientos, establecer criterios de testing, construir e investigar los requerimientos faltantes y articular las actividades necesarias para llevar adelante el testing. Adem´s se espera de a que sean capaces de comunicarse con los dem´s integrantes de forma eficaz y a puedan formular las estrategias de testing, aplicar priorizaci´n basada en riesgo, o y apoyarse en t´cnicas de dise˜o, llegando a un conjunto de casos de prueba que e n garantice una determinada cobertura, o cumpla con cierto criterio de finalizaci´n o de pruebas previamente establecido o negociado con los actores involucrados (usuarios funcionales, responsables en general). 4.4.1. Etapas del Proceso de Testing Manual Como se ve al inicio del cap´ ıtulo 4.2, los procesos se componen de etapas, y estas de actividades. Las tres letras iniciales previas al nombre una etapa o actividad corresponde a su identificador. Los identificadores y nombres son usados indistintamente para referirse expl´ ıcitamente a una determinada etapa o actividad. Este proceso se compone de las siguientes etapas: PLN - Planificaci´n Inicial. o ANR - An´lisis de Requerimientos. a DSP - Dise˜o de Casos de Prueba. n PEJ - Preparaci´n de Ejecuci´n. o o EJP - Ejecuci´n de Pruebas. o ADD - An´lisis de Defectos. a SAP - Seguir y Actualizar el Plan. AYR - Alcance y An´lisis de Riesgo. a VDD - Verificaci´n de Documentos. o INR - Informar Resultados.
  • ´ 4.4. FIT MODULO II 69 Un proyecto de testing deber´ contar como m´ ıa ınimo con las etapas de planificaci´n (PLN), an´lisis (ANR), dise˜o (DSP), ejecuci´n de pruebas (EJP) y la o a n o etapa de comunicar los resultados (INR). La preparaci´n de la ejecuci´n (PEJ) o o es una etapa importante, pero hay realidades en las cuales se pueden ejecutar pruebas sin tener un manejo especial de los entornos y ambientes. Las etapas de an´lisis de riesgo y alcance (AYR), verificaci´n de documentos (VDD) y de a o seguimiento y actualizaci´n del plan (SAP), contienen actividades muy recomeno dadas, pero no son absolutamente necesarias para la concepci´n de un proyecto o de testing. Veremos reflejado en el siguiente diagrama, que las etapas INR, AYR, VDD y SAP son transversales, es decir, ocurren durante el transcurso del proyecto. El diagrama muestra c´mo se relacionan las diferentes etapas, su precedencia, o paralelismo y si son requeridas o no. AYR - Alcance y An´lisis de Riesgo a DSN* - Dise˜o de n Casos de Prueba PEJ - Preparaci´n de Ejecuci´n o o EJP* - Ejecuci´n de Pruebas o INR* - Informar Resultados ANR* - An´lisis a de Requerimientos VDD - Verificaci´n de Documentos o SAP - Seguimiento y Actualizaci´n del Plan o PLN* - Planificaci´n Inicial o ADD - An´lisis de Defectos a Figura 4.3: FIT M´dulo II: Proceso de Testing Funcional Manual o Cada etapa est´ relacionada con la construcci´n o mantenimiento de documena o tos que registran la informaci´n relevante de las actividades. La utilidad de un o documento particular en un contexto dado, determinar´ su contenido, profundia
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 70 dad e incluso su existencia. En las siguientes secciones, al examinar cada etapa, mencionaremos las caracter´ ısticas m´s relevantes de cada documento. a El cuadro 4.1 presenta las diferentes etapas del M´dulo II del FIT, con su o identificador, su nombre y los documentos involucrados. Identificador PLN Nombre de la Etapa Planificaci´n o ANR An´lisis de Requerimientos a DSP Dise˜o de Pruebas n PEJ Preparaci´n de Ejecuci´n o o EJP Ejecuci´n de Pruebas o ADD An´lisis de Defectos a SAP AYR Seguir y Actualizar el Plan Alcance y An´lisis de Riesgo a VDD Verificaci´n de Documentos o INR Informar Resultados Documento Involucrado Plan de Testing Documento de An´lisis de a Testing Casos de Prueba dise˜ados / Documentos de n Misiones Documento de entornos y ambientes Documento de ejecuci´n o / Casos de Pruebas dise˜ados / Documentos de n Misiones Informe de An´lisis de Dea fectos Plan de Testing Plan de Testing Informe de Consultas y Observaciones Informes de Avance / Informe Final Cuadro 4.1: Documentos del Proceso de Testing Funcional Manual. El cuadro 4.2 presenta las diferentes etapas del proceso M´dulo II del FIT, o con su identificador, su nombre y los roles involucrados en cada una de ellas. El primer rol en el cuadro es el rol principal y cuenta con el apoyo de los siguientes.
  • ´ 4.4. FIT MODULO II Identificador 71 Nombre de la Etapa PLN Planificaci´n o ANR An´lisis de Requerimientos a DSP Dise˜o de Pruebas n PEJ Preparaci´n de Ejecuci´n o o EJP Ejecuci´n de Pruebas o ADD An´lisis de Defectos a SAP Seguir y Actualizar el Plan AYR Alcance y An´lisis de Riesgo a VDD Verificaci´n de Documentos o INR Informar Resultados Rol Involucrado Tester Profesional / Tester Funcional L´ ıder / L´ ıder de Proyecto Tester Profesional / Tester Funcional / L´ ıder de Proyecto / Desarrollador Tester Profesional / Tester Funcional Tester Funcional L´ ıder / Tester Profesional / L´ ıder de Proyecto Tester Funcional / Tester Profesional Tester Profesional / Tester Funcional Tester Funcional L´ ıder / Tester Profesional Tester Funcional L´ ıder Tester Profesional / Tester Funcional Tester Funcional L´ ıder / Tester Profesional Cuadro 4.2: Roles en el Proceso de Testing Funcional Manual. Planificaci´n Inicial o La etapa de planificaci´n consiste en la elaboraci´n de un plan que exprese o o las decisiones m´s importantes del transcurso del proyecto de testing. Puede a incluir la introducci´n, las estrategias seleccionadas para atacar las diferentes o pruebas, las estimaciones, junto con diagramas y descripci´n de la forma en que o se har´ el seguimiento y control del proyecto. Los proyectos de testing, tienen a algunas particularidades que los diferencian de proyectos de otra ´ ındole, y por lo tanto se deben manejar ligeramente diferente. Entre las particularidades, se puede decir que proyecto de testing: Provee informaci´n, desde una perspectiva de servicios: el testing sirve a o diferentes partes, actuando como nexo y aportando a cada uno de forma diferente. Suele ser de las etapas finales dentro de un proyecto mayor: carga con la responsabilidad de detectar los incidentes antes de que pasen a producci´n. o El proyecto debe estar enfocado a la transparencia y a la comunicaci´n o transparente y fluida.
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 72 Puede re-alimentar etapas de un proyecto paralelo o mayor: los productos de trabajo generados en testing pueden ser insumo, soporte, o material de consulta para otras ´reas, como ser desarrollo de documentaci´n de a o usuario, desarrolladores, entre otros. Puede dividirse en subproyectos que deben ser consistentes: en ocasiones el proyecto de testing avanza en paralelo con el proyecto de desarrollo, o se suceden muchos subproyectos de testing en torno a un producto, o fases de un producto. Conforme avanzan los subproyectos, estos deben ser consistentes con el proyecto de testing mayor que los contiene. Es probable que cada subproyecto deba dejar informaci´n a los dem´s, o que utilice o a la informaci´n generada en otros anteriores, o que est´n ejecut´ndose en o a a paralelo con ´l. e En el cuadro 4.3, se ven las diferentes actividades relacionadas con la etapa, mostrando el identificador de cada actividad, y si es obligatoria. El objetivo es la elaboraci´n de un plan de testing. o Identificador SEE EST ADR STD ALC SCP CRA Nombre de la Actividad Seleccionar Estrategia y Enfoque Formular Estimaciones An´lisis de Riesgo seg´n Requerimientos y a u Negocio Selecci´n de T´cnicas de Dise˜o o e n Alcance de las Pruebas Seguimiento y Control del Proyecto Criterios de Aceptaci´n o Cuadro 4.3: Etapa de Planificaci´n Inicial o ¿Es requerida? SI NO NO NO SI NO NO
  • ´ 4.4. FIT MODULO II 73 SCP - Seguimiento y Control del Proyecto SEE* - Seleccionar Estrategia y Enfoque EST - Formular Estimaciones ADR - An´lisis de Riesgo seg´n a u Requerimientos y Negocio STD - Selecci´n de o T´cnicas de Dise˜o e n ALC* - Alcance de las Pruebas CRA - Criterios de Aceptaci´n o Figura 4.4: Etapa Planificaci´n Inicial o Productos de trabajo involucrados en la etapa Plan de pruebas: en su forma m´s completa contiene un apartado para a cada actividad de la etapa. Se registra la decisi´n acerca de la estrategia a o utilizar, las estimaciones del proyecto de testing, el an´lisis de riesgo, las a t´cnicas de dise˜o de pruebas a utilizar, el alcance de las pruebas, ajustes e n al plan y criterios de aceptaci´n pautados para las pruebas. El plan puede o incluir comentarios acerca de si la automatizaci´n es parte de la estrategia. o El plan es una herramienta muy util para organizar el trabajo, documentar ´ el proceso y negociar el alcance de las pruebas y tener como referencia para la gesti´n del proceso. Los planes m´s formales suelen ser m´s dif´ o a a ıciles de mantener, por eso es com´n que los planes de testing se vuelvan u r´pidamente obsoletos. El plan de testing es un documento din´mico y por a a lo tanto tiene que ser consultado y actualizado. Planes menos rigurosos en formalismos, pero que hacen foco en los puntos relevantes al proceso suelen ser m´s realistas y realmente aportar en contextos de alto dinamismo4 . a 4 Con alto dinamismo nos referimos a contextos muy cambiantes, que provocar´ ajustes ıan
  • 74 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Seleccionar Estrategia y Enfoque: consiste en elegir, construir, o adaptar una estrategia de testing para las pruebas. Se puede optar por el testing planificado, testing exploratorio, o inclusive en la automatizaci´n de ciertos como ponentes (como se ve en el Proceso de Testing Funcional Automatizado, del M´dulo III del FIT en la secci´n 4.5 de este cap´ o o ıtulo). Las estrategias con tenor exploratorio son adecuadas a situaciones en las que los tiempos son acotados, comprometiendo algo de rigurosidad en la documentaci´n. La productividad de la estrategia de testing exploratorio depende en o gran medida de las habilidades del tester, favoreciendo el uso de la creatividad y toma de decisiones en el momento, siendo por esto ultimo m´s flexible que el ´ a enfoque de testing planificado. El testing planificado requiere un m´ ınimo de an´lisis y dise˜ o de pruebas antes a n de pasar a la ejecuci´n. Es conveniente para contextos en los cuales es necesario o documentar rigurosamente el proceso, por ejemplo para que dicha informaci´n o sea auditable. Eventualmente, el dise˜o de las pruebas puede estar a cargo de n un tester experimentado y la ejecuci´n a cargo de otro tester con menos expeo riencia o conocimiento del dominio, por lo cual la aplicaci´n de esta estrategia o tendr´ ´xito por motivo de un buen dise˜o de pruebas y no tanto por las haae n bilidades del tester que las ejecute. Como desventaja frente a la estrategia de testing exploratorio, el testing planificado es m´s r´ a ıgido y es afectado por los cambios en el proyecto, que derivan en un redise˜o de casos de prueba ante una n nueva realidad. Enfocar el proyecto alrededor de la automatizaci´n de pruebas es una estrategia o que en muchas realidades depende de la naturaleza del proceso de desarrollo seguido. Como se describe en la secci´n 2.5.1, la automatizaci´n puede ser una o o alternativa para asegurar la no regresi´n del producto debido a una alta freo cuencia de liberaciones del producto, puede ser la forma de manejar grandes vol´menes de informaci´n, o suplantar pruebas que manualmente tomar´ muu o ıan cho tiempo o son muy tediosas. La decisi´n de la estrategia no tiene por que ser un extremo, sino que la eso trategia puede ser un h´ ıbrido de las mencionadas, dado que en un sistema de gran porte, los diferentes componentes pueden requerir enfoques particulares, o la estrategia puede directamente ser algo diferente de lo mencionado. Roles involucrados Tester Profesional, Tester Funcional L´der: identifican las particularidaı des del proyecto y definen una estrategia para el proyecto de testing. Para esto se apoyan en la informaci´n preliminar que se pueda recopilar del proo yecto, ya sea de documentos o de otros actores, como Usuarios Funcionales y Referentes de Proyecto. frecuentes al plan, que de ser un documento muy estricto, se vuelve una tarea costosa.
  • ´ 4.4. FIT MODULO II 75 Usuarios Funcionales: proveen de informaci´n al equipo de testing sobre o el sistema, mencionando sus aspiraciones, los resultados deseables, y toda informaci´n relevante a la realidad del producto. o Formular Estimaciones: luego de tener idea del alcance y el dominio del problema, es posible plantear tiempos estimados para las diferentes etapas seleccionadas para el proyecto de testing particular. Es recomendable acompa˜ ar n estas estimaciones con alg´n diagrama estilo Gantt. Esta actividad, suele teu ner una participaci´n fuerte al principio, y luego en algunos hitos intermedios, o donde se pueden ajustar, corregir y volver a estimar, acorde a la realidad. Es una herramienta fundamental para el seguimiento y el control, ayud´ndonos a a tomar acciones correctivas. Roles involucrados Tester Profesional, Tester Funcional L´der: plantean estimaciones en base ı al dimensionamiento inicial del proyecto. La estimaci´n debe ser revisada o y ajustada como respuesta al seguimiento. Una buena estrategia es ajustar la estimaci´n al contar con una idea de los casos de prueba a ejecutar, o o las funcionalidades y flujos que se desean ensayar en el sistema. Responsables de desarrollo: mediante el conocimiento del sistema y de la complejidad de sus diferentes funcionalidades, los responsables de desarrollo colaboran a la construcci´n de una estimaci´n m´s acertada. o o a Usuarios Funcionales: conocen el dominio del problema, los puntos cr´ ıticos del negocio, y muchas veces el modo de uso del sistema. Esto los suele dotar de un gran conocimiento del dominio y la complejidad de las funcionalidades. Esta informaci´n contribuye a la mejora de las o estimaciones. An´lisis de Riesgo seg´ n Requerimientos y Negocio: el objetivo es a u plantear una lista inicial de riesgos, que apoyar´ la toma de decisiones en cuana to al alcance y el foco de las pruebas. El equipo de testers identificar´ los riesgos a a partir del an´lisis preliminar de los requerimientos, la interacci´n con otros a o actores del proyecto de desarrollo y el contexto del proyecto en s´ Esta lista ı. puede ser elaborada y mantenida mediante mecanismos cl´sicos de gesti´n del a o riesgo, u otros, como la heur´ ıstica de testing basado en riesgo [Bac99] mencionada en la secci´n 2.4.4. o Roles involucrados Tester Profesional, Tester Funcional L´der: elaboran una lista de riesgos a ı partir de la informaci´n aportada por los diferentes actores, conocimiento o previo del sistema, conocimiento del equipo de trabajo y desarrollo, experiencias en funcionalidades o productos similares, entre otros. Es frecuente que se necesiten varias instancias de reuni´n para llegar al o
  • 76 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING conjunto de riesgos adecuado. Dependiendo de la rigurosidad del proceso, esta actividad deber´ contar con la validaci´n de quien tenga la visi´n del a o o negocio, o tenga la responsabilidad de responder por la correcta mitigaci´n o de estos riesgos. Responsables de desarrollo, equipo de desarrollo: son consultados para evaluar el impacto t´cnico y riesgos asociados a la construcci´n del e o producto. Frecuentemente el equipo de desarrollo y responsables pueden informar de los riesgos asociados a la complejidad t´cnica, acoplamiento e e impacto de un cambio en otras funcionalidades, complejidad de mantenimiento, complejidad de comportamiento de cierta funcionalidad, grado de dificultad que representa automatizar o testear unitariamente cierta parte del producto, y otros riesgos. Usuarios Funcionales: entre la informaci´n que aportan, es de destacar o que son la fuente principal para identificar los riesgos que provienen de los aspectos del dominio (funcionalidades cr´ ıticas, importantes o accesorias) y de particularidades del uso del sistema. En ciertos contextos, tambi´n e pueden participar de la validaci´n de la lista de riesgos. Muchas veces o estos usuarios adem´s han tenido que gestionar riesgos mediante alg´ n a u mecanismo, por lo tanto esa informaci´n puede ser de suma utilidad en o esta actividad. Productos de trabajo involucrados Documento de Riesgos Identificados: contiene los riesgos que se destacan en el proyecto. Suele contar con una priorizaci´n y se puede presentar o por ejemplo en forma de lista priorizada, o matriz, como se ve´ en la ıa secci´n 2.4.4, entre otras t´cnicas. El material presente en este documento o e se puede anexar como secci´n al plan de pruebas elaborado. o Selecci´n de T´cnicas de Dise˜ o de Pruebas: del conocimiento resideno e n te en los testers, o como resultado de investigaci´n y contraste con un an´lisis o a primario de los requerimientos funcionales, se eligen las t´cnicas a utilizar para e derivar casos de prueba (de aplicar testing dise˜ado). Es com´ n recaer sobre n u t´cnicas populares como an´lisis de valores l´ e a ımites, particiones de equivalencia, a ´rboles de decisi´n, todos los pares; pero de optar por proceder con esta aco tividad, estamos ante una buena oportunidad para conocer e investigar sobre nuevas t´cnicas y heur´ e ısticas5 . Roles involucrados Tester Profesional, Tester Funcional L´der: seleccionan t´cnicas adecuaı e das a cada funcionalidad y seg´n la estrategia seguida. Para el testing u 5 Existe material base, como el libro de Mayers [Mye04b], as´ como muchos buenos recursos ı en la web, como el blog de testing de Google[JAWea11], o el blog de James Bach [Bac11], que han marcado tendencias en la disciplina
  • ´ 4.4. FIT MODULO II 77 dise˜ado se eval´a la aplicabilidad de las t´cnicas conocidas por los tesn u e ters y para el testing exploratorio, se puede optar por seguir las t´cnicas e mencionadas en la secci´n 2.4.2, u otras6 . o Productos de trabajo involucrados Plan de Pruebas: el conocimiento generado en esta actividad puede ser incluido en este documento. Alcance de las Pruebas: bas´ndose en los requerimientos analizados, se a formula un alcance y una cobertura para las funcionalidades del producto bajo testing. La cobertura expresa para cierto criterio, el grado de alcance que tendr´ la prueba. El alcance adem´s sirve para ajustar los tiempos del proyecto a a en base a las estimaciones. Se suele recortar el alcance de las pruebas menos cr´ ıticas, las que, luego del an´lisis de priorizaci´n y riesgo, sean menos prioritaa o rias. Roles involucrados Tester Profesional, Tester Funcional L´der: establecen una propuesta de ı alcance para las pruebas, las que luego validar´n con los diferentes actores. a Responsables de Desarrollo: revisan junto a los testers el alcance preliminar propuesto y eventualmente lo validan. Usuarios Funcionales: pueden participar en la validaci´n del alcance de las o pruebas, sobre todo en etapas tempranas en lo que respecta a las pruebas de aceptaci´n del producto. o Productos de trabajo involucrados Plan de Pruebas: el conocimiento generado en esta actividad puede ser incluido en este documento. Seguimiento y Control del Proyecto: es el nexo con la etapa de seguimiento y actualizaci´n del plan (SAP), la cual es transversal al transcurso del o proyecto. A trav´s de esta actividad, se contrasta la realidad con la planificae ci´n y se efect´an los ajustes necesarios. Aunque la etapa SAP no sea llevada a o u cabo, es posible implementar ajustes al plan mediante esta actividad. Los ajustes pueden ser a cualquier punto del plan, como las estimaciones, el alcance, comentarios sobre las t´cnicas usadas, entre otros. e Roles involucrados 6 Adem´s de las heur´ a ısticas mencionadas, James Wittaker presenta en su libro acerca de testing exploratorio [Whi09c], otras heur´ ısticas para llevar a la pr´ctica esta estrategia de a testing.
  • 78 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Tester Profesional, Tester Funcional L´der: mantienen el plan de pruebas, ı representando los ajustes necesarios para adaptarlo a la nueva realidad. Productos de trabajo involucrados Plan de Pruebas: el plan puede ser eventualmente enriquecido y ajustado en esta actividad. En contextos m´s rigurosos en cuanto a la a documentaci´n, se registran los ajustes y en en una secci´n aparte se o o incluyen los desv´ al plan junto con sus causas. ıos Criterios de Aceptaci´n: en proyectos que se requiera una validaci´n foro o mal de los elementos generados por las diferentes etapas, se puede establecer, negociar y validar los criterios de aceptaci´n del producto, entre diferentes paro tes involucradas. Entre estos criterios pueden estar las instancias de pruebas de aceptaci´n, la cantidad y/o gravedad de los incidentes conocidos tolerados, o as´ como consideraciones de cobertura y el conjunto m´ ı ınimo de casos de prueba a ejecutar, entre otros. Roles involucrados Tester Profesional, Tester Funcional L´der: elaboran junto a los Usuarios ı Funcionales y Responsables de Desarrollo la lista de criterios con sus diferentes niveles de aceptaci´n o rechazo del software. o Responsable de Desarrollo: colabora en la definici´n de los criterios de o aceptaci´n a ser negociados con los interesados y Usuarios Funcionales. o Es importante contar con sus aportes para definir la traducci´n de un o criterio de aceptaci´n a par´metros t´cnicos medibles. o a e Usuarios Funcionales: ayudan a la definici´n de criterios desde el punto o de vista conceptual, con la perspectiva del dominio del producto. En la mayor´ de los contextos, tienen la ultima palabra acerca de los criterios, ıa ´ y son quienes pueden dar el visto bueno al respecto. Productos de trabajo involucrados Plan de Pruebas: el plan puede contener los criterios de aceptaci´n o definidos.
  • ´ 4.4. FIT MODULO II 79 An´lisis de Requerimientos a Es la etapa que consiste del estudio de los requerimientos funcionales con el fin de identificar los puntos de verificaci´n y ganar conocimiento sobre el dominio. o Los requerimientos no siempre est´n completamente definidos, identificados y a documentados. En ocasiones el trabajo de los testers consisten colaborar a la definici´n y sintetizaci´n de los requerimientos. El requerimiento es un insuo o mo fundamental para el testing, pero, como veremos m´s adelante, el an´lisis a a de requerimientos puede llegar a ser simult´neo con el dise˜o, la ejecuci´n de a n o pruebas y el aprendizaje sobre producto y el dominio; en estrategias particulares como la de testing exploratorio. De una u otra manera, siempre estaremos ante alg´n tipo de an´lisis, ya sea contando con el tiempo necesario para estuu a diar los requerimientos o relevarlos y construirlos a partir del conocimiento de los diferentes actores, as´ como tambi´n en paralelo y simult´neamente con la ı e a ejecuci´n de pruebas. Es necesario transitar por alguna de las actividades de eso ta etapa y seg´n la estrategia formulada, ser´ c´mo se ejecutar´n las actividades. u a o a La siguiente tabla indica las actividades con su identificaci´n y si son requeridas o dependiendo del tipo de estrategia7. Identificador ANR VFR CRF VDR Nombre de la Actividad An´lisis de requerimientos a Verificaci´n de requerimientos o Construcci´n de requerimientos o faltantes Validaci´n de requerimientos reo levados ¿Es requerida? SI NO NO NO Cuadro 4.4: Etapa de An´lisis de Requerimientos a 7 Referencias de la tabla: TD: actividad es requerida para testing dise˜ado, y opcional para testing exploratorio. n TE: actividad requerida para testing exploratorio y opcional para testing dise˜ado. n SI: actividad requerida para estrategias exploratorios y de testing dise˜ado. n NO: actividad opcional para ambas estrategias.
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING ANR* - An´lisis a de Requerimientos ANR* - An´lisis de Requerimientos a 80 VFR - Verificaci´n o de Requerimientos CRF - Construcci´n de o Requerimientos Faltantes VDR - Validaci´n de o Requerimientos Relevados ANR* - An´lisis a de Requerimientos Figura 4.5: Etapa An´lisis de Requerimientos a An´lisis de requerimientos: estudio de los requerimientos funcionales idena tificando las entradas, las salidas y el comportamiento esperado del sistema. Como los requerimientos pueden o no estar escritos, tambi´n conlleva un aprene dizaje del dominio. Esta actividad es fundamental en esta etapa, y es el principal insumo para las tareas de testing, sobre todo para el testing planificado. Es una actividad que puede llevarse a cabo simult´neamente con las dem´s actividades a a de esta etapa, y es la unica actividad requerida. En diagrama podemos ver, ´ mediante el orden de precedencia, que se inicia y finaliza con esta actividad. Adem´s la actividad tambi´n se va dando progresiva y simult´neamente, retroa e a aliment´ndose de los resultados intermedios de las dem´s actividades de la etapa. a a Para estrategias exploratorias, el an´lisis del dominio y los requerimientos se a abordan en la profundidad suficiente como para delinear los aspectos m´s ima portantes de las misiones del testing exploratorio. El an´lisis m´s profundo se a a da simult´neamente con la ejecuci´n de las pruebas, siendo los l´ a o ımites entre an´lisis, dise˜o y ejecuci´n, mucho m´s difusos en este caso. a n o a Roles involucrados Tester Profesional, Tester Funcional L´der: construyen el an´lisis de las ı a funcionalidades del producto a verificar. Coordinan reuniones o generan instancias donde poder consultar la informaci´n necesaria. Es com´ n que o u
  • ´ 4.4. FIT MODULO II 81 las dudas planteadas por el equipo de testing, ayude a clarificar la soluci´n o al problema en s´ por lo tanto es recomendable, siempre que sea posible, ı, que las etapas de an´lisis del problema comiencen lo antes posible, incluso a desde el momento mismo de la definici´n de los requisitos. o Responsable de Desarrollo, equipo de desarrollo: cuentan la visi´n t´cnica o e de la funcionalidad. Dado que para desarrollar cierta funcionalidad, se tiene que comprender el problema, los caminos seguidos por testers y desarrolladores son similares en este aspecto, diferenci´ndose en el punto a de vista. La colaboraci´n enriquece mucho, sobre todo para interactuar o con los expertos del dominio, ayud´ndoles a definir mejor sus requisitos. a Usuarios Funcionales: dado que son los expertos en el dominio, su papel es fundamental en la definici´n de los requisitos. La interacci´n con el o o equipo de testing a menudo favorece la correcta formulaci´n de lo que se o espera de cierto producto y su funcionamiento. Los Usuarios Funcionales encuentran muchas veces en los testers una buena forma de canalizar sus expectativas, dado que los especialistas t´cnicos, suelen tener su visi´n e o y forma de comunicaci´n muy ligada al mundo y vocabulario t´cnico o e (configur´ndose una barrera a la comunicaci´n con Usuarios Funcionales). a o Productos de trabajo involucrados Documento de An´lisis de Requerimientos de Testing: se puede construir a el documento que registra la visi´n de testing del sistema a verificar. Este o documento oficia como base de conocimiento y muchas veces complementa la documentaci´n existente de los requerimientos del producto. Si se opta o por testing dise˜ado, es recomendable contar con documentos de este estilo n que pueda ser consultado, compartido y validado con diferentes actores y que sea una entrada unica para la definici´n de casos de prueba y ´ o escenarios. Verificaci´n de requerimientos: consiste en el an´lisis de los documentos o a con el fin de identificar si est´n claros, si la informaci´n es completa, y si es poa o sible dise˜ar casos de prueba o llevar adelante una estrategia de prueba con la n informaci´n disponible. Esta actividad es recomendada como mecanismo de ino corporaci´n de testing a etapas temprana de desarrollo del producto. Es com´ n o u encontrar inconsistencias en la definici´n de los requerimientos, lo que redunda o en menos esfuerzo de testing y desarrollo al prevenir futuros incidentes. Consecuentemente los documentos son m´s completos y precisos. a Roles involucrados Tester Profesional, Tester Funcional L´der: revisan los documentos de la ı manera descrita. Se pueden dar varias interacciones con los autores de los documentos.
  • 82 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Responsable de Desarrollo, Usuarios Funcionales, otros autores de documentos: revisan las sugerencias de cambios, se re´nen con los testers para u evacuar dudas, e impactan las posibles modificaciones a los documentos, motivando eventuales nuevas verificaciones por parte de los testers. Productos de trabajo involucrados Documentos a verificar: cualquier documento puede ser verificado si se considera que influye en el correcto desarrollo del producto. Entre estos pueden estar los documentos de an´lisis de requerimientos, manuales de a usuario, documentos de an´lisis de riesgo e informes en general. a Construcci´n de requerimientos faltantes: es la actividad de completar o la especificaci´n de los requerimientos funcionales, si no estuviese completa. El o testing dise˜ado en su forma m´s estricta, requiere de documentos completos o lo n a m´s cercano posible. Mediante reuniones con expertos funcionales, investigaci´n a o del producto, investigaci´n de documentaci´n anterior y lectura de manuales de o o usuario; el tester elabora su an´lisis y enriquece o completa los documentos. a Roles involucrados Tester Profesional, Tester Funcional L´der: si se le requiere y autoriza, el ı tester es capaz de complementar los documentos con la informaci´n a la o que ha podido acceder (probablemente por la ejecuci´n de la actividad de o Verificaci´n de Requerimientos). o Responsable de Desarrollo, equipo de desarrollo: revisan que los documentos complementados con los testers reflejen lo esperado. Estas instancias de validaci´n y enriquecimiento de documentos puede generar varias ino teracciones entre los equipos. Usuarios Funcionales, otros autores de documentos: al igual que los desarrolladores, estos revisan la informaci´n agregada por los testers, y o pueden tener instancias de coordinaci´n con ellos. Como se mencionaba o anteriormente, el objetivo perseguido es eliminar las ambig¨ edades e u inconsistencias de los documentos, para que sean m´s comprensibles y a hagan m´s sencilla la tarea para el equipo de desarrollo. a Productos de trabajo involucrados Documento de requerimientos a enriquecer: es el documento que el tester tratar´ de completar con la informaci´n que ha podido recopilar. a o
  • ´ 4.4. FIT MODULO II 83 Validaci´n de requerimientos relevados: esta actividad est´ estrechameno a te ligada a la etapa de construcci´n de requerimientos faltantes. El trabajo de o investigaci´n de los requerimientos llevado adelante por los testers debe ser valio dado por alg´n responsable o l´ u ıder de proyecto; potencialmente se podr´ estar ıan incluyendo cambios importantes de definici´n, y dicha informaci´n puede haber o o sido consultada con diferentes actores, con m´ltiples visiones. Es importante por u lo tanto, que exista una unica versi´n validada en a la que todos los involucrados ´ o puedan referirse como la informaci´n oficial. o Roles involucrados Tester Profesional, Tester Funcional L´der: presentan la informaci´n ı o recopilada y procesada, haciendo ´nfasis en qu´ significa esta para el e e equipo de testing. Responsable de Desarrollo, equipo de desarrollo, Usuarios Funcionales, otros autores de documentos: colaboran en la definici´n y puesta en o com´n de la informaci´n presentada por el equipo de testing, dando su u o consentimiento de la correctitud de los datos relevados, as´ como tambi´n ı e corregir y agregar m´s informaci´n. a o Productos de trabajo involucrados Documento de An´lisis de Requerimientos de Testing: de ser construido, a suele contener la fuente de la informaci´n que los testers van a impactar o en los documentos de requerimientos. Puede tambi´n ser validado con los e diferentes actores. Documento de requerimientos a validar: es el documento modificado por los testers, que luego puede ser revisado y validado por los autores, as´ como tambi´n regresar a testing para nuevas revisiones, como ser la ı e verificaci´n de las correcciones o las respuestas a las eventuales dudas y la o confirmaci´n de la correctitud de la informaci´n agregada. o o
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 84 Dise˜ o de Pruebas n El desarrollo de esta etapa depende de la estrategia seleccionada. En las estrategias con un enfoque de testing planificado, se aplicaran t´cnicas de dise˜ o e n logrando un conjunto de casos de prueba inicial. En las estrategias con tenor exploratorio, la etapa se desarrolla identificando los grandes puntos y flujos funcionales, con el fin de establecer misiones y trazando algunos hitos que interesa recorrer en la exploraci´n. o La siguiente tabla indica las actividades con su identificaci´n y si son requeridas o dependiendo del tipo de estrategia8 . Identificador DCP ESP DMS EMS Nombre de la Actividad Dise˜o de Casos de Prueba n Especificaci´n de Casos de Prueo ba Dise˜o de Misiones y Sesiones n Especificaci´n de Misiones y Seo siones ¿Es requerida? TP TP TE TE Cuadro 4.5: Etapa Dise˜o de Pruebas n DCP - Dise˜o de n Casos de Prueba ESP - Especificaci´n o de Casos de Prueba Figura 4.6: Etapa Dise˜o de Pruebas del Testing Planificado n 8 Referencias del cuadro 4.5: TP: actividad es requerida para testing planificado, y opcional para testing exploratorio. TE: actividad requerida para testing exploratorio y opcional para testing planificado. SI: actividad requerida para estrategias exploratorios y de testing dise˜ado. n NO: actividad opcional para ambas estrategias.
  • ´ 4.4. FIT MODULO II 85 Dise˜ ar casos de prueba: esta actividad consta en la derivaci´n de casos n o de prueba a partir de la aplicaci´n de unas o varias t´cnicas. El objetivo es o e llegar a un conjunto de casos de prueba que puede ser insumo para negociaci´n o de alcance, priorizaci´n, ajuste de estimaciones y seguimiento de cobertura o de funcionalidades. Se estila que los casos de prueba dise˜ados incluyan un n identificador, las variables involucradas, el resultado esperado ante la ejecuci´n y o alg´n comentario o descripci´n; incluso, pueden llevar una explicaci´n detallada u o o paso a paso de su ejecuci´n, y los puntos de verificaci´n durante la ejecuci´n 9 . o o o Especificaci´n de Casos de Prueba: es la tarea de instanciar un caso o de prueba a una situaci´n particular de ejecuci´n. Por ejemplo, mediante la o o inclusi´n exacta de los valores que se van a utilizar en las pruebas. Esta etapa o puede estar vinculada con la b´squeda de datos apropiados, un detalle no menor, u y que puede llegar a consumir mucho tiempo. Las estrategias de testing con inclinaci´n al testing dise˜ado, ven muy comprometido su ´xito en lograr un o n e conjunto de casos de prueba de calidad, como ve´ ıamos en la secci´n 2.7.1. o DMS - Dise˜o de n Misiones y Sesiones EMS - Especificaci´n o de Misiones y Sesiones Figura 4.7: Etapa Dise˜o de Pruebas del Testing Exploratorio n Dise˜ ar Misiones y Sesiones: mediante este dise˜o se elaboran las n n descripciones verbales de las misiones y se organizan las sesiones de testing exploratorio. A partir de la informaci´n funcional obtenida, se delimitan los o grandes puntos. Un enfoque podr´ ser el separar las misiones con diferente ıa granularidad, para explorar grupos de funcionalidades relacionadas, operaciones y usos. Luego, se asigna una o varias sesiones que aborden las misiones dise˜ adas. n Estas ideas provienen de la t´cnica de testing exploratorio basado en sesiones e (visto en la secci´n 2.4.2), que puede ser aplicada m´s rigurosamente siguiendo o a las recomendaciones de la t´cnica. e 9 Por ejemplo, un caso de prueba puede ser la descripci´n en pasos de un flujo o funcional, identificando los puntos d´nde se debe validar y verificar informaci´n, especificando o o qu´ resultados se esperan. Esta forma de documentaci´n es muy util para la automatizaci´n e o ´ o de pruebas (ver etapa Seleccionar Pruebas en la seccion 4.5.1
  • 86 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Especificaci´n de Misiones y Sesiones: consiste en detallar la informaci´n o o relativa a las sesiones, armar archivos donde se reportar´n, y organizar matea rial para tener alguna trazabilidad entre misiones, sesiones, testers e incidentes encontrados. Aqu´ podemos: asignar las misiones y sesiones a los testers, espeı cificar la rigurosidad esperada en la ejecuci´n de pruebas, describir el tipo de o prueba y establecer delineamientos de la cobertura esperada, entre otros. Roles involucrados en la etapa Tester Profesional, Tester Funcional L´der: son los encargados de ejecutar ı las actividades de dise˜o. Es importante que los testers cuenten con n conocimiento en t´cnicas de dise˜o de pruebas y enfoques para testing e n exploratorio, sabiendo para qu´ realidades aplican y as´ poder evaluar e ı cu´les son las m´s adecuadas para cada contexto. a a Productos de trabajo involucrados en la etapa Casos de Prueba dise˜ados: documenta los casos de pruebas que pueden n derivar de la aplicaci´n de una o varias t´cnicas. Estos documentos pueden o e llegar hasta el detalle de contar con los datos de pruebas espec´ ıficos que se van a utilizar para la ejecuci´n. El detalle del documento puede depender o de la experiencia que tenga el tester que ejecutar´ las pruebas (ya sea en a el dominio del producto, como en la disciplina de testing en s´ ı). Documentos de Misiones: representa un enumerado de las misiones a ejecutar por los testers. Si bien se esta basando este documento en la t´cnica de James Bach, mencionada en la secci´n 2.4.2, tambi´n es e o e una buena pr´ctica para cualquier otro enfoque adoptado, en alg´ n a u momento registrar las intenciones que tendr´n las pruebas acerca de a ensayar determinada funcionalidad. Alcance y An´lisis de Riesgo a Esta es una etapa no requerida. Si bien no es imprescindible, abordar su ejecuci´n denota cierta madurez en el proceso seguido, al involucrar actividades o secundarias en pro de la mejora de la calidad del proceso de testing en s´ Las ı. t´cnicas de manejo y gesti´n del riesgo utilizadas pueden ser diversas,algunas e o de ellas mencionadas en 2.4.4. Se hace presente en la actividad un componente fuerte de negociaci´n, contraposici´n de ideas y manejo de la interacci´n con o o o los diferentes actores del proyecto.
  • ´ 4.4. FIT MODULO II Identificador PRF SPC NVA 87 Nombre de la Actividad Priorizar Requerimientos y Funcionalidades Seleccionar y Priorizar Casos de Prueba Negociar y Validar Alcance ¿Es requerida? NO NO NO Cuadro 4.6: Etapa Alcance y An´lisis de Riesgo a PRF - Priorizar Requerimientos y Funcionalidades SPC - Seleccionar y Priorizar Casos de Prueba NVA - Negociar y Validar Alcance Figura 4.8: Etapa Alcance y An´lisis de Riesgo a Roles involucrados en la etapa Tester Profesional, Tester Funcional L´der: construyen las listas para ı priorizar con el resto de los actores, ya sea de requerimientos y funcionalidades como de los casos de prueba tentativos. Responsable de Desarrollo: aportan la visi´n t´cnica a la hora de valorar o e las funcionalidades y casos de prueba a incluir en las tareas de testing. En algunas organizaciones son tambi´n quienes pueden validar el alcance de e las pruebas negociando con el equipo de testing. Usuarios Funcionales: ayudan a la priorizaci´n de casos y funcionalidades o desde su visi´n de expertos en el dominio. Tambi´n pueden ser o e determinantes a la hora de definir el alcance de las pruebas. En otras organizaciones son autoridades de mayor jerarqu´ incluso que los ıa responsables de desarrollo de los distintos productos, y por lo tanto son quienes tienen la ultima palabra en la negociaci´n del alcance. ´ o Productos de trabajo involucrados en la etapa
  • 88 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Plan de Testing: el resultado de la negociaci´n se puede documentar en o una secci´n del plan de testing. De ser necesario una formalizaci´n mayor o o del acuerdo, se puede acompa˜ar este documento de otro que exprese la n conformidad de todos los actores con el alcance pautado.
  • ´ 4.4. FIT MODULO II 89 Priorizar Requerimientos y Funcionalidades: mediante un an´lisis a primario del equipo de testers, y luego con los dem´s integrantes del proyecto, se a elabora una lista de requerimientos y eventualmente funcionalidades asociadas a alg´n indicador de prioridad. Independientemente de la escala utilizada, la idea u es que se logre un insumo importante para la negociaci´n de alcance, manejo o de los riegos, ajustes de estimaciones de esfuerzo, entre otros. La priorizaci´n o enfocada en el riesgo puede utilizar cualquiera de las t´cnicas comentadas en la e secci´n 2.4.4 sobre manejo de riesgo, entre otras. o Seleccionar y Priorizar Casos de Prueba: en contraste con la priorizaci´n o y tomando como punto de partida un conjunto de casos de prueba, el objetivo de esta actividad es sintetizar un conjunto de casos de prueba lo m´s adecuado a posible al contexto del proyecto. Ya sea por extensi´n, complejidad, relevancia o o riesgo; los casos de prueba deben ser catalogados y etiquetados con una prioridad adecuada, o simplemente ser descartados ante casos de prueba de mejores caracter´ ısticas. Es conveniente que el equipo que discute sobre estos temas tenga un representante de cada actor relevante (en ejemplo: desarrolladores, testers, usuarios y l´ ıderes de proyecto), dependiendo tambi´n de la rigurosidad del e proceso en s´ de la organizaci´n (la formalidad en las validaciones por ejemplo). ı o Negociar y Validar Alcance: los casos de prueba dise˜ados y priorizados n (tambi´n aplicar´ a las sesiones y misiones de testing exploratorio) pueden e ıa ser validados con responsables de diferentes ´reas, o con quienes tengan la a responsabilidad de aceptar o no un componente modificado o creado. Si el proyecto requiere una formalidad superior, esta actividad produce documentos al estilo de contrato o acuerdo, donde las partes se comprometen a cierto patr´n o de transcurso de las pruebas y su resultado esperado. Al validar el alcance se est´n validando aspectos de cobertura de las pruebas dise˜adas. a n
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 90 Preparaci´n de Ejecuci´n o o Esta es la etapa en la que debemos asegurarnos que todo esta listo para pasar a la ejecuci´n. Puede ser tan compleja como el contexto lo requiera. Es necesario o tener debidamente instaladas y configuradas las versiones de los productos a probar, as´ como tambi´n todas las herramientas de apoyo a la ejecuci´n de ı e o pruebas y administraci´n del proceso de testing. De ya contar con ambientes o y herramientas de apoyo al testing, las actividades de esta etapa ser´n menos a profundas y se desarrollar´n m´s al nivel de configuraci´n y puesta a punto. a a o Identificador CET BDP CHA Nombre de la Actividad Configurar Entorno de Testing y Ambientes B´squeda de Datos para las u Pruebas Configuraci´n de Herramientas o de Apoyo ¿Es requerida? NO NO SI Cuadro 4.7: Etapa Preparaci´n de Ejecuci´n o o CET - Configurar Entorno de Testing y Ambientes BDP - B´squeda de u Datos para las Pruebas CHA* - Configuraci´n de o Herramientas de Apoyo Figura 4.9: Etapa Preparaci´n de Ejecuci´n o o Roles involucrados en la etapa Tester Profesional, Tester Funcional L´der: definen los requisitos de ı software y hardware para generar un ambiente de ejecuci´n de pruebas. o Muchas veces, las condiciones est´n dadas y puede ser que el equipo de a testing tenga que adaptar sus necesidades a los recursos disponibles. Como
  • ´ 4.4. FIT MODULO II 91 m´ ınimo tiene que asegurarse cierta independencia de datos y ambientes, de tal manera que las pruebas no se vean afectadas, por ejemplo por la existencia de pruebas del equipo de desarrollo en el mismo ambiente. Si el tester no tiene control sobre el ambiente y sus datos, no tendr´ certeza a sobre el resultado de las pruebas. Especialista en Infraestructura: asiste en la instalaci´n y configuraci´n o o de las herramientas de base a utilizar para la ejecuci´n de las pruebas, o as´ como los ambientes y las versiones del producto a verificar. ı Productos de trabajo involucrados en la etapa Documento de Entornos y Ambientes: detalla los ambientes preparados y sus caracter´ ısticas como ser el software de base, herramientas de apoyo instaladas y sus versiones, manejadores de bases de datos, caracter´ ısticas de la informaci´n presente en las bases de datos de testing (calidad, origen o y calidad de los datos, fidelidad con respecto a los datos reales que maneja el producto, vigencia de la informaci´n, entre otros) y escenarios simulados o por cada ambiente. Este documento sirve de referencia a todos los equipos para saber d´nde est´n los datos de las pruebas, c´mo se manejan y o a o qu´ prop´sito tiene cada ambiente preparado; y como constancia de los e o requisitos para la ejecuci´n de pruebas. o Configurar Entorno de Testing y Ambientes: para el desarrollo normal de las pruebas, es importante contar con un ambiente de pruebas separado del ambiente de desarrollo. Se torna muy dificultoso para las actividades de testing interactuar con versiones que sufren cambios, o con datos inestables que no pueden ser controlados. Consecuentemente las pruebas pierden validez, y no es posible generar confianza en el producto bajo testing. Si ya contamos con un ambiente de testing aislado del de desarrollo, se debe poner en condiciones para la ejecuci´n de pruebas. Esto incluye la instalaci´n del producto en la versi´n o o o que se desea verificar, la configuraci´n de software de base, manejadores de bases o de datos y cualquier otra aplicaci´n que interopere con el producto o que sean o herramientas anexas para la ejecuci´n de pruebas. Algunas de estas tareas las o puede llevar a cabo un tester, pero para la mayor´ es probable que se necesite ıa, el apoyo de expertos en infraestructura e incluso los desarrolladores; quienes suelen contar con mucho conocimiento t´cnico en configuraci´n de entornos y e o ambientes. B´ squeda de Datos para las Pruebas: es la investigaci´n de los entornos u o y ambientes con el objetivo de extraer datos para especificar los casos de prueba, para conocer el perfil de los datos cargados en el dominio, y saber a grandes rasgos si ser´ posible ejecutar los casos de prueba dise˜ados. Si no encontramos a n datos en los entornos que sean consistentes con las pruebas que se intentan ejecutar, entonces hay que intentar modificar las pruebas, o lo que es m´s a com´n, intentar modificar los datos, creando el juego de datos necesario para la u ejecuci´n de las pruebas. Dependiendo del contexto, esta actividad puede llegar o
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 92 a ser muy compleja, y puede llegar a condicionar la ejecuci´n de ciertos casos en o determinadas situaciones. Por ejemplo, supongamos que tenemos un dise˜ o de n pruebas o una misi´n que tiene por objetivo verificar el comportamiento de la o aplicaci´n ante un valor poco frecuente de una variable identificada, entonces, o si el valor consumido de cierto entorno, no est´ cargado correctamente, ese a escenario no se puede ejecutar en un principio con el mecanismo tradicional de ejecuci´n de la aplicaci´n; lo que en definitiva nos estar´ anulando los casos de o o ıa prueba relacionados con ese escenario10 . Configuraci´n de Herramientas de Apoyo: mediante esta actividad se o instalan y configuran las herramientas anexas que dar´n soporte al resto de a las actividades de testing. Entre estas herramientas pueden estar los sistemas de seguimientos de incidentes (como se ve en el ap´ndice A), herramientas e de gesti´n en general, productos de ofim´tica y herramientas auxiliares al o a testing como captores de pantalla y editores avanzados de texto plano. Si las herramientas est´n instaladas y configuradas, esta actividad se focaliza en a poblarlas de la informaci´n del proyecto de testing. o Ejecuci´n de Pruebas o La etapa de ejecuci´n de pruebas consiste en interactuar con el sistema bajo o testing corriendo las pruebas planificadas sobre el ambiente de pruebas, con la intenci´n de obtener informaci´n y detectar posibles defectos. Esta informaci´n o o o ser´ debidamente documentada e informada seg´n la estrategia seguida. En el a u proceso de ejecuci´n es posible que la misma interacci´n con el producto revele o o la necesidad de ajustar las pruebas. Identificador ECP RDC DEJ Nombre de la Actividad Ejecuci´n de Casos de Prueba o Redise˜o y Adaptaci´n de Casos n o Documentaci´n de Ejecuci´n o o ¿Es requerida? SI NO NO Cuadro 4.8: Etapa Documentaci´n de Ejecuci´n o o 10 Para bajar m´s a tierra, supongamos que tenemos una aplicaci´n que sugiere medicamena o tos gen´ricos compatibles a partir de las drogas especificadas. Puede suceder que cierta droga, e nos condicione todo un escenario de prueba, pero, que no est´ cargada en la base de datos de e las drogas disponibles. En este caso, si no fuera posible generar o emular la extracci´n de esa o informaci´n, entonces, los casos de prueba relacionados no se podr´ ejecutar. o ıan
  • 93 ECP* - Ejecuci´n o de Casos de Prueba RDC - Redise˜ o y Adaptaci´n de Casos n o DEJ - Documentaci´n de Ejecuci´n o o ´ 4.4. FIT MODULO II Figura 4.10: Etapa Ejecuci´n de Pruebas o Roles involucrados en la etapa Tester Profesional, Tester Funcional L´der: se encargan de la ejecuci´n ı o de las pruebas, registro de incidentes y documentaci´n de la ejecuci´n. o o Tambi´n quedan a su cargo las actividades relacionadas con la adaptaci´n e o y redise˜o de casos de prueba. n Tester: tambi´n ejecutan y documentan las pruebas y registran incidentes. e Las pruebas que ejecutan son dise˜adas por los testers m´s experientes, n a pero es recomendable incluirlos en las actividades de dise˜o para que n adquieran conocimiento y puedan profesionalizarse. Productos de trabajo involucrados en la etapa Casos de Pruebas Dise˜ados: sirven como gu´ de ejecuci´n de pruebas n ıa o dise˜adas, y pueden adem´s transformarse en registro de ejecuci´n de n a o pruebas. Documento de Misiones: es el que indica los lugares por donde transitar´ a a grandes rasgos el testing exploratorio (dependiendo de la estrategia o estilo abordado). Documento de Ejecuci´n: se registra la evidencia de las pruebas. Puede o ser un anexo a los casos de pruebas dise˜ados y especificados, agregando n
  • 94 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING la informaci´n del resultado de la prueba contra el resultado esperado. o Otra forma de documentar la ejecuci´n de las pruebas es contando con o un documento aparte que muestra la ejecuci´n de cada caso de prueba o dise˜ado (expresado en el documento de Casos de Pruebas Dise˜ ados, n n o Documento de Misiones) vinculando ambos documentos mediante el identificador del caso de prueba o de la misi´n. Este documento es muy util o ´ a la hora de planificar las pruebas automatizadas. Se puede adem´s anexar a la informaci´n de los incidentes encontrados por cada caso de prueba, o o en determinada ejecuci´n de testing exploratorio. o Ejecuci´n de Casos de Prueba: se trata de la actividad de ejecutar las o pruebas en el sistema. Depende de la estrategia seguida. Si contamos con casos de prueba dise˜ados, tendremos una especificaci´n de c´mo se deben ejecutar n o o las pruebas y los resultados esperados. Si tenemos un dise˜ o m´s flexible o n a una estrategia estilo exploratoria, entonces seguiremos una ejecuci´n que tiene o una componente que se beneficia del valor agregado de la participaci´n de o un tester con m´s o menos experiencia, dejando lugar para la aplicaci´n de a o modelos mentales, intuici´n y capacidad anal´ o ıtica de situaciones en el momento. La actividad de ejecutar pruebas implica el eventual registro de los incidentes detectados en el sistema de seguimiento de incidentes. En el ap´ndice A, se e destacan los aspectos deseables de la herramienta que oficie de sistema de gesti´n o de incidentes. Redise˜ o y Adaptaci´n de Casos: en el transcurso de las pruebas n o puede suceder que al contrastar el dise˜o de las pruebas, o las misiones n planificadas contra la realidad del producto, nos encontremos con que no son del todo adecuadas. En estos casos se debe reconsiderar el conjunto de pruebas planificados, y hacer los ajustes necesarios, que pueden tanto ser leves, como de gran importancia, incluso impactando en estimaciones y transcurso del proyecto en s´ No tiene sentido ejecutar casos de prueba que no est´n acordes al estado ı. a actual del producto, ya sea porque el software est´ demasiado inestable, porque a no maneja las funcionalidades de la manera que se consider´ en la planificaci´n o o de las pruebas, porque el mismo sistema no permite ciertos escenarios, entre otras muchas circunstancias. Las modificaciones pueden ir desde temas como modificar los datos de entrada, los resultados esperados, recortar o extender el alcance de las pruebas y cobertura, o incluso cambiar de tipo de prueba (por ejemplo, si el sistema est´ muy inestable, podr´ a ıamos dar un enfoque m´s de a “prueba de humo” que las pruebas estrictas dise˜adas, que pueden no tener n sentido en el estado actual de madurez del producto). Documentaci´n de ejecuci´n: es una actividad intensamente ligada a la o o actividad de ejecuci´n, pero es separada dado que se puede ejecutar casos o de prueba, eventualmente, sin dejar evidencias documentadas. El objetivo es justamente, el de llevar un documento que respalde los resultados de la ejecuci´n. Estos documentos, suelen ser un buen apoyo cuando se deben ejecutar o
  • ´ 4.4. FIT MODULO II 95 pruebas de regresi´n, o pruebas sobre funcionalidades ya verificadas. Incluso, o en metodolog´ ´giles, pueden llegar a constituir respaldo documental de los ıas a requerimientos. Para el testing exploratorio, dependiendo de la rigurosidad, se va dejando documentaci´n de los puntos visitados, los incidentes encontrados, o las observaciones, datos de prueba y cualquier comentario que el tester considere relevante. El testing exploratorio basado en sesiones (ver en secci´n 2.4.2) tiene o su propia forma de gestionarse y de documentarse, que se recomienda seguir si se desea aplicar con ´xito este mecanismo y obtener sus beneficios. El documento e de ejecuci´n que est´ acorde a un conjunto de casos dise˜ados, generalmente o e n expresado en un documento de casos de prueba, se sugiere est´ separado en e secciones y resalte una secci´n especial para cada identificador de caso de o prueba, correspondiente en ambos documentos. De esta manera, se podr´ ver un a panorama general de la ejecuci´n en el documento de dise˜o de casos de prueba o n (especificados o no) y luego acceder a su evidencia mediante la b´squeda del u identificador correcto en el documento de ejecuci´n de pruebas. o
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 96 Seguir y Actualizar el Plan Ejecut´ndose en paralelo a las dem´s, esta etapa es la que corresponde al control a a frecuente de las actividades que se van sucediendo dentro de las diferentes etapas. Como documento base, utiliza el plan de testing, extray´ndose datos e para construir mediciones que se contrastan con la realidad. Los desv´ al plan ıos pueden ser manejados, reprocesando las estimaciones para las tareas faltantes, ajustando el plan y reasignando el esfuerzo para mantener el foco en los objetivos. Identificador RPT AEF APL Nombre de la Actividad Reestimar Proyecto de Testing Ajustar Esfuerzo Ajustar Plan ¿Es requerida? NO NO SI Cuadro 4.9: Etapa Seguir y Actualizar el Plan RPT - Reestimar Proyecto de Testing AEF - Ajustar Esfuerzo APL* - Ajustar Plan Figura 4.11: Etapa Seguir y Actualizar el Plan Roles involucrados en la etapa Tester Profesional, Tester Funcional L´der: eval´ an los cambios de ı u contexto y lo contrastan contra la planificaci´n actual. De ser preciso o se pueden reunir con diferentes responsables con el fin de obtener mejor informaci´n, y presentar la replanificaci´n. Los ajustes se pueden impactar o o en el documento plan de testing.
  • ´ 4.4. FIT MODULO II 97 Productos de trabajo involucrados en la etapa Plan de Testing: es impactado con los cambios pertinente en cuanto a los ajustes efectuados a la planificaci´n. Tambi´n puede documentarse en ´l o e e los desv´ y sus motivos, con el prop´sito de que en un futuro pueda servir ıos o como material de an´lisis en pro de mejorar los procesos en s´ (conocer a ı las causas por las cuales el camino para lograr los objetivos se aparta del planificado, puede derivar en tomar acciones preventivas en futuros proyectos). Reestimar Proyecto de Testing: es la tarea de ajustar la estimaci´n ante la o presencia de desv´ y el cambio del contexto. Los proyectos suelen cambiar sus ıos prioridades, lo que impacta en todas las ´reas involucradas. Como todo plan, el a Plan de Testing debe ser un documento din´mico acorde con la realidad. Ante los a cambios del proyecto, se debe revisar el panorama y contemplar los factores que han cambiado y que motivan nuevas estimaciones con sus ajustes. Los diferentes factores internos y externos que pueden atacar el transcurso del proyecto, deben ser manejados y documentados en el plan. Replantear los objetivos, y modificar los cronogramas y actividades, nos mantendr´ en el foco nuevamente de lograr el a ´xito del proyecto. Forzar un proyecto a cumplir un cronograma o planificaci´n e o est´tica, que ya est´ obsoleta y es dispar con la realidad; lo conducir´ a un a a a probable fracaso. Ajustar Esfuerzo: mediante esta actividad se reorganizan los recursos disponibles para orientarlos a la nueva realidad. Esta es una tarea de gesti´n o que se ve beneficiada por las habilidades administrativas del Tester L´ ıder que la ejecute. La estrategia es reasignar los diferentes recursos a las tareas pendientes, para que en el transcurso del tiempo del proyecto se cumplan los objetivos. Ajustar Plan: es la actividad que se encarga de impactar las nuevas decisiones, los ajustes de esfuerzo y estimaciones en el documento Plan de Testing. El plan es la herramienta de seguimiento m´s importante y por a lo tanto debe estar actualizado con la informaci´n m´s reciente. Tanto las o a nuevas decisiones como los desv´ al plan original pueden ser documentados, ıos informaci´n que en un futuro an´lisis del proyecto puede ser util para establecer o a ´ mejoras al proceso de testing seguido.
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 98 Informar Resultados Las etapas de comunicaci´n son fundamentales para la articulaci´n del proyecto. o o Se destacan algunas actividades particulares de comunicaci´n relevantes al o proyecto de testing. Esta etapa es el nexo del proyecto de testing con el proyecto de desarrollo, y los diferentes actores. Identificador CAO OBM CIN Nombre de la Actividad Comunicar Avances y Obst´cua los Obtener Mediciones Crear Informes ¿Es requerida? SI NO SI Cuadro 4.10: Etapa Comunicar Avances y Obst´culos a CAO* - Comunicar Avances y Obst´culos a OBM - Obtener Mediciones CIN* - Crear Informes Figura 4.12: Etapa Informar Resultados Roles involucrados en la etapa Tester Funcional L´der: elaboran los informes a partir de los hechos y ı las mediciones obtenidas seg´n los patrones acordados. Estos roles suelen u participar en la creaci´n de informes finales y de estado del equipo frente o a las tareas asignadas. Son los encargados de definir y acordar con los restantes equipos qu´ tipos de informes ser´n entregados. e a Tester Profesional, Tester: se encargan de completar los informes solicitados por el Tester L´ ıder. Estos informes pueden ser destinados a Usuarios Finales, Desarrolladores, y otros perfiles por ejemplo de ´ ındole
  • ´ 4.4. FIT MODULO II 99 pol´ ıtica o direcci´n de la organizaci´n; por lo tanto el tester debe ser o o capaz de adaptar el vocabulario utilizado y visi´n del documento a cada o interlocutor. Productos de trabajo involucrados en la etapa Informe de Avances y Obst´culos: contiene el estado del proyecto de a testing en un per´ ıodo particular de tiempo. Estos informes pueden ser diarios, semanales, o con la frecuencia que el Tester L´ ıder defina o acuerde. Debe contar con la informaci´n de los logros y las dificultades del proyecto, o aportando una visi´n general que pueda ser interpretada y r´pidamente o a manejada por aquellos que necesiten estar informados del estado del proyecto, o quienes tengan las facultades para remover los obst´culos a identificados. Informe Final: detalla los acontecimientos del proyecto de testing y es elaborado al finalizarlo. Contiene informaci´n acerca de los incidentes o encontrados, las pruebas ejecutadas, las funcionalidades cubiertas, y comentarios sobre el trabajo completado. Otros informes solicitados: pueden existir documentos propios de la organizaci´n que se requiera completar al encarar actividades de testing. o Deben ser documentos que puedan ser enriquecidos por la informaci´n o derivada de las pr´cticas de testing, de lo contrario, ser´ recomendable a ıa revisar su inclusi´n en el proceso abordado. o Comunicar Avances y Obst´culos: a modo de resumen se informa a los a responsables de las diferentes ´reas, l´ a ıderes y dem´s integrantes del equipo de los a avances y puntos alcanzados, as´ como tambi´n se puede alertar de obst´culos ı e a encontrados en la ejecuci´n del proyecto. Se estila que esta actividad sea llevada o a cabo por cada integrante del equipo de testing cada cierto per´ ıodo de tiempo acordado. Obtener Mediciones Relevantes Para el Contexto: se trata de la extracci´n de informaci´n a partir de la documentaci´n generada en el proyecto o o o de testing, y posterior procesamiento de esos datos para elaborar estad´ ısticas y comunicar resultados. La informaci´n extra´ puede ser de los incidentes, o ıda teniendo en cuenta su prioridad, estado de ejecuci´n, criticidad, estado de o reparaci´n, funcionalidad afectada; o pude obtenerse informaci´n acerca de los o o desv´ del plan, de la cobertura de las funcionalidades, entre otros. Volviendo ıos al caso particular del Testing Exploratorio Basado en Sesiones, hay muchas m´tricas11 interesantes que se pueden obtener aplicando la herramienta que e 11 Algunas de las m´tricas propuestas por la t´cnica de Bach: e e N´mero de sesiones completas u N´mero de problemas encontrados u ´ Areas funcionales cubiertas
  • 100 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING propone el m´todo. Estas mediciones ser´n insumo importante de los informes e a presentados. Crear Informes: es la elaboraci´n de documentos informativos, de los cuales o los interesados y l´ ıderes podr´n servirse para tomar decisiones. Estos informes a pueden ser informes intermedios de avance, o informes finales de proyecto. Suelen contener la informaci´n de la cobertura alcanzada, las estad´ o ısticas de los incidentes reportados, con su gravedad, origen y prioridad. Puede ir acompa˜ ado n de alguna sugerencia o comentario de los testers respecto a la impresi´n general o del comportamiento y estado del producto. Verificaci´n de Documentos o La etapa de verificaci´n de documentos se compone de actividades que pueden o aplicarse desde el inicio del proceso de desarrollo. El objetivo es encontrar ambig¨edades, carencias en claridad, formato y redacci´n de los documentos que u o servir´n de entrada para diferentes equipos de la organizaci´n. Esta etapa no a o es obligatoria, pero es muy recomendable que sea ejecutada en contextos donde los documentos son insumo fundamental para la construcci´n del producto, la o verificaci´n, as´ como cuando son material importante en la toma de decisiones o ı del proyecto. Roles involucrados en la etapa Equipo de Testing: verifican los documentos y env´ ıan sus dudas y observaciones a los autores. Si las observaciones generan correcciones, el documento puede volver a manos del equipo de testing para un nuevo ciclo de verificaci´n. De tratarse de documentos de definici´n de o o requerimientos y funcionalidades, es sabido que los errores encontrados son ventajosos en costo para la organizaci´n frente a los errores encontrados o en etapas posteriores, cuando el producto est´ construido, y por lo tanto a es recomendable (no obligatorio) que el equipo de testing participe de la revisi´n de los documentos. o Productos de trabajo involucrados en la etapa Informe de Consultas y Observaciones: contiene las dudas y puntos observados en la verificaci´n efectuada por el equipo de testing. Las observacioo nes pueden contener sugerencias de redacci´n, formato, identificaci´n de o o ambig¨edades, faltas ortogr´ficas y principalmente errores en definici´n u a o (de requerimientos por ejemplo). Las herramientas inform´ticas proveen a mecanismos para elaborar la correcci´n mediante control de cambios, por o Porcentaje del tiempo de la sesi´n dedicado a preparar el testing o Porcentaje del tiempo de la sesi´n dedicado al ejecutar pruebas o Porcentaje del tiempo de la sesi´n dedicado a investigar problemas o
  • ´ 4.4. FIT MODULO II 101 lo tanto muchas veces este documento est´ incluido en una versi´n revia o sada del documento a verificar. Aunque se pueda contar con la versi´n o revisada y corregida, es buena pr´ctica extraer las dudas y observaciones a en un documento aparte que pueda ser f´cilmente consultado en el futuro a (o que sirva de insumo para la comprensi´n del contexto, y correcci´n de o o otros documentos). Documentos a verificar: son los documentos que estar´n en el circuito de a verificaci´n del equipo de testing, y correcci´n por parte de los autores. o o Los incidentes encontrados a los documentos pueden incluso registrarse en el sistema de seguimiento de incidentes si el proceso lo requiere. Identificador ESP RVD ROB IRD Nombre de la Actividad Establecer Par´metros Observaa bles Revisi´n de Documentos o Registrar Observaciones a Documentos Crear Informe de Revisi´n de o Documentos ¿Es requerida? NO SI NO SI Cuadro 4.11: Etapa Verificaci´n de Documentos o ESP - Establecer Par´metros Observables a RVD* - Revisi´n o de Documentos ROB - Registrar Observaciones a Documentos IRD* - Crear Informe de Revisi´n de Documentos o Figura 4.13: Etapa Verificaci´n de Documentos o
  • 102 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Establecer Par´metros Observables: se construye una lista de elementos a a los que se pondr´ especial ´nfasis en la verificaci´n de documentos. Los a e o aspectos pueden involucrar la visi´n del testing, de otros equipos de desarrollo, o par´metros de expertos del negocio entre otros involucrados en el proyecto. a Para la revisi´n de documentos que no est´n directamente involucrados con las o a actividades de testing, o que se desea un enfoque desconocido por los testers, basta con acordar con el equipo de testing cu´les son los puntos a tener en a cuenta durante la revisi´n, as´ como la informaci´n esperada del documento. o ı o Revisi´n de Documentos: actividad que corresponde a la lectura e o investigaci´n de los documentos con la intenci´n de detectar puntos d´biles. o o e En cuanto al testing, se verifica la documentaci´n para corroborar que los o requisitos sean verificables, est´n completamente definidos, no tengan problemas e de redacci´n, ambig¨edades u otras carencias. No solamente los documentos que o u contienen requerimientos pueden ser verificados, sino tambi´n todo documento e para el que se considere importante que cuente con revisiones imparciales, independientes de su autor original. Una buena estrategia que apoya actividades de testing temprano es que el equipo de testing est´ verificando los documentos e involucrados en la construcci´n del producto y que ser´n insumo para la o a construcci´n del futuro testware y por consiguiente de la ejecuci´n de las o o actividades de testing. Registrar Observaciones a Documentos: se trata del registro de las dudas, consultas y observaciones que el tester identifica en el documento. Muchas veces las mismas herramientas de ofim´tica proveen funcionalidades a para el control de cambio. En proyectos de mayor escala, con procedimientos de documentaci´n estrictos, puede ser necesario registrar estas observaciones o directamente como incidentes en un sistema de seguimiento de incidentes, rigi´ndose por las mismas reglas que el ciclo de prueba de un incidente del e producto construido en s´ ı. Crear Informe de Revisi´n de Documentos: es la manera en la que o se comunican los resultados de la revisi´n. Puede ser un documento aparte, o destacando las observaciones, dudas y consultas por cada secci´n del documento o revisado. Es com´n que este informe, sea un versionado del mismo documento, u aprovechando las capacidades de revisi´n y control de cambios que brindan las o herramientas de ofim´tica (haciendo seguimiento de modificaciones, sugerencias, a comentarios, entre otras funcionalidades).
  • ´ 4.4. FIT MODULO II 103 An´lisis de Defectos a La informaci´n almacenada de los incidentes puede ser analizada para extraer o conclusiones interesantes. Esta etapa puede ser parte de un an´lisis post mortem a del proyecto al finalizar un periodo de pruebas, o como para reforzar la estrategia de pruebas de regresi´n. El objetivo com´n es aprender de los acontecimientos o u y tomar ventaja de ellos en el futuro. As´ podremos identificar puntos d´biles ı, e y puntos fuertes, teniendo material para generar alertas, mejorar pr´cticas o a tomar decisiones ventajosas para el contexto. Identificador AIN PIN CIA Nombre de la Actividad Analizar Informaci´n de Incideno tes Procesar Informaci´n de Incideno tes Crear Informes de An´lisis de a Incidentes ¿Es requerida? SI NO SI Cuadro 4.12: Etapa An´lisis de Defectos a AIN* - Analizar Informaci´n de Incidentes o PIN - Procesar Informaci´n de Incidentes o CIA* - Crear Informe de An´lisis de Incidentes a Figura 4.14: Etapa An´lisis de Defectos a Roles involucrados en la etapa Tester Profesional, Tester Funcional L´der: analizan la informaci´n de ı o los incidentes registrados, tratando de encontrar patrones o elementos notables que se puedan aprovechar para mejorar el proceso. Son los encargados de sintetizar y comunicar esta informaci´n. o
  • 104 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Productos de trabajo involucrados en la etapa Informe de An´lisis de Defectos: presenta los datos estad´ a ısticos de los incidentes y las conclusiones que de ellos se pueden extraer. Se pueden mencionar aspectos sobre qu´ funcionalidades son m´s propensas a errores, e a cu´les son los tipos de errores que se cometen m´s, d´nde est´ la fuente del a a o a error en el proceso (por ejemplo en la especificaci´n de los requerimientos, o en la construcci´n del producto, en el dise˜o de la soluci´n) entre otros o n o factores. An´lisis de la Informaci´n de Incidentes: es la actividad de recopilar a o y seleccionar la informaci´n de los incidentes que se considere necesaria para o extraer conclusiones. Comienza por la investigaci´n del repositorio de incidentes o y tambi´n estudia las particularidades del proyecto, revisando requerimientos, e o informaci´n de las prioridades, riesgos identificados y manejados, y elementos o presentes en el Plan de Testing. Tambi´n involucra la tarea de decidir cu´les son e a los criterios para clasificar la informaci´n, cu´les mediciones queremos obtener, o a y qu´ factores deseamos investigar. A modo de ejemplo, el an´lisis puede e a estar enfocado a: investigar qu´ sucedi´ con un conjunto de funcionalidades, e o los desv´ en los tiempos del proyecto de testing y sus causas, identificar ıos proveedores m´s confiables, establecer una mejor estrategia para las pruebas a de regresi´n, identificar fortalezas y debilidades en el proyecto de desarrollo, o entre muchos otros posibles objetivos. Procesar Informaci´n de Incidentes: el esfuerzo en esta actividad se o concentra en ordenar la informaci´n y procesarla seg´n las mediciones que se o u deseen obtener. Los incidentes suelen tener informaci´n de gravedad, tipo de o incidente, versi´n del producto, proveedor o desarrollador involucrado, estado o de la resoluci´n, entre otros. Lo importante es tomar la muestra de incidentes o a analizar, supongamos, para una versi´n del producto, y categorizarlos para o ajustarse a las diferentes m´tricas definidas. Informaci´n com´ n que se desea e o u obtener puede ser: funcionalidades con m´s y menos errores (seg´ n gravedad), a u proveedores que provocan m´s defectos, incidentes de gravedad alta que no a fueron reparados, cantidad de idas y vueltas entre desarrollo y testing para un incidente de cierta funcionalidad, incidentes de las diferentes etapas de desarrollo (errores en requerimientos, dise˜o de la soluci´n, en implementaci´n) entre n o o muchos otros posibles factores. Crear Informe de An´lisis de Incidentes: es el trabajo de documentar la a etapa de An´lisis de Defectos. El informe debe contener los resultados obtenidos a del procesamiento de la informaci´n del an´lisis y puede ir acompa˜ ado de o a n algunas sugerencias sobre los puntos fuertes y d´biles, y c´mo atacarlos. Tambi´n e o e puede contener secciones comentando el proceso seguido para el an´lisis, a medici´n y construcci´n de la informaci´n, as´ como tambi´n alguna gu´ acerca o o o ı e ıa de c´mo se debe interpretar la informaci´n contenida en el documento. o o
  • ´ 4.4. FIT MODULO II 4.4.2. 105 Roles Un rol se especifica mediante un nombre y una descripci´n de las funciones o que desempe˜a una persona que lo asume. Puede incluir las aptitudes t´cnicas n e deseadas o requeridas para desempe˜ar cierto grupo de actividades, as´ como n ı las caracter´ ısticas m´s importantes que distinguen al rol. Los roles pueden ser a adoptados por varias personas, y a su vez, una persona puede tomar varios roles. Esto sucede a menudo con roles m´s generales o m´s experientes que abarcan a a las actividades de los roles m´s b´sicos. a a Tester Funcional Conoce los conceptos b´sicos de testing de software. Es capaz de ejecutar pruea bas, trabajar en conjunto con l´ ıderes de testing y testers m´s experimentados. a Posee habilidades de comunicaci´n y es capaz de participar en los procesos de o dise˜o de pruebas aplicando t´cnicas, y an´lisis de requerimientos de testing en n e a conjunto con testers m´s experientes o profesionales. a Tester Funcional Profesional Cuenta con las habilidades del Tester Funcional m´s experimentadas, adem´s es a a capaz de analizar requerimientos, construir requerimientos de testing, seguir una metodolog´ o proceso de testing, establecer una estrategia adecuada para un ıa determinado contexto, dise˜ar pruebas y elaborar documentaci´n e informes de n o testing. Tambi´n es capaz de contribuir a la elaboraci´n de un plan de testing, e o seguirlo y ajustarlo. Posee conocimiento en t´cnicas de dise˜o de pruebas y e n es capaz de discernir cu´l aplica para el caso dado, y que beneficios aporta. a Debe trabajar en coordinaci´n con l´ o ıderes de testing y responsables. Apoya a los usuarios en sus pruebas de aceptaci´n. Puede responsabilizarse de proyectos o de testing de mediano porte. Tester Funcional L´ ıder El tester l´ ıder, cuenta con las habilidades del tester profesional y adem´s, es a capaz de coordinar y dirigir las actividades de testing, siguiendo determinados procesos, pudiendo aportar en la mejora continua de estos. Dirige al equipo de testing, y es su responsable. Interact´a con los responsables de las dem´s u a a ´reas dando visibilidad sobre la informaci´n generada por el testing, aportando o conocimiento en su utilizaci´n para toma de decisiones. Puede asistir al tester o profesional en la elecci´n de las estrategias y guiarlo en el rumbo a seguir. o Establece los objetivos del proyecto de testing particular y su interacci´n con o el proyecto de desarrollo. Entrena y promueve la capacitaci´n continua del o grupo de testing, adem´s de los actores involucrados en el proyecto cuando a sea necesario. Puede responsabilizarse por proyectos de gran porte.
  • 106 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Usuarios Funcionales Ser´n los encargados de ejecutar las pruebas de aceptaci´n de los productos. a o Puede ser en conjunto con los testers o no. Son los clientes internos, y definir´n a si un producto, o determinado cambio cumple con sus expectativas. Tambi´n e ofician de or´culo12, al ser expertos en el dominio; poseen el conocimiento del a negocio, y muchas veces, son los destinatarios finales del producto13 . Referentes o Responsables de Desarrollo Se encargan de la implementaci´n de las soluciones, responden al L´ o ıder de proyecto. En relaci´n al testing funcional, es el actor encargado de notificar o al tester de un nuevo producto, cambio o liberaci´n para pruebas. Coordinan o la reparaci´n de los incidentes. Toman decisiones a partir de las pruebas de los o testers o de los usuarios funcionales14 . L´ ıderes, Responsables de Proyecto o Gestores Est´n encargados de la coordinaci´n del proyecto de desarrollo. Trabaja en a o coordinaci´n con el Tester L´ o ıder, elaborando nuevas estrategias a partir de la informaci´n aportada por testing. En cuanto al relevo de requerimientos, es un o nexo importante entre el tester y los usuarios funcionales, sobre todo al inicio del proyecto. Negocia la propuesta de alcance del plan de testing, y colabora en la priorizaci´n de funcionalidades y casos de prueba. El L´ o ıder puede estar presente en pruebas de aceptaci´n y debe tomar decisiones de liberaci´n de funo o cionalidades y productos a partir de la informaci´n aportada por testing. o En cuanto a los incidentes, el L´ ıder de proyecto es tambi´n un nexo inicial entre e desarrolladores y testers, y puede coordinar la reparaci´n de los incidentes seg´ n o u su percepci´n de la prioridad, sirvi´ndose de la prioridad sugerida por testers. o e Especialista en Infraestructura: Coordinan y gestionan la instalaci´n y configuraci´n de los ambientes, entornos, o o herramientas de apoyo, permisos, y todo lo que tenga que ver con infraestructura tecnol´gica para que se puedan llevar a cabo las pruebas. Generalmente toda o organizaci´n cuenta con un responsable en esta materia (o es impl´ o ıcitamente ejecutado por integrantes del equipo de desarrollo). 12 Un or´culo nos brinda informaci´n acerca del resultado esperado de una prueba. Es usado a o para discernir cuando un test fue exitoso o estamos ante un posible incidente. 13 Este rol se conserva desde el modulo inicial. 14 Este rol tiene variaciones desde el identificado en el punto de partida.
  • ´ 4.5. FIT MODULO III 4.5. 107 FIT M´dulo III: Proceso de Testing Funo cional Automatizado Existen ciertos tipos de problemas que no pueden ser atacados solamente con las etapas del proceso del M´dulo II del FIT. Algunos de ellos motivan a la o incorporaci´n de soluciones orientadas a la automatizaci´n de pruebas, por o o ejemplo si: El testing Manual consume mucho tiempo, es repetitivo y tedioso, y es propenso a contener errores. Las restricciones de tiempo del proyecto no admiten dedicar esfuerzo a ejecutar pruebas de regresi´n ante sucesivas liberaciones del producto, o o ante peque˜os cambios en el software. Finalmente, el producto es liberado n con poco testing, o sin testing alguno. Es necesario correr pruebas que involucren grandes vol´menes de datos. u Un siguiente an´lisis posible, podr´ referirse al estado de la organizaci´n, para a ıa o decidir por ejemplo si se encuentra en condiciones de enfrentar un proyecto de automatizaci´n. Los siguientes son algunos indicadores de situaciones en las que o ser´ conveniente implementar automatizaci´n de pruebas: ıa o Cuando no se est´ en momentos de grandes cambios organizacionales, a grandes presiones, o un clima de des-organizaci´n general en curso. o Cuando el estado actual del testing no es satisfactorio. Cuando existe un compromiso e inter´s estrat´gico y pol´ e e ıtico de la organizaci´n en apoyar al testing automatizado y manual. o Si la realidad de la organizaci´n no se ajusta a los puntos mencionados, no o significa que no se deba introducir testing automatizado, sino que quiz´s sean a mayores los obst´culos a superar. En definitiva, la automatizaci´n supone una a o inversi´n relativamente superior a la de las pruebas manuales, con un retorno a o m´s largo plazo. a El roadmap definido ha transitado por el proceso del M´dulo II del FIT, o cumpliendo etapas y actividades de testing manual y a continuaci´n lo har´ con o a las etapas y actividades del proceso de testing automatizado del M´dulo III o del FIT. En este m´dulo se busca definir el proceso de automatizaci´n, con la o o tecnolog´ a usar, y sus detalles t´cnicos. El M´dulo III del FIT tiene como ıa e o objetivo brindar soporte a la implementaci´n del testing automatizado y lograr o su institucionalizaci´n. o
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 108 4.5.1. Etapas de Proceso de Testing Funcional Automatizado Definiremos a continuaci´n las etapas del m´dulo con sus identificadores, meno o cionando los productos de trabajo que est´n relacionados. Posteriormente, detaa llaremos cada una de las etapas involucradas y las actividades que las componen. El proceso de testing automatizado consta de las siguientes etapas: SHE - Seleccionar Herramientas. SPR - Seleccionar Pruebas. PDA - Preparaci´n de Automatizaci´n. o o IPA - Implementaci´n de Prueba Automatizada. o EPA - Ejecuci´n de Pruebas Automatizadas. o AED - An´lisis de Errores Detectados. a MTA - Mantenimiento de Testware de Automatizaci´n. o INR - Informar Resultados. En este m´dulo, todas las etapas del proceso deber´ ejecutarse. Para que el o ıan proceso sea flexible, se admite variar la rigurosidad con que se ejecutan las diferentes actividades, c´mo se documenta el proceso, y adem´s cu´les de las activio a a dades opcionales ser´n elegidas para integrar el roadmap del proyecto particular. a
  • ´ 4.5. FIT MODULO III 109 SPR* - Seleccionar Pruebas PDA* - Preparaci´n o de Automatizaci´n o IPA* - Implementaci´n o de Prueba Automatizada EPA* - Ejecuci´n de o Pruebas Automatizadas INR* - Informar Resultados MTA* - Mantenimiento de Testware de Automatizaci´n o SHE* - Seleccionar Herramientas AED* - An´lisis de a Errores Detectados Figura 4.15: FIT M´dulo III: Proceso de Testing Funcional Automatizado o El cuadro siguiente muestra en qu´ etapa se construye o se complementa con e m´s informaci´n cada documento. a o
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 110 Identificador SHE SPR Nombre de la Etapa Seleccionar Herramientas Seleccionar Pruebas PEJ Preparaci´n de Ejecuci´n o o IPA Implementaci´n de Prueo bas Automatizadas Ejecuci´n de Pruebas Auo tomatizadas Mantenimiento de Testware de Automatizaci´n o EPA MTA Documento Involucrado Informe de Herramientas Casos de Pruebas Dise˜ados / Informe de Inn cidentes / Documento de Misiones y Sesiones / Documento de Dise˜ o de n Pruebas Automatizadas Documento de Entornos y Ambientes Documento de Dise˜ o de n Pruebas Automatizadas Documento de Resultados de Automatizaci´n o Documento de Mantenimiento de Automatizaci´n o Cuadro 4.13: Documentos del Proceso de Testing Funcional Automatizado.
  • ´ 4.5. FIT MODULO III 111 Seleccionar Herramientas En la etapa de selecci´n de herramientas se compromete gran parte del ´xito o e del proyecto. Las herramientas son “la punta del iceberg”, es decir, si bien no es todo el proceso de automatizaci´n que pasa por las herramientas a utilizar, o son el elemento m´s notable. Se busca lograr el conjunto de herramientas m´s a a adecuado al contexto. Para este fin seguiremos algunas actividades que den un marco de confianza que evite una decisi´n apresurada y con pocos argumentos. o Identificador IDR INH CPC EIH DFH Nombre de la Actividad Identificar Restricciones Investigar Herramientas Construir Prueba de Concepto Elaborar Informe de Herramientas Definir Herramientas ¿Es requerida? SI NO NO NO SI Cuadro 4.14: Etapa Seleccionar Herramientas
  • 112 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING IDR* - Identificar Restricciones INH - Investigar Herramientas CPC - Construir Prueba de Concepto EIH - Elaboraci´n de o Informe de Herramientas DFH* - Definir Herramientas Figura 4.16: Etapa Seleccionar Herramientas Roles involucrados en la etapa Tester Profesional, Tester Funcional L´der, Tester Automatizador: invesı tigan y elaboran pruebas de concepto con el fin de evaluar las herramientas y recopilar informaci´n para que la decisi´n sobre las herramientas a o o utilizar se base en argumentos s´lidos, dado que la definici´n de las heo o rramientas a utilizar puede estar en manos del equipo de testing, o puede ser responsabilidad de otros roles (sobre todo si involucra una inversi´n o econ´mica). o Productos de trabajo involucrados en la etapa Informe de Herramientas: contiene las conclusiones sobre el proceso de selecci´n de herramientas, con los resultados de la evaluaci´n o o destacando puntos fuertes y d´biles de cada una en relaci´n con e o el contexto. Adem´s, de ser necesario, se puede incluir informaci´n a o desprendida de cualquier otra actividad del proceso de selecci´n de o herramientas, como ser la identificaci´n de las restricciones (las que pueden o transformar determinadas caracter´ ısticas de las herramientas en ventajas o desventajas).
  • ´ 4.5. FIT MODULO III 113 Identificar Restricciones: consiste en la elaboraci´n de una lista de condio ciones espec´ ıficas de la organizaci´n, el producto y el estado actual del proyecto. o Las restricciones se pueden agrupar en diferentes categor´ como ve´ ıas ıamos en la secci´n 2.5.2. o Algunas de las categor´ para ordenar restricciones pueden ser: ıas Requisitos de Uso: las configuraciones de hardware y software que deben estar presentes para poder hacer uso de la herramienta. Plataforma del Producto: la plataforma y la arquitectura del producto que se va a automatizar, deben ser soportadas por la herramienta seleccionada. Por ejemplo, si la aplicaci´n es web, sobre java, o si es cliente/servidor con o una interfaz de escritorio, entre otras posibilidades. Interoperabilidad : c´mo se integra la herramienta con el producto, con o otras herramientas, con software y hardware de base. Soporte: la disponibilidad de recursos para solucionar eventuales problemas, como ser soporte t´cnico propietario o la disponibilidad de comunidae des de usuarios para herramientas libres. Un factor importante a considerar al evaluar las restricciones soporte son la presencia en el mercado local de un representante de la herramienta, o de una comunidad de usuarios activa. Costo y Estrategia: la restricci´n econ´mica al uso de la herramienta en o o cuanto al precio de las licencias de uso; o imposiciones de marco pol´ ıtico y estrat´gico, por ejemplo que indiquen la obligatoriedad del uso de ciertos e componentes o herramienta de determinado proveedor comercial, o del mundo del software libre. Tambi´n el tiempo requerido o disponible para e desarrollar un proyecto de automatizaci´n, es una limitante estrat´gica. o e Curva de Aprendizaje: el tiempo estimado que le tomar´ a un usuario ıa inexperto, o a un equipo en determinado nivel en relaci´n a una o herramienta, dominar la tecnolog´ que ofrece cierta herramienta. ıa Teniendo claras las restricciones, se puede contrastar las prestaciones de las herramientas investigadas y candidatas, tratando de identificar cu´les las a satisfacen. Investigar Herramientas: las herramientas candidatas pueden estar predeterminadas por la organizaci´n por temas pol´ o ıticos o estrat´gicos, o porque se e considera que existe mucha experiencia acumulada en su utilizaci´n. De todas o formas es conveniente aventurarse peri´dicamente a investigar nuevas soluciones o en el mercado comercial, y en el mundo del software libre.
  • 114 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Construir Prueba de Concepto: consiste en crear prototipo tecnol´gico o sencillo con el fin de identificar mayores inconvenientes al interactuar con la herramienta, y as´ evaluar la posible inclusi´n en la lista de herramientas ı o candidatas. Se busca identificar las ventajas y desventajas de la herramienta en los siguientes aspectos: Curva de aprendizaje: la dificultad con la que el automatizador puede interactuar con la herramienta y conseguir un resultado satisfactorio para el proyecto de automatizaci´n o Funcionalidad de grabaci´n y reproducci´n: es deseable que para ciertos o o escenarios, como ser el de desarrollo web, se pueda contar con la ventaja de poder grabar un esqueleto a la vez que se corre la aplicaci´n. Esto es o ventajoso dado que no es necesario comenzar a escribir el script desde cero. Configuraci´n: el tiempo que se dedica a que la herramienta est´ funcioo e nalmente disponible para su uso. Elaborar Informe de Herramientas: se construye un documento listando las herramientas analizadas, destacando las herramientas candidatas, identificando sus ventajas y desventajas. El informe contiene algunos puntos del proceso de selecci´n de herramientas, como las restricciones de la organizaci´n, o o comentario sobre las herramientas, y opiniones, percepciones o juicios informales sobre las herramientas, entre otros puntos. Definir Herramientas: finalmente, luego del proceso, se busca llegar al conjunto de herramientas a utilizar para la automatizaci´n. Es importante o que esta decisi´n sea tomada cuidadosamente, bas´ndose en el an´lisis de la o a a informaci´n generada en el proceso, dado que puede tener un gran impacto en o el proyecto el hecho de que sea necesario redefinir el esquema de herramientas de automatizaci´n. o Seleccionar Pruebas La etapa de selecci´n de pruebas consta del an´lisis del conjunto total de eleo a mentos automatizables con el fin de decidir cu´les de ellos ser´n automatizados, a a cu´les no, y en qu´ orden. Se puede optar entre m´ltiples criterios para seleca e u cionar pruebas, como los vistos en la secci´n 2.5.1. o El conjunto inicial de casos de pruebas podr´ ser generado a trav´s de testing diıa e se˜ado, ser compuesto por descripciones de pruebas motivadas por anotaciones n del testing exploratorio, e incluso ser la reproducci´n de los incidentes encontrao dos en otras instancias de pruebas. Es importante identificar los objetivos que buscamos de la automatizaci´n y priorizarlos. El foco puede ser ahorrar tiempo o en tareas repetitivas, optimizar la ejecuci´n con grandes vol´ menes de datos, o u evitar repetir tareas complejas y tediosas o llegar a un conjunto de pruebas que
  • ´ 4.5. FIT MODULO III 115 ataquen el n´cleo del producto, entre otros. Tener las prioridades nos ayudar´ a u a seleccionar los casos de prueba y decidir en qu´ orden ser´n implementadas las e a pruebas automatizadas y en qu´ orden es conveniente ejecutarlas. e Esta etapa est´ compuesta por algunos puntos estrechamente relacionados, en a lugar de actividades como las restantes etapas: Contar con el conjunto de casos de prueba: sean casos de pruebas dise˜ados, notas de testing exploratorio, reproducciones de incidentes. n Identificar el objetivo de la automatizaci´n: crear una lista o priorizada de lo que se espera conseguir con la automatizaci´n de pruebas. o Seleccionar las pruebas seg´ n objetivos: teniendo en cuenta la lista u de objetivos de la automatizaci´n, seleccionar los casos de prueba que o est´n mejor orientados a cumplir los objetivos. e Decidir orden de implementaci´n y ejecuci´n: organizar los casos de o o pruebas seleccionados con el fin de decidir cu´les se implementan primero a y en qu´ orden deber´ ser ejecutados. La relaci´n entre los diferentes e ıan o casos de prueba y la lista priorizada de objetivos nos ayudar´ con esta a organizaci´n. o Roles involucrados en la etapa Tester Profesional, Tester Funcional L´der: analizan las pruebas ejecuı tadas y sus resultados, notas de ejecuci´n y los incidentes detectados y o corregidos para seleccionar un conjunto de pruebas a desarrollar, o identificar los lugares donde va a estar atacando la automatizaci´n. Trabajan o adem´s con el Tester Automatizador para conocer la visi´n de qu´ implica a o e automatizar determinada prueba. Tester Automatizador: aporta la opini´n m´s valiosa acerca de qu´ trae o a e como consecuencia automatizar determinada prueba. Por ejemplo en temas de complejidad de implementaci´n con las herramientas dadas, o mantenibilidad de las pruebas, tiempo que insume y en general qu´ recurso e insume la automatizaci´n en s´ (informaci´n crucial a la hora de o ı o contrastarla con el beneficio que reporta, y poder tomar una decisi´n al o respecto de c´mo invertir en automatizaci´n). o o Productos de trabajo involucrados en la etapa Documento de Dise˜o de Pruebas Automatizadas: presenta las pruebas pan ra las cuales se tiene la intenci´n de implementar pruebas automatizadas. o Los casos de pruebas pueden estar identificados y as´ hacerlos corresponder ı con su implementaci´n, lo cual es un extra de trazabilidad que puede facio litar las tareas de mantenimiento de los tests automatizados. Puede incluir dise˜o detallado de los pasos y puntos de verificaci´n de los scripts, para n o
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 116 un mantenimiento m´s riguroso. Adem´s pueden organizarse los scripts a a por criterio de funcionalidad cubierta, complejidad, tipo de prueba, suites a las que pertenecen, entre otros. Preparaci´n de Automatizaci´n o o Para dar paso a la automatizaci´n de pruebas, es necesario transitar por las o actividades de preparaci´n. Esta etapa incluye la instalaci´n y configuraci´n de o o o las herramientas que sirven a la automatizaci´n, as´ como tambi´n los ambientes o ı e en donde estar´ instalado el producto, junto con sus fuentes de datos. Por ultimo, a ´ como actividad prioritaria se destaca el dise˜o de la prueba automatizada, la n agrupaci´n l´gica de los archivos de la automatizaci´n y el orden en que se o o o deben ejecutar las pruebas. Identificador PEP DPA PFA Nombre de la Actividad Preparar Entorno y Producto Dise˜ar Prueba Automatizada y n Organizar Ejecuci´n o Preparar Framework de Automatizaci´n o ¿Es requerida? SI SI SI Cuadro 4.15: Etapa Preparaci´n de Automatizaci´n o o PEP* - Preparar Entorno y Producto DPA* - Dise˜ar n Prueba Automatizada PFA* - Preparar Framework de Automatizaci´n o Figura 4.17: Etapa Preparaci´n de Automatizaci´n o o Roles involucrados en la etapa
  • ´ 4.5. FIT MODULO III 117 Tester Profesional, Tester Funcional L´der, Tester Automatizador: colaı boran en la definici´n de las pruebas automatizadas y en c´mo ser´n ejeo o a cutadas. Es conveniente que el Tester Automatizador cuente con esta informaci´n como entrada a su trabajo, dado que de lo contrario tendr´ que o a invertir tiempo investig´ndola y defini´ndola. El Tester Automatizador a e por su parte construye y acondiciona las herramientas de automatizaci´n o necesarias, contando con el apoyo de alg´n Especialista en Infraestructura. u Especialista en Infraestructura: instala las versiones del producto y las herramientas necesarias para la construcci´n y ejecuci´n de las pruebas o o automatizadas. Puede trabajar en equipo con el Tester Automatizador, dado que por su perfil m´s t´cnico en programaci´n, tiene conocimientos a e o de desarrollo, instalaci´n y configuraci´n de herramientas y ambientes. o o Productos de trabajo involucrados en la etapa Documento de Entornos y Ambientes: como en el m´dulo de Testing o Funcional Manual, este documento detalla los ambientes de testing, incorporando adem´s la informaci´n sobre las herramientas a utilizar y a o c´mo encontrarlas en el entorno preparado (en t´rminos generales, se o e puede decir que es el mismo documento presentado en el m´dulo II, que o adem´s anexa esta informaci´n). a o Preparar Entorno y Producto: dependiendo de la naturaleza de las pruebas automatizadas que se intenten lograr, ser´ la severidad con que a esta actividad debe ser ejecutada. Las pruebas orientadas a datos son extremadamente sensibles a los cambios en los entornos. Es conveniente, siempre que sea posible, independizarse de los datos almacenados en las bases de datos y que la prueba cuente con un mecanismo para generarse sus propios datos de entrada. Esto puede resultar costoso de implementar y en tiempo de ejecuci´n, pero muchas veces es la unica alternativa posible para poder o ´ ejecutar pruebas automatizadas, sobre todo en entornos inestables o que son accedidos por m´ltiples actores. La preparaci´n de los datos y del producto para u o la ejecuci´n de la automatizaci´n se puede hacer mediante m´dulos especiales o o o que ingresen lo datos necesarios, ya sea mediante la interacci´n con el sistema o o levantando respaldos en bases de datos. Cuando el volumen de la prueba lo amerita, la preparaci´n de los datos y el producto puede ser manual; por ejemplo, o si el ingreso de datos es muy complejo de automatizar, pero gener´ndolos a manualmente es posible poner a ejecutar una prueba que ahorra mucho tiempo de testing manual, entonces, la preparaci´n manual de los datos y el producto o se vuelve conveniente. Dise˜ ar prueba automatizada y organizar ejecuci´n: el objetivo es n o documentar la organizaci´n l´gica de los scripts, y las particularidades de o o organizar las pruebas en conjuntos relacionados. Los scripts de prueba pueden tener una contraparte en mayor nivel que indique los puntos m´s relevantes a
  • 118 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING que toca el script lo que favorece el mantenimiento de los scripts, visto en la secci´n 4.5.1. Llamaremos “suite” al conjunto de scritps agrupados bajo alg´ n o u criterio. Una suite suele encargarse de un ciclo funcional, de una serie de pasos, por ejemplo, imitando el comportamiento de un usuario en la aplicaci´n desde o que ingresa, tiene interacci´n, ingresa datos, obtiene resultados y sale de la o aplicaci´n. Esta forma de estructurar las pruebas automatizadas favorece la o reutilizaci´n de scritps. Es conveniente que los scritps se encarguen de tareas o puntuales y manejables para poder integrar m´s de una suite. De contar con a una complejidad superior, puede ser necesario organizar las suites en ´reas de a pruebas funcionalmente relacionadas. Un ´rea de prueba se compone de suites, y a ´ estas se componen de scritps. Areas de pruebas y suites son agrupaciones l´gicas o de elementos sem´nticamente relacionados, s´lo que de diferente jerarqu´ a o ıa. Preparar Framework de Automatizaci´n: consta de la instalaci´n de las o o herramientas necesarias para implementar y ejecutar las pruebas automatizadas, y del dise˜o de la arquitectura de las pruebas tanto en la organizaci´n n o del testware como en la definici´n de la informaci´n a extraer de las pruebas. o o Por ejemplo, se tratan temas de en qu´ forma se van a almacenar los archivos e generados por la automatizaci´n, cu´l va a ser la jerarqu´ de los directorio, o a ıa qu´ informaci´n se registrar´ en un script, y c´mo se relacionar´n las ´reas de e o a o a a pruebas, suites y scripts entre s´ y en la jerarqu´ de directorios propuesta. ı ıa Un framework m´ ınimo de automatizaci´n cuenta con: o Herramientas de desarrollo: los entornos en los cuales se implementaran las pruebas. Puede ser que la herramienta cuente con su entorno y lenguaje propios, o que se acuda a lenguajes de programaci´n populares. o Herramientas de ejecuci´n: son capaces de ejecutar una prueba automatio zada escrita en determinado lenguaje sobre un sistema. Por ejemplo existen motores de ejecuci´n sobre plataforma web as´ como tambi´n para o ı e aplicaciones de escritorio. Las herramientas de ejecuci´n pueden ser para o uso general, como espec´ ıficas de un producto particular. Este es el caso de las aplicaciones que se construyen con la intenci´n de que sean testeables o de forma autom´tica, y con este fin se provee de herramientas y procea dimientos auxiliares que permiten una interacci´n desatendida que puede o ser invocada desde un c´digo program´tico. o a Organizaci´n del testware: es la forma en que se va a organizar el software o de automatizaci´n generado. En qu´ lugar va el c´digo de la ejecuci´n, de o e o o d´nde se toman los resultados esperados y en d´nde y c´mo se dejan los o o o resultados de las ejecuciones de pruebas. Implementaci´n de Prueba Automatizada o Esta etapa tiene un gran componente t´cnico. El tester automatizador con apoyo e del resto del equipo comenzar´ las actividades de construcci´n de las pruebas a o
  • ´ 4.5. FIT MODULO III 119 automatizadas. Identificador IPS VFS Nombre de la Actividad Implementaci´n de Scripts o Verificaci´n de Scripts o ¿Es requerida? SI SI Cuadro 4.16: Etapa Implementaci´n de Pruebas Automatizadas o IPS* - Implementaci´n o de Scripts VFS* - Verificaci´n de Scripts o Figura 4.18: Etapa Implementaci´n de Prueba Automatizada o Roles involucrados en la etapa Tester Automatizador: genera el c´digo de las pruebas automatizadas en o el conjunto de herramientas seleccionadas, siguiendo la especificaci´n dada o en el dise˜o de las pruebas automatizadas. Es positivo que pueda contar n con el apoyo del tester funcional para definir temas relativos a las pruebas, y con la con la colaboraci´n de integrantes del equipo de desarrollo para o apoyar en la parte t´cnica de implementaci´n. e o Productos de trabajo involucrados en la etapa Documento de Dise˜o de Pruebas Automatizadas: es utilizado por el n Tester Automatizador como gu´ sobre cu´les son las pruebas que debe ıa a implementar. Puede ser un documento simple, que contenga una lista de las pruebas deseables, hasta uno que especifique incluso una prioridad u orden de implementaci´n. o
  • 120 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Implementaci´n de Scripts: en la actividad de implementaci´n, se o o construyen los scripts de la prueba en el lenguaje de la herramienta de automatizaci´n seleccionada o en el lenguaje de desarrollo correspondiente. Las o principales tareas para el desarrollo de scripts: Generar Esqueleto de Script: consta del uso de una herramienta de grabaci´n que capture los gestos efectuados en un producto y que sea capaz o de traducirlo a un lenguaje de programaci´n de scripts. Las herramientas o com´nmente cuentan con esta funcionalidad, conocida en la jerga como u ”Rec And Play”, o grabar y ejecutar. Otra de las formas de generar un esqueleto, es a trav´s de la reutilizaci´n de scripts, o partes de scripts que e o ataquen problemas similares. Depuraci´n de Scripts: luego degenerado el esqueleto de un script, es o necesario ajustarlo para sacar el mejor provecho. El objetivo es efectuar el mantenimiento necesario para que el esqueleto se ajuste al nuevo contexto de uso. Los scripts generados por las herramientas de grabaci´n son un o volcado de la ejecuci´n de acciones sobre el software. Por lo tanto es o importante identificar los lugares donde se manifiestan las entradas y salidas del sistema, identificando las variables, datos, valores constantes; para conseguir un script parametrizado, y que se integre correctamente con el resto del conjunto de elementos de la prueba automatizada. Por ejemplo, el script resultante podr´ luego ser ejecutado para varios datos diferentes, ıa accediendo una fuente de datos externa, aprovechando las ventajas de lo que se conoce com´nmente como Data-Driven Scripts 15 . u Programaci´n de Scripts: implementaci´n de las pruebas, partiendo o o de scripts base grabados, o desde un script vac´ Esta es una actividad ıo. plena de desarrollo. Se supone que los temas de testing est´n en su a mayor´ resueltos. Eventualmente esta tarea podr´ ser ejecutada por un ıa ıa desarrollador, si estuviese completamente especificada. El rol del tester automatizador, que se describe en la secci´n 4.5.2 tiene un valor agregado, o ya que podr´ tomar decisiones relativas al testing y hacer ajustes al a enfoque, lo cual, no estar´ a cargo de un desarrollador. ıa Verificaci´n de Scripts: las pruebas automatizadas son en definitiva o software. Por lo tanto, deben ser verificadas. El enfoque para verificar los scripts es variado, y aplican las t´cnicas de pruebas unitarias y de integraci´n16 como las e o que ejecutan los desarrolladores a sus m´dulos. El comportamiento esperado de o 15 Data-Driven Scripts se podr´ traducir como “pruebas automatizadas orientadas a ıa datos”. [FG99h] 16 Seg´ n [IEE91], testing unitario es el testing individual de unidades de hardware o software, u o grupos de unidades relacionadas. Una unidad es un elemento separable que puede ser verificado. Suelen ser m´dulos o piezas de software relacionadas. El test de integraci´n o o es el testing de la combinaci´n de diferentes componentes, tanto software como hardware, o para evaluar y verificar c´mo interact´an. Ver en el documento referenciado “unit testing”, o u “integration testing” y “unit”.
  • ´ 4.5. FIT MODULO III 121 un script, o conjunto de scripts, es que ejecute y no falle, a menos que encuentre un incidente. Como veremos m´s adelante, los scripts son muy sensibles a los a cambios en la aplicaci´n y en los datos, por lo tanto en las tareas de construcci´n o o y mantenimiento, es necesario correr varias veces los scripts para asegurarnos de que estos no nos traen falsos positivos, es decir, fallan por otros factores que no sean bugs o errores en el producto. Ejecuci´n de Pruebas Automatizadas o Esta es la etapa donde se ejecutan las pruebas automatizadas. La ejecuci´n de o las pruebas debe planificarse, dado que no siempre es conveniente correr todo el conjunto de pruebas automatizado. Los resultados de las pruebas tienen que ser recolectados y analizados, para ser debidamente informados. La etapa de ejecuci´n de pruebas es un punto cr´ o ıtico del proceso, dado que su resultado es fuente de informaci´n para otras etapas y actividades, por ejemplo, la ejecuci´n o o puede revelar nuevos incidentes, as´ como tambi´n la necesidad de que las prueı e bas mismas necesiten mantenimiento. PEA - Planificaci´n o de la Ejecuci´n o RRP* - Recopilar Resultados de las Pruebas IRA* - Informar Resultados de Pruebas Automatizadas Figura 4.19: Etapa Ejecuci´n de Pruebas Automatizadas o Roles involucrados en la etapa Tester Profesional, Tester Funcional L´der: planifican y ejecutan las ı pruebas automatizadas. Luego deben analizar la informaci´n. Los testers o no automatizadores deben ser capaces de correr las pruebas, por eso deben trabajar en colaboraci´n de quien las implement´. Analizan la o o informaci´n de los resultados de las pruebas, lo que puede modificar o reporte de incidentes, consultas o ajustes a las pruebas. Tester Automatizador: asiste en la obtenci´n de los resultados de las o
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 122 pruebas para su correcto an´lisis. Colabora en la ejecuci´n de las pruebas a o con el resto del equipo de testing. Productos de trabajo involucrados en la etapa Documento de Resultados de Automatizaci´n: contiene las conclusiones o obtenidas del an´lisis de los resultados de las pruebas. Puede contener a los incidentes encontrados, la cantidad de pruebas ejecutadas, las funcionalidades cubiertas, el tiempo que demora la ejecuci´n de las o pruebas, comentarios acerca de la mantenibilidad, entre otros. Identificador PEA RRP IRA Nombre de la Actividad Planificaci´n de la Ejecuci´n o o Recopilar Resultados de las Pruebas Informar Resultados de las Pruebas Automatizadas ¿Es requerida? SI SI SI Cuadro 4.17: Etapa Ejecuci´n de Pruebas Automatizadas o Planificaci´n de la Ejecuci´n: acarrea la decisi´n de cu´les pruebas se van o o o a ejecutar, y en qu´ momento. Por ejemplo una estrategia puede ser ejecutar e las pruebas del n´cleo del producto tras las liberaciones diarias, y ejecutar u pruebas anexas en ciertos momentos y a demanda, involucrando el resto de las funcionalidades. As´ como tambi´n priorizar y planificar las pruebas m´s ı e a costosas en tiempo y recursos. La actividad involucra el posible agendado de la ejecuci´n, por ejemplo, que corran durante la noche las pruebas m´s costosas o a en tiempo y proceso. Recopilar Resultados de las Pruebas: en esta actividad se consultan los resultados de las pruebas automatizadas y las posibles trazas almacenadas. La informaci´n puede estar en bases de datos, archivos de logs y puede ser generadas o por los motores de ejecuci´n de pruebas, o monitores instalados en diferentes o partes del sistema (m´s com´n en pruebas relacionadas con mediciones de a u rendimiento). El caudal de datos obtenido se procesa convenientemente para su posterior manejo y estudio. Informar Resultados de las Pruebas Automatizadas: generamos en esta actividad un Documento de Resultados de Automatizaci´n. El documento es o un resumen de lo acontecido en la ejecuci´n de la automatizaci´n de pruebas. o o Esta es una herramienta importante para identificar errores en el producto, o en las mismas pruebas automatizadas. La construcci´n y detalle de este o
  • ´ 4.5. FIT MODULO III 123 informe ser´ acorde a las necesidades del producto. Por ejemplo, si las pruebas a automatizadas intentan verificar que el producto no ha sufrido una regresi´n en o su calidad, antes de una liberaci´n, es importante detallar qu´ puntos fallaron o e o no, y qu´ pruebas han podido ser ejecutadas. Si las pruebas son referentes a e aspectos de rendimiento, es com´n que este material sea enriquecido con gr´ficas u a y an´lisis de los datos, con el fin de acotar los posibles errores encontrados. a An´lisis de Errores Detectados a Esta etapa no est´ subdividida en actividades. Consiste en la revisi´n de los a o resultados de las pruebas con el fin de identificar si han encontrado errores o los scripts requieren ajustes. La automatizaci´n no es capaz de discernir entre o estas posibilidades, por lo cual requiere de la intervenci´n humana. o Puede suceder que el volumen de casos de pruebas que fallan sea muy grande, en ese caso, conviene evaluar cuidadosamente c´mo invertir el tiempo en o analizarlos. Una estrategia posible puede ser tomar un n´cleo representativo u de los casos de prueba que fallan y tratar de identificar el motivo, para luego de reparados esos incidentes, volver a ejecutar las pruebas automatizadas. Aunque las pruebas sean automatizadas, pueden requerir muchos recursos para su ejecuci´n repetitiva y demorar en completar su ejecuci´n, por lo tanto, es o o importante revisar con cuidado c´mo se invertir´ el esfuerzo de an´lisis y reo a a ejecuci´n de pruebas. o Escenarios de falla de casos de prueba Al analizar los resultados de la ejecuci´n pueden darse los siguientes casos: o El caso de prueba fue exitoso: no falla la ejecuci´n de la prueba o automatizada. En este escenario sabemos que el software no presenta incidentes para el escenario ejercitado por el caso de prueba. El caso de prueba fall´: o • Por causa de errores en el producto: el producto presenta una regresi´n, y se registran los incidentes asociados. En una nueva o versi´n se volver´ a correr la prueba automatizada para verificar que o a el caso de prueba se ejecute exitosamente. • Por motivo de errores en las pruebas automatizadas: El producto tiene el comportamiento correcto y se deben ajustar las pruebas. En este punto es donde aplican las tareas de mantenimiento de las pruebas. Los motivos por los cuales puede suceder esto es porque el producto cambi´ su especificaci´n y la prueba automatizada o o no refleja este cambio, o porque los datos utilizados por las pruebas no se condicen con el estado actual de la aplicaci´n, o por un error o en las pruebas debido a mantenimientos err´neos. o
  • CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING 124 Mantenimiento de Testware de Automatizaci´n o La etapa de mantenimiento es transversal al resto de las etapas del Proceso de Testing Automatizado. No es necesaria ejecutarla rigurosamente, pero en ciertos contextos se vuelve imprescindible y permanente. Es com´ n que el manteniu miento sea necesario en proyectos donde las pruebas automatizadas se ejecuten repetidamente. Suele suceder que cambios en el producto impactan en los test automatizados implicando que estos fallen, no por la presencia de bugs, sino porque no est´n acordes a los cambios; o que cambios en el proyecto motiven el a ajuste de diferentes elementos del testware de automatizaci´n o su arquitectura. o Identificador REC ATA EAM Nombre de la Actividad Revisar Etapa de Automatizaci´n en Curso o Ajuste de Testware de Automatizaci´n o Elaborar Informe de Ajuste de Mantenimiento ¿Es requerida? NO SI NO Cuadro 4.18: Etapa Mantenimiento de Testware de Automatizaci´n o REC - Revisar Etapa de Automatizaci´n en Curso o ATA* - Ajuste de Testware de Automatizaci´n o EAM - Elaborar Informe de Ajuste de Mantenimiento Figura 4.20: Etapa Mantenimiento de Testware de Automatizaci´n o
  • ´ 4.5. FIT MODULO III 125 Roles involucrados en la etapa Tester Profesional, Tester Funcional L´der: identifican las fallas en las ı pruebas y si su procedencia es relativa a un incidente o a un ajuste necesario en la implementaci´n de la automatizaci´n. Le indican al Tester o o Automatizador el conjunto de pruebas que necesitan mantenimiento. Tester Automatizador: implementa los ajustes necesarios para que las pruebas que deben ejecutarse puedan correr. Completa el Documento de Mantenimiento de Automatizaci´n para registrar los cambios. o Productos de trabajo involucrados en la etapa Documento de Mantenimiento de Automatizaci´n: detalla qu´ pruebas o e sufrieron cambios y por qu´ motivo; por ejemplo por ser obsoletas, por e contener errores ante una nueva realidad o por no ser ejecutables debido a un incidente presente. Revisar Etapa de Automatizaci´n en Curso: consiste en identificar la o etapa en curso y extraer sus particularidades para decidir cu´les son las tareas a de mantenimiento correspondientes. En la etapa de dise˜o de la automatizaci´n, n o el mantenimiento es enfocado a los documentos. En etapas pr´ximas a la o implementaci´n y la ejecuci´n de las pruebas, se trata del ajuste de los scripts o o y archivos espec´ ıficos del desarrollo. Los scripts de automatizaci´n de pruebas o suelen ser muy sensibles aciertos cambios del producto, el entorno de los datos y la estabilidad general del sistema. El trabajo de mantenimiento es menor si se dedica esfuerzo relativo a planificar c´mo ser´n mantenidos los scripts en o a el momento del dise˜o y la implementaci´n de las pruebas, como se menciona n o en la secci´n 4.5.1. Los factores que da˜an la mantenibilidad, son similares o n a los que amenazan a los m´dulos de desarrollo. Ciertos aspectos dificultan las o tareas de mantenimiento, como ser por ejemplo, un sistema inestable, un entorno de ambiente cambiante, cambios importantes en requerimientos y definiciones, entre otros. Ajuste de Testware de Automatizaci´n: es la actividad de impactar o los cambios necesarios a los elementos involucrados en cada etapa. Puede corresponder a ajustar documentos de dise˜o, archivos de scripts, e incluso n puede ser necesario hace una re-ingenier´ de la arquitectura de la soluci´n ıa o de automatizaci´n, aunque es la situaci´n menos deseada. o o Elaborar Informe de Ajustes de Mantenimiento: esta actividad se trata de documentar los cambios, para contar con un registro de mantenimiento. La existencia de buena informaci´n de los ajustes facilita las probables futuras o tareas de mantenimiento. El registro de mantenimiento suele contener la fecha y el responsable del cambio, la etapa involucrada y los elementos afectados.
  • 126 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING Informar Resultados Esta etapa no tiene diferencia con la del m´dulo anterior en sus actividades. o Difiere solamente en qu´ tipo de informaci´n es extra´ acorde a las actividades e o ıda de automatizaci´n. V´anse en la secci´n 4.4.1 las actividades que involucra esta o e o etapa. 4.5.2. Roles Como se describe en la secci´n 4.4.2, un rol consta de un nombre y una o descripci´n de las funciones que desempe˜a la persona que lo asume. o n Tester Automatizador A los roles del nivel anterior, se incorpora la figura del Tester Automatizador. Hasta esta incorporaci´n, tienen lugar las etapas de testing funcional manual, o luego se requiere un conjunto de habilidades t´cnicas diferentes para automatie zar, m´s vinculadas con desarrollo de software. Es importante que la persona en a este rol colabore con el resto del equipo de testers en la definici´n de los casos o de prueba, y que estos colaboren en la selecci´n, as´ como tambi´n tenga buena o ı e comunicaci´n con el equipo de desarrollo quienes le ser´n de mucha ayuda para o a sortear posibles inconvenientes t´cnicos a la hora de automatizar. e 4.6. Relevancia y profundidad de la documentaci´n o Con el fin de registrar lo ocurrido en las diferentes actividades, se elaboran documentos para apoyar las tareas, brindar informaci´n y facilitar el seguimiento o y control de las diferentes actividades y etapas. La relevancia y la necesidad de construcci´n de un documento debe evaluarse seg´n las caracter´ o u ısticas del proyecto. No construir ni mantener un documento, puede permitir invertir tiempo en otras actividades, pero va en dem´rito de las actividades de seguimiento y e de eventuales revisiones posteriores, como apoyo a futuros proyectos o cambios dentro del proyecto actual. Determinados proyectos pueden no requerir estrictamente contar con un documento particular, e incluso puede configurarse como un obst´culo al desarrollo del proyecto. a Algunos documentos pueden ser presentados en versiones resumidas, o con menos formalidad, por ejemplo omitir secciones que apuntan a que el documento se presente y explique a s´ mismo, como ser la introducci´n y prop´sito, yendo ı o o directamente al punto central. Parte importante de la flexibilidad de la propuesta metodol´gica se basa en o saber qu´ documentos aportan al desarrollo del proceso de testing. A la hora de e elaborar un documento, se eval´a primero qui´n lo solicita, cu´l es su aporte, u e a
  • 4.7. RESUMEN 127 y qu´ esfuerzo requiere su construcci´n para diferentes niveles de rigurosidad. e o Un documento no requerido por la organizaci´n, que insume mucho tiempo en o formalismos y que adem´s rara vez ser´ consultado; es un firme candidato a ser a a descartada su mantenimiento o incluso elaboraci´n. o 4.7. Resumen Con la intenci´n de generar un marco de trabajo adaptable a las necesidades o de ASSE, se elabora una propuesta metodol´gica organizada en m´dulos, cuyo o o nombre es “Framework Instanciable de Testing”. Se definen tres m´dulos. Un o m´dulo inicial se utilizar´ como punto de partida identificando el estado de la o a organizaci´n, un m´dulo que contiene un proceso de testing funcional manual o o y otro m´dulo que est´ compuesto por un proceso de testing funcional manual o a automatizado. Cada proceso cuenta con etapas, y las etapas con actividades. La metodolog´ debe ser personalizada para cada contexto de uso, siendo posible ıa seleccionar qu´ etapas y actividades transitar (dentro de cierto espectro) y en e qu´ profundidad. A la configuraci´n de etapas y actividades para un proyecto e o particular, se le da el nombre de “roadmap”.
  • 128 CAP´ ITULO 4. FRAMEWORK INSTANCIABLE DE TESTING
  • Cap´ ıtulo 5 Proyecto piloto “Son vanas y est´n plagadas de errores las ciencias que no han a nacido del experimento, madre de toda certidumbre.” Leonardo da Vinci 5.1. Introducci´n o Una de las primeras actividades del proyecto de grado, fue la identificaci´n de o las realidades de la organizaci´n en cuanto al testing y desarrollo de sistemas o inform´ticos. Con esta informaci´n como situaci´n inicial, se investiga y doa o o cumenta el estado del arte en testing funcional. Se construye luego un marco de trabajo, suficientemente flexible, cuya intenci´n es cubrir lo m´ximo posible o a de las diferentes realidades de los proyectos de ASSE. La etapa posterior, es poner en pr´ctica la forma de trabajo en proyectos reales de la organizaci´n, a o observando el proceso y extrayendo conclusiones. En este capitulo se presenta esta ultima etapa, mostrando la experiencia y los resultados del trabajo de campo. ´ Uno de los puntos relevantes del proyecto de grado es la implantaci´n de herrao mientas que permitan asistir al testing, logrando enfocar las pruebas manuales a puntos donde es necesaria m´s actividad cognitiva. a 5.2. Descripci´n de la Metodolog´ adoptada o ıa El marco de metodol´gico propuesto organiza el trabajo en tres m´dulos o o principales. El primer m´dulo corresponde a la identificaci´n inicial de las o o particularidades del proyecto y la forma de trabajo, rescatando fortalezas e identificando debilidades con respecto al testing funcional y elementos relacionados. La etapa inicial se nutre de un an´lisis al estilo que se presenta a 129
  • 130 CAP´ ITULO 5. PROYECTO PILOTO en el capitulo 3, siendo este un ejercicio de informe de an´lisis y diagn´stico a o inicial para la situaci´n de ASSE. Los m´dulos II y III contienen definiciones o o del proceso de testing funcional manual y testing funcional automatizado, respectivamente. Cada proceso cuenta con sus etapas y actividades, que aplicar´n a cada proyecto particular. Decimos que el marco de trabajo es a instanciable, ya que es posible seleccionar para un proyecto espec´ ıfico, qu´ etapas e y actividades se transitan de cada proceso propuesto en la metodolog´ y la ıa rigurosidad con que se van a ejecutar.
  • 5.3. PROPUESTA DE PROYECTO PILOTO 5.3. 131 Propuesta de proyecto piloto Como parte del proyecto de grado, es importante aplicar la metodolog´ en un ıa contexto de uso real. Con tal motivo, se han investigado tres posibles sistemas de ASSE, candidatos a participar en el proyecto piloto. Estos son Escritorio Cl´nico, OpenSIH y M´dico de Referencia. En el cuadro 5.1 se describen las ı e caracter´ ısticas percibidas de cada producto en el an´lisis de la informaci´n oba o tenida. La intenci´n del proyecto piloto, es que sea una experiencia aislada (dentro de o lo posible) de la forma de trabajo actual de ASSE, para que de esta manera, sea pueda evaluar su funcionamiento y viabilidad. Por este motivo, es preferible que el proyecto piloto no est´ bajo condiciones reales de criticidad, presi´n o riesgo. e o Para que el proyecto piloto tenga ´xito, fue necesario contar con el apoyo y e consentimiento de la direcci´n, dado que insumimos recursos materiales y sobre o todo trabajo de personas que han colaborado para poder llevar adelante la experiencia exitosamente. 5.4. Proyectos Candidatos Luego de analizar comparativamente los proyectos (v´ase el cuadro 5.1), el softe ware que mejor cumple con las caracter´ ısticas necesarias para un proyecto piloto es OpenSIH, dado que es un sistema estable de mediano porte, que no cuenta con una alta tasa de liberaciones y se puede automatizar a trav´s de la construcci´n e o de un framework de herramientas libres. De los restantes sistemas, se elige Escritorio Cl´ ınico, lo cual nos brinda la oportunidad de atacar un sistema de mediano porte, con una funcionalidad compleja, implementado en GeneXus1 , usando la herramienta GXtest2 (ver an´lisis de la conveniencia del uso de GXtest en este a tipo de escenarios en la secci´n 5.8). El tama˜o de los formularios de ingresos o n es similar al de OpenSIH pero la aplicaci´n cuenta con un bajo nivel de docuo mentaci´n, lo que pone a prueba la adaptabilidad de la propuesta metodol´gica. o o La experiencia simula una reestructura del ´rea de Testing y por lo tanto es a necesario contar con el apoyo de la direcci´n, para que asigne recursos y declare o al proyecto como “de inter´s” para lograr sortear posibles dificultades externas. e 1 GeneXus es un generador de c´digo muy popular de la empresa uruguaya Artech, para o m´s informaci´n www.Genexus.com a o 2 GXtest es una herramienta de gesti´n y automatizaci´n de pruebas funcionales para o o aplicaciones web desarrolladas en GeneXus. Pertenece a la empresa uruguaya Abstracta, por m´s informaci´n, visitar http://www.abstracta.com.uy/es/gxtest-overview-testing-toola o GeneXus.html, accedido por ultima vez en mayo de 2011. ´
  • CAP´ ITULO 5. PROYECTO PILOTO 132 Porte del Software Nivel de Documentaci´n o Estabilidad de las funcionalidades Tama˜o de los Formulan rios Frecuencia de Cambios Plataforma de Desarrollo Herramienta de automatizaci´n o Escritorio Cl´ ınico Mediano Bajo Peque˜o n Alto M´dico de e Referencia Peque˜ o n Alto Media Alta Alta Entre 50 y 100 campos Alta GeneXus 9.0 - Java sobre MySQL Entre 50 y 100 campos Moderada Java - Ajax - JBOSS con MySQL Selenium Webdriver Entre 5 y 20 campos Moderada GeneXus 9.0 - Java sobre Oracle GXtest OpenSIH GXtest Cuadro 5.1: Sistemas candidatos a incluirse en el Proyecto Piloto. Algunos datos complementarios: Escritorio Cl´ ınico: tiene una alta frecuencia de cambios3 y liberaciones a producci´n. Es com´n que se solicite el testing del producto para su o u liberaci´n inmediata, en el mismo d´ que termina el desarrollo. o ıa Comentarios sobre OpenSIH: es un sistema estable y en desarrollo. Cuenta con una moderada frecuencia de cambios4 y est´ siendo instalado a en todos los CTI de ASSE. M´dico de Referencia: para cada usuario del sistema de salud, se define e el m´dico de referencia, qui´n puede acceder a la historia cl´ e e ınica. Contiene un Web Service M´dico de Referencia. e Al inicio del proyecto piloto en ASSE, Fernando Pereira y Carlos Gutierrez tienen en curso una automatizaci´n de pruebas sobre los WebServices Personas y o Autenticaci´n LDAP. En este punto se brind´ apoyo en dise˜ o de pruebas para o o n completar la cobertura de la prueba en curso, y adem´s ensayar la aplicaci´n a o de t´cnicas de dise˜o de pruebas para un caso pr´ctico. e n a 3 Una frecuencia de cambios Alta implica que en la forma de trabajo actual es dificultoso aplicar un proceso de testing riguroso 4 Una frecuencia de cambios Moderada, deja espacio para estimar esfuerzo y completar las etapas requeridas en un proyecto de testing
  • 5.5. PROCESO DE TESTING APLICADO A ESCRITORIO CL´ INICO 133 5.5. Proceso de Testing aplicado a Escritorio Cl´ ınico En esta secci´n se describen particularidades del sistema Escritorio cl´ o ınico y el resultado de aplicar la propuesta metodol´gicas. o 5.5.1. Introducci´n a la aplicaci´n o o Escritorio Cl´ ınico se trata de una aplicaci´n Web desarrollada en GeneXus. Se o compone de varios m´dulos, uno de ellos es la consulta de agenda, donde un o usuario del servicio de salud tiene agendado (mediante otro sistema, el SGA) una cita con un m´dico. e El usuario del sistema es un m´dico que atiende consultas en determinado cene tro de salud. Ingresa con un nombre de usuario y va a la funcionalidad consulta de agenda, donde podr´ informarse de los pacientes que tiene para atender en a el d´ Adem´s, puede ingresar a chequear la informaci´n de cada uno de esos ıa. a o pacientes. Los pacientes se clasifican como ni˜o, adolescente y adulto. Para cada uno de n estos, al entrar a ver la informaci´n, el sistema muestra un men´ con diferentes o u opciones. 5.5.2. Tipo de aplicaci´n o Arquitectura y acceso a datos Es una aplicaci´n web desarrollada en GeneXus generando para Java, que o utiliza una base de datos MySQL5 . La base de datos de Escritorio Cl´ ınico est´ centralizada en ASSE. a Complejidad del dominio El dominio del sistema es complejo y la soluci´n desarrollada lo refleja. Involucra o manejo de historias cl´ ınicas, informaci´n que es muy sensible y a la vez o perteneciente a un contexto complejo, partiendo por ejemplo, desde la dificultad del vocabulario manejado. 5.5.3. Contexto de desarrollo 5 Es un manejador de base datos opensource muy popular, para m´s informaci´n se puede a o consultar documentaci´n en http://dev.mysql.com/doc/ o
  • 134 CAP´ ITULO 5. PROYECTO PILOTO Estado de la aplicaci´n o Si bien el producto es estable y se puede testear, se percibe una alta tasa de errores y oportunidades de mejora. Por ejemplo, un inconveniente de usabilidad recurrente es que todas las consultas cargan datos patron´ ımicos (datos que definen al paciente), y es necesario ingresarlos manualmente en cada consulta, es decir, no se contextualizan los datos a lo largo de un flujo funcional. No es claro qu´ tan estable se mantendr´ el sistema en cuestiones de dise˜ o de e a n la interfaz gr´fica, dado que para el tipo de paciente “ni˜ o”, los formularios se a n muestran de una forma y para “adultos” y “adolescentes” se muestran de otra. Es de suponer por lo tanto que sufrir´n cambios; lo cu´l tiene impacto directo a a en la automatizaci´n y puede elevar el costo de mantenimiento al punto de la o re-implementaci´n de los casos de prueba, incluso usando una herramienta efio ciente como GXtest (por contar con un manejo particular de las pruebas, que favorece el mantenimiento en aplicaciones generadas con GeneXus). Estado de los datos Para el testing del sistema, se trabaja regularmente sobre el mismo conjunto de datos y los que son estables en el ambiente de pruebas. En producci´n, los datos o no est´n sincronizados con la base de persona (datos del paciente, a trav´s del a e Web Service “persona”), debido a que la calidad de los datos no es confiable y esta informaci´n causa muchos errores en la aplicaci´n. Los datos son extra´ o o ıdos la primera vez que se da de alta una consulta para un paciente y luego se trabaja con la base de datos centralizada de Escritorio Cl´ ınico. Disponibilidad de apoyo de desarrollo La interacci´n con los desarrolladores es directa y muy buena. El equipo o est´ instalado en la instituci´n y se muestra sumamente colaborativo. Se ha a o consultado a los desarrolladores por temas t´cnicos y algunos detalles del e dominio, logrando colaboraci´n inmediata. o
  • 5.5. PROCESO DE TESTING APLICADO A ESCRITORIO CL´ INICO 135 5.5.4. Proceso de testing Estrategia adoptada En este proyecto se ha adoptado por una estrategia h´ ıbrida de testing exploratorio y testing planificado para el testing manual, y pruebas automatizadas para apoyar las pruebas de regresi´n. o Se emplea testing planificado para verificar la informaci´n obtenida en el panel o Programa del Adulto, el cual se accede desde el men´ Paciente, luego Consulta u Espontanea del Paciente e ingresando la c´dula del paciente. Otra opci´n pae o ra acceder es desde el men´ Paciente, luego Ver Agenda del T´cnico, elegir la u e agenda del d´ y luego seleccionar el paciente; esta ultima opci´n involucra una ıa ´ o carga previa de datos en otro sistema (SGA) para lograr visualizar el paciente en la agenda. La forma de llegar al panel Programa del Adulto a trav´s de Consulta Espontae nea del Paciente es m´s recomendable para las tareas de automatizaci´n, dado a o que no hay interacci´n con otro sistema. o La documentaci´n generada tiende a ser la m´ o ınima imprescindible suponiendo un contexto ´gil y orientado a resultados, en el cual la informaci´n auditable no a o es la prioridad; de los documentos se genera solamente los necesarios, haciendo hincapi´ en el el punto central. e Herramientas definidas La automatizaci´n ser´ llevada a cabo con la herramienta GXtest, para evao a luar su desempe˜o para sistemas de este tipo en el contexto de la organizaci´n. n o GXtest permite grabar una ejecuci´n y generar un modelo gr´fico sobre el cual o a se ejecutar´n los casos de pruebas. Tambi´n resuelve temas de planificaci´n de a e o ejecuci´n de pruebas y mantenimiento (ver en la secci´n 5.8). o o Complejidad del testing funcional Desde el punto de vista de la verificaci´n, el sistema es testeable (ver testeabio lidad en la secci´n 2.6), al contar con muchos lugares de los cuales el testing o se puede servir, dado que existen herramientas construidas y utilizadas por los propios desarrolladores para sus pruebas y depuraci´n. o La funcionalidad de Alta de Agenda del paciente se hace a trav´s del sistema e SGA, lo que implica la interacci´n con un sistema externo para crear los esceo narios de testing relacionados.
  • CAP´ ITULO 5. PROYECTO PILOTO 136 En cuanto a las pruebas, se dise˜an casos de prueba para un formulario complejo n (de los que cambian su interfaz seg´n el tipo del paciente) y se automatiza un u subconjunto de los casos. Complejidad de automatizaci´n o El formulario de ingreso est´ subdivido en bloques que agrupan campos con una a l´gica de relaci´n entre los datos. Por ejemplo, Datos Patron´micos y Anteceo o ı dentes Socioecon´micos del Usuario. Esto facilita la divisi´n l´gica del dise˜ o o o o n de las pruebas y su posterior automatizaci´n, siendo posible atacar dise˜ o, auo n tomatizaci´n y ejecuci´n de pruebas de manera incremental; comenzando por o o los datos patron´ ımicos y luego el resto. Esta estrategia permite que en cada momento se pueda enfocar en un grupo de campos en particular y favorece la modularizaci´n tanto del dise˜ o de las o n pruebas manuales c´mo de la implementaci´n de los casos automatizados. o o Para la automatizaci´n, se dividen los casos seg´n la agrupaci´n l´gica de los o u o o campos, logrando casos gen´ricos y modulares, que permiten ingresar informae ci´n a los bloques de forma independiente, permitiendo as´ ejecutar pruebas o ı para los bloques en conjunto o por separado, siempre teniendo en cuenta las pre-condiciones que pueden tener cada caso, como ser el ingreso de los datos obligatorios. Un ejemplo de caso de prueba de un formulario completo: Ejecuta un caso de prueba de ingreso de Datos Obligatorios Ejecuta un caso de prueba del Bloque Patron´ ımico Ejecuta un caso de prueba del Bloque Socioecon´mico o Recursos de Testing El proyecto es llevado adelante trabajando con la colaboraci´n de Carlos Gutieo rrez, integrante del ´rea de testing de ASSE, quien contaba con conocimiento a del sistema, y adem´s mostr´ inter´s en el uso de la herramienta GXtest. a o e Al finalizar las etapas de testing manual, a´n no se contaba con la licencia de u la herramienta GXtest, por temas administrativos ajenos al proyecto de grado, lo que dificult´ el desarrollo del proceso. Finalmente se obtuvo la licencia para o poder utilizar la herramienta y continuar la experiencia. Se genera para el proyecto, la documentaci´n necesaria para apoyar el proceso o en el supuesto del contexto ´gil ya mencionado. a
  • 5.6. PROCESO DE TESTING APLICADO A OPENSIH 5.5.5. 137 Conclusiones La experiencia de trabajo en conjunto con Carlos Gutierrez y el grupo de desarrollo aplicando la metodolog´ propuesta es muy positiva. El proceso de testing ıa pudo ser aplicado, y se logr´ automatizar pruebas mediante el uso de GXtest. o Las tareas de an´lisis, dise˜o y planificaci´n insumen la mayor parte del tiempo. a n o El desarrollo de las pruebas automatizadas se hace r´pidamente con la herraa mienta GXtest. El equipo de desarrollo se integra a la herramienta de gesti´n propuesta para el o proyecto piloto, Redmine, que se configura para que modele las necesidades del proyecto, favoreciendo la interacci´n entre ambos equipos. o 5.6. Proceso de Testing aplicado a OpenSIH El marco de trabajo dise˜ado, tambi´n se aplica en otro sistema de ASSE, n e OpenSIH. Esta secci´n describe algunas caracter´ o ısticas de OpenSIH y las conclusiones extra´ ıdas acerca del uso de la propuesta metodol´gica. o 5.6.1. Introducci´n a la aplicaci´n o o El Sistema de Ingreso Hospitalario, OpenSIH, es una herramienta web para el ingreso de intervenciones quir´rgicas de las unidades ejecutoras por parte de u los m´dicos cirujanos, anestesistas y dem´s integrantes del equipo medico. Es e a de destacar que entre otras funcionalidades, se encarga del c´lculo del puntaje a VAC (variable anest´sico quir´rgico), lo que est´ directamente relacionado con e u a los honorarios del personal actuante, y por lo tanto es muy sensible a eventuales errores. La funcionalidad principal de OpenSIH es la de ingreso de la descripci´n de o la intervenci´n quir´rgica, la cual consta de un formulario extenso, implicando o u que cada caso de prueba ejecutado manualmente insume mucho tiempo. Por lo tanto, se invertir´ en automatizar casos de prueba de ingresos, dado que reprea sentan una buena relaci´n de costo y beneficio, frente a la ejecuci´n manual de o o pruebas de regresi´n. o Al explorar el sistema OpenSIH, se percibe como una herramienta estable y en condiciones de recibir pruebas de sistema 6 . 6 Se ensayan pruebas exploratorias en la versi´n 2.6, previamente instalada en un ambiente o de testing disponible en ASSE
  • CAP´ ITULO 5. PROYECTO PILOTO 138 5.6.2. Tipo de aplicaci´n o Arquitectura y acceso a datos Es una aplicaci´n web desarrollada en Java que utiliza AJAX, corriendo en un o servidor JBoss7 a la que se accede mediante un navegador, preferentemente Mozilla Firefox8 . Los datos se encuentran en una base de datos MySQL administrada por ASSE. Complejidad del dominio Si bien el dominio es complejo y la tarea de an´lisis de los desarrolladores fue a laboriosa, la soluci´n ataca una problem´tica compleja de manera muy elegante o a (la interfaz es intuitiva, y controla el ingreso de datos, se asiste con el ingreso de c´digos de diagn´sticos y procedimientos, entre otros). Resulta por lo tanto o o f´cil conocer el dominio del sistema a trav´s del uso de la herramienta y el a e conocimiento acumulado en los testers de ASSE. 5.6.3. Contexto de desarrollo Estado de la aplicaci´n o El sistema se somete a pruebas exploratorias para recorrer las funcionalidades y aprender del dominio. En la exploraci´n se percibe que la aplicaci´n es estable o o y se puede testear sin manifestar interrupciones del servicio. Estado de los datos El producto se comunica correctamente con las fuentes de datos, y el conjunto de datos con el que se trabaja es controlado y con referencias de uso por parte de los testers de ASSE. Adem´s, el sistema tiene validaciones al ingreso de los a datos, y asiste en la selecci´n de informaci´n al ingreso. o o Disponibilidad de apoyo de desarrollo Los integrantes del equipo de desarrollo de OpenSIH muestran actitud colaborativa y se encuentran f´ ısicamente en la instituci´n (y pertenecen a ella). o En esta etapa no fue necesario contar con su asistencia, dado que los temas t´cnicos program´ticos se pudieron resolver desde testing y las dudas del dominio e a fueron en su mayor´ resueltas o manejadas por Fernando Pereira. ıa 7 JBoss es un servidor de aplicaciones basado en Java, para m´s informaci´n se puede a o consultar http://www.jboss.org, accedido por ultima vez en setiembre de 2011 ´ 8 Mozilla Firefox es un navegador web opensource, para m´s informaci´n visitar a o http://www.mozilla.org, accedido por ultima vez en setiembre de 2011 ´
  • 5.6. PROCESO DE TESTING APLICADO A OPENSIH 5.6.4. 139 Proceso de testing Estrategia adoptada Para el testing de OpenSIH se emplea una estrategia mayoritariamente de testing planificado. Dado que se cuenta con una versi´n del producto instalada, o tambi´n se aplica testing exploratorio para conocer las funcionalidades b´sicas e a del sistema y su interacci´n con el usuario. Se generan los documentos de las o etapas abordadas a modo de ejercicio, para dejar constancia de la aplicaci´n o del proceso en la modalidad de proceso auditable. El objetivo principal es lograr automatizaci´n a modo de pruebas de regresi´n de la parte m´s costosa para el o o a testing manual, que es el ingreso de descripci´n operatoria. o Herramientas definidas Dada la naturaleza del proyecto se opta por herramientas en plataforma libre. El marco de trabajo es construido sobre herramientas gratuitas. Las herramientas definidas son Selenium Webdriver 9 como motor de interacci´n con la aplicaci´n o o web, Java como lenguaje de programaci´n y TestNG 10 como motor de ejecuci´n o o de pruebas automatizadas. Complejidad del testing funcional La herramienta cuenta b´sicamente con un gran formulario, intuitivo y de f´cil a a interacci´n. La complejidad fundamental radica en la gran extensi´n de campos o o a ingresar para cada alta de descripci´n operatoria. Consecuentemente cada o caso de prueba que involucre un ciclo funcional entero de ingreso de descripci´n o operatoria insume mucho tiempo, haciendo que el testing manual en s´ requiera ı una gran inversi´n en tiempo, consuma muchos recursos del ´rea de testing y o a se torne tedioso. Complejidad de automatizaci´n o La herramienta est´ desarrollada en plataforma web, por lo tanto es accesible a por la herramienta Selenium WebDriver. La presencia de AJAX11 dificulta levemente la automatizaci´n, pero la popularidad de las herramientas utilizadas o para el testing y la forma de implementaci´n de OpenSIH, facilita encontrar en o la web muchos ejemplos de soluciones a problemas de similares caracter´ ısticas. La complejidad mayor se basa en el dise˜o de un marco de trabajo para la auton matizaci´n, dado que se trabaja con un conjunto de herramientas libres que hay o 9 Selenium WebDriver es una herramienta para interactuar program´ticamente con a diferentes navegadores. En la web del proyecto http://seleniumhq.org/projects/webdriver/ se puede obtener m´s informaci´n. a o 10 TestNG es un framework http://testng.org/doc/index.html de planificaci´n y ejecuci´n de o o pruebas unitarias que puede ser utilizado como motor de ejecuci´n de pruebas automatizadas. o 11 La sigla AJAX significa JavaScript Asincr´nico y XML (Asynchronous JavaScript And o XML) y es una conjunto de t´cnicas de programaci´n para crear aplicaciones web interactivas. e o
  • 140 CAP´ ITULO 5. PROYECTO PILOTO que orquestar para que funcionen como una sola soluci´n de automatizaci´n de o o pruebas. Con este motivo se defini´: o 1. Obtenci´n de par´metros de configuraci´n de los tests en o a o archivos de propiedades: aqu´ se almacenan datos relativos al acceso ı a la aplicaci´n en el entorno actual, los cuales se comparten por muchos o tests y tienden a cambiar menos frecuentemente. 2. Aplicaci´n de patrones de automatizaci´n para favorecer la o o mantenibilidad de los tests: se basa en el uso del patr´n Page Object, o que a grandes rasgos recomienda el manejo de sectores de una web l´gicamente relacionados por medio de una clase cuyas propiedades y o m´todos modelan la interacci´n con los diferentes conceptos del sitio web, e o encapsulando as´ toda la l´gica de interacci´n con la web y favoreciendo ı o o las tareas de mantenimiento de los tests automatizados. 3. La forma de acceder a los datos almacenados en disco: se define una forma de acceder a archivos que se puedan acceder con las herramientas libres disponibles en la organizaci´n. Se incluye para este fin acceso a o archivos CSV12 para consumir datos en forma tabular. 4. Uso de proveedores de datos (data providers) para las pruebas: se implementa adem´s que los datos accedidos desde archivos (en a primera instancia CSV) puedan cargarse en memoria y se modele su uso mediante Data Types, y que estos datos sean suministrados a las pruebas automatizadas para implementar pruebas orientadas a datos, que significa poder utilizar una misma implementaci´n con un conjunto de datos, de o manera que una prueba automatizada pueda representar potencialmente una gran cantidad de casos de prueba. 5. Interacci´n entre herramienta de programaci´n, ejecuci´n web y o o o motor de testing: se define la forma en que los tests ser´n jerarquizados, a utilizando la herramienta TestNG como motor de ejecuci´n de pruebas o automatizadas integrado con Java13 como lenguaje de programaci´n, e o interactuando con la librer´ para Java de Selenium Webdriver, quien se ıa encarga de comunicarse con el navegador desde la interfaz de usuario. 12 CSV significa valores separados por coma (de comma separated values) es un formato de archivo simple para representar datos tabulados en texto plano, donde las filas se separan por saltos de l´ ınea y las columnas por coma o punto y coma. 13 Java es un lenguaje de programaci´n orientado a objetos de libre distribuci´n cuyo sitio o o oficial en espa˜ol es http://java.com/es n
  • 5.6. PROCESO DE TESTING APLICADO A OPENSIH 141 Recursos de Testing Se trabaj´ en conjunto con un integrante del equipo de estudiantes del proyecto o de grado y un integrante de ASSE. Se pudo avanzar r´pidamente en la definici´n a o de las pruebas y planificaci´n dado que Fernando Pereira cuenta con amplio coo nocimiento sobre el sistema a verificar. Se gener´ documentaci´n formal de todo el proceso aplicado. o o Luego de que estuvo el conjunto de herramientas orquestado, fue posible avanzar velozmente con la implementaci´n de la automatizaci´n, sorteando r´pidamente o o a los obst´culos. a 5.6.5. Conclusiones El trabajo conjunto aplicando los procesos de testing dio resultados muy positivos. Si bien se gener´ gran documentaci´n, no implic´ una sobrecarga extra de o o o trabajo, en parte porque el integrante de ASSE ten´ mucho conocimiento de la ıa aplicaci´n y en parte porque se pudo bajar a tierra r´pidamente siguiendo las o a actividades propuestas en el proceso. El proceso de automatizaci´n tambi´n fue seguido exitosamente, siendo las aco e tividades de construcci´n del framework de automatizaci´n y programaci´n de o o o las pruebas las que insumieron la mayor parte del tiempo. Se trabaj´ de forma o colaborativa, y se acumul´ mucho conocimiento acerca de las herramientas y o la forma de trabajo, luego utilizado para ajustar los procesos propuestos. Durante la automatizaci´n se impactaron nuevas versiones y se pudo actualizar o r´pidamente el conjunto de pruebas dado que la soluci´n de automatizaci´n fue a o o dise˜ada para que sea mantenible. n La gesti´n e interacci´n con los equipos de desarrollo se lleva a cabo en la herrao o mienta propuesta Redmine14 , la cual modela el sistema de gesti´n de incidentes, o de manera aislada a las existentes en la organizaci´n, con el fin de no alterar o el foco en la evaluaci´n de la forma de trabajo. Los desarrolladores se integran o paulatinamente al sistema, el cual es configurado para modelar las necesidades de todos los equipos y procesos involucrados. 14 Redmine es una herramienta web opensource para gesti´n y manejo de proyectos se puede o consultar el sitio http://www.redmine.org/ (accedido en ultima instancia en agosto de 2011) ´ para obtener m´s informaci´n. a o
  • CAP´ ITULO 5. PROYECTO PILOTO 142 5.7. Cuestionario para los Integrantes de ASSE Luego de la aplicaci´n pr´ctica en los proyectos piloto, se genera un breve cueso a tionario a los integrantes del ´rea de testing de ASSE, con el fin de conocer sus a impresiones acerca de la metodolog´ y el desarrollo de los proyectos piloto en ıa general. Esas recomendaciones han sido tomadas en cuenta para mejorar aspectos del presente informe. Las preguntas planteadas son las siguientes: 1. ¿La informaci´n de cada etapa/actividades del FIT permite llevar a cabo o su aplicaci´n? o 2. ¿Los casos de pruebas automatizados cubrieron el alcance estipulado? 3. ¿El framework de la programaci´n de pruebas automatizadas de aplicao ciones web no-GeneXus es util? ´ 4. ¿La documentaci´n generada en los proyectos piloto es de utilidad seg´ n o u el contexto? 5. ¿Se lograron los objetivos planteados para los proyectos piloto? 6. ¿La herramienta de colaboraci´n para la gesti´n de incidente es util? o o ´ 7. Sugerencias/Comentarios generales de la metodolog´ ıa. 5.7.1. Respuestas de Carlos Guti´rrez e Carlos Guti´rrez particip´ en la experiencia piloto sobre la aplicaci´n Escritorio e o o Cl´ ınico, aplicando la metodolog´ en conjunto con los estudiantes, utilizando ıa GXtest como herramienta de automatizaci´n de pruebas. A continuaci´n se o o presentas sus repuestas al cuestionario planteado. 1. ¿La informaci´n de cada etapa/actividades del FIT permite llevar a cabo o su aplicaci´n? o - S´, la permite llevar a cabo sin problemas ı 2. ¿Los casos de pruebas automatizados cubrieron el alcance estipulado? - En el caso de la aplicaci´n de Escritorio Cl´nico hubiese sido deseable o ı dedicar mas tiempo a la automatizaci´n con GXtest, pero dado que se o tuvieron problemas para la validaci´n de las licencias y por otra parte los o estudiantes no pod´an utilizarlo fuera de ASSE, no fue posible. De todas ı formas se aplicaron los criterios de automatizaci´n estipulados en lo que o se hizo, lo cual va a permitir automatizar con la herramienta sin problema en un futuro.
  • 5.7. CUESTIONARIO PARA LOS INTEGRANTES DE ASSE 143 3. ¿El framework de la programaci´n de pruebas automatizadas de aplicao ciones web no-Genexus es util? ´ - Si bien no era mi tema, en los momentos que ten´a problemas con ı la licencia de GXtest intent´ utlizarlo para la aplicaci´n de Escritorio e o Cl´nico y lo poco que pude probar me pareci´ muy util. Estaba muy ı o ´ bien modularizado, muy claro y f´cil de utilizar, sin dudas que en la a parte de automatizaci´n los logros por el lado de este framework fueron o mucho m´s utiles que los obtenidos con GXtest. Vale decir que GXtest a ´ ya lo conoc´amos, en cambio de Selenium ten´amos solamente alguna ı ı experiencia mas que nada con el uso del IDE, y no ten´amos ninguna ı experiencia con Webdriver. 4. ¿La documentaci´n generada en los proyectos piloto es de utilidad seg´ n o u el contexto? - La documentaci´n generada me parece lo mas util que ha dejado el o ´ proyecto. 5. ¿Se lograron los objetivos planteados para los proyectos piloto? - S´, se lograron los objetivos. ı 6. ¿La herramienta de colaboraci´n para la gesti´n de incidente es util? o o ´ ´ - Si, me pareci´ muy util y muy apropiada para el Area de Testing para o ´ una mejor documentaci´n de su trabajo y como forma de que el trabajo o del ´rea sea visible para los encargados y los involucrados. a 7. Sugerencias/Comentarios generales de la metodolog´ ıa. - Me hubiese gustado una mayor preparaci´n de los estudiantes en GXtest o para desarrollar el proyecto, se necesitaba un conocimiento similar al que si tienen en el framework para aplicaciones no GeneXus, pienso que es el gran debe del proyecto piloto. - Personalmente fue un gusto participar del proyecto de grado, en cuanto a metodolog´a de testing y del framework para aplicaciones no GeneXus ı aprend´ bastante y me fue de suma utilidad. ı 5.7.2. Respuestas de Fernando Pereira Fernando Pereira fue parte de la experiencia piloto sobre la aplicaci´n OpenSIH. o Utilizando la metodolog´ propuesta, se construye adem´s una plataforma ıa a basada en herramientas libres para la automatizaci´n de las pruebas. Las o siguientes, son las respuestas obtenidas para el cuestionario planteado. 1. ¿La informaci´n de cada etapa/actividades del FIT permite llevar a cabo o su aplicaci´n? o - S´. ı
  • CAP´ ITULO 5. PROYECTO PILOTO 144 2. ¿Los casos de pruebas automatizados cubrieron el alcance estipulado? - S´, totalmente en lo que respecta Java + Webdriver + Testng para no ı GeneXus. En cuanto a GXtest me gustar´a se tomara la opini´n de Carlos. ı o 3. ¿El framework de la programaci´n de pruebas automatizadas de aplicao ciones web no-Genexus es util? ´ - S´, ultimamente tambi´n por nuestra cuenta probamos grabar con ı ´ e Selenium IDE y ejecutarlas en Java haciendo uso de el framework. La grabaci´n de este modo permitir´a acelerar una aproximaci´n a la o ı o automatizaci´n por medio de usuarios no tan avanzados. o 4. ¿La documentaci´n generada en los proyectos piloto es de utilidad seg´ n o u el contexto? - S´, totalmente en lo que respecata Java+ Webdriver+ Testng para no ı GeneXus. En cuanto a GXtest me gustar´a se tomara la opini´n de Carlos. ı o 5. ¿Se lograron los objetivos planteados para los proyectos piloto? - En lo que respecta a OpenSIH s´, por Escritorio Cl´nico la respuesta ı ı corresponde a Carlos. 6. ¿La herramienta de colaboraci´n para la gesti´n de incidente es util? o o ´ - S´, totalmente. ı 7. Sugerencias/Comentarios generales de la metodolog´ ıa. - Dado que la metodolog´a plantea casi la totalidad de las disciplinas/tareas ı de Testing y al aplicarla se elegir´a un roadmap (con algunas obligatorias) ı pienso se deber´a disponer de una gu´a/m´todo sobre c´mo determinar ı ı e o las etapas que se saltean, ya sea por falta de personal, documentaci´n y o tiempos. 5.8. Herramientas de Automatizaci´n de Prueo bas Las herramientas estudiadas como motor de automatizaci´n son: Selenium Webo driver, y GXtest. Para los sistemas desarrollados en GeneXus (Escritorio Cl´ ınico y M´dico de Referencia) GXtest es ventajoso15 y para el resto, que corre en plae taforma web (como OpenSIH) se puede utilizar Selenium Webdriver. La decisi´n de la herramienta a utilizar est´ directamente relacionada con el o a Software elegido y desde el punto de vista de testing funcional de caja negra. 15 Es v´lido destacar que aunque se use GeneXus, siempre que se genere para plataforma a Web, se podr´n utilizar herramientas como Selenium Webdriver, la ventaja aqu´ viene de a ı las prestaciones de GXtest como herramienta completa en sus funcionalidades y su natural integraci´n con GeneXus. o
  • ´ 5.8. HERRAMIENTAS DE AUTOMATIZACION DE PRUEBAS 145 GXtest Las raz´n de por qu´ GXtest es muy ventajoso como herramienta de automatio e zaci´n para aplicaciones desarrolladas en GeneXus, pasa mayoritariamente por o la gran mantenibilidad de los casos de prueba que provee. GxTest actualiza los casos de prueba luego de un re-ordenamiento de campos de GeneXus, no as´ en ı Selenium, teniendo que cambiar todos los casos implementados, o teniendo que construir pruebas enfocadas a la mantenibilidad, aumentando as´ el costo de ı mantenimiento, automatizaci´n y ejecuci´n de las pruebas.Lo segundo a tener o o en cuenta es la facilidad de automatizar y reutilizar los casos de prueba ya automatizados. GXtest brinda una interfaz gr´fica que permite a un usuario no experto, a automatizar casos de pruebas de manera simple, incluso se puede delegar la construcci´n de pruebas para ciclos funcionales b´sicos a Usuarios Finales o a expertos en el dominio, con el debido entrenamiento, el cu´l no es costoso (dado a que la curva de aprendizaje de la herramienta es “media”16 . Selenium Webdriver Cuando la plataforma es web (en nuestro contexto, tampoco desarrollado en GeneXus, como es el caso de OpenSIH), una opci´n libre y muy popular, con o antecedentes de uso en la organizaci´n es Selenium, en este caso Selenium Webo driver. Al momento de estudio, GXTest no aplica para automatizaci´n de otras o aplicaciones que no sean generadas por GeneXus. Selenium Webdriver permite una gran variedad de escenarios de automatizaci´n, es OpenSource, y soporta o java. La gran popularidad mencionada, trae consigo la existencia de muchos recursos en foros, comunidades de usuarios, e infinidad de sitios web. En el contexto del proyecto, la herramienta sera utilizada como motor de interacci´n con o el navegador, las tareas de planificaci´n y dise˜o de tests mantenibles se impleo n mentan por fuera de Selenium. En el contexto de uso (y sin contar la dificultad de armar el framework de pruebas automatizadas), la complejidad de la herramienta se deriva al manejo del lenguaje de programaci´n seleccionado (en este caso Java) y al desaf´ de o ıo identificar los diferentes elementos interactivos en el formulario (como ser los que usan AJAX y tecnolog´ interactivas de interfaz de usuario). ıas 16 Aqu´ el termino “media”, significa que Usuarios Funcionales, que en general no tienen ı conocimiento en programaci´n, pueden aprender a utilizar la herramienta para grabar y o ejecutar sus casos de prueba, sencillos en implementaci´n, pero posiblemente muy provechosos o por el lado del ciclo funcional representado.
  • CAP´ ITULO 5. PROYECTO PILOTO 146 Comparaci´n de herramientas o El siguiente cuadro, 5.2, muestra una comparaci´n de GXtest contra el o framework implementado con un conjunto de herramientas libres. GXtest Curva de aprendizaje Costo econ´mico o Soporte Lenguaje de scripting Plataformas soportadas Integraci´n con Herrao mientas de Desarrollo Grabaci´n de Esqueleo to Gesti´n de casos de o prueba Trazabilidad con requerimientos Trazabilidad con incidentes Media U$S 10.000 a enero de 2012 Disponible, brindado por la empresa Se puede utilizar JavaScript o Procedimientos GeneXus Web. Limitado a desarrollo en GeneXus Compatible con GeneXus S´ muy amigable e inı, tuitiva. Integrado en la herramienta Java + TestNG + Selenium Alta Libre Material disponible en foros, requiere investigaci´n o Requiere conocimientos de Programaci´n en Jao va Web Entornos para Java Posible mediante el uso de Selenium IDE. No integrado. No integrado. No Integrado. No Integrado. No integrado. Mantenibilidad de los casos de prueba Integrado en la herramienta. Es sencillo efectuar tareas de mantenimiento versi´n a vero si´n. o Es posible dise˜ ar una n soluci´n o mantenible. Existen patrones de dise˜ o para este fin. n Posibilidad de pruebas orientadas a datos Integrado S´ mediante uso de daı, taproviders de TestNG. Dise˜o de casos n Ejecuci´n en difereno tes navegadores Ejecuci´n distribuida o Planificaci´n de la ejeo cuci´n o Herramienta de modelado incluida. Internet Explorer, Firefox Integrado Integrado No integrado. Internet Explorer, Firefox, Chrome. No integrado. No integrado. Cuadro 5.2: Comparaci´n de herramientas de automatizaci´n de pruebas o o
  • 5.9. CONCLUSIONES 147 En el cuadro 5.2, todas las funcionalidades no integradas en las herramientas siempre pueden ser implementadas manualmente, modeladas a trav´s de otra e herramienta, o en el caso del framework de automatizaci´n, este puede ser o extendido. 5.9. Conclusiones En ambos proyectos el trabajo fue satisfactorio. Se pudo aplicar exitosamente la metodolog´ generando las etapas y actividades propuestas, para cada proceso ıa, de testing (manual y automatizado). Se genera documentaci´n en herramientas o gratuitas existentes en la organizaci´n que son testigo de etapas y actividades o y que sirven de ejemplo para otros proyectos de testing. Los procesos fueron seguidos en dos proyectos, conformando un equipo de testing de cinco integrantes, los dos testers de ASSE y los tres integrantes del proyecto de grado, adem´s de contar con la colaboraci´n de Ariel Sabiguero y a o Marcelo Lemos para la parte de infraestructura, instalaci´n y configuraci´n de o o herramientas. Accesoriamente se implanta el uso de la herramienta Redmine, cuya flexibilidad permite entre otras cosas modelar el flujo de trabajo y ciclo de vida de los incidentes, permitiendo la paulatina integraci´n de los desarrolladores a la forma o de trabajo y generando un entorno aislado de la forma de trabajo habitual, para evitar interferencias. Se logra excelente interacci´n y colaboraci´n con los desarrolladores, equipos o o internos y externos a ASSE. La direcci´n apoy´ el desarrollo del proyecto, y los integrantes del proyecto de o o grado pudimos entrar a trabajar en la organizaci´n a la par del resto de los o equipos como meros integrantes del ´rea de testing. a
  • 148 CAP´ ITULO 5. PROYECTO PILOTO
  • Cap´ ıtulo 6 Conclusiones Este cap´ ıtulo resume comentarios acerca del diagn´stico inicial, muestra una o s´ ıntesis de las conclusiones sobre el proyecto piloto y presenta alternativas de trabajo a futuro. El cap´ ıtulo cierra con conclusiones globales acerca de todo el trabajo del proyecto de grado. 6.1. Conclusiones del diagn´stico actual o El an´lisis del diagn´stico muestra que la realidad de ASSE frente al desarrollo a o de software y testing, carece de proceso o etapas claramente definidas. Por el lado de desarrollo, esto se da porque cuenta con una estructura compleja de proveedores y desarrollo interno la cual no responde a un proceso unico gestio´ nado por ASSE, y ademas porque los contextos son cambiantes y complejos. El a ´rea de testing tampoco tiene procesos claramente definidos, pero adem´s tiene a el agravante de estar a cargo de un personal muy reducido (al momento, un integrante), que no puede abarcar todo el volumen de trabajo de testing necesario para todos los productos. Para lidiar con estos temas, se recomienda contar con consultor´ en diferentes ´reas, como ser gesti´n de proyectos, ingenier´ ıas a o ıa de software y testing de software en particular. 6.2. Conclusiones generales del proyecto piloto El trabajo en el proyecto piloto fue satisfactorio, permitiendo ver la metodolog´ ıa propuesta en funcionamiento para dos productos de ASSE. Para ambos sistemas se siguen las etapas y actividades relevantes para cada contexto y se genera la informaci´n pertinente. Se logra verificar de forma manual, y generar pruebas o automatizadas en dos herramientas de diferentes caracter´ ısticas, apuntando a la mantenibilidad de las pruebas. 149
  • CAP´ ITULO 6. CONCLUSIONES 150 En cada proyecto se trabaja en conjunto con los integrantes del ´rea de testing a de ASSE y en relaci´n con los diferentes desarrolladores, todos quienes colaboran o excelentemente con la experiencia. Se cont´ con el apoyo de la direcci´n en todo o o momento y con otros integrantes de ASSE, apoyando con la infraestructura y configuraci´n de herramientas de apoyo (Ariel Sabiguero y Marcelo Lemos). o 6.3. Trabajo a futuro Como continuaci´n de este trabajo, se pod´ extender el estado del arte a otros o ıa tipos de testing, generando nuevos m´dulos con nuevos procesos. Temas a ser o abordados podr´ ser Testing de Seguridad, Testing de Rendimiento y Perforıan mance, Testing de Usabilidad, Gesti´n del Testing y Mejora del proceso en s´ o ı. Siempre con la premisa de tratar de lograr propuestas que se puedan adaptar al contexto de la organizaci´n y a muchos otros. o Por el lado de la aplicaci´n pr´ctica, seria recomendable extender las sugerencias o a al ´rea de Ingenier´ de Software, con el fin de atacar temas m´s generales a ıa a que adem´s influyen directamente con el ´rea de estudio. En el cap´ a a ıtulo 3, se recomienda entre otras cosas, contar con consultor´ en el ´rea de Ingenier´ de ıas a ıa Software, para tratar temas de gesti´n de proyectos en la modalidad adoptada o por ASSE (desarrollo interno y adem´s muchos proyectos tercerizados), para a trabajar aspectos de Ingenier´ de Requerimientos, entre otras sugerencias. ıa 6.4. Conclusiones generales del trabajo Si bien el testing de software es una disciplina relativamente reciente con respecto al desarrollo de software, el material existente es abundante y en ocasiones reciente. El estado del arte tiene una extensi´n quiz´s excesiva para lo que se o a espera de una investigaci´n para el proyecto de grado, sobre todo porque se o invirti´ tiempo en revisar y filtrar mucho material. Por temas de extensi´n y o o prioridades no se pudo abarcar tanto en temas de actualidad como se pretend´ ıa (lo que implicar´ dejar por fuera los temas m´s b´sicos e importantes). ıa a a El dise˜o de la metodolog´ propuesta insumi´ gran parte del tiempo del pron ıa o yecto antes de ser aplicada. Queda la incertidumbre de si hubiese sido posible dise˜arla de manera incremental, y as´ poder ajustarla simult´neamente con su n ı a aplicaci´n. o Trabajar con los integrantes de ASSE y en relaci´n con otros actores fue muy o satisfactorio y conlleva un aprendizaje conjunto. De la buena relaci´n generao da, tenemos la convicci´n de que tambi´n fue provechoso y satisfactorio para o e ellos, como se expresa en los comentarios de la secci´n 5.7 del cap´ o ıtulo 5. Como complemento se podr´ haber ahondado m´s en temas de capacitaci´n t´cnica ıa a o e en testing, m´s all´ de los casos puntuales que derivan de la colaboraci´n en el a a o
  • 6.4. CONCLUSIONES GENERALES DEL TRABAJO 151 proyecto piloto. Como conclusi´n general, los estudiantes integrantes del proyecto de grado, o estamos conformes con el trabajo logrado y sobre todo con la haber podido transitar esta experiencia junto a todos los involucrados.
  • 152 CAP´ ITULO 6. CONCLUSIONES
  • Ap´ndice A e Sistema de Seguimiento de Incidentes De la ejecuci´n de las pruebas, surge mucha de la informaci´n a partir de la cual o o los responsables o gestores de proyecto toman la decisi´n sobre el futuro de los o desarrollos. Los incidentes detectados, debidamente registrados, son una fuente fundamental de informaci´n. De su an´lisis se pueden extraer muchas concluo a siones interesantes acerca del estado de las funcionalidades, la confiabilidad de nuestros proveedores, y la evoluci´n de los productos, entre otras. o Es importante contar con una herramienta que oficie de sistema de gesti´n de o incidentes, en la cual se pueda registrar, mantener y extraer la informaci´n neo cesaria. Dentro de las caracter´ ısticas deseables de un sistema de gesti´n de incidentes, o destacamos: Accesibilidad global: el sistema tiene que poder ser consultado desde diferentes puntos de la organizaci´n. No puede estar concentrado en un s´lo o o recurso f´ ısico al cual sea dif´ de acceder simult´neamente. Un ejemplo de ıcil a un sistema poco accesible, seria una planilla electr´nica donde se registran los o incidentes, la cual es compartida y mantenida por los testers. Soluciones m´s a adecuadas son las que involucran arquitecturas cliente-servidor. Centralizaci´n de informaci´n: implica que los datos no est´n distribuidos o o a en diferentes fuentes. Centralizar la informaci´n del registro de incidentes evita o el re-trabajo de actualizar el registro desde los posibles or´ ıgenes que proveen informaci´n. o Modelado del flujo de trabajo y manejo de perfiles: hay sistemas que permiten o sugieren, cierta forma de trabajo para registrar y seguir los cambios, 153
  • 154 ´ APENDICE A. SISTEMA DE SEGUIMIENTO DE INCIDENTES seg´n el perfil del usuario del sistema. Adoptar el flujo de trabajo propuesto por u la herramienta, o personalizarla, puede colaborar a la organizaci´n del trabajo o y la comunicaci´n. o Modelado del ciclo de vida del incidente: junto con el flujo de trabajo, el incidente pasa por diferentes estados. Es deseable que el sistema cuente con al menos los estados utilizados en la organizaci´n para el ciclo de vida de los o incidentes. Si la herramienta no provee un conjunto de estados, al menos que sea posible definirlos, junto con su ciclo de vida. Cuando el ciclo de vida adem´s, a modela qu´ rol puede acceder a ciertos estados y cambiarlo, estamos ante el e modelado del flujo de trabajo mencionado anteriormente. Disponibilidad y Confiabilidad: el sistema tiene que estar a disposici´n o al menos todo el tiempo que est´ funcionando la organizaci´n. Adem´s, la e o a persistencia y manejo de la informaci´n debe ser confiable, dado que los datos o registrados son muy valiosos para las actividades de testing y desarrollo. Control de acceso basado en roles: es posible configurar la herramienta de tal forma que ciertos perfiles puedan acceder a la informaci´n de diferente o forma. Se puede restringir quienes pueden consultar, modificar y eliminar la informaci´n registrada. o Posibilidad de extensi´n y adaptaci´n: finalmente, adem´s de que las cao o a racter´ ısticas deseables de personalizaci´n y adaptaci´n de la herramienta, muo o chos sistemas de seguimiento de incidentes proveen mecanismos para extender sus funcionalidades seg´n las necesidades de cada proyecto y organizaci´n. Por u o ejemplo, supongamos que un proyecto necesita que todos los reportes de incidentes cuenten con una captura de pantalla que muestre el momento en el que se manifiesta; entonces, una herramienta extensible provee un mecanismo de incluir ese detalle en la descripci´n del incidente. o Adem´s de los puntos mencionados, tambi´n se deben tomar en cuenta las a e restricciones de la organizaci´n a la hora de incorporar una herramienta de o seguimiento de incidentes; similares a los mencionados en la secci´n 2.5.2 sobre o la elecci´n de una herramienta de automatizaci´n. Existen muchas soluciones o o comerciales y gratuitas para este fin. Un buen ejemplo es la herramienta Mantis1 , ya utilizada por la organizaci´n, la cual es una muy buena alternativa libre para o este tipo de sistemas. 1 Manti es una herramienta de seguimiento de incidentes opensource, ver el sitio http://www.mantisbt.org/ (accedido por ultima vez en marzo de 2011) ´
  • Ap´ndice B e Ejemplos de Instrumentaci´n de la o Metodolog´ ıa El prop´sito de este apartado es ilustrar ejemplos de c´mo personalizar la proo o puesta metodol´gica para diferentes realidades supuestas. Para definir y clasifio car los diferentes contextos, se establece un conjunto de criterios. Cada criterio admite un conjunto de valores posibles. Los diferentes contextos de estudio se clasificar´n a trav´s de los criterios dea e finidos y sus valores. Esta clasificaci´n es un supuesto arbitrario, y a modo de o ejemplo, de un escenario real para una organizaci´n. o Se representar´ un posible escenario de instanciaci´n de FIT para cada cona o texto, especificando la estrategia a adoptar y el resumen del supuesto roadmap ´ para esa realidad. Adem´s, para los escenarios particulares de “Testing Agil” a y “Testing Independiente con Interrelaci´n con Equipos (tester como articulao dor)”, se complementa la instanciaci´n con una representaci´n gr´fica de etapas o o a y actividades involucradas. Los criterios y sus valores son totalmente arbitrarios, as´ como la valoraci´n de ı o cada contexto, los cuales no responden a ninguna fuente oficial, sino que deriva de la percepci´n y la experiencia de los autores. Especialistas en la materia o podr´ proponer muchas otras alternativas. ıan 155
  • ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA 156 B.1. Criterios para clasificar los contextos B.1.1. Frecuencia de liberaciones Este criterio se refiere al ritmo de las liberaciones de productos o cambios en el mismo. Alta: en el entorno de liberaciones diarias. Media: corresponde a liberaciones en intervalos de algunas semanas, por ejemplo, de una a cuatro semanas. Baja: son proyectos que tienen entregas m´s a largo plazo, como ser de a uno a seis meses. B.1.2. Proceso seguido por desarrollo En este punto se presta atenci´n a la naturaleza del proceso de desarrollo seguido o en la organizaci´n. o Varios: la organizaci´n cuenta con un equipo de desarrollo heterog´neo, o e o con varios equipos de desarrollo, cada uno siguiendo su propia metodolog´ ıa. ´ Agil: se sigue una metodolog´ ´gil de desarrollo con iteraciones que duran ıa a de tres a seis semanas generalmente. Cascada: el proceso abordado cuenta con etapas definidas, que se suceden unas a otras. B.1.3. Necesidad de evidencia de pruebas La rigidez de los dem´s procesos de la organizaci´n, pueden marcar la exigencia a o de que todos los procesos sean auditables. Esto puede afectar el proceso de testing, sobre todo en lo que respecta a documentaci´n que deje constancia de o la ejecuci´n de las pruebas y sus resultados. o Alta: todos los procesos y sus resultados deben estar documentados. Media: es recomendable dejar constancia de la ejecuci´n de las pruebas o y sus resultados. Puede servir para resolver diferencias. Ninguna: no es necesario documentar ninguna parte del proceso. La decisi´n de documentar las pruebas pasa por la conveniencia detectada o por el tester y en todo lo que aporte a su labor, dado que no hay una exigencia por parte de la organizaci´n al respecto. o
  • B.1. CRITERIOS PARA CLASIFICAR LOS CONTEXTOS B.1.4. 157 Complejidad del SUT Apunta a la complejidad percibida del producto de software a testear (o SUT, correspondiente a la sigla en ingl´s “Software Under Test”). Un e software se puede considerar complejo porque su funcionalidad responde a un comportamiento intrincado, dif´ de entender y aprender; o porque su ıcil funcionamiento es oscuro al usuario y es dif´ generar un modelo mental de ıcil su operativa; o involucra c´lculos muy complejos o maneja grandes vol´ menes a u de datos, o tiene una arquitectura muy compleja, entre otros aspectos. Alta: sistema muy complejo. Es necesaria la colaboraci´n de muchos o actores para lograr un conocimiento del producto. Media: el software es complejo, pero es posible aprender a utilizarlo sin mucha asistencia externa a testing. Baja: el software es f´cil de entender y su correspondencia con el dominio a es directa. B.1.5. Criticidad del SUT Responde al aspecto de qu´ tan cr´ e ıtico es el producto o la funcionalidad visto desde la perspectiva del negocio, esto es, un software cr´ ıtico que falla, genera una gran da˜o al negocio. n Alta: el sistema tiene un gran impacto al negocio. Su falla implica un gran riesgo. Media: corresponde a productos que tienen relaci´n directa con su o contexto, pero son tolerantes a algunas fallas en su dominio. Baja: este tipo de producto est´ enfocado a cubrir la funcionalidad, pero a la presencia de fallas no es cr´ ıtica para el negocio. Suele corresponderse con sistemas o funcionalidades secundarias o poco usadas. B.1.6. Conocimiento Previo del Dominio Refiere a la experiencia previa que existe en los testers acerca del producto. Esto influye directamente en la estrategia a adoptar y el esfuerzo a invertir en tareas an´lisis de requerimientos y ejecuci´n de pruebas. a o Bajo: el producto y sus funcionalidades son de total desconocimiento para el equipo de testing, y existen pocos antecedentes de pruebas similares. Medio: se conocen las funcionalidades del producto y los nuevos desarrollos representan desaf´ en aprendizaje para el testing, pero ıos conservan muchos puntos en com´n con el conocimiento existente en el u a ´rea de testing.
  • ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA 158 Alto: el sistema es ampliamente manejado por el equipo de testing, los cambios y funcionalidades nuevas no presentan una gran diferencia con las existentes. B.1.7. Complejidad del Dominio El criterio de complejidad del dominio expresa la dificultad de adquirir el conocimiento de c´mo se comporta el negocio. Adem´s de estar relacionado o a con la dificultad de la realidad abordada por el producto, tambi´n influye la e disponibilidad de expertos en el dominio que puedan asistir en esta tarea. Alta: el dominio es muy complejo, maneja terminolog´ muy extensa y ıa particular, y/o es poco probable contar con la colaboraci´n de un experto o en el dominio. Media: si bien el dominio del problema puede ser complejo, es posible acceder a la asistencia de los expertos en el negocio, de tal manera que se pueda aprender del producto en contraste con la realidad que maneja. Baja: el negocio manejado por el sistema es sencillo, los t´rminos e involucrados son f´cilmente manejados por el ´rea de testing y la relaci´n a a o del dominio con el uso del sistema es directa. B.1.8. Plazos establecidos externamente Los intervalos de tiempo marcados por la organizaci´n afectan directamente la o estrategia y la planificaci´n de actividades del proyecto de testing. o Cortos y r´ ıgidos: la organizaci´n establece plazos muy exigentes para o la concreci´n de los proyectos. Estos plazos, adem´s, no pueden ser o a negociados y modificados. Cortos y flexibles: los intervalos de tiempo son acotados, pero el no cumplimiento de los hitos generalmente deriva en un ajuste de los planes y modificaci´n de plazos. o Flexibles: los plazos establecidos y no alcanzados no tienen gran impacto en el negocio. Las metas no alcanzadas se descartan, o se re-planifican con nuevos plazos. B.2. ´ Testing Agil El testing ´gil se da en organizaciones que adoptan una metodolog´ ´gil de desaa ıa a rrollo. Consecuentemente, en este contexto la documentaci´n de requerimientos o es escasa, y s´lo se genera aquella que es necesaria. Se cuenta con liberaciones o muy frecuentes y las actividades est´n orientadas a resultados. Una pr´ctica de a a testing r´ ıgida y extremadamente documentada no tendr´ ´xito en esta realidad. ae
  • ´ B.2. TESTING AGIL 159 Suponemos adem´s que la infraestructura, configuraci´n de ambientes y cona o junto de herramientas a utilizar son provistas por la organizaci´n y encargada o a otros equipos. Supuestos seg´ n criterios definidos: u Figura B.1: Contexto de organizaci´n que adopta una metodolog´ Agil. o ıa ´ B.2.1. Estrategia La estrategia a adoptar, ser´ ejecutar testing exploratorio para la mayor´ de las a ıa funcionalidades, y testing planificado para las funcionalidades m´s cr´ a ıticas y que atentan al negocio. La documentaci´n generada es la m´ o ınima imprescindible que permita apoyar el proceso, m´s que dejar constancia de su aplicaci´n (aunque a o
  • 160 ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA siempre es positivo contar con ella). El foco tiene que estar en la automatizaci´n o de pruebas, sobre todo para las tareas engorrosas y pruebas de regresi´n del o producto. Las herramientas de comunicaci´n giran entorno al sistema de gesti´n o o de incidentes, e interacciones cara a cara (preferibles antes que otros medios de comunicaci´n, como ser correo electr´nico o chat). o o B.2.2. Instanciaci´n de FIT o Se enfoca el proceso a la automatizaci´n. Se prescinde de las etapas de o verificaci´n de documentos, y la etapa de an´lisis de defectos se utiliza para o a identificar debilidades en los componentes del sistema y mejorar la estrategia de pruebas de regresi´n. Los procesos de testing manual y automatizado generan o la documentaci´n m´ o ınima imprescindible. El testing manual se encarga de las pruebas de humo y de generar informaci´n que es insumo para el testing o automatizado. De ser posible se puede aplicar testing temprano, y enfocar las actividades de testing para proveer informaci´n lo antes posible ante nuevo o software funcionando, apto para ser verificado. La comunicaci´n es importante, o las etapas de informar resultados adem´s pasan a tener un componente fuerte a de interacci´n humana y reporte oral, antes que escrito. o B.2.3. Representaci´n gr´fica del roadmap o a Etapas del M´dulo II y III en el roadmap o Como se puede ver en los siguientes diagramas, casi todas las etapas y actividades de los procesos son transitadas, de hecho, en el m´dulo II solamente se deja o por fuera la etapa de Verificaci´n de Documentos, debido a que se supone que o en la organizaci´n no hay documentos formales del proceso de desarrollo. Para o el m´dulo III se toman todas las etapas. o La interrogante v´lida que surge para este caso, ser´ ¿Por qu´ en un contexto a ıa: e a ´gil se toma la decisi´n de abordar tantas etapas y actividades de los procesos?, o dado que es razonable pensar que implica una sobrecarga de trabajo que obstaculizar´ el logro de los objetivos. El motivo por el cu´l se considera esta ıa a instrumentaci´n como la adecuada, es que por m´s que se transiten muchas o a actividades y etapas; no se generan documentos formales y extensos para documentar el proceso, sino que se vuelca el esfuerzo en las actividades de comunicaci´n y el registro de informaci´n que corresponde s´lo a la generaci´n o o o o de material imprescindible para las pruebas. Como comentario de ejemplo, se podr´ decir que en este contexto no se contar´ con plantillas de documentos ıa a formales conteniendo control de versi´n y autores, introducci´n, puntos centrales o o y conclusiones.
  • ´ B.2. TESTING AGIL 161 Etapas del Proceso de Testing Funcional Manual AYR - Alcance y An´lisis de Riesgo a DSN* - Dise˜o de n Casos de Prueba PEJ - Preparaci´n de Ejecuci´n o o EJP* - Ejecuci´n de Pruebas o INR* - Informar Resultados ANR* - An´lisis a de Requerimientos VDD - Verificaci´n de Documentos o SAP - Seguimiento y Actualizaci´n del Plan o PLN* - Planificaci´n Inicial o ADD - An´lisis de Defectos a Figura B.2: FIT M´dulo II: Proceso de Testing Funcional Manual para Testing o ´ Agil .
  • 162 ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA Actividades de Planificaci´n Inicial o SCP - Seguimiento y Control del Proyecto SEE* - Seleccionar Estrategia y Enfoque EST - Formular Estimaciones ADR - An´lisis de Riesgo seg´n a u Requerimientos y Negocio STD - Selecci´n de o T´cnicas de Dise˜o e n ALC* - Alcance de las Pruebas ACP - Criterios de Aceptaci´n o ´ Figura B.3: Etapa Planificaci´n Inicial para Testing Agil o .
  • ´ B.2. TESTING AGIL 163 ANR* - An´lisis de Requerimientos a Actividades de An´lisis de Requerimientos a ANR* - An´lisis a de Requerimientos VFR - Verificaci´n o de Requerimientos CRF - Construcci´n de o Requerimientos Faltantes VDR - Validaci´n de o Requerimientos Relevados ANR* - An´lisis a de Requerimientos ´ Figura B.4: Etapa An´lisis de Requerimientos para Testing Agil a Actividades de Dise˜ o de Pruebas n DMS - Dise˜o de n Misiones y Sesiones EMS - Especificaci´n o de Misiones y Sesiones ´ Figura B.5: Etapa Dise˜o de Pruebas del Testing Exploratorio para Testing Agil n
  • 164 ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA DCP - Dise˜o de n Casos de Prueba ESP - Especificaci´n o de Casos de Prueba ´ Figura B.6: Etapa Dise˜o de Pruebas del Testing Planificado para Testing Agil n Actividades de Preparaci´n de Ejecuci´n o o CET - Configurar Entorno de Testing y Ambientes BDP - B´squeda de u Datos para las Pruebas CHA* - Configuraci´n de o Herramientas de Apoyo ´ Figura B.7: Etapa Preparaci´n de Ejecuci´n para Testing Agil o o
  • ´ B.2. TESTING AGIL 165 ECP* - Ejecuci´n o de Casos de Prueba RDC - Redise˜ o y Adaptaci´n de Casos n o DEJ - Documentaci´n de Ejecuci´n o o Actividades de Ejecuci´n de Pruebas o ´ Figura B.8: Etapa Ejecuci´n de Pruebas para Testing Agil o Actividades de Alcance y An´lisis de Riesgo a PRF - Priorizar Requerimientos y Funcionalidades SPC - Seleccionar y Priorizar Casos de Prueba NVA - Negociar y Validar Alcance ´ Figura B.9: Etapa Alcance y An´lisis de Riesgo para Testing Agil a
  • 166 ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA Actividades de Informar Resultados CAO* - Comunicar Avances y Obst´culos a OBM - Obtener Mediciones CIN* - Crear Informes ´ Figura B.10: Etapa Informar Resultados para Testing Agil Actividades de Seguimiento y Actualizaci´n del Plan o RPT - Reestimar Proyecto de Testing AEF - Ajustar Esfuerzo APL* - Ajustar Plan ´ Figura B.11: Etapa Seguir y Actualizar el Plan para Testing Agil
  • ´ B.2. TESTING AGIL 167 Actividades de An´lisis de Defectos a AIN* - Analizar Informaci´n de Incidentes o PIN - Procesar Informaci´n de Incidentes o CIA* - Crear Informe de An´lisis de Incidentes a ´ Figura B.12: Etapa An´lisis de Defectos para Testing Agil a .
  • ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA 168 Etapas del Proceso de Testing Funcional Automatizado SPR* - Seleccionar Pruebas PDA* - Preparaci´n o de Automatizaci´n o IPA* - Implementaci´n o de Prueba Automatizada EPA* - Ejecuci´n de o Pruebas Automatizadas INR* - Informar Resultados MTA* - Mantenimiento de Testware de Automatizaci´n o SHE* - Seleccionar Herramientas AED* - An´lisis de a Errores Detectados Figura B.13: FIT M´dulo III: Proceso de Testing Funcional Automatizado para o ´ Testing Agil .
  • ´ B.2. TESTING AGIL 169 Actividades de Seleccionar Herramientas IDR* - Identificar Restricciones INH - Investigar Herramientas CPC - Construir Prueba de Concepto EIH - Elaboraci´n de o Informe de Herramientas DFH* - Definir Herramientas ´ Figura B.14: Etapa Seleccionar Herramientas para Testing Agil .
  • 170 ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA Actividades de Preparaci´n de Automatizaci´n o o PEP* - Preparar Entorno y Producto DPA* - Dise˜ar n Prueba Automatizada PFA* - Preparar Framework de Automatizaci´n o ´ Figura B.15: Etapa Preparaci´n de Automatizaci´n para Testing Agil o o Actividades de Implementaci´n de Prueba Automatizada o IPS* - Implementaci´n o de Scripts VFS* - Verificaci´n de Scripts o ´ Figura B.16: Etapa Implementaci´n de Prueba Automatizada para Testing Agil o
  • ´ B.2. TESTING AGIL 171 Actividades de Ejecuci´n de Pruebas Automatizadas o PEA - Planificaci´n o de la Ejecuci´n o RRP* - Recopilar Resultados de las Pruebas IRA* - Informar Resultados de Pruebas Automatizadas ´ Figura B.17: Etapa Ejecuci´n de Pruebas Automatizadas para Testing Agil o Actividades de Mantenimiento de Testware de Automatizaci´n o REC - Revisar Etapa de Automatizaci´n en Curso o ATA* - Ajuste de Testware de Automatizaci´n o EAM - Elaborar Informe de Ajuste de Mantenimiento Figura B.18: Etapa Mantenimiento de Testware de Automatizaci´n para Testing o ´ Agil
  • 172 B.3. ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA Testing Independiente con Interrelaci´n o con Equipos En este contexto, se cuenta con una realidad muy dispar de procesos de desarrollo y actores involucrados. El tester suele tomar un rol articulador, al necesitar la visi´n de varios actores (a quienes tambi´n puede proveer informaci´n) cuyos o e o canales de comunicaci´n parecen ca´ticos. o o Supuestos seg´ n criterios definidos: u Figura B.19: Contexto de organizaci´n con Testing Independiente integrado. o
  • ´ B.3. TESTING INDEPENDIENTE CON INTERRELACION CON EQUIPOS173 B.3.1. Estrategia Mayoritariamente testing exploratorio, dise˜o de pruebas para asuntos muy n cr´ ıticos o por negociaci´n con el contratante. La documentaci´n generada es o o la imprescindible para apoyar el proceso, pero en condiciones normales, se genera bastante documentaci´n, dado que el tester tiene acceso al n´ cleo de o u los requerimientos y acumula mucha informaci´n, sobre todo para verificar o realidades complejas. La automatizaci´n puede ser abordada como estrategia o de mitigaci´n a tareas que insumen mucho tiempo, o puede ser inter´s de la o e organizaci´n. Tiene una pol´ o ıtica de informe de resultados frecuente para los dem´s responsables. a B.3.2. Instanciaci´n de FIT o El proceso de testing es “descontracturado”. Se toman todas las etapas de an´lisis y de planificaci´n, pero se genera la documentaci´n necesaria y/o a o o exigida por la organizaci´n contratante. Las etapas de an´lisis marcan el perfil o a articulador del tester en este contexto, consiguiendo que los diferentes actores trabajen en conjunto con el fin com´n de aportar a la mejora de la calidad u (desarrolladores, gerentes, usuarios finales, interesados, entre otros). En este contexto se puede automatizar pruebas dependiendo de la disponibilidad de recursos y el inter´s del contratante. e B.3.3. Representaci´n gr´fica o a Etapas del M´dulo II y III en el roadmap o Para este contexto, el proceso de testing prescinde solamente de la etapa de An´lisis de Defectos, suponiendo que no hay una estrategia prevista en la ora ganizaci´n para dedicar un tiempo a investigar la informaci´n residente en el o o sistema de seguimiento de incidentes. El proceso de testing automatizado cuenta con todas las etapas definidas. Se asume que la organizaci´n no es extremadamente formal con sus procedio mientos y cuenta con muchos proyectos de desarrollo. La rigurosidad de las actividades de testing al nivel de exigencia y forma de trabajo de la organizaci´n, o en incluso del proyecto en particular. Las actividades que generan documentaci´n m´s extensa son las relacionadas con comunicaci´n, ejecuci´n de pruebas o a o o y automatizaci´n de pruebas. o
  • ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA 174 Etapas del Proceso de Testing Funcional Manual AYR - Alcance y An´lisis de Riesgo a DSN* - Dise˜o de n Casos de Prueba PEJ - Preparaci´n de Ejecuci´n o o EJP* - Ejecuci´n de Pruebas o INR* - Informar Resultados ANR* - An´lisis a de Requerimientos VDD - Verificaci´n de Documentos o SAP - Seguimiento y Actualizaci´n del Plan o PLN* - Planificaci´n Inicial o ADD - An´lisis de Defectos a Figura B.20: FIT M´dulo II: Proceso de Testing Funcional Manual para Testing o Independiente .
  • ´ B.3. TESTING INDEPENDIENTE CON INTERRELACION CON EQUIPOS175 Actividades de Planificaci´n Inicial o SCP - Seguimiento y Control del Proyecto SEE* - Seleccionar Estrategia y Enfoque EST - Formular Estimaciones ADR - An´lisis de Riesgo seg´n a u Requerimientos y Negocio STD - Selecci´n de o T´cnicas de Dise˜o e n ALC* - Alcance de las Pruebas ACP - Criterios de Aceptaci´n o Figura B.21: Etapa Planificaci´n Inicial para Testing Independiente o .
  • 176 ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA Actividades de An´lisis de Requerimiento a ANR* - An´lisis a de Requerimientos Figura B.22: Etapa An´lisis de Requerimientos para Testing Independiente a Actividades de Dise˜ o de Pruebas n DMS - Dise˜o de n Misiones y Sesiones EMS - Especificaci´n o de Misiones y Sesiones Figura B.23: Etapa Dise˜o de Pruebas del Testing Exploratorio para Testing n Independiente DCP - Dise˜o de n Casos de Prueba ESP - Especificaci´n o de Casos de Prueba Figura B.24: Etapa Dise˜o de Pruebas del Testing Planificado para Testing n Independiente
  • ´ B.3. TESTING INDEPENDIENTE CON INTERRELACION CON EQUIPOS177 Actividades de Preparaci´n de Ejecuci´n o o CET - Configurar Entorno de Testing y Ambientes BDP - B´squeda de u Datos para las Pruebas CHA* - Configuraci´n de o Herramientas de Apoyo Figura B.25: Etapa Preparaci´n de Ejecuci´n para Testing Independiente o o ECP* - Ejecuci´n o de Casos de Prueba RDC - Redise˜o y Adaptaci´n de Casos n o DEJ - Documentaci´n de Ejecuci´n o o Actividades de Ejecuci´n de Pruebas o Figura B.26: Etapa Ejecuci´n de Pruebas para Testing Independiente o
  • 178 ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA Actividades de Alcance y An´lisis de Riesgo a PRF - Priorizar Requerimientos y Funcionalidades SPC - Seleccionar y Priorizar Casos de Prueba NVA - Negociar y Validar Alcance Figura B.27: Etapa Alcance y An´lisis de Riesgo para Testing Independiente a Actividades de Informar Resultados CAO* - Comunicar Avances y Obst´culos a OBM - Obtener Mediciones CIN* - Crear Informes Figura B.28: Etapa Informar Resultados para Testing Independiente
  • ´ B.3. TESTING INDEPENDIENTE CON INTERRELACION CON EQUIPOS179 Actividades de Seguimiento y Actualizaci´n del Plan o RPT - Reestimar Proyecto de Testing AEF - Ajustar Esfuerzo APL* - Ajustar Plan Figura B.29: Etapa Seguir y Actualizar el Plan para Testing Independiente Actividades de Verificaci´n de Documentos o ESP - Establecer Par´metros Observables a RVD* - Revisi´n o de Documentos ROB - Registrar Observaciones a Documentos IRD* - Crear Informe de Revisi´n de Documentos o Figura B.30: Etapa Verificaci´n de Documentos para Testing Independiente o .
  • ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA 180 Etapas del Proceso de Testing Funcional Automatizado SPR* - Seleccionar Pruebas PDA* - Preparaci´n o de Automatizaci´n o IPA* - Implementaci´n o de Prueba Automatizada EPA* - Ejecuci´n de o Pruebas Automatizadas INR* - Informar Resultados MTA* - Mantenimiento de Testware de Automatizaci´n o SHE* - Seleccionar Herramientas AED* - An´lisis de a Errores Detectados Figura B.31: FIT M´dulo III: Proceso de Testing Funcional Automatizado para o Testing Independiente .
  • ´ B.3. TESTING INDEPENDIENTE CON INTERRELACION CON EQUIPOS181 Actividades de Seleccionar Herramientas IDR* - Identificar Restricciones INH - Investigar Herramientas CPC - Construir Prueba de Concepto EIH - Elaboraci´n de o Informe de Herramientas DFH* - Definir Herramientas ´ Figura B.32: Etapa Seleccionar Herramientas para Testing Agil .
  • 182 ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA Actividades de Preparaci´n de Automatizaci´n o o PEP* - Preparar Entorno y Producto DPA* - Dise˜ar n Prueba Automatizada PFA* - Preparar Framework de Automatizaci´n o Figura B.33: Etapa Preparaci´n de Automatizaci´n para Testing Independiente o o Actividades de Implementaci´n de Prueba Automatizada o IPS* - Implementaci´n o de Scripts VFS* - Verificaci´n de Scripts o Figura B.34: Etapa Implementaci´n de Prueba Automatizada para Testing o Independiente
  • ´ B.3. TESTING INDEPENDIENTE CON INTERRELACION CON EQUIPOS183 Actividades de Ejecuci´n de Pruebas Automatizadas o PEA - Planificaci´n o de la Ejecuci´n o RRP* - Recopilar Resultados de las Pruebas IRA* - Informar Resultados de Pruebas Automatizadas Figura B.35: Etapa Ejecuci´n de Pruebas Automatizadas para Testing o Independiente Actividades de Mantenimiento de Testware de Automatizaci´n o REC - Revisar Etapa de Automatizaci´n en Curso o ATA* - Ajuste de Testware de Automatizaci´n o EAM - Elaborar Informe de Ajuste de Mantenimiento Figura B.36: Etapa Mantenimiento de Testware de Automatizaci´n para Testing o Independiente
  • ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA 184 B.4. Desarrollo en Cascada con proceso r´ ıgido auditable Proceso de desarrollo con en etapas definidas, iterativo e incremental, el cual es seguido rigurosamente. Las pautas organizacionales marcan que se debe dejar constancia de los procesos llevados adelante y sus resultados. Los roles y las responsabilidades est´n definidas, por lo tanto se sabe que se espera de cada a equipo. En estos contextos el testing tiene el desaf´ de no transformarse en ıo cuello de botella al ser muchas veces incorporado en etapas tard´ del desarroıas llo del producto. Supuestos seg´ n criterios definidos: u Figura B.37: Contexto de organizaci´n que usa desarrollo en Cascada. o
  • B.5. TESTING INDEPENDIENTE A MODO DE TESTING FACTORY 185 B.4.1. Estrategia La estrategia abordada por el equipo de testing tendr´ que basarse en testing a temprano con verificaci´n de documentos y validaci´n de requerimientos. El o o testing planificado tendr´ lugar para la mayor´ de las funcionalidades a verificar a ıa y se preferir´n pruebas de humo con testing exploratorio. La documentaci´n a o generada ser´ detallada, y la automatizaci´n ser´ efectuada s´lo en partes muy a o a o estrat´gicas del sistema. e B.4.2. Instanciaci´n de FIT o Todas las etapas y actividades son ejecutadas y documentas, salvo an´lisis de a defectos que es opcional. Las etapas de informaci´n de resultados y comunicaci´n o o son especialmente importantes. Las etapas que definen el transcurso del proyecto deben contar con informaci´n validada por los responsables.. o B.5. Testing Independiente a modo de Testing Factory Este escenario corresponde a las tareas de testing encargadas a un equipo herm´tico que trabaja a modo de Testing Factory(f´brica de testing). En ese a te contexto la responsabilidad del testing es delegada al equipo y el alcance de las pruebas es estrictamente negociado entre la organizaci´n y el equipo. La o documentaci´n generada en el proceso tiene dos formas: documentaci´n interna o o para apoyar el proceso de testing del equipo y documentaci´n visible a la orgao nizaci´n comunicando avances, obst´culos y resultados de las pruebas (u otros o a documentos exigidos por la organizaci´n). o Supuestos seg´ n criterios definidos: u
  • 186 ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA Figura B.38: Contexto de organizaci´n interactuando con una Testing Factory. o B.5.1. Estrategia En este contexto la estrategia es similar a la de un proceso r´ ıgido. Por ejemplo, testing exploratorio para las pruebas de humo, testing planificado con dise˜ o n de casos de prueba para la mayor´ de las funcionalidades. La automatizaci´n ıa o se lleva adelante s´lo si es contratada por la organizaci´n o si esta reporta una o o relaci´n costo beneficio atractiva para la empresa tercerizada. La documentaci´n o o interna difiere de la externa en la forma de comunicar y su contenido. La documentaci´n externa, no suele revelar los detalles de la metodolog´ seguida, o ıa sino proveer informaci´n acerca de los avances, resultados y obst´culos de las o a pruebas.
  • B.5. TESTING INDEPENDIENTE A MODO DE TESTING FACTORY 187 B.5.2. Instanciaci´n de FIT o El proceso seguido puede ser r´ ıgido o flexible dependiendo de la organizaci´n o interna del equipo. Generalmente en esta modalidad, se define un proceso de c´mo llevar adelante el testing, que suele contar con documentaci´n interna y o o que se comunica con la organizaci´n contratante. Las etapas avanzadas, como o ser las de post morten, se llevan adelante s´lo si la organizaci´n tercerizadora o o las cree de importancia y se negocian con el equipo de la testing factory. En este contexto podr´ ıamos suponer que las etapas se siguen rigurosamente, y que se genera la documentaci´n pertinente con cierta formalidad. Las etapas de o informaci´n de resultados son importantes y tienen un componente interno y o externo, dependiendo si el destinatario es el mismo equipo, autoridades de la empresa tercerizada, o el contratante.
  • 188 B.6. ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA Testing en Organizaci´n preocupada por la o Mejora continua Es una organizaci´n que generalmente cumple con sus metas en tiempo y forma. o Se estimulan tareas que analicen los procesos seguidos para aprender de ellos y mejorarlos. La preocupaci´n por la calidad abarca al producto y la organizaci´n o o misma. Supuestos seg´ n criterios definidos: u Figura B.39: Contexto de organizaci´n preocupada por la Mejora Continua. o
  • ´ B.6. TESTING EN ORGANIZACION PREOCUPADA POR LA MEJORA CONTINUA189 B.6.1. Estrategia La estrategia es apuntar a la automatizaci´n y sacar provecho de la informaci´n o o acumulada en los sistemas de gesti´n de incidentes. El testing manual o predominante adopta testing exploratorio. Por fuera del proceso definido, se pueden automatizar pruebas no funcionales. B.6.2. Instanciaci´n de FIT o Adem´s de las etapas comunes, se pueden agregar las actividades avanzadas a de post mortem, como ser an´lisis de defectos. Tambi´n se apunta al testing a e temprano y validaci´n de documentos. La documentaci´n generada no es o o excesiva, sino que es la necesaria para apoyar al proceso. Las etapas de comunicaci´n son muy importantes, y el foco principal est´ en la automatizaci´n o a o de pruebas. Todas las etapas del proceso son ejecutadas, y se apunta a que las pruebas sean mantenibles. Adem´s se puede incluir actividades en las que se a promueve el buen uso de los conceptos de testing y la preocupaci´n por la o calidad.
  • 190 ´ ´ APENDICE B. INSTRUMENTACION DE LA METODOLOG´ IA
  • Glosario A Aplicaci´n Usado como sin´nimo de Producto de Software. o o Automatizaci´n Acci´n de automatizar. o o Automatizar Tareas entorno al objetivo de generar pruebas implementadas de tal manera que se puedan ejecutar de forma desatendida. C Caso de Prueba Unidad m´ ınima de verificaci´n que puede ensayarse sobre un o software. Ciclo de Prueba Per´ ıodo de tiempo en el cual se practican tareas de testing sobre una versi´n de determinado producto, sin que esta sufra o cambios. Ciclo Funcional Conjunto de funcionalidades relacionadas que corresponden a flujo de uso del sistema. F Flujo Funcional Utilizado como sin´nimo de Ciclo Funcional. o Framework (como herramienta de software) Herramienta, o conjunto de herramientas de software que tienen el prop´sito de asistir o llevar o adelante determinada tarea. Por ejemplo framework de testing unitario, corresponde a la herramienta que ejecuta, planifica y clasifica las pruebas unitarias. En el cap´ ıtulo 5 este t´rmino es e referido de esta forma. (como propuesta metodol´gica) Se refiere a la metodolog´ o forma o ıa de trabajo con su conjunto de etapa y actividades propuestas para los diferentes procesos. En el cap´ ıtulo 4 se ver´ el t´rmino usado a e de esta forma y como sin´nimo de Marco de Trabajo. o Funcionalidad Caracter´ ıstica de funcionamiento del producto de software existente o que se desarrollar´. a 191
  • 192 GLOSARIO I Instancia Elemento particular perteneciente a una clase. El cap´ ıtulo 4 es usado para referirse a una aplicaci´n particular de la metodolog´ o ıa en un contexto dado. Instanciable Que se pueden generar instancias del elemento referido. En el cap´ ıtulo 4 se dice que el framework es instanciable, porque se pueden generar instancias de ´l para un contexto particular. e Instanciaci´n Acci´n de generar instancias del elemento referido. En el cap´ o o ıtulo 4 se refiere como instanciaci´n a la acci´n de contextualizar la o o metodolog´ propuesta para una realidad concreta. ıa M Mantenibilidad Es la capacidad de un elemento de ser mantenible. Mantenible Que se le pueden realizar ajustes y mejoras sin que la mayor parte del esfuerzo sea invertido en la preparaci´n del objeto para dichos o ajustes. P Producto Usado como sin´nimo de Producto de Software. o Proyecto de Grado Se refiere al trabajo particular llevado adelante por los estudiantes autores de este documento en la materia proyecto de grado de la carrera de Ingenier´ en Computaci´n de la Facultad ıa o de Ingenier´ Universidad de la Rep´blica. ıa, u Proyecto Piloto Experiencia pr´ctica de aplicaci´n de la metodolog´ propuesa o ıa ta, en sistemas de software de ASSE. Prueba Usado como sin´nimo de Caso de Prueba, o para referirse a todas o las actividades de verificaci´n de determinado sistema. o Prueba Automatizada Implementaci´n de un caso de prueba en forma o program´tica. Es un producto de trabajo de la Automatizaci´n. a o Pruebas de Regresi´n Tareas de verificaci´n que tienen la intenci´n de o o o detectar si el producto no ha sufrido una regresi´n en su calidad o debido a cierto mantenimiento. R Requerimiento Descripci´n de una funcionalidad de determinado sistema. o
  • 193 GLOSARIO S Script C´digo de un caso de prueba implementado en alg´n lenguaje de o u programaci´n o lenguaje propio de alguna herramienta. o Sistema Usado como sin´nimo de Producto de Software. o Software Under Test SUT Sistema de software que es el objetivo de la verificaci´n. o Sigla que significa Software Under Test. T Tercerizaci´n Acci´n de tercerizar determinadas tareas de una organizaci´n. o o o Tercerizado/da Organizaci´n que presta servicios al tercerizador. o Tercerizador Organizaci´n que delega actividades a otra que no la integra. o Tercerizar Significa que una organizaci´n decide que ciertas actividades las o desarrolle otra ajena. Generalmente implica una relaci´n comercial, o pero no es excluyente. Test Usado como sin´nimo de Caso de Prueba. o Testeabilidad Testeabilidad es la capacidad que tiene un software de ser probado, en un determinado contexto. Testeable. Se dice de un software que acorde alg´n criterio puede ser verificado u en determinado contexto. Tester Persona encargada de ejecutar tareas relativas al testing. Testing Actividades involucradas con la verificaci´n de un software. o Testware Producto de trabajo de las actividades relacionadas con la generaci´n de Pruebas Automatizadas. o W Web Service Es un componente de software que brinda servicios en la web a trav´s de una interfaz siguiendo ciertos est´ndares y protocolos de e a comunicaci´n. o
  • 194 GLOSARIO
  • Bibliograf´ ıa [20005] Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE. Number ISO/IEC 25000. ISO/IEC, Geneva, Switzerland, 2005. [Aca01] Spanish Royal Academy. Diccionario de la Lengua Espanola (Spanish Edition) (2 volumes). Espasa Calpe Mexicana, S.A., 2001. [Bac99] James Bach. Heuristic risk-based testing. Software Testing and Quality Engineering, Noviembre 1999. [Bac00] Jonathan Bach. Session-based test management. Software Testing and Quality Engineering, Noviembre 2000. [Bac02] James Bach. Exploratory testing explained, Abril 2002. The Test Practitioner, disponible en http://www.satisfice.com/articles/etarticle.pdf, accedido Diciembre de 2010. [Bac11] James Bach. James bach’s blog, Mayo 2011. [Bol09] Michael Bolton. Testability, Julio 2009. Accedido en diciembre de 2010. [CES10] CES, 12 2010. [FG99a] Mark Fewster and Dorothy Graham. Software Test Automation. Addison-Wesley Professional, 1999. [FG99b] Mark Fewster and Dorothy Graham. Software Test Automation, chapter 9, pages 229–232. Addison-Wesley Professional, 1999. [FG99c] Mark Fewster and Dorothy Graham. Software Test Automation, chapter 10, pages 248–280. Addison-Wesley Professional, 1999. [FG99d] Mark Fewster and Dorothy Graham. Software Test Automation, chapter 1, pages 7–9. Addison-Wesley Professional, 1999. [FG99e] Mark Fewster and Dorothy Graham. Software Test Automation, chapter 1, pages 22–25. Addison-Wesley Professional, 1999. 195
  • BIBLIOGRAF´ IA 196 [FG99f] Mark Fewster and Dorothy Graham. Software Test Automation, chapter 9, page 243. Addison-Wesley Professional, 1999. [FG99g] Mark Fewster and Dorothy Graham. Software Test Automation, chapter 1, pages 4–5. Addison-Wesley Professional, 1999. [FG99h] Mark Fewster and Dorothy Graham. Software Test Automation, chapter 3, pages 83–89. Addison-Wesley Professional, 1999. [Fou11] TMMi Foundation. Test maturity model integration, 2011. [Her93] Paul Herzlich. The w-model. EuroSTAR, 1993. [IAB97] IABG. V-modell, Agosto 1997. [IEE91] IEEE. IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990. Institute of Electrical & Electronics Enginee, 1991. [IEE06] IEEE. IEEE Standard Dictionary of Measures of the Software Aspects of Dependability. Number IEEE Std 982.1TM -2005. Mayo 2006. [JAWea11] J. A. W. James A. Whittaker et al. Google testing blog, Mayo 2011. [Kne08] Ralf Kneuper. CMMI: Improving Software and Systems Development Processes Using Capability Maturity Model Integration (CMMI-DEV). Rocky Nook, 2008. [Mil95] J. Voas & K. Miller. Software testability: the new verification. IEEE Soft, 12:17 – 28, Mayo 1995. [Mye04a] Glenford J. Myers. The Art of Software Testing, Second Edition, chapter 2, page 6. Wiley, 2004. [Mye04b] Glenford J. Myers. The Art of Software Testing, Second Edition. Wiley, 2004. [Pet09] Bret Pettichord. Design for testability, Octubre 2009. Accedido en diciembre de 2010. [P´r06] e Beatriz P´rez. e Proceso de testing funcional independiente. Master’s thesis, Universidad de la Rep´ blica - Facultad de u Ingenier´ 2006. ıa, [Sog09] Sogeti. TPI Next - Business Driven Test Process Improvement. UTN Publishers, 2009. [vdABR+ 08] Leo van der Aalst, Rob Baarda, Ewald Roodenrijs, Johan Vink, and Ben Visser. TMap Next, Business Driven Test Managament. UTN Publishers, 2008.
  • BIBLIOGRAF´ IA 197 [Whi09a] James A. Whittaker. Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design, chapter Appendix C, page 183. Addison-Wesley Professional, 2009. [Whi09b] James A. Whittaker. Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design, chapter Appendix C, pages 183–184. Addison-Wesley Professional, 2009. [Whi09c] James A. Whittaker. Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design. Addison-Wesley Professional, 2009. [Zap10] Carlos Mario et al. Zapata. Una representaci´n gr´fica del testing o a a ´gil. Avances en Sistemas e Inform´tica, 7:18–25, 2010. a