Testing Basado en Requerimientos - RBT - Revision de Ambiguedad

Mogyorodi, Gary. Requirements-Based Testing - Ambiguity Reviews. En: Testing Experience, The Magazine for Professional Testers (en línea) Junio 2008, vol. 2, Berlin, Alemania. p. 28 - 30. (citado 28 de octubre de 2009). Disponible en Internet previa suscripción: http://www.testingexperience.com Este documento provee una visión general del proceso de Testing Basado en Requerimientos (RBT). RBT es un proceso riguroso para mejorar la calidad de los requerimientos y para derivar el mínimo número de casos de prueba para cubrir el 100% de dichos requerimientos. RBT se compone de dos técnicas: la Revisión de ambigüedad y el Gráfico de Causa-Efecto. La revisión de ambigüedad es utilizada en la fase de definición de requerimientos durante el ciclo de vida del desarrollo de un sistema, para identificar ambigüedades en los requerimientos funcionales. El propósito de la revisión de ambigüedad es el de identificar lo que no es claro, lo que es ambigüo o incompleto en los requerimientos. El gráfico de Causa-Efecto es una técnica de diseño de casos de prueba que se realiza una vez que se haya revisado la ambigüedad y el contenido de los requerimientos. Se revisa el contenido de los requerimientos para asegurar que son correctos y completos. La técnica del gráfico de Causa-Efecto deriva el mínimo número de casos de test para cubrir el 100% de la funcionalidad de los requerimientos, a fin de mejorar la calidad de la cobertura del test. Este artículo trata sobre la primer técnica del proceso RBT – La revisión de ambigüedad. Entonces, ¿Qué es esto de los requerimientos? El documento de requerimientos describe cual es el comportamiento esperado del sistema. Es el punto de inicio para todas las fases restantes del desarrollo de software. Los requerimientos deben ser escritos de una manera detallada para que no haya malentendidos sobre lo que se espera que el sistema haga. Llamo a esto un requerimiento testeable. Usualmente, no se dedica demasiado tiempo al documento de los requerimientos, entonces cuando los requerimientos son escritos, hay confusión en cuanto a:        Lo que los grupos de interés (1) esperan que sea entregado.        Lo que se espera que los desarrolladores entreguen.        Lo que se espera que los testers prueben. Por lo tanto, beneficiará a todo el grupo de trabajo si hay un conjunto de requerimientos claro, detallado y testeable con el que puedan trabajar. ¿Por qué nos importa contar con requerimientos testeables? Los requerimientos testeables reducen el tiempo de desarrollo evitando defectos costosos en fases tardías del ciclo de vida del desarrollo de un sistema. El costo relativo de corregir un error El costo de corregir un error de software es más bajo en la fase de los requerimientos, durante el ciclo de vida del desarrollo de un sistema. Esto se debe a que, si se encuentra un error, hay pocos entregables a corregir al inicio de un proyecto. A medida que el proyecto avanza hacia fases posteriores del ciclo de vida, el costo de corregir un error se incrementa dramáticamente, debido a que hay más entregables afectados por la correción de cada error, como el documento de diseño o el código mismo. La siguiente tabla indica el costo relativo de corregir un error en diferentes fases del ciclo de vida del desarrollo de un sistema. La distribución de los defectos Un estudio realizado por James Martin(2) muestra que la causa principal del 56% de todos los errores de software identificados en proyectos son el resultado de errores introducidos en la fase de los requerimientos. De los errores arraigados en los requerimientos, aproximadamente la midad de ellos se deben a requerimientos pobremente escritos, ambigüos, confusos o incorrectos. La otra mitad de dichos errores se deben a requerimientos que han sido completamente omitidos. Entonces, hay mucho margen de mejora para escribir requerimientos claros, concisos, inambigüos y completos. ¿Qué es la revisión de ambigüedad? La revisión de ambigüedad es la prueba de los requerimientos para asegurarnos que están escritos de una manera clara, concisa e inambigüa. La revisión de ambigüedad se lleva a cabo en fases tempranas del desarrollo, por ejemplo, en la fase de los requerimientos. En esta instancia del proyecto, todo el grupo del proyecto utiliza los requerimientos como una descripción de lo que es deseable que el sistema haga. La revisión de ambigüedad se lleva a cabo previo a que sea revisado el contenido de los requerimientos por los expertos de dominio (3). El propósito de la revisión de ambigüedad es proveer a los expertos de dominio un conjunto de requerimientos de mayor calidad con los que trabajar, para que de esta forma puedan identificar mejor los requerimientos faltantes y mejorar el contenido (en completitud y exactitud) de todos los requerimientos. La revisión de ambigüedad esta basada en el checklist de los 15 problemas comunes que tiene la gente al escribir requerimientos. Hagamos la revisión de ambigüedad Usualmente un ejemplo es la mejor manera de ilustrar una técnica. Utilizaremos un documento de requerimientos titulado “La Regulación Postal” para ilustrar el uso de la revisión de ambigüedad. La versión borrador de los requerimientos de la Regulación Postal se provee en el cuadro siguiente: El primer paso en una revisión de ambigüedad es identificar cualquier palabra o frase que sea potencialmente ambigüa. Se han marcado en azul aquellas palabras que son ambiguas, para examinar cada una a continuación. 1- La palabra otro en la frase otro tipo de items postales no define claramente cuales tipos de items postales hay además de los paquetes; entonces debemos identificar cuales son los otros tipos de items postales. 2- La palabra aplicará(4) identifica una ambigüedad llamada Else ambiguo(5). Dicha palabra nos dice lo que normalmente se espera que ocurra, por ejemplo: que los Recargos por País y Peso serán aplicados a paquetes que las personas envíen hacia América del Sur entre el 1ro y 24 de diciembre. Pero los requerimientos no nos dicen nada acerca de lo que ocurrirá para cualquier otro set de condiciones. Por ejemplo, los requerimientos no nos dicen cuales serán los recargos de envío si los paquetes son enviados hacia América del Sur pero NO entre el 1ro y el 24 de Diciembre. Entonces tenemos un else ambiguo. 3- La palabra estos es un pronombre que hace referencia a los recargos que el sistema aplicará. Sería más claro hacer la referencia explícita, tal como los recargos en la Tabla 1, y eliminar la palabra estos. 4- La palabra estándar no define claramente el monto de los gastos de envío aplicados previo a la aplicación de los recargos postales definidos. El autor del requerimiento probablemente entienda lo que significan los gastos de envío estandar. La oración ha sido escrita como si el autor asumiera que el lector conoce lo que significa la frase gastos de envío estándar, lo que podría no ser verdad. El próximo paso de la revisión de ambigüedad es revisar los requerimientos e identificar si hay algo más que sea ambiguo. De la revisión de los requerimientos, se pueden realizar adicionalmente las siguientes preguntas:        ¿Existe tal cosa como envío no-estandar?        ¿Qué recargos en gastos de envío son aplicados a paquetes enviados hacia América del Sur entre el 1ro y 24 de Diciembre que van a Brasil y pesan exactamente 33 libras?        ¿Qué recargos en gastos de envío son aplicados cuando se hacen envíos a otros países de América del Sur, que no sean Argentina o Brasil?        ¿Cuál es la moneda de los recargos en gastos de envío?        ¿Cuál es el recargo en gastos de envío para items postales que no sean paquetes? Luego de obtener las aclaraciones necesarias de los expertos de dominio sobre estas cuestiones, las ambiguedades han sido eliminadas y los requerimientos reescritos de la siguiente forma: En Resumen La meta es derivar un conjunto de requerimientos testeables. Un requerimiento es testeable si es escrito de manera tal que cada sentencia es determinista. Determinista significa que dadas las condiciones de inicio y un conjunto de entradas, el lector puede determinar exactamente cuales serán las salidas. Cada sentencia en los requerimientos luego podrá ser utilizada para probar o desaprobar si el comportamiento del sistema es correcto. Eliminar las ambiguedades es el primer paso para obtener requerimientos testeable. Una vez que los requerimeintos hayan sido revisados y corregida su ambigüedad, podrán ser revisados por los expertos de dominio para asegurarse que son correctos y completos. Luego los requerimientos están corregidos de cualquier error u omisión. Luego, el equipo de desarrollo puede avanzar hacia la fase de diseño en el ciclo de vida del desarrollo de un sistema con un conjunto completo de requerimientos. Al mismo tiempo, el equipo de testing puede iniciar el diseño de los casos de prueba. Por ejemplo, aplicando el Gráfico de Causa – Efecto. ____________________ (1) Stakeholders (2) James Martin (3) Expertos de dominio o expertos en la materia (stakeholders, usuarios, etc.) (4) En el documento original en inglés se hace mención al auxiliar WILL utilizado con el verbo apply (5) En inglés Dangling Else