Copyright © 2007 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture. Conceptos Básicos del.

Presentación del tema: "Copyright © 2007 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture. Conceptos Básicos del."— Transcripción de la presentación:

1

2 Copyright © 2007 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture. Conceptos Básicos del Testing y Definición de Condiciones de Prueba

3 Copyright © 2007 Accenture All Rights Reserved. Agenda Clase 1 Objetivos Definiciones básicas Importancia del diseño de condiciones de prueba Lineamientos y buenas prácticas para la definición de condiciones de prueba Clase 2 Definición de Condiciones de Prueba – Principales Métodos para su diseño

4 Copyright © 2007 Accenture All Rights Reserved. Objetivos Ayudar a mejorar la forma en que analizamos y diseñamos las condiciones de prueba. Uniformizar la estructura de las condiciones de prueba, siguiendo lineamientos y buenas prácticas identificados por el área de SQA de Accenture. Presentar estrategias de derivación de condiciones de prueba que maximicen la efectividad y eficiencia del proceso de Testing

5 Copyright © 2007 Accenture All Rights Reserved. Conceptos - Testing “El proceso de operar un sistema o componente bajo condiciones específicas, observando; registrando los resultados, y haciendo una evaluación de algunos aspectos del sistema o componente”. Testing es un proceso que ejecuta un programa con la intención de encontrar errores. Testing es el proceso por el cual se compara “lo que es” con “lo que debería ser”

6 Copyright © 2007 Accenture All Rights Reserved. Principios del Testing Examinar un programa para ver si hace lo que se espera que haga es sólo la mitad del test, la otra parte es examinar si el programa no hace algo que no se espera que haga. Un programador debe evitar testear su propio programa. Una organización debe evitar testear sus propios programas. Inspeccionar detenidamente los resultados de cada test Cuanto antes se detecte un error más fácil es corregirlo Testing es una tarea extremamente creativa y un desafío intelectual

7 Copyright © 2007 Accenture All Rights Reserved. Principios del Testing Testing es una disciplina profesional que requiere gente entrenada y competente Para tener éxito se requiere profesionales competentes y entrenados con el apoyo adecuado de la administración superior; no debe ser tratado como trampolín, debe ser independiente, imparcial, y organizado para que se cuente con el reconocimiento justo de su contribución a la calidad del producto Se debe cultivar una aptitud de equipo positiva para la destrucción creativa Se necesita considerable creatividad para destruir algo en una forma controlada y sistemática; una buena prueba debe desarmar un producto metódicamente, encontrar sus debilidades, empujar hacia los límites

8 Principios del Testing El objetivo es identificar problemas en el producto que se está desarrollando antes de que pase a la siguiente etapa Categorías de problemas –errores son los problemas identificados en la etapa en la que se crearon –defectos son los problemas en la etapa siguiente a la etapa en la que se crearon –fallas son los problemas detectados depués de la implementación

9 Copyright © 2007 Accenture All Rights Reserved. Niveles de Testing Test de aceptación del usuario Test de sistema Test de integración Test de unidad o componente

10 Copyright © 2007 Accenture All Rights Reserved. Técnicas de Evaluación Durante el desarrollo de software usamos distintas técnicas de evaluación para detectar posibles problemas. Podemos clasificarlas en: Técnicas Estáticas Técnicas Dinámicas

11 Copyright © 2007 Accenture All Rights Reserved. Evaluación Estática Buscan fallas sobre el sistema en reposo. Se trabaja sobre los diferentes artefactos (representaciones estáticas) del sistema buscando posibles problemas en los mismos. Pueden aplicarse a artefactos de requerimientos, análisis, diseño y código. Entre las principales técnicas podemos mencionar Revisiones, Inspecciones, Walkthroughs y Auditorias de calidad.

12 Copyright © 2007 Accenture All Rights Reserved. Evaluación Dinámica Se pone el sistema a funcionar, buscando diferencia entre las salidas esperadas y las reales. A la aplicación de Técnicas Dinámicas también se la denomina “Testing” o “Prueba”. Desarrollo las realiza sobre el código, que suele ser su único producto ejecutable. Comúnmente se divide en dos tipos: De Caja Negra o Funcionales De Caja Blanca o Estructurales

13 Copyright © 2007 Accenture All Rights Reserved. Evaluación Dinámica Testing de Caja Negra: estrategia en la cual las pruebas se basan solo en los requerimientos y especificaciones. No requiere conocer la estructura interna del sistema/componente bajo prueba. Testing de Caja Blanca: estrategia en la cual las pruebas se basan en los caminos básicos, estructura de control e implementación del SW a probar. En general este tipo de Testing requiere testers con skills de programador.

