ProTest Proceso de Testing Funcional

Beatriz Prez
Universidad de la Repblica, Grupo de Ingeniera de Software,
Montevideo, Uruguay, 11000
bperez@fing.edu.uy


Resumen

En este artculo se presenta ProTest, proceso para
realizar testing funcional de un producto de software.
Es independiente del ciclo de vida de desarrollo, y
puede ser usado para realizar el testing funcional de
productos desde su comienzo, a travs de sucesivos
ciclos de desarrollo o en productos ya terminados.
ProTest es una gua pensada para una
organizacin que se dedica a la evaluacin de
productos de software desarrollados por terceros y es
el proceso aplicado en el Laboratorio de Testing
Funcional del Centro de Ensayos de Software (CES),
se presenta como caso de estudio su aplicacin en un
proyecto del CES.
Las principales caractersticas de ProTest son: Se
basa en el anlisis de riesgos del producto a probar,
se prueban primero las partes del producto cuyo
funcionamiento incorrecto representan mayor impacto
negativo para el negocio. La planificacin del
proyecto de testing se realiza en funcin de los ciclos
de prueba: cada ciclo de prueba est asociado a una
versin del producto a probar. El proceso definido
incluye la revisin de las especificaciones y su mejora,
en caso de ser necesario.

1. Introduccin

La motivacin de contar con un equipo de testing
independiente del desarrollo surge para mitigar la falta
de objetividad al realizar el testing que puede ocurrir
cuando la organizacin que desarrolla es la misma que
escribe las pruebas, esto, sumado a las presiones
institucionales por salir al mercado hacen que en
muchos casos la calidad del software se conozca recin
cuando se pone en produccin.
En organizaciones de pequeo y mediano porte la
subcontratacin de los servicios de testing es
imprescindible para implementar el testing
independiente, ya que es difcil sustentar la existencia
de un rea dedicada exclusivamente al testing dentro
de la organizacin misma.
Dentro de las ventajas que se obtienen al tener una
organizacin de testing independiente de la de
desarrollo estn la motivacin en el proceso de
pruebas, la separacin del proceso de pruebas del
control gerencial de la organizacin de desarrollo y el
conocimiento especializado que la organizacin
independiente tiene respecto a las pruebas [1]. Dentro
de las desventajas se encuentra que la organizacin de
testing independiente puede no tener el conocimiento
necesario del dominio del negocio, lo que puede llevar
a que olvide aspectos importantes o los subestime.
Adems, si la curva de aprendizaje del producto es
elevada, la transmisin de conocimiento puede ser
demasiado costosa y se corre el riesgo de que con el
tiempo el equipo de testing independiente sea el nico
que conoce como probar el producto.
El testing se define como la verificacin dinmica del
comportamiento de un programa usando un conjunto
finito de casos de prueba, seleccionados desde el
dominio infinito de ejecucin, contra el
comportamiento esperado. La verificacin dinmica
implica que para realizar las pruebas siempre hay que
ejecutar el programa para los datos de entrada [5]. El
testing funcional tiene como objetivo validar si el
comportamiento observado del software probado
cumple o no con sus especificaciones. [5].
Los conceptos, las estrategias, las tcnicas y las
mediciones del testing son integrados en un proceso
definido y controlado que es realizado por personas. El
proceso de testing apoya las actividades de testing y
provee guas para el equipo de testing de forma de
asegurar que los objetivos del test son alcanzados de
forma rentable [2].
ProTest es el proceso aplicado en el Laboratorio de
Testing Funcional del Centro de Ensayos de Software
(CES)[3], se presenta como caso de estudio su
aplicacin en un proyecto del CES.
El resto del documento de organiza de la siguiente
forma. En la seccin 2 se describen los principales
aportes para este trabajo, en la seccin 3 se describe el
proceso ProTest, se definen sus etapas y roles. En la
seccin 4 se muestra para cada etapa las principales
actividades que la componen. En la seccin 5 se
describe la experiencia de aplicar ProTest en el Centro
de Ensayos de Software y en la seccin 6 se presentan
las conclusiones.

2 Trabajos Relacionados

