universidad de costa ricapci.ucr.ac.cr/sites/default/files/trabajos_de_graduacion/a72278.pdfiii...
TRANSCRIPT
UNIVERSIDAD DE COSTA RICA SISTEMA DE ESTUDIOS DE POSGRADO
COMPARACIÓN DE LA EFECTIVIDAD DE PRUEBAS AUTOMATIZADAS Y MANUALES SOBRE HERRAMIENTAS WEB CORPORATIVAS EN TÉRMINOS DEL
RETORNO SOBRE LA INVERSIÓN
Trabajo Final de Investigación aplicada sometido a la consideración de la Comisión del Programa de Estudios de Posgrado en Computación e Informática para optar al grado y título de Maestría Profesional en
Computación e Informática
JOSÉ IGNACIO DOBLES SOLANO
Ciudad Universitaria Rodrigo Facio, Costa Rica 2018
ii
Dedicatoria
A Carla, quien me apoyó incondicionalmente y aconsejó durante toda la maestría, y a mis
padres, quienes me motivaron a obtener el posgrado.
Agradecimientos
A Alexandra Martínez, por su paciencia y guía constante y acertada tanto en el pregrado
como en el posgrado.
A Christian Quesada, por sus consejos y su perspectiva, que ayudaron a la realización de
esta investigación.
iii
"Este Trabajo Final de Investigación Aplicada fue aceptado por la comisión del programa de Estudios de Posgrado en Computación e Informática de la Universidad de Costa Rica,
como requisito parcial para optar al grado y título de Maestría Profesional en Computación e Informática."
_________________________________
Dra. Gabriela Marín Raventós
Representante del Decano
Sistema de Estudios de Posgrado
_________________________________
Dra. Alexandra Martínez Porras
Profesora Guía
_________________________________
Mag. Christian Quesada López
Representante de la Directora
Programa de Posgrado en Computación e Informática
_________________________________
José Ignacio Dobles Solano
Sustentante
iv
Tabla de contenidos Portada …………………………………………..…………………………………………..………………..…………………. i
Dedicatoria ………………..………………..………………..………………..………………..…………………………….. ii
Agradecimientos ………………..………………..………………..………………..………………..………………..….. ii
Hoja de aprobación ………………..………………..………………..………………..………………..………………. iii
Tabla de contenidos ………………..………………..………………..………………..………………..……………… iv
Lista de tablas ..……………..………………..………………..………………..…………..…..………………………… vii
Lista de figuras ………………..………………..………………..………………..…………..…..…………………….. viii
1. Introducción ………………………………………………………………………………………………………………… 1
1.1 Justificación .............................................................................................................. 4
1.2 Problema .................................................................................................................. 5
1.3. Objetivos ................................................................................................................. 7
1.3.1 Objetivo general ................................................................................................ 7
1.3.2 Objetivos específicos ......................................................................................... 7
2. Marco Teórico …………………………………………………………………………………………………………….. 9
2.1 Aseguramiento de la calidad del software ................................................................ 9
2.2 Pruebas de software ................................................................................................. 9
2.2.1 Tipos de pruebas ............................................................................................. 10
2.2.2 Niveles de pruebas .......................................................................................... 12
2.2.3 Técnicas de diseño de pruebas ........................................................................ 14
2.3 Retorno sobre la inversión (ROI) ............................................................................. 18
3. Trabajo relacionado ………………………………………………………………………………………………….. 21
4. Diseño de los casos de estudio ………………………………………………………………………………….. 27
v
4.1 Preguntas de investigación ..................................................................................... 27
4.2 Selección de roles y datos ....................................................................................... 27
4.3 Caso de estudio múltiple ........................................................................................ 29
4.3.1 Primer caso ...................................................................................................... 31
4.3.2 Segundo caso ................................................................................................... 33
4.3.3 Tercer caso ...................................................................................................... 34
4.3.4 Recolección de datos ....................................................................................... 36
4.3.5 Amenazas a la validez de los estudios .............................................................. 40
4.4 Procedimiento de análisis ....................................................................................... 42
4.5 Procesos e instrumentación.................................................................................... 45
4.5.1 Plan de pruebas ............................................................................................... 45
4.5.2 Ejecución de pruebas manuales y creación de reporte ..................................... 48
4.5.3 Ejecución de pruebas automatizadas ............................................................... 48
5. Resultados y análisis ………………………………………………………………………………………………….. 51
5.1 Resultados .............................................................................................................. 51
5.1.1 Resultados del primer caso de estudio ............................................................. 51
5.1.2 Resultados del segundo caso de estudio .......................................................... 55
5.1.3 Resultados del tercer caso de estudio .............................................................. 61
5.2 Análisis ................................................................................................................... 68
5.2.1 Inversión .......................................................................................................... 68
5.2.2 Costo ahorrado ................................................................................................ 69
5.2.3 Cobertura de código ........................................................................................ 69
5.2.4 Desempeño ..................................................................................................... 70
vi
5.2.5 Retorno sobre la inversión ............................................................................... 73
6. Conclusiones ……………………….……………………………………………………………………………………. 75
7. Trabajo futuro …………………………………………………………………………………………………………… 78
8. Referencias ……………………………………………………………………………………………………………….. 79
vii
Lista de tablas Tabla 1. Resultados del primer caso de estudio. 51
Tabla 2. Resultados del segundo caso de estudio. 56
Tabla 3. Resultados de la primera iteración del tercer caso de estudio. 62
Tabla 4. Resultados de la segunda iteración del tercer caso de estudio. 63
Tabla 5. Resultados de la tercera iteración del tercer caso de estudio. 65
Tabla 6. Matriz de confusión obtenida para las pruebas automatizadas. 70
Tabla 7. Matriz de confusión obtenida para las pruebas manuales. 70
viii
Lista de figuras Figura 1. Ilustración del dominio de valores aceptables para una entrada. 15
Figura 2. Ilustración del dominio de valores frontera para una entrada. 16
Figura 3. Todas las combinaciones para tres variables de encendido/apagado. 17
Figura 4. Matriz ortogonal para tres variables de encendido/apagado. 17
Figura 5. Estructura general de los casos de estudio. 31
Figura 6. Estructura del primer caso de estudio. 32
Figura 7. Estructura del segundo caso de estudio. 34
Figura 8. Estructura del tercer caso de estudio. 36
Figura 9. Matriz de confusión. 39
Figura 10. Ejemplo de plan de pruebas. 47
Figura 11. Ejemplo de reporte de un criterio de prueba. 48
Figura 12. Ejemplo de reporte generado por la herramienta automatizada al
concluir una ejecución de una prueba. 50
Figura 13. Duración de las pruebas manuales y automatizadas para el primer
caso de estudio. 53
Figura 14. Cantidad de errores por severidad encontrados por ambos tipos de
pruebas. 57
Figura 15. Monto ahorrado en USD por tipo de prueba. 59
Figura 16. Diferencias de tiempo dedicado a scripting entre los tres casos de
estudio. 66
Figura 17. Cobertura de código obtenida en cada iteración del tercer caso de
estudio. 67
1
1. Introducción Es normal que durante el desarrollo de un sistema o componente de
software se introduzcan de manera accidental errores que pueden impactar de
manera negativa el funcionamiento de dicho software. La severidad del daño
causado por uno de estos errores puede generarle a la compañía varios miles de
dólares en pérdidas, ya sea por el impacto causado a sus clientes o por la
inversión de recursos necesarios para arreglar dicho error. Tanto así que se
estimó que solo en Estados Unidos el costo de los errores de software alcanzó los
$1.1 billones en el 2016 [1]. Tal monto justifica que haya un interés por prevenir
que estos errores pasen sin ser detectados. Si se pudiese encontrar un error antes
de que cause problemas a un cliente, el impacto se vería reducido de manera
significativa. Es aquí donde el aseguramiento de la calidad cobra importancia
como parte del proceso del desarrollo de software. Este se puede definir como el
nivel de confianza de que el software no posea vulnerabilidades, y que funcione de
manera esperada [2]. Por medio de esto se puede validar que el software se
comporte como se espera que se comporte y tratar de minimizar los daños que
pasen sin ser detectados con el fin de reducir el impacto en el usuario final. Por
ejemplo, se pueden aplicar buenas prácticas de programación que ayudan a la
creación de un código mantenible y eficiente. También se pueden realizar
validaciones en el código, como por ejemplo, el análisis de una porción de código
realizado por varios programadores con el fin de obtener múltiples perspectivas
sobre la lógica implementada. Todos estos ejemplos de procedimientos que se
pueden realizar caben dentro de lo que se conoce como el control de la calidad del
software; una serie de procedimientos que una organización puede realizar para
garantizar que el software cumpla con los requisitos mínimos de calidad que
provean el mayor beneficio al cliente [3]. Entre los procedimientos más comunes
que se utilizan están las pruebas de software [4]. Las pruebas de software son
ejecutadas con el fin de detectar el comportamiento inapropiado del componente
2 bajo inspección [4]. Si una prueba obtiene un resultado que no era el esperado,
probablemente sea debido a un error en el código.
Las pruebas de software se pueden dividir principalmente en dos
categorías: manuales y automatizadas [5]. Un ingeniero de calidad puede utilizar
la aplicación con el fin de encontrar errores y comportamientos inesperados. Este
tipo de prueba es considerada una prueba manual, ya que una persona interactúa
directamente con la aplicación [5]. Por otro lado, el mismo probador de software
puede programar un proceso que recibe ciertas entradas de datos y espera ciertas
respuestas con el fin de simular la interacción de un usuario con la aplicación. Esto
se considera una prueba automatizada ya que, una vez programada, puede ser
ejecutada por una computadora de forma automática (sin intervención humana)
[5]. Ambos tipos de pruebas implican necesariamente una inversión en tiempo y
recursos tales como personal y dinero, que debe ser tomada en cuenta durante la
planificación de un proyecto. Si bien las pruebas automatizadas tienen la ventaja
de que pueden ser ejecutadas múltiples veces por una computadora a un costo
muy bajo, hay contextos donde un tipo de prueba es preferible a otro [6]. Por
ejemplo, las pruebas de estrés o de rendimiento que ejecutan transacciones
concurrentes deben ser automatizadas, ya que serían muy difíciles de ejecutar
manualmente [6]. También se ha observado que las pruebas automatizadas son
ideales para reducir el riesgo de regresión (cuando código que ya existía es
modificado y, por ende, se vuelve vulnerable a nuevos errores) [6]. Por otro lado,
las pruebas manuales son preferibles para validar requerimientos de naturaleza
subjetiva o intangible, como la apariencia o el atractivo visual de una interfaz
gráfica [6]. Además se ha reportado que las pruebas manuales son adecuadas
para tratar de encontrar formas de quebrar una nueva funcionalidad [6]. De ahí
que los objetivos de las pruebas manuales difieren de los objetivos de las pruebas
automatizadas [6]. Esta diferencia debe ser considerada al decidir cuál tipo de
prueba ejecutar en cada situación. Otros factores a considerar cuando se está
eligiendo entre estos dos tipos de pruebas son [5, 6, 7]:
3 ● Compatibilidad con el sistema: es posible que la herramienta de
automatización no sea compatible con el software bajo prueba.
● Nivel de experiencia del ingeniero de calidad: si el ingeniero no tiene
experiencia con la herramienta de automatización, la calidad de las pruebas
puede ser inferior en comparación con las pruebas manuales.
● Reutilización de las pruebas: Como se mencionó antes, las pruebas
automatizadas suelen ser preferibles por la capacidad de realizar tareas
repetitivas. Si las pruebas no se pueden repetir o su repetición no es
necesaria, la automatización puede no ser necesaria.
● Costo de la herramienta: Algunas herramientas de automatización
requieren licencias de uso, que pueden ser un costo elevado. Esto se debe
contrastar con el beneficio que se espera obtener de las pruebas
automatizadas, para justificar la inversión.
● Políticas de la empresa: Dependiendo de la compañía, es posible que
existan restricciones sobre el ambiente de desarrollo o de pruebas, que
restrinjan la utilización de pruebas automatizadas. Por ejemplo, cuentas de
usuario, información confidencial (si la herramienta fue creada por una
compañía externa, es posible que por seguridad no se pueda usar), o
restricciones geográficas pueden impedir el funcionamiento de la
herramienta de automatización.
● Creación de reportes de prueba: Una prueba es tan valiosa como la
información que provee. Si el reporte de la prueba automatizada no
contiene la información necesaria para generar valor a la compañía, la
herramienta de automatización pierde valor. Por otro lado, si el reporte
automatizado es de utilidad, este es preferible al reporte manual debido al
tiempo que se ahorraría.
● Cantidad de scripting necesario: Para ejecutar la prueba automatizada, es
necesario crear instrucciones para que la herramienta de automatización
pueda ejecutarlas. Dependiendo de la herramienta, el tiempo necesario
4 para crear estas instrucciones puede variar, aumentando o disminuyendo la
inversión requerida.
Independientemente de la decisión que se tome respecto al tipo de pruebas
a utilizar, el objetivo de ambos tipos de pruebas es invariable: asegurar que el
software entregado sea de la mejor calidad posible para cumplir con las
expectativas del cliente y con las metas de calidad de la organización encargada
del sistema, dentro del tiempo y presupuesto planeados.
1.1 Justificación
Se estima que alrededor del 50% del costo de un proyecto es invertido en el
control de calidad [6]. Factores tales como un ambiente corporativo cada vez más
competitivo, el desarrollo ágil y los presupuestos limitados, agregan presión a la
fase de pruebas del software [6]. Es por esto que el desarrollo y la
comercialización de herramientas de automatización surge como una respuesta
para reducir los costos del software [6].
Sin embargo, existe amplia evidencia de que la automatización de todas las
pruebas de un proyecto de software puede ser contraproducente [7]. Entre las
razones más comunes están (i) la inversión inicial en el desarrollo de las pruebas
automatizadas y (ii) el mantenimiento de las pruebas automatizadas [6]. La
inversión inicial en el desarrollo de las pruebas automatizadas es típicamente alta
[6] por todo lo que ello implica: escoger el framework o herramientas de
automatización, entrenar al personal en su uso, configurar los ambientes de
pruebas, e implementar las pruebas propiamente. Si el presupuesto del proyecto
no contemplaba esta inversión, sería riesgoso usar el (poco) tiempo planeado para
las pruebas en automatizar, pues es posible que ni se logre la meta de
automatizar todo ni tampoco alcance el tiempo para hacer pruebas manuales, con
lo cual se pondría en riesgo la calidad del producto. Por otra parte, cualquier
5 cambio en el software bajo prueba puede impactar negativamente el conjunto de
pruebas automatizadas (es decir, es posible que algunas pruebas ya no funcionen,
o que fallen cuando deberían pasar), incurriendo en una inversión adicional de
tiempo y esfuerzo para actualizar o ajustar las pruebas ante el cambio realizado en
el software.
Varios estudios han determinado que la decisión de automatizar las
pruebas en un proyecto de software debe venir acompañada de un análisis de
costos y beneficios, que justifique la inversión de recursos [5, 6, 8, 9]. A partir de
este análisis, es posible que el negocio decida, por ejemplo, optar por pruebas
manuales si observa que las ganancias obtenidas de la automatización son
menores que las de las pruebas manuales [10]. Sin embargo, este análisis
depende en gran medida del contexto donde se vayan a ejecutar las pruebas.
Factores como la cultura organizacional, el entrenamiento del personal, la
disponibilidad de herramientas de automatización, e incluso la tendencia o rechazo
a la adopción de nuevas tecnologías o prácticas, pueden afectar el beneficio
obtenido por uno u otro tipo de pruebas [10, 11]. Precisamente la necesidad de
contar con un análisis de costos y beneficios en el contexto de la organización
bajo estudio fue lo que motivó la presente investigación, para determinar cuál tipo
de pruebas resulta más beneficiosa en su contexto específico.
1.2 Problema
La organización en la cual se realizó este estudio quería conocer cuál tipo
de pruebas le generaba un mayor retorno sobre la inversión, para hacer el control
de calidad de sus sistemas.
Dicha organización cuenta con 11 aseguradores de calidad (QA, por sus
siglas en inglés: Quality Assurance) y 73 desarrolladores de software distribuidos
en 5 equipos de desarrollo (estos equipos no incluyen ningún QA). Cada equipo
6 tiene entre 14 y 16 desarrolladores y se encarga como máximo de 4 proyectos. La
metodología de desarrollo que se utiliza es ágil. Si bien cada proyecto varía en
tamaño, se presupuesta un 30% del tiempo de implementación para la realización
de pruebas de software.
En esta organización, la selección y ejecución de pruebas manuales es de
carácter heurístico, ya que el QA las realiza según su nivel de experticia. Debido a
ello, es posible que dos QAs no realicen las mismas pruebas para el mismo
software. Similarmente, las pruebas automatizadas también tienen un carácter
heurístico, con la diferencia de que la ejecución de estas pruebas se hace por
medio de scripts que son ejecutados por una herramienta de automatización. La
herramienta de automatización fue creada a lo interno de la organización por un
departamento con 2 desarrolladores y 2 QAs (distinto al departamento donde se
realizó esta investigación). El desarrollo se completó a mediados del año 2015 y
actualmente recibe actualizaciones trimestrales, las cuales son realizadas por el
mismo departamento que creó la herramienta. A pesar de que esta herramienta
está a disposición de los QAs, la gran mayoría de las pruebas que se realizan
actualmente son manuales. Una de las razones es porque se desconoce si los
beneficios de la automatización superan los beneficios de la ejecución de pruebas
manuales y por lo tanto, no se ha invertido en el entrenamiento de los QAs. En la
actualidad, solo dos QAs cuentan con entrenamiento en la herramienta de
automatización. Fuera del departamento donde se realizó este estudio, la
herramienta de automatización no es utilizada con frecuencia ya que las pruebas
que se pueden realizar con la herramienta son específicas a ciertas aplicaciones,
por lo que muchos departamentos han decidido crear sus propias herramientas de
automatización para cumplir sus necesidades.
El sistema de software de la organización que se probó en esta
investigación fue desarrollado por quince desarrolladores de software y contaba
con un QA asignado a tiempo completo. Este sistema es un conjunto de
7 aplicaciones web que permiten a los usuarios llenar múltiples formularios para
exponer sus productos en una página de ventas por internet. Fue desarrollado en
el lenguaje Java 1.8, junto con otras tecnologías desarrolladas dentro de la
organización, para permitir la integración del sistema con las bases de datos
internas. En el resto del documento, nos referiremos a este sistema de software
bajo prueba como “SUT” (siglas en inglés de software under test).
El interés de la organización es conocer (y luego optimizar) el retorno sobre
la inversión de las pruebas que realizan los ingenieros de calidad. Si se conoce
cuál tipo de prueba (manual o automatizada) genera un mayor retorno de
inversión, el QA puede hacer un mejor uso de su tiempo y esfuerzo para
maximizar la calidad del SUT en el menor tiempo posible.
1.3. Objetivos
1.3.1 Objetivo general
El objetivo general de la investigación es comparar la efectividad de las pruebas automatizadas y manuales en términos del retorno sobre la inversión.
1.3.2 Objetivos específicos
1. Analizar la efectividad de un conjunto de pruebas manuales y
automatizadas.
2. Estimar el retorno sobre la inversión del conjunto de pruebas manuales y
automatizadas.
3. Realizar una comparación de la efectividad y el retorno sobre la inversión
entre las pruebas manuales y automatizadas.
8 Con el primer objetivo específico se busca determinar qué tan efectivo es
cada tipo de prueba (manual y automatizada) en encontrar errores.
El segundo objetivo busca estimar el retorno monetario sobre la inversión
realizada, para ambos tipos de pruebas (manuales y automatizadas). Para esto,
se debe elegir un modelo de costos y una fórmula que calcule el retorno sobre la
inversión (ROI), con base en métricas que estén disponibles en la organización.
Parte del cálculo del ROI incluye la información obtenida en el primer objetivo
específico.
El tercer objetivo busca comparar los resultados arrojados por los dos
primeros objetivos específicos, y analizar diferencias o similitudes encontradas con
ambos tipos de pruebas. El logro de este objetivo permitirá identificar cuál tipo de
prueba genera un mayor retorno sobre la inversión en el contexto bajo estudio.
Este documento está organizado de la siguiente manera. El capítulo 2
define un marco teórico para poder comprender el proceso y los resultados de la
investigación realizada. El capítulo 3 expone trabajos relacionados a la presente
investigación, en particular sobre la comparación entre pruebas manuales y
pruebas automatizadas. El capítulo 4 explica la metodología, particularmente los
casos de estudio que se realizaron y los datos que se recolectaron en cada uno.
En el capítulo 5 se presentan los resultados de los casos de estudio y un análisis
de los mismos para responder a las preguntas de investigación. Finalmente, el
capítulo 6 expone las conclusiones del trabajo y esboza posibles trabajos futuros
que se pueden derivar a partir de este estudio.
9
2. Marco Teórico
2.1 Aseguramiento de la calidad del software
Según el estándar IEEE 12207, el aseguramiento de la calidad del software
es un proceso para proveer una garantía adecuada de que los procesos y
productos del ciclo de vida del software se ajustan a sus requerimientos
específicos y se adhieren a los planes establecidos [12]. Es decir, el
aseguramiento de calidad consiste en ofrecer garantía y credibilidad: el producto
final debe funcionar correctamente y los usuarios deben creer que es así [13].
Dentro del aseguramiento de la calidad, es necesaria la creación de un plan
de pruebas de software que verifique que los requerimientos se cumplan
correctamente. Un plan de pruebas completo debe asegurar que el diseño del
software es adecuado, que la implementación es correcta y que el producto final
cumple con todas las expectativas planteadas al inicio del proyecto. Además, un
buen plan de pruebas debe verificar la calidad del software a través de todo su
ciclo de vida [13]. Para ello existen diferentes tipos de pruebas de software. A
continuación, se detallan las pruebas de software que son relevantes para esta
investigación.
2.2 Pruebas de software
Las pruebas de software son una serie de actividades conducidas por el QA
con la intención de encontrar errores en un sistema [14]. Existen varias
clasificaciones de pruebas de software, según su tipo, nivel y técnica de diseño.
En cuanto a tipos, se clasifican en: pruebas manuales o automatizadas, y también
en pruebas funcionales o no-funcionales. De acuerdo al nivel, se pueden clasificar
en pruebas unitarias, de integración, de sistema y de aceptación. Según la técnica
10 de diseño, se dividen en dos grandes categorías: pruebas de caja negra y de caja
blanca [15].
2.2.1 Tipos de pruebas
Como mencionamos anteriormente, existen varios tipos de pruebas. En
primer lugar, se distinguen las pruebas manuales de las automatizadas, según sea
la ejecución de las mismas. En segundo lugar, se diferencian las pruebas
funcionales de las no-funcionales, según el aspecto (o requerimiento) que evalúen
del sistema. Dado que estas clasificaciones son independientes, se pueden dar
todas las combinaciones posibles; por ejemplo, una prueba puede ser funcional y
manual, o funcional y automatizada, o no-funcional y manual. La decisión de cuál
tipo de prueba utilizar se toma cuando se crea el plan de pruebas. Este plan lo
hace el encargado de pruebas (QA) y allí define qué pruebas deben ejecutarse
para verificar y validar la completitud y correctitud del SUT, entre otros aspectos,
con el fin de que el producto liberado cumpla con las expectativas establecidas por
el negocio y el cliente. Por lo tanto, es de vital importancia que el QA tenga un
claro entendimiento del objetivo del sistema y sus requerimientos [9]. Es común
que un plan de pruebas combine varios tipos de pruebas. A continuación se
explica con más detalle cuáles tipos de pruebas existen.
Pruebas manuales
Las pruebas manuales son aquellas que ejecuta una persona
(generalmente el QA) de forma manual sobre el software [9]. El QA, por lo tanto,
tiene como una de sus tareas ejecutar el rol del usuario final, utilizando la
aplicación como la usaría cualquier otra persona. Esto con el fin de encontrar
errores en el flujo normal del software. Además, otra de sus tareas es verificar
manualmente que el SUT no se pueda usar de manera incorrecta, y para ello debe
tratar de usar la aplicación de formas que no sean las intencionadas, para verificar
su comportamiento. Por ejemplo, en una aplicación bancaria para transferencias
monetarias, es tan importante que un usuario pueda hacer una transferencia de su
11 cuenta a otra, como lo es que un usuario no autorizado no pueda hacer
transferencias. En este caso, el QA debería probar ambos casos para validar que
el comportamiento de la aplicación sea el esperado en ambas situaciones.
Pruebas automatizadas
Las pruebas automatizadas, al contrario de las manuales, son ejecutadas
por una computadora de manera automática (sin intervención humana). Para esto
se utilizan herramientas de automatización especializadas que permiten crear
scripts de pruebas [10]. Un script contiene las instrucciones necesarias para que la
prueba pueda ejecutarse automáticamente [10]. Típicamente un script puede
“personalizarse” para que las pruebas se ejecuten con datos específicos de interés
[10]. Incluso algunas herramientas de automatización permiten grabar la
interacción del QA con el software bajo prueba, y generar un script a partir de
dicha interacción. Las pruebas automatizadas pueden comparar el
comportamiento esperado del software bajo prueba con el comportamiento real, y
reportar cualquier diferencia encontrada como un posible error [10].
Pruebas funcionales
Las pruebas funcionales intentan verificar si hay discrepancia entre el
software y su especificación (descripción precisa del comportamiento del software
desde la perspectiva del usuario final).
Pruebas no-funcionales
Las pruebas no-funcionales verifican los requerimientos no-funcionales del
sistema. Algunos ejemplos de pruebas no-funcionales son: pruebas de carga,
volumen, rendimiento, seguridad, usabilidad, accesibilidad, compatibilidad,
localización, globalización, configuración, instalación y recuperación [16]. A
continuación, se explican las pruebas no-funcionales usadas en esta investigación.
12 Pruebas de localización
Las pruebas de localización consisten en verificar que la interfaz gráfica del
SUT sea capaz de adaptarse a distintos idiomas, es decir, que las traducciones
sean visibles y correctas. Además, la experiencia del usuario no debería verse
afectada por el idioma que seleccione. Sin embargo, dependiendo de ciertas
restricciones legales en algunos países, es posible que dentro de los
requerimientos existan diferencias en la experiencia del usuario dependiendo de
su ubicación geográfica [15].
Pruebas de seguridad
Las pruebas de seguridad pretenden revelar vulnerabilidades del software
que puedan impactar los datos que maneja e, incluso, la funcionalidad de todo el
sistema [17]. Estas pruebas se han vuelto de mucho interés para las grandes
compañías debido al riesgo que enfrentan si son víctimas de un ataque. Para citar
solo un ejemplo, un ataque en el año 2015 sustrajo alrededor de mil millones de
dólares de cientos de bancos alrededor del mundo [18], a causa de una
vulnerabilidad explotada en el software bancario.
2.2.2 Niveles de pruebas
Las pruebas de software típicamente se llevan a cabo a diferentes niveles
con distintos propósitos: unidad, integración, sistema y aceptación [19], [20]. A
continuación, se describe cada uno de estos niveles.
Pruebas unitarias
Las pruebas unitarias consisten en dividir el código de una aplicación en
unidades independientes y pequeñas, con el fin de validar cada una por aparte
[10]. Las pruebas unitarias por sí solas no son suficientes para garantizar la
calidad del software [10], de ahí que existan otros niveles superiores. Una ventaja
muy importante de las pruebas unitarias es que se pueden ejecutar tan pronto
13 como la unidad de código a probar esté lista [10], sin tener que esperar a que
todas las demás unidades estén implementadas. Sin embargo, el mayor problema
de las pruebas unitarias es que no validan la interacción que hay entre las
diferentes unidades que componen el sistema, de manera que podrían dejar pasar
errores de integración en el código [10].
Pruebas de integración
Las pruebas de integración consisten en combinar y probar componentes
de software, de hardware, o ambos, para evaluar su interacción [21]. En este tipo
de pruebas se verifica la compatibilidad entre los componentes o módulos,
enfocándose en buscar potenciales problemas a nivel de interfaz entre módulos
[22]. Para facilitar el nivel de pruebas de integración, es recomendable que los
componentes o módulos a integrar hayan pasado previamente por el nivel de
pruebas unitarias [20].
Pruebas de sistema
Las pruebas de sistema se conducen sobre un sistema completo e
integrado, con el fin de evaluar si el sistema cumple con los requerimientos
especificados [21]. Este nivel de pruebas verifica el comportamiento de todo el
sistema con respecto a su especificación [22]. Las pruebas de sistemas se
realizan después de las pruebas de integración, y deben comprobar tanto las
características funcionales como los no-funcionales del sistema.
Pruebas de aceptación
Las pruebas de aceptación de usuario son pruebas que permiten al cliente
determinar si acepta el sistema [21]. Este nivel de pruebas mide la calidad del
sistema y en función de ello determina si el sistema cumple las expectativas de los
usuarios [23] [16].
14 2.2.3 Técnicas de diseño de pruebas
Las técnicas de diseño de pruebas sirven para diseñar y seleccionar el
conjunto de casos de prueba a utilizar. Estas técnicas se agrupan en dos grandes
enfoques: el de caja blanca y el de caja negra [24].
Enfoque de caja blanca
El enfoque de caja blanca analiza la lógica y la estructura interna del
software a probar, por lo tanto es necesario que su código fuente esté disponible
al QA [14] [24]. Las pruebas diseñadas bajo este enfoque típicamente se
consideran bastante efectivas para encontrar errores en el software [14]. Sin
embargo, este enfoque puede no ser el más apropiado en ciertos contextos,
debido a que requiere una gran inversión de tiempo para poder analizar todo el
código escrito en la fase de implementación [14]. Además, cabe destacar que para
poder realizar adecuadamente pruebas de caja blanca, el QA debe tener un buen
conocimiento del lenguaje en el que se desarrolló el software bajo prueba, pues de
lo contrario podría impactar negativamente la calidad de la validación [14, 2].
Enfoque de caja negra
El enfoque de caja negra se centra en examinar el comportamiento externo
del sistema (sus entradas y salidas), sin preocuparse de cómo está diseñado o
implementado internamente [15] [23]. Partiendo de la especificación de
requerimientos formulada en las fases iniciales del ciclo de vida del software, el
QA infiere lo que el SUT debe y no debe hacer, y usa esta información para
confeccionar pruebas que verifican si el software cumple con el comportamiento
esperado [15] [23]. Algunos ejemplos de estrategias de diseño bajo el enfoque de
caja negra son: partición en clases de equivalencia, análisis de valores frontera,
análisis causa-efecto y pruebas combinatorias [23]. A continuación, se explican las
pruebas de caja negra utilizadas en esta investigación.
15 Pruebas de Valor Frontera
Las pruebas de valor frontera se enfocan en probar el sistema con valores
que están en los bordes (o sus cercanías) que delimitan las clases de equivalencia
[19] [25]. La razón de escoger estos valores de frontera es porque ahí es donde
más errores se esconden [19].
Supóngase que existe una funcionalidad del software que espera una
variable X de entrada. Además, supóngase que los posibles valores de esta
variable están dentro de un rango definido, A ≤ X ≤ B, como ilustra la Figura 1. Los
valores A y B delimitan los valores permitidos y no-permitidos para la variable X.
Figura 1. Ilustración del dominio de valores aceptables para una entrada [15].
Las pruebas de valor frontera prueban, entonces, valores que se
encuentran en o cerca de los límites de valores permitidos por el sistema, tal como
se muestra en la Figura 2.
16
Figura 2. Ilustración del dominio de valores frontera para una entrada [15].
La motivación para este tipo de análisis es que los errores tienen a suceder
cerca de las extremidades de los dominios de las entradas [25]. Además, la razón
por la que se estudia solo una entrada a la vez en lugar de analizar varias
entradas al mismo tiempo es por la suposición del error singular, la cual afirma que
estadísticamente los fallos en una aplicación rara vez suceden por la ocurrencia
de dos o más errores a la vez [25].
Pruebas Combinatorias
Un problema fundamental en el área de pruebas de software es la dificultad
para probar todas las posibles combinaciones de entradas que acepta el software
[26]. Por ejemplo, para una aplicación que tiene 10 posibles entradas en un
formulario, cada una con dos posibles valores (por ejemplo, una casilla de
selección estilo ‘check’), se necesitarían 1024 pruebas para verificar todas las
posibles combinaciones de sus 10 entradas. Normalmente, las aplicaciones que
se prueban hoy en día son mucho más complejas que la del ejemplo, de manera
que la cantidad de combinaciones de valores de entrada es prohibitiva en términos
prácticos. Para solucionar este problema, las pruebas combinatorias se basan en
estadística para diseñar pruebas que cubran la mayor cantidad posible de
combinaciones sin necesidad de mucho esfuerzo.
El uso de matrices ortogonales permite simplificar la validación de múltiples
combinaciones de entradas en una sola prueba. Supóngase que existe un sistema
17 que tiene tres interruptores, donde cada interruptor sólo puede estar encendido o
apagado. Si se fuese a validar cada combinación por aparte, se necesitarían 8
pruebas, como se muestra en la Figura 3. Sin embargo, usando una matriz
ortogonal solo necesitan probar 4 combinaciones, como se muestra en la Figura 4.
Para llegar a esas combinaciones de la matriz ortogonal, se dividen los estados de
los interruptores en parejas, donde cada interruptor se prueba con uno de los otros
dos, es decir (I1, I2), (I1, I3), e (I2, I3). Cada par de interruptores puede estar en
uno de estos estados: (0,0), (0,1), (1,0), o (1.1). Como hay 3 posibles pares de
interruptores y cada par puede estar en uno de 4 estados, se ocuparían un total de
12 combinaciones, pero como en cada iteración podemos probar los tres
interruptores al mismo tiempo, la cantidad de combinaciones a probar se reduce.
Este ejemplo es suficientemente trivial para manualmente encontrar las
combinaciones correctas, sin embargo, conforme se agregan variables, encontrar
las combinaciones se vuelve más complicado y en esos casos es mejor recurrir a
una herramienta que encuentre las combinaciones necesarias [15].
Figura 3. Todas las combinaciones para tres variables de encendido/apagado [26].
Figura 4. Matriz ortogonal para tres variables de encendido/apagado [26].
18
La ventaja de esta metodología radica en que disminuye la cantidad de
pruebas a realizar (respecto al enfoque exhaustivo). Sin embargo, conforme se
agregan más variables, encontrar una matriz que cubra adecuadamente la
funcionalidad del sistema se vuelve cada vez más complejo [26].
2.3 Retorno sobre la inversión (ROI)
Como se mencionó antes, la decisión de usar pruebas automatizadas o
pruebas manuales debe estar precedida por un análisis que justifique su uso. Si
bien ambos tipos de pruebas tienen como objetivo detectar errores, la inversión
y/o el beneficio obtenido puede variar. En un escenario ideal, la organización
escogería el tipo de prueba que le genere el mayor beneficio (ganancia) con la
menor inversión. Esta proporción ganancia-inversión es conocida como el retorno
sobre la inversión [27]. Este cálculo es muy útil a la hora de comparar dos o más
aproximaciones a un problema en términos de cuánto dinero le generó o le ahorró
cada una a la organización. Esta métrica es de particular interés en nuestra
investigación, ya que se usa para comparar el retorno obtenido al realizar pruebas
manuales y automatizadas, y poder responder cuál es más rentable según los
casos de estudio planteados en el contexto de la organización.
Un método muy utilizado para calcular el ROI [27], que compara los ahorros
(en lugar de las ganacias) contra la inversión, es el siguiente:
ROI = !"#$"#%&"''()"#*+,-.'#/ó,+,-.'#/ó,
Por ejemplo, supongamos que un proyecto costaba inicialmente $1000,
pero al aplicar una nueva tecnología, su costo fue $900 (se ahorraron $100), y la
19 inversión necesaria para aplicar la nueva tecnología fue de $10. En este caso, el
ROI se calcularía así: 122*12
12= 9.
Esto implica un retorno sobre la inversión del 900%.
En el contexto de nuestro estudio, fue necesario determinar cómo se
calcularía el beneficio (o ahorro, según el modelo anterior) y la inversión de cada
tipo de prueba. Después de analizar varias opciones, se decidió calcular el ahorro
total como la suma del ahorro obtenido por cada error detectado en la fase de
pruebas. El ahorro obtenido por un error detectado en la fase de pruebas se
estimó como el costo asociado a la severidad del error. Esta fórmula aplica para
ambos tipos de pruebas, ya que depende solo de la severidad de los errores
detectados. Por otra parte, la inversión se calculó como la cantidad de horas que
le tomó al QA hacer las pruebas multiplicada por el costo de la hora del QA en la
organización.
Por ejemplo, si las pruebas automatizadas detectan 2 errores de severidad
1 (con un costo de $150 por error), 5 errores de severidad 2 (con un costo de $100
por error), 2 errores de severidad 3 (con un costo de $75 por error), y 2 errores de
severidad 5 (con un costo de $25 por error), el ahorro se calcula como la suma de
$300+$500+$150*$50 para un total de $1000 ahorrados en errores detectados
antes de la liberación del software. Además, si al QA le toma 6 horas ejecutar
todas las pruebas, considerando que el costo de la hora del QA es $20 [8], la
inversión se calcula como $20*6 = $120. Entonces, para este ejemplo, el retorno
sobre la inversión en el contexto de la organización sería:
456%= !"#$"#%&"''()"#*+,-.'#/ó,+,-.'#/ó,
20
=1222*172172
= 882172
= 7.33
Es decir, el retorno sobre la inversión sería de un 733%.
21
3. Trabajo relacionado
La automatización de las pruebas ha sido propuesta como una solución
para reducir los costos de la fase de pruebas, que suelen abarcar más del 50% del
costo de un proyecto [6]. Otros investigadores se han dedicado a analizar los
beneficios de las pruebas automatizadas en comparación con las pruebas
manuales, y cómo balancear los costos en los que incurre cada una con tal de
obtener una respuesta que ayude a determinar cuándo optar por la automatización
y cuándo optar por las pruebas manuales con tal de obtener el mayor retorno
sobre la inversión realizada. A continuación, se exponen algunas de estas
investigaciones.
En su estudio, Ramler et al. [6] proponen un modelo de optimización para
determinar cuándo utilizar la automatización basado en optimización lineal al
introducir el concepto de costo de oportunidad. El costo de oportunidad incurrido
en una automatización está determinado por el beneficio perdido al no ejecutar las
pruebas manualmente [6]. Sin embargo, en su investigación se destaca que existe
una diferencia importante entre las pruebas manuales y las automatizadas; debido
a que el costo de ejecutar una prueba automatizada es negligentemente bajo ya
que la realización de las mismas no requiere de un humano, el verdadero costo de
las pruebas automatizadas se da por el número de casos de prueba que se
pueden correr. En contraste, debido a la necesidad de una persona, el costo de
las pruebas manuales se da por el número de pruebas realizadas ya que cada
ejecución trae consigo el costo de tener al QA corriendo la prueba [6].
El estudio continúa identificando factores que se deben considerar a la hora
de decidir qué tipo de prueba es más beneficioso. Por ejemplo, existen pruebas
que solamente pueden ejecutarse de manera automatizada, como lo son las
pruebas de esfuerzo y de carga [6]. Si se requieren de mil pruebas concurrentes
para simular la carga a la que se puede exponer el sistema, es irreal esperar que
22 una persona pueda hacer esta simulación. En su lugar, una automatización puede
fácilmente completar la simulación. Otro factor es el cambio de la productividad en
el tiempo [6]. Por ejemplo, los autores encontraron que conforme se utilizaban
herramientas de automatización, la curva de aprendizaje de las mismas se reducía
y la productividad aumentaba en proporción inversa a esta. Además, se debe
considerar el esfuerzo que probar un sistema en un ambiente de desarrollo
iterativo [6]. Cada cambio incremental aumenta la cantidad de pruebas que hace
falta realizar. Esto impacta tanto las pruebas manuales como las automatizadas ya
que por un lado, implica más pruebas que el QA debe hacer a mano, o en
contraste, modificar los scripts de automatización para adaptarse a los nuevos
cambios. Sin embargo, los scripts también pueden volverse inmantenibles, y los
QAs pueden perder más tiempo tratando de reparar un script dañando que de
hecho ejecutando la prueba manualmente.
En un estudio similar, Berner et. al. [28] observaron que muy a menudo, las
automatizaciones tienen sentido sólo si se les usa a menudo ya que esto
promueve a darle mantenimiento a los scripts. De lo contrario, los scripts se
desactualizan al punto en el que repararlos tomaría tanto tiempo como crear un
script nuevo, por lo que eleva el costo de la automatización. Además, se observó
que un requerimiento que a menudo se omite es la capacidad de poder probar
algo. Si un caso de uso no es fácilmente verificable de manera manual, muy
probablemente no sea más sencillo probarlo de manera automatizada. Por otro
lado, se observó que el verdadero valor de las pruebas automatizadas se da
cuando las pruebas deben ejecutarse repetidamente, especialmente en el
desarrollo iterativo. Esto aunado a que la frecuencia con la que se deben repetir
las pruebas suele ser muy alto [28] justifica la automatización de pruebas
repetitivas como una solución al costo elevado de las pruebas de software. Sin
embargo, se observó que hay escenarios donde no existe un valor agregado al
automatizar una prueba. Una prueba automatizada revalida una unidad bajo
verificación, pero no es capaz de sustituir a un QA que puede conocer las
23 deficiencias del equipo de desarrollo y utilizar ese conocimiento para encontrar
errores en el sistema [28]. Es decir, un QA capacitado es capaz de encontrar
errores que una herramienta de automatización no puede encontrar. En este
aspecto, las pruebas automatizadas son constructivas, mientras que un QA debe
siempre tratar de tomar una postura destructiva hacia el software que está
probando. Por esto, los autores opinan que un buen sistema de pruebas
automatizadas es aquel que releva al QA de las actividades tediosas y repetitivas
para permitirle encontrar nuevos enfoques y maneras de probar el software con el
fin de encontrarle más defectos [28].
En su estudio, Sharma [29] realiza un análisis cuantitativo comparando
pruebas manuales con pruebas automatizadas al proponer métricas que ayuden a
cuantificar el desempeño de ambas metodologías. En este estudio, se proponen
métricas tales como:
a) Productividad de creación: Cuántos casos de prueba fueron creados en un
tiempo determinado.
b) Productividad de ejecución: Cuántos casos de prueba fueron ejecutados en
un tiempo determinado.
c) Aceptación de defectos: Cuántos errores encontrados por las pruebas
fueron errores reales y no falsas alarmas.
d) Rechazo de defectos: Cuántos errores encontrados por las pruebas fueron
falsas alarmas y no errores reales.
e) Productividad de arreglo: Cuántos errores arreglados por un desarrollador
resurgieron posterior a su arreglo.
f) Cobertura de código: Cuál fue el porcentaje de código cubierto por las
pruebas
g) Comparación de costos: Cuál fue el costo de realizar las pruebas,
determinado por el tiempo dedicado por el QA y el costo del salario por hora
del QA.
24 El estudio concluyó que la inversión de tiempo varía significativamente en
ambos tipos de prueba; en la automatización, la inversión de tiempo es mucho
mayor durante la creación de las pruebas en comparación con las pruebas
manuales [29]. Sin embargo, la capacidad de ejecutar las pruebas automatizadas
en ejecuciones posteriores implica una inversión de tiempo mucho menor en
comparación con las pruebas manuales. En otras palabras, las pruebas
automatizadas son más costosas al inicio de la fase de pruebas, pero ven un
ahorro significativo en la ejecución regresiva de pruebas, mientras que el inverso
es observable en las pruebas manuales. Sin embargo, el mismo estudio encontró
que dependiendo del caso, es posible que no todas las pruebas se puedan
automatizar, o cuya automatización implica un costo tan elevado que supera los
beneficios obtenidos en el ahorro del tiempo proveniente de la regresión de
pruebas [29]. El autor concluye que la realización de un análisis que permita
determinar cuáles pruebas pueden ser automatizadas permite maximizar los
beneficios obtenidos durante la fase de pruebas de software, y propone sus
métricas como una base para la realización de dicho análisis [29]. Sin embargo,
los resultados de las métricas deben aplicarse dentro de un contexto definido, ya
que existen factores variables que pueden alterar significativamente los
resultados, como el nivel de experiencia en los QAs, o la complejidad del software
bajo escrutinio.
En su estudio, Hoffman [30] también propone métricas para obtener un
análisis del costo-beneficio de la automatización. Sin embargo, en ese mismo
estudio, el autor presenta varios factores no cuantificables que deben tomarse en
cuenta durante la realización de un análisis a pesar de que no puedan introducirse
en el cálculo del retorno sobre la inversión. Entre los factores que el autor
menciona, se encuentran:
a) Testing sin supervisión: El valor de la ejecución de pruebas automatizadas
sin la necesidad de la intervención de una persona. Si bien el costo de tener
25 una persona dedicada es cuantificable, no hay forma de cuantificar el
beneficio (o costo) del control computarizado de las pruebas.
b) Expansión hacia pruebas avanzadas: Al no necesitar al QA para ejecutar
las pruebas, el QA puede dedicarse a encontrar otros errores o incluso, a
desarrollar pruebas más robustas.
c) Rechazo al cambio: No todos los miembros de una organización van a estar
de acuerdo con una metodología automatizada.
d) Calidad de las pruebas: Los miembros de una organización pueden
volverse más eficientes en la forma de desarrollar sus pruebas, o al
contrario, depender mucho de la automatización, lo que puede disminuir la
confiabilidad de las pruebas.
El autor también deja clara la importancia de no establecer expectativas
inalcanzables [30]. Por ejemplo:
a) Todas las pruebas se pueden automatizar. Esto no puede ni debe hacerse
por lo mencionado en los estudios anteriores.
b) Los beneficios de la automatización se percibirán inmediatamente. Esto no
necesariamente es cierto ya que el mayor valor de la automatización se ve
en la fase de regresión, que usualmente viene en las últimas etapas de un
proyecto.
c) No hay curva de aprendizaje. Esto no siempre es cierto debido a que puede
haber una falta de conocimiento por parte de los QAs. No todas las
herramientas de automatización son iguales, y probablemente haya una
etapa de aprendizaje antes de que un QA se vuelva eficiente en el uso de la
automatización.
d) Una herramienta de automatización es suficiente. A menudo una
herramienta no va a ser capaz de correr todo tipo de pruebas. Es razonable
pensar que la combinación de más de una herramienta permita una mejor
26 cobertura que tratar de forzar una herramienta para todos los casos de
prueba.
Al igual que en los estudios antes mencionados, el autor concluye que es
preciso un análisis que ayude a tomar la decisión sobre cuáles pruebas pueden
ser automatizadas para maximizar los beneficios obtenidos por las pruebas
automatizadas [30].
27
4. Diseño de los casos de estudio Para esta investigación se utilizó un conjunto de casos de estudio para
lograr cumplir los objetivos propuestos en la sección 1.3. Se realizan varios casos
de estudio debido a que existen múltiples variables que deben tomarse en
consideración, por lo que en cada caso de estudio se alteran estas variables de
distintas maneras y se observan los efectos de estas variaciones en los resultados
de cada caso de uso.
A continuación, se explica en detalle el diseño de los casos de estudio utilizados
en esta investigación.
4.1 Preguntas de investigación Para alcanzar los objetivos específicos, se plantearon las siguientes
preguntas de investigación:
RQ1. ¿Cuál tipo de prueba requiere la menor inversión?
RQ2. ¿Cuál tipo de prueba encuentra más errores en un tiempo determinado?
RQ3. ¿Cuál tipo de prueba es más efectivo en detección de errores?
RQ4. ¿Hay alguna clase de error que sea más fácilmente detectable con uno de
los tipos de prueba?
RQ5. ¿Cuál tipo de prueba obtiene una mejor cobertura de código?
4.2 Selección de roles y datos
Los roles que se necesitarán para la realización de los casos de estudio son
los siguientes:
1. QA automatizador: encargado de ejecutar las pruebas automatizadas. El
QA automatizador debe tener el mismo entrenamiento que el QA manual en
28 el uso de la herramienta de automatización de las pruebas. Tiene además
la responsabilidad de recolectar las métricas de interés sobre las pruebas
automatizadas. Cabe mencionar que este rol lo desempeñó el autor de la
presente investigación.
2. QA manual: encargado de ejecutar las pruebas manuales. El QA manual
debe contar con experiencia previa en la realización de pruebas manuales
dentro de la organización. Tiene además la responsabilidad de recolectar
las métricas de interés sobre las pruebas manuales.
3. Desarrollador: se encarga de arreglar los errores encontrados por las
pruebas. Además, tiene la responsabilidad de liberar el código al ambiente
de producción de la organización.
La selección de los casos de prueba utilizados en todos excepto uno de los
casos de estudio, se realizó de manera aleatoria sobre una batería de pruebas
previamente creada. Esta batería de pruebas fue creada conjuntamente por el
equipo de desarrollo y el QA manual (asignado al proyecto), con base en los
requerimientos y los casos de uso de las distintas aplicaciones a probar. Las
pruebas de la batería se clasificaban en:
1. Pruebas combinatorias: estas pruebas consisten en probar el SUT con
distintos exploradores de Internet o distintas configuraciones de la cuenta
de usuario. Por ejemplo, probar cierto botón solo si un valor específico fue
seleccionado en otro campo.
2. Pruebas de localización: estas pruebas consisten en validar que todo el
texto visible al usuario esté adecuadamente traducido. Esta prueba se hace
cambiando el lenguaje de preferencia en la cuenta de usuario y verificando
que todo el texto aparezca traducido. (En caso de no estar traducido, el
texto aparece en inglés.)
3. Pruebas de seguridad: estas pruebas consisten en hacer ataques al SUT.
Por ejemplo, escribir instrucciones Javascript en campos de texto para
29 intentar un ataque de cross-site scripting, o bien, una instrucción SQL para
intentar un ataque de SQL injection.
4. Pruebas de valores frontera: estas pruebas se realizan sobre campos de
texto para verificar la existencia de validaciones de dominio. Por ejemplo,
tratar de poner letras en un campo que solo debería aceptar números, o
tratar de poner un texto aleatorio donde se espera un correo electrónico.
4.3 Caso de estudio múltiple
Para responder a las preguntas de investigación, se optó por hacer un
diseño de casos múltiples. En particular, se realizaron tres casos de estudio con
distintos objetivos, pero cuyos resultados se usaron de manera conjunta para
responder las preguntas de investigación dentro de un mismo contexto [31]: la
organización bajo estudio. Más adelante se explica cada uno de los casos de
estudio realizados.
El objeto estudiado fue la efectividad de las pruebas automatizadas y
manuales, en términos de cinco variables:
1. Costo ahorrado (derivado de la cantidad de errores encontrados y el costo
monetario asociado a la severidad de los mismos)
2. Inversión (derivado del tiempo invertido por el QA en completar las pruebas
y el salario por hora del QA)
3. Cobertura de código
4. Desempeño
5. Retorno sobre la inversión [11]
Las primeras dos variables son utilizadas para calcular el retorno sobre la
inversión. Sin embargo, la cobertura de código y el desempeño no fueron
incorporadas al cálculo del ROI debido a que su efecto es más indirecto y no
30 fácilmente combinable con las otras dos variables. A pesar de ello, estas métricas
son de interés en el análisis de la eficiencia. El ROI se calculará utilizando
solamente el costo ahorrado y la inversión. Además, la inversión considerada para
el ROI no incluye el tiempo de entrenamiento para utilizar la herramienta de
automatización debido a que el tiempo puede variar dependiendo de la persona
que lo lleve, y actualmente no hay suficientes datos históricos para incorporar un
promedio en la duración del entrenamiento dentro de este cálculo. Por otro lado, la
inversión asociada a la creación de la herramienta de automatización tampoco se
consideró ya que fue creada por un departamento distinto al departamento en el
que se realizó esta investigación, por lo que esos datos no se pudieron adquirir.
En cada caso de estudio, se registró el tiempo necesario para crear scripts
(en el caso de pruebas automatizadas), ejecución de pruebas, creación de reporte
(en el caso de pruebas manuales), así como los errores encontrados con su
severidad asociada. De igual manera, se registró el porcentaje de cobertura de
código obtenido en ambos tipos de pruebas. A la vez, se registraron los
verdaderos positivos y negativos, y falsos positivos y negativos encontrados en las
pruebas automatizadas. Por último, se realizó un análisis del retorno sobre la
inversión obtenido en cada caso de estudio.
En la Figura 5 se observa la estructura general de los casos de estudio. En
primer lugar, se tiene un conjunto o pool de todos los casos de prueba necesarios
para validar toda la aplicación bajo pruebas. Luego, se procede a seleccionar
aleatoriamente un conjunto de casos de prueba. Posteriormente se seleccionan
los datos que se usarán para correr las pruebas. Una vez definido esto, se
procede a ejecutar las pruebas. Por último, se genera un reporte con los
hallazgos.
31
Figura 5. Estructura general de los casos de estudio
Seguidamente describimos cada caso de estudio realizado y la variación
que tuvo respecto a la estructura general de la Figura 5.
4.3.1 Primer caso
El objetivo del primer caso de estudio fue determinar si había alguna diferencia en
la inversión requerida por cada tipo de prueba, manteniendo constante el conjunto
de datos de prueba y casos de prueba. Con los resultados de este caso de estudio
se buscaba responder la primera y tercera preguntas de investigación (RQ1 y
RQ3).
32 La Figura 6 muestra la estructura específica del primer caso de estudio.
Primeramente, se seleccionó un conjunto de casos de prueba de forma aleatoria.
El QA automatizador y el QA manual decidieron conjuntamente cuáles datos de
prueba iban a usar en cada caso de prueba, con el fin de controlar que se usaran
los mismos datos de prueba en ambos tipos de prueba. A partir de este punto, hay
cambios a la estructura general del caso de estudio, pues la ejecución de los
casos de prueba varía dependiendo del tipo de prueba: manual o automatizada.
Por último, se procede a la generación del reporte, donde también se modifica la
estructura general del caso. De manera automatizada, el reporte es provisto por la
herramienta de automatización, mientras que para las pruebas manuales el QA lo
genera a mano con sus hallazgos.
Figura 6. Estructura del primer caso de estudio.
33 4.3.2 Segundo caso
El objetivo del segundo caso de estudio fue determinar la cantidad y el tipo de
errores (en términos de su severidad) encontrados por cada tipo de prueba. Con
este caso de estudio se buscaba responder la segunda, tercera, cuarta y quinta
preguntas de investigación (RQ2, RQ3, RQ4 y RQ5).
La Figura 7 muestra la estructura específica del segundo caso de estudio.
Se inició seleccionando aleatoriamente un nuevo conjunto de casos de prueba (de
la batería de pruebas existente, que no hubiesen sido ejecutados ya). A diferencia
del primer caso de estudio (y de la estructura general del caso de estudio de la
Figura 5), se dejó a discreción de cada QA qué datos de prueba usar, de manera
que no se controló que los datos de prueba fueran los mismos para ambos tipos
de prueba. Se dio a cada QA un total de ocho horas (un día laboral) para ejecutar
tantas pruebas (del conjunto seleccionado inicialmente) como le fuera posible. El
proceso de ejecución de las pruebas fue igual al del primer caso de estudio.
34
Figura 7. Estructura del segundo caso de estudio.
4.3.3 Tercer caso
El tercer caso de estudio se realizó después de que el SUT se liberara al ambiente
de producción de la organización. El objetivo de este caso fue determinar si hubo
errores en producción (después de la liberación del SUT) que no fueron
detectados durante la fase de pruebas. Además, otro propósito fue evaluar la
capacidad de detección de errores al haber cambios incrementales en el SUT (i.e.,
errores de regresión), para ambas metodologías. Con este caso de estudio se
buscaba responder la tercera y quinta preguntas de investigación (RQ3 y RQ5).
35 La Figura 8 muestra la estructura específica utilizada en el tercer caso de
estudio. En este caso se corrieron pruebas de regresión manuales y
automatizadas (como parte del proceso de aseguramiento de calidad) para todo
cambio incremental semanal del SUT. Cabe destacar que durante las pruebas
automatizadas se ejecutaron todos los scripts que fueron creados como parte de
la realización de los primeros dos casos de estudio mencionados anteriormente.
Se registró el tiempo que tomó realizar las pruebas de regresión manuales y
automatizadas. Cuando no existía un script automatizado para probar un cambio
incremental, se registró el tiempo requerido para crear un nuevo script que
ejecutase la prueba automatizada. Este caso de estudio abarcó tres iteraciones de
cambios incrementales. Se calculó el retorno sobre la inversión obtenido en cada
iteración, tanto para las pruebas manuales como para las automatizadas.
36
Figura 8. Estructura del tercer caso de estudio.
4.3.4 Recolección de datos
Basándose en Lethbridge et al. [32], nuestra técnica de recolección de
datos se clasifica como observación de primer grado con alta interacción, debido a
que el investigador tiene contacto directo con los datos recolectados en tiempo
real, así como contacto directo con las pruebas mismas por su responsabilidad de
ejecutar las pruebas automatizadas. La ventaja de esta técnica es que le permite
37 al investigador controlar la forma en la que los datos están siendo recolectados y
reportar cualquier hallazgo de manera útil para el estudio de forma inmediata.
Para efectos de recolección de datos, cada dato de prueba se consideró
“una prueba”, aunque procediera originariamente del mismo caso de prueba. Es
decir, si un mismo caso de prueba se ejecutaba 5 veces con valores frontera
distintos o combinaciones distintas, cada una de esas 5 ejecuciones fue
contabilizada (cada una se consideró como una prueba “distinta”). Por otro lado,
cada error encontrado se contó solo una vez si más de una prueba lo detectaba.
Por ejemplo, si durante la ejecución de una prueba combinatoria se detectaba el
mismo error en cada prueba, dicho error se contabilizaba sólo una vez.
Para cada caso de estudio se recolectaron las siguientes métricas (la
mayoría aplican tanto para pruebas automatizadas como para pruebas manuales -
las excepciones se indican expresamente):
A. Cantidad de pruebas ejecutadas: suma total de las pruebas ejecutadas.
B. Cantidad de errores: suma total de los errores detectados por las pruebas
de manera intencional. Cualquier error encontrado sin intención no contó
dentro de este cálculo. Es decir, los únicos errores contabilizados fueron
aquellos que se pretendía encontrar con la ejecución de la prueba. Los
errores que se encontraron por accidente no se contabilizaron en la suma
de errores, pero sí se anotaron para su posterior corrección.
C. Cobertura de código: corresponde al porcentaje de líneas de código (del
SUT) que fueron ejercitadas por las pruebas. Para las pruebas
automatizadas, esta información se extrajo directamente de la herramienta
de automatización, que computaba la cobertura de forma automática. Para
las pruebas manuales, el cálculo de la cobertura se hizo de la siguiente
manera. En el primer caso de estudio, asumimos que la cobertura era la
misma para ambos tipos de prueba debido a que los datos de prueba y los
casos de prueba eran los mismos (debieron haberse ejecutado las mismas
38 líneas de código). En el segundo y tercer casos de estudio, debido a que
los datos de prueba podían variar entre ambos tipos de prueba, se procedió
a automatizar las pruebas manuales que había realizado el QA manual,
para extraer de la herramienta de automatización el porcentaje de
cobertura.
D. Tiempo de creación de script (hh:mm): muestra el tiempo en horas y
minutos que invirtió el QA en crear o modificar el script mediante la
herramienta de automatización. Solo aplica para las pruebas
automatizadas.
E. Tiempo de ejecución de pruebas (hh:mm): se refiere al tiempo en horas y
minutos invertido exclusivamente en la ejecución de las pruebas. En el caso
de las pruebas automatizadas, mide el tiempo que duró la herramienta de
automatización ejecutando los scripts creados por el QA automatizador. En
el caso de las pruebas manuales, muestra el tiempo que le tomó al QA
manual realizar todas las pruebas manualmente.
F. Tiempo de creación de reporte (hh:mm): solo aplica para las pruebas
manuales, debido a que la herramienta de automatización genera
automáticamente un reporte al completar la ejecución de los scripts,
mientras que el QA manual debe llenar el reporte digital. Este rubro
contabiliza el tiempo en horas y minutos que le tomó al QA manual
completar el reporte de cada prueba ejecutada manualmente.
G. Duración total (hh:mm): en el caso de las pruebas automatizadas, la
duración total es la sumatoria de los tiempos (en horas y minutos)
recolectados por las métricas D y E (lo que duró el QA automatizador en
crear los scripts de las pruebas automatizadas y ejecutarlos). En el caso de
las pruebas manuales, la duración total es la sumatoria de los tiempos (en
horas y minutos) recolectados por las métricas E y F (lo que duró el QA
manual en ejecutar las pruebas manuales y generar el reporte de errores).
Para las pruebas manuales no se contempla la métrica D puesto que no
requieren de un script. Para las pruebas automatizadas no se contempla la
39 métrica F puesto no se requiere la elaboración de un reporte manual. El
tiempo necesario para determinar la severidad de los errores no se
consideró dentro de esta métrica, ya que sería el mismo tiempo para ambos
tipos de prueba (la discusión de la severidad la hacen en conjunto el QA
manual y el QA automatizador).
H. Cantidad de verdaderos positivos (VP): cantidad de pruebas ejecutadas que
detectaron errores (intencionalmente) cuando verdaderamente había
errores.
I. Cantidad de verdaderos negativos (VN): cantidad de pruebas ejecutadas
que no detectaron errores cuando realmente no hubo errores.
J. Cantidad de falsos positivos (FP): cantidad de pruebas ejecutadas que
detectaron errores cuando en realidad no hubo errores.
K. Cantidad de falsos negativos (FN): cantidad de pruebas ejecutadas que no
detectaron errores cuando verdaderamente sí había errores.
Las últimas cuatro métricas (VP, VN, FP y FN) forman una matriz de
confusión, como se muestra en la Figura 9. Estos valores se obtuvieron al analizar
cada prueba en su “intención”. Esto significa que si una prueba no detectaba un
error cuando el objetivo (o intención) de la prueba no era verificar ese tipo de error,
esto no se consideró un falso negativo dentro de nuestro análisis. Similarmente, si
se encontraba un error por casualidad y no porque la prueba estuviera orientada a
detectarlo, no se consideró como verdadero positivo en nuestro análisis.
Positivo obtenido Negativo obtenido
Positivo real Verdadero positivo Falso negativo
Negativo real Falso positivo Verdadero negativo
Figura 9. Matriz de confusión.
40 Las métricas anteriores se usaron para calcular métricas compuestas que
representan nuestras variables de análisis. Estas detallan en la sección 4.4
‘Procedimiento de Análisis’.
4.3.5 Amenazas a la validez de los estudios
Las amenazas a la validez son un análisis de las distintas formas en las que
el procedimiento realizado y sus conclusiones pueden estar influenciados por
factores que potencialmente alteren los resultados [31]. Este análisis también
incluye la forma en que se mitigaron dichas amenazas. Las amenazas típicamente
de clasifican en:
a) Amenazas internas: influencias o condiciones internas que pueden afectar
el resultado del caso de estudio.
b) Amenazas externas: complican la generalización de los resultados del
estudio para una práctica fuera del contexto del estudio.
c) Amenazas de constructo: relacionado con amenazas al diseño del caso de
estudio y su capacidad de reflejar el objeto de estudio.
d) Amenazas de conclusión: analizan los problemas que pueden afectar la
habilidad para extraer conclusiones a partir del tratamiento aplicado y el
resultado del caso de estudio.
A continuación, se presenta el análisis de amenazas a la validez para
nuestro estudio.
Validez interna
Rasgos y habilidades: en este caso de estudio, la experiencia del QA manual es
muy superior a la del QA automatizador en cuanto al control de calidad del
software. Esto se mitigó asignando el QA manual a la realización de pruebas
manuales ya que se requiere mayor experticia para ejecutar estas pruebas que las
automatizadas. Esta amenaza sólo aplica al segundo caso de estudio, pues los
otros dos casos usaron los mismos criterios de prueba para las pruebas manuales
41 y las automatizadas. El QA automatizador recibió el mismo entrenamiento que el
QA manual para la creación de los scripts y la utilización de las herramientas de
automatización. Con esto, la brecha en el conocimiento se redujo.
Cansancio: este riesgo se puede presentar debido al esfuerzo solicitado al QA
automatizador y al QA manual de dedicar varias horas al día a realizar las pruebas
para los casos de estudio. El cansancio y el trabajo repetitivo pueden causar
errores, e impactar los resultados obtenidos en el estudio. Este riesgo está
presente en mayor medida en el segundo caso de estudio debido a que requirió 8
horas dedicadas a realizar pruebas durante un solo día.
Miedo a la evaluación: este riesgo sucede cuando una persona cambia su
comportamiento al estar siendo evaluado. En este estudio, el rendimiento del QA
estaba siendo evaluado de manera indirecta como producto de la ejecución de
pruebas manuales, lo que pudo haber impactado el resultado final del caso de
estudio. La forma en la que se mitigó este riesgo fue incorporando (eligiendo) un
QA con varios años de experiencia en la organización y con amplio conocimiento
del proyecto bajo prueba.
Validez externa
Replicación y generalización: este estudio fue realizado en un contexto
organizacional específico. La herramienta de automatización es propiedad de la
organización para uso exclusivamente interno. El SUT que se probó solo tiene
sentido dentro del contexto de la organización. Y el conocimiento sobre la
ejecución de las pruebas, tanto la heurística para la realización de las pruebas
manuales como el entrenamiento para la creación de los scripts para las pruebas
automatizadas, solo se puede obtener con la aprobación de la organización. Por lo
tanto, replicar este estudio puede obtener resultados distintos si se realiza en un
contexto distinto.
42 Validez de constructo
Métricas: si bien las métricas de desempeño y cobertura de código son de valor
para la investigación, no se encontró una forma natural de integrarlas en el cálculo
del retorno sobre la inversión. Por lo tanto, nuestros resultados del ROI no
incluyen ciertos beneficios que reflejan el desempeño y la cobertura de código.
Además, el cálculo de la inversión no contempla el tiempo de entrenamiento
requerido para aprender a usar la herramienta de automatización, ni tampoco la
inversión asociada a la creación de la herramienta, puesto que no se cuenta con
esta información en la organización debido a que el departamento que creó la
herramienta es distinto del departamento en el cual se realizó esta investigación.
Por otro lado, el costo del mantenimiento es cubierto por el departamento que creó
la herramienta, por lo que este valor tampoco fue considerado.
Validez de conclusión
Escasa fiabilidad en la aplicación de tratamientos: para la realización de este caso
de estudio, se contó con un QA para realizar las pruebas manuales y un QA para
las pruebas automatizadas. Los resultados obtenidos para ambos tipos de prueba
pueden haber sido influenciados por las pruebas que cada QA eligió correr (en dos
de los casos de estudio). Sin embargo, esto se mitigó realizando un caso de
estudio donde ambos QAs ejecutaron los mismos casos de prueba con los
mismos datos de prueba, con tal de obtener resultados más fiables.
4.4 Procedimiento de análisis
El análisis de resultados se hizo sobre cinco variables cuantitativas: el costo
ahorrado, la inversión, la cobertura de código, el desempeño y el retorno sobre la
inversión. Estas variables se derivan de las métricas recolectadas, que fueron
especificaron en la sección 4.3.1. Seguidamente explicamos el proceso de
derivación de las variables de análisis.
43 Costo ahorrado: se derivó al sumar el costo asociado a cada error encontrado
dependiendo de su severidad asignada. Gracias a que la organización contaba
con datos históricos, se pudo estimar el costo en el que incurriría al arreglar un
error que no fue detectado en la fase de pruebas sino en producción. Entre más
grande es la severidad del error, mayor es el costo de haberlo detectado en
producción. La severidad de un error fue decidida conjuntamente por el QA
manual y el QA automatizador, apegándose a ciertos criterios usados por la
organización. La severidad se divide en 5 categorías, de mayor a menor impacto:
severidad 1 (con un costo asociado de $150), severidad 2 (con un costo asociado
de $100), severidad 3 (con un costo asociado de $75), severidad 4 (con un costo
asociado de $40), y severidad 5 (con un costo asociado de $25).
Inversión: se derivó multiplicando el tiempo invertido en realizar las pruebas
(obtenido de la métrica D para las pruebas automatizadas debido a que el QA
automatizador no necesita invertir tiempo para ejecutar las pruebas, y de la
métrica G para las pruebas manuales) por el salario por hora del QA. Recordemos
que la forma de calcular el tiempo invertido varía según se trate de pruebas
automatizadas o manuales. (Para más detalles, ver descripción de las métricas D,
E, F, y G en la sección 4.3.1.) En cuanto al salario por hora del QA, este es de $20
por hora. Dicho valor se obtuvo al preguntarle a la organización para poder
determinar la inversión para este caso de estudio. En el cálculo de la inversión no
se contempló el tiempo de entrenamiento para aprender a usar la herramienta,
debido a que este tiempo es variable pues depende de la velocidad con la que
cada QA complete el entrenamiento. Además, no tenemos suficientes datos para
obtener un promedio de duración, ya que solo 2 QAs han llevado el
entrenamiento. Por otro lado, el cálculo de la inversión tampoco incluyó el costo de
creación de la herramienta de automatización, debido a que la herramienta fue
desarrollada por un departamento ajeno al departamento donde se realizó esta
investigación y no se pudo conseguir información sobre la inversión realizada por
ese departamento. Adicionalmente, el costo original de la herramienta se diluye
44 entre los proyectos que la usan, de manera que cada vez que la herramienta es
usada en un proyecto, su costo disminuye, lo cual hace muy difícil obtener un valor
específico de costo de la herramienta.
Cobertura de código: se calculó mediante la herramienta de automatización. La
herramienta de automatización indicaba la cobertura de código alcanzada al
ejecutar las pruebas. Esta facilidad fue utilizada también para calcular la cobertura
de las pruebas manuales por medio de una reproducción de los pasos realizados
por el QA manual durante la ejecución de pruebas manuales para obtener una
aproximación del código cubierto durante dichas pruebas.
Desempeño: esta es una métrica multidimensional, compuesta por la certeza
(capacidad de detectar errores reales), precisión (capacidad de distinguir un error
de una falsa alarma), sensibilidad (capacidad de encontrar todos los errores que
existen), y especificidad (capacidad de evitar falsas alarmas). Estas cuatro
dimensiones o métricas se calculan a partir de las métricas de verdaderos y falsos
positivos, y verdaderos y falsos negativos, mediante las siguientes fórmulas:
9:;<:=> = @A + @C
@A + @C + DA + DC
E;:9FGFóH = @A
@A + DA
G:HGFIFJFK>K = @A
@A + DC
:GE:9FLF9FK>K = @C
@C + DA
Retorno sobre la inversión (ROI): se derivó a partir de las variables ‘costo
ahorrado’ e ‘inversión’ descritas previamente. En nuestro caso el ROI es un
indicador de la relación (o proporción) que hay entre la cantidad de dinero que se
45 invierte en realizar un tipo de pruebas (métrica de inversión) y la ganancia
devengada por realizar dichas pruebas (métrica de costo ahorrado). El resultado
obtenido es el porcentaje de ganancia que se obtuvo con respecto a la inversión
inicial.
Una vez obtenidos estos datos, se procedió a realizar un análisis cualitativo
para explicar los resultados cuantitativos obtenidos y su significado de manera
holística.
Se escogieron estas métricas por considerar que ayudarían a la gerencia
de la organización a tomar la decisión final sobre cuál tipo de prueba utilizar (las
cinco ofrecen perspectivas diferentes). La gerencia necesita saber sobre el ahorro
que genera cada tipo de prueba (costo ahorrado), la inversión que requiere para
ejecutar cada tipo de prueba, la capacidad de detectar nuevos errores introducidos
accidentalmente durante una liberación incremental (cobertura de código), el
desempeño de cada tipo de prueba, y los beneficios obtenidos de cada
metodología (retorno sobre la inversión).
4.5 Procesos e instrumentación
Para la ejecución de los casos de estudio, se usaron los siguientes
instrumentos y procesos:
4.5.1 Plan de pruebas El plan de pruebas se creó a partir de la lista de requerimientos. Dicho plan
tenía el siguiente formato:
● ID: Identificador único del requerimiento
● Requerimiento: Descripción verbal del caso de uso o la funcionalidad
deseada
46 ● ID Caso Concreto: Identificador de un caso de pruebas específico. Cada
requerimiento puede tener varios casos concretos asociados.
● Descripción del caso concreto: Una descripción verbal del caso de
prueba que será ejecutado.
● ID Criterio: El identificador único del conjunto de pasos y datos utilizados
para ejecutar el caso de prueba. Cada caso de prueba puede tener varios
criterios asociados.
● Tipo de criterio: La clasificación de la prueba. Por ejemplo, localización,
pruebas de seguridad, combinatoria, o valores frontera.
● Descripción de criterio: La lista de pasos y datos utilizados en orden para
ejecutar el caso de prueba.
Para cada caso de prueba usado, los QAs generaron un plan de pruebas.
Un ejemplo de plan de pruebas se muestra en la Figura 10.
47
Figura 10. Ejemplo de Plan de pruebas.
48 4.5.2 Ejecución de pruebas manuales y creación de reporte
En el contexto de esta investigación, las pruebas manuales las ejecutó el
‘QA manual’ siguiendo el plan de pruebas. En un documento de texto llamado
‘Reporte de criterio de prueba’, el QA registraba, para cada prueba realizada, el
identificador del criterio de prueba (según el plan de pruebas) así como los pasos
que se ejecutaron como parte de la verificación y el comportamiento del sistema al
concluir la prueba. En caso de encontrar errores, el QA los indicaba en ese mismo
reporte. Los campos contenidos en dicho reporte son los siguientes:
ID: Identificador del criterio probado.
Pasos: Pasos seguidos por el QA para probar el criterio.
Errores encontrados: Lista de errores encontrados por el QA durante la prueba.
Pasa validación: Indicador de si la validación pasó o no.
Un ejemplo de este documento que llenaba el QA manual se muestra en la Figura
11.
Figura 11. Ejemplo de Reporte de un criterio de prueba.
4.5.3 Ejecución de pruebas automatizadas
La herramienta de automatización que se usó fue creada por la
organización en la que se realizó la investigación. La herramienta le permite al QA
abrir un explorador de internet integrado. Este explorador le comunica
constantemente a la herramienta las interacciones que realiza el QA. El QA
49 procede a ejecutar un caso de prueba, y al cerrar el explorador, le indica a la
herramienta el fin del caso de prueba. La herramienta analiza las interacciones y
genera un script que, de ejecutarse sin modificarse, replica todas las interacciones
de manera automática, tal y como lo hizo el QA. Este script puede ser libremente
modificado por el QA usando la misma herramienta, para realizar distintas
versiones del mismo caso de prueba. Esto debido a que el script guarda los
identificadores de los componentes gráficos con los que interactuó el QA y
reconoce cuáles son las entradas que el QA le brindó al sistema. Por ejemplo, si el
caso de prueba consistía en abrir una página web, ingresar un texto en un campo,
y presionar un botón, la herramienta identifica el campo de texto y el botón, así
como las interacciones que se hicieron con cada componente (e.g., el texto que
fue ingresado y la presión del botón) junto con la respuesta que devolvió el
sistema al presionar el botón. El script entonces puede ser modificado para que se
ejecute utilizando distintos textos predeterminados por el QA en el mismo campo.
Se le puede indicar a la herramienta que ejecute la prueba tantas veces como
posibles textos indicados en el script, o un número aleatorio de veces. Además, el
script puede ser configurado para que se ejecute en distintos exploradores de
internet (Firefox, Chrome, Internet Explorer, Safari, entre otros).
Otro tipo de configuración posible en el script es la de combinaciones. Al
poder identificar los componentes con los que interactuó el QA, se pueden
correlacionar las entradas para cada componente de tal manera que se ejecuten
ciertas entradas de un componente con ciertas entradas de otro componente. Por
ejemplo, se puede configurar el comportamiento de la herramienta para que
ciertas entradas se ejecuten sólo en combinación de otras entradas, como
presionar un botón solo si cierto texto fue ingresado en un campo en particular.
Este nivel de configuración permite probar tantas combinaciones como desee el
QA.
50 Una funcionalidad de gran utilidad en esta herramienta es la de modificar el
código html de una página con el objetivo de realizar pruebas de seguridad. Por
ejemplo, si un botón está deshabilitado en la interfaz porque ciertas condiciones
no se han cumplido, es posible modificar el html para habilitarlo y poder hacerle
click sin cumplir las condiciones adecuadas. Esto es particularmente útil para
probar vulnerabilidades en el sistema, y en este caso, ver si se hacen validaciones
del lado del servidor para verificar las condiciones en lugar de confiar en el cliente
y sus validaciones.
Al concluir las pruebas, la herramienta genera un reporte automático
indicando qué entradas usó en cada campo en cada iteración de la prueba, así
como cualquier anomalía encontrada al haber obtenido una respuesta no
esperada por parte del sistema bajo verificación. La Figura 12 muestra un ejemplo
del reporte generado por la herramienta de automatización al concluir una
ejecución de una prueba.
Figura 12: Ejemplo de reporte generado por la herramienta automatizada al concluir una
ejecución de una prueba.
51
5. Resultados y análisis
5.1 Resultados
A continuación, se muestran las tablas con los resultados obtenidos en
cada caso de estudio.
5.1.1 Resultados del primer caso de estudio El objetivo del primer caso de estudio era determinar si había diferencias de
tiempo entre las pruebas manuales y las automatizadas. La Tabla 1 muestra los
resultados obtenidos.
Tabla 1: Resultados del primer caso de estudio.
Totales Automatizada Manual Cantidad de pruebas ejecutadas 233 233 Cantidad de errores 14 14 Cobertura de código 26.57% 26.57% Costo de errores (USD) 810 810 Tiempo de creación de script (hh:mm) 2:52 -
Tiempo de ejecución de pruebas (hh:mm) 1:15 1:28 Tiempo de creación de reporte (hh:mm) -
2:12
Duración total (hh:mm) 4:07 3:40 Cantidad de verdaderos positivos 14 14 Cantidad de verdaderos negativos 219 219 Cantidad de falsos positivos 0 0 Cantidad de falsos negativos 0 0
Como se puede observar de la Tabla 1, las pruebas manuales y las
automatizadas ejecutaron la misma cantidad de pruebas (233) y encontraron la
52 misma cantidad de errores (14). Además, debido a que las pruebas ejecutadas
(incluyendo los datos usados para correr las pruebas) fueron idénticas, el
porcentaje de cobertura de código reportado fue el mismo. La cantidad de
verdaderos y falsos positivos y negativos también fueron idénticos en ambos tipos
de prueba.
Se encontró una diferencia de 27 minutos entre el tiempo que tomaron las
pruebas automatizadas y las manuales: las automatizadas se completaron en 4
horas y 7 minutos, mientras que las manuales en 3 horas y 40 minutos. La Figura
13 muestra un desglose del tiempo invertido por fase del proceso de pruebas,
tanto para las pruebas manuales como automatizadas. La diferencia de tiempo
entre ambos tipos de prueba se debe a la creación de los scripts de
automatización, ya que si ignoramos la creación de los scripts y del reporte de
errores de las pruebas manuales (es decir, considerando solo la ejecución de las
pruebas manuales y automatizadas), las pruebas automatizadas se ejecutaron 13
minutos más rápido.
53
Figura 13. Duración de las pruebas manuales y automatizadas para el primer caso de
estudio.
Hay que destacar que durante la ejecución del primer caso de estudio
sucedió que en el caso R5.TC1.1 el QA observó un error a nivel de la interfaz
gráfica que la herramienta de automatización no detectó. Sin embargo, dicho error
no era parte del objetivo de las pruebas que se estaban realizando en ese
momento; el QA detectó el error porque era visualmente notable al ojo humano. La
herramienta automatizada pudo haber detectado el error de habérsele agregado
lógica al script para verificar los componentes gráficos. La complejidad necesaria
para hacer este tipo de validaciones de manera automatizada es bastante alta, ya
que la herramienta debe validar cada componente visual después de ejecutar
cada paso de la prueba. Dicho error no se consideró como un falso negativo ya
que la intención del script automatizado no era encontrar este tipo de errores. No
obstante, esto revela que las pruebas automatizadas no deben sustituir por
completo las pruebas manuales, ya que un error de este tipo puede fácilmente
encontrarse manualmente mientras que el esfuerzo necesario para encontrarlo de
54 manera automatizada es elevado si se considera las funcionalidades que la
herramienta ofrece en su estado actual.
En cuanto al retorno sobre la inversión, las pruebas automatizadas tuvieron
una inversión de tiempo de 2:52 horas o 2.86 horas (no se considera el tiempo de
ejecución de scripts debido a que no requieren de supervisión ni interacción por
parte del QA automatizador). Al realizar el cálculo del retorno, se obtiene que
456%= !"#$"#%&"''()"#*+,-.'#/ó,+,-.'#/ó,
= 812*(7.8O∗72)(7.8O∗72)
=812*RS.7RS.7
= SR7.8RS.7
= 13.16
Por otro lado, las pruebas automatizadas encontraron la misma cantidad de
errores, pero en un tiempo de 3:40 horas, o 3.66 horas (en este caso, se
consideran tanto el tiempo de ejecución de pruebas como el de creación del
reporte, ya que ambos pasos son realizados manualmente). El cálculo sería
456T= !"#$"#%&"''()"#*+,-.'#/ó,+,-.'#/ó,
= 812*(U.OO∗72)(O∗72)
=812*SU.7SU.7
= SUO.8SU.7
= 10.06
55
Por lo tanto, las pruebas automatizadas tuvieron un mayor retorno sobre la
inversión, en comparación con las pruebas manuales.
5.1.2 Resultados del segundo caso de estudio
El objetivo del segundo caso de estudio era determinar la cantidad y el tipo
de errores encontrados por cada tipo de prueba. La Tabla 2 muestra los resultados
obtenidos en este caso de estudio.
En este caso de estudio, se ejecutaron los mismos casos de prueba pero se
dejó a discreción de cada QA los datos concretos de prueba a usar. Durante un
lapso de 8 horas, se realizaron tantas pruebas manuales y automatizadas como
fuese posible. En la Tabla 2 se puede observar que el QA automatizador fue
capaz de correr 288 casos automatizados mientras que el QA manual logró correr
302 casos de forma manual. Esto correspondió a una cobertura de código del
36.33% para las pruebas automatizadas y del 36.42% para las pruebas manuales.
56 Tabla 2: Resultados del segundo caso de estudio.
Totales Automatizada Manual Cantidad de pruebas ejecutadas 288 302 Cantidad de errores 18 13 Costo de errores (USD) $950 $815 Cobertura de código 36.33% 36.42% Tiempo de creación de script (hh:mm)
5:19 -
Tiempo de ejecución de pruebas (hh:mm) 2:46 3:24 Tiempo de creación de reporte (hh:mm) - 4:35 Duración total (hh:mm)
8:05 7:59 Cantidad de verdaderos positivos 18 13 Cantidad de verdaderos negativos 270 289 Cantidad de falsos positivos 0 0 Cantidad de falsos negativos 0 3
Si bien se pudieron correr más pruebas manuales que automatizadas en las
8 horas establecidas, las pruebas automatizadas encontraron más errores (18)
que las pruebas manuales (13). Las pruebas manuales encontraron 13 verdaderos
positivos, 289 verdaderos negativos, 3 falsos negativos y ningún falso positivo,
mientras que las pruebas automatizadas encontraron 18 verdaderos positivos, 270
verdaderos negativos, y ningún falso positivo o negativo.
La Figura 14 muestra la cantidad de errores encontrados por cada tipo de
pruebas, según su severidad. Las pruebas automatizadas encontraron 5 errores
de severidad 2, 6 errores de severidad 3, y 7 errores de severidad 4, mientras que
las pruebas manuales encontraron solo 2 errores de severidad 2, 5 errores de
severidad 5, y 6 errores de severidad 6.
57
Figura 14. Cantidad de errores por severidad encontrados por ambos tipos de pruebas.
Sin embargo, hay diferencias importantes en los errores encontrados ya
que ciertos errores fueron encontrados solo por uno de los dos tipos de pruebas.
Es necesario ver estas diferencias y analizar sus causas:
● R7.TC2.1: Este caso de prueba reveló aún más la necesidad de combinar
las pruebas manuales y automatizadas, ya que durante las pruebas
manuales el QA manual observó que había un error en la interfaz gráfica,
una situación que también se vio en el primer caso de estudio. Y de igual
manera, las pruebas realizadas en sí no iban orientadas a encontrar este
tipo de error, pero no se puede negar la existencia del mismo. Esto no fue
considerado un falso negativo por parte de las pruebas automatizadas
debido a que su intención no era la de encontrar este tipo de errores.
● R8.TC1.1: En este caso, el QA manual cometió un error y omitió una
posible combinación de datos que revelaba un error. La herramienta de
58 automatización siempre ejecuta todas las posibles combinaciones, por lo
que sí fue capaz de encontrar el error. Este caso sí fue considerado un
falso negativo de parte de las pruebas manuales debido a que la intención
de la prueba era tal que este error tuvo que haber sido detectado
manualmente de haberse ejecutado la prueba correctamente. Cabe
destacar que el reporte de errores de la ejecución de pruebas manuales
indicaba erróneamente que todas las combinaciones posibles fueron
probadas cuando en realidad faltó una combinación.
● R8.TC2.2: En este caso de prueba, el QA manual olvidó ejecutar una
prueba de localización en el explorador Safari. La herramienta de
automatización sí ejecutó las pruebas en los exploradores relevantes, y
detectó un problema de codificación de texto chino en Safari. Esto también
fue considerado un falso negativo en las pruebas manuales ya que la
intención de la prueba sí era encontrar problemas de localización.
● R12.TC1.2: En este caso, al QA manual no se le ocurrió ejecutar esta
prueba de seguridad. Sin embargo, a pesar de que se detectó un error al
ejecutar esta prueba de manera automatizada, no se considerará como un
falso negativo en las pruebas manuales ya que manualmente no se ejecutó
ninguna prueba de seguridad.
● R13.TC1.2: En este caso de localización, el QA manual omitió una posible
localización, y no detectó que faltaba una traducción. La herramienta de
automatización detectó que el SUT fue incapaz de encontrar la traducción
adecuada, y reportó el problema. Esto se considerará un falso negativo
durante las pruebas manuales ya que la prueba de localización ejecutada
correctamente debió haber detectado este error.
● R16.TC1.3: El QA manual no ejecutó esta prueba de seguridad ya que no
sabía que podía realizarse un ataque en un componente específico. En este
error se vio una opción que ofrece la herramienta para modificar el html de
la página web en vivo, lo que simplifica la ejecución de varios tipos de
ataques para verificar la seguridad. Esto no se considerará un falso
59 negativo por parte de las pruebas manuales ya que el ataque no se realizó
del todo manualmente.
● R20.TC1.2: Este caso de prueba fue ejecutado solamente de manera
manual debido a que el QA manual logró realizar más casos de prueba
manuales en el tiempo asignado para el caso de estudio. Por lo tanto, no se
considerará un falso negativo por parte de las pruebas automatizadas a
pesar de que se encontró un error durante las pruebas manuales.
La Figura 15 muestra el monto (en dólares) que ahorraron tanto las pruebas
manuales como las automatizadas. Las pruebas automatizadas generaron un
ahorro de $950, en comparación con un ahorro de $815 por parte de las pruebas
manuales.
Figura 15. Monto ahorrado en USD por tipo de prueba.
Para el cálculo de la inversión de las pruebas automatizadas, se tiene que
el tiempo dedicado a creación de scripts fue de 5:19 horas o 5.32 horas. El cálculo
del retorno sobre la inversión para las pruebas automatizadas sería
60
456%= !"#$"#%&"''()"#*+,-.'#/ó,+,-.'#/ó,
= VR2*(R.U7∗72)(R.U7∗72)
=VR2*12O.W12O.W
= 8WU.O12O.W
= 7.93
Esto corresponde a un retorno del 793%. Por otro lado, el cálculo del ROI
para las pruebas manuales es el siguiente:
456T= !"#$"#%&"''()"#*+,-.'#/ó,+,-.'#/ó,
= 81R*(S.V8∗72)(S.V8∗72)
=81R*1RV.O1RV.O
= ORR.W1RV.O
= 4.11
Por tanto, el retorno sobre la inversión de las pruebas automatizadas
(793%) fue mayor al de las pruebas manuales (411%).
Sin embargo, se pudieron observar diferencias que van más allá del
aspecto meramente monetario:
1. El factor humano: el QA manual cometió errores en tres instancias al omitir
posibles combinaciones. Esto pudo haber causado que errores que fueron
pasados por alto llegasen al ambiente de producción. También reveló que
el proceso de reporte manual que realiza el QA manual está expuesto al
61 mismo problema ya que en el reporte se indicó erróneamente que todas las
combinaciones habían sido probadas. Además, demostró la ventaja de
realizar pruebas combinatorias usando la herramienta de automatización
debido a que, si el script está bien hecho, la herramienta verifica todas las
combinaciones que se le indique. Y si sucede que una combinación no fue
probada, eso se podrá identificar en el reporte que entrega la herramienta
de automatización al terminar de ejecutar los casos de prueba ya que indica
todas las combinaciones que fueron realizadas de acuerdo al script.
2. El nivel de conocimiento: el QA automatizador cuenta con mayor
conocimiento en el campo de la seguridad que el QA manual, por lo que las
pruebas de seguridad realizadas de manera automatizada fueron más
efectivas y encontraron más errores. Por otro lado, el QA manual cuenta
con más experiencia en control y aseguramiento de calidad del software
que el QA automatizador, por lo que el QA manual ejecutó pruebas que el
QA automatizador no conocía.
3. Velocidad de ejecución: durante el mismo periodo de tiempo se pudieron
ejecutar 14 pruebas manuales más que pruebas automatizadas. Esto,
aunado con lo encontrado en el primer caso de estudio, expone aún más el
hecho de que las pruebas manuales pueden ejecutarse más rápidamente
que las pruebas automatizadas.
4. Pruebas de interfaz gráfica: como en el primer caso de estudio, en este
segundo caso se volvió a observar un error de interfaz gráfica que el QA
manual detectó, pero que las pruebas no tenían intención de buscar. Esto
soporta aún más la idea de que la herramienta automatizada en su estado
actual no puede sustituir por completo a las pruebas manuales.
5.1.3 Resultados del tercer caso de estudio
El objetivo primordial del tercer caso de estudio era determinar si se
encontraban errores en producción que no hubiesen sido detectados durante la
62 fase de pruebas. Un objetivo secundario era evaluar, para cada tipo de prueba, su
capacidad de detección de errores al haber cambios incrementales en el SUT.
En las tres iteraciones semanales que incluyó el caso de estudio, hubo
requerimientos nuevos que no fueron considerados durante la fase de
levantamiento de requisitos, por lo que los desarrolladores tuvieron que agregar la
lógica respectiva al SUT, y tanto el QA manual como el QA automatizador
agregaron estos nuevos criterios a las pruebas correspondientes.
Primera iteración
En la primera iteración hubo un nuevo requerimiento en el SUT, por lo que
se tuvo que verificar su implementación. La Tabla 3 muestra los resultados de la
primera iteración del tercer caso de estudio.
Tabla 3: Resultados de la primera iteración del tercer caso de estudio.
Totales Automatizada Manual Cantidad de pruebas ejecutadas 522 9 Cantidad de errores 0 0 Cobertura de código 59.34% 1.30% Costo de errores (USD) 0 0 Tiempo de creación de script (hh:mm) 0:03 -
Tiempo de ejecución de pruebas (hh:mm)
4:01 0:06
Tiempo de creación de reporte (hh:mm)
- 0:04
Duración total (hh:mm) 4:04 0:10 Cantidad de verdaderos positivos 0 0 Cantidad de verdaderos negativos 522 9 Cantidad de falsos positivos 0 0 Cantidad de falsos negativos 0 0
63 Como se puede ver en la Tabla 3, el QA automatizador ejecutó todos los
scripts que se crearon en los dos primeros casos de estudio para un total de 522
pruebas en un lapso de 4 horas y 4 minutos. El QA manual solo ejecutó pruebas
para el caso de uso que se vio impactado por el cambio incremental, por lo que
obtuvo una cobertura del 1.3% en 10 minutos de los cuales 6 fueron en ejecución
de la prueba y 4 en la creación del reporte manual. Para incorporar el cambio en el
script, el QA automatizador requirió de 3 minutos. Al finalizar las ejecuciones,
ninguna prueba encontró errores; las pruebas automatizadas encontraron 522
verdaderos negativos, ningún verdadero positivo ni falsos positivos ni negativos.
Manualmente se encontraron 9 verdaderos negativos sin verdaderos positivos ni
falsos positivos ni negativos.
Segunda iteración
La segunda iteración también tuvo un cambio incremental producto de un
nuevo requerimiento. La Tabla 4 muestra los resultados de la segunda iteración
del tercer caso de estudio.
Tabla 4: Resultados de la segunda iteración del tercer caso de estudio. Totales Automatizada Manual Cantidad de pruebas ejecutadas 524 7 Cantidad de errores 0 0 Cobertura de código 59.38% 1.24% Costo de errores (USD) 0 0 Tiempo de creación de script (hh:mm)
0:04 -
Tiempo de ejecución de pruebas (hh:mm)
4:01 0:04
Tiempo de creación de reporte (hh:mm)
- 0:04
Duración total (hh:mm) 4:05 0:08 Cantidad de verdaderos positivos 0 0 Cantidad de verdaderos negativos 524 7 Cantidad de falsos positivos 0 0 Cantidad de falsos negativos 0 0
64 El cambio incremental en el SUT trajo consigo la integración de dos nuevos
casos de pruebas en el script automatizado. Como se puede observar en la Tabla
4, el QA automatizador volvió a ejecutar todas las pruebas automatizadas a su
disposición para un total de 524 pruebas distintas contra 7 pruebas manuales
realizadas por el QA manual para validar el nuevo requerimiento. Ninguna
validación encontró errores, por lo que se obtuvieron 524 verdaderos negativos de
manera automatizada y 7 verdaderos negativos de manera manual. La cobertura
obtenida de manera automatizada fue del 59.38% mientras que manualmente se
cubrió solamente 1.24%.
En esta iteración, al QA automatizador le tomó 3 minutos integrar los dos
nuevos casos de pruebas y 4 horas con 1 minuto para ejecutar todas las
validaciones. Al QA manual le tomó 4 minutos ejecutar todas las pruebas del caso,
y 4 minutos más para generar el reporte de pruebas.
Tercera iteración
En esta iteración también se agregó un nuevo requerimiento al SUT, y se
hizo un cambio incremental para incluirlo. La Tabla 5 muestra los resultados de la
tercera iteración del tercer caso de estudio.
En la tercera iteración se agregó un nuevo caso de pruebas a las pruebas
automatizadas, por lo que automatizadamente se ejecutaron 525 casos de prueba
contra 5 casos de prueba ejecutados manualmente. Como se puede ver en la
Tabla 5, durante esta iteración, se obtuvo una cobertura de código del 59.41% de
manera automatizada mientras que manualmente se obtuvo una cobertura del
1.26%. El QA automatizador logró integrar el nuevo caso de prueba en 5 minutos,
y la ejecución de todas las pruebas tomó 4 horas con 2 minutos. El QA manual fue
capaz de correr las pruebas correspondientes en 7 minutos, y generó el reporte
manual en 4 minutos. En esta iteración, una prueba automatizada detectó un error
que las pruebas manuales no. Esto debido a que la validación realizada
65 manualmente fue solo del caso de uso nuevo mientras que la validación
automática validó todos los casos de uso que habían sido validados anteriormente
y fue capaz de detectar un error introducido un caso de uso ya existente.
Tabla 5: Resultados de la tercera iteración del tercer caso de estudio. Totales Automatizada Manual Cantidad de pruebas ejecutadas 525 5 Cantidad de errores 1 0 Cobertura de código 59.41% 1.26% Costo de errores (USD) 100 0 Tiempo de creación de script (hh:mm) 0:05
-
Tiempo de ejecución de pruebas (hh:mm)
4:02 0:07
Tiempo de creación de reporte (hh:mm)
- 0:04
Duración total (hh:mm) 4:07 0:11 Cantidad de verdaderos positivos 1 0 Cantidad de verdaderos negativos 524 5 Cantidad de falsos positivos 0 0 Cantidad de falsos negativos 0 0
A diferencia de los primeros dos casos de estudio, los tiempos de scripting
en este caso de estudio fueron mucho menores, como se aprecia en la Figura 16.
66
Figura 16. Diferencias de tiempo dedicado a scripting entre los tres casos de estudio.
Esto es de interés debido a que si bien en el primer caso de estudio las
pruebas automatizadas duraron más que las pruebas manuales debido a que se
requiere de una inversión significativa de tiempo para la creación del script, esta
inversión de tiempo solo se realiza una única vez, y cualquier cambio en el criterio
de la prueba se hace modificando el script existente. Para demostrar esto basta
con observar que el tiempo total dedicado a modificar los scripts durante las tres
iteraciones de este caso de estudio fue de alrededor de 12 minutos. Esto es
importante si se observa la cobertura de código que se obtuvo durantes estas
iteraciones, que fue de alrededor del 60% del código. Esto debido a que durante
las tres iteraciones se ejecutaron todos los scripts automatizados que se habían
creado en los primeros dos casos de estudio. Por otro lado, el QA manual solo
ejecutó la prueba del nuevo requerimiento, lo que correspondía a una cobertura
inferior al 2% del código. Esto se puede ver en la Figura 17.
67
Figura 17. Cobertura de código obtenida en cada iteración del tercer caso de estudio.
Si bien esto implicó una duración mucho mayor durante la ejecución de las
pruebas automatizadas (alrededor de 4 horas comparado a los aproximadamente
7 minutos de las pruebas manuales), la naturaleza de estos procesos
incrementales no trae consigo una urgencia que requiera una ejecución rápida. El
QA automatizador incluso fue capaz de dejar la herramienta de automatización
ejecutando las pruebas sin supervisión, por lo que esas 4 horas no requieren de la
atención de quien esté ejecutando las pruebas.
Para calcular el retorno sobre la inversión de este caso de estudio, sólo se
consideró la última iteración debido a que no se encontraron errores (ahorros) en
las primeras dos iteraciones. En el caso de las pruebas automatizadas, se
necesitaron 5 minutos para modificar el script, que corresponde a 0.08 horas. Por
lo tanto, el cálculo del ROI para las pruebas automatizadas sería
456%= !"#$"#%&"''()"#*+,-.'#/ó,+,-.'#/ó,
68
= 122*(2.28∗72)(2.28∗72)
=122*1.O1.O
= V8.W1.O
= 61.5
Las pruebas automatizadas obtuvieron un retorno del 615% para esta
iteración. Las pruebas manuales no detectaron ningún error, por lo que no
obtuvieron retorno alguno.
5.2 Análisis
A continuación, se analizan los resultados a la luz de las cinco métricas de interés descritas previamente.
5.2.1 Inversión Los resultados del primer y segundo caso de estudio coinciden en que las
pruebas manuales se pueden ejecutar en menos tiempo que las pruebas
automatizadas, es decir, requieren una menor inversión de tiempo. Sin embargo,
el tercer caso de estudio corrobora este resultado solo para la primera vez que se
ejecutaron las pruebas (debido al tiempo que toma la creación de los scripts
automatizados). Las subsiguientes veces que se ejecutaron las pruebas, las
automatizadas exhibieron un mejor tiempo (13 minutos más rápidas) que las
manuales, ya que las pruebas automatizadas consisten solo en ejecutar el script
(el script ya fue creado previamente). Sin embargo, debido a que las pruebas
automatizadas no requieren que el QA esté presente para la ejecución de las
mismas, la inversión monetaria es menor que en las pruebas manuales. En
síntesis, respecto a la primera pregunta de investigación: ¿Cuál tipo de prueba
requiere la menor inversión?, se puede decir que las pruebas manuales requieren
menos inversión de tiempo la primera vez que se ejecutan, pero en ejecuciones
69 posteriores estas requieren mayor inversión que las automatizadas. Es decir, la
inversión depende de si las pruebas se van ejecutar múltiples veces o una única
vez. Pero en términos monetarios, las pruebas automatizadas requieren menos
inversión ya que necesitan una menor intervención por parte del QA.
5.2.2 Costo ahorrado
Como se pudo observar en el segundo caso de estudio, aún si se
ejecutaron más pruebas de manera manual, las pruebas automatizadas generaron
un ahorro $135 mayor (un 14.2% más) que las pruebas manuales. Y si se
considera el tercer caso de estudio, las pruebas automatizadas ahorraron $100
mientras que las pruebas manuales no generaron ningún ahorro. Además,
conforme se vayan agregando nuevos requerimientos a la aplicación como parte
del proceso iterativo, las pruebas automatizadas tienen mayores probabilidades de
encontrar más errores que las pruebas manuales, debido a la cantidad de pruebas
que se ejecutan en comparación con la metodología de prueba que se realiza
manualmente.
Con respecto a la segunda pregunta de investigación: ¿Cuál tipo de prueba
encuentra más errores en un tiempo determinado?, se pudo determinar que las
pruebas automatizadas fueron capaces de encontrar más errores que las
manuales en un lapso de tiempo dado (segundo caso de estudio).
5.2.3 Cobertura de código
En los dos primeros casos de estudio la cobertura de código para ambos
tipos de prueba fue bastante similar, mientras que en el tercer caso de estudio
(pruebas de regresión) hubo una diferencia bastante significativa en la cobertura
de código. Debido a que el QA solo realiza pruebas alrededor de las
modificaciones incrementales, las pruebas automatizadas son capaces de cubrir
mucho más código de manera más rápida y eficiente, con la diferencia de
cobertura de código en las tres iteraciones del tercer caso de estudio de casi un
70 60%. Además, ya que las pruebas son ejecutadas por la herramienta, la inversión
de tiempo depende únicamente del tamaño de la modificación necesaria para
probar adecuadamente el cambio incremental. Posteriormente, la herramienta de
automatización es capaz de ejecutar los scripts sin supervisión. Por lo tanto, si
bien durante las tres iteraciones se duraron alrededor de 4 horas para ejecutar
todas las pruebas, la inversión de tiempo por parte del QA automatizador para las
pruebas automatizadas fue de 4 minutos en promedio por iteración, mientras que
por parte del QA manual se necesitó una inversión de 10 minutos en promedio por
iteración; más del doble de lo necesario para las pruebas automatizadas.
Esto responde la quinta pregunta de investigación: ¿Cuál tipo de prueba
obtiene una mejor cobertura de código?, ya que es evidente que las pruebas
automatizadas obtienen una cobertura muy superior a las pruebas manuales.
5.2.4 Desempeño
A partir de los datos obtenidos en los casos de estudio, se generaron dos
matrices de confusión: una para las pruebas automatizadas y otra para las
pruebas manuales, las cuales se muestran en las Tablas 6 y 7, respectivamente.
Tabla 6. Matriz de confusión obtenida para las pruebas automatizadas.
Positivo obtenido Negativo obtenido
Positivo real 33 0
Negativo real 0 2059
Tabla 7. Matriz de confusión obtenida para las pruebas manuales.
Positivo obtenido Negativo obtenido
Positivo real 27 3
Negativo real 0 529
71 Con base en estas matrices de confusión, se derivaron los valores de
certeza, precisión, sensibilidad y especificidad, tanto para las pruebas
automatizadas como manuales. A continuación, se muestran los resultados para
las pruebas automatizadas:
● 9:;<:=>% = XYZX[
XYZX[Z\YZ\[
=UUZ72RV
UUZ72RVZ2Z2= 1.0
● E;:9FGFóH% = XY
XYZ\Y
=UU
UUZ2= 1.0
● G:HGFIFJFK>K% = XY
XYZ\[
=UU
UUZ2=1.0
● :GE:9FLF9FK>K% = X[
X[Z\Y
=72RV
72RVZ2= 1.0
Seguidamente se muestran los resultados para las pruebas manuales:
● 9:;<:=>T = XYZX[
XYZX[Z\YZ\[
= 27 + 529
27 + 529 + 0 + 3= c. ddef
72
● E;:9FGFóHT = XY
XYZ\Y
= 7S
7SZ2= 1.0
● G:HGFIFJFK>KT = XY
XYZ\[
=7S
7SZU=0.9
● :GE:9FLF9FK>KT = X[
X[Z\Y
=R7V
R7VZ2= 1.0
Se puede observar que las pruebas automatizadas tienen una certeza del
100% para diferenciar los errores reales de entre todos los errores encontrados
mientras que las pruebas manuales tienen una certeza del 99.47%. Las pruebas
automatizadas tienen una precisión del 100% para distinguir los verdaderos
errores de las falsas alarmas al igual que las pruebas manuales. Además, las
pruebas automatizadas tienen una sensibilidad del 100% para obtener
absolutamente todos los errores mientras que las pruebas manuales solo
detectaron 90% de los errores que debían detectar. Por último, tanto las pruebas
automatizadas como las manuales tienen una especificidad del 100% para evitar
detectar errores que en realidad no lo son.
Esto responde la tercera pregunta de investigación: ¿Cuál tipo de prueba es
más efectivo en detección de errores? A partir de los resultados de los tres casos
de estudio realizados, se puede determinar que las pruebas automatizadas son
más efectivas para detectar errores. Sin embargo, no se puede ignorar que el
factor humano siempre va a influir en los resultados de cada prueba, y que
dependiendo del conocimiento de quien realice las pruebas, los errores que se
encuentren pueden variar.
73 5.2.5 Retorno sobre la inversión
En el primer caso de estudio el retorno sobre la inversión fue mayor en la
ejecución de pruebas automatizadas (1316%) comparado con la ejecución de
pruebas manuales (1006%). De igual manera, en el segundo caso de estudio, las
pruebas automatizadas tuvieron un mayor retorno (793%) comparado con las
pruebas manuales (411%). En el tercer caso de estudio, las pruebas
automatizadas obtuvieron un retorno (615%) mientras que las pruebas manuales
no obtuvieron retorno alguno. Por lo tanto, la organización obtuvo en los tres casos
de estudio un mayor retorno sobre la inversión al realizar las pruebas de manera
automatizada. Sin embargo, cabe destacar que de haber utilizado solo pruebas
automatizadas, ciertos errores habrían sido omitidos. Esto refuerza la idea de que
un modelo híbrido que combine pruebas manuales y automatizadas puede traer
más beneficios que la aplicación de solo un tipo de prueba.
La cuarta pregunta de investigación, ¿Hay alguna clase de error que sea
más fácilmente detectable con uno de los tipos de prueba?, se puede responder
analizando los hallazgos relacionados con errores de interfaz gráfica durante el
primer y segundo casos de estudio, y con errores cometidos por el QA manual
durante las pruebas combinatorias en el segundo caso de estudio. Esto ya que el
QA manual fue capaz de detectar anomalías en la interfaz gráfica aún si la prueba
que se realizaba en ese momento no iba dirigida a ese tipo de errores. Si se
observa que la diferencia entre la detección de un error y la omisión del mismo fue
la mayor participación humana en la ejecución de las pruebas debido a la
naturaleza de las pruebas manuales, se puede afirmar entonces que las pruebas
manuales son más efectivas para encontrar errores a nivel de interfaz gráfica.
Además, en el estado actual de la herramienta de automatización, la detección de
este tipo de errores requiere de una inversión de tiempo importante debido a que
el script debe incluir una verificación del estado de todos los componentes gráficos
después de la ejecución de cada paso de la prueba. Por otro lado, los errores por
omisión hechos por el QA también demuestran que las pruebas automatizadas
74 son más efectivas para probar todas las posibles combinaciones dependiendo del
script hecho. Y de manera quizá aún más importante es el reporte generado por la
herramienta de automatización ya que si hubo una combinación que fue omitida
durante la creación del script, se podrá ver claramente en el reporte de la
ejecución de la herramienta, mientras que el reporte hecho a mano por el QA
manual como parte de las pruebas manuales indicaba erróneamente que todas las
combinaciones fueron probadas. Por lo tanto, las pruebas manuales son más
efectivas para detectar errores en la interfaz gráfica mientras que las pruebas
automatizadas son más efectivas para detectar errores que surgen a partir de
distintas combinaciones de datos.
Los resultados de esta investigación demuestran que la organización puede
verse beneficiada por la introducción de la automatización en su proceso de
control de calidad. Sin embargo, se debe realizar un análisis adicional durante la
fase de diseño del plan de pruebas y estimación de tiempo del proyecto para
determinar cuál tipo de prueba traerá más beneficios para el equipo. Como se
observó en los trabajos relacionados, existen muchos factores que deben
considerarse antes de tomar la decisión, tales como tiempo, experiencia del
equipo, presupuesto, y tecnología. Además, si bien para este caso de estudio se
demostró la utilidad de la automatización, se demostró también que no es la
solución para todos los problemas de detección de errores. Por lo tanto, las
pruebas manuales no pueden ni deben ser completamente sustituidas por las
pruebas automatizadas. La organización debe entonces optar por desarrollar un
modelo híbrido que combine pruebas manuales y pruebas automatizadas.
Además, debe crearse un modelo de toma de decisiones que ayude al equipo a
decidir qué tipo de prueba aplicar con el fin de mejorar la detección de errores y a
la vez, brindar un cálculo aproximado del tiempo requerido para la ejecución de los
mismos. Esto con el objetivo de poder brindar fechas de entrega realistas que
permitan validar satisfactoriamente que el sistema vaya conforme a las
expectativas de calidad de la organización y del usuario final.
75
6. Conclusiones Esta investigación tuvo como propósito analizar el retorno sobre la inversión
de las pruebas manuales y automatizadas dentro del contexto de una organización
con el objetivo de determinar cuál tipo de prueba es más rentable para el
aseguramiento de la calidad en páginas web orientadas a la venta de productos en
línea. Las pruebas automatizadas se realizaron con una herramienta de
automatización creada por la misma organización.
En todos los casos de estudio se determinó que el retorno sobre la
inversión era mayor para las pruebas automatizadas. Esto a pesar de que las
pruebas automatizadas tomaran más tiempo en ejecutarse, ya que dicho tipo de
prueba no requiere que el QA automatizador esté presente. Esto confirma lo
hallado en trabajos relacionados [28, 30]. De aquí se derivan dos hallazgos de
interés: (i) si bien las pruebas automatizadas requieren una mayor inversión de
tiempo para completarse, requieren menor intervención humana durante su
ejecución, y (ii) las pruebas automatizadas requieren una mayor inversión de
tiempo solo la primera vez, ya que las siguientes veces se reutiliza el mismo script,
de manera que las pruebas automatizadas se completan más rápidamente que las
manuales, con una menor inversión de tiempo. Esto está acorde con lo que
menciona Sharma en su estudio [29].
A pesar de los buenos resultados obtenidos por las pruebas automatizadas
en términos del retorno de la inversión, estas no pueden reemplazar por completo
a las pruebas manuales. Esto debido a que, si bien la herramienta de
automatización tuvo un desempeño del 100% en la detección de errores, se
encontraron casos donde las pruebas manuales encontraron errores accidentales
para los cuales no se tenía intención de hallar, como lo fueron los dos casos
donde hubo problemas con la interfaz gráfica. Una posible mejoría para la
herramienta automatizada sería la de poder realizar validaciones sobre los
76 componentes gráficos de la página web sin necesidad de desarrollar un script
complejo que valide cada aspecto de la interfaz posterior a cada paso de la
prueba. Sí se pudo observar una ventaja de la automatización para las pruebas
combinatorias debido a que se reducen las probabilidades de que se omitan
combinaciones por error. Esto confirma lo mencionado por Berner et al [28] en su
estudio: las pruebas automatizadas pueden encargarse de las tareas repetitivas
para permitirle al QA enfocar su atención en tareas más productivas.
En cuanto a las pruebas de regresión, se observó que las pruebas
manuales tienen una gran desventaja en comparación a las pruebas
automatizadas. Gracias al uso de los scripts, las pruebas automatizadas pudieron
correrse durante cada nueva iteración del ciclo de vida del SUT posterior a su
liberación. Esto también fue observado en varios de los trabajos analizados [28,
30]. Las pruebas manuales, por otro lado, solo se realizaron sobre cada nuevo
cambio incremental, lo que significa una cobertura de código muy inferior a la
obtenida por las pruebas automatizadas. La inversión también es
significativamente distinta entre ambos tipos de pruebas, debido a que la
herramienta de automatización es capaz de ejecutar el script sin necesidad de una
persona, mientras que las pruebas manuales, por su naturaleza, requieren de una
inversión de tiempo proporcional a la cantidad de pruebas que se ejecuten. Por lo
tanto, entre más veces se necesite repetir una prueba, mayor es el retorno
generado por la automatización. Esto confirma lo encontrado por Sharma [29],
quien menciona que los beneficios a largo plazo tienden a incrementarse por
medio de la utilización de pruebas automatizadas.
Se puede concluir también que la herramienta de automatización ofrece
ciertas ventajas durante la realización de ciertas pruebas. Por ejemplo, la
herramienta permite crear listas de entradas que pueden reutilizarse para agilizar
la creación del script. Esto es de particular utilidad durante la ejecución de pruebas
de seguridad, ya que se pueden crear diccionarios de contraseñas o palabras
77 clave para validar las medidas de seguridad del SUT. Por otro lado, como se
menciona en otros estudios [28, 30], las pruebas automatizadas tienen ventaja en
tareas que son repetitivas, lo cual fue observado en la ejecución de las pruebas
combinatorias. La herramienta de automatización permite establecer por medio del
scripting la lista de combinaciones que se desea utilizar durante un caso de
prueba, y a diferencia de las pruebas manuales, no permite la omisión de
combinaciones si estas fueron programadas correctamente en el script. Más aún,
el reporte generado por la herramienta de automatización indica qué
combinaciones fueron ejecutadas, por lo que, si hubo una combinación que no se
ejecutó, esto queda evidenciado en el reporte y permite al QA darse cuenta del
error para corregirlo. Por otro lado, las pruebas manuales resultaron más
apropiadas que las pruebas automatizadas para las pruebas de localización, ya
que para validar la traducción de la interfaz gráfica, se deben introducir todas las
hileras traducidas en el script para validar que estas aparezcan correctamente en
el SUT. Este trabajo es más fácil de hacer manualmente, ya que se puede hacer
una comparación visual de las hileras para determinar rápidamente si la traducción
es correcta o no.
En términos de la mantenibilidad de los scripts, la necesidad de modificarlos
depende de la naturaleza del SUT. En la organización se pueden encontrar
proyectos que no tienen necesidad de cambios incrementales frecuentes, en cuyo
caso sus scripts no requirirían actualizaciones constantes para seguir siendo
útiles. Sin embargo, también se pueden encontrar proyectos altamente
cambiantes, para los cuales es de esperar que el tiempo de mantenimiento de sus
scripts sea mayor. Por lo tanto, la necesidad de invertir en modificar los scripts de
pruebas va a depender de la naturaleza del SUT al que aplican.
78
7. Trabajo futuro Con base en los hallazgos de esta investigación, se recomienda a la
organización la implementación de un modelo híbrido de pruebas que utilice
pruebas automatizadas y manuales de forma combinada, para aprovechar las
ventajas de cada una en la detección de errores. Como trabajo futuro se puede
realizar un análisis del retorno sobre la inversión de distintos modelos de
decisiones dentro de la organización, para aplicar el modelo que sea más
adecuado. El modelo que genere un mayor retorno podría ser aplicado durante la
fase de planeamiento de los proyectos con el fin de maximizar los beneficios
obtenidos durante la realización del control de calidad.
Como resultado de esta investigación, la organización además decidió
empezar a utilizar la herramienta de automatización en varios proyectos, con el fin
de obtener más retroalimentación por parte de los QAs sobre posibles mejoras a la
herramienta. Además, 3 nuevos QAs se inscribieron en el entrenamiento para
aprender a utilizar la herramienta de automatización. Posteriormente, se realizará
una investigación interna con un análisis similar a este estudio para observar el
retorno obtenido por las pruebas automatizadas ejecutadas en aplicaciones que
no sean web.
79
8. Referencias [1] Software Fail Watch: 2016 in review. Tricentis. (2017)
[2] IEEE Standards 730-2014 - IEEE Standards for Software Quality Assurance
Processes. IEEE Computer Society. (2014)
[3] Clapp, J. Software Quality Control, Error Analysis, and Testing. William Andrew
In. (1995)
[4]. Grossman, Edward. Puttin' the Queue in QA. Queue 3.1 (2005)
[5] Sahaf, Z., Garousi, V., Pfahl, D., Irving, R., Amannejad, Y. When to Automate
Software Testing? Decision Support Based on System Dynamics: An Industrial
Case Study. Proceedings of the 2014 International Conference on Software and
System Process. Estados Unidos. (2014).
[6] Ramler, Rudolf, and Klaus Wolfmaier. Economic perspectives in test
automation: balancing automated and manual testing with opportunity cost.
Proceedings of the 2006 international workshop on Automation of software tests.
(2006)
[7] Marick, B. When should a test be automated. Software testing analysis & review
conference (STAR East). (1999)
[8]. Dobles, J. I. Datos históricos sobre remuneración económica de la
organización para la cual se realizó el estudio. Confidencial. (2017)
80 [9] Itkonen, J., Mantyla, M., Lassensius, C. Defect Detection Efficiency: Test Case
Based vs Exploratory Testing. First International Symposium on Empirical Software
Engineering and Measuring. (2007)
[10] Kolawa, A., Huizinga, D. Automated Defect Prevention: Best Practices in
Software Management. IEEE Computer Society Press, p. 74. (2007)
[11] Gallivan, M. Organizational adoption and assimilation of complex technological
innovations: development and application of a new network. ACM SIGMIS
Database: The database advances in information systems. Volumen 32, edición 3.
(2001)
[12] IEEE Standard 12207-2017 - Systems and software engineering - Software life
cycle processes. IEEE Computer Society. (2017)
[13] Feldman, S. Quality Assurance: Much More Than Just Testing. Revista
“Queue - Quality Assurance- Volumen 3, Edición 1. (2005)
[14] Khan, M. E. Different Approaches to White Box Testing Technique for Finding
Errors. International Journal of Software Engineering and its Applications. Volumen
5, Edición 3. (2011)
[15] Limaye, M. G. Software Testing - Principles, Techniques and Tools. Tata
McGraw Hill Education, p. 216. (2009)
[16] Myers, G. J. The Art of Software Testing. Wiley-Interscience, 3ra ed. (2011)
[17] Pesante, L. Introduction to Information Security. Carnegie-Mellon University.
(2008)
81 [18] Carbanak APT - The Great Bank Robbery. Kaspersky Lab. (2015)
[19] Coopeland, L. A Practitioner’s Guide to Software Test Design. Artech House
Publishers. (2004)
[20] Lewis, W. E. Software Testing and Continuous Quality Improvement, 2da ed.
Auerbach Publications. (2005)
[21] The Institute of Electrical and Electronics Engineers, Inc. IEEE Std. 610.12-
1990(R2002) Standard Glossary of Software Engineering Terminology. (2002)
[22] Pezzè, M. y Young, M. Software Testing and Analysis: Process, Principles,
and Techniques. Wiley. (2008)
[23] Naik, K. y Tripathy, P. Software Testing and Quality Assurance: Theory and
Practice. Wiley. (2008)
[24] Burnstein, I. Practical Software Testing. Springer-Verlag, (2003)
[25] P. Jorgenson. Software Testing - A Craftman’s Approach. CRC Press. New
York, NY. (1995)
[26] Kuhn, R. Introduction to Combinatorial Testing. National Institute of Standards
And Technology Gaithersburg. Carnegie-Mellon University. (2011)
[27] Emam, K. E. The ROI of Software Quality. Auerbach Publications. (2005)
[28] Berner, S., Weber, R., Keller, R. K. Observations and lessons learned from
automated testing. Proceeding of the 27th International conference on Software
Engineering. (2005)
82 [29] Sharma, R.M. Quantitative Analysis of Automation and Manual Testing.
International Journal of Engineering and Innovative Technology. (2008)
[30] Hoffman, D. Cost Benefits Analysis of Test Automation. Software Quality
Methods, LLC. (1999)
[31] Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., Wesslén, A.
Experimentation in Software Engineering. Springer. (2012)
[32] Lethbridge, T.C., Sim, S.E., Singer, J. Studying software engineers: data
collection techniques for software field studies. Empir. Softw. Eng. 10. (2005)
