See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/296480694

Evaluación y selección de técnicas de prueba de software

Article · October 2016

CITATIONS READS
0 522

2 authors:

Ronald Ibarra Glen Dario Rodriguez

Universidad Nacional Agraria de la Selva, Tingo María Universidad Nacional de Ingeniería (Peru)
2 PUBLICATIONS   0 CITATIONS    44 PUBLICATIONS   148 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Generation of software test cases and test suites View project

Software Testing Techniques Recommender System View project

All content following this page was uploaded by Ronald Ibarra on 14 March 2017.

The user has requested enhancement of the downloaded file.

Evaluación y selección de técnicas de prueba de software
Ronald Ibarra
Facultad de Ingeniería Sistemas e Informática
Universidad Nacional Mayor de San Marcos
Lima, Perú
Facultad de Ingeniería Informática y Sistemas
Universidad Nacional Agraria de la Selva
Tingo María, Perú
ronald.ibarra@unmsm.edu.pe
ronald.ibarra@unas.edu.pe
ABSTRACT
Software testing is a vital activity and a determining factor for
success of a given project since testing allow stakeholders to know
if the product meets their expectations and requirements,
additionally, the cost of testing is very significant in relation to
development cost, therefore is important to select the most suitable
testing techniques and tools in a given project to find defects at
less cost possible; however in many projects, the practitioners
adopt the same testing technique/tool used in past projects or any
available without knowing the testing technique attributes. As a
theoretical basis for future research, in this article we present an art
state about the testing techniques evaluation and selection which
contain a set of characterization schemas and a comparison
between approaches for lead primary studies leading to build
knowledge bases or repositories and in other way we present the
existing methods and approaches about the informed selection of
testing techniques for a given project based on repositories
information.
Keywords: Software testing techniques selection, software testing
techniques repositories, characterization schema.
1. INTRODUCCION
El testing es el componente mas importante de cualquier proceso
de ingeniería de software para producir aplicaciones de alta calidad
dado que apunta a encontrar errores en el objeto probado y da
confianza en su correcto comportamiento mediante la ejecución del
objeto probado con valores de entrada. [14]
Las pruebas de software son caras para la industria y siempre están
limitadas por tiempo y esfuerzo. Aunque hay muchas técnicas de
pruebas, actualmente no hay directrices cientificas para la selección
de las técnicas apropiadas en diferentes dominios y contextos [7].
Aunque la cuestión de “cuáles son las técnicas más adecuadas para
desarrollar el banco de casos de prueba para probar un Sistema
dado” aparentemente posee enormes dificultades, esta es sin
embargo una cuestión con la que lidian los testers cada vez que
tienen que probar un sistema. ¿Y cómo se responde actualmente a
esta cuestión?: Ni sistemáticamente ni con directrices bien
definidas. En efecto, de todas las técnicas existentes, algunas nunca
son consideradas para usarse y otras son usadas una y otra vez en
diferentes proyectos sin siquiera ser examinadas después de su uso
sean o no realmente útiles [16].
Glen Rodriguez
Facultad de Ingeniería Industrial y de Sistemas
Universidad Nacional de Ingeniería
Lima, Perú
grodriguez@uni.edu.pe
Según Vegas y Basili en [16], las decisiones tomadas por los
desarrolladores no son tomadas tan al azar en la medida de su
conocimiento de la técnica. Hay dos razones principales por las que
los desarrolladores no toman buenas decisiones:
- La información disponible sobre las técnicas está normalmente
distribuida a través de diferentes fuentes de información
(libros, artículos e incluso la gente). Esto quiere decir que los
desarrolladores no tienen una idea general de que técnicas están
disponibles y de toda la información de interés acerca de cada
técnica de prueba.
- No tienen acceso a información pragmática concerniente a cada
técnica de prueba a menos que ellos la hayan usado antes. Los
desarrolladores no tienden a compartir con otros el
conocimiento que adquieren al usar técnicas de pruebas. Lo
cual quiere decir que ellos pierden la oportunidad de aprender
a partir de las experiencias de otros.
Existen varios esfuerzos en el mundo académico y en la industria
para contar con marcos de trabajo que permitan conducir estudios
primarios para caracterizar las técnicas de pruebas de software de
manera uniforme para generar bases de conocimiento y evidencia
incremental útil para la realización de estudios secundarios de
manera cotidiana en la industria del software con la finalidad de
evaluar las técnicas y herramientas de pruebas de software en
contextos particulares de modo que se garantice principalmente
efectividad y eficiencia en el proceso de pruebas.
Existen también métodos y estrategias que se proponen apoyar el
proceso de selección de una o más técnicas de pruebas de software
para un contexto dado por las características del proyecto y sistema
a probar.
Según se muestra en la Figura 1, el presente trabajo pretende
ofrecer una visión integradora de los trabajos realizados en pro de
una selección informada de técnicas y herramientas de testing de
software; a manera de soporte teórico a futuros trabajos de
investigación en el tema. Se ha realizado una revisión preliminar
de literatura en cuanto a esquemas de caracterización, métodos,
protocolos y frameworks de la realización de estudios primarios, y
métodos y herramientas para realizar estudios secundarios.
En la sección 2, se muestran los trabajos orientados a la
caracterización de técnicas y herramientas de software. En la
sección 3 se presentan tres marcos de trabajo orientados al diseño
de estudios primarios como casos de estudio y experimentos.
Finalmente en la sección 4 relacionada a métodos y herramientas
para conducir estudios secundarios, se presentan dos métodos para
la selección y recomendación de técnicas de testing de software y
un método para la recomendación de herramientas de testing de
software.
 se tiene acerca de las técnicas de testing. El esquema de