Los aportes para este trabajo surgen de diferentes
fuentes, a continuacin se describen las principales
referencias utilizadas, dichas referencias son citadas
cuando corresponde en los puntos 3 y 4 de este artculo
donde se presenta ProTest.
La propuesta de Rex Black [4] se concentra en los
aspectos administrativos y de gestin del testing: su
planificacin, seguimiento y control, sin entrar en
detalles de cmo realizar el testing.
La propuesta de Edward Kit [5], muestra como usar
tcnicas y estrategias para mejorar el proceso de
testing, sin especificar una metodologa de trabajo.
La propuesta de Cem Kaner, James Bach, Bret
Pettichord [6], recopila 293 lecciones aprendidas por
los autores al realizar testing, sin definir una forma de
trabajo para aplicarlas.
Testing Maturity Model (TMM)[7] es una gua para
las organizaciones que quieren mejorar y evaluar su
proceso de testing. TMM contiene un conjunto de
niveles para que la organizacin mejore la madurez de
su proceso de testing, un conjunto de prcticas
recomendadas en cada nivel de madurez y un modelo
de evaluacin que permite a la organizacin evaluar y
mejorar su proceso de testing.
Todas estas propuestas se focalizan en el testing
realizado por el equipo de desarrollo, ProTest combina
las actividades y guas existentes en estas propuestas
en lo que tiene que ver con realizar testing funcional y
su gestin, agrupndolas en etapas con objetivos
definidos. Una actividad en ProTest es el resultado de
integrar las distintas propuestas y de ajustarlas para ser
utilizadas en forma independiente del ciclo de vida de
desarrollo.

3 ProTest

En esta seccin se definen las etapas de ProTest y
cmo ocurren en el tiempo, sus objetivos y los roles
definidos para el proceso.

3.1 Etapas de ProTest

En la figura 1 se muestran las etapas de ProTest en
el tiempo, el proceso consta de cuatro etapas: Estudio
Preliminar, Planificacin, Ciclos de Prueba y
Evaluacin del Proyecto.


Figura 1: Etapas de ProTest

Estudio Preliminar: Esta etapa ha sido pensada para
el caso de la evaluacin independiente de un producto,
donde previo a comenzar con el proyecto de testing, se
debe estudiar la factibilidad de realizar el mismo.
Planificacin: El objetivo de esta etapa es planificar
el proyecto de Testing, una vez que se acord con el
cliente comenzar el proyecto de prueba.
Ciclos de Prueba: Uno de los principales desafos
desde el punto de vista del testing independiente es
estimar cuantos ciclos de prueba se requieren. En un
ciclo de prueba se puede ejecutar una, alguna o todas
las pruebas planificadas para el producto. Cada ciclo
de prueba est asociado a una versin del producto a
probar, cada nuevo ciclo de prueba implica una nueva
versin de uno o ms componentes del sistema [4].
Esta etapa se divide a su vez en sub-etapas como se
muestra en la figura2.
Evaluacin: Durante esta etapa se evala la
satisfaccin del cliente, se realiza el informe final y se
evala el proceso, ajustndolo para su uso en proyectos
posteriores.
En cada ciclo de prueba se realizan cuatro sub-
etapas en el tiempo como se muestra en la figura 2. Las
sub-etapas definidas para un ciclo son: Seguimiento
del Ciclo, Configuracin del Entorno, Diseo de las
Pruebas y Ejecucin de las Pruebas.
Los objetivos de cada sub etapa en un ciclo de
prueba se describen a continuacin:
Configuracin del Entorno: El objetivo de esta sub
etapa es configurar el ambiente de pruebas, separando
los ambientes de desarrollo y testing, instalar las
herramientas necesarias y el software a probar en la
versin correspondiente a cada ciclo de prueba.
Diseo de las Pruebas: Durante esta etapa se realiza
el diseo de los casos de prueba a partir de la
especificacin del producto, segn la estrategia de
pruebas definida en la etapa de Planificacin
Ejecucin de las Pruebas: El objetivo de esta etapa
es contrastar el comportamiento esperado del software
con su comportamiento real, analizar las diferencias y
reportar los resultados.
Seguimiento del Ciclo: Esta etapa ocurre en
paralelo con las tres anteriores. Se realiza el
seguimiento y control del proyecto de Testing. La
planificacin realizada al principio del proyecto es
revisada al comenzar cada ciclo de prueba. Se planifica
en detalle las tareas para el ciclo y se ajusta la
planificacin segn las estimaciones y posteriores
mediciones realizadas en los ciclos anteriores.
Figura 2: Sub etapas en cada Ciclo de Prueba

Los ciclos de prueba se solapan en el tiempo, por
ejemplo, mientras se ejecutan las pruebas para un
ciclo, se puede al mismo tiempo estar diseando las
pruebas del ciclo siguiente, como se ilustra en la figura
2.