14 Copyright © 2007 Accenture All Rights Reserved. Condición y Dato de Prueba Una condición de prueba describe situaciones a Testear “Es un conjunto de condiciones de ejecución sobre los valores de entrada, los cuales satisfacen un objetivo particular”. Un dato de prueba es un elemento del dominio de entrada que satisface una o más condiciones de prueba; es un valor concreto. – Dependen del ambiente de prueba con que se esté trabajando. – Se pueden seleccionar a priori o en el momento de la ejecución.

15 Copyright © 2007 Accenture All Rights Reserved. Condiciones de pruebas Una buena condición de prueba es aquella que tiene una probabilidad alta de descubrir errores. Una condición exitosa es aquella que detecta un error no encontrado. Una parte necesaria de una condición de prueba es la definición de la salida esperada o resultado. Se deben documentar tanto los valores de las entradas/salidas inválidos o inesperados cómo así también los válidos.

16 Copyright © 2007 Accenture All Rights Reserved. Es importante definir las condiciones de prueba? La definición de Condiciones de Prueba es fundamental. ¿Por qué?

17 Copyright © 2007 Accenture All Rights Reserved. Importancia de la definición Durante el análisis de Condiciones de Prueba se puede tener una idea genérica de la aplicación. Se detecta de manera temprana problemas de inconsistencia e incompletitud en la documentación del sistema a probar. Se pueden establecer dimensiones, prioridades y tiempos. Evitamos olvidar áreas o funcionalidades a testear. Se pueden organizar y repartir tareas.

18 Copyright © 2007 Accenture All Rights Reserved. Importancia de la definición Probar sin definir previamente las condiciones de prueba, podría ocasionar: – Que queden cosas sin probar. –Que se pruebe varias veces lo mismo –Complicaciones en definir tiempos y prioridades. –No es posible generar datos previamente. –Es difícil determinar cuándo parar y si se llegó a cubrir lo necesario. –Si se recorta el tiempo de testing, no se sabría hasta dónde llegar.

19 Copyright © 2007 Accenture All Rights Reserved. Que información usamos para diseñar Condiciones de Prueba? Casos de uso Requerimientos Diseños Prototipos Charlas con los referentes ( usuario, analista funcional ) La aplicación Casos de test ya existentes Manual de usuario

20 Copyright © 2007 Accenture All Rights Reserved. Condiciones Sucias y Condiciones Limpias Condiciones Limpias o Positivas: el objetivo de este tipo de casos es mostrar que el producto satisface sus requerimientos, o en otras palabras, “que hace lo que tiene que hacer”. Condiciones Sucias o Negativas: el objetivo de este tipo de casos verificar “que el sistema no hace lo que no tiene que hacer”.

21 Copyright © 2007 Accenture All Rights Reserved. Componentes de las Condiciones de prueba Los fundamentales son: –Descripción –Datos y Pasos –Resultado Esperado –Prioridad

22 Copyright © 2007 Accenture All Rights Reserved. Descripción Es la descripción clara y concisa de la situación representada en la condición. En general se representa como acción a realizar y condiciones involucradas.

23 Copyright © 2007 Accenture All Rights Reserved. Datos Se especifica toda la informacion necesaria para la ejecución de la condición y las precondiciones que se deben cumplir (previo a la ejecución). También sirve para ampliar la Descripción: Campos involucrados Perfiles/permisos Variaciones de una misma condición (por ejemplo, “Valor incorrecto de DNI es un valor no numérico, un numérico con más de 8 caracteres, un numérico menor a cero, un numérico con decimales, …).

24 Copyright © 2007 Accenture All Rights Reserved. Pasos Detalla la secuencia de tareas a realizar para ejecutar la condición de prueba, hasta el punto previo a la verificación del resultado esperado.

25 Copyright © 2007 Accenture All Rights Reserved. Resultado Esperado Debe enumerar todas las verificaciones a realizarse luego de la ejecución de las condiciones de prueba. Debe detallar todas las post condiciones a verificarse una vez ejecutada la acción en la Descripción.

26 Copyright © 2007 Accenture All Rights Reserved. Prioridad Es muy importante clasificar correctamente las condiciones de prueba según su prioridad, de manera tal de ordenar la ejecución. En general la prioridad refleja la importancia de la condición de prueba. No confundir prioridad de las Condiciones de prueba con las prioridades de las Funcionalidades.

27 Copyright © 2007 Accenture All Rights Reserved. Prioridad Muchas veces por cuestiones de tiempo el testing se ve “recortado”. En ese momento tiene gran importancia la priorización de las condiciones de prueba. Además, es fundamental para poder dar feedback rápido a desarrollo y demás interesados.

