ProTest – Proceso de Testing Funcional Beatriz Pérez Universidad de la República, Grupo de Ingeniería de Software, Montevideo, Uruguay, 11000 bperez@fing.edu.uy
Resumen En este artículo se presenta ProTest, proceso para realizar testing funcional de un producto de software. Es independiente del ciclo de vida de desarrollo, y puede ser usado para realizar el testing funcional de productos desde su comienzo, a través de sucesivos ciclos de desarrollo o en productos ya terminados. ProTest es una guía pensada para una organización que se dedica a la evaluación de productos de software desarrollados por terceros y es el proceso aplicado en el Laboratorio de Testing Funcional del Centro de Ensayos de Software (CES), se presenta como caso de estudio su aplicación en un proyecto del CES. Las principales características de ProTest son: Se basa en el análisis de riesgos del producto a probar, se prueban primero las partes del producto cuyo funcionamiento incorrecto representan mayor impacto negativo para el negocio. La planificación del proyecto de testing se realiza en función de los ciclos de prueba: cada ciclo de prueba está asociado a una versión del producto a probar. El proceso definido incluye la revisión de las especificaciones y su mejora, en caso de ser necesario.
1. Introducción La motivación de contar con un equipo de testing independiente del desarrollo surge para mitigar la falta de objetividad al realizar el testing que puede ocurrir cuando la organización que desarrolla es la misma que escribe las pruebas, esto, sumado a las presiones institucionales por salir al mercado hacen que en muchos casos la calidad del software se conozca recién cuando se pone en producción. En organizaciones de pequeño y mediano porte la subcontratación de los servicios de testing es imprescindible para implementar el testing independiente, ya que es difícil sustentar la existencia de un área dedicada exclusivamente al testing dentro de la organización misma.
Dentro de las ventajas que se obtienen al tener una organización de testing independiente de la de desarrollo están la motivación en el proceso de pruebas, la separación del proceso de pruebas del control gerencial de la organización de desarrollo y el conocimiento especializado que la organización independiente tiene respecto a las pruebas [1]. Dentro de las desventajas se encuentra que la organización de testing independiente puede no tener el conocimiento necesario del dominio del negocio, lo que puede llevar a que olvide aspectos importantes o los subestime. Además, si la curva de aprendizaje del producto es elevada, la transmisión de conocimiento puede ser demasiado costosa y se corre el riesgo de que con el tiempo el equipo de testing independiente sea el único que conoce como probar el producto. El testing se define como la verificación dinámica del comportamiento de un programa usando un conjunto finito de casos de prueba, seleccionados desde el dominio infinito de ejecución, contra el comportamiento esperado. La verificación dinámica implica que para realizar las pruebas siempre hay que ejecutar el programa para los datos de entrada [5]. El testing funcional tiene como objetivo validar si el comportamiento observado del software probado cumple o no con sus especificaciones. [5]. Los conceptos, las estrategias, las técnicas y las mediciones del testing son integrados en un proceso definido y controlado que es realizado por personas. El proceso de testing apoya las actividades de testing y provee guías para el equipo de testing de forma de asegurar que los objetivos del test son alcanzados de forma rentable [2]. ProTest es el proceso aplicado en el Laboratorio de Testing Funcional del Centro de Ensayos de Software (CES)[3], se presenta como caso de estudio su aplicación en un proyecto del CES. El resto del documento de organiza de la siguiente forma. En la sección 2 se describen los principales aportes para este trabajo, en la sección 3 se describe el proceso ProTest, se definen sus etapas y roles. En la sección 4 se muestra para cada etapa las principales
actividades que la componen. En la sección 5 se describe la experiencia de aplicar ProTest en el Centro de Ensayos de Software y en la sección 6 se presentan las conclusiones.
2
Trabajos Relacionados
Los aportes para este trabajo surgen de diferentes fuentes, a continuación se describen las principales referencias utilizadas, dichas referencias son citadas cuando corresponde en los puntos 3 y 4 de este artículo donde se presenta ProTest. La propuesta de Rex Black [4] se concentra en los aspectos administrativos y de gestión del testing: su planificación, seguimiento y control, sin entrar en detalles de cómo realizar el testing. La propuesta de Edward Kit [5], muestra como usar técnicas y estrategias para mejorar el proceso de testing, sin especificar una metodología de trabajo. La propuesta de Cem Kaner, James Bach, Bret Pettichord [6], recopila 293 lecciones aprendidas por los autores al realizar testing, sin definir una forma de trabajo para aplicarlas. Testing Maturity Model (TMM)[7] es una guía para las organizaciones que quieren mejorar y evaluar su proceso de testing. TMM contiene un conjunto de niveles para que la organización mejore la madurez de su proceso de testing, un conjunto de prácticas recomendadas en cada nivel de madurez y un modelo de evaluación que permite a la organización evaluar y mejorar su proceso de testing. Todas estas propuestas se focalizan en el testing realizado por el equipo de desarrollo, ProTest combina las actividades y guías existentes en estas propuestas en lo que tiene que ver con realizar testing funcional y su gestión, agrupándolas en etapas con objetivos definidos. Una actividad en ProTest es el resultado de integrar las distintas propuestas y de ajustarlas para ser utilizadas en forma independiente del ciclo de vida de desarrollo.
3
ProTest
En esta sección se definen las etapas de ProTest y cómo ocurren en el tiempo, sus objetivos y los roles definidos para el proceso.
3.1 Etapas de ProTest En la figura 1 se muestran las etapas de ProTest en el tiempo, el proceso consta de cuatro etapas: Estudio Preliminar, Planificación, Ciclos de Prueba y Evaluación del Proyecto.
Figura 1: Etapas de ProTest Estudio Preliminar: Esta etapa ha sido pensada para el caso de la evaluación independiente de un producto, donde previo a comenzar con el proyecto de testing, se debe estudiar la factibilidad de realizar el mismo. Planificación: El objetivo de esta etapa es planificar el proyecto de Testing, una vez que se acordó con el cliente comenzar el proyecto de prueba. Ciclos de Prueba: Uno de los principales desafíos desde el punto de vista del testing independiente es estimar cuantos ciclos de prueba se requieren. En un ciclo de prueba se puede ejecutar una, alguna o todas las pruebas planificadas para el producto. Cada ciclo de prueba está asociado a una versión del producto a probar, cada nuevo ciclo de prueba implica una nueva versión de uno o más componentes del sistema [4]. Esta etapa se divide a su vez en sub-etapas como se muestra en la figura2. Evaluación: Durante esta etapa se evalúa la satisfacción del cliente, se realiza el informe final y se evalúa el proceso, ajustándolo para su uso en proyectos posteriores. En cada ciclo de prueba se realizan cuatro subetapas en el tiempo como se muestra en la figura 2. Las sub-etapas definidas para un ciclo son: Seguimiento del Ciclo, Configuración del Entorno, Diseño de las Pruebas y Ejecución de las Pruebas. Los objetivos de cada sub etapa en un ciclo de prueba se describen a continuación: Configuración del Entorno: El objetivo de esta sub etapa es configurar el ambiente de pruebas, separando los ambientes de desarrollo y testing, instalar las herramientas necesarias y el software a probar en la versión correspondiente a cada ciclo de prueba. Diseño de las Pruebas: Durante esta etapa se realiza el diseño de los casos de prueba a partir de la especificación del producto, según la estrategia de pruebas definida en la etapa de Planificación Ejecución de las Pruebas: El objetivo de esta etapa es contrastar el comportamiento esperado del software con su comportamiento real, analizar las diferencias y reportar los resultados. Seguimiento del Ciclo: Esta etapa ocurre en paralelo con las tres anteriores. Se realiza el seguimiento y control del proyecto de Testing. La planificación realizada al principio del proyecto es revisada al comenzar cada ciclo de prueba. Se planifica en detalle las tareas para el ciclo y se ajusta la planificación según las estimaciones y posteriores mediciones realizadas en los ciclos anteriores.
Figura 2: Sub etapas en cada Ciclo de Prueba Los ciclos de prueba se solapan en el tiempo, por ejemplo, mientras se ejecutan las pruebas para un ciclo, se puede al mismo tiempo estar diseñando las pruebas del ciclo siguiente, como se ilustra en la figura 2.
3.2 Roles Los roles definidos para el equipo de testing son: Líder del Proyecto de Testing, Diseñador y Tester. El líder es quien dirige el proyecto de testing. El diseñador es quien realiza el diseño de los casos de prueba a partir de las especificaciones del producto y el Tester es quien ejecuta los casos de prueba y reporta los resultados. Existen además dos roles que no son parte del equipo de testing: el Cliente y el Desarrollador. Aquí definiremos al Cliente como la persona que necesita el producto y que está interesado en la calidad del mismo, conoce las necesidades del negocio y el impacto que el funcionamiento incorrecto de cada parte del producto tiene en el mismo. El desarrollador es quien construye el producto de software, conoce como fue realizado internamente y las fortalezas y debilidades de los distintos módulos que lo componen.
4
Etapas y Actividades de Protest
En esta sección se describen los objetivos, las principales actividades y los roles involucrados en cada una de las Etapas de ProTest.
4.1 Estudio Preliminar Esta etapa ha sido introducida en ProTest debido a que en la evaluación independiente de un producto, en forma previa a comenzar con el proyecto de testing, se debe estudiar la factibilidad de realizar el mismo. Las actividades a realizar son un subconjunto de las realizadas en la etapa de Planificación, a diferencia de
esa etapa, aquí se realizan con el objetivo de estudiar la factibilidad del proyecto de prueba y realizar una cotización del mismo. Se realiza un estudio preliminar de las partes más riesgosas del producto y se negocia con el cliente qué funcionalidades serán probadas y cuáles no, acordando una primera agenda sobre la cual realizar la planificación del proyecto de testing. En el caso de que se llegue a un acuerdo entre las partes se pasa a las etapas siguientes del proceso de testing. En la tabla 1 se muestran las actividades que se realizan en esta etapa y los roles involucrados. Dichas actividades se describen en la próxima etapa: Planificación. Tabla 1: Actividades y roles de la Etapa: Estudio Preliminar Estudio Preliminar Actividad Negociación con el cliente Revisión de Requerimientos Análisis de Riesgos del Producto
Roles involucrados Cliente, Desarrollador, Líder de Proyecto Cliente, Desarrollador, Líder de Proyecto Cliente, Desarrollador, Líder de Proyecto
4.2 Planificación El objetivo de esta etapa es planificar el proyecto de Testing, una vez que se acordó con el cliente comenzar el proyecto de prueba. En la tabla 2 se muestra para cada actividad, los roles involucrados en esta etapa. La negociación con el cliente tiene como objetivo ponerse de acuerdo respecto a las actividades a ser realizadas por el equipo de testing, por los desarrolladores y el cliente. Se define el alcance del proyecto de testing, esto es, qué funcionalidades se van a probar y cuales no y una agenda preliminar, indicando la cantidad de ciclos de prueba y las fechas tentativas de comienzo y fin de cada ciclo. No es posible probar todo, la decisión de qué probar se basa en los riesgos de cada parte del sistema. En la actividad Análisis de Riesgo del Producto se realiza una lista priorizada de las funcionalidades del producto, junto con el cliente y desarrolladores Al realizar testing funcional se debe decidir si la salida observada al ejecutar el programa es la salida esperada. La salida esperada está expresada en las especificaciones del producto. La actividad Revisión de Requerimientos estudia la correspondencia entre las distintas fuentes de requerimientos y evalúa si es posible realizar el diseño de las pruebas a partir de ellas. En caso contrario, se debe trabajar junto con desarrolladores y cliente en mejorar los requerimientos
existentes. Las especificaciones pueden ser obtenidas de diferentes fuentes: documentos de requerimientos, sistemas ya existentes, manuales del sistema, reportes de defectos, entrevistas con cliente y usuarios, prototipos. Tabla 2: Actividades y roles de la Etapa: Planificación Planificación Actividad Negociación con el cliente Revisión de Requerimientos Análisis de Riesgo del Producto Definición de los Ciclos de Prueba Definición del Plan de Pruebas
Roles involucrados Cliente, Desarrollador, Líder de Proyecto Cliente, Desarrollador, Líder de Proyecto Cliente, Desarrollador, Líder de Proyecto Cliente, Desarrollador, Líder de Proyecto Líder de Proyecto
En general los tiempos no permiten volver a correr todas las pruebas para cada versión, esto fuerza a seleccionar un conjunto de pruebas en cada ciclo de prueba [4]. En la actividad Definición de los Ciclos de Prueba se definen las funcionalidades que serán probadas en cada ciclo junto con el cliente a partir del análisis de riesgo del producto. En el plan de pruebas se define quién, cuándo, dónde y cómo se realizan las actividades de testing. Se incluye el alcance del proyecto, el calendario, los ciclos, los requerimientos de hardware y software para ejecutar las pruebas, las técnicas usadas para el diseño de las pruebas, los roles y sus responsabilidades, la clasificación de los defectos usada en el proyecto y la especificación de qué reportes y otros productos se entregarán al cliente durante el proyecto y al finalizar el mismo.
4.3 Ciclos de Prueba El objetivo de esta etapa es realizar las pruebas para cada versión del producto. En un ciclo de prueba se puede ejecutar una, alguna o todas las pruebas planificadas para el producto. Esta etapa se divide a su vez en sub-etapas como se muestra en la figura 2 de la sección 2.1 de este artículo. Las sub-etapas son: Seguimiento del Ciclo, Configuración del Entorno, Diseño de las Pruebas y Ejecución de las Pruebas. En cada ciclo, se comienza con la sub-etapa: Seguimiento del Ciclo, donde se administra y planifica el ciclo de prueba. En paralelo se realizan las subetapas de Configuración del Entorno y el Diseño de las Pruebas, a continuación se realiza la Ejecución de las Pruebas. Si no se cuenta con la versión ejecutable del producto, el Diseño de las Pruebas puede realizarse de
todos modos, ya que se realiza a partir de la especificación del producto, en cambio la Configuración del Entorno y la Ejecución de las Pruebas requieren de la versión ejecutable del producto. Los ciclos de prueba se solapan en el tiempo, por ejemplo, mientras se ejecutan las pruebas para un ciclo, se puede al mismo tiempo estar diseñando las pruebas del ciclo siguiente, como se ilustra en la figura 2. 4.3.1
Seguimiento del Ciclo
La planificación realizada al principio del proyecto es revisada al comenzar cada ciclo de prueba. Se planifica en detalle las tareas para el ciclo y se ajusta la planificación según las estimaciones y posteriores mediciones realizadas en los ciclos anteriores. En la tabla 3 se muestra para cada actividad, los roles participantes en esta sub-etapa. El análisis de riesgo del producto puede requerir ser ajustado, debido a cambios en las prioridades del negocio o a la confianza adquirida en el producto como resultado de la realización de las pruebas en ciclos anteriores. Se revisa la lista de riesgos y se modifica en caso de ser necesario. Tabla 3: Actividades y roles de la sub-etapa: Seguimiento del Ciclo Seguimiento del Ciclo Actividad Análisis de riesgo del producto Planificación del Ciclo
Roles involucrados Cliente, Desarrollador, Líder de Proyecto Cliente, Desarrollador, Líder de Proyecto
En la actividad Planificación del Ciclo se realiza el plan detallado de las tareas a realizar en el ciclo de prueba, estimando el tiempo y esfuerzo requerido para cada tarea. Para realizar la planificación del ciclo se tienen en cuenta las mediciones de ciclos anteriores, las funcionalidades priorizadas para el ciclo y las pruebas de regresión que deben ejecutarse en el ciclo, debido a incidentes encontrados en ciclos anteriores que fueron arreglados para la versión de este ciclo. 4.3.2
Configuración del Entorno
El objetivo de esta sub-etapa es configurar el ambiente de pruebas, separando los ambientes de desarrollo y testing e instalar las herramientas necesarias y el software a probar en la versión correspondiente a cada ciclo de prueba. Esta etapa es
realizada por desarrolladores 4.3.3
los
Testers,
apoyados
por
los
Diseño de las Pruebas
El objetivo de esta etapa es diseñar las pruebas que serán luego ejecutadas sobre el software a probar. Incluye revisar los requerimientos de las funcionalidades que serán probadas en este ciclo, diseñar los casos de prueba, identificar los datos de prueba y validar los casos de prueba con el cliente. En la Tabla 4 se muestra para cada actividad, los roles involucrados en esta sub-etapa. En la actividad Revisión de Requerimientos se revisan las especificaciones existentes de las funcionalidades que han sido planificadas para este ciclo, en caso de que no sea posible realizar el diseño de las pruebas a partir de ellas, se trabaja junto con desarrolladores y cliente en mejorar los requerimientos existentes. En cada ciclo se mejoran solamente las funcionalidades que van a ser probadas en el ciclo. Tabla 4: Actividades y roles de la sub-etapa: Diseño de las Pruebas Diseño de las Pruebas Actividad Revisión de Requerimientos Diseño de los casos de prueba Validación de los casos de prueba
Roles involucrados Cliente, Desarrollador, Líder de Proyecto Diseñador Diseñador, Desarrollador
Ejecución de las Pruebas
Tabla 5: Actividades y roles involucrado en la subetapa: Ejecución de las Pruebas Ejecución de las Pruebas Actividad Pruebas de Humo Ejecución de las Pruebas Testing Exploratorio Verificación de las correcciones Evaluación de las Pruebas
Roles involucrados Tester Tester Tester Tester Líder de Proyecto, Diseñador, Tester
Cliente,
En la actividad Diseño de los Casos de Prueba, usando técnicas de caja negra se desarrollan los casos de prueba. Esta actividad incluye diseñar las pruebas e identificar los datos de prueba. Para cada funcionalidad a probar, se crea una matriz que muestra su correspondencia con los casos de prueba, de forma de conocer qué casos de prueba cubren qué ítems de prueba [7]. Entre las técnicas posibles de caja negra a utilizar para el diseño de los casos de prueba se encuentran: partición de equivalencia, valor límite, conjetura de errores, grafo causa efecto [1], partición en categorías [8], máquinas de estado finitas [9], escenarios [6]. En la actividad Validación de los Casos de Prueba, los casos de prueba definidos deben ser validados con el cliente. Se busca con esta actividad que los casos de prueba diseñados y los datos de prueba sean de valor para el negocio.
4.3.4
El objetivo de esta etapa es contrastar el comportamiento esperado del software con su comportamiento real, analizar las diferencias y reportar los resultados. Al finalizar la etapa se reporta el avance del testing en el ciclo y se evalúan los resultados obtenidos. En la Tabla 5 se muestra para cada actividad, los roles involucrados en esta sub-etapa. Las pruebas de humo son un conjunto de pruebas aplicadas a cada nueva versión, su objetivo es validar que las funcionalidades básicas de la versión se cumplen según lo especificado. Estas pruebas buscan grandes inestabilidades o elementos clave faltantes o defectuosos, que hacen imposible realizar el testing como fue planificado para el ciclo. Si la versión no pasa las pruebas de humo, no se comienza la ejecución de las pruebas de la versión [6].
La actividad Ejecución de las Pruebas consiste en ejecutar los casos de prueba seleccionados para el ciclo y observar su resultado. Incluye seleccionar los casos de prueba, ejecutarlos, registrar resultados y determinar si los defectos son causados por errores en el producto o errores en las pruebas. En caso de encontrar defectos, se reportan. Al reportar un incidente debe quedar claro si es un defecto, una mejora o una observación y estar acompañado de una valorización de impacto y criticidad. La ejecución de las pruebas puede ser manual o automatizada. El testing exploratorio se define como el aprendizaje, diseño y ejecución del testing en forma simultánea [10]. Los testers diseñan, desarrollan y ejecutan las pruebas durante la ejecución del producto. Esta actividad tiene como objetivo mitigar el riesgo de estar realizando un mal análisis de riesgo del producto, de esta forma se realiza testing con otra metodología distinta a la de realizar testing basado en los riesgos. Si se encuentran defectos durante el Testing Exploratorio que no fueron encontrados por las pruebas planificadas y que son críticos para el funcionamiento del producto o para el cliente, entonces, es momento de revisar el análisis de riesgo realizado.
La actividad Verificación de las Correcciones es la que sigue a un ciclo de prueba: se revisa que el incidente se haya corregido y que pueda ser cerrado. Luego de terminada la ejecución de las pruebas en un ciclo de prueba, los incidentes reportados serán corregidos por los desarrolladores. Los testers realizan las pruebas de regresión para asegurar que los cambios no introducen un comportamiento no deseado o nuevos errores. Esto implica seleccionar los casos de prueba a reejecutar, ejecutarlos y reportar nuevos incidentes si corresponde. Al finalizar el ciclo de prueba, la actividad Evaluación de las Pruebas implica realizar los reportes de avance del proyecto, mostrando el avance del testing del ciclo y de la calidad de la versión probada. Se evalúa el testing realizado en el ciclo y si es necesario seguir o se deben parar las pruebas. Para realizar el seguimiento de las pruebas ejecutadas se cuenta el número de casos de prueba planificados, disponibles, ejecutados, ejecutados exitosos, ejecutados fallidos [5]. 4.3.5
Evaluación del Proyecto
Esta etapa tiene como objetivos conocer el grado de satisfacción del cliente, realizar el informe final y la evaluar el proceso de testing para su mejora. En la Tabla 6 se muestra para cada actividad, los roles involucrados en esta etapa. Al finalizar el proyecto, es importante conocer el grado de satisfacción del cliente respecto a los resultados obtenidos, la comunicación que se tuvo durante el proyecto y a su percepción del avance durante el proyecto. Estos elementos ayudan a ajustar y mejorar el proceso de testing. Los modelos de mejora del proceso de testing como el Testing Maturity Model (TMM) [7], muestran la importancia de tener un grupo dedicado a la mejora del proceso de testing, que aplique técnicas de mejora incremental del proceso y evalúe su impacto. Al finalizar el proyecto de testing, el equipo de mejora del proceso de testing junto con el equipo de testing debe evaluar los procedimientos existentes para futuras experiencias. Según la naturaleza del dominio del negocio de cada producto de software a probar, pueden surgir procedimientos específicos, que es interesante recolectar y escribir, de forma de ayudar a la mejora del proceso y de guardar una memoria colectiva. Una vez finalizado el proyecto de testing, se realiza un reporte que resume el proyecto en su conjunto. Este reporte debe indicar el esfuerzo total, el esfuerzo por ciclo, por etapa y por actividad, las desviaciones que ocurrieron respecto al proceso definido y las razones de dichas desviaciones. Las
mediciones realizadas durante este proyecto de testing son la base para las estimaciones de los proyectos posteriores. Tabla 6: Actividades y roles involucrado en la etapa: Evaluación del Proyecto Evaluación del Proyecto Actividad Evaluación de la satisfacción del Cliente Ajustes y Mejoras del Proceso de Testing Reporte Final del Proyecto de Testing
5
Roles involucrados Cliente, Líder de Proyecto Líder de Proyecto, Diseñador, Tester Líder de Proyecto
Aplicación en el Laboratorio de Testing del Centro de Ensayos de Software
5.1 El Centro de Ensayos de Software En el año 2004 se crea el Centro de Ensayos de Software [3]. Se trata de un emprendimiento conjunto de la Universidad de la República (UDELAR) de Uruguay, a través de la Fundación Julio Ricaldoni, y de la CUTI (Cámara Uruguaya de Tecnologías de la Información), entidad que agrupa a la mayoría de las empresas productoras de software del país. El CES brinda servicios de verificación y evaluación de software, funcional y no funcional. El CES está compuesto por un Laboratorio de Testing, enfocado en la evaluación de productos desde el punto de vista funcional y un Laboratorio de Ensayos de Plataformas con el objetivo de realizar pruebas de desempeño y asistir a la industria en resolver problemas de funcionamiento en arquitecturas de hardware y software complejas.
5.2 La aplicación de ProTest ProTest es aplicado en el Laboratorio de Testing del Centro de Ensayos de Software (CES), en general, los clientes con que se ha trabajado son empresas productoras de software, estas empresas tienen productos que venden a distintos clientes y les interesa mejorar su calidad, son productos que se desarrollaron para un cliente en particular y luego fueron adaptados para otros clientes, con lo cual se cuenta con distintas instalaciones de los mismos, con variantes en cada caso. Estos productos se encuentran en etapa de mantenimiento o de desarrollo de nuevas funcionalidades. Usaremos como caso de estudio en este artículo un proyecto que actualmente se encuentra en curso. Los resultados mostrados fueron levemente maquillados
por razones de confidencialidad, pero sin alterar su esencia. El producto de software es una aplicación de gestión, que hace varios años está en producción, pero ha sufrido varios cambios. Existe un manual de usuario de la aplicación el cual no se actualiza desde hace un par de años, no hay documento de requerimientos ni otro material de apoyo. El cliente cuenta con un sistema donde ingresan las solicitudes de cambio para cada nueva versión. Se aplicaron para este proyecto las etapas de ProTest y sus actividades, como se describe a continuación. La etapa de Estudio Preliminar es muy importante en el caso de testing independiente, ya que para cotizar los proyectos de testing, es necesario conocer las funcionalidades del producto. En este caso la etapa Estudio Preliminar se llevo a cabo durante 3 reuniones con el cliente en las cuales se definieron las prioridades para las pruebas y se explicaron los principales requerimientos del sistema, el equipo de testing a partir de las reuniones realizó una agenda preliminar, en la que se definieron dos ciclos de prueba y las principales funcionalidades a probar en cada ciclo. A partir de esto se realizó la cotización del proyecto de prueba, las actividades necesarias para realizar la cotización, no son parte de ProTest. El cliente dio el visto bueno a la propuesta, momento en el cual se comenzó el proyecto de testing. Durante la etapa de Planificación, la negociación con el cliente y el análisis de los riesgos del producto son las actividades principales, para poder planificar el trabajo de testing, y definir los ciclos de prueba del producto. Para cada ciclo de prueba debe definirse qué funcionalidades se probarán en el ciclo y cuándo comienza y termina el ciclo. La definición de las funcionalidades se hace agendando en los ciclos las funcionalidades según la importancia asignada en el análisis de riesgo del producto, dado que cada ciclo se corresponde con una versión del producto, las fechas de comienzo y fin van a estar dadas por las fechas en que desarrollo genera nuevas versiones. Se definieron 2 ciclos de 1 mes cada uno, como se muestra en la Tabla 7. Las funcionalidades para el proyecto se clasificaron junto con el cliente según Prioridad, Complejidad y Criticidad y se asignaron en cada ciclo como se describe en la Tabla 8. La definición del Plan de Pruebas ha resultado de gran utilidad para que el cliente tenga visibilidad respecto al trabajo del proyecto de testing independiente, así como lograr acuerdos respecto a responsabilidades y compartir un vocabulario común.
Tabla 7: Planificación del Proyecto OBJETIVO Planificación del Proyecto Plan de Pruebas Completo Laboratorio Configurado Ciclo de Prueba 1 Redacción de las funcionalidades del Ciclo 1 Diseño de los casos de prueba del Ciclo 1 Ejecución de las Pruebas Reporte de Incidentes Ciclo de Prueba 2 Redacción de las funcionalidades del Ciclo 2 Diseño de los casos de prueba del Ciclo 2 Ejecución de las Pruebas Reporte de Incidentes Informe final de las pruebas
TIEMPO Semanas 1 y 2 Semanas 1 y 2 Semana 1 Semanas 3, 4 y 5 Semanas 3 y 4 Semanas 3 y 4 Semanas 4 y 5 Semanas 4 y 5 Semanas 6, 7 y 8 Semanas 6 y 7 Semanas 6 y 7 Semanas 7 y 8 Semanas 7 y 8 Semana 9
Una vez planificado el proyecto de prueba, se comienza con el Ciclo 1. Se realizó la instalación y configuración del producto en el ambiente de pruebas. Dado que no se cuenta con la documentación de los requerimientos del producto, se incluyó el relevamiento de requerimientos como parte del proyecto de prueba, lo que el cliente ve como positivo, ya que además de conocer la calidad del producto que desarrolla, obtiene como valor agregado la documentación de las funcionalidades que se van a probar. El poder explorar el producto es de gran utilidad en estos casos, el tener un ejecutable del producto permite entender el sistema y sus requerimientos rápidamente, reduciendo las horas de reuniones para especificar requerimientos. Tabla 8: Funcionalidades por Ciclo de Prueba
A la vez que se relevaron los requerimientos para el ciclo, se diseñaron los casos de prueba. Se definieron 153 casos de prueba para el Ciclo 1, los cuales fueron validados por el cliente. La ejecución de los casos de prueba se hizo al finalizar el ciclo, encontrándose 57 incidentes: 5 son de prioridad Alta, 3
de prioridad Media y 49 de prioridad Baja. En la tabla 9 se detallan los incidentes encontrados por tipo. Tabla 9: Incidentes por tipo Incidentes por Tipo Funcional - Implementación Incorrecta Interfaz de Usuario Mensajes erróneos y Falta de Mensaje. Ortografía y/o Gramática
Incidentes 15 10 30 2
Los incidentes encontrados fueron validados por el cliente, para la comunicación y seguimiento de incidentes se usa la herramienta Bugzilla. Los incidentes son ingresados por el equipo de testing y luego son validados por el cliente, el cliente puede asignar los incidentes a sus desarrolladores y cuando el incidente está corregido, queda en el estado resuelto, de forma de que el equipo de testing realice las pruebas de regresión para el nuevo ciclo de prueba. Actualmente se ha terminado el Ciclo 1, se está esperando la versión correspondiente para comenzar el Ciclo 2.
6
Conclusiones
En este artículo se define ProTest, guía para realizar testing funcional de un producto de software y su aplicación en el Laboratorio de Testing Funcional del Centro de Ensayos de Software. Las principales características de ProTest se listan a continuación: Se basa en el análisis de riesgo del producto para priorizar las funcionalidades a probar, esto requiere involucrar al cliente y desarrolladores en ese análisis y responsabilizarlos de tomar decisiones durante las pruebas, de forma que el testing realmente evalúe el producto según las necesidades del negocio. Los ciclos de prueba son los que guían cada proyecto de testing. La decisión de las pruebas a ejecutar en cada ciclo se realiza a partir del análisis de riesgo del producto y de la relación entre el costo y su beneficio. Se revisan las especificaciones existentes y se trabaja junto con el cliente y los desarrolladores para mejorarlas, si fuese necesario En cada ciclo de prueba se realiza testing exploratorio además del testing planificado para el ciclo. El objetivo es mitigar el riesgo de estar realizando un mal análisis de riesgo del producto, usando una metodología distinta a la de realizar testing basado en los riesgos. Si se encuentran defectos durante el testing exploratorio que no fueron encontrados por las pruebas planificadas y que son críticos para el funcionamiento del producto o para el
cliente, entonces, es momento de revisar el análisis de riesgo realizado y de la relación costo/beneficio. Como trabajo futuro se encuentra seguir con este caso de estudio hasta su finalización, para poder concluir sobre el uso de ProTest en un proyecto de prueba desde su comienzo hasta su conclusión. Resulta interesante comparar los resultados de la aplicación del proceso con clientes que no sean quienes desarrollan el software y también estudiar la aplicación de ProTest con herramientas que ayuden a la gestión del testing.
7
Referencias
[1] Myers G, The Art of Software Testing, John Wiley & Sons, 1979. ISBN: 0471043281 [2] Guide to the Software Engineering Body of Knowledge SWEBOK, 2004 version. Pages: 73-86. IEEE Computer Society. www.swebok.org [3] Centro de Ensayos de Software, www.ces.com.uy [4] Black R., Managing the Testing Process, 2nd Edition. Rex Black. Editorial Wiley, ISBN 0-471-22398-0, 2002 [5] Kit E., Software Testing In The Real World: Improving The Process, Addison Wesley. ISBN 0201877562 [6] Kaner C., Bach J, Pettichord B.Lessons learned in Software Testing. Willey, 2002. ISBN 0-471-08112-4 [7] Suwannasart T., Burnstein I., Carlson C. Developing a Testing Maturity Model: Part I, llinois Institute of Technology. Published in: Crosstalk, August 1996 [8] Ostrand T., Balcer M, The category-partition method for specifying and generating functional tests, Communications of the ACM, Volume 31, Issue 6, Pages: 676 – 686, June 1988. [9] Beizer B, Software Testing Techniques, International Thomson Press, 1990 [10] Bach J, Exploratory Testing Explained, http://www.satisfice.com/articles/et-article.pdf , 2002.