3.2 Roles

Los roles definidos para el equipo de testing son: Lder
del Proyecto de Testing, Diseador y Tester. El lder es
quien dirige el proyecto de testing. El diseador es
quien realiza el diseo de los casos de prueba a partir
de las especificaciones del producto y el Tester es
quien ejecuta los casos de prueba y reporta los
resultados.
Existen adems dos roles que no son parte del equipo
de testing: el Cliente y el Desarrollador. Aqu
definiremos al Cliente como la persona que necesita el
producto y que est interesado en la calidad del mismo,
conoce las necesidades del negocio y el impacto que el
funcionamiento incorrecto de cada parte del producto
tiene en el mismo. El desarrollador es quien construye
el producto de software, conoce como fue realizado
internamente y las fortalezas y debilidades de los
distintos mdulos que lo componen.

4 Etapas y Actividades de Protest

En esta seccin se describen los objetivos, las
principales actividades y los roles involucrados en
cada una de las Etapas de ProTest.

4.1 Estudio Preliminar

Esta etapa ha sido introducida en ProTest debido a
que en la evaluacin independiente de un producto, en
forma previa a comenzar con el proyecto de testing, se
debe estudiar la factibilidad de realizar el mismo. Las
actividades a realizar son un subconjunto de las
realizadas en la etapa de Planificacin, a diferencia de
esa etapa, aqu se realizan con el objetivo de estudiar la
factibilidad del proyecto de prueba y realizar una
cotizacin del mismo.
Se realiza un estudio preliminar de las partes ms
riesgosas del producto y se negocia con el cliente qu
funcionalidades sern probadas y cules no, acordando
una primera agenda sobre la cual realizar la
planificacin del proyecto de testing. En el caso de que
se llegue a un acuerdo entre las partes se pasa a las
etapas siguientes del proceso de testing.
En la tabla 1 se muestran las actividades que se
realizan en esta etapa y los roles involucrados. Dichas
actividades se describen en la prxima etapa:
Planificacin.

Tabla 1: Actividades y roles de la Etapa: Estudio
Preliminar
Estudio Preliminar
Actividad Roles involucrados
Negociacin con el
cliente
Cliente, Desarrollador, Lder
de Proyecto
Revisin de
Requerimientos
Cliente, Desarrollador, Lder
de Proyecto
Anlisis de Riesgos del
Producto
Cliente, Desarrollador, Lder
de Proyecto

4.2 Planificacin

El objetivo de esta etapa es planificar el proyecto de
Testing, una vez que se acord con el cliente comenzar
el proyecto de prueba. En la tabla 2 se muestra para
cada actividad, los roles involucrados en esta etapa.
La negociacin con el cliente tiene como objetivo
ponerse de acuerdo respecto a las actividades a ser
realizadas por el equipo de testing, por los
desarrolladores y el cliente. Se define el alcance del
proyecto de testing, esto es, qu funcionalidades se van
a probar y cuales no y una agenda preliminar,
indicando la cantidad de ciclos de prueba y las fechas
tentativas de comienzo y fin de cada ciclo.
No es posible probar todo, la decisin de qu probar
se basa en los riesgos de cada parte del sistema. En la
actividad Anlisis de Riesgo del Producto se realiza
una lista priorizada de las funcionalidades del
producto, junto con el cliente y desarrolladores
Al realizar testing funcional se debe decidir si la
salida observada al ejecutar el programa es la salida
esperada. La salida esperada est expresada en las
especificaciones del producto. La actividad Revisin
de Requerimientos estudia la correspondencia entre las
distintas fuentes de requerimientos y evala si es
posible realizar el diseo de las pruebas a partir de
ellas. En caso contrario, se debe trabajar junto con
desarrolladores y cliente en mejorar los requerimientos
existentes. Las especificaciones pueden ser obtenidas
de diferentes fuentes: documentos de requerimientos,
sistemas ya existentes, manuales del sistema, reportes
de defectos, entrevistas con cliente y usuarios,
prototipos.

Tabla 2: Actividades y roles de la Etapa: Planificacin
Planificacin
Actividad Roles involucrados
Negociacin con el
cliente
Cliente, Desarrollador, Lder
de Proyecto
Revisin de
Requerimientos
Cliente, Desarrollador, Lder
de Proyecto
Anlisis de Riesgo del
Producto
Cliente, Desarrollador, Lder
de Proyecto
Definicin de los Ciclos
de Prueba
Cliente, Desarrollador, Lder
de Proyecto
Definicin del Plan de
Pruebas
Lder de Proyecto

