Testing Basado en Requerimientos - RBT

Mogyorodi, Gary. Requirements-Based Testing - Cause-Effect Graphing. En: Testing Experience, The Magazine for Professional Testers (en línea) Marzo 2009, vol. 5, Berlin, Alemania. p. 40 - 44. (citado 27 abril 2009). Disponible en Internet: http://www.testingexperience.com Testing Basado en requerimientos - Gráfico Causa/Efecto Este artículo provee una revisión del proceso de Testing Basado en Requerimientos (RBT, Requeriments-Based Testing). RBT es una técnica rigurosa para mejorar la calidad de los requerimientos, mientras obtenemos el mínimo número de casos de prueba posibles para cubrir el 100% de esos requerimientos. RBT esta compuesta de dos técnicas: la Revisión de ambigüedades y el Gráfico de Causa-Efecto. La revisión de ambigüedades es utilizada, durante el desarrollo de software, en la fase de especificación de requerimientos para identificar ambigüedades en los requerimientos funcionales. La intención es identificar lo que no es claro, conciso o lo que es ambiguo en los requerimientos. La eliminación de dichas ambigüedades mejora la calidad de esos requerimientos. El gráfico de Causa-Efecto es una técnica de diseño de casos de prueba que es realizada una vez que ha sido revisada la ambigüedad de los requerimientos, seguida de una revisión de su contenido. Es necesario revisar el contenido de los requerimientos para asegurarnos que son correctos y completos. La técnica del gráfico de Causa-Efecto deriva el mínimo número de casos de prueba para cubrir el 100% de la funcionalidad de los requerimientos a fin de mejorar la calidad de cobertura de un test. Este artículo trata la segunda técnica del proceso RBT: el gráfico Causa-Efecto. Diseño de casos de prueba El reto en el diseño de casos de prueba es obtener el conjunto necesario y suficiente de casos de prueba para cubrir el 100% de la funcionalidad de nuestro sistema a testear. Sin el 100% de cobertura funcional, habrá cierta funcionalidad que irá a producción sin ser testeada. Hay muchas técnicas para el diseño de casos de prueba, pero pocas nos aseguran que los casos de prueba proveerán una cobertura del 100% de la funcionalidad. La técnica del gráfico de Causa-Efecto comienza a partir del conjunto de requerimientos, y determina el mínimo número de casos de prueba para cubrir completamente los requerimientos. Revisión de los casos de prueba Una vez que los casos de prueba han sido generados por el test designer (1) , el proceso RBT incluye la revisión de esos casos de prueba por los siguientes stakeholders (podríamos definirlos como cualquier involucrado en la definición y realización de los requerimientos funcionales): ·         El autor de los requerimientos verifica que esta de acuerdo en como fueron trasladados los requerimientos a casos de prueba. ·         Los expertos en el dominio de los requerimientos revisan los casos de prueba a fin de determinar la respuesta a la siguiente pregunta: ¿Estamos construyendo el sistema correcto? ·         Los desarrolladores revisan los casos de prueba para clarificar su entendimiento de los requerimientos. Los desarrolladores aprenderán acerca de lo que se pondrá a prueba, pudiendo así desarrollar un software válido. Realizando estas revisiones, todos los involucrados en el equipo de proyecto podrán obtener el mismo entendimiento de lo que se va a construir. Técnicas tradicionales para el diseño de Casos de Prueba Hay numerosas técnicas de diseño, tal como la Partición por Clases de Equivalencia (Equivalence Class Partitioning) y el Análisis de valores de Frontera (Boundary Value Analysis). Estas técnicas cuentan con que el test designer haga manualmente la correcta combinación de casos de prueba. A menudo, el test designer no usa una técnica formal de diseño de casos de prueba y se basa en su intuición para evaluar si la cobertura que brindan es suficiente. Mientras que estas técnicas generan una combinación de casos de prueba, a menudo no están a la altura de ofrecer plena cobertura funcional. Muy seguido el flujo normal de la funcionalidad se superpone en casos de prueba redundantes, mientras que las excepciones y condiciones de error no son sometidas al test. El gráfico de Causa-Efecto La técnica del gráfico de Causa-Efecto fue inventada por Bill Elmendorf de IBM en 1973. En vez de intentar el test designer manualmente determinar el conjunto correcto de casos de prueba, modela el problema utilizando un gráfico de Causa-Efecto, y el software que soporta la técnica, BenderRBT, calcula el conjunto correcto de casos de prueba para cubrir el 100% de la funcionalidad. La técnica del gráfico de Causa-Efecto utiliza el mismo algoritmo que es utilizado en el testeo de los circuitos lógicos del hardware. Los casos diseñados para las pruebas de hardware aseguran virtualmente un hardware libre de defectos. La técnica del gráfico de Causa-Efecto tiene también la capacidad para detectar defectos que se cancelan unos con otros, y la habilidad para detectar defectos escondidos por otras cosas que marchan bien. Estos son temas avanzados que no se tratarán en el artículo. El punto de inicio del gráfico de Causa-Efecto es el documento de requerimientos. Los requerimientos describen "que" intentamos que el sistema haga. Los requerimientos pueden describir sistemas de tiempo real, eventos, diagramas de transición de estados, sistemas basados en datos, sistemas orientados a objetos, estándares de interfaz gráfica de usuario, etc. Cualquier tipo de lógica puede ser modelada utilizando el diagrama de Causa-Efecto. Cada causa (o entrada) en el requerimiento es expresada en el gráfico de Causa-Efecto como una condición, que puede ser verdadera o falsa. Cada efecto (o salida) es expresada como una condición, que puede ser, también, verdadera o falsa. Un ejemplo simple del gráfico Causa-Efecto Tengo un requerimiento que dice que: "Si A o B, entonces C". Luego, siguiendo las reglas indicadas para este requerimiento:            Si A es verdadero y B es verdadero, entonces C es verdadero.            Si A es verdadero y B es falso, entonces C es verdadero.            Si A es falso y B es verdadero, entonces C es verdadero.            Si A es falso y B es falso, entonces C es falso. El gráfico de Causa-Efecto que representa este requerimiento es el de la siguiente figura. El gráfico de Causa-Efecto muestra la relación entre las causas y los efectos. En la anterior figura, A, B y C son llamados nodos. Los nodos A y B son las causas, mientras que el nodo C es un efecto. Cada nodo puede tener una condición verdadera o falsa. Las líneas, llamadas vectores, conectan los nodos causa A y B con el nodo efecto C. Todos los requerimientos son transformados en nodos y relaciones en el gráfico de Causa-Efecto. Hay cuatro posibles relaciones entre los nodos, y son indicadas siguiendo los siguientes símbolos: 1) Donde A nos lleva a C, una linea recta ----------------------. 2) Donde A o B nos llevan a C, una V en la intersección significa "o". 3) Donde A y B nos llevan a C, una V invertida en la intersección significa "y". 4) Una tilde ~ significa "no" como en "Si no A, entonces C". La tabla de Decisión El gráfico de causa-efecto es convertido luego en una tabla de decisión o de verdad representando las relaciones lógicas entre las causas y los efectos. Cada columna de la tabla de decisión es un caso de prueba. Cada caso de prueba corresponde a una única posible combinación de entradas que están ya sea en un estado positivo, en un estado falso, o en un estado enmascarado (que será descrito más adelante). Dado que hay dos entradas para este ejemplo, hay 2 x 2= 4 combinaciones de entradas que pueden ser seleccionadas para los casos de prueba. De la tabla de decisión, notar que hay sólo tres casos de prueba. Sin embargo, estos tres casos de prueba cubren el 100% de la funcionalidad para este ejemplo. La cuarta combinación de entradas (A = verdadero y B = verdadero) no agregan cobertura funcional adicional, y es un caso de prueba redundante. Cada relación es testeada con la correcta combinación de causas de modo que todos los defectos están cubiertos para esa relación, resultando en una cobertura del 100%. Creemos un gráfico de Causa-Efecto Caso de Estudio: La Regulación Postal en América del sur La siguiente regulación postal determina los recargos de envío. Esta regulación solo aplica a paquetes, no a otro tipo de items postales, y solo a paquetes enviados a América del Sur. Otros items postales son los sobres y tarjetas postales. No hay recargos de envío para sobres y tarjetas postales. Para paquetes que las personas envían a América del Sur entre el 1ro de Diciembre y el 24 de Diciembre de cada año, el sistema aplicará los recargos de acuerdo a la siguiente tabla además de los gastos de envío estándar de u$s5. Para paquetes que la gente envía a América del Sur en fechas no incluidas entre el 1ro de Diciembre al 24 Diciembre de cada año, el sistema aplica los recargos en la tabla 2 además de los gastos de envío estándar de u$s5 (para este ejemplo la tabla 2 ha sido excluida). El test designer traslada los requerimientos al diagrama de causa efecto mostrado en la siguiente figura (2). El nodo I10 representa el estado en que el ítem es enviado a América del Sur Y el ítem postal es un paquete Y el ítem es enviado entre el 1ro de Diciembre y el 24 de Diciembre. Hay un gran número de estados enmascarados en el diagrama Causa-Efecto. Los estados enmascarados definen restricciones en el sistema a testear. Como un ejemplo, la máscara (Argentina, Alto_peso, Bajo_peso, 15_kilos) significa que cuando Argentina es el país, entonces las divisiones de peso asociadas con Brazil son entradas irrelevantes. El gráfico de Causa-Efecto se traduce en la siguiente tabla de decisión (salida del programa BenderRBT): Cada columna en la figura 5 representa un caso de prueba. Las entradas son listadas bajo las "causas", mientras que las salidas bajo los "efectos". Cada valor en la matriz puede ser Verdadero (T / True), Falso (F / False) o "enmascadado" (una entrada enmascarada es irrelevante a ese caso de prueba). Cada columna representa una única combinación de entradas. Los siguientes 8 casos de prueba se obtienen de los requerimientos de Regulación Postal utilizando la técnica del diagrama de Causa-Efecto. TEST #1 -- La Regulación Postal Causa(s): El ítem NO es enviado a América del Sur. Efecto(s): Estas condiciones están fuera del alcance para el problema de la Regulación Fiscal. TEST #2 -- La Regulación Postal Causa(s): El ítem es enviado a América del Sur. El ítem postal NO es un paquete. Efecto(s): Estas condiciones están fuera del alcance para el problema de la Regulación Fiscal. TEST #3 -- La Regulación Postal Causa(s): El ítem es enviado a América del Sur. El ítem postal es un paquete. El ítem NO fue enviado entre el 1ro de Diciembre y el 24 de Diciembre. Efecto(s): Ver tabla 2 (fuera del alcance de este artículo) para recargas postales. TEST #4 -- La Regulación Postal Causa(s): El ítem es enviado a América del Sur. El ítem postal es un paquete. El ítem fue enviado entre el 1ro de Diciembre y el 24 de Diciembre. El país es Argentina. Efecto(s): El recargo postal es de u$s 11. TEST #5 -- La Regulación Postal Causa(s): El ítem es enviado a América del Sur. El ítem postal es un paquete. El ítem fue enviado entre el 1ro de Diciembre y el 24 de Diciembre. El país NO es Argentina El país NO es Brasil. Efecto(s): El recargo postal es de u$s 15. TEST #6 -- La Regulación Postal Causa(s): El ítem es enviado a América del Sur. El ítem postal es un paquete. El ítem fue enviado entre el 1ro de Diciembre y el 24 de Diciembre. El país es Brasil. El ítem pesa más que 15 kilogramos. Efecto(s): El recargo postal es de u$s 21. TEST #7 -- La Regulación Postal Causa(s): El ítem es enviado a América del Sur. El ítem postal es un paquete. El ítem fue enviado entre el 1ro de Diciembre y el 24 de Diciembre. El país es Brasil. El ítem pesa 15 kilogramos. Efecto(s): El recargo postal es de u$s 19. TEST #8 -- La Regulación Postal Causa(s): El ítem es enviado a América del Sur. El ítem postal es un paquete. El ítem fue enviado entre el 1ro de Diciembre y el 24 de Diciembre. El país es Brasil. El ítem pesa menos que 15 kilogramos. Efecto(s): El recargo postal es de u$s 17. En Resumen La figura 5 muestra que hay 8 entradas para el requerimiento de Regulación Postal (por ejemplo, Continente, Tipo_Item_Postal, Fechas, Argentina, Brasil, Alto_Peso, Bajo_Peso). Es interesante notar que con 8 entradas, hay 28 = 256 combinaciones de entradas de las cuales pueden ser seleccionados los casos de prueba. La técnica del gráfico Causa-Efecto derivó sólo 8 casos de prueba que cubren el 100% de la funcionalidad descrita en el requerimiento. Ningún otro caso de prueba es necesario para mejorar la cobertura funcional. Casos de prueba adicionales proveerán una cobertura redundante, ya suministrada por una porción de cada uno de los 8 casos de prueba originales. En Resumen El gráfico de Causa-Efecto, en conjunto con una poderosa herramienta de análisis como lo es BenderRBT , provee un riguroso, coherente y rentable enfoque para obtener casos de prueba. Dado que la técnica determina el mínimo número de casos de prueba, el esfuerzo de testeo se reduce, y el test designer puede estar confiado de que una vez que los casos de prueba se ejecutaron exitosamente, el testing está completo, y ninguna funcionalidad sin testear será puesta en producción. Notas: Un requerimiento funcional, especifica lo que el sistema debería ser capaz de hacer, en términos que son significativos para sus usuarios. (1) Test Case Designer (2) Continent = Continente / Postal Item Type = Tipo de Item Postal / Parcels = Paquete / Surcharge = Recargo / Weight High = Alto peso / Weight Low = Bajo Peso / 33  15 kg / See_table = ver_tabla / Dates =»Pounds  Fechas