28 Copyright © 2007 Accenture All Rights Reserved. Prioridad ALTA Llevan a recorrer la aplicación a lo ancho, probando cada funcionalidad en su condición más básica y normal. Su principal objetivo es detectar tempranamente la existencia de funcionalidades no implementadas o que no funcionan ni siquiera en una situación sencilla y frecuentemente usada. Suelen generar incidentes invalidantes para poder seguir con la prueba o para la puesta en producción. En general no se suelen incluir en esta categoría condiciones negativas o de seguridad.

29 Copyright © 2007 Accenture All Rights Reserved. Prioridad MEDIA Permiten probar con mayor profundidad las funcionalidades más críticas del sistema. Se plantean distintas variaciones y situaciones incluyendo las principales pruebas de seguridad. Las situaciones planteadas presentan probabilidad de ocurrencia alta o media. Se incluyen en esta categoría todos los casos cuya ejecución no puede ser pospuesta hasta la puesta en producción. En general la falla de estos casos generarían incidentes que impedirían el pasaje a producción del sistema o de alguna de sus funcionalidades.

30 Copyright © 2007 Accenture All Rights Reserved. Prioridad BAJA Casos cuya probabilidad de ocurrencia es baja y cuyo impacto en caso de falla no es invalidante para la aceptación de una funcionalidad o su pasaje a producción. Estos casos son importantes pero se pueden posponer o suspender su ejecución en caso de tener que recortar el alcance de las pruebas. La clasificación de estos casos también dependerá mucho del usuario final del sistema y de las opciones de contingencia en caso de fallar determinadas funcionalidades o situaciones particulares.

31 Copyright © 2007 Accenture All Rights Reserved. Definir es más difícil cuando... No se tiene la aplicación Se tiene sólo la aplicación La documentación es incompleta La documentación es obsoleta Se tiene poco tiempo esto requiere mucha interacción con analistas funcionales / desarrolladores / líderes

32 Copyright © 2007 Accenture All Rights Reserved. Lineamientos - Descripción Estructurar la descripción de manera tal que quede claro el objetivo de la condición y la pantalla/funcionalidad a testear. La longitud excesiva en la descripción atenta contra la claridad, hace perder el foco de la prueba.

33 Copyright © 2007 Accenture All Rights Reserved. Lineamientos – Descripción Ejemplo INCORRECTO: Ingresar Caja de Ahorro como Cuenta Origen, monto a transferir menor al saldo de la cuenta y realizar la transferencia a cuenta con la misma moneda que la Cuenta Origen. CORRECTO: Transferencia. Cuenta Origen = Caja de Ahorro. Monto < Saldo. Moneda Cuenta Origen = Moneda Cuenta Destino

34 Copyright © 2007 Accenture All Rights Reserved. El orden de las acciones y condiciones debe permitir la rápida verificación del cubrimiento. Ejemplo INCORRECTO: Saldo < Monto. Cuenta Origen = Caja de Ahorro. Transferencia. CORRECTO: Transferencia. Cuenta Origen = Caja de Ahorro. Saldo < Monto. Lineamientos - Descripción

35 Copyright © 2007 Accenture All Rights Reserved. Lineamientos - Descripción Se deben incluir en la descripción todas las condiciones de prueba necesarias para describir la situación a testear. No son admisibles 2 condiciones de prueba con exactamente la misma descripción.

36 Copyright © 2007 Accenture All Rights Reserved. Lineamientos Descripción Ejemplo INCORRECTO: “Transferencia. Saldo < Monto” (no aclaro nada sobre la Cuenta Origen, a pesar que cambia el RE si en lugar de una CA fuera una CC con descubierto habilitado). CORRECTO: “Transferencia. Cuenta Origen = Caja de Ahorro. Saldo < Monto”.

37 Copyright © 2007 Accenture All Rights Reserved. Lineamientos - Descripción Siempre que se incluya una condición negativa que determine por sí sola el resultado esperado, debe ser parte de las primeras condiciones descriptas, y no es necesario aclarar el resto de las condiciones en la descripción (pero sí en los Datos de la condición de prueba). Si la Descripción hace referencia a conceptos como ser “valor inválido”, “valor incorrecto”, etc., en la sección de Datos deben describirse las condiciones involucradas en dichos conceptos.