En general los tiempos no permiten volver a correr
todas las pruebas para cada versin, esto fuerza a
seleccionar un conjunto de pruebas en cada ciclo de
prueba [4]. En la actividad Definicin de los Ciclos de
Prueba se definen las funcionalidades que sern
probadas en cada ciclo junto con el cliente a partir del
anlisis de riesgo del producto.
En el plan de pruebas se define quin, cundo,
dnde y cmo se realizan las actividades de testing. Se
incluye el alcance del proyecto, el calendario, los
ciclos, los requerimientos de hardware y software para
ejecutar las pruebas, las tcnicas usadas para el diseo
de las pruebas, los roles y sus responsabilidades, la
clasificacin de los defectos usada en el proyecto y la
especificacin de qu reportes y otros productos se
entregarn al cliente durante el proyecto y al finalizar
el mismo.

4.3 Ciclos de Prueba

El objetivo de esta etapa es realizar las pruebas para
cada versin del producto. En un ciclo de prueba se
puede ejecutar una, alguna o todas las pruebas
planificadas para el producto. Esta etapa se divide a su
vez en sub-etapas como se muestra en la figura 2 de la
seccin 2.1 de este artculo. Las sub-etapas son:
Seguimiento del Ciclo, Configuracin del Entorno,
Diseo de las Pruebas y Ejecucin de las Pruebas.
En cada ciclo, se comienza con la sub-etapa:
Seguimiento del Ciclo, donde se administra y planifica
el ciclo de prueba. En paralelo se realizan las sub-
etapas de Configuracin del Entorno y el Diseo de las
Pruebas, a continuacin se realiza la Ejecucin de las
Pruebas. Si no se cuenta con la versin ejecutable del
producto, el Diseo de las Pruebas puede realizarse de
todos modos, ya que se realiza a partir de la
especificacin del producto, en cambio la
Configuracin del Entorno y la Ejecucin de las
Pruebas requieren de la versin ejecutable del
producto.
Los ciclos de prueba se solapan en el tiempo, por
ejemplo, mientras se ejecutan las pruebas para un
ciclo, se puede al mismo tiempo estar diseando las
pruebas del ciclo siguiente, como se ilustra en la figura
2.

4.3.1 Seguimiento del Ciclo

La planificacin realizada al principio del proyecto
es revisada al comenzar cada ciclo de prueba. Se
planifica en detalle las tareas para el ciclo y se ajusta la
planificacin segn las estimaciones y posteriores
mediciones realizadas en los ciclos anteriores. En la
tabla 3 se muestra para cada actividad, los roles
participantes en esta sub-etapa.
El anlisis de riesgo del producto puede requerir ser
ajustado, debido a cambios en las prioridades del
negocio o a la confianza adquirida en el producto
como resultado de la realizacin de las pruebas en
ciclos anteriores. Se revisa la lista de riesgos y se
modifica en caso de ser necesario.

Tabla 3: Actividades y roles de la sub-etapa:
Seguimiento del Ciclo
Seguimiento del Ciclo
Actividad Roles involucrados
Anlisis de riesgo del
producto
Cliente, Desarrollador,
Lder de Proyecto
Planificacin del Ciclo Cliente, Desarrollador,
Lder de Proyecto

En la actividad Planificacin del Ciclo se realiza el
plan detallado de las tareas a realizar en el ciclo de
prueba, estimando el tiempo y esfuerzo requerido para
cada tarea. Para realizar la planificacin del ciclo se
tienen en cuenta las mediciones de ciclos anteriores,
las funcionalidades priorizadas para el ciclo y las
pruebas de regresin que deben ejecutarse en el ciclo,
debido a incidentes encontrados en ciclos anteriores
que fueron arreglados para la versin de este ciclo.

4.3.2 Configuracin del Entorno

El objetivo de esta sub-etapa es configurar el
ambiente de pruebas, separando los ambientes de
desarrollo y testing e instalar las herramientas
necesarias y el software a probar en la versin
correspondiente a cada ciclo de prueba. Esta etapa es
realizada por los Testers, apoyados por los
desarrolladores

4.3.3 Diseo de las Pruebas

