INTRODUCCIÓN

El incremento de la complejidad de los productos de software incrementa a su vez la necesidad de asegurar su calidad mediante la fase de prueba. Sin embargo, esta fase suele realizarse al final del proceso de desarrollo, lo que provoca en la mayoría de los casos que se realice de manera superficial e incompleta teniendo en cuenta que al cierre del proceso aumentan las presiones de plazo y de costes.

La División DATAZUCAR tiene como premisa prevenir la entrega no intencional de productos no conformes a sus clientes y para ello define las pruebas y verificaciones que se realizan a los productos de software, antes de que sean entregados a los clientes externos para su uso final o demostrativo, fuera o dentro de la institución, por lo que se le otorga especial atención a la realización de pruebas tempranas a los productos paralelo a su desarrollo.

DESARROLLO

La validación del software debe basarse en la prevención y detección temprana de los errores, ya que éstos se producen más frecuentemente en las primeras fases del ciclo de vida y el coste de corregirlos crece exponencialmente según avanza el proyecto. Ambos procesos, desarrollo y pruebas, deben realizarse en paralelo, de aquí la importancia de contar con un Sistema de Gestión de la Calidad (SGC) que cubra todo el ciclo de vida del proceso de desarrollo.

Las metodologías ágiles son una serie de técnicas para la gestión de proyectos basadas en el desarrollo iterativo e incremental, donde el proyecto se divide en distintos bloques temporales denominados iteración. En una iteración se repite un determinado proceso de trabajo donde los componentes logran evolucionar el producto dependiendo de los completados en las iteraciones antecesoras, agregando más opciones de requisitos y logrando así un mejoramiento.

Específicamente Scrum (Ágil) es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente en la entidad donde el desarrollo de un nuevo producto software o la modificación de uno existente se divide en iteraciones, lo cual permite que el desarrollo se realice de forma iterativa/incremental, logrando al final de cada iteración una nueva versión funcional del producto. 

Las necesidades de los usuarios se representan mediante “historias de usuario” que corresponden a los requisitos del sistema y contienen los criterios de aceptación del cliente. Estos criterios son definidos por el Especialista Funcional que establece una lista priorizada de requisitos para la iteración y sus criterios de aceptación para considerar el requisito como satisfecho. Cada historia de usuario tiene asociado criterios de aceptación y para cada criterio de aceptación se definen casos de prueba. 

Una vez definida de forma correcta una historia de usuario, el probador del equipo tendrá suficientes elementos para diseñar y documentar los casos de prueba necesarios para ejecutar el plan de pruebas que incluye:

• pruebas funcionales basadas en los criterios de aceptación facilitados por el cliente, 
• pruebas que demuestran el rendimiento y el uso eficiente de los recursos,
• pruebas que permitan encontrar los errores y fallas en el producto que se desarrolla.

Un caso de prueba describe el procedimiento a seguir paso a paso para los diferentes caminos válidos de un escenario de prueba. Un escenario de prueba puede tener uno o más casos de prueba asociados a él y contiene un identificador, sus precondiciones, los pasos a seguir y los resultados esperados. Una vez ejecutado el caso de prueba se especifica su estado y se describe el resultado actual real añadiendo comentarios en cada escenario fallido a lo largo del desarrollo de la iteración. 

En cada iteración del proceso de desarrollo, paralelamente a la implementación de los requisitos comprendidos dentro del alcance de la iteración en curso, se realizan pruebas al producto en desarrollo por parte de los probadores y a partir de los criterios de aceptación establecidos para cada requisito. Las pruebas de control de la calidad sobre una versión intermedia se realizan con el propósito de asegurar, desde iteraciones tempranas, la calidad del producto en desarrollo. Esta revisión completa se realiza ejecutando los casos de pruebas diseñados a partir de los criterios de éxito de las historias de usuarios. El rol de probador dentro del proceso de desarrollo, no impide que la persona que lo desempeñe pueda simultanear las actividades de prueba con otras propias de otros roles, como por ejemplo las actividades propias del rol de desarrollador. Sin embargo, bajo ninguna circunstancia pueden realizar pruebas a componentes de software o aplicaciones en cuyo desarrollo hayan participado como desarrolladores.

Los probadores deben verificar el cumplimiento de los requisitos definidos por el experto funcional y que se encuentran dentro del alcance de la iteración (esto incluye tanto funcionalidades incorporadas en la iteración como funcionalidades ya presentes en versiones anteriores del producto – pruebas de regresión), el cumplimiento de los requisitos definidos en la División DATAZUCAR para productos de software, la implementación de mecanismos para la validación y garantía de la coherencia de la información que se trabaja, el empleo del estándar de código definido, la correcta y coherente documentación del código generado, según requisitos definidos.

Los requisitos definidos en la División DATAZUCAR para productos de software son:

Se definirá un Producto No Conforme si:

• La solución informática incumple algún requisito funcional o no funcional definido por el experto funcional.
• La solución informática incumple los requisitos para productos de software definidos en la División DATAZUCAR.

