Empresa Financiera

Herramientas de SW Servicios
 Resulta importante mencionar que sta es una empresa cuya actividad
principal est enfocada a satisfacer las necesidades financieras de los
clientes, a travs de productos y servicios bancarios, utilizado las
herramientas de software como un medio para brindar estos productos
y servicios de manera confiable y eficiente

Ciertamente el proceso actual de pruebas de Software en la empresa

que represento aun se encuentra en un nivel poco maduro, en relacin
con otras empresas dedicadas al desarrollo de software, sin embargo
el rea de calidad ha evolucionado constantemente, siempre tratando
de minimizar los errores en produccin y en pro de garantizar la
continuidad del negocio.
 Siendo las pruebas parte fundamental en la cadena de valor del
desarrollo de software para minimizar el riesgo de errores o fallas
antes de que los sistemas sean utilizados por los usuarios o clientes
finales, convirtindose ste en el propsito y alcance de dicho proceso
en el ciclo de vida de un proyecto de software.

Verificar la calidad y funcionamiento de los desarrollos y

mantenimientos de los sistemas y encontrar las deficiencias y fallas de
los mismos antes de su liberacin a produccin son los objetivos
primordiales del proceso.
 Han existido en la empresa factores que han contribuido a minimizar el
protagonismo del proceso de calidad de software:

La falta de cultura entre muchos desarrolladores sobre la importancia

de las pruebas de software.

Los costos necesarios que se deben invertir en la calidad del software.

El time to market
Las actividades que se desarrollan dentro del Departamento de
Gestin de Calidad son las siguientes:

1. Revisin de Documentacin

2. Ejecucin Pruebas de Aceptacin

 Documento en el que se disean casos de pruebas, stos a su vez
estn conformados por escenarios de pruebas, los cuales ser
ejecutados, en una etapa posterior.

Este es el nico documento que se revisa de manera formal, como

parte del las actividades del rea de Gestin de Calidad, sin embargo
al llevar a cabo la revisin del plan de pruebas, debe revisarse
indirectamente los documentos:

Especificacin de Requerimientos de Sistema.

Especificacin de Requerimientos de Software (Diagrama de Casos de
Uso, Casos de Uso en Modelo Extendido).
Objetivo de la Revisin

En la revisin se amplia y se mejora el plan de pruebas tomando

como referencia los documentos mencionados.

Lo que se busca en sta revisin es que se estn cubriendo todos los

posibles escenarios a probar, se define las prioridades de los
escenarios y se asegura que el documento cumpla con los estndares
tanto de forma como de fondo, definidos por la empresa.

Adems de acuerdo a la cantidad de escenarios que conformen el plan

de pruebas, se realiza la estimacin del tiempo que se requiere para
posteriormente ejecutar las pruebas.
 La estrategia para ejecutar las pruebas, constituye en la ejecucin de
los casos de prueba diseados en el plan de pruebas y algunas otras
pruebas que no hayan sido documentadas, pero que partiendo de la
experiencia pueden aportar valor.

Las pruebas se realizan prcticamente en la etapa final del desarrollo,

antes de salir a produccin.
 Una vez que el proyecto se encuentre en sta etapa, se realiza la
coordinacin con el analista y el lder de negocio para la ejecucin de
las pruebas.

Las pruebas se ejecutan en un ambiente de pruebas, el cual es similar

al ambiente de produccin.

Este ambiente es previamente configurado y solicitado por el analista,

a un rea dedicada a administrar las versiones de ambientes y
servidores de prueba.

En paralelo con sta actividad el analista debe preparar los datos de

pruebas que se requieren para la ejecucin de las pruebas.
 La ejecucin de las pruebas se lleva a cabo en conjunto con el
analista programador y el lder de negocio que valida que la aplicacin
cumpla con lo definido y acordado en los requerimientos en la etapa de
diseo.

En caso de que se identifiquen errores o deficiencias de la aplicacin

que se est evaluando, se reporta al analista programador y se
documenta para poder darle seguimiento a los incidentes detectados.

El proyecto se devuelve a la etapa de programacin para que los

defectos sean corregidos.
 Una vez que el analista corrige los defectos identificados, debe
ejecutase nuevamente las pruebas cuyo resultado no fue satisfactorio,
en caso de que sea requerido se repiten otras pruebas adicionales
para garantiza que las correcciones no afectaran la funcionalidad ya
certificada exitosamente.

Una vez finalizada la revisin y certificada la aplicacin en conformidad

con los requerimientos y concepciones reales del diseo, se procede a
dar el visto bueno para seguir el flujo de desarrollo y finalmente que el
proyecto salga a produccin.
 No existe un proceso de pruebas definido y publicado para la
organizacin.

Resistencia al proceso de pruebas, calidad versus tiempo de entrega.

Documentos de Requerimientos de Sistema y Documento de

Requerimientos de Software mal diseados.

No hay repositorios eficaces para la documentacin de los casos de

prueba que permitan la reutilizacin de los mismos.

Ambientes de prueba limitados e insuficientes.

 Problemas con la conectividad con terceros y disponibilidad de ambientes
de prueba de terceros.

No existen estndares visuales documentados para la interfaz de las