El objetivo de esta etapa es disear las pruebas que
sern luego ejecutadas sobre el software a probar.
Incluye revisar los requerimientos de las
funcionalidades que sern probadas en este ciclo,
disear los casos de prueba, identificar los datos de
prueba y validar los casos de prueba con el cliente. En
la Tabla 4 se muestra para cada actividad, los roles
involucrados en esta sub-etapa.
En la actividad Revisin de Requerimientos se
revisan las especificaciones existentes de las
funcionalidades que han sido planificadas para este
ciclo, en caso de que no sea posible realizar el diseo
de las pruebas a partir de ellas, se trabaja junto con
desarrolladores y cliente en mejorar los requerimientos
existentes. En cada ciclo se mejoran solamente las
funcionalidades que van a ser probadas en el ciclo.

Tabla 4: Actividades y roles de la sub-etapa: Diseo de
las Pruebas
Diseo de las Pruebas
Actividad Roles involucrados
Revisin de
Requerimientos
Cliente, Desarrollador, Lder
de Proyecto
Diseo de los casos de
prueba
Diseador
Validacin de los casos
de prueba
Diseador, Cliente,
Desarrollador

En la actividad Diseo de los Casos de Prueba,
usando tcnicas de caja negra se desarrollan los casos
de prueba. Esta actividad incluye disear las pruebas e
identificar los datos de prueba. Para cada funcionalidad
a probar, se crea una matriz que muestra su
correspondencia con los casos de prueba, de forma de
conocer qu casos de prueba cubren qu tems de
prueba [7]. Entre las tcnicas posibles de caja negra a
utilizar para el diseo de los casos de prueba se
encuentran: particin de equivalencia, valor lmite,
conjetura de errores, grafo causa efecto [1], particin
en categoras [8], mquinas de estado finitas [9],
escenarios [6].
En la actividad Validacin de los Casos de Prueba,
los casos de prueba definidos deben ser validados con
el cliente. Se busca con esta actividad que los casos de
prueba diseados y los datos de prueba sean de valor
para el negocio.


4.3.4 Ejecucin de las Pruebas

El objetivo de esta etapa es contrastar el
comportamiento esperado del software con su
comportamiento real, analizar las diferencias y reportar
los resultados. Al finalizar la etapa se reporta el avance
del testing en el ciclo y se evalan los resultados
obtenidos. En la Tabla 5 se muestra para cada
actividad, los roles involucrados en esta sub-etapa.
Las pruebas de humo son un conjunto de pruebas
aplicadas a cada nueva versin, su objetivo es validar
que las funcionalidades bsicas de la versin se
cumplen segn lo especificado. Estas pruebas buscan
grandes inestabilidades o elementos clave faltantes o
defectuosos, que hacen imposible realizar el testing
como fue planificado para el ciclo. Si la versin no
pasa las pruebas de humo, no se comienza la ejecucin
de las pruebas de la versin [6].

Tabla 5: Actividades y roles involucrado en la sub-
etapa: Ejecucin de las Pruebas

Ejecucin de las
Pruebas

Actividad Roles involucrados
Pruebas de Humo Tester
Ejecucin de las Pruebas Tester
Testing Exploratorio Tester
Verificacin de las
correcciones
Tester
Evaluacin de las Pruebas Lder de Proyecto,
Diseador, Tester

La actividad Ejecucin de las Pruebas consiste en
ejecutar los casos de prueba seleccionados para el ciclo
y observar su resultado. Incluye seleccionar los casos
de prueba, ejecutarlos, registrar resultados y
determinar si los defectos son causados por errores en
el producto o errores en las pruebas. En caso de
encontrar defectos, se reportan. Al reportar un
incidente debe quedar claro si es un defecto, una
mejora o una observacin y estar acompaado de una
valorizacin de impacto y criticidad. La ejecucin de
las pruebas puede ser manual o automatizada.
El testing exploratorio se define como el
aprendizaje, diseo y ejecucin del testing en forma
simultnea [10]. Los testers disean, desarrollan y
ejecutan las pruebas durante la ejecucin del producto.
Esta actividad tiene como objetivo mitigar el riesgo de
estar realizando un mal anlisis de riesgo del producto,
de esta forma se realiza testing con otra metodologa
distinta a la de realizar testing basado en los riesgos. Si
se encuentran defectos durante el Testing Exploratorio
que no fueron encontrados por las pruebas planificadas
y que son crticos para el funcionamiento del producto
o para el cliente, entonces, es momento de revisar el
anlisis de riesgo realizado.
La actividad Verificacin de las Correcciones es la
que sigue a un ciclo de prueba: se revisa que el
incidente se haya corregido y que pueda ser cerrado.
Luego de terminada la ejecucin de las pruebas en un
ciclo de prueba, los incidentes reportados sern
corregidos por los desarrolladores. Los testers realizan
las pruebas de regresin para asegurar que los cambios
no introducen un comportamiento no deseado o nuevos
errores. Esto implica seleccionar los casos de prueba a
reejecutar, ejecutarlos y reportar nuevos incidentes si
corresponde.
Al finalizar el ciclo de prueba, la actividad
Evaluacin de las Pruebas implica realizar los reportes
de avance del proyecto, mostrando el avance del
testing del ciclo y de la calidad de la versin probada.
Se evala el testing realizado en el ciclo y si es
necesario seguir o se deben parar las pruebas. Para
realizar el seguimiento de las pruebas ejecutadas se
cuenta el nmero de casos de prueba planificados,
disponibles, ejecutados, ejecutados exitosos,
ejecutados fallidos [5].