caracterización describe las propiedades de todas las técnicas de
Métodos y
acuerdo al mismo patrón. El esquema hará posible construir un
herramientas
Marcos de para estudios repositorio conteniendo todas las técnicas de interés para una
trabajo para secundarios organización dada.
Esquemas de estudios
Caracterización primarios Tabla 1 – Esquema utilizado en [8]
Elemento Atributo Valor
Aplicabilidad Tipo de Procedural, OO, Independiente
Figura 1- Hacia la selección informada de técnicas de testing lenguaje
Tipo de Basado en componentes, Manejador
En [3], [16] y [17], se menciona la necesidad de realizar estudios
software de base de datos
primarios que proporcionen una base de evidencia y/o
Método Entrada Código fuente, Código intermedio
conocimiento como soporte al proceso de evaluación y selección
para máquinas virtuales, Código de
de técnicas y/o herramientas de testing (La Figura 2 ilustra este máquina, Entradas en ciertos
proceso) que realizan los profesionales de la industria e formatos
investigadores. El proceso de selección podría realizarse mediante Enfoque Control de flujo, Firewall, Slicing,
estudios secundarios, consiguiendo de este modo tomar decisiones Basado en dependencia
de manera informada, lo cual reduciría los riesgos asociados a una Granularidad Sentencia, Función, Clase, Modulo,
inadecuada selección. Componente
Para la realización de estudios primarios, en [17] se han Propiedades Habilidad de Segura
identificado varias barreras como: el consumo de tiempo, costos , detección
resistencia de las empresas a participar en casos de estudio; sin Reducción de Minimización
costos
embargo estas deben superarse para lograr acceder a las ventajas
que supone la toma de decisiones informadas como por ejemplo:
contar con información estructurada que permita realizar Tabla 2 - Esquema presentado en [7]
comparaciones entre técnicas y/o herramientas de testing, Medida de eficiencia
minimizar los riesgos por una sección inadecuada en un contexto 1. Tiempo actual para cada fase
dado, tomar decisiones en base a evidencia y experiencia de forma 2. Tiempo para detector defectos y/o fallas, tiempo para detector el tipo
de defecto.
objetiva, dar lugar al desarrollo de herramientas que den soporte a
3. Cuánto tiempo toma encontrar el primer defecto o falla
la toma de decisiones, entre otros.
4. Opinión personal de los sujetos sobre cada tarea en el proceso (fácil,
difícil, posee problemas secundarios)
5. Tiempo para crear manualmente los casos de prueba (para uno, el
primero y variantes)
6. Cuantos casos de prueba únicos e instancias de casos de prueba se
crean.
Medida de eficacia
1. Número absoluto de cuantos defectos no inyectados, fueron
encontrados comparados con los defectos inyectados.
2. Cantidad de defectos aislados por tipo y severidad del total de
defectos encontrados.
3. Estimación de cobertura
Aplicabilidad de la técnica
1. En qué fase son encontrados(distribuidos) los defectos en el tiempo
2. Juicio personal del sujeto de cada tarea en el proceso (Fácil, difícil,
plantea problemas secundarios, etc.)
3. Facilidad de aprendizaje de la técnica (fácil, difícil, posee problemas
secundarios, etc.)
4. Niveles (código, componente, integración, sub sistema, sistema)
donde es posible usar la técnica.
Figura 2 – Creando un cuerpo de evidencia [17] 5. Generalidad de la técnica
a. Contexto (Sistema operativo, hardware, dominio, etc.)
b. Lenguaje y restricciones (C, C++, Java, y versión/compilador)
2. ESQUEMAS CARACTERIZACION DE 6. Número de variantes de la técnica dentro de cada alcance
TECNICAS Y HERRAMIENTAS DE 7. Evaluación de aplicabilidad de automatización de la técnica, lo cual
TESTING DE SOFTWARE es una evaluación cualitativa. La medida se encuentra en el rango a
partir de (mala, lenta, ineficaz) en una escala flotante hasta (buena,
Vegas en [16], propone un esquema de caracterización como una rápida y eficaz)
solución al problema de cómo identificar información relevante 8. Evaluación del proceso completo.
para la selección de técnicas de testing de software, indica además
que la solución no está limitada a identificar los criterios de Se han encontrado múltiples trabajos que proponen esquemas de
selección útiles, sino tambien provee una infraestructura para caracterización como artefacto base para la realización de estudios
almacenar la información identificada y especificada para cada primarios y secundarios. Estos esquemas organizan sus atributos
técnica existente con el bjetivo de ayudar a los profesionales de bajo distintos criterios como: aplicabilidad, método, agente,
testing con la selección y a los investigadores en testing de herramientas, técnicas, operación, entre otros.
software a enfocar sus investigaciones en el conocimiento que no
El esquema de la Tabla 1, ha sido utilizado para caracterizar 28 Tabla 4 - Esquema de caracterización MBT [5]
técnicas de testing de regresión en base a su aplicabilidad, método Caracterización de técnica Caracterización de proyecto
y propiedades. Modelo usado para representar el Modelo de estructura y
El esquema de la Tabla 2, ha sido presentado como un conjunto de comportamiento/estructura del comportamiento provisto por el
preguntas de medición y control para determinar eficiencia, software a probar. proyecto de software
eficacia y aplicabilidad de técnicas de testing como parte de un Criterio usado para medir la cobertura No aplica.
marco de trabajo experimental para conducir estudios primarios. de las pruebas.
Tabla 3 - Esquema de caracterización presentado en [16] Criterio usado para generar casos de No aplica.
prueba automáticamente.
Elemento Atributo Descripción Entradas requeridas para iniciar el uso No aplica.
Agente Conocimiento Conocimiento requerido para poder de una técnica MBT
aplicar la técnica Limitaciones/restricciones para usar No aplica.
Experiencia Experiencia requerida para poder aplicar una técnica MBT
la técnica Tipo de testing en que la técnica se Tipo de técnica de testing a
Herramientas Identificador Nombre de la herramienta y del puede aplicar. aplicar
fabricante Nivel de testing en el cual la técnica Niveles de testing a ser aplicados
Automatización Parte de la técnica automatizada por la MBT es aplicada. en el proyecto de software
herramienta Formato de las salidas generadas por Tipos de defectos a ser revelados
Costo Costo de la herramienta compra y una técnica MBT.
mantenimiento Características de calidad de software Características de calidad de
Entorno Plataforma (software y hardware) y que la técnica MBT puede evaluar. software requeridas para el
lenguaje de programación que opera la desarrollo.
herramienta Existencia (o no) de una herramienta Herramientas de soporte.
Técnica Soporte El soporte prestado por el fabricante de la que soporte la técnica.
herramienta Costo requerido para utilizar la No aplica.
Comprensibilidad Es o no la técnica fácil de entender herramienta de soporte.
Costo de Cuánto esfuerzo se necesita para aplicar Plataforma de ejecución para usar la No aplica.
aplicación la técnica herramienta de soporte.
Entradas Entradas necesarios para aplicar la Plataforma de ejecución del software Plataforma de ejecución del
técnica bajo el cual la técnica puede correr. software.
Criterio de Generación de casos de prueba y la regla Paradigma de desarrollo de software Paradigma de desarrollo
adecuación de parada bajo el cual la técnica MBT puede adoptado en el proyecto de
Costo para la Costo para identificar los datos de prueba probar software. software.
prueba de datos Lenguaje de programación con el cual Lenguaje de programación usado
Dependencias Relaciones de una técnica con otra la técnica MBT puede probar para el desarrollo del software.
Repetibilidad Si dos personas generan los mismos casos software.
de prueba Necesidad de desarrollo de modelos No aplica.
Casos de Fuentes de Donde encontrar información acerca de la intermedios durante el proceso de
prueba información técnica generación de pruebas.
Completitud La cobertura proporcionada por el Tecnología usada para modelar las Tecnología usada para el
conjunto de casos pruebas generadas. modelado del software.
Precision Cuantos casos de pruebas repetidas Necesidad de resultados de uso de la No aplica.
genera la técnica técnica MBT en proyectos de
Eficacia Que capacidad del conjunto de casos software anteriores.
debe tener para detectar defectos Resultados históricos de uso de una No aplica.
Tipo de defecto Tipos de defectos detectados en el técnica MBT en proyectos de
sistema software anteriores.
Número de casos Número de casos generados por el Proporción de pasos automatizados No aplica.
generados tamaño de la unidad de software por número total de pasos en su
Objeto Elemento Elementos del sistema sobre el que actúa proceso de generación de pruebas.
la prueba Indicación de evaluación No aplica.
Aspecto Funcionalidad del sistema a ensayar experimental de la eficiencia y
Tipo de software Tipo de software que puede ser probado escalabilidad de la técnica MBT.
usando la técnica Nivel de complejidad para ejecutar No aplica.
Lenguaje de Lenguaje de programación que se puede pasos no automatizados durante el
programación utilizar proceso de generación de pruebas.
Método de Método de desarrollo o ciclo de vida a la Existencia de mecanismos de No aplica.
desarrollo que está vinculado trazabilidad entre los modelos del
Tamaño Tamaño que el software debe tener para software y las pruebas generadas.
poder utilizar la técnica Habilidades/conocimiento requeridos Habilidades provistas por el
Proyecto Proyectos de Proyectos anteriores en los que la técnica para usar la técnica MBT. equipo de testigo.
referencia se ha utilizado Existencia de modelos de verificación No aplica.
Herramientas Las herramientas utilizadas en proyectos para evaluar los modelos del software
usadas anteriores antes de la generación de las pruebas.
Personal El personal que trabajaron en proyectos
anteriores
Satisfacción Opinión Opinión general sobre la técnica después El esquema de la Tabla 3, consta de 32 atributos y ha sido utilizado
de haber usado en una versión anterior en [15] para la construcción de un catálogo
Beneficios Beneficios del uso de la técnica de 13 técnicas de testing de software.
Problemas Problemas con el uso de la técnica
El esquema de la Tabla 4, ha sido desarrollado para soportar la En la Figura 1, se puede observar la referencia a los trabajos que
selección de técnicas de testing basado en modelo (MBT: Model presentan esquemas de caracterización, la cantidad de atributos de
Based Testing). Un subconjunto de los atributos del esquema son cada uno y la relación entre algunos de ellos, destacando el
utilizados para encontrar el nivel de adecuación entre un proyecto esquema presentado por Vegas en [16], ya que ha sido la base para
de software y las técnicas de testing, estos atributos, tienen una el desarrollo de los esquemas presentados en [17] y [5] y que
redacción diferente para caracterizar al proyecto y para caracterizar además incluye entre sus atributos la mayoría de los presentados en
a la técnica por lo que en la tabla se presenta a manera de mapeo. los demás esquemas, con excepción a [3], que es
específicamente centrado en el tipo de defectos.
El esquema de la ¡Error! La autoreferencia al marcador no es
válida., se ha presentado como parte de un framework
[8] [9] [19]
metodológico para la realización de estudios primarios mediante
casos de estudio. 17 atributos 7 atributos 32 atributos
El esquema de la Tabla 6 se ha presentado para caracterizar
técnicas de testing en un contexto experimental orientado a
alinear un sistema a probar con las técnicas de testing en base al [4] <<basado en>>
tipo de defectos ODC(Orthogonal Defect Classification) que el 3 atributos [20] en [6]
sistema podría contener y que las técnicas podrían detectar.
22 atributos 25 atributos