38 Copyright © 2007 Accenture All Rights Reserved. Lineamientos - Descripción No se deben incluir en la Descripción detalles sobre el Resultado Esperado. Ejemplo INCORRECTO Descripción: “Modificación de permisos. Verificar que no se puede editar el registro si el usuario no tiene los permisos necesarios.” Resultado Esperado: “Da error al intentar modificar.” CORRECTO Descripción: “Modificación de permisos. Usuario sin permisos edita registro”. Resultado Esperado: “Se muestra un mensaje explicando al usuario que no cuenta con los permisos para realizar la acción, se cierra el form de modificación de permisos y no se registran los cambios en la tabla Permisos.”

39 Copyright © 2007 Accenture All Rights Reserved. Lineamientos - Descripción No se deben incluir en la Descripción cuestiones NO relacionadas con las condiciones y acciones necesarias para ejecutar el caso. Ejemplo: INCORRECTO Descripción: “Reporte de Gastos por Proyecto. Agregar nueva columna de Gastos Generales”. CORRECTO: Lo correcto sería que las verificaciones a realizar sobre la nueva columna formen parte de los Resultados Esperados de algunos casos.

40 Copyright © 2007 Accenture All Rights Reserved. Lineamientos – Datos Tratar de incluir la mayor cantidad de información posible para que el tester que ejecuta entienda lo que hay que probar. Solamente información útil Muchas veces el campo Datos amplia la información provista en la Descripción: Campos involucrados Permisos de usuarios Variaciones de un mismo caso (“Se considera Fecha incorrecta a…”)

41 Copyright © 2007 Accenture All Rights Reserved. Lineamientos - Ejercicio Ejercicio –Transferencia entre cuentas: Cuenta Origen = Caja de Ahorro Saldo > Monto La forma de realizar la transferencia entre las dos cuentas difiere dependiendo de la moneda de la cuenta origen y la destino, y si existe conversión definida entre monedas.

42 Copyright © 2007 Accenture All Rights Reserved. Lineamientos – Ejercicio INCORRECTO Descripción: Transferencia. Cuenta origen= Caja de Ahorro. Saldo > Monto. Resultado Esperado: Se realiza la transferencia. Se está sub-especificando, agrupando varios casos en uno. Descripción: Transferencia. Cuenta origen= Caja de Ahorro. Saldo > Monto. Resultado Esperado: Se realiza la transferencia y si la moneda difiere se hace la conversión. Idem anterior.

43 Copyright © 2007 Accenture All Rights Reserved. Lineamientos – Ejercicio CORRECTO CASO 1: Transferencia. Cuenta origen= Caja de Ahorro. Saldo >Monto. Moneda cuenta destino = moneda cuenta origen. Resultado Esperado: Se realiza la transferencia

44 Copyright © 2007 Accenture All Rights Reserved. Lineamientos – Ejercicio CORRECTO CASO 2: Transferencia. Cuenta origen=Caja de Ahorro. Saldo > Monto. Moneda cuenta destino <> moneda cuenta origen. Existe conversión entre ambas monedas. Resultado Esperado: Se realiza la transferencia

45 Copyright © 2007 Accenture All Rights Reserved. Lineamientos – Ejercicio CORRECTO CASO 3: Transferencia. Cuenta origen=Caja de Ahorro. Saldo > Monto. Moneda cuenta destino <> moneda cuenta origen. No existe conversión entre ambas monedas. Resultado Esperado: No se realiza la transferencia

46 Copyright © 2007 Accenture All Rights Reserved. Terminamos por HOY MUCHAS GRACIAS

47 Copyright © 2007 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture. Definición de Condiciones de Prueba Métodos

48 Copyright © 2007 Accenture All Rights Reserved. Agenda Introducción Objetivos Testing de Caja Negra - Principales Técnicas –Testing positivo y negativo –Clases de equivalencias –Análisis de Condiciones de Borde –Test de robustez –Tablas de Desición Técnicas Complementarias: –Definición jerárquica –Random Testing –Análisis de Historial de Defectos –Exception Testing

49 Copyright © 2007 Accenture All Rights Reserved. Introducción Cuales son los retos actuales que encontramos en los Proyectos de Testing normalmente? El tiempo no alcanza para testear apropiadamente Demasiadas combinaciones de input para probar Dificultades para determinar el Resultado Esperado de cada test Requerimiento inexistentes, pobremente documentados o cambiantes Falta de entrenamiento en técnicas de testing Management que no entiende o no le interesa la Calidad, y por lo tanto el proceso de Testing

50 Copyright © 2007 Accenture All Rights Reserved. Introducción Cual es el problema principal del Testing de Caja Negra? –El tester nunca está seguro cuanto del SW ha testeado. –No importa cuan inteligente y diligente sea el tester, algunos caminos pueden quedar sin cubrir. Por ejemplo, cual es la probabilidad que un tester diseñe un caso de prueba que ejecute esta sentencia, si no está en las especificaciones? If ((snombre == “Cynthia”) && (idiaNacimiento==”06”)) {EnviarCheque(150000);}