Las incidencias detectadas durante el desarrollo por los probadores del equipo serán igualmente documentadas en las herramientas AgilePro y Gitlab para garantizar su seguimiento. El jefe de proyecto utiliza la información relativa a las pruebas realizadas, que

está registrada en la aplicación AgilePro, en la toma de decisiones relativas al reproceso del producto no conforme, si fuere necesario. Durante toda la iteración el probador del equipo podrá realizar pruebas exploratorias de control de la calidad manuales (caja blanca) no solo a las historias de usuario abiertas sino a toda la aplicación garantizando así una mejora incremental en cada entrega. 

El jefe de proyecto de conjunto con el equipo de desarrollo podrá considerar una incidencia como un impedimento técnico temporal y su corrección podrá ser re-planificada en una iteración posterior siempre y cuando esta no influya en la presentación demostrativa al experto funcional. Las incidencias detectadas internamente durante el proceso de desarrollo, por el probador del equipo deben ser solucionadas antes de la liberación de la iteración por parte del asegurador de la calidad de la entidad. Una vez realizadas las pruebas de liberación por el asesor de calidad, las fallas detectadas en productos que aún no se encuentran liberados, deben ser analizadas durante la reunión de retrospectiva correspondiente a dicha iteración. En dicha reunión los integrantes del equipo de desarrollo decidirán las acciones a tomar para su solución. (Ver Anexo 1).

Al finalizar la iteración las historias de usuario desarrolladas llegan con mayor calidad al asegurador de la calidad que es el encargado de detectar posibles incumplimientos de los requisitos funcionales y/o no funcionales del software, antes de que estos sean entregados al cliente para su uso o presentados con fines demostrativos, además realizará una evaluación el producto resultado de una iteración o del proyecto completo en función de los requisitos de calidad instaurados en la organización y en correspondencia con los requisitos y expectativas del cliente. Resultado de esta evaluación el asegurador decide si el producto/iteración es conforme o no para ser liberado y comunica por escrito la liberación o no del producto y entrega su documentación técnica. (Ver Anexo 2).

Las pruebas de liberación (control de la calidad de un producto terminado) son pruebas que se realizan obligatoriamente antes de que el producto software sea entregado al cliente externo para su utilización, pruebas o demostración, dentro o fuera de las instalaciones de la División DATAZUCAR. Las pruebas de control de la calidad se realizan usando la técnica de Pruebas Exploratorias, que mantienen el principio del muestreo, en oposición a la revisión completa que usa casos de prueba. El tamaño de la muestra debe estar en dependencia de si es una versión para liberación o si se trata de una revisión de una versión intermedia. Si el producto es liberado satisfactoriamente es publicado para su demostración al cliente.

La calidad y el porciento de No Conformidades (NC) son objetivos de la medición en el proceso de desarrollo de la entidad. La medida de la calidad se calcula a partir de la cantidad de NC detectadas en las pruebas de control de la calidad o de liberación. La medida del porciento de NC se calcula a partir de las corregidas en revisiones anteriores. (Ver Anexo 3).

Las pruebas de aceptación se escriben en las fases tempranas del desarrollo, y antes de que el sistema se implemente, para validar las necesidades de los usuarios y para dirigir la implementación. Se puede considerar que las historias de usuario y, por extensión, las pruebas asociadas juegan el papel de especificaciones del sistema.

Las metodologías ágiles plantean que el desarrollo no es un conjunto de fases en las que las pruebas son una fase más, sino que abogan por que las prácticas y el desarrollo estén completamente integradas, lo que puede llevar a modificar las estructuras organizativas de las empresas. Las metodologías ágiles no consideran las pruebas como un conjunto de niveles que hay que ir superando para alcanzar la validación final del sistema que se está desarrollando. Las metodologías ágiles presentan distintos enfoques del proceso de desarrollo que vienen determinados por los tipos de pruebas que se realizan.

CONCLUSIONES

Las pruebas desempeñan un papel importante en los diferentes modelos de procesos, en las prácticas ágiles para el desarrollo de software, las pruebas se escriben antes de comenzar la codificación y sólo se escribe el código necesario para superar las pruebas ya que estas guían el proceso de desarrollo. El hecho de que las pruebas se hacen tan pronto como es posible, está alineado con la reducción del impacto del coste y esfuerzo de la detección de errores en las fases de pruebas. 

Contar con un Sistema de Gestión de la Calidad que abarque todo el proceso de desarrollo donde se describan los procedimientos, roles y documentación establecida para el proceso de desarrollo de software y la prueba de los productos es indispensable para obtener resultados con valor agregado en el menor tiempo y con el menor costo posible.

RECOMENDACIONES

En las metodologías ágiles, no se distinguen de forma específica las pruebas de integración sino que para lograrla en cada una de las iteraciones, se aplican entornos de integración continua. Estos entornos además permiten la realización automatizada de las pruebas de regresión del sistema desarrollado por lo que se recomienda la utilización de herramientas que propicien estas mejoras en el desarrollo del software en la entidad.

