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