Camarotta plaverocai

866 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
866
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
3
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Camarotta plaverocai

  1. 1. ´ 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
  2. 2. ii
  3. 3. 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
  4. 4. iv RESUMEN
  5. 5. 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
  6. 6. vi AGRADECIMIENTOS
  7. 7. ´ 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 . . . . . . . . . . . . . . . . . . . . .
  8. 8. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  9. 9. ´ 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
  10. 10. ´ 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
  11. 11. ´ 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 . . . . . . .
  12. 12. 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
  13. 13. ´ 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
  14. 14. xiv ´ INDICE DE CUADROS
  15. 15. 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
  16. 16. ´ 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.
  17. 17. 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.
  18. 18. ´ 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
  19. 19. 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
  20. 20. 6 ´ CAP´ ITULO 1. INTRODUCCION
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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.
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. 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 ´
  31. 31. 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
  32. 32. 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
  33. 33. ´ 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.
  34. 34. 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.
  35. 35. 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.
  36. 36. 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].
  37. 37. 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
  38. 38. 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)
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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).
  43. 43. 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
  44. 44. 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
  45. 45. 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.
  46. 46. 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
  47. 47. 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”.
  48. 48. 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.
  49. 49. 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
  50. 50. 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

×