La generación de pruebas automáticas son prácticas que igualmente optimizan el esfuerzo y coste en el desarrollo de aplicaciones. Su utilización en la entidad constituiría una ventaja favorable teniendo en cuenta la fluctuación de los recursos humanos en los equipos de desarrollo. Para ello es necesaria la homogenización de la escritura de las historias de usuarios a partir de los cuales se podrían generar los casos de prueba. 

Igualmente los históricos de los resultados de las pruebas pueden ser utilizados para estimar tiempo, esfuerzo, cantidad de no conformidades y niveles de cobertura a considerar en pruebas a productos.

TÉRMINOS Y DEFINICIONES

AgilePro. Aplicación utilizada para registrar las historia de usuarios.

Gitlab: Sistema de administración de repositorios GIT basado en la web, donde se registran las incidencias detectadas.

Pruebas de Regresión: Pruebas para detectar nuevos errores introducidos en funcionalidades existentes (regresiones), luego de la realización de cambios a una aplicación, como por ejemplo: incorporación de nueva funcionalidad, corrección de errores o cambios de configuración. Tienen como objetivo principal asegurarse de que un cambio no introdujo nuevos errores.

Pruebas Alfa: En este tipo de prueba el usuario o cliente, se invita al área de desarrollo para que use la aplicación, mientras los desarrolladores sirven de observadores para anotar cada acción o entrada particular llevada a cabo por el usuario. Cualquier comportamiento anormal del sistema debe documentarse para ser corregido.

Pruebas Beta: En este tipo de pruebas el software se distribuye como una versión beta a los usuarios para que lo revisen en sus dependencias. Igualmente se documentan las desviaciones detectadas.

Reproceso: Acción tomada sobre un producto no conforme para que cumpla con los requisitos del cliente. Al contrario de la reparación, el reproceso puede implicar el rediseño y el cambio de determinadas partes del producto no conforme.

Requisito: Necesidad o expectativa establecida, generalmente implícita u obligatoria.

Pre-alfa: Se refiere a todas las actividades realizadas durante el proyecto de software antes de la prueba. Estas actividades pueden incluir el análisis de requerimientos, diseño de software, desarrollo de software y pruebas unitarias. En nuestro proceso consideramos varios tipos de versiones pre-alfa que comúnmente se llaman milestones (hitos) incluyen conjuntos específicos de funciones y son liberados tan pronto como la funcionalidad es completa. 

Alfa: Es la primera versión del programa, la cual es enviada a los verificadores para probarla. Durante esta fase o versión el software todavía es inestable, se mantiene una trazabilidad respecto a los errores o la puesta en práctica de funcionalidades, pero satisface la mayoría de los requisitos. Los paquetes de software marcados como alfa no se presentan completos y no son adecuados para entornos de producción.

Beta: Una versión beta o liberación beta representa generalmente la primera versión completa del software, que es posible que sea inestable pero útil para inspecciones previa (preview) o como una inspección previa. Esta etapa comienza a menudo cuando se define que el desarrollo ha terminado, por lo que no se incluirán más características al producto y que solamente se harán pequeñas ediciones o se corregirán errores. Las versiones beta están en un paso intermedio en el ciclo de desarrollo completo. El equipo de desarrollo de conjunto con el área de comercial lanzan el software a un grupo de probadores beta (a veces el público en general o a un grupo reducido de empresas) para una prueba de usuario. Los probadores divulgan cualquier error que encuentran y características, a veces de menor importancia, que quisieran ver en la versión final. Los receptores de betas deberían firmar un acuerdo de no revelación.

RC release candidate, Candidata a lanzamiento: Una versión candidata a versión final o candidata para el lanzamiento, comprende un producto final, preparado para publicarse como versión definitiva a menos que aparezcan errores que lo impidan. En esta fase el producto implementa todas las funciones del diseño y se encuentra libre de cualquier error que suponga un punto muerto en el desarrollo. Muchas empresas de desarrollo utilizan frecuentemente este término.

Release to Manufacturing (RTM) o liberación de la comercialización: La versión de un producto lista para ser entregada al cliente. Normalmente es casi idéntica a la versión candidata final, con sólo correcciones de última hora. Esta versión es considerada muy estable y relativamente libre de errores con una calidad adecuada para una distribución amplia y usada por usuarios finales.  General Availability (GA) o Disponibilidad general, es el punto en el que todas las actividades de comercialización necesarios se han completado y el software se ha puesto a disposición del mercado general, ya sea a través de la web o medios físicos. Las actividades de comercialización podrían incluir, pero no están limitadas a la disponibilidad en los medios de comunicación sitios Web, etc. o a través de centros de distribución (colaboradores). La etapa de disponibilidad general (GA) indica que la liberación es muy estable y adecuada para su distribución masiva y de uso por los usuarios finales.

2.       Ciclo de vida de las liberaciones (División DATAZUCAR):