51 Copyright © 2007 Accenture All Rights Reserved. Objetivos En esta presentación no veremos técnicas mágicas para solucionar los problemas enumerados, pero sí técnicas que ayuden a diseñar condiciones de prueba más efectivas, que intenten maximizar la cantidad de defectos encontrados, con menor cantidad de recursos.

52 Copyright © 2007 Accenture All Rights Reserved. Tipos de Testing Técnicas Funcionales *-* Técnicas de Caja Negra –El programa o sistema es tratado como una caja negra. Los programas son tratados como una función que mapea valores del dominio de entrada con valores del dominio de salida. Se basan en la especificación del programa, es totalmente independiente de la implementación realizada y de hecho pueden ser definidos antes de la implementación. El testing funcional es realizado desde el punto de vista del usuario. Técnicas Estructurales *-* Técnicas de Caja Blanca Basan su definición de casos en la estructura interna del programa, en la implementación. Su foco está en el estilo de programación, el flujo de control y de datos, el lenguaje de programación, el diseño de la base de datos y otros detalles de codificación.

53 Copyright © 2007 Accenture All Rights Reserved. Cual elegir? Ambas técnicas son útiles y ninguna puede ser reemplazada por la otra. Suelen detectar distintos problemas y lo más usual es complementar la definición de tests realizadas por una técnica con la otra. Testing de Caja Gris –combinación de testing de caja blanca y caja negra para tomar las ventajas de ambos –el tester estudia los requerimientos especificados y se comunica con el desarrollador para entender la estructura interna del programa Ejemplo: si sé que una misma función es llamada desde varios lados, puedo eliminar casos redundantes.

54 Copyright © 2007 Accenture All Rights Reserved. TESTING POSITIVO Y NEGATIVO

55 Copyright © 2007 Accenture All Rights Reserved. Testing Positivo y Negativo Técnica muy básica Se basa en los valores de entrada del programa –Un test positivo es aquel con input válido. –Un test negativo es aquel con input inválido. La técnica consiste en testear valores positivos y negativos para los valores de entrada del programa. Requiere se realice un apropiado balance entre pruebas “positivas” y “negativas”. Dado que en general hay más tests negativos que positivos, un balance sugerido es 80% negativos y 20% positivos.

56 Copyright © 2007 Accenture All Rights Reserved. Testing Positivo y Negativo Ejemplo El input debe ser un entero incluido en el rango entre 0 y 100” –Positivos: cualquier entero entre 0 y 100. –Negativos: entero < 0 entero > 100 no numérico real con decimales

57 Copyright © 2007 Accenture All Rights Reserved. Clases de Equivalencia

58 Copyright © 2007 Accenture All Rights Reserved. Clases de equivalencia Técnica que se usa para reducir el número de condiciones de prueba a una cantidad “manejable”, manteniendo un grado de cobertura razonablemente bueno. Es un proceso sistemático que identifica un conjunto de clases de pruebas representativas de grandes conjuntos de otras pruebas posibles; la idea es que el sistema bajo prueba se comportara de la misma manera para todos los miembros de la clase El proceso incluye dos pasos Identificar las clases de equivalencia Identificar las condiciones de prueba

59 Copyright © 2007 Accenture All Rights Reserved. Clases de equivalencia Como hacerlo? Se particiona el dominio de entrada en un conjunto de clases de entrada (o inputs) que tienen comportamientos similares. Luego se selecciona un valor representativo de cada partición para ser testeado, y se define el caso. Se asume que los resultados predicen el resultado de los otros valores en la partición, por lo cual es indistinto el valor elegido.

60 Copyright © 2007 Accenture All Rights Reserved. Paso 1: Identificar las clases Se toma cada condición de entrada y se la divide en dos o más grupos. Clase válida: son aquellos inputs válidos para el programa Clase inválida: todos los otros posibles estados de la condición Condiciones de entradaClases validasClases invalidas

61 Copyright © 2007 Accenture All Rights Reserved. Clases de equivalencia - Heurística según las condiciones de entrada Rango de valores o cantidad de valores 1 clase válida y 2 inválidas –Por ejemplo para: 0 <=p<= 100 se definen las siguientes clases: 0 <= p <= 100 (válida) p < 0 (inválida) p > 100 (inválida) Conjunto de valores 1 clase por cada valor válido + 1 inválida Por ejemplo, listas de valores. Valor pertenece a la lista de valores (válido) Valor NO pertenece a la lista de valores (inválido) Valor mandatorio 1 clase válida + 1 inválida Por ejemplo, “se debe ingresar una descripción” Se ingresa descripción No se ingresa descripción