4.3.5 Evaluacin del Proyecto

Esta etapa tiene como objetivos conocer el grado de
satisfaccin del cliente, realizar el informe final y la
evaluar el proceso de testing para su mejora. En la
Tabla 6 se muestra para cada actividad, los roles
involucrados en esta etapa.
Al finalizar el proyecto, es importante conocer el
grado de satisfaccin del cliente respecto a los
resultados obtenidos, la comunicacin que se tuvo
durante el proyecto y a su percepcin del avance
durante el proyecto. Estos elementos ayudan a ajustar y
mejorar el proceso de testing.
Los modelos de mejora del proceso de testing
como el Testing Maturity Model (TMM) [7], muestran
la importancia de tener un grupo dedicado a la mejora
del proceso de testing, que aplique tcnicas de mejora
incremental del proceso y evale su impacto. Al
finalizar el proyecto de testing, el equipo de mejora del
proceso de testing junto con el equipo de testing debe
evaluar los procedimientos existentes para futuras
experiencias. Segn la naturaleza del dominio del
negocio de cada producto de software a probar, pueden
surgir procedimientos especficos, que es interesante
recolectar y escribir, de forma de ayudar a la mejora
del proceso y de guardar una memoria colectiva.
Una vez finalizado el proyecto de testing, se
realiza un reporte que resume el proyecto en su
conjunto. Este reporte debe indicar el esfuerzo total, el
esfuerzo por ciclo, por etapa y por actividad, las
desviaciones que ocurrieron respecto al proceso
definido y las razones de dichas desviaciones. Las
mediciones realizadas durante este proyecto de testing
son la base para las estimaciones de los proyectos
posteriores.

Tabla 6: Actividades y roles involucrado en la etapa:
Evaluacin del Proyecto
Evaluacin del Proyecto
Actividad Roles involucrados
Evaluacin de la
satisfaccin del Cliente
Cliente, Lder de Proyecto
Ajustes y Mejoras del
Proceso de Testing
Lder de Proyecto,
Diseador, Tester
Reporte Final del
Proyecto de Testing
Lder de Proyecto

5 Aplicacin en el Laboratorio de Testing
del Centro de Ensayos de Software

5.1 El Centro de Ensayos de Software

En el ao 2004 se crea el Centro de Ensayos de
Software [3]. Se trata de un emprendimiento conjunto
de la Universidad de la Repblica (UDELAR) de
Uruguay, a travs de la Fundacin Julio Ricaldoni, y
de la CUTI (Cmara Uruguaya de Tecnologas de la
Informacin), entidad que agrupa a la mayora de las
empresas productoras de software del pas. El CES
brinda servicios de verificacin y evaluacin de
software, funcional y no funcional. El CES est
compuesto por un Laboratorio de Testing, enfocado en
la evaluacin de productos desde el punto de vista
funcional y un Laboratorio de Ensayos de Plataformas
con el objetivo de realizar pruebas de desempeo y
asistir a la industria en resolver problemas de
funcionamiento en arquitecturas de hardware y
software complejas.

5.2 La aplicacin de ProTest

