Pruebas de Software

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 través 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 relación
con otras empresas dedicadas al desarrollo de software, sin embargo
el área de calidad ha evolucionado constantemente, siempre tratando
de minimizar los errores en producción 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, convirtiéndose éste en el propósito 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 liberación a producción 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
Gestión de Calidad son las siguientes:
1. Revisión de Documentación
2. Ejecución Pruebas de Aceptación
Documento en el que se diseñan casos de pruebas, éstos a su vez
están 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 Gestión de Calidad, sin embargo
al llevar a cabo la revisión del plan de pruebas, debe revisarse
indirectamente los documentos:


Especificación de Requerimientos de Sistema.
Especificación de Requerimientos de Software (Diagrama de Casos de
Uso, Casos de Uso en Modelo Extendido).
Objetivo de la Revisión
En la revisión se amplia y se mejora el plan de pruebas tomando
como referencia los documentos mencionados.
Lo que se busca en ésta revisión es que se estén cubriendo todos los
posibles escenarios a probar, se define las prioridades de los
escenarios y se asegura que el documento cumpla con los estándares
tanto de forma como de fondo, definidos por la empresa.
Además de acuerdo a la cantidad de escenarios que conformen el plan
de pruebas, se realiza la estimación del tiempo que se requiere para
posteriormente ejecutar las pruebas.
La estrategia para ejecutar las pruebas, constituye en la ejecución de
los casos de prueba diseñados 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 prácticamente en la etapa final del desarrollo,
antes de salir a producción.

Una vez que el proyecto se encuentre en ésta etapa, se realiza la
coordinación con el analista y el líder de negocio para la ejecución de
las pruebas.

Las pruebas se ejecutan en un ambiente de pruebas, el cual es similar
al ambiente de producción.

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 ejecución de las pruebas.

La ejecución de las pruebas se lleva a cabo en conjunto con el
analista programador y el líder de negocio que valida que la aplicación
cumpla con lo definido y acordado en los requerimientos en la etapa de
diseño.

En caso de que se identifiquen errores o deficiencias de la aplicación
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 programación 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 revisión y certificada la aplicación en conformidad
con los requerimientos y concepciones reales del diseño, se procede a
dar el visto bueno para seguir el flujo de desarrollo y finalmente que el
proyecto salga a producción.

No existe un proceso de pruebas definido y publicado para la
organización.

Resistencia al proceso de pruebas, calidad versus tiempo de entrega.

Documentos de Requerimientos de Sistema y Documento de
Requerimientos de Software mal diseñados.

No hay repositorios eficaces para la documentación de los casos de
prueba que permitan la reutilización 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 estándares 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 difíciles de recolectar.

Falta de administración 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 ejecución de
pruebas.

El proceso de pruebas se ejecuta en las etapas finales del proyecto.
Las pruebas que realiza el departamento de Gestión 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 categoría existen una serie de tipos de pruebas, entre
las que se mencionan:




Pruebas Funcionales
Pruebas de Regresión
Pruebas de Valores Límite
Pruebas de Integración

Pruebas Funcionales
Evalúan el conjunto de características y capacidades de los
componentes del sistema.
Aseguran el trabajo apropiado de los requisitos funcionales, incluyendo
la navegación, entrada de datos, procesamiento y obtención de
resultados. Se verifica lo siguiente:



Que se aplique apropiadamente cada regla de negocio.
Que los resultados esperados ocurran cuando se usen datos válidos.
Que sean desplegados los mensajes apropiados de error y precaución
cuando se usan datos inválidos.

Pruebas de Regresión
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 versión modificada del producto de software.
Estas pruebas buscan asegurar la calidad después de añadir la nueva
funcionalidad a un componente que se había evaluado anteriormente.
El propósito de estas pruebas es asegurar que:


Los defectos identificados en la ejecución anterior de la prueba se ha
corregido.
Los cambios realizados no han introducido nuevos defectos o
reintroducido defectos anteriores.

Pruebas de Valores Límites
Pruebas diseñadas para evaluar el manejo de error con valores límites
o valores extremos.
Si una condición de entrada está en un rango de valores entre A y B,
se deben diseñar pruebas para los límites A y B, así como para los
valores dentro de los límites y por encima de estos.

Pruebas de Integración
Las pruebas de integración se llevan a cabo durante la construcción
del sistema, involucran a un número creciente de módulos y terminan
probando el sistema como conjunto.
Se prueban todos los módulos 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 Gestión de Calidad.
Las pruebas de carga estudian el programa o componente de software
en condiciones limitadas de volumen, estrés y almacenaje.
Se utiliza la herramienta WebLoad para ejecutar éstas pruebas.
Pruebas de Caja Blanca
Son llamadas también caminatas de código.
Estas pruebas no son ejecutadas por los Gestores de Calidad, sino
son implementadas por los Líderes Técnicos, con ellas se valida la
lógica de implementación en el código fuente programado o modificado
por sus subalternos.
Actualmente en la ejecución de pruebas, no se están 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 Gestión de Calidad en
el proceso de desarrollo, las métricas se obtienen tomado como
referencia lo siguiente:

Satisfacción del Cliente (mediante una encuesta sobre el servicio
recibido).

Existe un SLA (Service Level Agreement) de tiempo definido para la
atención de los servicios de Gestión de Calidad.
Dado que el software es uno de los activos más 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 razón se realizó un análisis exhaustivo sobre las necesidades
de la empresa en relación a la calidad del software y el nivel de
madurez en éste campo.
Como resultado de éste análisis 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 módulos, sistemas e interfaces definidas
dentro del alcance del proyecto.