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 Funciones Salidas
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.