ProTest es aplicado en el Laboratorio de Testing del
Centro de Ensayos de Software (CES), en general, los
clientes con que se ha trabajado son empresas
productoras de software, estas empresas tienen
productos que venden a distintos clientes y les interesa
mejorar su calidad, son productos que se desarrollaron
para un cliente en particular y luego fueron adaptados
para otros clientes, con lo cual se cuenta con distintas
instalaciones de los mismos, con variantes en cada
caso. Estos productos se encuentran en etapa de
mantenimiento o de desarrollo de nuevas
funcionalidades.
Usaremos como caso de estudio en este artculo un
proyecto que actualmente se encuentra en curso. Los
resultados mostrados fueron levemente maquillados
por razones de confidencialidad, pero sin alterar su
esencia.
El producto de software es una aplicacin de
gestin, que hace varios aos est en produccin, pero
ha sufrido varios cambios.
Existe un manual de usuario de la aplicacin el cual
no se actualiza desde hace un par de aos, no hay
documento de requerimientos ni otro material de
apoyo. El cliente cuenta con un sistema donde ingresan
las solicitudes de cambio para cada nueva versin.
Se aplicaron para este proyecto las etapas de
ProTest y sus actividades, como se describe a
continuacin.
La etapa de Estudio Preliminar es muy importante
en el caso de testing independiente, ya que para cotizar
los proyectos de testing, es necesario conocer las
funcionalidades del producto. En este caso la etapa
Estudio Preliminar se llevo a cabo durante 3 reuniones
con el cliente en las cuales se definieron las
prioridades para las pruebas y se explicaron los
principales requerimientos del sistema, el equipo de
testing a partir de las reuniones realiz una agenda
preliminar, en la que se definieron dos ciclos de prueba
y las principales funcionalidades a probar en cada
ciclo. A partir de esto se realiz la cotizacin del
proyecto de prueba, las actividades necesarias para
realizar la cotizacin, no son parte de ProTest. El
cliente dio el visto bueno a la propuesta, momento en
el cual se comenz el proyecto de testing.
Durante la etapa de Planificacin, la negociacin
con el cliente y el anlisis de los riesgos del producto
son las actividades principales, para poder planificar el
trabajo de testing, y definir los ciclos de prueba del
producto. Para cada ciclo de prueba debe definirse qu
funcionalidades se probarn en el ciclo y cundo
comienza y termina el ciclo. La definicin de las
funcionalidades se hace agendando en los ciclos las
funcionalidades segn la importancia asignada en el
anlisis de riesgo del producto, dado que cada ciclo se
corresponde con una versin del producto, las fechas
de comienzo y fin van a estar dadas por las fechas en
que desarrollo genera nuevas versiones. Se definieron
2 ciclos de 1 mes cada uno, como se muestra en la
Tabla 7.
Las funcionalidades para el proyecto se clasificaron
junto con el cliente segn Prioridad, Complejidad y
Criticidad y se asignaron en cada ciclo como se
describe en la Tabla 8. La definicin del Plan de
Pruebas ha resultado de gran utilidad para que el
cliente tenga visibilidad respecto al trabajo del
proyecto de testing independiente, as como lograr
acuerdos respecto a responsabilidades y compartir un
vocabulario comn.


Tabla 7: Planificacin del Proyecto
OBJETIVO TIEMPO
Planificacin del Proyecto Semanas 1 y 2
Plan de Pruebas Completo Semanas 1 y 2
Laboratorio Configurado Semana 1
Ciclo de Prueba 1 Semanas 3, 4 y 5
Redaccin de las funcionalidades del
Ciclo 1
Semanas 3 y 4
Diseo de los casos de prueba del
Ciclo 1
Semanas 3 y 4
Ejecucin de las Pruebas Semanas 4 y 5
Reporte de Incidentes Semanas 4 y 5
Ciclo de Prueba 2 Semanas 6, 7 y 8
Redaccin de las funcionalidades del
Ciclo 2
Semanas 6 y 7
Diseo de los casos de prueba del
Ciclo 2
Semanas 6 y 7
Ejecucin de las Pruebas Semanas 7 y 8
Reporte de Incidentes Semanas 7 y 8
Informe final de las pruebas Semana 9

Una vez planificado el proyecto de prueba, se
comienza con el Ciclo 1. Se realiz la instalacin y
configuracin del producto en el ambiente de pruebas.
Dado que no se cuenta con la documentacin de los
requerimientos del producto, se incluy el
relevamiento de requerimientos como parte del
proyecto de prueba, lo que el cliente ve como positivo,
ya que adems de conocer la calidad del producto que
desarrolla, obtiene como valor agregado la
documentacin de las funcionalidades que se van a
probar. El poder explorar el producto es de gran
utilidad en estos casos, el tener un ejecutable del
producto permite entender el sistema y sus
requerimientos rpidamente, reduciendo las horas de
reuniones para especificar requerimientos.

Tabla 8: Funcionalidades por Ciclo de Prueba