Tabla 5 - Esquema de caracterización presentado en [17]

Elemento Atributo Figura 3- Esquemas de caracterización de técnicas y
Prerequisitos Estática o dinámica herramientas de testing
Tipo de software
Fase de ciclo de vida 3. MARCOS DE TRABAJO PARA
Entorno
Escalabilidad ESTUDIOS PRIMARIOS
Entradas En la Tabla 7, se presenta una comparación de 3 marcos de trabajo
Conocimiento para estudios primarios.
Experiencia Tabla 7 - Marcos de trabajo para estudios primarios
Resultados Salidas
Completitud Framework / Comparación de Evaluación de Basado en tipos
Método técnicas de técnicas y de defectos ODC
Eficacia
testing [7] herramientas [3]
Tipos de defectos
de testing [17]
Tamaño del banco de pruebas
Publicado 2006 2012 2012
Operación Interacción
Tipo Metodológico Metodológico Organizacional
Guía al usuario
Orientado a Diseño de Diseño de casos Diseño de
Fuentes de información
experimentos. de estudio experimentos.
Tareas de aplicabilidad
Comprensibilidad Alcance Técnicas Técnicas y Técnicas
Satisfacción subjetiva Herramientas
Esfuerzo Limitado a SI NO SI
Madurez inyección de
defectos
Obtención de la herramienta Obtención de la herramienta
Criterios de Eficacia Eficacia Habilidad para
evaluación Eficiencia Eficiencia detectar defectos
Aplicabilidad Satisfacción Costo detección
Tabla 6 - Esquema de caracterización en [3] subjetiva defectos
Capacidad de detección de defectos Actitud hacia tipo
1. ¿Cuál de las técnicas comparadas detecta el mayor porcentaje de de defecto
defectos respecto a los presentes inicialmente? Base de No indicada ISO 9241-11: ODC (Chillarege
2. ¿El porcentaje de fallos detectados depende de la cantidad inicial de criterios de 1998 et al., 1992)
fallos en el programa? medición
3. ¿El porcentaje de defectos detectados depende del tipo de software Instanciación Académica Académica , en Académica
elegido? la industria
Costo de detección de defectos Técnicas para Random, Fast Search based Functional
1. ¿Cuál de las técnicas detecta el mayor número de defectos en el las que fue Anti- structural Statistical
mismo tiempo de prueba (tasa: El mayor # de defectos/h ) asumiendo instanciado Random, testing, Search Stress
el esfuerzo personal como medida de costo (hora persona). Equivalence Based Robustness
2. El ratio #defectos/h (tasa de detección) depende de la cantidad classes, Boundary Functional
inicial de defectos? value, heuristic Testing, Web
3. ¿La tasa de detección depende del tipo de software elegido? method testing: model-
Actitud hacia el tipo de fallos based testing,
1. Dado un tipo de defecto, ¿Cuál de las técnicas disponibles detecta el coverage-based
mayor porcentaje de defectos de tal tipo (son los defectos de un tipo as testing, black-
fácilmente detectable por una técnica en particular que con otra)? box testing and
2. ¿Es una técnica dada más propensa a detector algún tipo de defecto state-based
que otras? testing
En [7], Eldh propone un framework para comparar la eficiencia,
eficacia y aplicabilidad de técnicas de testing de software,
orientado al diseño de experimentos, el cual consiste en los
siguientes pasos: (1) preparar muestras de código con defectos
conocidos, (2) seleccionar una técnica de testing, (3) realizar el
experimento aplicando la técnica y recolectar datos, finalmente (4)
analizar los datos, comparar las técnicas y evaluar resultados. El
experimento debe repetirse con distintas técnicas y con nuevas
muestras de código (con nuevos defectos inyectados) hasta tener
suficientes datos para realizar sugerencias.
El método indicado propuesto por Cotroneo en [3] comprende dos
grandes pasos: el primero, consiste en construir un conjunto de
modelos predictivos para caracterizar una aplicación de software
desde la perspectiva del tester quien es el interesado en saber
cuántos defectos tiene la aplicación y de qué tipo son los defectos
usando ODC(Orthogonal Defect Classification); el paso siguiente
define un procedimiento basado en experimentos controlados para
caracterizar las técnicas de testing en términos de tipos de defectos
ODC que son propensas a detectar; una vez elegido el conjunto
de técnicas de interés, la caracterización consiste en evaluar su
performance respecto a tipos de defectos ODC que potencialmente
pueden afectar al sistema, costo de detección y eficacia en la
detección. De este modo podría relacionarse el Sistema a probar
con las técnicas de testing mediante el tipo de defectos ODC que el
sistema es propenso a contener y que una o más técnicas tiende a
detectar.
Como una mejora a [18], en [17] se presenta un framework
metodológico orientado al diseño de casos de estudio, cuyos
criterios de evaluación son la eficiencia, la eficacia y la satisfacción
subjetiva; el framework consta de procedimientos e indicaciones
exhaustivas organizados en siete partes: (1) Objetivo - ¿Que se
espera conseguir?, (2) Casos o tratamiento - ¿Que se estudia o
evalúa?, (3) Sujetos - ¿Quiénes aplican las técnicas/herramientas?,
(4)Objetos - ¿Cuáles son los proyectos piloto?, (5) Variables y
métricas - ¿Qué datos recolectar?, (6)Protocolo - ¿Cómo ejecutar
el estudio y recolectar los datos? y (7)Amenazas a la validez de los
estudios realizados.
A continuación se resaltan algunos aspectos en que se parecen y/o
diferencian los frameworks arriba mencionados:
 Metodológico vs. Organizacional: en [7] y [17] se presentan
frameworks metodológicos, mientras que en [3] se presenta un
framework organizacional. Un framework organizacional,
generalmente está enfocado en aportar en el proceso de
evaluación de técnicas de testing mediante esquemas de
caracterización, líneas guías, precauciones a tener en cuenta para
que los estudios sean diseñados cuidadosamente minimizando
los factores de confusión; a diferencia del metodológico que
propone: el cómo evaluar, el cómo definir las preguntas de
investigación, las variables que deben medirse, y que amenazas
a la validez especificas pueden presentarse.
 Utilidad: Un framework puede utilizarse para realizar estudios
experimentales tal como se propone en [3] y [7] o para la
conducción de casos de estudio como se propone en [17]. Es
importante resaltar que en el caso de frameworks orientados al
diseño de experimentos para la evaluación de técnicas de testing,
generalmente requieren hacer uso de la inyección de defectos,
mientras que en los de casos de estudio, esto es opcional.
 Factores de evaluación: los 3 frameworks encontrados
presentan coincidencias a alto nivel en cuanto a los factores de
evaluación de las técnicas y/o herramientas de testing de
software, sin embargo difieren en cuanto a los atributos o
indicadores necesarios para su medición. En [17], la eficiencia es
determinada a partir de: tiempo para el aprendizaje de la técnica,
tiempo para diseñar los casos de prueba, tiempo para instalar la
infraestructura de pruebas necesaria para la técnica, tiempo para
probar y observar fallas, tiempo para identificar tipos de defectos
y causas para cada falla observada. Mientras que en [7] la
eficiencia es determinada a partir de: tiempo (planificación,
implementación, ejecución), tiempo para detectar defectos e
identificar su tipo, tiempo para encontrar el primer defecto o la
primera falla, juicio de cada sujeto participante en las tareas de
prueba (fácil, difícil, etc.), tiempo para crear casos de prueba
manualmente, cantidad de instancias únicas de los casos de
prueba son creadas (numero por caso de prueba/número de
variantes). La eficacia por su lado en [17], se determina a partir
de: número de casos de prueba diseñados o generados, número
de casos de prueba generados inválidos, número de casos de
prueba generados repetidos, numero de fallas observadas,
numero de defectos encontrados, numero de falsos positivos,
numero de falsos negativos, tipo y causa de los defectos
encontrados, estimación de cobertura; mientras que en [7] se
determinar a partir de: Numero de defectos encontrados
comparado con los inyectados, defectos encontrados por cada
nivel de severidad del defecto, estimación de cobertura de flujo
de datos y control de flujo. Es importante mencionar la similitud
entre satisfacción subjetiva y aplicabilidad que presentan como
factores de evaluación los framewoks propuestos en [17], y [7]
respectivamente; el primero considera como criterio de
evaluación la satisfacción subjetiva a partir de indicadores como:
percepción de complejidad, intención de uso futuro, facilidad de
uso, necesidad de soporte adicional, percepción de
inconsistencias, facilidad de aprendizaje, etc., utilizando para su
medición un cuestionario denominado System Usability Score
(SUS), diagramas de Ven y nube de palabras para agrupar
reacciones de los sujetos, así como reacciones faciales
emocionales durante las entrevistas y por ultimo opiniones
subjetivas acerca de las técnicas y / o herramientas evaluadas; el
segundo framework a su vez contempla como criterio de
evaluación, la aplicabilidad a partir de indicadores como: fase en
la que se encuentran los errores, facilidad de aprendizaje, niveles
donde es posible usar la técnica, evaluación del proceso
completo, generalidad de la técnica(SO, hardware, dominio,
lenguajes soportados) , etc., aunque no se indica las estrategias o
técnicas aplicadas para su medición. Más de un indicador
considerado en ambos frameworks se contempla una medición
subjetiva de la eficiencia y eficacia como complemento para
determinar la satisfacción y/o aplicabilidad de una técnica o
herramienta de testing. Mencionaremos de forma separada los
indicadores utilizados en [3], dado que sus factores de evaluación
difieren de los otros frameworks por lo menos a alto nivel; así la
habilidad para detección de defectos se determina a partir de:
porcentaje de defectos detectados independientemente de su tipo;
el costo de detección de defectos se determina por: defectos
detectados en un tiempo dado respecto al esfuerzo
(personas/hora), a su vez la actitud hacia el tipo de defectos es
determinado por: % de defectos detectados por tipo y la
propensión a detectar cierto tipo de defecto.
 Instanciaciones: se han encontrado múltiples instanciaciones
aunque a excepción del framework propuesto en [17] que ha sido
instanciado en la industria en proyectos reales mencionados en
[18]:2011, [17]:2012, [1]:2014 y [2], [9]:2014, los demás han
sido instanciados en ambientes académicos según se indica en
[7]:2006 y [3]:2012.
4. ESTUDIOS SECUNDARIOS
Según [17], existe una necesidad real en la industria por tener guías
sobre que técnicas de testing usar para distintos objetivos de
testing, y cuan usables (eficaces, eficientes, satisfactorias) son estas Tal como se muestra en la Tabla 8, se han encontrado tres trabajos
técnicas. Actualmente, estas guías no existen, tales guías podrían asociados a la evaluación y selección de técnicas y herramientas de
obtenerse realizando estudios secundarios sobre una base de pruebas de software: en [16]:2005 presentan un esquema de
evidencia consistente en la evaluación de casos de estudio y caracterización y un protocolo (Instanciado en [11]:2013) que
comparando técnicas y herramientas de testing. consiste en: (1)identificar los valores deseados de los atributos de
Para la selección o evaluación de técnicas de testing mediante las técnicas según el esquema de caracterización, así como la
estudios secundarios, es muy importante la homogeneidad en el eficacia y los tipos de defectos a encontrar, (2) identificar si hay
diseño y conducción de los estudios primarios, es decir que en lo otros atributos que pueden restringir el uso de la técnica a elegir
posible deben haberse realizado usando un mismo framework, (por ejemplo: personal necesario), (3) comparar los valores
checklist, esquema de caracterización, entre otros. [16] . deseados con los valores de cada técnica que contiene el repositorio
4.1. Métodos de evaluación y selección de instanciaciones preexistente, (4) si no se obtienen técnicas que
cumplan con los valores deseados, se debe relajar alguna
Tabla 8 - Métodos de evaluación y selección restricción del paso (3), (5) examinar los valores de los atributos de
Método/Herra Characterizati Porantim [5] MENTOR [13] las técnicas preseleccionadas para tomar una decisión
mienta on schema Como una mejora al método presentado en [4], en [5] se presenta
[16] un método limitado a Model-Based Testing (MBT) soportado por
Publicado 2005 2014 2014
su respectiva herramienta “porantim” que a partir de un catálogo
Alcance Técnicas de Técnicas de Herramientas
testing testing basado en de testing
de técnicas de testing, extrae un conjunto de técnicas más
modelo adecuadas para un proyecto dado para luego hacer un análisis de
Mecanismos Comparación Comparación Comparación impacto de usar una técnica o un conjunto combinado de ellas
Análisis de sobre las variables de análisis (cobertura, esfuerzo ahorrado en el
impacto modelado y recursos humanos) y sugerir un conjunto de
Basado en SI SI SI alternativas de combinación sobre las cuales los testers deberán
métricas tomar una decisión final de manera informada. El método utiliza el
Tecnología de Provee un Provee Provee un coeficiente de Jaccard [10] para convertir los valores cualitativos
sugerencia catálogo de alternativas de ranking de los atributos de caracterización en valores cuantitativos como
técnicas combinación con
paso previo a la representación vectorial del proyecto y de cada
análisis de
impacto técnica de testing existente en el catálogo; para luego encontrar el
Soporta NO SI NO nivel de adecuación de una técnica respecto al proyecto utilizando
combinación la medida de distancia euclidiana. Por ultimo MENTOR es un
Criterios de No aplica Software Project NO aplica método soportado por herramientas propuesto por en [13]:2014
análisis para la Coverage (SPC) cuyo objetivo es ayudar en la selección de herramientas de testing
combinación Saved Modelling tomando como base un catálogo de herramientas de testing
Effort (SME) caracterizadas mediante una misma taxonomía preexistente y a
Human Resources partir de los datos de contexto del proyecto y del proceso de
Suitability
desarrollo que sigue la organización, así como un conjunto de
Nivel de Bajo (la Medio (la Medio (La
automatización decisión es decisión es decisión es criterios de selección que representan mayor importancia para los
de la decisión soportada soportada por soportada por interesados, elabora un ranking de las herramientas teniendo, sobre
completamente herramienta y herramienta y el cual los interesados deberá decidir.
por humano) humano) humano)
Métodos y Ad-hoc basada Similitud, kNN AHP, 4.2. Validación de los métodos de selección y
técnicas para en catálogo Basada en MAUT(Multi
toma de catálogo Attribute Utility evaluación
decisión Theory) El esquema de caracterización y protocolo de selección propuestos
Criterios de Completitud, Completitud, Eficacia en [16], se evalúan mediante experimentos que confrontan los
validación del eficacia, eficacia, (Oráculo hecho
método eficiencia, eficiencia. por 3 expertos)
resultados de usar el esquema y protocolo frente a utilizar libros
satisfacción, (Oráculo hecho acerca de técnicas de software para realizar la selección, utilizando
usabilidad. por 2 expertos) como factores de evaluación: eficiencia, usabilidad, satisfacción,
(Esquema vs. completitud y eficacia.
libros) El método Porantim presentado en [5], es evaluado en un
Estrategia de Esquema vs. Esquema vs. MENTOR vs. experimento con dos grupos diferentes, el primero conformado por
validación libros porantim EXPERTOS estudiantes de pregrado con poca experiencia en ingeniería de
Nº atributos del 32 25 No aplica, software y testing, el segundo por estudiantes de doctorado con más
esquema de utiliza
experiencia en ingeniería de software y testing. El objetivo fue
caracterización taxonomía
Alimentación Mediante Mediante revisión No aplica
evaluar la completitud, eficacia y eficiencia de usar Porantim
del revisión de de literatura (julio comparado al método presentado en [16], encontrándose que
repositorio/catá literatura 2006). mejora la efectividad y eficiencia del proceso de selección y que
logo. (2002). puede favorecer la completitud.
Nº de técnicas 13 técnicas 219 técnicas MBT No aplica MENTOR, un método de recomendación de herramientas de
del catálogo diferentes (+200 papers) testing propuesto en [13] es evaluado contrastando los resultados
Representativas de la selección realizada por expertos en testing frente a los
de diferentes proporcionados por MENTOR, encontrándose coincidencias en el
familias
primer nivel del ranking, aunque no necesariamente en los
siguientes niveles, lo cual según los autores podría deberse a que
los expertos conocían y han considerado características de las
herramientas evaluadas que no son necesarias para los proyectos
de los experimentos, mientras que mentor solo tuvo en cuenta los
criterios necesarios para el contexto de los proyectos de los
experimentos.
4.3. Toma de decisiones multicriterio
AHP es una técnica para toma de decisiones que utiliza
comparación por pares, así como el juicio de experto para derivar
escalas de prioridad entre los criterios de selección. Las
comparaciones son realizadas utilizando una escala de juicios
absoluta que representa cuanto más un elemento domina a otro
respecto a un atributo dado. Mediante la creación de una matriz de
comparación de criterios, esta técnica genera un conjunto de pesos
que representan el grado de preferencia entre criterios, luego se
debe realizar una matriz de comparación por cada crierio. (T. Saaty,
2008 referenciado en [13]).
TOPSIS: Es una técnica sobre cuyas bases se ha desarrollado el
método presentado en [5] para ordenar las preferencias según su
similitud con la solución ideal (Technique for Order preference by
Similarity to Ideal Solution), y se usa para calcular las ventajas
relativas a cada alternativa (individualmente); se considera que la
mejor alternativa a elegir es aquella que tiene la distancia más corta
hacia la solución ideal positiva y la más larga hacia la solución ideal
negativa. TOPSIS ha sido utilizada también en otros dominios, tal
como en el trabajo presentado por Zaidan en [19], referido a
selección de paquetes de software EMR usando AHP y TOPSIS,
de manera simialar se ha usado para la selección de sistemas de
gestión de contenido en [12].
MAUT: (Multi Attribute Utility Theory), es un método utilizado en
[13] como complemento a AHP de modo tal que luego de obtener
los pesos que indican la escala de preferencia por los criterios de
selección, se evalúa las alternativas utilizando una función de
utilidad. MAUT asigna un valor de utilidad a cada acción que
representa la preferencia hacia un criterio. De este modo se tendrá
al final una matriz de preferencia en una única escala de 0 a 1.
4.4. Problemas de los métodos de evaluación y
selección
En los trabajos de evaluación y selección de técnicas de testing, se
encuentran varios problemas entre los cuales podríamos
mencionar: (1)la posible subjetividad de los testers para asignar
importancia a los criterios de decisión, (2)la presencia de datos con
valores faltantes en los repositorios preexistentes a partir de los
cuales se hacen sugerencias de técnicas de testing, (3) múltiple
terminología que podría usarse para indicar los valores de los
atributos para caracterizar una técnica o herramienta.
Entre los métodos revisados, se abordan algunos de los problemas
arriba mencionados, por ejemplo: Porantim [5] no pide los pesos
de los atributos a los testers, los obtiene a partir de un estudio
realizado con investigadores, estos pesos fueron obtenidos como
parte de la construcción del esquema de caracterización. Sin
embargo el punto de vista de los investigadores podría no ser un
representativo de los profesionales de testing de software en la
industria; respecto a la diversidad de terminología, en [13] se ha
desarrollado una herramienta Thesaurus, para normalizar la
terminología utilizada en la caracterización de las herramientas de
testing en cuanto a actividades, tareas y conceptos utilizados en el
proceso de desarrollo de software, cuyas equivalencias deben ser
mantenida por un experto del dominio.
4.5. Base de conocimientos y su
mantenimiento
En [15], se presenta un catálogo de 13 técnicas de testing las que
forman parte de cuatro familias de técnicas de testing (funcional,
control de flujo, flujo de datos, mutación) y en [6], se presenta un
catálogo de 219 técnicas o enfoques MBT (Model Based Testing).
En ambos casos los catálogos fueron realizados mediante revisión
de literatura técnica cuya evidencia está conformada por ejemplos,
pruebas de concepto, reportes de experiencia industrial,
experimentación y especulación.
La base de conocimiento debe ser refinada con el tiempo mediante
agregación iterativa de conocimiento producido en la organización
[3].
Como se muestra en la Figura 4, proponen un mecanismo que
sugiere una forma de mantener actualizada esta base de
conocimiento, por un lado a partir de la información provista por
los testers (consumidores) proveniente de sus experiencias en el
uso de técnicas de testing, y por otro lado a partir de información
provista por investigadores en el área (productores) proveniente del
resultado de sus investigaciones en el desarrollo de nuevas técnicas
así como en el estudio de las condiciones de aplicabilidad de las
ya existentes. Un bibliotecario participará de manera indirecta
supervisando la información para el mantenimiento del repositorio.
Figura 4 - Uso de repositorio [16]
5. CONCLUSIONES
Se han encontrado disponibles 6 esquemas de caracterización de
técnicas de testing de software, lo cual ha hecho posible construir
bases de conocimiento y de evidencia, lo cual a su vez ha permitido
el desarrollo de métodos y herramientas para la selección y
evaluación de técnicas de testing de software. Entre los esquemas
de caracterización, destaca el de Vegas [16] por su capacidad de
ser adaptado a distintos contextos tal como ha quedado demostrado
con su adaptación en [6](método de selección basado en catálogo)
y [17](marco de trabajo para conducir casos de estudio que cuenta
con múltiples instanciaciones en la industria), por lo que constituye
una base escalable y adaptable para el desarrollo de otros esquemas
de caracterización para contextos genéricos específicos en futuros
trabajos.
Se han encontrado catálogos de técnicas de testing de software
construidos mediante revisión de literatura técnica haciendo
referencia a múltiples tipos de evidencia (pruebas de concepto,
experiencia industrial, experimentación, especulación), sin
embargo no se han encontrado disponibles aún catálogos o
repositorios sistematizados cuyas evidencias se hayan generado
mediante un mismo marco de trabajo o protocolo. No obstante, el
framework presentado en [17]cuenta con múltiples instanciaciones
en la industria, por lo que podría emplearse en más organizaciones
a fin de implementar bases de conocimiento sistematizadas sobre
las técnicas y herramientas de testing utilizadas en sus proyectos,
lo cual permitiría conducir estudios secundarios en pro de una
selección informada de técnicas y herramientas de testing de
software; incluso sería posible la colaboración entre
 organizaciones dado que el marco de trabajo caracteriza no solo la
técnica si no el contexto (proyecto, sistema a probar, entre otros
aspectos) en que se instancia.
Los métodos y herramientas encontrados para asistir la toma de
decisiones en la selección y evaluación de técnicas de testing,
utilizan esquemas de caracterización para: (1) adquirir información
sobre los proyectos y/o software a probar, y (2) para
catalogar/evaluar las técnicas de testing; y entre las técnicas usadas
en los métodos de selección y evaluación de técnicas de testing, de
manera análoga a la selección de tecnología en otros dominios,
destacan AHP, TOPSIS y MAUT, lo cual se condice con la
naturaleza multiatributo de las técnicas de testing de software y los
proyectos en los que son instanciadas.
Si bien es cierto los métodos de selección de técnicas y
herramientas de testing encontrados han logrado demostrar su
eficacia y eficiencia frente a métodos tradicionales como el uso de
libros, es importante tener en cuenta que estos métodos requieren
del mantenimiento y actualización de su base de conocimiento o
repositorio, por lo que es necesario encontrar maneras de hacerlo
de tal modo que sean transferibles y sostenibles para las
organizaciones en la industria.
REFERENCIAS
[1] E Brosse, A Bagnato, Tanja Vos, and N Condori,
"Evaluating the FITTEST automated testing tools in
SOFTEAM: an industrial case study," Utrecht University,
2014.
[2] Nelly Condori Fernández, Peter M Kruse, Tanja E.J. Vos,
Etienne Brosse, and Alessandra Bagnato, "Combinatorial
Testing in an Industrial Environment–Analyzing the
Applicability of a Tool," in 9th International Conference on
the Quality of Information and Communications
Technology, 2014.
[3] Domenico Cotroneo, Roberto Pietrantuono, and Stefano
Russo, "Testing techniques selection based on ODC fault
types and software metrics," Journal of Systems and
Software, 2012.
[4] Arilo Claudio Dias-Neto and Guilherme Horta Travassos,
"Model-based testing approaches selection for software
projects," Information and Software Technology, 2009.
[5] Arilo Claudio Dias-Neto and Guilherme Horta Travassos,
"Supporting the Combined Selection of Model-Based
Testing Techniques," IEEE TRANSACTIONS ON
SOFTWARE ENGINEERING, 2014.
[6] ARILO C. DIAS-NETO and GUILHERME H.
TRAVASSOS, "A Picture from the Model-Based Testing
Area: Concepts, Techniques, and Challenges," ADVANCES
IN COMPUTERS, pp. 45-120, 2010.
[7] Sigrid Eldh, Hans Hansson, Sasikumar Punnekkat, Anders
Pettersson, and Daniel Sundmark, "A Framework for
Comparing Efficiency, Effectiveness and Applicability of
Software Testing Techniques," in Testing: Academic and
Industrial Conference - Practice And Research, 2006.
View publication stats
[8] E. Engstrom, P. Runeson, and M. Skoglund, "A systematic
review on regression test selection techniques," in
Information and Software Technology, 2010, pp. 14-30.
[9] Nelly Condori Fernández et al., "Analyzing the
Applicability of a Combinatorial Testing Tool in an
Industrial Environment," in EASE’14, Londres, 2014.
[10] Paul Jaccard, "Étude comparative de la distribution florale
dans une portion des Alpes et des Jura," Bulletin del la
Société Vaudoise des Sciences Naturelles, no. 37, pp. 547-
579, 1901.
[11] Kazeem Olorisade Babatunde, Sira Vegas, and Natalia
Juristo, "Determining the effectiveness of three software
evaluation techniques through informal aggregation,"
Information and Software Technology, pp. 1590–1601,
2013.
[12] Basar Oztaysi, "A decision model for information
technology selection using AHP integrated TOPSIS-Grey:
The case of content management systems," Knowledge-
Based Systems, 2014. [Online].
http://dx.doi.org/10.1016/j.knosys.2014.02.010
[13] Marina Pilar, Jocelyn Simmonds, and Hernán Astudillo,
"Semi-automated Tool Recommender for Software
Development Processes," Electronic Notes in Theoretical
Computer Science, pp. 95–109, 2014.
[14] Zhongsheng Qian, Huaikou Miao, and Hongwei Zeng, "A
practical web testing model for web application testing," in
Third International IEEE Conference on Signal-Image
Technologies and Internet-Based Systems, Shanghai, 2007,
pp. 434-441.
[15] Sira Vegas, "Characterization schema for selecting software
testing techniques," Universidad Politécnica de Madrid,
Madrid, PhD Thesis 2002.
[16] Sira Vegas and V.R. Basili, "A characterization schema for
Software Testing Techniques," Journal of Empirical Softw.
Engineering, pp. 437-466, 2005.
[17] Tanja Vos, Beatriz Marin, Maria Jose Escalona, and
Alejandro Marchetto, "A methodological framework for
evaluating software testing techniques and tools," in 12th
International Conference on Quality Software, Xi’an,
China, 2012, pp. 230–239.
[18] Tanja Vos et al., "Evaluating Software Testing Techniques
and Tools," in XVI. JISBD, 2011, pp. 531–536.
[19] A.A. Zaidan et al., "Evaluation and selection of open-
source EMR software packages based on integrated AHP
and TOPSIS," Journal of Biomedical Informatics, 2014.