62 Copyright © 2007 Accenture All Rights Reserved. Paso 2: Seleccionar datos y definir condiciones 1. Asignar un número único a cada clase de equivalencia 2. Escribir un nuevo caso de test que cubra la mayor cantidad de clases de equivalencia válidas hasta cubrir todas las clases de equivalencias válidas 3. Escribir un nuevo caso de test que cubra una y sólo una de las clases de equivalencia inválidas hasta cubrir todas las clases de equivalencias inválidas

63 Copyright © 2007 Accenture All Rights Reserved. Ejemplo Tenemos una empresa que otorga préstamos hipotecarios para personas cuyos sueldos oscilan entre los 1.000 y los 83.333 pesos por mes (punto separador de miles; coma separador de decimales); si gana menos de 1.000 pesos no califica; si gana más de 83.333 pesos mensuales, no necesita el préstamo). Además, la empresa solo otorga préstamos a personas; no así a corporaciones, sociedades u cualquier otra entidad legal. Por otra parte, solo se otorgan préstamos para adquirir condominios, casas de campo o casas de familia. No se realizarán préstamos para la adquisición de dúplex, casas rodantes, o cualquier otro tipo de propiedad. Por último, podrán adquirirse con un solo préstamo entre 1 y 5 casas (inclusive).

64 Copyright © 2007 Accenture All Rights Reserved. Ejemplo

65 Copyright © 2007 Accenture All Rights Reserved. Aplicaciones y limitaciones Se adecua mejor en sistemas donde los inputs provienen de rangos o conjuntos de valores. Otra forma es analizar los outputs para determinar las clases. Tener en cuenta de no olvidarse de probar clases de input. La técnica asume que los datos de una clase son procesados por el sistema de la misma manera. La mejor manera de saber esto es preguntar al programador. Si se tiene el tiempo y/o recursos pueden agregarse casos variando las condiciones de entrada de las clases.

66 Copyright © 2007 Accenture All Rights Reserved. Análisis de Condiciones de Borde

67 Copyright © 2007 Accenture All Rights Reserved. Pone el foco en los bordes de los valores de entrada y salida de las clases de equivalencias. Los errores tienden a estar en los bordes. Focalizando el testing en estas áreas se incrementa la probabilidad de detectarlos. Esta técnica es una variación de la técnica de partición de equivalencias que se focaliza en los bordes de cada clase de equivalencia: “por arriba y por debajo” de cada clase. En vez de seleccionar un valor de test arbitrario dentro de una clase de equivalencia, el análisis de valores de bordes selecciona uno o más casos para testear cada margen. Análisis de condiciones de borde

68 Copyright © 2007 Accenture All Rights Reserved. Análisis de condiciones de borde - Técnica El foco está sobre el espacio de inputs (clases de equivalencias de entrada) y sobre el espacio de outputs (clases de equivalencia de salida). Es más difícil definir las clases de equivalencias de outputs, ya que no es fácil encontrar los valores de entrada que hacen que el resultado coincida con los bordes de los valores de output. Puede requerir la creación de una gran cantidad de casos de tests debido a la gran cantidad de variaciones de entradas y salidas que pueden existir. Una limitación es que puede ser muy difícil definir el rango de la clase de equivalencia si involucra cálculos muy complejos. Es por eso que los requerimientos deben estar lo más detallados que se pueda

69 Copyright © 2007 Accenture All Rights Reserved. Análisis de condiciones de borde – Heurística según condiciones de input/output Rango de valores o cantidad de valores escribir un caso para el máximo, otro para el mínimo, valor siguiente al máximo, valor anterior al mínimo Ejemplo. “La cuenta puede tener a lo sumo 2 titulares”. Casos : cuenta con 0 titulares cuenta con 1 titular cuenta con 2 titulares cuenta con 3 titulares Conjunto ordenado escribir un caso para el 1ro y para el último –Ejemplo: tablas o arreglo read/update/insert/delete el primer registro read/update/insert/delete el último registro

70 Copyright © 2007 Accenture All Rights Reserved. Ejemplo Para el ejemplo de la empresa de préstamos, para Sueldo y Cantidad de Propiedades podemos crear las siguientes condiciones de prueba: Sueldo=1.000, # Propiedades=1 (válido) Sueldo=83.333, # Propiedades=1 (válido) Sueldo=1.000, # Propiedades=5 (válido) Sueldo=83.333, # Propiedades=5 (válido) Sueldo=1.000, # Propiedades=0 (inválido) Sueldo=1.000, # Propiedades=6 (inválido) Sueldo=83.333, # Propiedades=0 (inválido) Sueldo=83.333, # Propiedades=6 (inválido) Sueldo=999, # Propiedades=1 (inválido) Sueldo=83.334, # Propiedades=1 (inválido) Sueldo=999, # Propiedades=5 (inválido) Sueldo=83.334, # Propiedades=5 (inválido)

