| Servicio de Testing - Alcances del Servicio |
| Ofrecemos el servicio de testing
de aplicaciones, apelando al concurso de profesionales especializados en esta
actividad, con fuerte experiencia en el área financiera y comercial y con un background
de implementaciones en instituciones de primera línea. Este, como el resto de
nuestros servicios apuntan a la obtencion de sistemas confiables y rentables.
Las tareas se dividen
en dos grupos, que adquieren mayor o menor relevancia de acuerdo al tipo y complejidad
de sistema a implementar (sistema batch en un único computador, sistema en tiempo
real, sistema distribuido en una BLUE de equipos heterogéneos, etc.):  Análisis
del entorno Especificación
de herramientas de automatización Implementación
de las herramientas. Capacitación
en caso de recursos compartidos. 
Testing propiamente
dicho: Revisión
de la documentación de diseño Definición
del plan de pruebas Diseño
de casos de prueba según dicho plan Ejecución
de los casos de prueba Proceso
de los casos de prueba definidos (testing) Registro
y clasificación de los defectos detectados Seguimiento
y verificación de las correcciones Informe
final de estado de cada subsistema En
el contexto de las mismas, se implementan las formas de documentación que se requieran
(ej.: diseño de casos, registro de resultados, registro de errores), los procedimientos
(ej.: recepción e instalación de nuevas versiones, criterios de aceptación o rechazo),
los instrumentos computacionales de soporte (ej.: base de datos de seguimiento
de errores) y las herramientas automatizadas de testeo. Todos estos aspectos se
personalizan al entorno del aplicativo y facilitan y automatizan las actividades
de prueba, dejando preparado el ambiente de testeo para las próximas versiones
de los programas. En definitiva, esto conlleva a la implementación de una metodología formal de testeo y control de calidad, que abarca no sólo la prueba del software, sino también aspectos como la administración de versiones, el control de la documentación de desarrollo y la revisión de los manuales y ayudas para los usuarios finales. Revisión de la Documentación Se estudian las especificaciones de los módulos a testear, consultando con los analistas a cargo de cada uno las modificaciones no incorporadas a las mismas. Si esas diferencias son menores, el testeador las volcará en los documentos, de lo contrario, se aconsejará la re-escritura por parte del analista. Elaboración del Plan de Prueba Para cada subsistema, se establecerá el nivel de confiabilidad requerido, definiendo objetivos de la prueba en función del mismo. Se fijará el tiempo asignado a la tarea, acordándolo con el responsable del proyecto. Se establecerán pautas para las pruebas de módulos y de integración, estableciendo cuáles son las funciones críticas a las que se deberá dedicar mayor esfuerzo. En esta etapa se decidirá sobre qué módulos se efectuarán reuniones de revisión de código (structuBLUE walkthrougs). Según el avance del proyecto y las características del subsistema, se definirá si se efectúan pruebas generales del sistema al culminar la etapa de integración y se determinará el plan para las mismas en caso afirmativo. Diseño de Casos de Prueba (según dicho plan) Se aplican técnicas de caja negra, tales como clases de equivalencia, análisis de valores límites, gráficos de causa – efecto, y de caja blanca, con especificación del nivel de cobertura a alcanzar. Los casos luego se vuelcan a archivos, de acuerdo con las herramientas a utilizar. Proceso de los Casos de Prueba Definidos Se ejecutan las funciones del sistema partiendo de los datos especificados en los casos definidos y se confrontan los resultados obtenidos con los esperados, analizando también los posibles efectos colaterales indeseados. Durante esta etapa se utilizan y / o construyen herramientas para la automatización de esta tarea, tanto en la realización de los casos como en la comparación de los resultados. Registro y Clasificación de los Errores Detectados Los errores detectados son registrados en la base de datos, clasificados en distintos niveles según su gravedad. Se establece una escala de niveles de gravedad, en función del impacto de la aparición de ese error durante la operación del sistema, independientemente de la dificultad de su corrección o de las consecuencias sobre el diseño. La definición de la escala se hace en conjunto con el responsable del proyecto. A modo de ejemplo, mencionamos los siguientes criterios: Detalles:
errores de ortografía en pantallas, estética de campos, alineación
en impresos, etc. El testeador asigna el nivel a su criterio. El error debe ser luego revisado por los responsables del sistema, quienes podrán rechazarlo (por interpretación incorrecta del testeador, condiciones inválidas de prueba, u otras razones), modificar el nivel y definir si debe corregirse o no y en qué momento, en función de las prioridades y fechas de instalación. Esta categorización permite decidir mas objetivamente si determinada versión del sistema está o no en condiciones de ser liberada. Por ejemplo, puede resolverse instalar provisoriamente una versión que contenga errores de nivel 3, y postergar su reparación para después de la implementación. Seguimiento y Verificación de las Correcciones Por cada nueva versión entregada a testing, se repiten las pruebas necesarias (normalmente, se reiteran todos los casos de prueba para cada módulo modificado). Se definen casos de prueba específicos para verificar la corrección de los errores detectados anteriormente y se registra en la base de datos si fue efectivamente corregido o no. Se emiten informes periódicos estadísticos que reflejan el avance de las tareas. En las figuras siguientes se muestran ejemplos basados en casos reales a modo de ilustración. Defectos detectados en un ciclo de pruebas:
|