aplicaciones con los usuarios.

El proceso de pruebas se ejecuta en las etapas finales del proyecto.

Datos de prueba difciles de recolectar.

Falta de administracin de defectos.

Disponibilidad de recursos (Gestores de Calidad). versus demanda.

Baja calidad del software.

 No hay seguimiento de las mejoras recomendadas en el proceso de
pruebas para futuros proyectos.

No se cuenta con herramientas automatizadas para la ejecucin de

pruebas.

El proceso de pruebas se ejecuta en las etapas finales del proyecto.

Las pruebas que realiza el departamento de Gestin de Calidad son
pruebas de caja negra.

Las pruebas de caja negra por su lado, son parte integral del proceso
de Desarrollo que se lleva a cabo en la empresa, por lo que ocupan un
lugar preponderante.

Entrada Salidas
Funciones
 Pruebas de Caja Negra:

Dentro de esta categora existen una serie de tipos de pruebas, entre

las que se mencionan:

Pruebas Funcionales
Pruebas de Regresin
Pruebas de Valores Lmite
Pruebas de Integracin
 Pruebas Funcionales

Evalan el conjunto de caractersticas y capacidades de los

componentes del sistema.

Aseguran el trabajo apropiado de los requisitos funcionales, incluyendo

la navegacin, entrada de datos, procesamiento y obtencin de
resultados. Se verifica lo siguiente:

Que se aplique apropiadamente cada regla de negocio.

Que los resultados esperados ocurran cuando se usen datos vlidos.
Que sean desplegados los mensajes apropiados de error y precaucin
cuando se usan datos invlidos.
 Pruebas de Regresin

Son una estrategia de prueba en la cual las pruebas que se han

ejecutado anteriormente se vuelven a realizar, esta vez, sobre en una
nueva versin modificada del producto de software.

Estas pruebas buscan asegurar la calidad despus de aadir la nueva

funcionalidad a un componente que se haba evaluado anteriormente.
El propsito de estas pruebas es asegurar que:

Los defectos identificados en la ejecucin anterior de la prueba se ha

corregido.
Los cambios realizados no han introducido nuevos defectos o
reintroducido defectos anteriores.
 Pruebas de Valores Lmites

Pruebas diseadas para evaluar el manejo de error con valores lmites

o valores extremos.

Si una condicin de entrada est en un rango de valores entre A y B,

se deben disear pruebas para los lmites A y B, as como para los
valores dentro de los lmites y por encima de estos.
 Pruebas de Integracin

Las pruebas de integracin se llevan a cabo durante la construccin

del sistema, involucran a un nmero creciente de mdulos y terminan
probando el sistema como conjunto.

Se prueban todos los mdulos asociados. Se realizan con el fin de

encontrar fallos en las interfaces entre nuestro sistema y otros con los
que interacciona.
Pruebas de Carga de Ambiente

Estas pruebas son ejecutadas por los analistas programadores, no por

el rea de Gestin de Calidad.

Las pruebas de carga estudian el programa o componente de software

en condiciones limitadas de volumen, estrs y almacenaje.
Se utiliza la herramienta WebLoad para ejecutar stas pruebas.
Pruebas de Caja Blanca

Son llamadas tambin caminatas de cdigo.

Estas pruebas no son ejecutadas por los Gestores de Calidad, sino
son implementadas por los Lderes Tcnicos, con ellas se valida la
lgica de implementacin en el cdigo fuente programado o modificado
por sus subalternos.
 Actualmente en la ejecucin de pruebas, no se estn utilizando
herramientas automatizadas, sin embargo se est evaluando la necesidad
de las mismas y analizando las siguientes:

ARCAD Software
VERIFIER
EXTRACT

RATIONAL
IBM Rational Robot

ORIGINAL SOFTWARE
1 Qualify
2. Test-bench
3. Test-drive
 Tal y como participa actualmente el rea de Gestin de Calidad en
el proceso de desarrollo, las mtricas se obtienen tomado como
referencia lo siguiente:

Satisfaccin del Cliente (mediante una encuesta sobre el servicio

recibido).

Existe un SLA (Service Level Agreement) de tiempo definido para la

atencin de los servicios de Gestin de Calidad.
Dado que el software es uno de los activos ms importantes para la
operativa de la empresa y con el debe garantizarse la continuidad del
negocio, esto ha propiciando un mayor apoyo de las otras gerencias al
rea de Calidad de Software.

Por esta razn se realiz un anlisis exhaustivo sobre las necesidades

de la empresa en relacin a la calidad del software y el nivel de
madurez en ste campo.

Como resultado de ste anlisis se propuso un nuevo proceso de

Calidad de Software, siguiendo el esquema de Centro de Excelencia
(CoE), este es un proceso robusto y maduro, el cual se ajusta a las
necesidades de cada rea de desarrollo.
Objetivo del Proceso:

Lograr que los productos se entreguen con niveles consistentes de

calidad.

Que la funcionalidad de los productos cumpla con las expectativas de

los clientes.

Verificar que los requerimientos tengan un nivel de cumplimiento con

los objetivos definidos por el cliente.

Validar la funcionalidad de los mdulos, sistemas e interfaces definidas

dentro del alcance del proyecto.