71 Copyright © 2007 Accenture All Rights Reserved. Test de robustez Es una técnica complementaria. Consiste en ingresar valores inválidos para el tipo de campo. Por ejemplo, un valor mucho mayor al máximo permitido. Sirve especialmente para detectar problemas de tipo de datos no manejados. Ejemplo: Ingresar 999999999999999999999999999999999999999999999999999 99999999999 999999999999999999999999999999999999999999999999999 999 en un campo char.

72 Copyright © 2007 Accenture All Rights Reserved. Tabla de decisión

73 Copyright © 2007 Accenture All Rights Reserved. Se usan para documentar reglas del negocio que el sistema debe implementar. Sirven como guía para diseñar condiciones de prueba. Las condiciones representan inputs. Las acciones son los procesos que deben ejecutarse dependiendo de la combinación de condiciones presentes. Cada regla define una combinación única de condiciones que dispara las acciones asociadas con dicha regla. Tabla de Decisión

74 Copyright © 2007 Accenture All Rights Reserved. Tabla de decisión -Técnica Regla 1Regla 2….Regla n Condiciones Condición 1 Condición 2 …. Acciones Acción 1 Acción 2

75 Copyright © 2007 Accenture All Rights Reserved. Tabla de decisión -Técnica Crear la menos un caso para cada regla Si las condiciones son binarias se escribe una caso por cada regla o columna (las condiciones son las entradas y las acciones las salidas) Si las condiciones son rangos de valores, crear caso para los bordes del rango (complemento con Análisis de Bordes)

76 Copyright © 2007 Accenture All Rights Reserved. Ejemplo Una empresa de automóviles brinda descuentos a aquellos conductores que están casados y/o son buenos estudiantes el descuento es variable Regla 1Regla 2Regla 3Regla 4 Condiciones Casado?SI NO Buen estudiante?SINOSINO Acción Descuento ($)60%25%50%0%

77 Copyright © 2007 Accenture All Rights Reserved. Definición Jerárquica

78 Copyright © 2007 Accenture All Rights Reserved. Definición Jerárquica Cada tests es dividido en subtests con diferentes condiciones Se arma un árbol jerárquico, donde cada nodo indica una condición. Los tests que son especificados y ejecutados, son las hojas del árbol Permite minimizar las cantidad de tests sin sentido Permite organizar la derivación sin olvidarse de ninguna combinación importante La llamada técnica ”caso-alternativa-variación” se basa en la definición jerárquica con una jerarquía de 3 niveles

79 Copyright © 2007 Accenture All Rights Reserved. Ejemplo

80 Copyright © 2007 Accenture All Rights Reserved. Otras Técnicas

81 Copyright © 2007 Accenture All Rights Reserved. Random Testing Los valores de input son seleccionados al azar. No es óptica porque tiene bajas de detectar errores, pero muchas veces cubre defectos que las técnicas estándar de testing pueden no tener en cuenta. Por lo tanto, debe ser considerada como una técnica completaria

82 Copyright © 2007 Accenture All Rights Reserved. Consiste en la en la situación sobre dónde y cómo los errores tienen alta probabilidad de ocurrir Algunos testers usan su intuición y experiencia para “oler” defectos No existe una metodología particular para aplicar esta técnica pero la idea básica es enumerar una lista de posibles errores potenciales o situaciones y escribir casos basados en la lista Es una técnica complementaria especialmente útil en sistemas: Hechos “a las apuradas” Modificados por varias personas Con estructuras anidadas, condiciones compuestas Complejos acceso a archivos Programa “collage” formado de partes de otros programas Conjetura de Errores

83 Copyright © 2007 Accenture All Rights Reserved. Se genera una condición de prueba (o se reejecuta) por cada defecto encontrado en testeos anteriores al sistema. Esta técnica puede ser usada en test de regresión Se necesita tener la historia de defectos encontrados Conviene priorizar los defectos por criticidad y probabilidad de ocurrencia Historia de defectos

84 Copyright © 2007 Accenture All Rights Reserved. Se identifican todos los mensajes de error y los manejos de excepciones, incluyendo las condiciones que los disparan. Se escribe una condición de prueba de tests para cada error. Ejemplo: Mensajes de error: “Por favor seleccione un registro” “No tiene permiso para eliminar el registro” “Registro duplicado” Casos: Baja. Presionar el botón eliminar sin haber seleccionado un registro Baja. Eliminar un registro con un usuario sin permiso de eliminación Alta. Dar de alta un registro cuya clave primaria ya existe en la base Exceptión Testing