A la vez que se relevaron los requerimientos para
el ciclo, se disearon los casos de prueba. Se
definieron 153 casos de prueba para el Ciclo 1, los
cuales fueron validados por el cliente. La ejecucin de
los casos de prueba se hizo al finalizar el ciclo,
encontrndose 57 incidentes: 5 son de prioridad Alta, 3
de prioridad Media y 49 de prioridad Baja. En la tabla
9 se detallan los incidentes encontrados por tipo.

Tabla 9: Incidentes por tipo
Incidentes por Tipo Incidentes
Funcional - Implementacin Incorrecta 15
Interfaz de Usuario 10
Mensajes errneos y Falta de Mensaje. 30
Ortografa y/o Gramtica 2

Los incidentes encontrados fueron validados por el
cliente, para la comunicacin y seguimiento de
incidentes se usa la herramienta Bugzilla. Los
incidentes son ingresados por el equipo de testing y
luego son validados por el cliente, el cliente puede
asignar los incidentes a sus desarrolladores y cuando el
incidente est corregido, queda en el estado resuelto,
de forma de que el equipo de testing realice las pruebas
de regresin para el nuevo ciclo de prueba.
Actualmente se ha terminado el Ciclo 1, se est
esperando la versin correspondiente para comenzar el
Ciclo 2.

6 Conclusiones

En este artculo se define ProTest, gua para realizar
testing funcional de un producto de software y su
aplicacin en el Laboratorio de Testing Funcional del
Centro de Ensayos de Software. Las principales
caractersticas de ProTest se listan a continuacin:
Se basa en el anlisis de riesgo del producto para
priorizar las funcionalidades a probar, esto requiere
involucrar al cliente y desarrolladores en ese anlisis y
responsabilizarlos de tomar decisiones durante las
pruebas, de forma que el testing realmente evale el
producto segn las necesidades del negocio.
Los ciclos de prueba son los que guan cada
proyecto de testing. La decisin de las pruebas a
ejecutar en cada ciclo se realiza a partir del anlisis de
riesgo del producto y de la relacin entre el costo y su
beneficio.
Se revisan las especificaciones existentes y se
trabaja junto con el cliente y los desarrolladores para
mejorarlas, si fuese necesario
En cada ciclo de prueba se realiza testing
exploratorio adems del testing planificado para el
ciclo. El objetivo es mitigar el riesgo de estar
realizando un mal anlisis de riesgo del producto,
usando una metodologa distinta a la de realizar testing
basado en los riesgos. Si se encuentran defectos
durante el testing exploratorio que no fueron
encontrados por las pruebas planificadas y que son
crticos para el funcionamiento del producto o para el
cliente, entonces, es momento de revisar el anlisis de
riesgo realizado y de la relacin costo/beneficio.
Como trabajo futuro se encuentra seguir con este
caso de estudio hasta su finalizacin, para poder
concluir sobre el uso de ProTest en un proyecto de
prueba desde su comienzo hasta su conclusin.
Resulta interesante comparar los resultados de la
aplicacin del proceso con clientes que no sean
quienes desarrollan el software y tambin estudiar la
aplicacin de ProTest con herramientas que ayuden a
la gestin del testing.

7 Referencias

[1] Myers G, The Art of Software Testing, John Wiley &
Sons, 1979. ISBN: 0471043281
[2] Guide to the Software Engineering Body of Knowledge
SWEBOK, 2004 version. Pages: 73-86. IEEE Computer
Society. www.swebok.org
[3] Centro de Ensayos de Software, www.ces.com.uy
[4] Black R., Managing the Testing Process, 2nd Edition.
Rex Black. Editorial Wiley, ISBN 0-471-22398-0, 2002
[5] Kit E., Software Testing In The Real World: Improving
The Process, Addison Wesley. ISBN 0201877562
[6] Kaner C., Bach J, Pettichord B.Lessons learned in
Software Testing. Willey, 2002. ISBN 0-471-08112-4
[7] Suwannasart T., Burnstein I., Carlson C. Developing a
Testing Maturity Model: Part I, llinois Institute of
Technology. Published in: Crosstalk, August 1996
[8] Ostrand T., Balcer M, The category-partition method
for specifying and generating functional tests,
Communications of the ACM, Volume 31, Issue 6,
Pages: 676 686, June 1988.
[9] Beizer B, Software Testing Techniques, International
Thomson Press, 1990
[10] Bach J, Exploratory Testing Explained,
http://www.satisfice.com/articles/et-article.pdf , 2002.