85 Para tener en cuenta Planificar desde el comienzo Definir condiciones y ciclos durante las etapas de especificación Probar los temas más importantes primero Minimizar los gaps y las superposiciones Documentar la prueba Automatizar lo que se pueda

86 Copyright © 2007 Accenture All Rights Reserved. Que debe lograr QA? –Asegurar un servicio de alta calidad tanto para los clientes internos (Desarrollo) como los externos (TODO1) –Estandarizar la metodología de trabajo, el uso de las distintas herramientas (Planillas de Estimación, de Condiciones de Prueba, Templates varios) –Simplificar los procesos de Prueba (reusabilidad - automatizar?) –Transmitir conocimiento – Crecimiento profesional-personal –Incrementar la productividad del equipo

87 Copyright © 2007 Accenture All Rights Reserved. Fuente de Conocimiento Bibliografía Software testing techniques, Boris Beizer- 1983 Software testing in the real world, improving the process, Edward Kit- 1995 Otras Fuentes: Accenture: Testing Course Pragma: Taller de casos de test Internet: Multiples web sites Colaboraron con material e información: Gonzalo Serralta Emmanuel Lopez Llabot

88 Copyright © 2007 Accenture All Rights Reserved. El FINAL GRACIASTOTALES

89 Bonus Track Características Generales de la Prueba Principales actividades: –definir la estructura de los ciclos a ejecutar –identificar quiénes van a participar –armar el plan de trabajo que se va seguir –identificar el entorno de trabajo donde se va a desarrollar

90 Copyright © 2007 Accenture All Rights Reserved. Desarrollo de una prueba 1.Definir condiciones 1.Armar ciclos 1.Preparar datos 1.Establecer resultados esperados 1.Verificar resultados obtenidos

91 Ciclos de Prueba Un ciclo es una agrupación de condiciones de prueba relacionadas lógicamente Los ciclos nos proveen un mecanismo para segmentar la prueba en módulos claramente definidos y ejecutables Consideraciones: –Balancear la independencia vs. la secuencia de ejecución de los ciclos –Probar siempre las funciones más simples primero y las más complejas después

92 Condiciones de Prueba Las condiciones de prueba son una lista de items derivados de la especificación que debe ser probada Cada condición describe un aspecto particular de la especificación Debe asegurarse que las áreas de riesgo de negocio y/o técnicas sean completamente probadas No olvidar definir condiciones de prueba de excepción y/o error

93 Prueba de Regresión  Prueba de Regresión El objetivo de la prueba de regresión es asegurar que los errores detectados fueron corregidos e implementados correctamente Se recomienda para áreas de alto riesgo Posibles estructuras: –Prueba de Modificaciones: Sólo prueba los ciclos afectados por algún problema –Prueba de Regresión: Prueba completa desde el primer ciclo cada vez que se corrige un problema

94 Preparar la Prueba El objetivo de esta actividad es armar los datos de entrada que se utilizaran para la ejecución de la prueba Principales actividades: –Armar los datos de prueba a partir de la condiciones identificadas –Desarrollar los scripts a utilizar durante la ejecución –Establecer los resultados esperados en función de los datos de prueba generados

95 Datos de Prueba Los datos de prueba son registros de entrada utilizados para probar las especificaciones Consideraciones –Armado Manual de datos: Control total vs. Tiempo y dificultad –Utilización de datos de Producción: Confidencialidad de la información. Cantidad vs. Calidad. –Armado de datos por el Sistema: Exactitud vs. Imposibilidad

96 Resultados Esperados Los resultados esperados representan lo que se espera que la ejecución de la prueba genere El input para la definición de los resultados esperados son los datos de prueba El nivel de detalle varía en función de la complejidad y criticidad de la prueba La documentación de las condiciones, datos y resultados esperados conforma la base para la ejecución, revisión y aprobación de la prueba

97 Corregir Problemas Ejecutar la Prueba El objetivo de esta etapa es llevar adelante la prueba planificada Registrar Diferencias Prueba de Regresión Ejecutar Ciclos de Prueba Criterio de Entrada Migrar de Entorno Criterio de Salida Verificar Resultado

98 Copyright © 2007 Accenture All Rights Reserved. Documentación de la Prueba Objetivos: –Asegurar un producto de alta calidad –Simplificar el proceso de Prueba (reusabilidad) –Incrementar la productividad del equipo