Mtp-istqb-28032018_v2.0-mtp.pdf

Principios de las Pruebas de Software Formación para el “Certified Tester – Foundation Level”, Versión 2.0

2

Capítulo 0 – Introducción • 0/01 Contenidos de la presentación. • 0/02 Contenido. • 0/03 Programa. • 0/04 Documentación. • 0/05 Evaluación. • 0/06 Niveles de Conocimiento.

3

0 – General 01 – Contenidos de la Presentación Seminario “Principios de las pruebas de Software” • Proporciona al participante conocimientos básicos en el campo de las Pruebas de Software. • Constituye la base de evaluación para el “Probador Certificado – Nivel Básico”.

Los objetivos de la formación para el Probador Certificado son, entre otros: • Proporcionar conocimientos acerca de las pruebas de software sobre una base fundamentada (marco estándar) • Poder concebir las pruebas de software específicamente para un proyecto • Poder elegir de forma adecuada las técnicas para las pruebas y sus objetivos • Poder escoger y utilizar de manera adecuada las herramientas de apoyo para las pruebas.

4

0 – General 02 – Contenido El seminario está dividido en siete capítulos de acuerdo con el plan de formación del ISTQB: • • • • • • •

Capítulo I Capítulo II Capítulo III Capítulo IV Capítulo V Capítulo VI Capítulo VII

Introducción. Principios de las pruebas de software. Pruebas durante el ciclo de vida del software. Técnicas estáticas. Técnicas de prueba (dinámicas). Gestión de las pruebas. Herramientas de Pruebas.

5

0 – General 03 – Programa El seminario de tres días con posible evaluación final por parte del ISTQB incluye : • Preparación teórica del material de estudio y una serie de ejemplos para determinados comportamientos técnicos. • Aclaración de dudas. • Ejercicios en profundidad acerca del material de estudio. • Discusión sobre los temas aprendidos.

6

0 – General 04 – Documentación • El material de apoyo se compone de: • Un manual completo. • Un conjunto de preguntas de tipo test para preparar el examen. • Listas de bibliografía, estándares, etc. • Referencias: • Certified Tester Foundation Level Syllabus Maintenance Release (Marzo de 2010) • ISTQB Glossary of terms used in Software Testing Version 2.1

7

0 – General 05 – Evaluación El manual se basa en los contenidos del Certified Tester Foundation Level Syllabus Maintenance Release (Marzo de 2010): • Tras la finalización del seminario se podrá llevar a cabo la evaluación para el Nivel básico para el probador certificado (que no caduca). • La aceptación se llevará a cabo por un examinador independiente. • El examen que estará dividido en diferentes áreas, de acuerdo a los capítulos de este seminario, se compone de preguntas de elección múltiple. El examen será en español con una duración de 60 minutos. Es necesario obtener un 65% (26 de 40)

8

0 – General 06 – Niveles de Conocimiento En cada sección del Syllabus se indican los objetivos de aprendizaje correspondientes, y se clasifican según lo siguiente (consultar el Apéndice B del Syllabus): • K1: recordar, reconocer, memorizar. • K2: entender, explicar, razonar, comparar, clasificar, categorizar, poner ejemplos, resumir. • K3: aplicar, usar (ejercicios prácticos). • K4: saber analizar y proponer acciones apropiadas para solucionar un problema o abordar una tarea. NOTA: cada tema se examinará según sus objetivos de aprendizaje (K).

9

10

Capítulo I – Introducción • I/01 Destinatarios. • I/02 ISTQB / Organizaciones Internacionales. • I/03 Probador certificado.

11

I – Introducción 01 – Destinatarios

Queremos dirigirnos a probadores de software en empresas de software y empresas industriales que quieran asentar sus conocimientos sobre unas bases fundamentadas.

¡El aprendizaje durante toda la vida es imprescindible, especialmente en el sector de las TI!

12

I – Introducción 02 – ISTQB / Organizaciones Internacionales Programa de cualificación del ISTQB • En 1998 se definió en Gran Bretaña un programa de cualificación multi-etapa. •

En el Nivel Básico se presentan las bases de las Pruebas de Software.

•

Desde el año 2004 se ofrece, asimismo, la posibilidad de certificarse en el Nivel Avanzado (Gestor de Pruebas, Probador Técnico, Probador Funcional).

• Existen comités de pruebas específicos para cada país que forman conjuntamente el ISTQB - International Software Testing Qualification Board. En España existe el Spanish Software Testing Qualification Board. • Los comités de pruebas específicos de cada país son responsables de la acreditación de los proveedores de formación y de la realización de exámenes en los respectivos países.

www.istqb.org 13

I – Introducción 03 – Probador certificado Programa de cualificación del iSTQB • Como instancia independiente, el comité verifica los cursos ofrecidos en base a los criterios definidos y otorga la acreditación al proveedor de formación. • A pesar de que la comprobación y las pruebas de software tienen en la práctica una gran importancia debido a la irrupción de las tecnologías de la información en prácticamente todos los ámbitos de la vida, existen pocos cursos de aprendizaje y seminarios que se ocupen de manera intensiva de esta problemática. • Esto ha llevado al ISTQB a reavivar las ya mencionadas medidas de cualificación en diferentes etapas.

14

15

Capítulo II – Fundamentos de las pruebas de Software • II/01 Conceptos y definiciones. • II/02 ¿Por qué es necesario probar?. • II/03 ¿Qué son las pruebas (Testing)? • II/04 Problemática de la comprobación y las pruebas. • II/05 Siete Principios de las Pruebas. • II/06 Proceso de pruebas fundamental. • II/07 Psicología de las pruebas. • II/08 Código de buenas prácticas. • II/09 Resumen.

16

II - Fundamentos de las pruebas de software 01 – Conceptos y definiciones Fallos, defectos, errores… • Error: Desviación entre el comportamiento real y el comportamiento esperado, no cumplimiento de un requisito establecido. • Defecto (defect, fault): Anomalía en un componente o sistema que puede dar lugar a que no se lleve a cabo correctamente una función determinada. El término “bug” se aplica históricamente a los defectos en informática. • Fallo (failure). Efecto del error Manifestación de un defecto. • Equivocación (mistake): Acción humana que da lugar a un resultado incorrecto. El software es elaborado por seres humanos que pueden cometer errores que dan lugar a defectos. Estos defectos pueden generar un fallo. 17

II - Fundamentos de las pruebas de software 01 – Conceptos y definiciones Prueba y Caso de Prueba • Enmascaramiento del error: Varios estados de error se compensan mutuamente – no aparece el efecto del error. • Depuración: Localización y corrección de errores internos. • Prueba: Búsqueda dirigida y sistemática de los efectos del error, para demostrar defectos. • Prueba de Software: Cada ejecución de un objeto de prueba que sirva para su comprobación.

18

II - Fundamentos de las pruebas de software 01 – Conceptos y definiciones Prueba y Caso de Prueba • Caso de Prueba: Unión de una prueba y unas condiciones de entorno establecidas – p. ej. requisitos de ejecución, datos de entrada fijos en relación con los datos esperados o con un comportamiento esperado del objeto de prueba. • Explosión de casos de prueba: Debido a las numerosas posibilidades de combinación, p.ej. de datos de entrada, el número de los posibles casos de prueba crece tanto que puede llevar a un conjunto de cientos o miles de casos de prueba.

19

II - Fundamentos de las pruebas de software 01 – Conceptos y definiciones Calidad de Software • Según ISO / IEC 9126: La calidad de software es la totalidad de propiedades y características de un producto de software referidas a su aptitud para satisfacer necesidades explícitas o implícitas. • Según IEEE Std 610: El grado en el que un componente, sistema o proceso alcanza los requisitos especificados y/o las necesidades y expectativas del usuario o cliente.

20

II - Fundamentos de las pruebas de software 01 – Conceptos y definiciones Calidad de Software • La Calidad de Software según la norma ISO / IEC 9126 abarca: • Funcionalidad. • Fiabilidad. • Usabilidad. • Eficiencia. • Mantenibilidad. • Portabilidad. • El aseguramiento de la calidad (QS/QA) diferencia entre: • Medidas constructivas para evitar errores (p.ej. mediante métodos adecuados de ingeniería de software). • Métodos analíticos para la detección de errores (p. ej. mediante pruebas, ya que el descubrimiento de errores sirve para corregir defectos y elevar de esta manera la calidad del software).

21

II - Fundamentos de las pruebas de software 01 – Conceptos y definiciones Medidas constructivas para el aseguramiento de la calidad (QA) Medidas QA constructivas

Medidas Técnicas

Métodos

Herramientas

Medidas Organizativas

Directrices

Estándares

Listas de Chequeo

Requisitos legales

Plantillas

• Motivación principal: Los errores que no se cometen no necesitan ser corregidos.

22

II - Fundamentos de las pruebas de software 01 – Conceptos y definiciones Medidas analíticas para el aseguramiento de la calidad (QA) Medidas QA analíticas

Medidas estáticas

Revisiones / Walkthroughs

Medidas dinámicas

Análisis de flujos de control y de datos

Análisis de código. Compiladores

Caja negra

• • • •

Técnicas basadas en la experiencia

Partición de equivalencia Análisis de valores límite Transición de estados Tablas de decisión

Caja blanca

• Cobertura de sentencias • Cobertura de decisiones o ramas • Cobertura de condiciones

23

II – Fundamentos de las pruebas de software 02.1 – ¿Por qué es necesario probar? El software como factor económico • El software contribuye de manera definitiva al funcionamiento de aparatos e instalaciones de uso cotidiano (automoción, banca...). De hecho, existen sistemas que serían inviables sin un software que los apoyara.

Calidad del Software • La calidad del software es un factor decisivo para el éxito de determinados productos o de las propias empresas. Desgraciadamente todos tenemos experiencias negativas... • Movimientos incorrectos en la cuenta del banco, en la factura del teléfono, etc. • Problemas con la “centralita” del automóvil. • No disponibilidad de páginas Web. • No poder sacar dinero de la cuenta. • No poder realizar una gestión administrativa. • No poder devolver o recoger un libro, etc. 24

II – Fundamentos de las pruebas de software 02.1 – ¿Por qué es necesario probar?

Que la calidad del software sea un factor decisivo de éxito es difícil de ver, pero que la falta de calidad es un factor decisivo de fracaso, es un tema bastante claro.

25

II – Fundamentos de las pruebas de software 02.1 – ¿Por qué es necesario probar? Ejemplo: Fallo en la unidad de coma flotante del Pentium • En 1994 se descubrió que algunas operaciones de división devolvían siempre un valor erróneo por exceso. • Estas comprobaciones crearon una gran polémica. Intel negó inicialmente la existencia del problema, después lo minimizó negándose a una sustitución sistemática. Si bien evaluaciones independientes mostraron la poca importancia del error llegó a haber demandas (incluyendo entre los demandantes empresas como IBM). Por último, Intel se vio forzada a aceptar sustituir todos los microprocesadores defectuosos, lo que le representó un coste enorme.

26

II – Fundamentos de las pruebas de software 02.1 – ¿Por qué es necesario probar? Ejemplo: Phobos 1 • La Phobos 1 despegó y tuvo un funcionamiento correcto hasta que dos meses después de su lanzamiento se perdió la señal. La fuente del problema fue una orden errónea (concretamente se transmitió un "+" en vez de un "-"). Incapaz de controlar su orientación, la Phobos 1 dejó de orientar sus paneles solares hacia nuestra estrella. Sin energía, no pudo restablecerse contacto con ella. • Al margen del error, parecería lógico haber “asegurado” una orden tan crítica como demostró ser la que se envió. Estaba previsto, pero la versión definitiva del código que la contenía no se implantó a causa de las prisas en la finalización de los trabajos.

27

II – Fundamentos de las pruebas de software 02.1 – ¿Por qué es necesario probar? Otros errores software famosos • Apolo 11 (fallo de aterrizaje). • Mariner 1 (faltaba una coma). • Ariadne 5 (basado en una versión anterior de sw, el equipo físico no pudo responder a la mayor aceleración). Importancia de las condiciones de entorno. • Therac-25 (Dosis masivas de radiación. Generó, al menos, 5 muertes). Importancia del control de los sistemas software .

28

II – Fundamentos de las pruebas de software 02.2 – ¿Por qué es necesario probar? Causas de los defectos • El software es elaborado por seres humanos que pueden cometer errores que dan lugar a defectos. Estos defectos pueden generar un fallo. • Las causas de los errores (al margen de la falibilidad del ser humano) pueden ser: presión en los tiempos, complejidad de la aplicación o la arquitectura, tecnologías cambiantes, existencia de un gran número de interfaces, etc. • Al margen de por la existencia de un defecto pueden producirse fallos por condiciones ambientales (radiación, magnetismo, campos eléctricos, etc.).

29

II – Fundamentos de las pruebas de software 02.3 – ¿Por qué es necesario probar? Las Pruebas como medio de mejora de la calidad • Un medio para conseguir la mejora de la calidad tanto de los sistemas de software como del propio proceso de desarrollo son la comprobación y prueba sistemática del software desarrollado. • Los errores que se detecten antes del uso del software pueden ser corregidos antes de que generen fallos. • Puede exigirse por contrato un nivel mínimo de prueba. • Las pruebas pueden requerirse también para satisfacer requisitos contractuales o legales, o estándares específicos de la industria.

30

II - Fundamentos de las pruebas de software 02.4 – ¿Por qué es necesario probar? Calidad de Software • Una Funcionalidad de buena calidad implica • Circunscribirse a las características funcionales requeridas (corrección). • Cubrir todos los requisitos funcionales definidos (completitud). • Características que debe cumplir una funcionalidad (ISO/IEC 9126): • Idoneidad (suitability). ¿Son adecuadas las funciones disponibles para la utilización prevista?

• Precisión (accuracy). ¿Se ejecutan las funciones correctamente (como estaba acordado)?

• Conformidad (compliance). ¿Se cumplieron las normas y preceptos?

• Interoperabilidad. ¿Se proporciona una interrelación libre de errores con el entorno del sistema?

• Seguridad. ¿Están protegidos los datos / programas frente a accesos / pérdidas? 31

II - Fundamentos de las pruebas de software 02.4 – ¿Por qué es necesario probar? Calidad de software. Atributos no funcionales • Fiabilidad • Capacidad de un software / un sistema de mantener un rendimiento / funcionalidad bajo condiciones predeterminas durante un periodo de tiempo definido. • Da una idea del comportamiento de la calidad a lo largo del tiempo. • Factores asociados: tolerancia a fallos, capacidad de recuperación ante fallos. • Usabilidad* • Un software es usable si es: • Fácil de entender (uso intuitivo). • Fácil de aprender. • Existe normativa específica. * ver ISO / IEC 9241.

32

II - Fundamentos de las pruebas de software 02.4 – ¿Por qué es necesario probar? Calidad de software. Atributos no funcionales • Eficiencia • Utilización de recursos lo más reducida posible (p.ej. tiempo de CPU) para la consecución de una tarea. • Mantenibilidad • Esfuerzo necesario para realizar una serie de modificaciones definidas de antemano. • Factores asociados: estabilidad, facilidad de cambio. • Portabilidad • Posibilidad de trasladar un software a otro entorno (hardware, software u organizativo). • Factores asociados: facilidad de sustitución, facilidad de instalación, cumplimiento de estándares.

33

II - Fundamentos de las pruebas de software 02.4 – ¿Por qué es necesario probar? Calidad de Software. Atributos de la calidad • Algunas características de la calidad de software influyen entre si. Puede ser necesario según el caso asignar unas prioridades a las características. • Ejemplos: • • •

Una descripción puede dejar de ser concisa en aras de la claridad. Un software puede ser redundante (y con ello más difícil de mantener) para aumentar su fiabilidad. Una base de datos lo puede ser para mejorar los tiempos de acceso.

• A lo largo del seminario quedará claro que para las diferentes características deben ejecutarse diferentes tipos de pruebas.

34

II - Fundamentos de las pruebas de software 02.5 – ¿Por qué es necesario probar? ¿Cuánto esfuerzo en pruebas es suficiente? • Como todos los demás productos, tampoco el software está “siempre” libre de fallos: • Las pruebas no pueden garantizar nunca la ausencia de fallos en un programa, sin embargo pueden encontrar y solucionar errores. • En la práctica unas pruebas exhaustivas son rara vez posibles, sin embargo tampoco se puede garantizar para las partes probadas la ausencia total de errores.

35

II - Fundamentos de las pruebas de software 02.5 – ¿Por qué es necesario probar? ¿Cuánto esfuerzo en pruebas es suficiente? • Según el ámbito de aplicación y el tipo de error pueden ocasionarse daños graves. • Por eso deben ser probadas “todas” las funcionalidades de un software de manera sistemática. • Un proceso de pruebas puede considerarse en cierto sentido como destructivo y debe estar siempre encaminado a encontrar nuevos fallos. • La resolución de errores durante el desarrollo. • Mejora el producto. • Reduce el coste de una eliminación posterior de los errores.

36

II - Fundamentos de las pruebas de software 02.5 – ¿Por qué es necesario probar? ¿Cuánto esfuerzo en pruebas es suficiente? • Criterios de finalización • No localizar defectos durante un tiempo determinado. Es una métrica simple pero no es suficiente. La posibilidad de que exista un error crítico podría forzar la continuación de las pruebas. • Fin del tiempo o de los recursos disponibles para las pruebas. • Desgraciadamente, suele ser un criterio aplicado frecuentemente. • Curvas de crecimiento de fiabilidad. • Proporcionan un método de estimación objetiva para establecer el punto óptimo de finalización pero requieren un control preciso del esfuerzo de prueba y un conocimiento histórico de las características del sistema.

37

II - Fundamentos de las pruebas de software 02.5 – ¿Por qué es necesario probar? ¿Cuánto esfuerzo en pruebas es suficiente? • Criterios de finalización

La pendiente de la curva representa el número total de fallos encontrados, es muy pronunciada hasta casi el final de los 18 intervalos de pruebas, a partir de este punto el crecimiento de fallos irá decreciendo hasta hacerse nulo, momento en el que ya se habrán encontrado todos los fallos esperados.

38

II - Fundamentos de las pruebas de software 02.5 – ¿Por qué es necesario probar? ¿Cuánto esfuerzo en pruebas es suficiente? • Criterios de finalización Las técnicas de crecimiento de fiabilidad del software, se utilizan para estimar la tasa de fallos y la fiabilidad de un sistema de software durante la fase de pruebas de su desarrollo. Además, se podrá predecir el número de fallos que tendrá un sistema en la fase de producción, de forma que el gestor del proyecto dispondrá de una útil herramienta de decisión para: 1. Establecer si el conjunto de pruebas al que ha sido sometido el sistema ha resultado suficiente de forma que se pueda autorizar su paso a producción. 2. Reducir la posibilidad de que ocurra una incidencia grave en producción. 3. Estimar el momento, durante la fase de pruebas, en que se alcanzan los objetivos de fiabilidad del sistema.

39

II - Fundamentos de las pruebas de software 03 – ¿Qué son las pruebas (Testing)? • Las pruebas no son sólo ejecutar test cases: • Esto es parte de las pruebas, pero existen más actividades de pruebas • Existen actividades de prueba antes y después de la ejecución (planificación y control; diseño y ejecución de test cases; comprobación de resultados; evaluación de los criterios de salida; informar sobre el proceso de prueba y el sistema bajo prueba; y finalizar las actividades de cierre)

• Las pruebas también incluyen la revisión de la documentación (incluyendo el código) y la realización de análisis estático. • Ambas, pruebas estáticas y dinámicas persiguen los mismos objetivos y proporcionan información valiosa para la mejora, tanto del sistema, como de los procesos de desarrollo y de pruebas.

• Objetivos de las pruebas: • Encontrar defectos • Ganar confianza acerca del nivel de calidad • Proporcionar información para la toma de decisiones • Evitar o Prevenir defectos

40

II - Fundamentos de las pruebas de software 03 – ¿Qué son las pruebas (Testing)? • Depurar y probar son diferentes: • Las pruebas dinámicas muestran fallos causados por defectos. • La depuración, sin embargo, es la actividad de desarrollo que localiza, analiza y elimina las causas de los fallos. • Normalmente, la responsabilidad de las pruebas la tienen los probadores, mientras que los desarrolladores suelen tener la de la depuración (debugging)

41

II - Fundamentos de las pruebas de software 04 – Problemática de la comprobación y las pruebas Problemas generales de las pruebas • Ámbito de las pruebas • ¡Ningún software complejo puede ser probado completamente ! – Incluso si se definieran todos los casos de prueba posibles su ejecución consumiría enormes recursos. • En la práctica no sería posible la definición de todos los casos de prueba necesarios para unas pruebas exhaustivas, ya que habría que tener en cuenta todas las diferentes condiciones de entorno posibles. • Además prácticamente en ningún caso se podrá decir con seguridad que se han definido todos los casos de prueba posibles.

42

II - Fundamentos de las pruebas de software 04 – Problemática de la comprobación y las pruebas Problemas generales de las pruebas • Alcance • El alcance de las pruebas debe ser, por consiguiente, reducido - esto sucede en función de la relación entre Prioridades y Riesgo establecida utilizando formas de proceder sistemáticas. • Un alto esfuerzo de pruebas para la eliminación de fallos “menores” no está justificado. • Implementar un programa sin comprobar los errores en sus características esenciales no tiene mucho sentido.

• En la práctica se prueba mediante casos puntuales. • En todo caso, esta prueba puntual se determina en la práctica de manera analítica.

43

II - Fundamentos de las pruebas de software 04 – Problemática de la comprobación y las pruebas Problemas generales de las pruebas • Costes • Las pruebas originan altos costes dentro del desarrollo de software • Sobre todo en grandes proyectos de IT el esfuerzo para realizar las pruebas puede ser el mayor de todos respecto del esfuerzo total empleado. • Las pruebas tempranas contribuyen a la mejora del proceso de desarrollo y reducen de esta manera los costes (entre otras causas por la reducción de errores descubiertos en fases posteriores del desarrollo de software, ya que ahí el descubrimiento de fallos y su resolución conlleva un esfuerzo claramente mayor).

44

II - Fundamentos de las pruebas de software 04 – Problemática de la comprobación y las pruebas Problemas generales de las pruebas • Costes • Los errores que no se encuentran en las pruebas también producen costes (Coste de Errores): • Pérdidas de imagen, esfuerzos para las correcciones y compensación de daños amenazan al productor. • Errores o pérdidas de datos y tiempos de inactividad son las consecuencias para los clientes. • En muchas situaciones es aplicable que: • Los costes de las pruebas deberían ser menores que los posibles costes de los errores.

45

II - Fundamentos de las pruebas de software 05 – Siete Principios de las Pruebas Principio 1: Las pruebas muestran la presencia de defectos •

Las pruebas pueden mostrar la presencia de defectos. • Las desviaciones respecto a los resultados previstos que se descubren durante las pruebas permiten localizar defectos existentes en el software

•

Las pruebas no pueden probar la ausencia de defectos. • Las pruebas reducen la probabilidad de que queden defectos sin descubrir. La ausencia de fallos no prueba que el software sea correcto • El propio procedimiento de prueba puede contener errores • Las condiciones de pruebas pueden no estar bien preparadas para encontrar errores

46

II - Fundamentos de las pruebas de software 05 – Siete Principios de las Pruebas Principio 2: Las pruebas exhaustivas no son posibles •

Pruebas exhaustivas. Es una estrategia de pruebas en la que se abarcan todas las posibles combinaciones de valores de entrada y precondiciones.

•

Explosión de casos de prueba. Define el aumento exponencial de esfuerzo y coste que aparece cuando se hacen pruebas exhaustivas.

•

Muestreo en las pruebas •

•

•

Las pruebas deben incluir sólo un subconjunto de todos los valores de entrada posibles. Las entradas seleccionadas pueden escogerse de forma sistemática o aleatoria. En condiciones reales, se suele emplear el muestreo. Las pruebas de todas las combinaciones de entradas y precondiciones es viable desde el punto de vista económico sólo en casos triviales. En lugar de llevar a cabo pruebas exhaustivas, se debería utilizar el análisis de riesgo y el uso de priorizaciones para enfocar los esfuerzos de las pruebas.

47

II - Fundamentos de las pruebas de software 05 – Siete Principios de las Pruebas Principio 3: Pruebas tempranas Las actividades de prueba deberían iniciarse tan pronto como sea posible en el ciclo de vida de desarrollo y deberían tener objetivos concretos. •

Cuanto antes se descubra un defecto, menos costosa será su corrección. • • •

•

La máxima efectividad se alcanza cuando los errores se corrigen antes de ser implementados. Pueden probarse los documentos de requisitos conceptuales y las especificaciones. Los defectos que se descubren en la fase de concepción del proyecto se corrigen con mínimos esfuerzos y costes.

La preparación de una prueba consume tiempo. La prueba no es sólo la ejecución. • •

Pueden realizarse actividades de prueba (Diseño) antes de que se complete el desarrollo del software. Las actividades de prueba (considerando como tales las revisiones) deberían llevarse a cabo en paralelo a la especificación y el diseño del software. 48

II - Fundamentos de las pruebas de software 05 – Siete Principios de las Pruebas Principio 4: Bloques de defectos Unos pocos módulos contienen la mayor parte de los defectos descubiertos durante la fase de pruebas o son responsables de la mayoría de los fallos en producción. •

Encuentre un defecto y encontrará más en los alrededores • •

•

Los defectos aparecen frecuentemente en grupos como las setas. Es una buena idea repasar el módulo en el que se ha encontrado un defecto.

Los probadores deben ser flexibles • •

Una vez detectado un defecto, es una buena idea reconsiderar la dirección de las siguientes pruebas. La localización de un defecto debe ser revisada con un mayor nivel de detalle, ya sea incorporando nuevas pruebas o modificando las existentes.

49

II - Fundamentos de las pruebas de software 05 – Siete Principios de las Pruebas Principio 5: La paradoja del pesticida (Bezier) Si se repiten una y otra vez los casos de prueba, se llegará a que el mismo conjunto de casos de prueba no sirva para localizar nuevos defectos. Para superar esta “paradoja del pesticida”, los casos de prueba necesitan ser revisados de manera regular y se necesita escribir casos nuevos (y diferentes) para ejercitar diferentes partes del software o sistema para localizar más defectos. •

Cualquier método que se use para prevenir o encontrar bugs deja un residuo o bugs más sutiles, contra los que ese método no es efectivo.

•

Repetir las pruebas bajo las mismas condiciones no es efectivo. •

•

Si se repiten una y otra vez las mismas pruebas no se encontrarán nuevos errores.

Las pruebas deben ser revisadas regularmente. •

Es necesario repetir una prueba después de que se hagan cambios en el código.

•

Las pruebas automatizadas pueden ser una ventaja si se usa regularmente un grupo de casos de prueba. 50

II - Fundamentos de las pruebas de software 05 – Siete Principios de las Pruebas Principio 6: Las pruebas dependen del contexto Las pruebas se llevan a cabo de manera diferente en contextos diferentes. Por ejemplo, el software crítico desde el punto de vista de la seguridad de las personas (safety) se prueba de forma distinta que la seguridad de un portal de comercio electrónico (security). •

Las pruebas pueden tener distintos resultados en distintos contextos. • •

•

Diferentes objetos de prueba se prueban de forma distinta. El controlador del motor de un coche requiere distintas pruebas que las de una aplicación de comercio electrónico.

Pruebas en el entorno de prueba vs pruebas en el entorno de producción. • •

Las pruebas deben llevarse a cabo en un entorno separado al de producción. El entorno de prueba debe ser muy similar al de producción. Siempre habrá desviaciones entre ambos entornos.

51

II - Fundamentos de las pruebas de software 05 – Siete Principios de las Pruebas Principio 7: La falacia de la ausencia de errores Localizar y corregir defectos no sirve de nada si el sistema construido no cubre las necesidades y expectativas de los usuarios. •

Unas pruebas adecuadas localizan los fallos más serios. •

•

En la mayoría de los casos, las pruebas no encontrarán todos los defectos del sistema (ver principio 2) pero sí los más serios.

Con esto solamente, no se prueba la calidad del software. • •

La funcionalidad del software puede no cumplir las necesidades y expectativas de los usuarios. No se puede probar la calidad de un producto solo con las pruebas, debe construirse desde el principio con la calidad requerida.

52

II - Fundamentos de las pruebas de software 06 – Proceso de pruebas fundamental El proceso de desarrollo de software • Un desarrollo de software estructurado sigue pasos claramente definidos • Diferentes modelos de procedimiento muestran el desarrollo estructurado

•

Modelo en cascada según Royce (1970):

• Proceso de desarrollo en 7 etapas. • Cada etapa sólo tiene una conexión hacia atrás con la etapa anterior. • Las pruebas sólo representan una etapa en el proceso . • Se corresponde con la aceptación final de producto.

53

II - Fundamentos de las pruebas de software 06 – Proceso de pruebas fundamental Las pruebas dentro del proceso de desarrollo de software • Independientemente del modelo de procedimiento, las pruebas se llevan a cabo en diferentes momentos del proceso de desarrollo de software. • Las pruebas en sí deben ser entendidas también como un proceso. • El proceso de pruebas incluye las siguientes fases: • Planificación y control. • Análisis y diseño. • Implementación y ejecución. • Evaluación y documentación. • Cierre de las pruebas.

• Estas fases no tienen por qué ocurrir siempre de forma secuencial, podrían solaparse o suceder concurrentemente.

54

II - Fundamentos de las pruebas de software 06.1 – Proceso de pruebas fundamental Planificación de las pruebas • Comienza con el inicio del proceso de desarrollo • Principales tareas: • Determinar el alcance y los riesgos. • Identificar los objetivos de las pruebas y los criterios de finalización. • Seleccionar y priorizar las pruebas (p.ej. según el riesgo). • Determinar las técnicas, cobertura, herramientas, entorno y equipos de prueba. • Determinar los métodos y estrategia. • Planificar las actividades. • Adquirir/planificar los recursos. • Personal. • Entorno y medios de apoyo. • Coste.

• La planificación debe tomar en consideración la información que le proporcionen las actividades de control y monitorización.

Inicio Planificación y control

Análisis y diseño Implementación y Ejecución Evaluación y Documentación

Cierre

Fin

55

II - Fundamentos de las pruebas de software 06.1 – Proceso de pruebas fundamental Control de las pruebas • Comparar el progreso real con el planificado. Incluye tomar las acciones necesarias para llevar a cabo la mision y alcanzar los objetivos del proyecto. • Para ello, el proyecto de pruebas ha de ser monitorizado a lo largo de toda su vida. Ejemplos de métricas: • • • • • • • •

% del trabajo realizado en la preparar casos de prueba. % de trabajo hecho en la preparación del entorno. % Ejecución de casos. Información de defectos. Cobertura de requisitos, riesgos o código. Confianza subjetiva de los probadores en el producto. Fechas de los hitos de prueba. Costes de las pruebas.

Inicio Planificación y control

Análisis y diseño Implementación y Ejecución Evaluación y Documentación

• Principales tareas: • Tomar decisiones basadas en la información que le proporciona la monitorización de las pruebas. • Repriorizar las pruebas cuando aparece un riesgo identificado (por ejemplo, retraso en la entrega del sw). • Cambiar la planificación según la disponibilidad del entorno.

Cierre

Fin

56

II - Fundamentos de las pruebas de software 06.2 – Proceso de pruebas fundamental Análisis y diseño de las pruebas • Analizar la documentación en base a la cual se van a generar los casos de prueba. • Evaluar la capacidad de los objetos de ser probados. • Diseñar y priorizar casos de prueba lógicos (alto nivel). • En base a los métodos establecidos en la estrategia de pruebas.

• Identificar los datos de prueba. • A menudo son necesarios datos “anónimos”.

• Establecer las condiciones marco. • Diseñar/adaptar el entorno de pruebas. Identificar infraestructuras necesarias. • Definir la operación del entorno de prueba, incluyendo la administración de los usuarios. • Crear trazabilidad bidireccional entre la documentación base y los casos de prueba.

Inicio Planificación y control

Análisis y diseño

Implementación y Ejecución Evaluación y Documentación

Cierre

Fin

57

II - Fundamentos de las pruebas de software 06.3 – Proceso de pruebas fundamental Implementación de las pruebas • Desarrollo, implementación y priorización de casos de prueba. • En su caso, escribir scripts de pruebas automatizadas. • Crear secuencias de prueba para mejorar la eficiencia de la ejecución. • Implementar controladores de pruebas. • Implementar/configurar/verificar el entorno de pruebas. • Instalar herramientas. • Integrar los datos de prueba. • Verificar y actualizar la trazabilidad bidireccional entre la documentación base y los casos de prueba.

Inicio Planificación y control

Análisis y diseño Implementación y Ejecución Evaluación y Documentación

Cierre

Fin

58

II - Fundamentos de las pruebas de software 06.3 – Proceso de pruebas fundamental Ejecución de las pruebas • Ejecutar los casos/secuencias de prueba. • Registrar y analizar resultados. Registro de: • • • •

Objeto de la prueba. Probador. Datos de prueba. Resultado.

• Comparar los resultados obtenidos con los resultados esperados e informar acerca de las discrepancias, analizándolas establecer su origen (error en código, en los datos de prueba, en el caso de prueba, en la forma de ejecutar la prueba...). • Repetir las actividades de prueba según la acción que se lleve a cabo para cada discrepancia.

Inicio Planificación y control

Análisis y diseño Implementación y Ejecución Evaluación y Documentación

Cierre

Fin

59

II - Fundamentos de las pruebas de software 06.4 – Proceso de pruebas fundamental Evaluación y documentación de las pruebas • La evaluación de los criterios de finalización (o de salida) es la actividad en la que se valora la ejecución de la prueba respecto de los objetivos definidos. Debería llevarse a cabo en cada nivel de prueba e implica: • Analizar los logs de la prueba (resumen de actividades de prueba realizadas, resultado de la prueba, etc). • Comprobación de los criterios de finalización de las pruebas. • Comparar los resultados obtenidos con los objetivos esperados. • Si se cumplen todos los criterios, las pruebas finalizan.

Inicio Planificación y control

Análisis y diseño Implementación y Ejecución Evaluación y Documentación

Cierre

Fin

60

II - Fundamentos de las pruebas de software 06.4 – Proceso de pruebas fundamental Evaluación y documentación de las pruebas • Si no se cumplen los criterios, • Habrá que comprobar, en determinados casos, si realmente es posible cumplirlos • Habrá que comprobar si la planificación de las pruebas necesita ser adaptada

• En su caso, los errores encontrados llevan a un nuevo ciclo de pruebas – empezando por la especificación de los casos de prueba. • Se ha de proporcionar información suficiente para ayudar a la decisión de si se ha de continuar o no con las pruebas. • Se ha de generar un informe final de pruebas dirigido a las áreas afectadas.

Inicio Planificación y control

Análisis y diseño Implementación y Ejecución Evaluación y Documentación

Cierre

Fin

61

II - Fundamentos de las pruebas de software 06.4 – Proceso de pruebas fundamental Criterios de finalización de las pruebas • Ratio de localización de errores • El número de errores encontrados por hora de esfuerzo de pruebas desciende de un valor establecido. • Si se encuentra, p.ej., menos de un error nuevo por hora de esfuerzo de pruebas, las pruebas finalizarán. • Aquí se tiene en cuenta la rentabilidad de las pruebas que no se da a partir de un determinado ratio.

• Finalización de las pruebas por motivos de coste o tiempo • P.ej. a causa de una planificación escasa de recursos . • Origina, por norma general, costes adicionales por la aparición posterior de errores.

• Cobertura de código • x % de código del programa ha debido ser ejecutado.

• Cobertura de riesgos • Los casos de prueba de una clase de riesgo definida (p.ej. de la máxima prioridad) se han debido ejecutar sin errores.

62

II - Fundamentos de las pruebas de software 06.5 – Proceso de pruebas fundamental Actividades de cierre • Recoger datos de las actividades de prueba completadas para consolidar experiencia. • Cierre de los informes de incidencias o apertura de solicitudes de cambio para todos los puntos que sigan abiertos. • Comprobación de que entregables han sido efectivamente entregados y aprobados. • Documentación de la aceptación del sistema. • Archivado de las pruebas, el entorno de pruebas y la infraestructura de pruebas para posterior reutilización. • Análisis de las lecciones aprendidas para futuros proyectos. • Usar la información recopilada para mejorar la madurez de las pruebas.

Inicio Planificación y control

Análisis y diseño Implementación y Ejecución Evaluación y Documentación

Cierre

Fin

63

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas Diferencias entre diseñar, desarrollar y probar •

Las pruebas requieren una forma diferente de pensar de las de aquellos que diseñan o desarrollan sistemas: • • • •

•

La misión del diseñador es ayudar al cliente suministrándole los requisitos correctos. La misión del desarrollador es convertir los requisitos en funciones. La misión del probador es examinar la correcta implementación de los requisitos del usuario. Objetivo común: proporcionar buen software.

En principio, una persona puede asumir los tres roles: • • •

Es difícil pero es posible. Se deben tener en cuenta las diferencias en los objetivos asociados a cada rol. Otras soluciones (como tener un equipo de pruebas independiente) suelen ser más fáciles y producir mejores resultados.

64

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas

Las personas y los proyectos se conducen en base a objetivos. Las personas tienden a alinear sus planes con los objetivos establecidos por los gestores u otros responsables, por ejemplo: encontrar defectos o confirmar que funciona el software. Por eso es importante establecer de una forma clara los objetivos de las pruebas.

65

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas La mentalidad a utilizar durante las pruebas y revisiones es distinta a la que hay que tener durante el desarrollo. El desarrollador. • Transforma los requisitos. • Desarrolla estructuras. • Programa el software. • Consigue un producto. ⇒ ¡El desarrollador es constructivo!.

El probador. • Planifica sus pruebas. • Especifica casos de prueba. • Sólo quiere encontrar errores. • Los errores del programador son su éxito. ⇒ ¡El probador es destructivo!.

¡Falso! ¡También las pruebas son constructivas, ya que su objetivo es un producto libre de errores!

66

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas Las dificultades • El probador experimentado mantiene una distancia suficiente respecto del objeto de la prueba. • Cuanto más alejado esté el probador del desarrollo más independientemente y más objetivamente podrá llevar a cabo su trabajo. • Una distancia demasiado grande respecto del objeto de prueba puede, sin embargo, provocar que se necesite más tiempo para las pruebas.

67

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas Posibles formas de llevar a cabo las pruebas • Pruebas del desarrollador: • El desarrollador nunca se mantiene neutral respecto de su “creación”. • En definitiva conoce el objeto de prueba mejor que nadie. • No se producen costes adicionales por tener que ponerse al corriente respecto del objeto de prueba.

• El hombre tiende a ser ciego respecto a sus errores. • Por eso existe el peligro para el desarrollador de no ver fallos evidentes.

• Los errores como consecuencia de una mala interpretación de los requisitos quedan sin descubrir. • Estos errores se pueden evitar, o al menos reducir, mediante la formación de equipos de desarrollo en los que los desarrolladores comprueban mutuamente sus productos.

68

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas Posibles formas de llevar a cabo las pruebas • Pruebas diseñadas por otras personas del equipo de desarrollo. • La formación de equipos de pruebas con miembros de diferentes áreas del proyecto mejora la calidad de las pruebas. • Es importante que estos equipos puedan trabajar lo más independientemente posible. • Pruebas diseñadas por personas de un grupo distinto perteneciente a la organización (como un equipo de prueba independiente) o especialistas en pruebas (como los especialistas en pruebas de usabilidad o prestaciones).

69

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas Posibles formas de llevar a cabo las pruebas • Pruebas diseñadas por personas de otras organizaciones (como Outsourcing de pruebas o certificación realizada por un ente externo). • Una separación completa de las pruebas consigue la mayor distancia posible entre el objeto de prueba y el probador. • En todo caso se dispone de poco conocimiento sobre el objeto de prueba y el proyecto. • Se requiere un gran esfuerzo de puesta al corriente. • Los expertos externos deberían ser por ello involucrados desde las fases tempranas del proyecto.

• Los expertos externos tienen en todo caso un Know-how muy desarrollado acerca de las pruebas. • La definición optima de los casos de prueba queda así garantizada. • Como otra ventaja, la utilización óptima de métodos y herramientas, además de una ejecución de las pruebas acorde.

70

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas Personalidad de un buen probador •

Curioso, atento a los detalles. • • •

•

Para comprender los escenarios prácticos en los que se mueve el cliente. Para ser capaz de analizar la estructura de la prueba. Para descubrir detalles que pueden identificar fallos.

Escepticismo y ojo crítico. • •

Los objetos de prueba contienen defectos. Se trata de encontrarlos. No se debe ver limitado por el hecho de que un error grave pueda afectar a (por ejemplo) las fechas del proyecto.

71

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas Personalidad de un buen probador •

Buenas capacidades de comunicación. • • •

• •

Para dar malas noticias a los desarrolladores. Para no perder la perspectiva ante situaciones frustrantes. Para establecer rápidamente una relación de trabajo con los desarrolladores.

La comunicación positiva puede ayudar a evitar o facilitar situaciones complicadas. Experiencia. • •

Los factores personales influyen en la ocurrencia de errores. La experiencia ayuda a identificar donde se pueden acumular los errores.

72

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas Problemas de comunicación • Especialmente en fases del proyecto estresantes la notificación de los errores puede generar problemas, sobre todo si los probadores son vistos como portadores de malas noticias. • La manera de notificar el error y la descripción del mismo son decisivos. • No criticar a las personas sino mostrar el error de forma objetiva. • Facilitar la solución del error al desarrollador mediante la notificación. • El objetivo común debe estar siempre en primer plano. • Una comunicación insuficiente o la ausencia de ésta entre probadores y desarrolladores puede impedir el buen trabajo en equipo. • En ocasiones, no hay entendimiento entre el equipo de pruebas y el de desarrollo. • Los desarrolladores deberían tener nociones básicas de pruebas. • Los probadores deberían conocer las características esenciales del desarrollo de software.

73

II - Fundamentos de las pruebas de software 07 – Psicología de las pruebas Problemas de comunicación •

Hay, sin embargo, varias formas de mejorar la comunicación y las relaciones entre los probadores y el resto: • •

• •

Empezar a colaborar, en vez de entrar en refriegas - recordar a todos que el objetivo común es obtener sistemas de mejor calidad. Comunicar lo que se ha encontrado en el producto de forma neutra, enfocada a los hechos, sin criticar a la persona que lo ha creado, por ejemplo, redactando informes de incidencias y revisiones de forma objetiva y ateniéndose a los hechos. Intentar comprender como se siente la otra persona y por qué reacciona como lo hace. Confirmar que la otra persona ha entendido lo que has dicho y viceversa.

74

II - Fundamentos de las pruebas de software 08 – Código de buenas prácticas Necesario porque: • •

Debido a su participación en las pruebas del software el probador podría acceder a cierta información privilegiada y confidencial. Es necesario, entre otras razones, asegurar que dicha información no es objeto de un uso inapropiado.

El ISTQB establece el siguiente código de buenas prácticas: •

PUBLICO: Los probadores de software certificados actuarán conforme al interés público.

•

CLIENTE Y PROVEEDOR: Los probadores de software certificados actuarán de la mejor manera posible para el interés de sus clientes y proveedores a los que pertenecen, de conformidad con el interés público.

•

PRODUCTO: Los probadores de software certificados asegurarán que los entregables que proporcionen cumplan con los más altos estándares profesionales posibles.

•

JUICIO: Los probadores de software certificados mantendrán integridad e independencia en sus juicios profesionales.

75

II - Fundamentos de las pruebas de software 08 – Código de buenas prácticas El ISTQB establece el siguiente código de buenas prácticas (cont.): •

GESTIÓN: Los jefes y gestores de pruebas de software certificados promoverán y contribuirán con un enfoque ético de la gestión de las pruebas del software.

•

PROFESIÓN: Los probadores de software certificados potenciarán la integridad y reputación de la profesión de conformidad con el interés público.

•

COMPAÑEROS: Los probadores de software certificados serán justos y de apoyo a sus compañeros y promoverán la cooperación con los desarrolladores de software.

•

UNO MISMO: Los probadores de software certificados participarán en el aprendizaje permanente en lo que respecta a la práctica de su profesión y promoverán un enfoque ético en la práctica de su profesión.

76

II - Fundamentos de las pruebas de software 09 – Resumen Afirmaciones importantes del capítulo: • Las pruebas son el instrumento principal para el aseguramiento de la calidad durante el desarrollo de software. • La Norma ISO 9126 establece el término de calidad de software. • Las pruebas completas de programas son prácticamente imposibles. • El software no está casi nunca libre de errores. • La ausencia de errores no puede ser constatada en la práctica mediante pruebas. • Los costes de las pruebas se contrastan siempre con los costes de los errores. • Las pruebas son un proceso en sí dentro del proceso de desarrollo. • Para cada caso de prueba son necesarios datos de entrada y valores esperados, así como condiciones previas y posteriores.

77

II - Fundamentos de las pruebas de software 09 – Resumen Afirmaciones importantes del capítulo: • Para mantener un número manejable de los casos de prueba hay que priorizar. • Nadie trabaja sin errores – en todos los desarrollos ocurren errores. • Sin embargo, la naturaleza del hombre hace difícil reconocer los propios errores – ceguera frente a errores. • Chocan “dos mundos”. • Desarrollar es constructivo – ¡se crea algo!. • Probar es “destructivo” – ¡se deben y se tienen que demostrar los errores!. • Sin embargo, en conjunto ambas actividades son constructivas, siendo su objetivo común construir programas con el menor número de defectos posible. • Según la estrategia de pruebas, prueban los desarrolladores, los equipos de pruebas o expertos externos. • Para asegurar que la información accedida por el profesional de pruebas no es objeto de un uso inapropiado, el ISTQB establece un código de buenas prácticas (8) 78

79

Capítulo III – Las pruebas en el ciclo de vida del software • III/01 Modelos de desarrollo de software. • III/02 Niveles de prueba. •

Pruebas de componentes.

•

Pruebas de integración.

•

Pruebas del sistema.

•

Pruebas de aceptación.

• III/03 Tipos de prueba. • III/04 Pruebas de mantenimiento. • III/05 Resumen. 80

III – Las pruebas en el ciclo de vida del software 01 – Modelos de desarrollo de software Modelos de procedimiento • Los modelos de procedimiento relacionan métodos de desarrollo de software con fases de proyecto para permitir un desarrollo del proyecto estandarizado. • Las pruebas encajan en el modelo, estando asociadas a actividades de desarrollo. • Ejemplos de modelos de procedimiento: • Modelo en cascada. • Modelo genérico en V. • Modelo en V 97 (Modelo de procedimiento de la federación). • Modelo en V XT (nuevo modelo de procedimiento de la federación [2004]). • Extreme Programming (XP).

81

III – Las pruebas en el ciclo de vida del software 01.1 – Modelos de desarrollo de software Las pruebas en el modelo genérico en V • El modelo genérico en V es un modelo de procedimiento para el proceso de desarrollo de software (secuencial). • El desarrollo y las pruebas se representan mediante dos ramas de la misma consideración.

Especificación de requisitos

Pruebas de aceptación

Diseño funcional

Pruebas del sistema

Diseño técnico

Pruebas de integración

Especificación de componentes

Pruebas de componentes

Codificación

• Cada fase del desarrollo se contrapone a una fase diferente de las pruebas. • La preparación de las pruebas se lleva a cabo de manera paralela al desarrollo de software, de hecho, en cada etapa . • Se prueba durante el ciclo de vida completo del software. • Puede haber más o menos fases: pruebas de integracion de componentes y de integración de sistemas. 82

III – Las pruebas en el ciclo de vida del software 01.1 – Modelos de desarrollo de software Las pruebas en el modelo genérico en V • Fases del desarrollo (Rama izquierda) • Definición de requisitos. • Definición de las características del software.

• Diseño funcional. • Conversión de los requisitos en funciones y procesos.

• Diseño técnico. • Definición del entorno del sistema. • Diseño de interfases etc.

Especificación de requisitos Diseño funcional Diseño técnico Especificación de componentes Codificación

• Diseño de la arquitectura del sistema.

83

III – Las pruebas en el ciclo de vida del software 01.1 – Modelos de desarrollo de software Las pruebas en el modelo genérico en V • Fases del desarrollo (rama izquierda). • Especificación de componentes. • Elaboración de los componentes. • Unión de los componentes.

• Codificación. • Transformación de los componentes en código ejecutable.

Especificación de requisitos Diseño funcional Diseño técnico Especificación de componentes Codificación

84

III – Las pruebas en el ciclo de vida del software 01.1 – Modelos de desarrollo de software Las pruebas en el modelo genérico en V • Fases de pruebas (rama derecha). • Pruebas de componentes.

Pruebas de aceptación

• Se prueba la funcionalidad de cada componente individual.

Pruebas del sistema Pruebas de integración

• Pruebas de integración. • Probar si los componentes individuales trabajan en conjunto tal y como se esperaba.

Pruebas de componentes Codificación

• Se prueban funciones que abarquen varios componentes.

85

III – Las pruebas en el ciclo de vida del software 01.1 – Modelos de desarrollo de software Las pruebas en el modelo genérico en V • Fases de pruebas (rama derecha). • Pruebas del sistema.

Pruebas de aceptación

• Prueba de los requisitos que debe cumplir el sistema completo.

Pruebas del sistema Pruebas de integración

• Pruebas de aceptación. • Pruebas del cliente para comprobar el cumplimiento de los requisitos especificados.

Pruebas de componentes Codificación

86

III – Las pruebas en el ciclo de vida del software 01.1 – Modelos de desarrollo de software Las pruebas en el modelo genérico en V • Cada una de las fases del desarrollo se verifica respecto de su fase anterior. • verificar: demostrar, comprobar. • La verificación se refiere aquí a la comprobación acerca de si los supuestos trasladados de la fase anterior han sido correctamente implementados.

Especificación de requisitos

Pruebas de aceptación

Diseño funcional

Pruebas del sistema Pruebas de integración

Diseño técnico Especificación de componentes

Pruebas de componentes

Codificación

Desarrollo e integración Verificación

87

III – Las pruebas en el ciclo de vida del software 01.1 – Modelos de desarrollo de software Las pruebas en el modelo genérico en V • Mediante las fases de prueba se validan las fases de desarrollo. • validar: reforzar, reconocer como válido

Especificación de requisitos

Pruebas de aceptación

Diseño funcional

Pruebas del sistema

Diseño técnico

Pruebas de integración

Especificación de componentes

Pruebas de componentes

Desarrollo e integración Verificación Validación

Codificación

88

III – Las pruebas en el ciclo de vida del software 01.1 – Modelos de desarrollo de software Las pruebas en el modelo genérico en V • Ambas partes del modelo han de ser consideradas de igual valor. • Algunas actividades se pueden desarrollar en paralelo, de esta forma se pueden concluir con anticipación la especificación de casos de prueba / la planificación de las pruebas. Otras actividades deben ser postergadas.

Especificación de requisitos

Pruebas de aceptación

Diseño funcional

Pruebas del sistema

Diseño técnico

Pruebas de integración

Especificación de componentes

Pruebas de componentes

Desarrollo e integración Verificación Validación

Codificación

89

III – Las pruebas en el ciclo de vida del software 01.1 – Modelos de desarrollo de software Las pruebas en el modelo genérico en V • El modelo en W puede verse como una ampliación del modelo genérico en V • En el modelo de W queda claro que ciertas actividades de pruebas pueden establecerse como procesos paralelos al propio desarrollo de software.

Especificación de requisitos

Planificación actividades test

Diseño funcional

Diseño técnico Especificación de componentes

Ejecución pruebas de aceptación

Planificación pruebas de sistema

Ejecución pruebas del sistema

Planificación pruebas de integración Planificación pruebas de componentes

Ejecución pruebas de integración Ejecución pruebas de componentes

Debugging y corrección de errores Debugging y corrección de errores

Debugging y corrección de errores Debugging y corrección de errores

Codificación

90

III – Las pruebas en el ciclo de vida del software 01.2 – Modelos de desarrollo de software Modelos de desarrollo iterativos-incrementales •

Desarrollo de software iterativo • •

•

Las actividades: definición de requisitos, diseño, desarrollo y pruebas se dividen en etapas pequeñas y se lanzan continuamente. Para poder reorientar el proyecto si es necesario debe alcanzarse un consenso con el usuario tras cada iteración.

Ejemplos de modelos iterativos • •

• •

Prototipado: construcción rápida de una representación utilizable del sistema, seguida de modificaciones sucesivas hasta que el sistema esté preparado. Rapid Application Development (RAD): la interfaz del usuario se implementa mediante funcionalidad comercial, ignorando la funcionalidad que será desarrollada con posterioridad. Rational Unified Process (RUP): modelo orientado a objeto, producto de Rational / IBM. Proporciona sobre todo el lenguaje UML y soporte para el proceso unificado. Modelos de desarrollo ágiles, como Extreme Programming (XP): el desarrollo y las pruebas se llevan a cabo sin que exista una especificación de requisitos formalizada.

91

III – Las pruebas en el ciclo de vida del software 01.3 – Modelos de desarrollo de software Las pruebas dentro del modelo de ciclo de vida •

Hay varias características asociadas a unas buenas pruebas que aplican a todos los modelos de ciclo de vida: • • • •

•

Para cada actividad de desarrollo hay una actividad de prueba asociada Cada nivel de prueba tiene objetivos específicos al nivel. Debería iniciarse el análisis y diseño de las pruebas de cada nivel durante la actividad de desarrollo asociada Los probadores debieran involucrarse en la revisión de documentación tan pronto como estén disponibles los borradores

Se pueden combinar o reorganizar los niveles de prueba en función de la naturaleza del proyecto o de la arquitectura del sistema. Por ejemplo, para la integración de un software comercial (COTS) en un sistema, el comprador podría llevar a cabo pruebas de integración a nivel de sistema (esto es: integración con la infraestructura y con otros sistemas, o despliegue del sistema) y pruebas de aceptación (pruebas funcionales y/o no funcionales; y operacionales y/o de usuario).

92

III – Las pruebas en el ciclo de vida del software 02.1 – Niveles de prueba. Pruebas de componentes

Definiciones y conceptos • Pruebas de componentes (Definición): Pruebas de cada uno de los componentes básicos del software (componentes) respecto de su programación. Debido a las diferentes definiciones de componentes básicos de software en los distintos lenguajes de programación existen diferentes definiciones para las pruebas de componentes: • Pruebas de módulo (denominadas así, p.ej., en C). • Pruebas de clases (denominadas así, p.ej., en Java o C++ ). • Pruebas de unidad (denominadas así, p.ej., en Pascal). • Los componentes comprobados serán, respectivamente, módulos, clases o unidades.

93

III – Las pruebas en el ciclo de vida del software 02.1 – Niveles de prueba. Pruebas de componentes ¿Qué se prueba? • Pruebas completas de los componentes individuales. • Un componente puede estar formado por varios elementos más simples. • Cada componente se prueba de manera separada y aislada. • Se deben buscar errores internos. • Los efectos hacia otros componentes del programa quedan fuera de consideración. • Comentario.: A nivel de pruebas de componentes puede tener sentido la ejecución de pruebas de carga.

94

III – Las pruebas en el ciclo de vida del software 02.1 – Niveles de prueba. Pruebas de componentes ¿Dónde y como se prueba? • Los objetos de prueba son componentes individuales programados • Estos objetos de prueba son , por lo general, partes del programa que se puedan ejecutar aisladamente

• El probador dispone del código de programa de los componentes • Si Probador=Desarrollador (habitual): se puede probar de forma muy cercana al desarrollo • El conocimiento acerca de funciones, estructuras y variables pueden ser utilizados para la generación de casos de prueba (caja blanca) • A menudo se utilizan pruebas funcionales. • Mediante herramientas (depuradores) se posibilita la observación y actuación sobre las variables del programa.

• El conocimiento de código fuente posibilita, en general, la utilización de procedimientos de caja blanca para las pruebas de componentes.

95

III – Las pruebas en el ciclo de vida del software 02.1 – Niveles de prueba. Pruebas de componentes Generalidades •

Fuentes de casos: • • •

•

• • •

Especificación del componente. Diseño de SW. Modelo de datos.

Objetos de prueba típicos: • • •

Componentes. Programas. Conversión de datos / migración de programas.

•

Módulos de base de datos.

Los defectos suelen corregirse según se prueba. No se suelen documentar los errores. Una posible aproximación es preparar y automatizar las pruebas antes de codificar (“test first approach” o “test driven development”). Son modelos iterativos válidos para cuando las modificaciones suelen ser pequeñas.

96

III – Las pruebas en el ciclo de vida del software 02.1 – Niveles de prueba. Pruebas de componentes ¿Dónde y como se prueba? • Para la ejecución de los casos de prueba se utilizan, por regla general, stubs (maquetas) y, según el caso, controladores de pruebas • El controlador de pruebas constituye o utiliza la interfase abierta del objeto de prueba (componente) • Los controladores de pruebas posibilitan la ejecución de los componentes en el entorno del software • Los controladores de pruebas simulan entradas, p.ej., del usuario • Los controladores de pruebas recogen valores de salida

• Los controladores de pruebas proporcionan normalmente entornos de ejecución de software • Opcionalmente un controlador de pruebas también permite el registro de diferentes valores.

97

III – Las pruebas en el ciclo de vida del software 02.1 – Niveles de prueba. Pruebas de componentes ¿Dónde y como se prueba? • Los controladores de pruebas pueden ser programados por uno mismo si: • Se tiene conocimientos de programación. • El código de programa está disponible. • Se dispone de herramientas de programación. • Los stubs se necesitan cuando los componentes a probar requieren por su parte entradas o deben manipular salidas. Reemplazan o simulan componentes que aún no están disponibles. • Los stubs no contienen a diferencia de los controladores ninguna o una muy pequeña lógica de programación. • Los stubs proporcionan en ocasiones datos de pruebas (Dummies).

98

III – Las pruebas en el ciclo de vida del software 02.1 – Niveles de prueba. Pruebas de componentes ¿Dónde y como se prueba? Relación entre: • Componentes, • Controladores de pruebas,y • Stubs.

Controlador de pruebas

Componente

Datos de prueba

Stub

99

III – Las pruebas en el ciclo de vida del software 02.1 – Niveles de prueba. Pruebas de componentes ¿Porqué se prueba? • Pruebas funcionales • Las pruebas de componentes deben asegurar su funcionalidad: • ¿Se cumplen todas las especificaciones?. • ¿Se ejecutan correctamente todas las funciones?.

• Cada una de las funciones de un componente se comprueba, al menos, con un caso de prueba. • Los errores frecuentes que se pueden encontrar con estas pruebas son: • Errores en la elaboración. • Ausencia de funciones.

100

III – Las pruebas en el ciclo de vida del software 02.1 – Niveles de prueba. Pruebas de componentes ¿Porqué se prueba? • Pruebas de robustez • Se prueba cómo de robusto es un componente. • La robustez describe la capacidad de respuesta de un software frente a entradas incorrectas, etc.

• La robustez se prueba mediante casos de prueba negativos. • Los casos de prueba negativos son casos que contienen datos de entrada incorrectos o no permitidos.

• Si el componente dispone de un tratamiento de excepciones para cada posible entrada de datos errónea, se considera robusto. • Sin el correspondiente tratamiento de excepción los datos erróneos se introducen en el proceso y pueden ocasionar errores. • Las posibles consecuencias son caídas y mal funcionamiento de los componentes

101

III – Las pruebas en el ciclo de vida del software 02.1 – Niveles de prueba. Pruebas de componentes ¿Porqué se prueba? • Otras pruebas posibles • Según los requisitos también deben ser cumplidas otras características de la calidad de software. • Junto a la funcionalidad y la robustez también podrían jugar un papel dentro de las pruebas de componentes otros aspectos como la eficiencia y la capacidad de modificación.

102

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Definiciones y conceptos • Prueba de integración (Definición): Pruebas de la interrelación de los elementos del software (componentes) tras su integración • La integración es el proceso por el cual los elementos básicos del software (componentes) son agrupados en elementos mayores. • Si estos elementos se unen a su vez entre sí, esto también pertenece a la integración.

• Aún cuando los componentes básicos pasen sin error las pruebas de componentes debe comprobarse su funcionalidad externa. • Ello implica pruebas de interoperabilidad entre diferentes componentes de un software

103

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración ¿Qué se prueba? • En las pruebas de integración se comprueba la interoperabilidad entre elementos básicos (grupos de elementos) del software. • Funcionalidad de las interfases. Cada elemento básico debería haber sido comprobado antes de que comience la integración. • Comentario (sobre la psicología de las pruebas): En las pruebas de integración debería tenerse en cuenta que existe la posibilidad de tener que reunir los resultados de diferentes desarrolladores y/o equipos de pruebas.

104

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración ¿Qué se prueba? • En las pruebas de integración se comprueban también las interfases con el entorno del sistema. • En la mayoría de los casos sólo se comprueba el comportamiento de salida de los elementos agrupados frente al comportamiento de entrada simulado del entorno. • Bajo condiciones reales puede haber factores adicionales que afecten al funcionamiento del componente. Las pruebas de integración no pueden por ello garantizar una funcionalidad sin defectos en el entorno real del sistema.

105

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración ¿Donde y cómo se prueba? • Se comprueba un sistema (parte de un sistema) que se compone de componentes individuales. • Cada uno de los componentes tiene una interfase externa o que lleva a otro componente del sistema (sistema parcial). • Se necesitan de nuevo controladores de pruebas (que proporcionan el entorno de ejecución del sistema / subsistema) que: • Produzcan/posibiliten entradas y salidas para el sistema / sub-sistema. • Registren datos. Aquí pueden ser reutilizados los controladores de casos de pruebas utilizados en las pruebas de componentes.

106

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración ¿Donde y cómo se prueba? • En este punto se pueden introducir con sentido monitores que permitan un control de las pruebas mediante la captura de datos. • Los stubs sustituyen a los componentes que faltan: • Los datos/funciones de un componente que no hayan sido integrados se introducen mediante stubs especialmente programados. • Los stubs asumen las tareas elementales de los componentes que falten.

107

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración ¿Por qué se prueba? • Las pruebas de integración persiguen encontrar errores de interfases, se comprueba el correcto funcionamiento conjunto de los componentes (entre otras cosas también con vistas al rendimiento o a la seguridad). • Se efectúan pruebas de integración, entre otros motivos, por motivos de migración (pruebas de conformidad, pruebas de compatibilidad). • Para esto son necesarios otros procedimientos de pruebas.

108

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración ¿Por qué se prueba? • Los errores de interfase no aparecen hasta después de la integración de los elementos básicos: • Si se cambian los controladores de pruebas y los stubs por interfases de componentes “reales” pueden aparecer circunstancialmente errores. • P. ej. se pueden perder ciertos datos, no transmitirse o transmitirse de manera errónea, etc.

• Las pruebas de integración deberían asentarse sobre las pruebas de componentes: • Todos los errores de las pruebas de componentes podrían ser encontrados, en principio, en las pruebas de integración pero sería muy complicado localizarlos. • Probar los componentes en el nivel de integración es confuso. • No todos los casos de prueba pueden siquiera “lanzarse”.

109

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • Existen diferentes alternativas para las estrategias de integración. • Generalmente las estrategias serán establecidas por el gestor/responsable de pruebas. • El modo de proceder incremental es común a todas las estrategias (excepción: Big Bang).

• La elección de la estrategia deberá tener en cuenta la eficiencia de las pruebas • La estrategia de integración decide acerca del esfuerzo de las pruebas (p.ej. utilización de herramientas, programación de controladores de pruebas, stubs etc.) • La terminación de los componentes fija para cada estrategia de integración el marco temporal.

• Sin unos componentes probados no es eficaz una estrategia de integración encaminada a ahorrar esfuerzos.

110

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • En función del proyecto se deberá sopesar entre el ahorro de tiempo y el esfuerzo para las pruebas: • Probar lo que está terminado – eventualmente mayor esfuerzo, por el contrario, no existen periodos de inactividad. • Seguir una estrategia establecida – menor esfuerzo pero, por el contrario, eventualmente, periodos de inactividad.

111

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • Estrategias de integración • Estrategia Bottom-Up: • Se lleva a cabo una integración de abajo a arriba. • Se empieza por aquellos componentes que no llaman a otras partes del programa. • Siguen paso a paso los componentes que sólo llaman a la parte ya integrada. • Se aplica en desarrollos nuevos, pruebas de equipos grandes y distribuidos.

112

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • Estrategias de integración • Características de la estrategia Bottom-Up: • No existen huecos que deban ser completados por stubs. • Los componentes superiores deben ser simulados mediante controladores de pruebas.

• Implantación de la estrategia Bottom-Up: • La implantación de la estrategia sólo es posible para software construido jerárquicamente de manera constante – por ello en su forma pura no tiene apenas relevancia práctica.

113

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • Estrategias de integración • Estrategia Top-Down: • La integración se lleva a cabo sistemáticamente de arriba a abajo. • Se empieza por los componentes que no son llamadas desde otros componentes del software. • Paso a paso se integran aquellos componentes que únicamente son llamados desde la parte ya integrada. • Se aplica cuando se utiliza software ajeno o Frameworks.

114

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • Estrategias de integración • Características de la estrategia Top-Down: • Debido a la forma de proceder no son necesarios controladores de pruebas. • Todos los componentes subordinados deben ser sustituidos por stubs.

• Implantación de la estrategia Top-Down: • La implantación de la estrategia sólo es posible para software construido jerárquicamente de manera continuada – por ello en su forma pura no tiene apenas relevancia práctica.

115

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • Estrategias de integración • Integración orientada al proceso de negocio: • La integración se lleva a cabo por procesos de negocio. • En cada caso se integran los componentes necesarios por parte de un proceso de negocio. • También se denominan como pruebas End-to-End.

• Características de la integración orientada al proceso de negocio: • Los controladores de pruebas sustituyen los componentes de rango superior. • Todos los componentes subordinados de deben sustituir por stubs.

116

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • Estrategias de integración • Integración orientada a funciones: • La integración se orienta a una función del sistema escogida. • Se integra cada uno de los componentes necesitados por la función correspondiente del sistema.

• Características de la integración orientada a funciones: • Los controladores de pruebas sustituyen a los componentes de rango superior. • Todos los componentes subordinados deben ser sustituidos mediante stubs.

117

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • Estrategias de integración • Integración Ad-Hoc: • Los componentes ya probados son integrados – en tanto sea posibleinmediatamente después de su programación y comprobación exitosa.

• Características de la integración Ad-Hoc: • No existen retrasos en las pruebas, por lo que ocasionalmente se puede lograr un acortamiento del proceso completo de desarrollo del software. • Dependiendo del tipo de componente terminado pueden ser necesarios stubs y controladores de pruebas.

• Implantación de la estrategia Ad-Hoc: • La integración Ad-Hoc puede ser empleada en cualquier situación – en la práctica suele ser combinada con otras estrategias.

118

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • Estrategias de integración • Integración no incremental (big bang): • Se integra en el momento en que se dispone de todos los componentes. • Esta estrategia se aplica, p. ej., en proyectos de mantenimiento o ampliación, así como en el marco de migraciones.

• Características de la integración no incremental: • El área de las pruebas tiene mucho “tiempo muerto” – no se puede probar durante largo tiempo. • Las pruebas se hacen más complicadas y más amplias - los efectos de los errores aparecen con frecuencia y son difíciles de rastrear.

119

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Pruebas e integración • ¿Como se pueden coordinar la integración y las pruebas?

La integración debe llevarse a cabo de acuerdo con la arquitectura del sistema y la preparación de los componentes.

Se dispone de una estrategia de integración que sirve también de base para el proceso de pruebas. Determina también el esfuerzo de las pruebas pero depende de la disponibilidad de los componentes.

Las pruebas deben ser eficientes, es decir, encontrar el mayor número de errores graves sin utilizar para ello demasiados recursos.

En la planificación de las pruebas se determinan el tiempo y el resto de recursos para las pruebas – ¡si no se puede probar según el plan aparecen costes adicionales!

En principio el orden de la preparación determina la integración - y de esta manera también el curso de las pruebas . Se debe componer una estrategia que se adapte individualmente. 120

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Generalidades • Diferentes niveles de Pruebas de integración: A parte de las pruebas de integración de componentes, puede haber más niveles de pruebas de integración y, éstas, se pueden llevar a cabo en objetos de prueba de diversos tamaños. Un ejemplo sería: • Pruebas de integración de sistemas: se prueban las interacciones entre diferentes sistemas o entre hardware y software y podría llevarse a cabo después de las pruebas de sistema. En este caso, puede que la organización desarrolladora controle sólo un lado de la interfaz. Esto podría considerarse como un riesgo.

• Fuentes de casos: • Diseño de software y del sistema • Arquitectura • Workflows • Casos de uso

121

III – Las pruebas en el ciclo de vida del software 02.2 – Niveles de prueba. Pruebas de integración Generalidades • Objetos de prueba típicos: • Implementación de bases de datos de subsistemas • Infraestructura • Interfaces • Configuración del sistema • Configuración de datos

122

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Definiciones y conceptos • Pruebas del sistema (Definición): • Comprobación del sistema integrado completo respecto del cumplimiento de los requisitos específicos. • Desde el punto de vista técnico ya se han probado todos los componentes y su interrelación – faltan las pruebas del sistema completo en condiciones de funcionamiento y desde el punto de vista del usuario: • entorno • funciones • carga • …

123

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema ¿Qué se prueba? • Pruebas del sistema integrado desde el punto de vista del usuario • Implantación completa y correcta de los requisitos. • Implantación en el entorno real del sistema y con datos cercanos a la práctica.

• El entorno de pruebas debería corresponderse con el entorno de producción • Se omiten los controladores de pruebas y los stubs. • Todas las interfaces externas del sistema se probarán bajo condiciones de producción. • Recreación lo más exacta posible del entorno posterior de producción.

• Pero: ninguna prueba en el entorno de producción • Los errores surgidos pueden dañar el sistema productivo. • El entorno del sistema está en movimiento - las pruebas no son reproducibles.

124

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema ¿Por qué y como se prueba? • Las pruebas del sistema deben validar el cumplimiento de los requisitos establecidos. • En principio se prueba la calidad del software para el usuario.

• De acuerdo con la calidad de software según (ISO 9126) las pruebas del sistema diferencian entre requisitos: • Funcionales • Funcionalidad

• No funcionales • • • • •

Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad

125

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Requisitos funcionales • Cuestión: ¿Las características requeridas quedan implementadas por las funciones disponibles? • El sistema debe ser probado en los siguientes puntos: • Idoneidad • ¿Son adecuadas las funciones disponibles para la utilización prevista?

• Precisión • ¿Se ejecutan las funciones correctamente (como estaba acordado)?

• interoperabilidad • ¿Se proporciona una interrelación libre de errores con el entorno del sistema?

• Conformidad • ¿Se cumplieron las normas y preceptos?

• Seguridad • ¿Están protegidos los datos /programas frente a accesos/pérdidas?

126

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Requisitos funcionales • Las pruebas de los requisitos funcionales pueden incluir: • Pruebas basadas en riesgos y/o especificaciones de requisitos: • Los casos de prueba se deducen a partir de la definición de requisitos. • El número de casos de prueba varía en función de los requisitos.

• Pruebas basadas en procesos de negocio: • Los procesos de negocio individuales sirven como base para la creación de los casos de prueba. • Se puede trasladar la importancia de los procesos a la priorización de casos de prueba.

• Pruebas basadas en casos de uso: • Los casos de prueba se deducen a partir de los casos de uso – procesos habituales del usuario. • Aquellos casos de uso más frecuentes tendrán mayor prioridad en las pruebas.

• Cualquier otra descripción de alto nivel del comportamiento del sistema. 127

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Requisitos no funcionales (Eficiencia, fiabilidad, usabilidad, mantenibilidad, portabilidad) • Los requisitos no funcionales vienen especificados, entre otras, en la norma ISO 9126. • Junto a aspectos como rendimiento o seguridad, la ergonomía (usabilidad) representa un importante requisito no funcional. • Los requisitos de ergonomía vienen descritos en la norma ISO 9241, sobre todo en el capítulo 10, p.ej., tolerancia a fallos, facilidad de aprendizaje y adecuación a las tareas.

128

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Requisitos no funcionales • El cumplimiento de estos requisitos es igual de importante pero a menudo difícil de probar y por ello están sometidos a un mayor riesgo. • En la definición de requisitos no esta siempre claro “como de bien” debe funcionar algo: • A menudo definiciones vagas (manejar sin problemas, pantallas claras, etc.). • Los requisitos no funcionales se dan a menudo de manera implícita y por este motivo no se definen.

129

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Requisitos no funcionales • La prueba de un requisito no funcional se da como superada si se consigue un determinado valor en una métrica establecida: • P.ej., métrica para la fiabilidad del software: • MTBF – Mean Time Between Failure/Tiempo medio entre fallos • MTTR – Mean Time To Repair/Tiempo medio de reparación

• De todos modos suele ser difícil una cuantificación de los requisitos no funcionales.

130

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Requisitos no funcionales • Pruebas de carga. • ¿Cómo se comporta el sistema bajo condiciones de carga nominales (número creciente de usuarios/acciones)?

• Pruebas de rendimiento. • ¿Cómo de rápido es el sistema en determinadas funciones/casos de uso?

• Pruebas de volumen / Pruebas masivas. • ¿Como se comporta el sistema al procesar grandes cantidades de conjuntos de datos/archivos?

• Pruebas de estrés • ¿Como reacciona el sistema con sobrecarga? • ¿Como reacciona el sistema al regresar al modo de funcionamiento normal?

131

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Requisitos no funcionales • Pruebas de seguridad (- de datos). • ¿Está protegido el sistema frente a accesos no autorizados?. • ¿Están protegidos los datos frente a accesos no autorizados o pérdidas?.

• Pruebas de estabilidad. • ¿Con qué frecuencia se cae el sistema por unidad de tiempo determinada?. • Comportamiento del sistema en funcionamiento prolongado.

• Pruebas de robustez. • ¿Cómo reacciona el sistema frente a una utilización incorrecta o frente a errores de entrada (manejo de excepciones)?. • Comportamiento de sistema frente a defectos de hardware y el regreso al funcionamiento normal.

132

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Requisitos no funcionales • Pruebas de compatibilidad (Conversión de datos) • ¿Cómo trabaja el sistema junto con otros programas? • ¿Qué interfases existen hacia otros programas? • ¿Cómo reacciona el sistema en diferentes entornos (Hardware, S.S.O.O., etc.)?

• Pruebas de idoneidad de uso (usabilidad) • ¿Cómo de visible y comprensible es el sistema? • ¿Con qué facilidad puede aprender su manejo el usuario típico?

133

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Requisitos no funcionales • Comprobación de la documentación • ¿Concuerda la documentación del programa con el sistema real? • ¿La documentación se ha escrito de manera clara y comprensible?

• Comprobación de la mantenibilidad • ¿Se dispone de documentos adecuados acerca del desarrollo del sistema? • ¿Se han cumplido los estándares de código preestablecidos? • ¿Tiene el sistema una arquitectura estructurada (modular)?

134

III – Las pruebas en el ciclo de vida del software 02.3 – Niveles de prueba. Pruebas de sistema Generalidades • Fuentes de casos: • Especificación de requisitos del software y del sistema • Casos de uso • Especificación funcional • Informes de análisis de riesgos

• Objetos de prueba típicos: • Manuales de usuario, del sistema y de operación • Configuración del sistema • Configuración de datos

135

III – Las pruebas en el ciclo de vida del software 02.4 – Niveles de prueba. Pruebas de aceptación Definiciones y conceptos • Pruebas de aceptación (Definición): Las pruebas de aceptación comprueban el producto desde el punto de vista del usuario o del cliente antes de su paso a producción – ¿Se cumplen las expectativas del usuario/cliente? • El usuario/cliente está involucrado, dependiendo del grado, en la personalización del software • El software personalizado suele ser probado a menudo directamente por el solicitante/cliente • Para productos “de masas” se involucra a una selección representativa de usuarios en las pruebas

136

III – Las pruebas en el ciclo de vida del software 02.4 – Niveles de prueba. Pruebas de aceptación Posibles formas de las pruebas de aceptación • Pruebas de aceptación contratada • La aceptación en sí del producto por parte del cliente – el cliente comprueba si el producto cumple con los requisitos contratados • Primeras pruebas en las que el cliente debe estar involucrado activamente (en todo caso es aconsejable involucrar al cliente en las pruebas ya durante la fase de desarrollo de prototipos). • Se rige por criterios de aceptación acordados por contrato • Suelen estar cubiertas por el fabricante ya con las pruebas del sistema

137

III – Las pruebas en el ciclo de vida del software 02.4 – Niveles de prueba. Pruebas de aceptación Posibles formas de las pruebas de aceptación • Pruebas de aceptación contratada • El cliente determina los casos de prueba para las pruebas de aceptación. • Posibles mal interpretaciones de los requisitos pueden ser eliminadas – “solo el cliente sabe lo que realmente quiere”.

• Las pruebas se hacen en el entorno del cliente. • En ocasiones son posibles efectos de errores debido al entorno del cliente – eventualmente ha podido ser modificado desde el comienzo del proyecto.

138

III – Las pruebas en el ciclo de vida del software 02.4 – Niveles de prueba. Pruebas de aceptación Posibles formas de las pruebas de aceptación • Pruebas de aceptación del usuario • ¿Se acepta el software por parte de los usuarios últimos? • Se comprueba si es posible ya durante el desarrollo (p.ej., mediante prototipos)

• Se comprueba si el software • Cumple las expectativas de diferentes usuarios • Deja una impresión positiva en el usuario • Muestra errores graves, que reducen la aceptación por parte del usuario

139

III – Las pruebas en el ciclo de vida del software 02.4 – Niveles de prueba. Pruebas de aceptación Posibles formas de las pruebas de aceptación • Pruebas de aceptación del usuario • Las pruebas de aceptación deben realizarse en función de la personalización del software. • En la personalización de software específica para un cliente deben ser cumplidos obligatoriamente los requisitos de los grupos de usuarios especiales. • Para el software estándar suele ser normalmente difícil conseguir una aceptación general debido al gran número de grupos de usuarios

140

III – Las pruebas en el ciclo de vida del software 02.4 – Niveles de prueba. Pruebas de aceptación Posibles formas de las pruebas de aceptación • Pruebas de aceptación operacional • Aceptación del sistema por parte de los Administradores. Incluyen: • Pruebas de backup/restore • Recuperación de desastres • Gestión de usuarios • Tareas de mantenimiento • Tareas de carga y migración de datos • Comprobación periódica de vulnerabilidades de seguridad

141

III – Las pruebas en el ciclo de vida del software 02.4 – Niveles de prueba. Pruebas de aceptación Posibles formas de las pruebas de aceptación • Pruebas de campo (alfa y beta) • Distribución anticipada de versiones estables del software (versiones beta) a una selección representativa del círculo de clientes • Los clientes prueban en sus respectivos entornos de producción y documentan los efectos de los errores, etc. • Pruebas en escenarios predeterminados o implantación de versiones beta en el entorno normal del usuario

• Alternativamente primero pruebas a nivel alfa de una versión previa (versión alfa) • Usuarios representativos del entorno del productor llevan a cabo estas pruebas.

142

III – Las pruebas en el ciclo de vida del software 02.4 – Niveles de prueba. Pruebas de aceptación Posibles formas de las pruebas de aceptación • Pruebas de campo (alfa y beta) • Las pruebas de campo deben asegurar más allá de las pruebas del sistema, que el software se puede ejecutar en un gran número de entornos diferentes. • La utilización de pruebas de campo • Reduce el esfuerzo de las pruebas del sistema y • Posibilita pruebas de mayor alcance (posibilidad de pruebas en entornos diferentes, etc.).

143

III – Las pruebas en el ciclo de vida del software 02.4 – Niveles de prueba. Pruebas de aceptación Generalidades • Fuentes de casos: • Requisitos de usuario • Requisitos de sistema • Casos de uso • Procesos de negocio • Informes de análisis de riesgos

• Objetos de prueba típicos: • Procesos de negocio en el sistema integrado completo • Procesos operacionales y de mantenimiento • Procedimientos de usuario • Formularios • Informes • Configuración de datos

144

III – Las pruebas en el ciclo de vida del software 03 – Tipos de prueba Tipos de prueba •

Puede haber grupos de actividades de prueba encaminados a la verificación del software de un sistema (o de parte de un sistema) que estén basadas en una razón u objetivo de prueba determinados.

•

Cada tipo de prueba se centra en un objetivo de prueba en particular, como la prueba de una función que tiene que realizar el software, una característica de calidad no funcional como fiabilidad o usabilidad, la estructura o arquitectura del software o del sistema; o relacionado con cambios, esto es, confirmar que se han corregido los defectos (pruebas de confirmación) y buscar cambios no intencionados (pruebas de regresión).

•

Se puede elaborar un modelo de software y/o utilizarlo en las pruebas estructurales (ej.: un modelo de flujo de control o un modelo de estructura de menús); en las pruebas no funcionales (ej.: modelo de usabilidad); y, en las pruebas funcionales (ej.: un modelo de flujo de procesos, un modelo de transición de estados o una especificación en lenguaje sencillo)

145

III – Las pruebas en el ciclo de vida del software 03.1 – Tipos de prueba Pruebas funcionales •

•

•

•

Las funciones que tiene que realizar un sistema, subsistema o componente pueden ser descritas en productos de trabajo, como una especificación de requisitos, casos de uso, o una especificación funcional, o bien pueden quedar indocumentados. Las funciones son “qué” hace el sistema. Las pruebas funcionales se basan en funciones y rasgos (descritos en documentos o sobreentendidos por los probadores) y en su interoperabilidad con sistemas específicos, y pueden llevarse a cabo en todos los niveles de prueba (por ejemplo, las pruebas de componentes pueden basarse en la especificación del componente). Pueden usarse técnicas basadas en especificaciones para obtener casos de prueba a partir de la funcionalidad del software o del sistema (véase Capítulo 5). Las pruebas funcionales toman en consideración el comportamiento externo del software (pruebas de caja negra). Existe un tipo de prueba funcional, la prueba de seguridad que investiga las funciones (por ejemplo, un cortafuegos) relativas a la detección de amenazas, como virus, de intrusos maliciosos. Otro tipo de prueba funcional, la prueba de interoperabilidad, evalúa la capacidad del producto software para interactuar con uno o varios componentes o sistemas específicos. 146

III – Las pruebas en el ciclo de vida del software 03.2 – Tipos de prueba Pruebas no funcionales •

Las pruebas no funcionales incluyen, pero no están limitadas a, pruebas de prestaciones, de carga, de estrés, de usabilidad, de mantenibilidad, de fiabilidad y de portabilidad. Son las pruebas de “cómo” trabaja el sistema.

•

Pueden realizarse pruebas no funcionales en todos los niveles de prueba. El término prueba no funcional describe las pruebas necesarias para medir características de sistemas y de software que pueden cuantificarse según una escala variable, como pueden ser los tiempos de respuesta en las pruebas de prestaciones. Estas pruebas pueden hacer referencia a un modelo de calidad como el definido en ‘Software Engineering – Software Product Quality’ (ISO 9126).

147

III – Las pruebas en el ciclo de vida del software 03.3 – Tipos de prueba Pruebas de la Estructura/Arquitectura del software (estructurales) •

•

•

•

Las pruebas estructurales (de caja blanca) pueden llevarse a cabo en todos los niveles de prueba. Es mejor usarlas después de las técnicas basadas en especificación, ayuda a medir con rigurosidad las pruebas, mediante la evaluación de la cobertura de un tipo de estructura. La cobertura mide el grado con el que una suite de pruebas ha utilizado una estructura. Si la cobertura no es del 100%, pueden diseñarse más pruebas, para comprobar los elementos que se han pasado por alto y, por consiguiente, incrementar la cobertura. Las técnicas de cobertura se tratan posteriormente. En todos los niveles de prueba, pero especialmente en las pruebas de componentes y en las de integración de componentes, se pueden utilizar herramientas para medir la cobertura de código de elementos como sentencias o decisiones. Las pruebas estructurales pueden basarse en la arquitectura del sistema, como la jerarquía de llamadas. Los enfoques de prueba estructural pueden aplicarse también en los niveles de prueba de sistema, integración de sistemas o aceptación (por ejemplo, para los modelos de negocio o las estructuras de menús). 148

III – Las pruebas en el ciclo de vida del software 03.4 – Tipos de prueba Pruebas después de la aceptación • El cliente ha aceptado el producto y lo ha llevado a producción • Las fases propias del desarrollo y las pruebas relacionadas han finalizado. • El software mismo está sin embargo al comienzo de su vida • A menudo se implanta para muchos años y se sigue desarrollando. • Seguro que sigue conteniendo errores y por ello se sigue trabajando sobre él. • Debe ser adaptado a nuevas condiciones o integrado en un nuevo entorno. • ¡Cada nueva versión del producto, cada nueva actualización y cualquier otro tipo de cambio debe ser probado de nuevo!

149

III – Las pruebas en el ciclo de vida del software 03.4 – Tipos de prueba Pruebas después de la aceptación Pruebas relativas a los cambios (Confirmación o re-prueba y regresión) • Después de que se haya detectado y corregido un defecto, se debería volver a probar el software par confirmar que el defecto original se ha eliminado con éxito. A esto se le llama confirmación. La depuración (eliminación de defectos) es una actividad de desarrollo, no de pruebas. • Las pruebas de regresión consisten en la prueba repetida de un programa ya probado, tras su modificación, para descubrir cualquier defecto introducido o descubierto como resultado de uno o varios cambios. Estos defectos pueden estar, bien en el software que se está probando o en otro componente software relacionado o no relacionado. Se lleva a cabo cuando se cambia el software o su entorno. La extensión de las pruebas de regresión viene dada por el riesgo de no encontrar defectos en el software que estaba funcionando. • Las pruebas deberían ser repetibles si van a utilizarse como pruebas de confirmación y para ayudar a las pruebas de regresión • Las pruebas de regresión pueden hacerse en todos los niveles de prueba y se aplican tanto a pruebas funcionales como a no funcionales y estructurales. Los paquetes de pruebas de regresión se lanzan muchas veces y suelen evolucionar lentamente, por lo que son fuertes candidatos a la automatización.

150

III – Las pruebas en el ciclo de vida del software 04 – Pruebas de mantenimiento Pruebas después de la aceptación • Mantenimiento de software (Correctivo y adaptativo) • El mantenimiento de software distingue dos tipos de actividades • El propio mantenimiento: eliminación de errores que ya existen desde el desarrollo del software • Cuidado del software: adaptación del software a condiciones de implantación modificadas

• Pruebas de las modificaciones y eventualmente errores debido a las mismas • Continuación del desarrollo del software (Evolutivo) • La continuación del desarrollo abarca medidas que se salen del mantenimiento (continuación planificada del desarrollo) • Ampliación de las interfases • Ampliación de funciones

• Aquí se vuelve a recorrer otra vez el modelo de desarrollo

151

III – Las pruebas en el ciclo de vida del software 04 – Pruebas de mantenimiento Pruebas después de la aceptación • ¿Cómo se prueban las modificaciones en el software? • Pruebas de regresión Pruebas de un sistema que ya ha sido comprobado por si, debido a las modificaciones, surgen nuevos errores (p.ej., después de la corrección de errores). • Comentario: Las pruebas de regresión son necesarias y se aplican ya antes de la aceptación del producto.

152

III – Las pruebas en el ciclo de vida del software 04 – Pruebas de mantenimiento Pruebas después de la aceptación • En función del alcance de las pruebas de regresión se distingue entre: • Repetición de la prueba del error (también llamado Retest) • Repetir la ejecución de los casos de prueba que han descubierto errores para comprobar que fueron eliminados. • Las repeticiones de las pruebas son, de esta manera, una parte de las pruebas de regresión

• Pruebas de la funcionalidad modificada • Pruebas de todas las partes del software que han sido modificadas

• Pruebas de nuevas funcionalidades • Pruebas completas de las nuevas partes del programa • Estas han sido previamente comprobados como componentes etc.

• Pruebas de regresión completas • Las pruebas del sistema se ejecutan/repiten de nuevo

153

III – Las pruebas en el ciclo de vida del software 04 – Pruebas de mantenimiento Pruebas después de la aceptación • El software reacciona a menudo frente a los cambios en lugares en los que no se realizo ninguna modificación. • Alcance de las pruebas de regresión: • La repetición de las pruebas de la parte que generó el error no son suficientes por si mismas para comprobar una modificación. • Tampoco las pruebas exclusivamente de funciones nuevas o modificadas serían apropiadas en este contexto. • Unas pruebas completas de regresión serían una posible solución pero en la práctica necesitan mucho tiempo y generan muchos costes.

• Una combinación de pruebas de las partes modificadas (repetición de pruebas de error) y una selección de las pruebas del sistema (p.ej., en función de la priorización de las funciones a comprobar) es lo que mejor se adapta a los requisitos.

154

III – Las pruebas en el ciclo de vida del software 05 – Resumen Afirmaciones importantes del capítulo • Fases de pruebas establecidas según el “modelo genérico en V” • Diferenciación entre validación y verificación • La unidad de prueba mas pequeña para los elementos constituyentes del software es la prueba de componentes • Las pruebas de integración comprueban la interrelación entre estos elementos • Diferentes estrategias para la integración • El sistema completo se prueba mediante pruebas funcionales y no funcionales • Prueba de regresión = prueba de un software ya comprobado • Las pruebas de mantenimiento se llevan a cabo en programas pasados a producción

155

156

Capítulo IV – Técnicas estáticas • IV/01 Las técnicas estáticas y el proceso de prueba • IV/02 Proceso de revisión • IV/03 Análisis estático (Mediante herramientas) • IV/04 Resumen

157

IV – Técnicas estáticas 01 – Las técnicas estáticas y el proceso de prueba Conceptos generales • El término “técnicas estáticas”, “pruebas estáticas” o –frecuentemente también- “análisis estático” engloba procedimientos que adoptan • Análisis manual del objeto de prueba (leer, etc.) o • Análisis del objeto de prueba respaldado por herramientas sin ejecutar el objeto de prueba

• Se prescinde de los datos de prueba (necesarios en las pruebas dinámicas). • Los errores pueden ser descubiertos directamente con las pruebas estáticas (no únicamente en base a sus efectos) • El objetivo de las pruebas estáticas es encontrar errores / incidencias en las especificaciones mismas antes de que se implementen (totalmente). • Corregir especificaciones o supuestos y evitar errores en el software • Descubrir y eliminar los puntos débiles del proceso

158

IV – Técnicas estáticas 01 – Las técnicas estáticas y el proceso de prueba Conceptos generales • Beneficios: • • • • • • •

Detección y corrección temprana de defectos Mejora de la productividad del desarrollo Tiempos de desarrollo reducidos Mejores costes y tiempos de prueba Reducciones en el coste durante su tiempo de vida Menos defectos Mejora en las comunicaciones.

• Las revisiones pueden encontrar omisiones, por ejemplo, en los requisitos, algo que no se puede encontrar durante las pruebas dinámicas. • Tanto las revisiones como el análisis estático y las pruebas dinámicas tienen el mismo objetivo - identificar defectos. Son complementarias: diferentes técnicas pueden encontrar distintos tipos de defectos de forma efectiva y eficiente. • Entre los defectos típicos que son más fáciles de encontrar en las revisiones que en las pruebas dinámicas, se encuentran: desviaciones de los estándares, defectos en los requisitos o en el diseño, mantenibilidad insuficiente y especificaciones de interfaz incorrectas. 159

IV – Técnicas estáticas 02 – Proceso de revisión Conceptos y definiciones • Pruebas en grupo estructuradas (definición) : Las pruebas en grupo estructuradas son aquellos procedimientos de prueba en los que, sin apoyarse en una herramienta, sólo se aplican las cualidades humanas de “pensar” y “analizar”. • Se buscan errores en la documentación / objetos de prueba (en ocasiones con un enfoque determinado, p.ej., estilo de código) mediante un trabajo intensivo (leer, deducir, investigar) • Los procedimientos se agrupan bajo el termino revisión (también inspección). • La revisión y la inspección son a la vez tipos concretos de pruebas en grupo estructuradas

El siguiente apartado se orienta según los conceptos del plan de formación ASQF/ISTQB V2.2 y según IEEE1028

160

IV – Técnicas estáticas 02 – Proceso de revisión Objetivos de una revisión • Las revisiones deben mejorar el proceso de desarrollo y asegurar la calidad del producto • Las verificaciones en la rama izquierda del modelo en V – es decir, la correcta implementación de los requisitos de una etapa a otra – se llevan a cabo, p.ej., mediante revisiones. • Una calidad alta en la documentación (en toda la documentación) mejora obligatoriamente la calidad del producto • Si no hay errores en las especificaciones/requisitos no se pueden implementar errores. • Se pueden ahorrar costes • Si se corrigen errores de manera temprana se ahorrarán costes en el proceso de desarrollo posterior.

161

IV – Técnicas estáticas 02 – Proceso de revisión Ventajas e inconvenientes de la revisión • Ventajas • Documentación limpia • Bajos costes en comparación al alto potencial de ahorro • Desarrollo mejorado del producto mediante una documentación sin errores • Menos esfuerzo de pruebas durante el ciclo de vida del software • Aumento de la comunicación como consecuencia de las revisiones • Intercambio de ideas / intercambio de Know-how

162

IV – Técnicas estáticas 02 – Proceso de revisión Ventajas e inconvenientes de la revisión • Inconvenientes • Se pueden originar tensiones en el caso de que el autor sea tratado o atacado personalmente. • Expertos en la materia deben formarse como supervisores. • Se necesita tiempo libre para esta actividad. • Una mala preparación disminuye el éxito. • La calidad del moderador y de los participantes en la revisión determina en gran medida el resultado. • Si el moderador no consigue mantener la revisión en un plano técnico se reduce el éxito.

163

IV – Técnicas estáticas 02.1 – Proceso de revisión Fases de una revisión • Todos los tipos de revisiones se basan en una división común en fases • Planificación • Organización de la revisión (p.ej., por el moderador) • Planificación de plazos (p.ej., por el moderador) y de recursos (por regla general por el gestor) • Elección de los participantes y asignación de roles (por regla general por el gestor) • Selección de los objetos de prueba • Definición de los criterios de entrada y salida para revisiones más formales (ej.: inspecciones)

• Preparación organizativa • En su caso se citan todos los participantes para una reunión previa (Reunión de Kick off) • Distribución de los objetos de prueba • Distribución de toda la documentación relevante para la evaluación • Acuerdo de los criterios de prueba (ej: checklists), reparto de tareas, objetivos, procesos • Comprobación de los criterios de entrada (para revisiones más formales) 164

IV – Técnicas estáticas 02.1 – Proceso de revisión Fases de una revisión • Preparación individual • Preparación de los participantes para la reunión de revisión (revisando la documentación) • Los supervisores deben ocuparse intensivamente con la documentación/ objetos de prueba • Se determinan las carencias del objeto de revisión a comprobar • Se anotan los posibles defectos, preguntas y comentarios.

• Reunión de revisión • Encuentro de los participantes para la revisión (¡por regla general, sin el gestor!) Bajo la dirección del moderador, cada supervisor expone sus resultados. • Exposición objetiva y técnica de los aspectos a comprobar • Se anotan los defectos, tomando decisiones sobre los mismos • No se ataca al autor, ni éste debe pretender defender su trabajo • Los errores de ponderan y se consideran para una modificación posterior. La ausencia de errores se menciona también expresamente 165

IV – Técnicas estáticas 02.1 – Proceso de revisión Fases de una revisión • Retrabajo • La corrección de los defectos encontrados suele quedar en manos del autor

• Seguimiento (Follow-up) • El gestor recibe el protocolo de la reunión con los siguientes contenidos • Objeto de prueba y documentos de comparación • Participantes y asignación de roles • Resultados para el objeto de prueba • Afirmaciones/Recomendaciones de los supervisores • Decisión del gestor sobre la aceptación del documento • Seguir (o no) las recomendaciones. Se deberá hacer un seguimiento posterior para asegurarse (en su caso) de que se han seguido las recomendaciones • Eventualmente sigue una “reunión “posterior“ – 2ª. Revisión 166

IV – Técnicas estáticas 02.1 – Proceso de revisión Fases de una revisión • Seguimiento (follow up) • Se generarán métricas y se comprobará (en el caso de las revisiones más formales) si se han cumplido los criterios de finalización. • Se pueden extraer de los errores encontrados referencias sobre déficits generales en el proceso de desarrollo • Los resultados de la reunión no deberán ser empleados para adoptar medidas disciplinarias. Los resultados no se deben hacer por ello públicos con demasiado detalle.

167

IV – Técnicas estáticas 02.2 – Proceso de revisión Roles y responsabilidades • A los participantes en una revisión se les asignan diferentes roles y tareas o bien, se deben cubrir diferentes roles: • Gestor • Inicia la revisión y planifica en su caso su desarrollo, define participantes y distribuye recursos

• Moderador • Es neutral respecto del objeto de prueba y dirige la revisión • Dirige la discusión (enfocado a los objetivos) • Modera entre los diferentes puntos de vista

¡De la calidad del moderador depende principalmente el éxito de la revisión!

168

IV – Técnicas estáticas 02.2 – Proceso de revisión Roles y responsabilidades • Autor • Elaborador o representante del elaborador del objeto de prueba • Si se establece una crítica, es al objeto de prueba – ¡no debe ser criticado personalmente! • Asume finalmente las modificaciones requeridas

• Documentador • Documenta la revisión • Prepara una lista de todas las consideraciones realizadas y de todos los errores reconocidos

• Supervisor (también revisor o inspector) • Expertos en la materia que participan en una revisión – por regla general pueden participar hasta cinco supervisores en la revisión • Reciben previamente el objeto de prueba y trabajan sobre él • Descubren errores, plantean problemas, etc. • Tienen, idealmente, el enfoque de un supervisor acerca de aspectos especiales • Indican qué partes del objeto de prueba deben ser corregidas y cuales pueden mantenerse sin modificaciones

169

IV – Técnicas estáticas 02.3 – Proceso de revisión Tipos de revisión (IEEE 1028) • El proceso fundamental de la revisión –tal y como se ha descrito aquí– se puede dividir a su vez en diferentes modalidades de revisiones • Algunas de estas modalidades se diferencian en algunos aspectos del procedimiento general descrito • La diferenciación general de la revisión viene determinada por la clase de objeto de prueba a tratar • El proceso de desarrollo de software o el curso del proyecto se analiza y se hace un dictamen • Esto también se refiere a revisiones de gestión (estas revisiones no influyen directamente en el proceso de pruebas y no se tratan más dentro de este seminario)

• La documentación / los productos del proceso de desarrollo se analizan y se someten a dictamen • Revisión en el sentido de este apartado

170

IV – Técnicas estáticas 02.3 – Proceso de revisión Tipos de revisión (IEEE 1028) • Inspección: Desarrollo • Modo de proceder altamente formal con un reparto claro de roles. • Preparación previa a la reunión. • Previamente se establece la capacidad de que el objeto de prueba pueda ser revisado. El objetivo es encontrar defectos. • Los supervisores comprueban el objeto de prueba siguiendo criterios establecidos (reglas, listas de chequeo). Es frecuente que sea una revisión entre iguales (peer review). • Se necesita un moderador independiente (no el autor) para la reunión. • Las entradas y salidas están establecidas. Se genera un informe de inspección y una lista de hallazgos. • Proceso de seguimiento formal. • Incluye métricas. 171

IV – Técnicas estáticas 02.3 – Proceso de revisión Tipos de revisión (IEEE 1028) • Inspección: ventajas e inconvenientes • Reunión que se desarrolla con una buena organización • Gran esfuerzo para la preparación y la elaboración posterior • Se precisa de un moderador y un encargado de documentar la reunión • Es posible una búsqueda de errores estructurada

172

IV – Técnicas estáticas 02.3 – Proceso de revisión Tipos de revisión (IEEE 1028) • Walkthrough: desarrollo • En este tipo de revisiones se distribuye previamente a lo sumo la documentación. Puede haber una preparación previa a la reunión de revisión. • El propio autor presenta el objeto de prueba en una reunión y suele liderarla. Suele haber un documentador distinto del autor. Informe de revisión y lista de hallazgos • Durante la presentación del objeto de prueba por parte del autor, los supervisores intentan descubrir errores o problemas. Es frecuente que sea una revisión entre iguales (peer review) • Puede variar desde bastante informal a muy formal • Sesiones abiertas / de duración indefinida (open-ended) • Propósitos: aprender, ganar conocimiento y encontrar defectos • Ejemplos para la utilización de Walkthroughs • Walkthrough de documentación • Walkthrough de propuestas para GUI • Walkthrough de procesos de negocio 173

IV – Técnicas estáticas 02.3 – Proceso de revisión Tipos de revisión (IEEE 1028) • Walkthrough: Ventajas e inconvenientes • Menor esfuerzo en la preparación – por contra en ocasiones reuniones más larga • La reunión se puede iniciar a corto plazo • El autor tiene mucha influencia (precisamente como director de la reunión) – se corre el peligro de no discutir suficientemente acerca de puntos críticos. • No hay control, ya que el autor es el encargado de la elaboración posterior

174

IV – Técnicas estáticas 02.3 – Proceso de revisión Tipos de revisión (IEEE 1028) • Revisión técnica: desarrollo • Comprobación de los aspectos técnicos del objeto de prueba • Suelen participar expertos en la materia, si es posible expertos externos al proyecto. Pueden participar también iguales o ser enteramente una reunión entre iguales (peer review) • La reunión se desarrolla sin el autor. Suele haber moderador • Comprobación sólo en base a los requisitos y al patrón de pruebas • Se hace un dictamen unánime de la valoración global. Opcionalmente, uso de listas de comprobación, informe de revisión, lista de hallazgos, participación de los gestores • Preparación previa a la reunión • Puede variar desde bastante informal a muy formal • Propósito: discutir, tomar decisiones, evaluar alternativas, encontrar defectos, resolver problemas y comprobar conformidad (con especificaciones, planes, normas y estándares)

175

IV – Técnicas estáticas 02.3 – Proceso de revisión Tipos de revisión (IEEE 1028) • Revisión técnica: ventajas e inconvenientes • Aumento de la comunicación • Muy eficiente si el personal es adecuado (y los procedimientos correctos) • Se requiere disponer de personal experto (con tiempo disponible, lo que no siempre es fácil) • Gran esfuerzo para la preparación y la elaboración posterior • Se precisa de un moderador y un encargado de documentar la reunión • Es posible una búsqueda de errores estructurada

176

IV – Técnicas estáticas 02.3 – Proceso de revisión Tipos de revisión (IEEE 1028) • Revisión informal: desarrollo • La variante más simple de las revisiones • A menudo iniciada por el autor • Solo es necesaria la elección de los supervisores • No se requiere una reunión de revisión • Los resultados suelen transmitirse en forma de lista. Puede (o no) documentarse • Su utilidad depende mucho del revisor • A menudo en forma de lectura mutua de los objetos de prueba de entre colegas • Objetivo: Forma barata de obtener (algún) beneficio

177

IV – Técnicas estáticas 02.3 – Proceso de revisión Tipos de revisión (IEEE 1028) • Revisión informal: Ventajas e inconvenientes • Se organizan y desarrollan rápidamente • Coste bajo • No suele haber documentación

178

IV – Técnicas estáticas 02.4 – Proceso de revisión Factores de éxito en las revisiones • •

Es necesario que haya un líder a nivel de proyecto o de organización. Su autoridad debe ser reconocida por el resto de participantes (soporte de la Dirección) Hay que tener claras las ideas: • • • •

• •

Cada revisión tiene un objetivo predefinido claro Se involucra a la gente correcta desde el punto de vista de los objetivos de la revisión Se han de identificar los documentos más importantes para el proyecto. Tiene que haber un ROI claro. NO se debe revisar todo (las revisiones son costosas) Se aplican técnicas de revisión apropiadas al tipo y nivel de los productos software y de los revisores

Hay que planificar y hacer seguimiento de las actividades asociadas a la revisión (por ejemplo, reservar en los calendarios de proyecto un tiempo adecuado para las actividades de revisión). Puede ser necesario formar a los participantes en técnicas de revisión, especialmente en las más formales, como es la inspección

179

IV – Técnicas estáticas 02.4 – Proceso de revisión. Factores de éxito en las revisiones • •

Los probadores son revisores valorados, que contribuyen a la revisión y aprenden sobre el producto para poder preparar las pruebas más pronto. Hay que considerar los aspectos personales de las revisiones • • •

•

Facilitar el trabajo: • •

• • •

Los defectos encontrados son bienvenidos y se expresan de forma objetiva Se consideran los aspectos psicológicos y personales (por ejemplo, hacer que sean experiencias positivas para el autor) Estos aspectos han de ser considerados cuando se está dando la formación previa a la revisión Ser formal cuando sea necesario. No entrar a niveles de detalle demasiado altos o demasiado teóricos si no es necesario Utilizar listas de comprobación (checklists) o incorporar roles cuando ayude a incrementar la efectividad o la identificación de defectos

Cuidar la presentación de los resultados. Debe ser clara, concisa, objetiva y no herir susceptibilidades si no es necesario Hacer hincapié en la mejora continua del proceso, los participantes y las herramientas La revisión se realiza en un ambiente de confianza; el resultado no será utilizado para evaluar a los participantes 180

IV – Técnicas estáticas 03 – Análisis estático Conceptos y definiciones • Análisis, por lo general apoyado en herramientas, para la comprobación de los errores en un objeto de prueba, como documentos o código de programa sin llegar a ejecutarlo. • Los aspectos que pueden / suelen comprobarse con esta técnica son: • Directrices de programación y estándares • Construcción del programa (análisis del flujo de control) • Utilización de datos (análisis del flujo de datos) • Complejidad de la estructura del programa (Métricas – p.ej., complejidad ciclomática)

181

IV – Técnicas estáticas 03 – Análisis estático Generalidades • Todos los objetos de prueba deben tener una estructura formal. • Inevitable debido al empleo de herramientas • En el caso de documentos no se da con frecuencia • Las análisis estáticos se pueden desarrollar con poco esfuerzo en comparación con las revisiones, gracias a la implantación de herramientas. • Por eso se lleva a cabo frecuentemente un análisis estático antes de llevar a cabo la revisión.

182

IV – Técnicas estáticas 03 – Análisis estático Generalidades • Como herramientas se utilizan compiladores o analizadores • Compilador • Descubren errores de sintaxis en el lenguaje de programación • Proporcionan comprobantes del uso de las partes del programa (listas de referencias cruzadas) • Comprueban la utilización correcta de los tipos de variables • Encuentran variables no declaradas y código inaccesible (p.ej., el compilador de Java)

• Los analizadores se refieren más a aspectos como • Convenciones y • Estándares.

183

IV – Técnicas estáticas 03 – Análisis estático Análisis del flujo de control • Objetivo • Encontrar errores dentro de la construcción del programa (ramas muertas / código muerto etc.) • Procedimiento • Representación del código en forma de •

gráfico de flujo de control

• Gráfico orientado

?

• Sentencias del programa / secuencias como nodos • Decisiones / Bucles como aristas • Se crean generalmente mediante una herramienta

184

IV – Técnicas estáticas 03 – Análisis estático Análisis del flujo de control • Resultado • Representación visible del código del programa • Las anomalías se encuentran con facilidad y se pueden comprobar sus fallos • Salidas/saltos de bucles • Ramas muertas

?

185

IV – Técnicas estáticas 03 – Análisis estático Análisis del flujo de datos • Objetivo: Descubrir anomalías en el flujo de datos con ayuda del análisis de las rutas del programa y comprobar si las secuencias de flujo de datos son correctas

186

IV – Técnicas estáticas 03 – Análisis estático Análisis del flujo de datos • Procedimiento : • Una variable x puede ser accedida a lo largo de una ruta del programa de las siguientes maneras: • x se define (d) – asignar un valor (p.ej., x = 1) • x está indefinida (i) – La variable no tiene al principio ningún valor • x se referencia (r) – ¡el valor de x no se modifica! (p.ej., z = x + 5 o if(x > 0) ) • x no se utiliza (e) – x no se utiliza en la sentencia

• El flujo se datos de una variable puede ser de esta manera representado por una secuencia de d, i, r y e • En el caso de que una de estas secuencias tenga una secuencia parcial sin sentido existe una anomalía de flujo de datos

187

IV – Técnicas estáticas 03 – Análisis estático Análisis del flujo de datos • Ventajas: • Descubrimiento seguro de determinados tipos de errores • Localización directa del error • Buen complemento a otros procedimientos de pruebas

• Inconvenientes: • Limitado a escasos tipos de errores

188

IV – Técnicas estáticas 03 – Análisis estático Análisis del flujo de datos • Anomalías de flujo de datos • Ejemplo IV/03-1 En el ejemplo se intercambian los valores para Min y Max utilizando una variable auxiliar en caso de que no estén ordenadas por valor:

El análisis de flujo de datos muestra la siguiente anomalía: La variable Aux se referencia estando indefinida (anomalía ri) -

La variable Max se define dos veces seguidas (anomalía dd)

void MinMax (int Min, int Max) {

-

int Aux; if (Min>Max) { Max = Aux; Max = Min; Aux = Min; } End MinMax;

El ejemplo se puede corregir fácilmente:

El valor definido para Aux queda indefinido sin haber sido referenciado (anomalía di)

void MinMax (int Min, int Max) { int Aux; if (Min>Max) { Aux = Min; Min = Max; Max = Aux; } End MinMax;

189

IV – Técnicas estáticas 03 – Análisis estático Métricas y su determinación • Mediante las métricas se pueden medir y expresar aspectos individuales de la calidad • La unidad de medida debe referirse siempre al aspecto valorado

• Se mide la complejidad estática del programa • Existen actualmente aprox. 100 métricas diferentes

• Las diferentes métricas se orientan a diferentes características • Tamaño del programa (p.ej., líneas de código/Lines of Code – LOC) • Estructuras de control del programa (p.ej., número ciclomático) • Estructuras de control de datos (z. B. Medida-Halstead)

• ¡Por regla general las métricas con un objetivo idéntico tampoco se pueden comparar!

190

IV – Técnicas estáticas 03 – Análisis estático Métricas y su determinación • Número ciclomático • Medida de la complejidad estructural del código en base a los gráficos de flujo de control • Determinación de las rutas de programa independientes • Puntos de referencia para la evaluación de la prueba y el mantenimiento • El número ciclomático v(G) se calcula a partir de • El número de aristas e • El número de nodos n • El número de las conexiones externas p (generalmente si p = 2 significa entrada simple/ single entry –salida simple/single exit) • Los valores hasta 10 son aceptables según McCabe, por encima se debería reelaborar el código (Valores por experiencia)

v(G) = e − n + p 191

IV – Técnicas estáticas 03 – Análisis estático Métricas y su determinación • Ejemplo IV/03-2 (Número ciclomático)

v(G) = e − n + p

• El ejemplo de la derecha tiene

1

• 2 conexiones externas:

1

• p= 2 • 14 nodos: • 19 aristas:

2 2

n = 14 e = 19

4 1 5 8

• Si v (G ) = e − n + p se obtiene con ello un valor para el número ciclomático de v (G ) = 7

19

3 5

3 6

4

7 8 7 12 9 11 13 10 16 11 9 10 15 14 12 17 13 18 6

14

192

IV – Técnicas estáticas 03 – Análisis estático Métricas y su determinación • Número ciclomático (s. McCabe) – motivo de utilización • Puede así servir como directriz de comprobación en pruebas de grupo estructuradas • Una desviación entre el número de decisiones y el valor del número ciclomático reducido en una unidad apunta a errores: • Una rama innecesaria • La falta de una rama

• El número ciclomático puede utilizarse como una medida adicional para la cobertura de las pruebas, ya que v(G) está relacionado con el número de rutas del programa • El número ciclomático es un mejor indicador para la propensión a errores de un segmento del programa que su tamaño (medido en LOC – Lines Of Code)

193

IV – Técnicas estáticas 04 – Resumen Afirmaciones importantes del capítulo • Con el análisis manual – muchos ojos, muchos puntos de vista, muchas opiniones- se encuentran errores • Revisiones para el control y aumento de la calidad • Tareas y roles en las revisiones: • Gestor • Moderador • Autor • Supervisor • Documentador

194

IV – Técnicas estáticas 04 – Resumen Afirmaciones importantes del capítulo • El proceso de revisión elemental se compone de: • Planificación • Preparación organizativa • Preparación individual • Reunión de revisión • Re-trabajo • Seguimiento (Follow-up) • Tipos de revisiones según IEEE1028 • Inspección • Walkthrough • Revisión técnica • Revisión informal 195

IV – Técnicas estáticas 04 – Resumen Afirmaciones importantes del capítulo • Junto a las revisiones existen dictámenes sobre documentos apoyados por herramientas, también denominado análisis estático • Los gráficos de flujo de control representan el desarrollo del programa • Los análisis de flujos de control muestran “ramas muertas”, etc. • Las anomalías en el flujo de datos se encuentran con la ayuda de los análisis de flujos de datos • Diversas métricas permiten hacer afirmaciones acerca de la construcción estructural y del esfuerzo de las pruebas • Antes de la revisión del código debería realizarse un análisis estático

196

197

Capítulo V – Técnicas de diseño de prueba • V/01 El proceso de desarrollo de las pruebas • V/02 Categorización de las técnicas de diseño de prueba • V/03 Técnicas de caja negra (basadas en especificación) • V/04 Técnicas de caja blanca (basadas en la estructura) • V/05 Técnicas basadas en la experiencia • V/06 Selección de técnicas de prueba • V/07 Resumen 198

V – Técnicas de diseño de prueba 01 – El proceso de desarrollo de las pruebas Definiciones y conceptos • En las pruebas dinámicas se compara el resultado esperado y el resultado obtenido, donde los resultados obtenidos se obtienen mediante la ejecución de los casos de prueba sobre el objeto de prueba. • Las pruebas dinámicas son complementarias a las pruebas estáticas, donde los objetos de prueba son analizados sin ejecutarse • Las pruebas se ejecutan en un entorno de pruebas separado – según la fase de pruebas en (una representación del) el entorno de implantación o en un marco de pruebas sintético(p.ej., en las pruebas de componentes). • Los datos de prueba se ejecutan en el objeto de prueba • El comportamiento de salida / los resultados se documentan

199

V – Técnicas de diseño de prueba 01 – El proceso de desarrollo de las pruebas Análisis de las pruebas • Distintos niveles de formalidad a la hora de describir el proceso, dependiendo de: • Contexto de pruebas • Organización • Madurez de los procesos de desarrollo y pruebas • Restricciones de recursos y tiempo

• Durante el análisis de pruebas se analiza la documentación base de pruebas para determinar lo que hay que probar, es decir, las condiciones de prueba (ej.: una función, transacción, elemento estructural, característica de calidad). • Estableciendo trazabilidad desde las condiciones de prueba hacia las especificaciones y los requisitos permite: • Análisis de impacto (cuando cambian los requerimientos), y • Cobertura de requerimientos (para un conjunto de pruebas)

200

V – Técnicas de diseño de prueba 01 – El proceso de desarrollo de las pruebas Diseño de las pruebas • Durante el diseño de las pruebas los casos de prueba y datos de prueba se crean y especifican. • Un caso de prueba consiste en: • Conjunto de valores de entrada • Precondiciones de ejecución • Resultados esperados y poscondiciones de ejecución

desarrolladas para cubrir ciertas condiciones de prueba • En el ‘Standard for Software Test Documentation’ (IEEE 829) se describe el contenido de: • Especificaciones de diseño de pruebas • Especificaciones de casos de prueba

201

V – Técnicas de diseño de prueba 01 – El proceso de desarrollo de las pruebas Implementación de las pruebas • Los resultados esperados deberían formar parte de la especificación de los casos de prueba e incluir salidas, cambios de datos y estados, y cualquier consecuencia de la prueba • Los resultados esperados deberían ser definidos antes de la ejecución de las pruebas • Durante la implementación de las pruebas los casos de prueba son desarrollados, priorizados y organizados en una especificación de casos de prueba (o en una especificación de casos + especificación de procedimientos) • En un procedimiento de prueba se especifica la secuencia de acciones para la ejecución de la prueba

202

V – Técnicas de diseño de prueba 01 – El proceso de desarrollo de las pruebas Implementación de las pruebas • Los procedimientos de pruebas y scripts automatizados son incorporados en una planificación de ejecución de pruebas que define el orden en que se ejecutarán, cuando y por quien. • Tendrá en cuenta factores como: • Pruebas de regresión • Priorización • Dependencias lógicas y técnicas

203

V – Técnicas de diseño de prueba 02 – Categorización de las técnicas de diseño de prueba Generalidades • Los procesos de prueba dinámicos se dividen en dos categorías básicas • La división se orienta a los fundamentos respectivos para la especificación de casos de prueba

Caja negra

Whiteblanca Box Caja

• Cada una de las categorías engloba diferentes procedimientos para la especificación de los casos de prueba para las pruebas dinámicas

204

V – Técnicas de diseño de prueba 02 – Categorización de las técnicas de diseño de prueba Procedimiento de actuación. Técnicas de caja negra • El probador considera al objeto de prueba como una caja negra • La estructura del programa es irrelevante o desconocida

• Los casos de prueba se deducen en su totalidad de las especificaciones / requisitos disponibles • Pruebas de comportamiento de entrada y salida

• ¡La funcionalidad es el punto central a considerar! • Se habla por ello de procedimiento de pruebas funcional

Especificación de casos de prueba

Objeto de prueba

Deducción de los casos de prueba de las especificaciones La estructura de programa es irrelevante! Pruebas de todas las posibles combinaciones o combinaciones seleccionadas de valores de entrada y salida

205

V – Técnicas de diseño de prueba 02 – Categorización de las técnicas de diseño de prueba Procedimiento de actuación. Técnicas de caja blanca • El probador conoce la estructura del programa y su código • esto es, jerarquía de componentes, flujo de control , flujo de datos etc..

• Los casos de prueba se especifican en base a la estructura del programa / código del programa • Los accesos al objeto de pruebas durante la ejecución son posibles

• Se prueba la estructura del programa • Se habla por ello de procedimiento de pruebas estructural Objeto de prueba Especificación de los casos de prueba Elaboración los casos de prueba en base a la estructura del programa Posibilidad de dirigir la prueba desde el exterior mediante accesos externos Análisis de los procesos en el objeto de prueba durante la ejecución de las pruebas

206

V – Técnicas de diseño de prueba 02 – Categorización de las técnicas de diseño de prueba Clasificación de técnicas de pruebas

Aseguramiento dinámico de la calidad • Análisis del software mediante ejecución con datos de prueba

vs.

Aseguramiento estático de la calidad • Análisis del software sin ejecución

Caja negra • Implementación desconocida durante la especificación de casos de prueba

vs.

Caja blanca • Implementación conocida durante la especificación de casos de prueba

Procedimiento de pruebas funcional • La especificación es el punto de partida para la definición de casos de prueba

vs.

Procedimiento de pruebas estructurado • Generación de casos de prueba mediante el análisis de la implementación

207

V – Técnicas de diseño de prueba 03 – Técnicas de caja negra Generalidades • Las siguientes técnicas de caja negra son las que se tratan de manera más profunda: • Formación de clases de equivalencia • Análisis de valores límite • Pruebas referidas a estados Se trata de las técnicas más importantes y más utilizadas • Otras técnicas de caja negra son, p.ej. : • Pruebas aleatorias • Análisis de gráficos de causa y efecto • Pairwise Testing

208

V – Técnicas de diseño de prueba 03 – Técnicas de caja negra Generalidades • El objetivo de las pruebas funcionales es la comprobación de la integridad y funcionamiento correcto de las funciones • El sistema se comprueba respecto de sus especificaciones • ¿Están contenidas correctamente todas las funciones solicitadas? • La ejecución de las pruebas debería ser lo menos redundante posible y sin embargo amplia • ¡No probar más de lo necesario!

209

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia • Se prueba cada vez con un representante de la clase de equivalencia • Para todas las pruebas con otro valor de la clase de equivalencia se espera un resultado idéntico

• Las clases de equivalencia se crean para datos de entrada válidos y no válidos • Si se define un valor x como “x > 0”, aparecen en principio dos clases de equivalencia – una todas las entradas “> 0” y otra las entradas “<= 0” • Pueden identificarse tipos de datos no numéricos – esto representa otra posible clase de equivalencia

210

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Todas las variables de entrada (elementos) del objeto de prueba son identificadas • Campos de la máscara de una GUI • Parámetros de una función

• Para cada una de las variables de entrada se define el rango de definición • Las clases de equivalencia válidas (Cev) de las variables (del elemento) se corresponden con este rango de definición • Las clases de equivalencia inválidas se producen a partir de los valores fuera del rango de definición(Cei)

211

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Ejemplo V/03-1: • Un programa precisa la entrada de un peso en “Kg.” (una función integrada redondea siempre sin decimales – valores menores que “0,5” se redondean a “0”) • Se permiten aquí valores ≥ 0 y no permitidos serían todos los números negativos y los valores de entrada no numéricos (p.ej., “Hugo”) • Clase de equivalencia válida: • 1. Clase de equivalencia no válida: • 2. Clase de equivalencia no válida :

x≥0 x<0 x = no numérico

212

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Ejemplo V/03-1: • Junto a las clases de equivalencia no válidas enunciadas anteriormente existen más clases de equivalencia no válidas que no se tienen en cuenta en este ejemplo: • x > 0, pero mayor que el mayor número que puede representar el ordenador • x > 0, pero más pequeño que el número positivo más pequeño que se puede representar en el ordenador

213

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Durante la formación de clases de equivalencia se consideran los rangos de definición de los valores • Valores de entrada y salida respectivamente del programa

• Los valores definidos se dividen en clases de equivalencia • Esto es, aquellos para los que se espera un comportamiento idéntico del sistema son agrupados en una clase de equivalencia (CE)

214

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Las clases de equivalencia de cada variable (de cada elemento) deben ser subdivididas • CE válida: dentro del rango de definición se agrupan todos los valores que se procesan de forma idéntica por el objeto de prueba • En ejemplo V/03-1 son todas las entradas numéricas positivas

• CE no válidas : fuera del rango de definición se distinguen dos casos: • Valores con formato correcto pero que están fuera del rango de definición se agrupan en una o más clases de equivalencia • Valores con formato incorrecto forman generalmente otra clase de equivalencia • En el ejemplo V/03-1 se forman, p.ej., dos clases de equivalencia no válidas: x < 0 y x no es un valor numérico

215

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Finalmente se elige un representante para cada CE y se define el resultado esperado • Para el ejemplo V/03-1 :

Variable

Clase de equivalencia

Representante

Peso

CE1: x ≥ 0

+1,00

CE2: x < 0

-1,00

CE3: x no numérico

Hugo

216

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Ejemplo V/03-2: • Un programa calcula el precio de un producto en función de su valor, un descuento en % y gastos de envío establecidos de (6,- , 9,- o 12,-€ según envío) Variable

Clases de equivalencia

Valor del producto

CE11: x >= 0

Válido

1000,00

CE12: x < 0

No válido

-1000,00

CE13: x no numérico

No válido

Hugo

Válido

10%

CE22: x < 0%

No válido

-1%

CE23: x > 100%

No válido

101%

CE24: x no numérico

No válido

Hugo

CE31: x = 6

Válido

6

CE32: x = 9

Válido

9

CE33: x = 12

Válido

12

CE34: x ≠ {6, 9, 12}

No válido

5

CE35: x no numérico

No válido

Hugo

Descuento

Gastos de envío

CE21: 0% ≤ x ≤ 100%

Estado

Representante

Existen las siguientes excepciones: • Valor del producto numérico positivo con dos decimales • Descuento numérico en formato de % sin comas, entre 0% y 100% • Para los gastos de envío se proporcionan valores fijos que pueden ser 6, 9, o 12

217

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Ejemplo V/03-2: • Las clases de equivalencia válidas permiten formar las siguientes combinaciones o casos de prueba (CP01, CP02 y CP03) :

Variable

Calse de equivalencia

Valor del producto

CE11: x >= 0

Válido

1000,00

CE12: x < 0

No válido

-1000,00

CE13: x no numérico

No válido

Hugo

Válido

10%

CE22: x < 0%

No válido

-1%

CE23: x > 100%

No válido

101%

CE24: x no numérico

No válido

Hugo

CE31: x = 6

Válido

6

CE32: x = 9

Válido

9

CE33: x = 12

Válido

12

CE34: x ≠ {6, 9, 12}

No válido

5

CE35: x no numérico

No válido

Hugo

Descuento

Gastos de envío

CE21: 0% < x < 100%

Estado

Representante

CP01

CP02

CP03
























218

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Ejemplo V/03-2: • De las CE no válidas se deducen directamente los siguientes casos de prueba: cada una en combinación con CE válidas de los otros elementos

Variable

Calse de equivalencia

Valor del producto

CE11: x >= 0

Válido

1000,00

CE12: x < 0

No válido

-1000,00

CE13: x no numérico

No válido

Hugo

Válido

10%

CE22: x < 0%

No válido

-1%

CE23: x > 100%

No válido

101%

CE24: x no numérico

No válido

Hugo

CE31: x = 6

Válido

6

CE32: x = 9

Válido

9

CE33: x = 12

Válido

12

CE34: x ≠ {6, 9, 12}

No válido

5

CE35: x no numérico

No válido

Hugo

Descuento

Gastos de envío

CE21: 0% < x < 100%

Estado

Representante

CP0 4

CP0 5

CP0 6

CP0 7

CP0 8

CP0 9

CP1 0




















































219

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Ejemplo V/03-2: • Se deducen en total 10 casos de prueba 3 casos válidos y 7 casos no válidos:

Variable

Clase de equivalencia

Estado

CP01

CP02

CP03

Valor del producto

Válido

1000,00










No válido

-1000,00

No válido

Hugo

Válido

10%

No válido

-1%

No válido

101%

No válido

Hugo

Válido

6

Válido

9

Válido

12

No válido

5

No válido

Hugo

Descuento

Gastos de envío

CP04

CP05

CP06

CP07

CP08

CP09

CP10


































































220

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – procedimiento de actuación • Formación de clases de equivalencia en base a los valores de salida • El procedimiento se puede aplicar de forma análoga para la división de todos los valores de salida definidos • La variable (el elemento) será entonces un valor de salida (p.ej., un campo de salida de una GUI) • De los posibles valores de salida definidos se formarán otra vez las respectivas clases de equivalencia • Una CE engloba a aquellos valores a los que se subordina un mismo comportamiento de salida

• Por cada clase de equivalencia se elige un representante • Se decide finalmente mediante qué valores de entrada se pueden conseguir los representantes • Requiere un gran esfuerzo al tener que buscar datos de entrada para los diferentes comportamientos de salida definidos

221

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – Generalidades • Descomposición • El éxito o el fracaso de la calidad de las pruebas depende de la precisión con que se descompongan las variables individuales • De la precisión a la hora de descomponer las variables / elementos individuales depende la calidad de las pruebas • Las CE no reconocidas implican el riesgo de pasar posibles efectos de error por alto, ya que sus representantes pueden provocar resultados diferentes

222

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – Generalidades • Elección de representantes • Cada valor de una CE puede ser elegido como representante para la prueba – lo lógico es sin embargo elegir “valores típicos”. • Los representantes de las CE no válidas deben ser siempre unidos con representantes idénticos de la misma CE válida en casos de prueba (combinaciones estándar). • Con el fin de no enmascarar errores no se deben elegir representantes de CE no válidas junto a representantes de otras CE no válidas.

223

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – Generalidades • El criterio de finalización de las pruebas puede ser aquí un determinado grado de cobertura • ¿Cuantas de las posibles CE han sido probadas en relación a todas las CE definidas?

Cobertura de CE =

Nº de CE probadas * 100 % Nº total de CE

224

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – Generalidades • Paso de definiciones / requisitos a clases de equivalencia • A menudo una tarea difícil ya que los documentos disponibles no son precisos o son incompletos • Límites de rangos de valores imprecisos o, eventualmente falta de datos acerca de la definición exacta dificultan la transformación • ¡A menudo suele ser necesario volver a consultar con el cliente!

225

V – Técnicas de diseño de prueba 03.1 – Técnicas de caja negra Formación de clases de equivalencia – Generalidades • Ventajas del procedimiento • Determinación sistemática de casos de prueba, es decir, con un número mínimo de casos de prueba se maximiza la cobertura de pruebas • La descomposición en clases de equivalencia en base a las definiciones / especificaciones abarca de muy buena manera los requisitos funcionales. • La priorización de las clases de equivalencia puede servir para priorizar los casos de prueba (los datos de entrada que no se utilizan nunca son los últimos a probar) • La pruebas de las condiciones de excepción definidas quedan aseguradas por los casos de prueba negativos

226

V – Técnicas de diseño de prueba 03.2 – Técnicas de caja negra Análisis de valores límite • El análisis de valores límite amplia la formación de clases de equivalencia • Las regiones límite de las clases de equivalencia se prueban de forma más intensiva • ¿Por qué probar más intensivamente las regiones límite ? • A menudo hay una definición insuficiente en las especificaciones acerca de la los límites de los rangos de valores • Comprobación acerca de si los límites se han implementado correctamente en la programación

¡La experiencia muestra que los errores son más frecuentes en las regiones límite!

227

V – Técnicas de diseño de prueba 03.2 – Técnicas de caja negra Análisis de valores límite • La utilización del análisis de valores límite presupone que • La clase de equivalencia abarca un rango de valores y • Que se pueden identificar los límites para ese rango de valores

• La diferencia / la ampliación respecto de la formación de clases de equivalencia reside en la elección de los representantes • Formación de clases de equivalencia: • considera un valor cualquiera (típico) de la clase

• Análisis de valores límite: • Considera los límites de la clase y sus valores vecinos

• Si las clases de equivalencia de una variable vienen representadas en forma de un grupo de valores no se podrá, en general, formar valores límite • P.ej. Soltero, casado, separado, viudo

228

V – Técnicas de diseño de prueba 03.2 – Técnicas de caja negra Análisis de valores límite • Ejemplo V/03-3: • Rango de valores para el descuento en %: 0,00 ≤ x ≤ 100,00 • Formación de CE 3 Clases (< 0, Rango de definición, > 100) p.ej., con los representantes: -50,00; 50,00; 150,00 • Análisis de valores límite amplía los representantes a : 1. (-50,00): -0,01 2. (50,00): 0,00; 100,00 3. (150,00): 100,01

229

V – Técnicas de diseño de prueba 03.3 – Técnicas de caja negra Tablas de decisión • Es un buen sistema para representar la lógica de los requisitos de usuario, sobre todo las reglas de negocio complejas. • Las tablas de decisión están compuestas por cuatro secciones: REGLAS DE DECISIÓN

IDENTIFICACIÓN DE CONDICIONES

IDENTIFICACIÓN DE ACCIONES

VALORES DE CONDICIONES

VALORES DE ACCIONES

• Una vez confeccionada la tabla, quedarán determinadas las reglas de decisión. Estas son proposiciones que se leerán verticalmente, partiendo desde la sección Valores de Condiciones y descendiendo por la sección Valores de Acciones. Se las enuncia así: “SI.......(condición1, condición2, etc.)... ENTONCES ... (acción1, acción2, etc.)....”. 230

V – Técnicas de diseño de prueba 03.3 – Técnicas de caja negra Tablas de decisión • Ejemplo: REGLAS DE DECISIÓN CONDICIONES

1

2

3

4

¿Pago contado?

S

S

N

N

¿Compra > 50.000€?

S

N

S

N

X

X

ACCIONES Calcular descuento del 5% sobre el importe de la compra Calcular descuento del 7% sobre el importe de la compra Calcular importe neto de la factura

X X

X X

X

X

231

V – Técnicas de diseño de prueba 03.4 – Técnicas de caja negra Pruebas referidas al estado Los dos procedimientos conocidos hasta el momento solo tienen en cuenta los comportamientos de entrada/salida según las especificaciones • Los diferentes estados que puede adoptar un objeto de prueba durante su ejecución no son contemplados • ¿Tienen consecuencias los procesos que ya han tenido éxito sobre el desarrollo posterior? • Los diferentes estados que puede adoptar un objeto de prueba durante su ejecución se representan mediante un modelo de estados • Una prueba referida al estado debería ejecutar para cada estado todas las funciones definidas para el mismo al menos una vez

232

V – Técnicas de diseño de prueba 03.4 – Técnicas de caja negra Pruebas de transición de estados • Para aquellos sistemas que se ajusten a un modelo de transición de estados, el objetivo de las pruebas sobre este tipo de sistemas sería demostrar la conformidad de los requisitos especificados en forma de diagrama de transición de estados o tablas de transición de estados. EVENTOS ESTADOS Evento_1

Evento_n

Estado_1

Estado_2 Acción_ 1 (1)

Ignorar (n)

Estado_m

Ignorar (n*(m-1)+1)

Ignorar (n*m)

Se diseñarán casos de prueba que cubran todas las transiciones de estados representadas en la tabla. 233

V – Técnicas de diseño de prueba 03.4 – Técnicas de caja negra Pruebas de transición de estados • Ejemplo de una tabla de transición de estados para una máquina junto con el correspondiente diagrama de estados.

• Todas las entradas posibles a la máquina están enumeradas a través de las columnas de la tabla. Todos los estados posibles están enumerados a través de las filas. Desde la tabla de transición de estados anterior, es fácil ver que si la máquina está en S1 (la primera fila), y la siguiente entrada es el carácter 1, la máquina permanecerá en S1. Si llega un carácter 0, la máquina realizará la transición a S2 como puede verse desde la segunda columna. En el diagrama esto es denotado por la flecha desde S1 a S2 etiquetada con un 0. 234

V – Técnicas de diseño de prueba 03.4 – Técnicas de caja negra Pruebas referidas al estado • Criterios de finalización de pruebas • Cada estado se debe alcanzar al menos una vez • Cada transición de estados se debe alcanzar al menos una vez • Ventajas e inconvenientes del procedimiento • Es una buena posibilidad de probar objetos de prueba dependientes del estado • Método apropiado para las pruebas de clases en caso de disponer del ciclo de vida del objeto • Los estado son a menudo muy complejos en su estructura, esto es, son determinados por un gran número de parámetros diferentes • Tanto la definición de casos de prueba como la valoración de las pruebas son muy trabajosos en estos casos

• La cobertura de todas las transiciones de estado no garantiza unas pruebas completas

235

V – Técnicas de diseño de prueba 03.5 – Técnicas de caja negra Pruebas de escenarios de uso o casos de uso • Estas pruebas consisten en validar un sistema siguiendo la lógica de los casos de uso (también llamados escenarios de uso). • Los casos de uso describen los flujos de un sistema teniendo en cuenta situaciones reales a las que se enfrenta el usuario.

Los casos de prueba basados en casos de uso son muy útiles, ya que permiten descubrir defectos probando situaciones reales que sin duda se darán durante la explotación regular del sistema.

236

V – Técnicas de diseño de prueba 03.5 – Técnicas de caja negra Pruebas de escenarios de uso o casos de uso • Los casos de uso son muy interesantes para diseñar las pruebas de aceptación de usuario. • Además ayudan a descubrir defectos que no se encuentran durante las pruebas de componentes, pero si en las pruebas de integración de componentes, cuando esos mismos componentes interactúan unos con otros. Proceso dirigido por los Casos de Uso «trace» Caso de Uso

«trace»

Realización de Análisis

Realización de Diseño

«trace»

«trace»

Pruebas Unitarias Pruebas Funcionales

X Caso de Prueba

[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]

237

V – Técnicas de diseño de prueba 03.6 – Técnicas de caja negra Generalidades • Comprobación de la funcionalidad como objetivo de las técnicas de caja negra • El resultado de las pruebas depende de la calidad de la especificación de requisitos (p.ej., especificación con errores o incompleta) • Si existen errores en la especificación también se probará con errores – se prueba la funcionalidad descrita (anteriormente debería ser asegurada la calidad del código del programa mediante un análisis estático)

• Si el objeto de prueba contiene funciones que no han sido especificadas éstas permanecerán sin descubrir • Estas características no requeridas pueden ser problemáticas p.ej., cuando llevan a problemas de estabilidad o seguridad o cuando no se cumplen las expectativas del cliente

238

V – Técnicas de diseño de prueba 03.6 – Técnicas de caja negra Generalidades • A pesar de estas carencias las pruebas funcionales son las de mayor peso dentro de las pruebas • Por ello, los procedimientos de caja negra son siempre utilizados • Los problemas/puntos débiles mencionados pueden ser compensados al menos parcialmente por otros métodos de prueba (p.ej., procedimientos de caja blanca)

239

V – Técnicas de diseño de prueba 04 – Técnicas de caja blanca Procedimiento para el “análisis basado en código” • Se va a profundizar ahora en las siguientes técnicas dinámicas de caja blanca • Cobertura de sentencias • Cobertura de ramas • Cobertura de condiciones • Cobertura de rutas • Estas técnicas son las más importantes y utilizadas. Otras técnicas de caja blanca son p.ej., : • LCSAJ (Linear Code Sequence And Jump) • Procedimiento basado en el flujo de datos

240

V – Técnicas de diseño de prueba 04 – Técnicas de caja blanca Herramientas • En las técnicas de caja blanca se trata de ejecutar partes del programa • En teoría deberían ser probadas todas las partes del programa al menos una vez durante las pruebas • La ejecución es seguida mediante herramientas (p.ej., mediante analizadores de cobertura): • Se realiza una instrumentación, esto es, se instalan contadores en determinadas posiciones del objeto de prueba • Estos contadores están al principio de la prueba a cero y son aumentados escalonadamente con cada ejecución de la parte del programa • Si al final de la prueba quedan contadores a cero significa que la parte del programa no se ha ejecutado

241

V – Técnicas de diseño de prueba 04 – Técnicas de caja blanca Herramientas • Las técnicas de caja blanca necesitan en muchos casos el apoyo de herramientas - p.ej., durante la • especificación de casos de prueba • P.ej., deducción de gráficos de flujo de control a partir del código del programa

• ejecución de los casos de prueba • Herramientas para el seguimiento y control de los procesos dentro del objeto de pruebas

• La utilización de herramientas en este punto asegura y aumenta la calidad de las pruebas • Debido a la complejidad de los procesos, la ejecución manual: • Consume tiempo y recursos • Es propensa a errores y difícil de llevar a cabo

242

V – Técnicas de diseño de prueba 04 – Técnicas de caja blanca Generalidades acerca de las técnicas de caja blanca • • • •

¡Siempre se prueba sólo lo que existe! Casos de prueba basados en el código disponible ¡La falta de funciones no se descubre! Utilización de las técnicas más potentes en las fases de desarrollo mas tempranas • Pruebas cercanas al desarrollo con las técnicas de caja blanca • P.ej., pruebas de componentes y de integración

• Los procedimientos se diferencian en la intensidad de pruebas • En función del procedimiento y la estructura del programa varía el número de casos de prueba

243

V – Técnicas de diseño de prueba 04.1 – Técnicas de caja blanca Cobertura de sentencias • Cada sentencia de un programa y su ejecución respectiva constituyen el centro de la observación • ¿Qué casos de prueba son necesarios para ejecutar todas las sentencias disponibles o bien una cuota determinada de las mismas?

• La base de esta investigación es el gráfico de flujo de control • cada sentencia se representa mediante un nodo y el flujo de datos entre sentencias mediante una arista • las secuencias de sentencias son de nuevo agrupadas en un nodo (se ejecuta una directamente a continuación de la otra)

• El objetivo de las pruebas (criterio de finalización de las pruebas) consiste en ejecutar un número predeterminado de sentencias (Medida de cobertura o Medida-C0) Nº de sentencias cubiertas por casos (diseñadas o ejecutadas) Medida-C0 (Cobertura de sentencias) = * 100% Nº total de sentencias

244

V – Técnicas de diseño de prueba 04.1 – Técnicas de caja blanca Cobertura de sentencias • Ejemplo V/04-1 • Se da el siguiente segmento de programa representado a la derecha como gráfico de flujo de control : if (i > 0) { j = f(i); if (j > 10) { for (k=i; k > 10; k --) { ... } } }

245

V – Técnicas de diseño de prueba 04.1 – Técnicas de caja blanca Cobertura de sentencias • Ejemplo V/04-1 • El gráfico de flujo de control representado en la parte derecha • contiene dos sentencias IF y un bucle (dentro de la segunda sentencia IF)

• Hay tres “caminos” que llevan por este segmento de programa • de la primera sentencia IF salen dos caminos • la rama derecha de la primera sentencia IF se reparte otra vez en dos caminos mediante la segunda sentencia IF (el recorrido del bucle no se contempla aquí como un camino)

• Todas las sentencias de este ejemplo se pueden alcanzar por el camino de la derecha • un único caso de prueba conseguiría un 100% de cobertura de sentencia 246

V – Técnicas de diseño de prueba 04.1 – Técnicas de caja blanca Cobertura de sentencias • Ejemplo V/04-2 • El segundo ejemplo representa el gráfico de un segmento de programa algo más complicado • Se compone de tres sentencias IF y un bucle (dentro de una sentencia IF)

• Cuatro caminos diferentes recorren la parte del programa • de la primera sentencia IF salen dos caminos • para ambas ramas de la primera sentencia IF se dan respectivamente otras dos posibilidades de recorrido debido a las siguientes sentencias IF • el recorrido del bucle no se contempla aquí como un camino

• Por uno de los caminos se alcanzan sólo siete de las doce sentencias (C0=58,33%) • para una cobertura del 100% de las sentencias se necesitan aquí cuatro casos de prueba 247

V – Técnicas de diseño de prueba 04.1 – Técnicas de caja blanca Cobertura de sentencias – Generalidades • La medida de cobertura se realiza mediante herramientas • Se habla de los llamados analizadores de cobertura

• Ventajas/Inconvenientes del procedimiento • Las sentencias muertas, esto es, las sentencias que no pueden ser alcanzadas se encuentran en el caso de una solicitud de cobertura total. • Si existen sentencias muertas en el programa no es posible alcanzar una cobertura del 100%

• Las sentencias no existentes – sentencias que serían necesarias para la función – se quedan fuera • Lo que se prueba es si todas las sentencias contenidas son ejecutables / accesibles • ¡Si en una parte del programa falta una sentencia, esto no podrá ser determinado mediante la cobertura de sentencias!

248

V – Técnicas de diseño de prueba 04.2 – Técnicas de caja blanca Cobertura de decisiones o ramas • En lugar de las sentencias, es el flujo de control el que está en el centro de la valoración (no sólo los nodos si no también las aristas) • Todas las aristas del gráfico de flujo de control deben ser recorridas al menos una vez. • ¿Qué casos de pruebas son necesarios para recorrer todas las posibles flechas?

• El objetivo de las pruebas (criterio de finalización de las pruebas) consiste en conseguir una cobertura de ramas previamente determinada (cobertura de ramas o Medida-C1) Nº de ramas cubiertas por casos Medida- C1 (Cobertura de ramas) =

(diseñadas o recorridas)

* 100%

Nº total de ramas

249

V – Técnicas de diseño de prueba 04.2 – Técnicas de caja blanca Cobertura de decisiones o ramas • Ejemplo V/04-3 • Se da el segmento de programa representado por el gráfico de flujo de control de la ilustración de la derecha • Tres diferentes caminos recorren este segmento de programa • de la primera sentencia IF salen dos caminos • Una rama de la primera sentencia IF se reparte de nuevo en dos caminos mediante la segunda sentencia IF – el bucle se encuentra en la rama derecha de la sentencia • Todas las aristas sólo pueden ser alcanzadas mediante la combinación de los tres caminos diferentes • Tres casos de prueba llevarán a una cobertura del 100% de las ramas • Por los dos caminos de la derecha se pueden aún cubrir nueve de las diez aristas (Medida-C1=90%)

250

V – Técnicas de diseño de prueba 04.2 – Técnicas de caja blanca Cobertura de decisiones o ramas • Ejemplo V/04-4: • Aquí se representa el gráfico de un segmento de programa algo más complicado

• Cuatro posibles caminos recorren el segmento del programa • de la primera sentencia IF salen dos caminos • para ambas ramas de la primera sentencia IF se dan respectivamente otras dos posibilidades de recorrido debido a las siguientes sentencias IF

• recorriendo tres caminos sólo se recorren un máximo de trece de las quince aristas (C1=86,66%) • Para una cobertura 100% de los nodos/aristas se necesitan cuatro casos de prueba • Los casos de prueba para la cobertura de ramas pueden servir aquí también para la cobertura de sentencias!

251

V – Técnicas de diseño de prueba 04.2 – Técnicas de caja blanca Cobertura de decisiones o ramas • Este método lleva, por lo general, a mayor número de casos de prueba que la cobertura de sentencias • ¡La cobertura del 100% de las sentencias está contenida en una cobertura del 100% de las ramas! • No se puede evitar tener que recorrer varias veces algunas aristas • Inconvenientes • Las sentencias que falten no son localizadas • Inapropiado para la comprobación de condiciones complejas • Insuficiente para la comprobación de bucles • No se tienen en cuenta las dependencias entre bucles

252

V – Técnicas de diseño de prueba 04.2 – Técnicas de caja blanca Cobertura de sentencias y de ramas • Ambos procedimientos se refieren al recorrido de gráficos de flujo de control • La diferencia se debe al diferente número de casos de prueba • En el gráfico de flujo de control sólo se recoge el resultado de las sentencias (p.ej., IF (x > y) puede ser cierto o falso) • Esto es , qué camino se toma después de una sentencia • Quedan sin considerar aquí los errores dentro de la sentencia, es decir, errores dentro de sus condiciones múltiples

253

V – Técnicas de diseño de prueba 04.3 – Técnicas de caja blanca Otras técnicas basadas en estructura. Cobertura de condiciones • Este procedimiento examina los procesos dentro de las sentencias de un segmento de programa • ¿En qué condiciones se basa el valor verdadero que devuelve una sentencia? • El objetivo es localizar errores que se encuentren en condiciones (condiciones múltiples) • Las condiciones múltiples se forman mediante la unión con operadores (OR, AND, etc.) de condiciones elementales (p.ej., a > 2 OR b < 6) • Las condiciones elementales (como parte de una condición también condiciones elementales parciales) no contienen operadores lógicos (p.ej., a > 2) – se permiten los símbolos relacionales (=, > , <, etc.) • Se distinguen tres variantes de la cobertura de condiciones • Cobertura de condiciones simple, múltiple y múltiple mínima

254

V – Técnicas de diseño de prueba 04.3 – Técnicas de caja blanca Otras técnicas basadas en estructura. Cobertura de condiciones simple • Cada condición parcial elemental dentro de una condición múltiple debe tomar en la prueba tanto el valor verdadero como el valor falso • El ejemplo de la izquierda explica la cobertura de condiciones simple

• Se da una condición múltiple sencilla

Ejemplo V/04-6: Se da la siguiente condición:

• Con sólo dos casos de prueba se consigue la cobertura simple

a > 2 OR b < 6 Los casos de prueba para la cobertura de condiciones simple serían p.ej. : a =6 (verd.)

b=9 (falso)

a>2 OR b<6 (verd.)

a=1 (falso)

b=2 (verd.)

a>2 OR b<6 (verd.)

• Cada condición parcial ha adoptado ambos estado (verdadero y falso) • El resultado de la condición completa es, sin embargo, en ambos casos de prueba el mismo

• verdadero OR falso = verdadero • Los diferentes valores verdaderos de la condición completa no son tenidos en cuenta 255

V – Técnicas de diseño de prueba 04.3 – Técnicas de caja blanca Otras técnicas basadas en estructura. Cobertura de condiciones múltiple • Todas las combinaciones que se puedan formar a partir de los estados de las condiciones básicas contenidas deben estar contenidas en la prueba • El ejemplo de la izquierda explica la cobertura de condiciones múltiple • Se da una condición múltiple sencilla

Ejemplo V/04-6: Se da la siguiente condición: a > 2 OR b < 6 Los casos de prueba para la cobertura de condiciones múltiple serían p.ej. : a=6 (verd.)

b=9 (falso)

a>2 OR b<6 (verd.)

a=6 (verd.)

b=2 (verd.)

a>2 OR b<6 (verd.)

a=1 (falso)

b=2 (verd.)

a>2 OR b<6 (verd.)

a=1 (falso)

b=9 (falso)

a>2 OR b<6 (falso)

• Con cuatro casos de prueba se consigue la cobertura múltiple • Se han formado todas las posibles combinaciones de estados (verdadero & falso) • Se han alcanzado todas las posibles salidas de la condición múltiple • El número de casos de prueba crece exponencialmente: • n = Nº de condiciones elementales • 2n = Numero de casos de prueba 256

V – Técnicas de diseño de prueba 04.3 – Técnicas de caja blanca Otras técnicas basadas en estructura. Cobertura mínima de condiciones múltiple • Todas las combinaciones que se puedan formar a partir de los estados de las condiciones parciales contenidas deben estar incluidas en la prueba, si la variación del valor verdadero de una condición parcial puede influir en el resultado de la condición completa Ejemplo V/04-6: Se da la siguiente condición: a>2 OR b<6 Los casos de prueba para la cobertura de condiciones múltiple serían p.ej. a=6 (verd.)

b=9 (falso)

a>2 OR b<6 (verd.)

a=6 (verd.)

b=2 (verd.)

a>2 OR b<6 (verd.)

a=1 (falso)

b=2 (verd.)

a>2 OR b<6 (verd.)

a=1 (falso)

b=9 (falso)

a>2 OR b<6 (falso)

• El ejemplo de la izquierda explica la cobertura mínima de condiciones múltiple • Se da de nuevo una condición múltiple sencilla • En tres de los cuatro casos de prueba una modificación de uno de los valores verdaderos lleva a la modificación del resultado completo • ¡Sólo en el 2º caso (verdadero OR verdadero) la modificación de uno de los valores verdaderos no infuye en la condición completa – se puede prescindir del segundo caso de prueba! • El número de casos de prueba se reduce y queda entre n+1 y 2n 257

V – Técnicas de diseño de prueba 04.3 – Técnicas de caja blanca Otras técnicas basadas en estructura. Cobertura de condiciones • La cobertura de condiciones simple es un instrumento débil para comprobar condiciones múltiples • La cobertura de condiciones múltiple es un procedimiento sólido • Cumplimiento de la cobertura de ramas y sentencias • Por contra muchos casos de prueba (cantidad: 2n) • Eventualmente no se pueden representar las combinaciones • P.ej., para “5< x AND x < 10” no pueden ser nunca ambas condiciones parciales falsas

• La cobertura mínima de condiciones múltiples ofrece ventajas • Reduce el número de casos de prueba (de n+1 a 2n) • La cobertura de ramas y sentencias también quedan cubiertas • Tiene en cuenta la complejidad de las condiciones Si existen condiciones complejas deberán ser comprobadas. La cobertura mínima de condiciones múltiples es un procedimiento adecuado

258

V – Técnicas de diseño de prueba 04.3 – Técnicas de caja blanca Otras técnicas basadas en estructura. Cobertura de rutas • En el centro de estudio se sitúa la cobertura de todas las rutas del programa • Ruta: caminos que pueden tomas los datos dentro del programa • En la cobertura de ramas es suficiente, p.ej. para un bucle, un caso de prueba que lo recorra • La cobertura de rutas necesita de casos de prueba adicionales: • uno que no recorra el bucle y • respectivamente uno para cada posible recorrido adicional del bucle

259

V – Técnicas de diseño de prueba 04.3 – Técnicas de caja blanca Otras técnicas basadas en estructura. Cobertura de rutas • La base del análisis es de nuevo el gráfico de flujo de control • Las sentencias son los nodos • El flujo de datos se representa mediante aristas • Una ruta es el recorrido de nodos y aristas de principio al fin del gráfico de flujo de control • El objetivo de las pruebas (criterio de finalización de las pruebas) es un valor predefinido de cobertura de rutas:

Número de rutas recorridas* 100% Medida de cobertura de rutas = Número total de rutas

260

V – Técnicas de diseño de prueba 04.3 – Técnicas de caja blanca Otras técnicas basadas en estructura. Cobertura de rutas • Ejemplo V/04-7: • Se da el segmento de programa representado por el gráfico de flujo de control de la ilustración de la derecha • Compuesto de tres sentencias IF

• Tres diferentes “caminos” recorren este segmento de programa • Se pueden recorrer cinco rutas diferentes • Son necesarios cinco casos de prueba para una cobertura de rutas del 100% • (Sólo dos para un 100% de la medida C0 y tres para C1)

261

V – Técnicas de diseño de prueba 04.3 – Técnicas de caja blanca Otras técnicas basadas en estructura. Cobertura de rutas • Ejemplo V/04-7: • Se da el segmento de programa representado por el gráfico de control de flujo de la ilustración de la derecha • Compuesto por dos sentencias IF y un bucle (dentro de la segunda sentencia IF)

• Tres diferentes “caminos” recorren este segmento de programa • Se pueden recorrer cuatro rutas diferentes teniendo en cuenta el doble recorrido del bucle • Cada recorrido adicional del bucle supone un caso de prueba adicional

262

V – Técnicas de diseño de prueba 04.3 – Técnicas de caja blanca Otras técnicas basadas en estructura. Cobertura de rutas • La cobertura de rutas del 100% sólo se puede lograr con los segmentos de programa más sencillos • Un bucle lleva p.ej., a una explosión de los casos de prueba, ya que cada posible recorrido del bucle debe ser considerado como una ruta propia

• La cobertura de rutas tiene mayor alcance que la cobertura de sentencias o de ramas • Se recorre cada posible ruta dentro del segmento de programa a analizar

263

V – Técnicas de diseño de prueba 05 – Técnicas basadas en la experiencia Especificación intuitiva de casos de prueba • Definición Procedimiento en el que los casos de prueba son elaborados sin un modo de proceder claramente metódico en base a la intuición y la experiencia del probador. • Los casos de prueba se basan en la intuición y experiencia • ¿Donde han aparecido ya errores frecuentemente en el pasado? • ¿Donde podría aparecer todavía un error?

• La especificación intuitiva de casos de prueba se denomina también como pruebas orientadas a puntos débiles o error guessing

264

V – Técnicas de diseño de prueba 05 – Técnicas basadas en la experiencia Especificación intuitiva de casos de prueba •

En la práctica sólo se utiliza para completar un conjunto de casos de prueba disponibles • • •

No es suficiente para procedimientos de prueba sistemáticos Sin embargo, a menudo obtiene casos de prueba que no es posible especificar mediante otros procedimientos Ejemplos: • En la introducción de una fecha utilizar 30.02.2005 • Conjuntos vacios en datos de entrada

•

Como método es aplicable mas bién en las etapas posteriores de las pruebas

265

V – Técnicas de diseño de prueba 05 – Técnicas basadas en la experiencia Especificación intuitiva de casos de prueba • El probador debe tener experiencia o conocimientos que pueda transformar en casos de prueba • Intuición – ¿Dónde pueden estar los errores? • La intuición caracteriza a un buen probador

• Experiencia – ¿Dónde hubo errores en el pasado? • Los probadores experimentados tienen este conocimiento • Alternativamente se pueden recuperar listas con efectos de error recurrentes

• Saber / conocimiento – ¿Dónde se pueden esperar aquí los errores? • Entran los detalles especiales del proyecto • ¿Dónde se pueden esperar más errores en función de la complejidad o la escasez de tiempo?

266

V – Técnicas de diseño de prueba 05 – Técnicas basadas en la experiencia Casos de prueba intuitivos – Posibles fuentes • Resultados de pruebas y experiencias práctica con sistemas similares • Eventualmente un antecesor del software o un sistema con funcionalidad similar

• Experiencias de usuarios • Intercambio de experiencias relativas al software en círculos de usuarios

• Puntos críticos de la implantación • ¿Que áreas del software se utilizarán principalmente?

• Dificultades del desarrollo • ¿Es previsible un mayor número de errores en áreas determinadas?

267

V – Técnicas de diseño de prueba 05 – Técnicas basadas en la experiencia Especificación intuitiva de casos de prueba • La especificación intuitiva de casos de prueba es un buen complemento para los procedimientos sistemáticos • Debe permanecer, sin embargo, como un complemento • No hay criterios para comprobar su integridad – el número de casos de prueba intuitivos puede variar mucho

• La ejecución de las pruebas se corresponde con el de los casos de prueba especificados sistemáticamente • Sólo se diferencia en la forma en la que el caso de prueba es especificado / determinado

• Mediante las pruebas intuitivas se pueden encontrar errores adicionales que no se hubieran detectado mediante las pruebas sistemáticas

268

V – Técnicas de diseño de prueba 05 – Técnicas basadas en la experiencia Pruebas exploratorias • Consiste en la realización concurrente de diseño, ejecución, y registro de pruebas, y aprendizaje basado en unos objetivos de prueba dentro de una planificación de pruebas. • En las pruebas orientadas a scripts manuales, la ejecución de las pruebas, sin embargo, se lleva a cabo, siguiendo una secuencia de pruebas previamente documentada. • Técnica informal en la que el probador controla de manera activa el diseño de las pruebas así como de aquellas pruebas que se han ejecutado, y utiliza la información obtenida durante las pruebas para diseñar nuevas y mejores pruebas. • Buena aproximación cuando: • Las especificaciones son escasas o inadecuadas, • Hay presiones de tiempo, y • Como complemento a otras técnicas mas formales

269

V – Técnicas de diseño de prueba 05 – Técnicas basadas en la experiencia Pruebas exploratorias. Comparativa de aproximaciones En pruebas tradicionales (scripted), las pruebas son diseñadas y registradas. Luego pueden ser ejecutadas posteriormente, incluso por otro probador Basadas en términos: - Cuantitativos, y - Decisión

Vs En las pruebas exploratorias, las pruebas son diseñadas y ejecutadas al mismo tiempo, y a menudo no son registradas Basadas en términos de: - Adaptación y - Aprendizaje

270

V – Técnicas de diseño de prueba 06 – Selección de técnicas de prueba ¿Qué técnica seleccionar? •

La selección de qué técnicas utilizar depende de múltiples factores, entre los que se incluyen el tipo de sistema, estándares regulatorios, requisitos del cliente o contractuales, nivel de riesgo, tipo de riesgo, objetivo de las pruebas, documentación disponible, conocimiento de los probadores, tiempo y presupuesto, ciclo de vida de desarrollo, modelos de caso de uso y experiencia previa en cuanto al tipo de defectos encontrados.

•

Algunas técnicas son más aplicables a ciertas situaciones y niveles de prueba; otras son aplicables a todos los niveles de prueba.

•

Los probadores normalmente, cuando crean los casos de prueba, usan una combinación de técnicas de prueba que incluye procesos, normas y técnicas “data-driven”, para asegurar una adecuada cobertura del objeto bajo prueba.

271

V – Técnicas de diseño de prueba 07 – Resumen Afirmaciones importantes del capítulo • Existen muchos procedimientos de prueba diferentes con objetivos distintos • Algunas pruebas requieren controladores de pruebas y stubs adicionales • Diferencia entre técnicas de caja negra y caja blanca • ¡El objetivo debería ser especificar con el mínimo esfuerzo los casos de prueba más relevantes! • La formación de clases de equivalencia en combinación con el análisis de valores límite debería aplicarse a cada objeto de prueba • Las pruebas referidas al estado tienen en cuenta los diferentes estados que puede adoptar un objeto de prueba durante su ejecución • En general los procedimientos de caja negra no pueden descubrir funciones desarrolladas adicionalmente a las funciones especificadas

272

V – Técnicas de diseño de prueba 07 – Resumen Afirmaciones importantes del capítulo • La ejecución del segmento del programa está en primer plano en la ejecución de las pruebas de caja negra y las pruebas de caja blanca • Las pruebas de caja blanca se utilizan en la fase más temprana de las pruebas • Las pruebas de caja negra se ponen en práctica en las fases más tardías con los métodos adecuados • Como complemento a los métodos mencionados anteriormente nunca debería prescindirse de la especificación intuitiva de casos de prueba • Las pruebas engloban diferentes métodos y procedimientos que pueden ser combinados con sentido

273

274

Capítulo VI – Gestión del proceso de pruebas • VI/01 Consideraciones previas generales • VI/02 Organización del equipo de pruebas • VI/03 Estimación y planificación de las pruebas • VI/04 Monitorización y control de las pruebas • VI/05 Gestión de la configuración • VI/06 Riesgo y pruebas • VI/07 Gestión de incidencias • VI/08 Resumen

275

VI – Gestión del proceso de pruebas 01 – Consideraciones previas generales Consideraciones previas. • Las pruebas sistemáticas de software y la gestión de la calidad disminuyen a largo plazo los costes de desarrollo y mantenimiento. • La utilización temprana de la gestión de pruebas minimiza los riesgos en la implantación y permite acortar los tiempos del desarrollo del proyecto. • La gestión de pruebas proporciona transparencia y es, al mismo tiempo, un indicativo valioso para el estado global del proyecto. • Dentro del ciclo de vida de un producto deben llevarse a cabo diferentes tareas de pruebas. • La gestión de pruebas temprana y profesional asegura a largo plazo las inversiones.

276

VI – Gestión del proceso de pruebas 02 – Organización del equipo de pruebas Generalidades. • Las pruebas son una actividad que se distribuye durante el proceso de desarrollo completo. • Desde el primer componente hasta la aceptación. • Las pruebas comienzan ya con la elaboración de los primeros documentos (en forma de revisiones). • En cada fase del desarrollo se dispone de diferentes objetos de prueba para los que a su vez se deben implantar diferentes procedimientos de pruebas. • Pruebas de componentes, pruebas de integración, pruebas de sistema, etc. • Para cada una de estas fases de pruebas deben formarse probadores o equipos de pruebas. • Hay que equilibrar los costes y el aprovechamiento. • Escoger al equipo de pruebas en base a las áreas.

277

VI – Gestión del proceso de pruebas 02.1 – Organización del equipo de pruebas Posibles formas de organización. 1. No hay probadores independientes. Los desarrolladores de software son responsables de las pruebas de su propio código. 2. Hay probadores independientes dentro del equipo de desarrollo. 3. Hay un equipo de pruebas independiente en la organización. Este grupo informa al gestor de proyecto. 4. Existen probadores independientes que forman parte del área de negocio o del área usuaria. 5. Existen equipos especializados en pruebas dentro del proyecto que asumen las actividades de pruebas, principalmente para objetivos específicos: usabilidad, seguridad o certificación de la funcionalidad. 6. Hay probadores independientes, externalizados o externos a la organización.

Junto al enfoque de pruebas de aplicaciones mostrado aquí se debe tener en cuenta durante la organización de los equipos de pruebas, que también se requiere una organización de pruebas adecuada para las revisiones.

278

VI – Gestión del proceso de pruebas 02.2 – Organización del equipo de pruebas Beneficios y desventajas de la independencia. •

Entre los beneficios de la independencia se incluyen: • •

•

Los probadores independientes ven diferentes defectos y son imparciales. Un probador independiente puede verificar suposiciones que ha hecho la gente durante la especificación e implementación del sistema.

Entre las desventajas se incluyen: • • •

Aislamiento del equipo de desarrollo (si la independencia es total). Los probadores de pruebas pueden ser el cuello de botella en tanto en cuanto son el último punto de control. Los desarrolladores pueden perder sensación de responsabilidad respecto de la calidad.

279

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas Perfiles. •

Para proyectos grandes, complejos o críticos desde el punto de vista de la seguridad de las personas, suele ser mejor tener múltiples niveles de prueba, siendo realizados algunos o todos ellos por probadores independientes. El personal de desarrollo puede participar en las pruebas, especialmente en los niveles más bajos, pero su falta de objetividad suele limitar su efectividad. Los probadores independientes pueden tener autoridad para requerir y definir procesos y reglas de pruebas pero los probadores sólo deberían asumir esos roles relacionados con el proceso sólo cuando hay un claro mandato al respecto.

•

Dependiendo de la fase o nivel de prueba y los riesgos relacionados con el producto y el proyecto, diferentes personas pueden asumir el papel de probador manteniendo un cierto grado de independencia. Los probadores típicos a nivel de componente y de integración de componentes serían los desarrolladores, en las pruebas de aceptación, expertos en negocio y usuarios y en la aceptación operativa los operadores. Las pruebas de sistema e integración de sistemas suelen ser llevadas a cabo por equipos independientes de prueba. 280

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas Perfiles. • En el marco de las pruebas se necesitan muchos colaboradores diferentes. Para diferentes tareas se requieren diferentes cualificaciones. • Se distinguen en este curso dos perfiles básicos: • Responsable de pruebas (test leader). • Probador (tester).

• Las actividades y tareas ejecutadas por estos dos roles dependen del proyecto y de la organización. • A veces al responsable de pruebas se le llama también gestor de pruebas o coordinador de pruebas. • El rol de responsable de pruebas puede ser realizado por un jefe de proyecto, gestor de desarrollo, gestor de aseguramiento de calidad o el jefe de un grupo de pruebas. • En proyectos más grandes pueden existir dos posiciones diferenciadas: responsable de pruebas y gestor de pruebas.

281

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas Perfiles. • Respecto a los probadores, en función del grado de especialización se puede hablar de: • Analista de pruebas. • Diseñador de pruebas. • Automatizador de pruebas. • Administrador del sistema de pruebas. • Ejecutor de pruebas.

• Se pueden diferenciar otros roles.

282

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas Perfil del responsable de pruebas. •

Entre las tareas típicas de un responsable de las pruebas se pueden incluir: • • • •

•

Coordinar la estrategia y el plan de pruebas con los jefes de proyecto y otros responsables. Escribir o revisar una estrategia de pruebas para el proyecto, así como una política de pruebas para la organización. Contribuir con la perspectiva de prueba en otras actividades del proyecto, como la integración de la planificación. Planificar las pruebas – considerando el contexto y comprendiendo los objetivos y riesgos de las pruebas – incluyendo la selección de enfoques de prueba, la estimación del tiempo, esfuerzo y coste de las pruebas, adquisición de recursos, definición de los niveles y ciclos de prueba y planificación de la gestión de incidencias. Iniciar la especificación, preparación, implementación y ejecución de las pruebas, monitorizar sus resultados y comprobar los criterios de finalización.

283

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas Perfil del responsable de pruebas. •

• • • • • •

Adaptar la planificación en base a los resultados y progresos de las pruebas (documentado en ocasiones en informes de estado) y tomar cualquier acción necesaria para compensar los problemas. Establecer una gestión de configuración del software relacionado con las pruebas, para asegurar la trazabilidad. Introducir métricas adecuadas para la medición del progreso de pruebas y evaluar la calidad de las pruebas y del producto. Decidir qué debería automatizarse, hasta donde y cómo. Seleccionar herramientas para dar soporte a las pruebas y organizar la formación de los probadores en su uso. Decidir sobre el levantamiento del entorno de pruebas. Escribir informes resumen de las pruebas basadas en la información recopilada durante éstas.

284

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas Perfil del responsable de pruebas. • Se necesitan experiencias especiales en las áreas de: • Pruebas de SW y gestión de la calidad. • Planificación y dirección de pruebas. • Experiencia en dirección de proyectos. • Capacidad para dirigir.

285

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas Tareas del probador. •

Entre las tareas típicas de un probador se pueden incluir: • • • • • •

• • • •

Revisar y contribuir en los planes de prueba. Analizar, revisar y evaluar los requisitos de usuario, las especificaciones y los modelos, para valorar qué tanto pueden ser probados. Crear especificaciones de pruebas Montar el entorno de prueba (frecuentemente coordinándose con los administradores de sistemas y administradores de red). Preparar y adquirir datos de prueba. Implementar pruebas a todos los niveles, ejecutar y registrar los resultados de las pruebas, evaluar los resultados y documentar las desviaciones respecto de los resultados esperados. Usar herramientas de administración o gestión de las pruebas y probar herramientas de monitorización según se necesite. Automatizar pruebas (puede ser soportado por un desarrollador o por un experto en automatización de las pruebas). Medir las prestaciones de componentes y sistemas (si aplica). Revisar las pruebas desarrolladas por otros.

286

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas. Perfiles Perfiles. • Analista y diseñador de pruebas. • Estudia la documentación de entrada con el fin de analizar, revisar y evaluar los requisitos de usuario, las especificaciones y los modelos, para valorar qué tanto pueden ser probados. • Propone las pruebas necesarias y establece el orden de su ejecución. • Conocimientos: • Conocimiento (Know-how) de desarrollo y pruebas. • Conocimientos de ingeniería de SW. • Conocimientos sobre métodos de análisis y de especificación.

• Automatizador de pruebas. • Comprueba las posibilidades de automatización y las lleva a cabo. • Conocimientos: • Experiencia como probador. • Conocimientos (Know-how) en diseño de pruebas y automatización. • Experiencia en programación. • Muy buenos conocimientos de las herramientas implantadas. 287

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas. Perfiles Perfiles. • Administrador del sistema de pruebas. • Implanta el entorno de las pruebas y lo gestiona. • Conocimientos: • • • •

Administración de sistemas (o acceso a un administrador de sistemas). Herramientas de desarrollo y pruebas. Sistemas de bases de datos, Redes en caso de ser necesario. Instalación y gestión del entorno del sistema.

• Ejecutor de las pruebas de software. • Ejecuta las pruebas en función de los supuestos / especificaciones. • Conocimientos: • • • •

Conocimientos generales de IT y básicos de pruebas. Manejo / parametrización de la herramienta implantada. Experiencia en la ejecución de pruebas. Conocimientos acerca del objeto de prueba.

288

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas. Perfiles Perfiles. • Experto técnico. • Completa el equipo de pruebas en caso de necesidad. • Pueden ser: • Administradores o diseñadores de bases de datos. • Expertos en interfases de usuario. • Especialistas en redes.

• Otros perfiles. • Según el planteamiento del problema, el entorno de pruebas, etc. pueden incorporarse otros especialistas al equipo de pruebas. • Aquí se necesitan conocimientos especiales en materias que no tengan relación con las pruebas, p.ej., expertos en usabilidad o psicólogos.

289

VI – Gestión del proceso de pruebas 02.3 – Organización del equipo de pruebas. Perfiles Perfiles. • Perfiles Soft • A las cualificaciones técnicas referidas se añaden factores como: • Capacidad de trabajo en equipo, habilidad política o diplomática. • Disponibilidad para consultar acerca de hechos evidentes. • Capacidad para imponerse, apariencia de seguridad. • Exactitud y creatividad. • Manejar con seguridad situaciones complejas.

• Comentario: Sin estas características añadidas un probador sólo tendrá un éxito condicional aunque sea muy competente en la materia.

290

VI – Gestión del proceso de pruebas 03.1 – Estimación y planificación de las pruebas Planificación. •

•

• •

En esta sección se cubre el propósito de la planificación de las pruebas, tanto en proyectos de desarrollo e implementación como en actividades de mantenimiento. La planificación puede documentarse en un plan de proyecto o en un plan maestro de pruebas y en planes de pruebas separados para cada nivel de prueba (como en las pruebas de sistema y de aceptación). El ‘Standard for Software Test Documentation’ (IEEE 829) bosqueja los documentos de planificación de las pruebas. La planificación está influida por la política de pruebas de la organización, el alcance de las pruebas, objetivos, riesgos, restricciones, criticidad, capacidad de ser probado y disponibilidad de los recursos. Cuanto más progrese el proyecto y la planificación de las pruebas, más información se encontrará disponible y más detalle podrá incluirse en el plan. La planificación de las pruebas es una actividad continua y se lleva a cabo a lo largo de todas las actividades y procesos del ciclo de vida. El uso de la realimentación que proporcionan las actividades de pruebas, permite reconocer riesgos de cambio, de forma que se pueda ajustar la planificación.

291

VI – Gestión del proceso de pruebas 03.2 – Estimación y planificación de las pruebas Actividades de planificación de las pruebas. •

Entre las actividades de planificación de las pruebas se puede incluir: • • • • • • • • • •

Determinar el alcance y los riesgos, e identificar los objetivos de las pruebas. Determinar el enfoque general a aplicar durante las pruebas (la estrategia de prueba), incluyendo la definición de los niveles de prueba y los criterios de finalización. Integrar y coordinar las actividades de prueba dentro de las actividades del ciclo de vida del software: adquisición, suministro, desarrollo, operación y mantenimiento. Tomar decisiones acerca de qué probar, que roles llevarán a cabo las actividades de prueba, como deberán hacerse las actividades de prueba y como se evaluarán los resultados de las pruebas. Planificar las actividades de análisis y diseño de las pruebas. Planificar la implementación, ejecución y evaluación de las pruebas. Asignar recursos a las diferentes actividades definidas. Definir la cantidad, nivel de detalle, estructura y plantillas para la documentación de prueba. Seleccionar métricas para la monitorización y controlar la preparación y ejecución de las pruebas, la resolución de defectos y los factores de riesgo. Establecer el nivel de detalle de los procedimientos de prueba con vistas a proporcionar suficiente información para soportar una preparación y ejecución de las pruebas reproducible. 292

VI – Gestión del proceso de pruebas 03.3 – Estimación y planificación de las pruebas Plan de pruebas. •

• •

Es el documento en el que se presenta el alcance, enfoque, recursos y planificación de las actividades de prueba. Asimismo, se identifica los elementos a probar, las características a probar, las tareas, el personal encargado de cada tarea y los riesgos asociados. El plan de pruebas, es adaptado y modificado a lo largo del proyecto. En el ‘Standard for Software Test Documentation’ (IEEE 829) se proporciona una recomendación de estructura para el plan de pruebas.

293

VI – Gestión del proceso de pruebas 03.4 – Estimación y planificación de las pruebas Plan de pruebas según IEEE 829. 1. 2.

Identificador del Plan de pruebas Introducción

9.

3.

Objetos de prueba

4.

Características que deben ser probadas

11. Necesidades de entorno (Infraestructura de pruebas)

5.

Características que no deben ser probadas

Entregables de pruebas

10. Tareas de pruebas

12. Responsabilidades, obligaciones 13. Personal y necesidades de formación 14. Planificación

6.

Estrategia de pruebas

7.

Criterios de aceptación y rechazo

15. Riesgos de la planificación e imprevistos

8.

Criterios para la interrupción y el reinicio de las pruebas

16. Aprobación y Autorización

294

VI – Gestión del proceso de pruebas 03.5 – Estimación y planificación de las pruebas Criterios de entrada •

•

Los criterios de entrada definen cuándo comenzar a probar, como por ejemplo, al principio de un nivel de pruebas o cuando se tiene un conjunto de pruebas preparado para su ejecución. Típicamente, los criterios de entrada pueden consistir en: • • • •

Disponibilidad y preparación del entorno de pruebas. Preparación de las herramientas de pruebas en el entorno de pruebas. Disponibilidad de código que se puede probar. Disponibilidad de datos de prueba.

295

VI – Gestión del proceso de pruebas 03.6 – Estimación y planificación de las pruebas Criterios de finalización (salida). •

•

El propósito de los criterios de finalización es definir cuando dejar de probar, como al final de un nivel de prueba o cuando un conjunto de pruebas tienen un objetivo específico. Típicamente, los criterios de finalización pueden consistir en: • • • • •

Medidas del grado de rigurosidad, como cobertura de código, funcionalidad o riesgo. Estimación de la densidad de defectos o medidas de fiabilidad. Coste. Riesgos residuales, como pueden ser el número de defectos no corregidos o la falta de cobertura de pruebas en ciertas áreas. Planificaciones, como las que se basan en el time to market.

296

VI – Gestión del proceso de pruebas 03.7 – Estimación y planificación de las pruebas Estimación de las pruebas. •

En este curso están cubiertas dos aproximaciones en la estimación del esfuerzo en pruebas: • •

• •

La aproximación basada en métricas: estimar el esfuerzo en pruebas basándose en métricas de proyectos previos o similares o en valores típicos. La aproximación basada en la experiencia: la estimación queda a cargo del propietario (encargado) de las tareas o de expertos.

Una vez estimado el esfuerzo en pruebas, pueden identificarse recursos y prepararse una planificación. El esfuerzo en pruebas puede depender de múltiples factores, entre los que se incluyen: •

•

•

Características del producto: la calidad de la especificación y de otra información utilizada en los modelos de prueba (esto es, las bases de prueba), el tamaño del producto, la complejidad del dominio del problema, los requisitos de fiabilidad y seguridad y los requisitos de documentación. Características del proceso de desarrollo: la estabilidad de la organización, herramientas usadas, proceso de pruebas, capacidades de las personas involucradas y presión de tiempo. Los resultados de las pruebas: el número de defectos y la cantidad de re-trabajo requerida. 297

VI – Gestión del proceso de pruebas 03.8 – Estimación y planificación de las pruebas Estrategia de Pruebas, Aproximación de pruebas •

La Aproximación o Enfoque de las pruebas es la implementación de la Estrategia de pruebas para un proyecto específico

•

Típicamente incluye decisiones tomadas basándose en los objetivos de las pruebas y la evaluación de riesgos.

•

Es el punto de partida para: • • •

•

La planificación del proceso de pruebas. La selección de las técnicas y tipos de pruebas a llevar a cabo. La definición de los criterios de entrada y de salida.

La selección del enfoque de las pruebas debería considerar el contexto, incluyendo: • • • • •

Riesgo de fallo en el proyecto, peligros que pueden afectar al producto y riesgos de fallo del producto que pueden afectar a las personas, al entorno y a la compañía. Capacidades y experiencia de las personas en las técnicas de prueba, las herramientas y los métodos. El objetivo de esfuerzo de las pruebas y la misión del equipo de pruebas Aspectos reguladores, como las regulaciones internas y externas que aplican al equipo de desarrollo. La naturaleza del producto y del negocio. 298

VI – Gestión del proceso de pruebas 03.8 – Estimación y planificación de las pruebas Estrategia de Pruebas, Aproximación de pruebas •

Una forma de clasificar las aproximaciones o enfoques de prueba se basa en el momento en el que se inicia el diseño de las pruebas: • •

•

Enfoques preventivos, en los que las pruebas se diseñan tan pronto como se puede. Enfoques reactivos, en los que el diseño se realiza después de que se ha producido el software o el sistema.

Entre los enfoques o estrategias típicos se incluyen: • • • • •

Enfoques analíticos, como las pruebas basadas en riesgos, en las que la prueba se orienta a las áreas de mayor riesgo. Enfoques basados en modelos, como las pruebas estocásticas, en los que se utiliza información estadística acerca de los ratios de fallo (como los modelos de crecimiento de fiabilidad) o uso (como los perfiles operacionales). Enfoques metódicos como los basados en fallos (incluyendo error guessing y fault-attacks), los basados en la experiencia, los basados en listas de comprobación y los que se basan en características de calidad. Enfoques que cumplen procesos o estándares, como los especificados por estándares industriales o las metodologías “agiles”. Enfoques dinámicos y heurísticos como las pruebas exploratorias en las que las pruebas reaccionan a los eventos más que lo que se haya podido planear por anticipado, y en las que la ejecución y la evaluación son tareas concurrentes.

299

VI – Gestión del proceso de pruebas 03.8 – Estimación y planificación de las pruebas Estrategia de Pruebas, Aproximación de pruebas • •

•

Enfoques de consulta, como aquellos en los que la cobertura de pruebas está dirigida principalmente por el asesoramiento y guía de expertos en el dominio tecnológico y/o de negocio, fuera del equipo de pruebas. Enfoques centrados en la regresión, como aquellos que incluyen la reutilización de material de pruebas existente, automatización exhaustiva de pruebas de regresión y suites de prueba estándar.

Pueden combinarse diferentes enfoques, por ejemplo, un enfoque dinámico basado en riesgo.

300

VI – Gestión del proceso de pruebas 04.1 – Monitorización y control del proceso de prueba Monitorización. •

El propósito de la monitorización de las pruebas es proporcionar realimentación y visibilidad de las actividades de prueba. La información a monitorizar puede ser recogida de forma manual o automática y puede utilizarse para medir criterios de salida, como la cobertura. Pueden utilizarse también métricas para valorar el progreso respecto del calendario y presupuesto planificados. Entre las métricas de prueba comunes se incluyen: • • • • • • • •

Porcentaje de trabajo realizado en la preparación de casos de prueba (o porcentaje de casos de prueba preparados). Porcentaje de trabajo realizado en la preparación del entorno de pruebas. Ejecución de casos de prueba (por ejemplo: número de casos de prueba que se han lanzado / que no se han lanzado y casos de prueba que han pasado / que han fallado. Información de defectos (por ejemplo, densidad de defectos, defectos encontrados y corregidos, ratio de fallos y resultados de las re-pruebas). Cobertura de pruebas respecto a requisitos, riesgos o código. Confianza subjetiva de los probadores en el producto. Fechas de hitos de prueba. Costes de las pruebas, incluyendo el coste comparado con los beneficios de encontrar el siguiente defecto o de lanzar la siguiente prueba.

301

VI – Gestión del proceso de pruebas 04.2 – Monitorización y control del proceso de prueba Informes de pruebas •

Se trata de resumir información relativa al esfuerzo en pruebas, incluyendo: • •

•

Qué ha ocurrido y cuando ha ocurrido, como, por ejemplo, las fechas en las que se han alcanzado los criterios de finalización. Información y métricas analizadas para dar soporte a las recomendaciones y decisiones que haya que tomar, como, por ejemplo, una evaluación de los defectos que no han sido corregidos, el coste / beneficio económico de seguir probando, los riesgos más destacados y una valoración (una estimación del nivel de confianza) del software probado.

Deberían recogerse métricas durante y al final de cada nivel de prueba, con vistas a valorar: • • •

La adecuación a este nivel de los objetivos de prueba. La adecuación del enfoque de pruebas elegido. La efectividad de las pruebas respecto de sus objetivos.

302

VI – Gestión del proceso de pruebas 04.2 – Monitorización y control del proceso de prueba Informes de pruebas •

En el ‘Standard for Software Test Documentation’ (IEEE 829) se recomienda una estructura para el informe resumen de las pruebas: • • • • • • • •

Identificador del documento Resumen Variaciones Evaluación comprensible Resumen de resultados Evaluación Resumen de actividades Aprobación.

303

VI – Gestión del proceso de pruebas 04.3 – Monitorización y control del proceso de prueba Control de las pruebas •

•

Dentro del control de las pruebas se considera cualquier guía o acción correctiva tomada como resultado de información y métricas recogidas e informadas. Las acciones pueden cubrir cualquier actividad de prueba y pueden afectar a cualquier otra actividad o tarea del ciclo de vida del software. Ejemplos de acciones de control de las pruebas son: • • • •

Toma de decisiones basadas en la información de monitorización de las pruebas. Repriorización de las pruebas cuando ocurre un riesgo identificado (por ejemplo, software suministrado tarde). Cambios en el calendario de pruebas debido a la no disponibilidad de un entorno de pruebas. Establecimiento de un criterio de entrada que requiera que las correcciones hayan de ser vueltas a probar (prueba de confirmación) por un desarrollador antes de aceptarlas en un “build”.

304

VI – Gestión del proceso de pruebas 05 – Gestión de la configuración Generalidades. • En el transcurso del desarrollo de software se producen una gran cantidad de datos / informaciones/ resultados. • Comenzando con los requisitos. • Las especificaciones y el diseño del sistema. • Componentes individuales y elementos integrados. • Versiones completas del sistema.

• Dentro del proyecto existe un gran número de diferentes colaboradores que deben trabajar juntos en los objetos mencionados anteriormente. • Las partes individuales pasan por diferentes manos y son modificadas en diferentes lugares.

305

VI – Gestión del proceso de pruebas 05 – Gestión de la configuración Generalidades. • Para mantener la perspectiva, cada documento, cada dato, cada versión del programa debe ser descrito y catalogado claramente. • Se asignan sucesivas versiones numeradas del software, etc. • Las autorizaciones para su elaboración posterior son anotadas, etc. • Las modificaciones se posponen para un control posterior.

306

VI – Gestión del proceso de pruebas 05 – Gestión de la configuración Generalidades. • Todas las tareas mencionadas anteriormente se engloban bajo el término de gestión de la configuración • El objetivo de la gestión de la configuración es establecer y mantener la integridad de los productos (Componentes, datos y documentación) del software o del sistema durante el proyecto y el ciclo de vida del producto • Se trata en este caso de una función transversal dentro del proyecto – todas las modificaciones deben ser recogidas de forma centralizada y poder ser dadas a conocer según un esquema claramente definido • Según el tipo y el alcance del proyecto pueden variar en gran medida los requerimientos para la gestión de la configuración – se debe definir un plan de gestión de la configuración individualizado • En la IEEE 828 se dispone de un estándar para la gestión de la configuración y sus planes correspondientes

307

VI – Gestión del proceso de pruebas 05 – Gestión de la configuración Problemas típicos. • Si se desatiende la gestión de la configuración surgirán casi irremediablemente p.ej., los siguientes problemas: • “Confusión de versiones” – confusión acerca de que versiones de los ficheros van juntas, qué versiones son actuales – ¡se programa en base a especificaciones “antiguas”! • ¿Dónde y cuando se modificó algo? ¿Quién lo hizo? – Una modificación paralela de los datos es posible... Las modificaciones pueden ser en ocasiones sobrescritas. • ¿Qué versión de los ficheros se probó? – ¡Sin indicaciones claras acerca de las versiones se dificultan las pruebas y su valoración!

308

VI – Gestión del proceso de pruebas 05 – Gestión de la configuración Requisitos de la gestión de configuración. • Desde el punto de vista de un probador la gestión de la configuración permite que todos los elementos de testware se puedan identificar, versionar y controlar. Que se pueda hacer un seguimiento de los cambios y tener trazabilidad con los componentes desarrollados y probados: • Gestión de versiones. • Catalogar, almacenar y recuperar las diferentes versiones de un objeto (V1.0, V1.1 etc.)

• Registro de comentarios y motivos de modificación. • Administración de configuraciones. • Determinación y administración de todos los datos de la versión correspondiente que pueden juntarse en un sistema parcial.

• Seguimiento del estado. • El seguimiento de errores y modificaciones, el registro de reportes de problemas y la posibilidad de poder hacer el seguimiento de su conversión. 309

VI – Gestión del proceso de pruebas 05 – Gestión de la configuración Comprobación de la configuración. • Una comprobación de la configuración se implanta para verificar la efectividad de la gestión de la configuración. • Dentro de la comprobación de la configuración de comprueba entre otras cosas: • Si todos los componentes han sido recogidos en la gestión de la configuración. • Si las configuraciones pueden ser siquiera identificadas.

310

VI – Gestión del proceso de pruebas 06 – Riesgo y pruebas Definición de riesgo. •

Un riesgo es la posibilidad de que ocurra un evento con consecuencias no deseadas, un problema potencial. El nivel de riesgo vendrá determinado por la probabilidad de que ocurra el evento adverso y por el impacto (el daño resultante).

311

VI – Gestión del proceso de pruebas 06.1 – Riesgo y pruebas Riesgos del proyecto. • • •

Los riesgos asociados a proyecto que puedan influir en el éxito de éste deben ser gestionados. Se ha de estimar la probabilidad de que ocurra y el daño potencial. Implementar medidas para tratar los riesgos identificados. • • • •

•

Evitar riesgos Mitigar riesgos (preparar de forma activa medidas para reducir la probabilidad y/o el daño potencial). Controlar riesgos (preparar medidas necesarias si el riesgo se transforma en un problema, reservar tiempo y dinero). Ignorar el riesgo (esperar que los riesgos no acaben generando un problema, rezar, cruzar los dedos, etc).

Las tres primeras opciones cuestan dinero, la cuarta puede costar mucho dinero.

312

VI – Gestión del proceso de pruebas 06.1 – Riesgo y pruebas Riesgos típicos en un proyecto. •

Factores organizativos. • • • •

•

Factores técnicos. • • • • • •

•

Falta de recursos o de capacidad. Problemas personales entre equipos o entre miembros del mismo equipo. Insuficiente cooperación entre departamentos. Estimaciones no realistas. Requisitos incorrectos, incompletos o no realistas. No se pueden satisfacer los requisitos debido a la existencia de ciertas restricciones Tecnologías, métodos o herramientas nuevos. Baja calidad del diseño, del código o de las pruebas. No disponibilidad del entorno de pruebas a tiempo. Conversión de datos tardía, planificación y desarrollo de la migración y herramientas de migración/conversión de datos de prueba.

Riesgos asociados al proveedor. • • •

Cambios debidos a requisitos legales. Problemas contractuales con el suministrador. Mala calidad de los productos proporcionados por suministradores nuevos. 313

VI – Gestión del proceso de pruebas 06.2 – Riesgo y pruebas Riesgos asociados al producto. •

Se entiende como riesgos asociados a producto aquellas áreas de fallo potencial en el software o en el sistema que son un riesgo para la calidad del producto. Ejemplos: • • • • • •

•

•

La funcionalidad del producto suministrado es insuficiente. Atributos no funcionales insuficientes. Integridad y Calidad de los datos pobre. El producto no se ajusta al uso para el que estaba previsto, por lo que no puede implantarse en producción. El producto puede causar daños a la propiedad. El producto puede causar accidentalmente heridas o muerte.

El nivel de riesgo identificado sirve para decidir donde empezar a probar y donde se debe probar más. Se prueba para reducir la probabilidad de que ocurra el efecto negativo o para reducir el impacto. Los riesgos de producto son un tipo especial de riesgo que afectan al éxito de un proyecto. Las pruebas son una actividad de control de riesgos que proporciona información acerca del riesgo residual, mediante la medición de la efectividad de la eliminación de defectos críticos y planes de contingencia o evitar los riesgos asociados al producto. 314

VI – Gestión del proceso de pruebas 06.2 – Riesgo y pruebas Gestión de los riesgos del producto. •

Gestionar los riesgos del producto mediante las pruebas basadas en riesgo. • •

Se han de identificar, analizar y priorizar los riesgos. Los riesgos deben tenerse en cuenta desde la fase de planificación de las pruebas: • Seleccionando métodos de prueba para mitigar los riesgos. • Asignando un nivel de profundidad en las pruebas acorde al nivel de riesgos. • Adaptando el orden de la ejecución de los casos de prueba (primero los casos que puedan localizar errores críticos, de forma que se puedan encontrar lo antes posible).

•

•

Actualizar la hoja de evaluación de riesgos regularmente. Los riesgos pueden desaparecer o cambiar y pueden aparecer nuevos riesgos (nuevas funciones solicitadas).

Beneficios de las pruebas basadas en riesgo. • • • •

Se escogen métodos de prueba para mitigar los riesgos identificados. El alcance de las pruebas toma en consideración los riesgos identificados. De esta forma, los esfuerzos en pruebas se centran en la reducción del riesgo. Los errores que generan mayor nivel de riesgo se encuentran antes, por lo que es más económico corregirlos. Aún en el caso de que haya que parar las pruebas, se asegura que los casos de prueba más importantes han sido ejecutados (priorización de las pruebas basada en riesgos).

315

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Localización de errores durante el trabajo de pruebas. • Los probadores ejecutan las pruebas especificadas y documentan los resultados. • A continuación sigue la investigación acerca de las desviaciones entre los resultados esperados y obtenidos. • Los efectos de los errores se hacen públicos. • En este punto el probador ha cumplido hasta el momento con su tarea. • Ahora espera a someter a una repetición de las pruebas a la versión corregida. • La gestión y supervisión posterior de la eliminación de errores es asumida a partir de este punto por la gestión de incidencias.

316

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Tareas de la gestión de incidencias. • En la gestión de incidencias se recogen todos las incidencias / errores encontrados en el proyecto. • Además de su recogida y administración se establecen informaciones adicionales para los errores individuales. • Se determina la gravedad del error. • Estado del error- p.ej., abierto, en proceso de trabajo, solucionado… • Todas las informaciones se almacenan en una base de datos central. • Aquí es posible un tratamiento sin redundancias. • Se proporciona una visión óptima acerca de los errores encontrados y su tratamiento.

317

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Tareas de la gestión de incidencias. • Sin un proceso de gestión de incidencias en funcionamiento no se puede tener un tratamiento ordenado de las mismas. • La gestión de incidencias debe construirse al principio del proyecto. • Algunos puntos que deben ser considerados para una gestión correcta de incidencias son: • Proporcionar notificaciones / formularios de notificación comunes. • Todos las incidencias / errores / problemas deben ser recogidos, independientemente de parte de qué persona involucrada en el proceso provengan y de dónde hayan aparecido. • Se debe definir una manera de proceder determinada para el tratamiento de las incidencias (definir el proceso). • Debe de existir en la organización unas normas establecidas para clasificar las incidencias.

318

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Reparto de tareas. •

Probador. • Ejecuta las pruebas para detectar errores. • Documenta los resultados (Documentación de pruebas). • Registra los errores en la base de datos (Notificación de errores y desviaciones).

•

Gestor de pruebas. • Evalúa las notificaciones de errores. • Otorga prioridades (de acuerdo con el director de proyecto, el cliente, ...) • Supervisa el tratamiento.

319

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Reparto de tareas. •

Gestión de las modificaciones o Change Control Board (CCB) • Toma decisiones sobre las modificaciones y su priorización.

•

Desarrollador. • Corrige los errores de acuerdo con sus prioridades. • Lleva a cabo todas las modificaciones acordadas.

•

Las tareas se resuelven en un proceso iterativo: • Probador • Gestor de pruebas • Gestión de las modificaciones (o CCB) • Desarrollador

320

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Notificación de incidencia (informe de incidencias) •

Objetivos. - Proporcionar a los desarrolladores y otros roles de la organización, información sobre los problemas detectados para permitir su identificación y corrección en caso necesario. - Proporcionar a los responsables de pruebas un medio de seguimiento de la calidad del sistema bajo prueba y del progreso de las pruebas. - Proporcionar ideas para la mejora del proceso de pruebas.

321

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Contenido de una notificación de incidencia (informe de incidencias). •

La notificación del error / incidencia debería contener al menos los siguientes puntos: • Datos de la incidencia. • Número único (p.ej., asignación secuencial). • Datos acerca del objeto de prueba (nombre, versión). • Entorno de pruebas. • Nombre del notificador. • Fecha de la primera aparición.

• Clasificación de la incidencia. • Clase de la incidencia. • Estado de la incidencia (nueva, repetición de las pruebas, etc.). • Prioridad (primera valoración del notificador acerca de su urgencia).

322

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Contenido de una notificación de incidencia (informe de incidencias). • Descripción. • Descripción breve. • Descripción detallada de los pasos realizados durante la prueba que permitan su reproducción y resolución, incluyendo toda la información adicional que se considere importante (logs, datos de prueba, capturas de pantalla, etc.). • Caso de prueba que ha provocado la incidencia (proporciona toda la información acerca de las condiciones). • Caso de prueba (proporciona toda la información acerca de las condiciones). • Efecto de la incidencia. • Origen de la incidencia. • Referencia a notificaciones relacionadas. • Comentarios. • Eventualmente medidas de corrección adoptadas.

•

El gestor de pruebas debe realizar adaptaciones del formato de la notificación de incidencias a cada proyecto concreto. 323

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Clases. • La gravedad de una incidencia / error se determina según su clase: • Las clases se pueden formar libremente. • Las clases proporcionan diferentes niveles que se puede asignar a una incidencia (críticas, graves, medias, ligeras). • La base para la clasificación puede ser el grado de perjuicio en la implantación del producto [DIN 66271].

324

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Priorización. • El tratamiento / la corrección de errores se lleva a cabo en función de la prioridad asignada: • Un criterio de priorización en sin duda la gravedad del error, en la que se tienen en cuenta los efectos del mismo. • Otros criterios pueden ser también el desarrollo del proyecto, etc. ¿En que medida se impide el desarrollo posterior del proceso? • Las prioridades podrían ser: eliminación indispensable, eliminación en el siguiente tratamiento posterior del objeto, etc.

325

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Estado de la incidencia. • El estado de la incidencia determina en que fase de elaboración se encuentra. • Posibles caracterizaciones pueden ser: • Nuevo – el error o incidencia ha sido notificado por primera vez por parte del probador.

• Abierto – la notificación se liberó por parte del gestor de pruebas. • Rechazado – la notificación fue rechazada por el gestor de pruebas. • Investigado – el desarrollador intenta identificar el error. • Observación – no se puede identificar el error, está en observación. • En proceso – el error se ha liberado para su corrección (en caso contrario se rechaza).

• Repetición de la prueba –se asigna por parte del desarrollador después de la corrección.

• Solucionado – se asigna por el probador cuando el error se demuestra eliminado después de la repetición de la prueba.

• No solucionado – la asigna el probador cuando el error continúa apareciendo.

326

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Ejemplo de ciclo de vida de un error / incidencia. • Se pueden dar las siguientes transiciones de estado:

Nuevo Observación Abierto Rechazado Investigado En proceso de corrección No resuelto

Prueba

Resuelto

327

VI – Gestión del proceso de pruebas 07 – Gestión de incidencias Estados. • Sólo un probador puede confirmar un error como solucionado. • El gestor de pruebas o el gestor de modificaciones decide si una incidencia debe ser rechazada o trabajada en base a las informaciones disponibles acerca del suceso y los costes de su eliminación. • Todas las modificaciones junto a los comentarios se recogen en la gestión de incidencias. • Se proporciona un control constante sobre su tratamiento. • Se puede determinar la continuación de las pruebas. • En su caso se deben generar nuevos casos de prueba si la incidencia en cuestión no surgió durante la comprobación mediante casos de prueba.

328

VI – Gestión del proceso de pruebas 08 – Resumen Afirmaciones importantes del capítulo. • Para poder llevar a cabo pruebas efectivas deberían separase organizativamente en los niveles más altos de las pruebas las actividades de desarrollo y de pruebas. • Dentro del proceso de pruebas se requieren colaboradores con distintos conocimientos especiales de pruebas (p.ej., conocimientos relacionados con la ergonomía o la seguridad). • Junto a la competencia técnica también se requiere de una competencia social. • La planificación, la supervisión y la dirección de cada uno de los ciclos de pruebas pertenecen a las tareas centrales del gestor de pruebas.

329

VI – Gestión del proceso de pruebas 08 – Resumen Afirmaciones importantes del capítulo. • Las consideraciones económicas juegan un papel determinante en la gestión de las pruebas. • Un proceso de pruebas eficiente presupone una buena gestión de errores y configuración. • La base para un tratamiento de errores funcional es el registro común siguiendo un esquema único a lo largo de todas las etapas del análisis de errores. • Las normas y estándares contienen supuestos para la ejecución técnicamente correcta de pruebas de software.

330

331

Capítulo VII – Herramientas de pruebas • VII/01 Tipos de herramienta de pruebas • VII/02 Uso efectivo de las herramientas: beneficios y riesgos potenciales • VII/03 La introducción de una herramienta en una organización • VII/04 Resumen

332

VII – Herramientas de pruebas 01.1 – Tipos de herramienta de prueba Significado y propósito del soporte a pruebas mediante herramientas •

Las herramientas de pruebas pueden dar soporte a una o varias actividades de pruebas. Incluyen: • • • •

•

Herramientas utilizadas directamente en las pruebas, como herramientas de ejecución de pruebas, de generación de datos y de comparación de resultados. Herramientas para ayudar en la gestión del proceso de pruebas y en el reporte y monitorización de la ejecución de las pruebas. Herramientas usadas en la exploración (ej.: herramientas que monitorizan la actividad de un fichero para una aplicación) Cualquier herramienta que de soporte a las pruebas (ej.: una hoja Excel)

Propósitos del uso de herramientas para el soporte a pruebas: • • • •

Mejorar la eficiencia automatizando tareas repetitivas o dando soporte a tareas manuales de pruebas (como planificación, diseño, reporting…) Automatizar actividades que requieran un número significativo de recursos en caso de hacerse manualmente (como el análisis estático) Automatizar actividades que no pueden ejecutarse manualmente (como las pruebas de prestaciones a gran escala) Aumentar la fiabilidad de las pruebas (ej.; automatización de comparaciones de grandes datos o simulación de comportamiento) 333

VII – Herramientas de pruebas 01.2 – Tipos de herramienta de prueba Clasificación de las herramientas de prueba •

Las tareas de pruebas pueden tanto apoyarse en herramientas (Tools) como automatizarse mediante ellas. • El apoyo de herramientas tiene sentido en aquellas áreas en las que se trabaja de forma “creativa”. • La pura ejecución de las pruebas - el doing - puede automatizarse mediante herramientas.

•

La totalidad de las herramientas se denomina en relación al concepto CASE (Computer Aided Software Engineering), CAST-Tools (Computer Aided Software Testing).

•

Las herramientas se diferencian según su utilización. Para cada etapa del proceso de pruebas se dispone de diferentes herramientas. Algunas de ellas pueden ser utilizadas para dar soporte a más de una actividad. En tal caso se clasificará en base a la actividad a la que esté más ligada.

•

334

VII – Herramientas de pruebas 01.2 – Tipos de herramienta de prueba Clasificación de las herramientas de prueba (Cont.) •

•

Algunas herramientas dan soporte a un tipo de actividad. Hay vendedores que ofrecen familias de herramientas (suites) que proporcionan soporte a la mayoría o a todas las actividades asociadas al proceso de pruebas (HPQuality Center, IBM-Rational, Borland…) Las herramientas son particularmente útiles cuando hay tareas repetitivas proporcionando: • •

•

•

Mejoras en la eficiencia Mejoras en la fiabilidad

Algunas herramientas pueden ser intrusivas, pudiendo afectar al tiempo de respuesta de la aplicación, por ejemplo: las herramientas de cobertura de código (instrumentalización) o las de análisis de prestaciones (marcaje de tiempos). Al tiempo adicional se le denomina efecto sonda. Hay herramientas que son particularmente útiles a los desarrolladores. En este curso se marcarán con una “D”.

335

VII – Herramientas de pruebas 01.2 – Tipos de herramienta de prueba Clasificación de las herramientas de prueba (Cont.) 1.- Herramientas de soporte a la gestión y ejecución de las pruebas A) Herramientas de gestión de pruebas B) Herramientas de gestión de requisitos C) Herramientas de gestión de incidencias D) Herramientas de gestión de configuración 2.- Herramientas de soporte a las pruebas estáticas A) Herramientas de revisión B) Herramientas para el análisis estático (D) C) Herramientas de modelado (D) 3.- Herramientas de soporte a la especificación de pruebas A) Herramientas para el diseño de las pruebas B) Herramientas de preparación de datos de prueba 4.- Herramientas de soporte a la ejecución y el registro de resultados A) Herramientas para la ejecución de pruebas (Robots de pruebas, Depuradores (D) y controladores de prueba). B) Herramientas que proporcionan marcos de pruebas unitarias (frameworks) o armazones de prueba (D). C) Comparadores de prueba. D) Herramientas de medida de cobertura (D). E) Herramientas de prueba de seguridad. 5.- Herramientas de soporte al rendimiento y monitorización A) Herramientas de análisis dinámico (D). B) Herramientas de pruebas de rendimiento, carga y estrés. C) Herramientas de monitorización 6.- Herramientas de soporte para áreas de aplicación específicas 7.- Otras herramientas.

336

VII – Herramientas de pruebas 01.3 – Tipos de herramienta de prueba 1.- Herramientas de soporte a la gestión y ejecución de las pruebas A) Herramientas de gestión de pruebas • •

También conocidas como herramientas para la gestión de los casos y el proceso de prueba . Apoyo al probador en la administración y la gestión de pruebas. • Seguimiento de la ejecución de las pruebas y el estado de los casos de pruebas. • Interfaz con herramientas: • • • •

Ejecución de casos. Gestión de incidencias. Gestión de requisitos. Gestión de configuración.

• Soporte a la trazabilidad de requisitos-casos-resultados-incidencias. • Registro y administración de los casos, datos y resultados de prueba. • Documentación de las pruebas. • Generación automática de documentos como el plan de pruebas o los informes de pruebas. En general, documentación de las pruebas a partir de la información registrada (directa, resumida o procesada). 337

VII – Herramientas de pruebas 01.3 – Tipos de herramienta de prueba B) Herramientas de gestión de requisitos •

•

Hay quien considera que este tipo de herramientas no es, propiamente, una herramienta de pruebas. En cualquier caso, gran parte de las pruebas se basan en la comprobación de requisitos, por lo que las herramientas de gestión de requisitos, que ayudan a mejorar la calidad de éstos, facilitan y mejoran la calidad del trabajo de pruebas. Entre la funcionalidad que pueden proporcionar está: • • • • • •

•

Almacenar el texto de los requisitos. Almacenar atributos de los requisitos (fecha de modificación, origen, tipo, prioridad…). Comprobar la consistencia y la indefinición de requisitos (requisitos perdidos). Ayudar a la priorización de los requisitos. Ayudar a la trazabilidad de pruebas a requisitos, funciones y/o características (y viceversa): trazabilidad hacia delante y hacia atrás. Trazabilidad entre niveles de requisitos. Proporcionar interfaces con herramientas de gestión.

También puede reportarse el grado de cobertura de requisitos, funciones y/o características que proporciona un conjunto de pruebas.

338

VII – Herramientas de pruebas 01.3 – Tipos de herramienta de prueba C) Herramientas de gestión de incidencias •

•

En ocasiones, a estas herramientas se las denomina herramientas de seguimiento de defectos, de gestión de defectos, “bug tracking”. Es mejor hablar de gestión de incidencias porque puede haber anomalías no asociadas a defectos, solicitudes de mejora, etc. Las herramientas de gestión de incidencias almacenan y gestionan registros de incidencia. Asimismo, proporciona soporte a la gestión de las incidencias de varias formas, entre las que se incluye: • • • • • • •

•

Asociar atributos para su tipificación. Facilitar su priorización. Asignar acciones a las personas (por ejemplo, corregir o realizar pruebas de confirmación). Atribuirle un estado (por ejemplo, abierto, rechazado, duplicado, preparado para probar, diferido hasta la siguiente release, cerrado). La definición de estados suele ser “abierta”. Soporte a la generación de informes. Análisis estadístico. Asociar información adicional (correos, pantallazos…).

La funcionalidad de gestión de incidencias puede (de hecho, suele) estar incluida en herramientas de gestión de pruebas. 339

VII – Herramientas de pruebas 01.3 – Tipos de herramienta de prueba D) Herramientas de gestión de configuración •

Al igual que en los requisitos, las herramientas de gestión de la configuración (Configuration Management - CM) no son estrictamente herramientas de prueba, pero suelen ser necesarias para llevar a cabo el seguimiento de las diferentes versiones del software y de las pruebas.

•

Son particularmente útiles cuando se desarrolla en más de una configuración de entornos hardware / software (por ejemplo, para diferentes versiones de sistema operativo, diferentes librerías o compiladores, diferentes navegadores o diferentes ordenadores).

•

Las herramientas de gestión de la configuración: • • • • •

Almacenan información, no sólo de las versiones del software, sino también de los programas relacionados con las pruebas. Ayudan a mantener la trazabilidad entre los productos software y el software y documentación relacionado con las pruebas. Incluyen gestión de builds y releases. Ayudan a controlar el acceso a la información de prueba (seguridad de datos). Ayudan a la gestión de líneas base.

340

VII – Herramientas de pruebas 01.4 – Tipos de herramienta de prueba 2.- Herramientas de soporte a las pruebas estáticas A) Herramientas de revisión •

Dentro de los diversos tipos de revisión existentes, las herramientas de revisión (también conocidas como herramientas de soporte al proceso de revisión) son tanto más útiles: • • •

•

Cuanto más formal sea el proceso. Cuanta más gente participe en el proceso. Cuanto más repartida físicamente se encuentre.

Entre las características que puede incluir una herramienta de soporte a las revisiones están: • • • • • • • •

Almacenar información acerca de los procesos de revisión. Almacenar, organizar, comunicar y ayudar al seguimiento de los comentarios. Generar informes acerca de los defectos y el esfuerzo necesario para su resolución. Gestionar reglas y/o listas de comprobación (checklist). Realizar el seguimiento de la trazabilidad entre documentos y código fuente. Proporcionar ayuda a las revisiones online, lo que resulta útil si el equipo se encuentre dispersado geográficamente. Monitorizar el estado de cada revisión (pasada, pasada con correcciones…). Recoger e informar métricas. 341

VII – Herramientas de pruebas 01.4 – Tipos de herramienta de prueba B) Herramientas para el análisis estático (D) • •

•

Complementan el análisis realizado por los compiladores. De hecho, algunos compiladores incorporan características de análisis estático Están asociadas al lenguaje de programación: una herramienta puede analizar un número limitado de lenguajes. ¡Antes de adquirir una herramienta de este tipo, hay que considerar y prever, de ser posible, las tecnologías con las que se va a trabajar a corto y medio plazo! Estas herramientas pueden utilizarse, no sólo para analizar el código de la aplicación, sino también otros elementos como requisitos, websites… • Cálculo de métricas como los niveles de anidamiento, complejidad ciclomática, etc. Alguna de estas métricas pueden utilizarse para análisis de riesgos: Mayor complejidad, mayor posibilidad de error • Refuerzo de estándares de codificación • Análisis de flujos de control (estructuras, dependencias…) • Soporte a la comprensión del código (representación gráfica de la estructura del programa) • Localización de anomalías en el flujo de datos

342

VII – Herramientas de pruebas 01.4 – Tipos de herramienta de prueba C) Herramientas de modelado (D) •

Al margen de ser una herramienta de soporte al diseño de software y, por tanto, utilizadas por los desarrolladores, estas herramientas pueden ser utilizadas en las pruebas: •

• • •

Validando modelos de software. Por ejemplo, un comprobador de modelos de base de datos puede localizar defectos e inconsistencias en el modelo de datos. Ello complementa las pruebas: se puede haber lanzado un caso de prueba contra un dato, que el resultado sea correcto, pero que haya otro dato en la base de datos inconsistente con el anterior y pueda generar un error. Ayudando a identificar y priorizar áreas de prueba Otras herramientas de modelado pueden localizar defectos en un modelo de estado o de objetos. Estas herramientas pueden ayudar frecuentemente en la generación de algunos casos de prueba basados en el modelo (véase también más abajo las herramientas de diseño de pruebas)

El principal beneficio de las herramientas de análisis estático y las de modelado es el ahorro en costes asociado a encontrar más defectos en etapas tempranas del proceso de desarrollo (antes de lanzar las pruebas dinámicas). Como resultado, el proceso de desarrollo puede acelerarse y mejorarse al existir menos re-trabajo. 343

VII – Herramientas de pruebas 01.5 – Tipos de herramienta de prueba 3.- Herramientas de soporte a la especificación de pruebas A) Herramientas para el diseño de las pruebas •

Las herramientas de diseño de pruebas generan entradas o ejecutables de prueba a partir de: • • • • •

• • •

Los requisitos. De una interfaz gráfica de usuario. De modelos de diseño (de estado, datos u objetos). Del código. De condiciones de prueba.

También pueden generar resultados esperados (si incorpora un oráculo de prueba). Este tipo de herramienta puede generar también salidas (esto es, puede utilizar un oráculo de prueba). Las pruebas generadas a partir de un modelo de estados u objetos son útiles para verificar la implementación del modelo en el software, pero son pocas veces suficientes para verificar todos los aspectos del software o sistema.

344

VII – Herramientas de pruebas 01.5 – Tipos de herramienta de prueba A) Herramientas para el diseño de las pruebas (Cont.) •

•

•

Pueden ser muy útiles si el objetivo es comprobar el funcionamiento de todos y cada uno de los elementos (campos de entrada, botones, controles de check, ramas…) de una aplicación. El problema que puede generarse en este caso es que haya demasiados casos de prueba. En tal caso, debe seleccionarse un subconjunto que minimice riesgos y/o que seleccione casos significativos (ej: arrays ortogonales). Otras herramientas de esta categoría pueden ayudar a soportar la generación de pruebas mediante plantillas estructuradas, denominadas a veces marco de prueba, que generan pruebas o stubs de prueba, acelerando así el proceso de diseño de pruebas. Todas las herramientas obtienen los datos a partir de formalismos o determinadas estructuras. • •

Nunca pueden sustituir al probador (persona) que dispone de creatividad, intuición y conocimiento. Una elección manual de los datos o un tratamiento posterior de los datos generados es a menudo necesario.

345

VII – Herramientas de pruebas 01.5 – Tipos de herramienta de prueba B) Herramientas de preparación de datos de prueba. •

Las herramientas de preparación de datos de prueba manipulan fuentes de datos para establecer los datos de prueba a utilizar durante la ejecución de las pruebas: • • •

•

Extrayendo datos de archivos o bases de datos. Construyendo múltiples datos similares a partir de una plantilla o perfil. Generando nuevos registros con datos pseudo-aleatorios.

Son particularmente útiles: •

A efectos de protección de datos. • En ocasiones se toman datos de producción para prueba. Estas herramientas pueden coger el nombre de una persona, el apellido de otra, el teléfono de una tercera, etc, generando un registro que no se corresponde con el de ninguna persona real.

•

Para pruebas de fiabilidad y prestaciones en las que se necesitan grandes volúmenes de datos realistas.

346

VII – Herramientas de pruebas 01.5 – Tipos de herramienta de prueba B) Herramientas de preparación de datos de prueba (Cont.) •

Generadores de datos de prueba basados en bases de datos. • Obtienen datos de pruebas a partir de bases de datos o archivos. • Reconocen estructuras y contenidos y obtienen de ellos datos de prueba.

•

Generadores de datos de prueba basados en código. • Obtienen datos de prueba a partir del código fuente. • No pueden proporcionar valores esperados. • Al igual que los métodos de caja blanca sólo pueden obtener datos que investiguen “lo que hay”; las funciones que faltan etc. no son tenidas en cuenta generalmente.

347

VII – Herramientas de pruebas 01.5 – Tipos de herramienta de prueba B) Herramientas de preparación de datos de prueba (Cont.) •

Generadores de datos de prueba basados en interfases. • Obtienen datos de prueba en base a parámetros de interfases. • Deducen clases de equivalencia y valores límite a partir de los rangos de definición. • Tampoco proporcionan valores esperados pero son adecuados para las pruebas de robustez.

•

Generadores de datos de prueba basados en requisitos. • Obtienen datos o rangos de datos. A partir de esta información y aplicando técnicas de partición de equivalencia o valores límite se pueden generar casos / datos de prueba. • Se necesita obligatoriamente una notación formal para las especificaciones. • Las herramientas CASE pueden proporcionar modelos formales utilizables para este tipo de generadores de datos de prueba.

348

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba 4.- Herramientas de soporte a la ejecución y el registro de resultados. •

Se pueden distinguir los siguientes tipos: A) Herramientas para la ejecución de pruebas. B) Herramientas que proporcionan marcos de pruebas unitarias (frameworks) o armazones de prueba (D). C) Comparadores de prueba. D) Herramientas de medida de cobertura (D). E) Herramientas de prueba de seguridad.

349

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba A) Herramientas para la ejecución de pruebas. Robots de prueba. •

•

•

Es frecuente que cuando se habla de una herramienta de pruebas, se refiera a una herramienta de ejecución de pruebas. Las herramientas de ejecución de pruebas permiten ejecutarlas de forma automática o semiautomática, utilizando entradas y salidas esperadas almacenadas, haciendo uso de un módulo de captura y reproducción y/o un lenguaje de scripting (un lenguaje de programación). Aunque lo más llamativo es el módulo de captura que puede hacer pensar que basta con grabar y reproducir, la máxima eficiencia la proporciona el lenguaje de scripting, que hace posible manipular las pruebas con un esfuerzo limitado, por ejemplo, repetir las pruebas con distintos datos o probar diferentes partes del sistema que tengan pasos similares. En ocasiones es necesario proporcionar al script cierto grado de flexibilidad (por ejemplo: ignorar un número secuencial que genera el sistema; al ser siempre distinto, un script basado en una grabación “no inteligente” fallaría siempre. Ello se consigue con programación.

350

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba A) Herramientas para la ejecución de pruebas. Robots de prueba. (Cont.) •

•

•

•

Generalmente estas herramientas incluyen características de comparación dinámica y proporcionan un registro de resultados de las pruebas para cada vez que se corre una prueba. Las herramientas de ejecución de pruebas pueden también utilizarse para registrar pruebas, cuando incorporan herramientas de captura y reproducción. La captura de entradas de prueba durante las pruebas exploratorias o no documentadas puede resultar útil para reproducir y/o documentar una prueba, por ejemplo, si ocurre un fallo. La importancia que tienen estas herramientas en la automatización de la ejecución de las regresiones hace que en ocasiones se oiga hablar de ellas como de “herramientas de regresión”. Un aspecto crítico para que pueda utilizarse este tipo de herramientas es disponer de un entorno de prueba y un conjunto de datos estable.

351

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba A) Herramientas para la ejecución de pruebas. Robots de prueba. (Cont.) •

Entre las características principales de este tipo de herramientas se encuentran: • • • • • • • •

Captura de entradas de prueba (pulsaciones, movimientos o clicks de ratón…). Almacenamiento del resultado esperado. Ejecución de pruebas a partir de scripts almacenados y/o archivos de datos. Comparación dinámica. Registro de resultados. Medición de tiempos. Sincronización con la aplicación (esperar a que la aplicación esté preparada antes de enviarle el siguiente comando). Generación de informes o envío de información a una herramienta de generación de informes.

352

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba A) Herramientas para la ejecución de pruebas. Otras herramientas. • Depuradores (D) • Herramienta para la búsqueda de errores en un programa. • Posibilitan un proceso secuencial del programa (ejecución de sentencias individuales). • El proceso puede pararse en cualquier momento para comprobar cada una de las sentencias y condiciones. • Las variables se pueden definir o referenciar de forma individual.

353

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba A) Herramientas para la ejecución de pruebas. Otras herramientas. (Cont.) • Controladores de pruebas • Permiten el acceso a un objeto de prueba sin las interfases correspondientes. • Regulan la entrada y salida de datos y documentan el desarrollo. • Registro de valores obtenidos. • Pueden ser productos estándar ya preparados o se pueden programar especialmente para el objeto de prueba a tratar. • Proporcionan, además, por regla general, un entorno de ejecución.

354

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba B) Herramientas que proporcionan marcos de pruebas unitarias (frameworks) o armazones de prueba (D). •

•

•

Un armazón de pruebas (test harness) puede facilitar la prueba de componentes o de parte de un sistema mediante la simulación del entorno en el que van a correr estos objetos de prueba. Esto puede llevarse a cabo ya sea porque otros componentes de este entorno no se encuentran aún disponibles o simplemente para proporcionar un entorno predecible y controlable en el que pueda localizarse cualquier tipo de fallo en el objeto bajo prueba. Puede crearse un marco (framework) en aquellos casos en los que puede ejecutarse una parte del código, un objeto, método o función, unidad o componente, llamando al objeto a probar y/o proporcionando realimentación. Esto se puede hacer proporcionando medios artificiales de suministrar entradas al objeto de prueba (drivers) y/o suministrando stubs que proporcionen una salida del objeto, en lugar de disponer de salidas reales Las herramientas que proporcionan armazones de prueba pueden usarse para proporcionar marcos de ejecución en los casos en los que se comprueba middleware, donde se ha de probar de forma conjunta lenguajes, sistemas operativos o hardware. 355

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba B) Herramientas que proporcionan marcos de pruebas unitarias (frameworks) o armazones de prueba (D). (Cont.) •

Pueden ser denominadas herramientas de marco de pruebas unitarias cuando se enfocan a este nivel de prueba. Este tipo de herramienta ayuda a ejecutar pruebas de componente en paralelo a la construcción del código. Dentro de esta familia de herramientas están las “xUnit”: JUnit, NUnit… Este tipo de herramientas son muy similares a las de ejecución, proporcionando utilidades para almacenar casos y monitorizar resultados. Lo que no tienen es capacidad de grabar y reproducir casos.

•

Algunas de las características que pueden proporcionar estas herramientas: • • • •

Suministro de entradas y recepción del salidas al/del objeto de prueba. Ejecutar y almacenar pruebas (marcos o armazones). Registrar resultados (marcos). Soporte a la depuración (marcos).

356

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba C) Comparadores de prueba. • • •

Herramientas para la comparación entre valores esperados y valores obtenidos. La base de la comparación pueden ser bases de datos o archivos en diferentes formatos. Existen dos tipos de comparadores: •

•

• •

Dinámicos (los más habituales), que hacen la comparación durante la ejecución de la prueba. Este tipo de comparación es particularmente útil cuando el error (la diferencia entre resultado esperado y obtenido) ocurre en medio de la prueba, pudiéndose programar algún tipo de acción de recuperación o lanzando un subconjunto de casos “ad hoc”. Post-ejecución haciendo uso de una herramienta de comparación separada. Los sistemas operativos suelen tener herramientas que dan este tipo de soporte. Este tipo de comparador es particularmente útil cuando hay que comparar grandes volúmenes de datos, por ejemplo, el resultado de un batch.

Aspecto crítico: conocer el resultado esperado. Pueden utilizar oráculos de prueba, especialmente si están automatizados. Suelen incluirse filtros para seleccionar subconjuntos de resultados.

357

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba D) Herramientas de medida de cobertura (D) •

Miden el porcentaje de tipos específicos de estructura de código que han sido ejercitadas (por ejemplo, sentencias, ramas o decisiones y llamadas a módulos o funciones).

•

Pueden ser intrusivas o no intrusivas (suelen ser intrusivas) dependiendo de las técnicas de medición utilizadas, qué es lo que se mide y el lenguaje de codificación.

•

Las herramientas intrusivas, mediante una instrumentalización se instalan contadores que registran cada acceso. Después de finalizar las pruebas las herramientas pueden valorar a partir del estado de los contadores qué grado de cobertura se obtiene para las pruebas.

•

Puede ser aplicada a diversos niveles de prueba, pero sobre todo se usa en pruebas de componente.

•

Una cobertura de un 100% de un determinado tipo de estructura no implica una cobertura de prueba del 100%.

358

VII – Herramientas de pruebas 01.6 – Tipos de herramienta de prueba E) Herramientas de prueba de seguridad. •

•

•

Hay diversos elementos que ayudan a proteger a un sistema o aplicación de ataques externos. Un cortafuegos, por ejemplo, no es estrictamente una herramienta de seguridad, pero puede utilizarse en las pruebas de seguridad. Las herramientas de prueba de seguridad buscan en el sistema vulnerabilidades específicas. Pueden centrarse en la red, el software base, el código de la aplicación o la base de datos. Pueden incluir: • • • •

Identificación de virus. Detección de intrusiones. Simulación de ataques externos. Comprobación de puertos.

359

VII – Herramientas de pruebas 01.7 – Tipos de herramienta de prueba 5.- Herramientas de soporte al rendimiento y monitorización. • •

Son herramientas asociadas a la operación del sistema, ya sea en entornos preproductivos o productivos. Se distinguen los siguientes tipos: A) Herramientas de análisis dinámico. B) Herramientas de pruebas de rendimiento, carga y estrés. C) Herramientas de monitorización.

360

VII – Herramientas de pruebas 01.7 – Tipos de herramienta de prueba A) Herramientas de Análisis dinámico (D). •

Requieren que el código se esté ejecutando.

•

Llevan a cabo la supervisión y registro del estado interno del objeto: •

Utilización de memoria (memory leaks).

•

Estado de los punteros (identificación de punteros nulos).

•

Temporización (identificación de dependencias temporales).

•

Hay herramientas que llevan a cabo el análisis de los enlaces (típico de aplicaciones Web), para localizar enlaces no operativos.

•

Otras herramientas realizan análisis de cobertura.

•

Suelen utilizarse en las pruebas de componentes y de integración.

361

VII – Herramientas de pruebas 01.7 – Tipos de herramienta de prueba B) Herramientas de pruebas de rendimiento, carga y estrés. • •

• •

También son conocidas como herramientas de pruebas de prestaciones. Las herramientas de pruebas de rendimiento monitorizan e informan acerca de cómo se comporta un sistema bajo una determinada variedad de condiciones de uso simuladas. Simulan carga en una aplicación, una base de datos o un entorno de sistema, como pueden ser una red o un servidor. En función de la carga simulada se utiliza una nomenclatura distinta: • •

•

•

Cuando simulan una carga nominal se habla de pruebas de carga. Cuando simulan una carga superior a la nominal, se habla de prueba de sobrecarga o estrés

Se suele basar en la grabación de uno o varios casos de prueba que simulan las operativas principales. El técnico de prueba parametriza el lanzamiento simultaneo y/o escalonado de n casos y evalúa los resultados. Otro tipo de prueba es la prueba de volumen que se centra en los resultados obtenidos al lanzar una operativa contra un alto volumen de datos (típico en sistemas batch).

362

VII – Herramientas de pruebas 01.7 – Tipos de herramienta de prueba C) Herramientas de monitorización. •

•

Las herramientas de monitorización no son estrictamente herramientas de prueba, pero proporcionan información que puede utilizarse con propósitos de prueba y que no se encuentran disponibles mediante otros medios. Las herramientas de monitorización analizan, verifican e informan de forma continua y en tiempo real acerca del uso de recursos específicos del sistema: • • •

• • •

Número de usuarios de una red Tráfico de red …

Proporcionan alertas (pueden enviar mensajes a un administrador, por ejemplo) acerca de posibles problemas en el servicio. Pueden guardar logs con los resultados obtenidos para su análisis posterior (evolución histórica de datos). Por otra parte, pueden almacenar información acerca de la versión del software de aplicación y del de pruebas, ayudando a mantener la trazabilidad.

363

VII – Herramientas de pruebas 01.8 – Tipos de herramienta de prueba 6.- Herramientas de soporte para necesidades de prueba específicas. •

Existen determinadas herramientas para ciertas necesidades específicas de prueba, como por ejemplo, para el Análisis de la calidad de los datos: •

Los datos son la parte central de algunos proyectos concretos, como: • Proyectos de conversión/migración de datos • Algunas aplicaciones, como warehouses de datos

• •

•

Y sus atributos pueden cambiar en términos de criticidad y volumen. En este contexto, se necesita emplear herramientas para el análisis de la calidad de los datos, para verificar y revisar la conversión de los datos y las reglas de migración, de cara asegurar que los datos preparados son correctos, completos y cumplen con un estándar predefinido para ese contexto específico.

Existen también herramientas para las pruebas de usabilidad.

364

VII – Herramientas de pruebas 01.9 – Tipos de herramienta de prueba 7.- Otras herramientas. •

Las herramientas de prueba que se han enumerado aquí no son las únicas utilizadas por los probadores – también pueden usar hojas de cálculo, SQL o herramientas de depuración (D), por ejemplo.

365

VII – Herramientas de pruebas 02.1 – Uso efectivo de herramientas Beneficios y riesgos de usar una herramienta de soporte •

•

La simple compra o alquiler de una herramienta no garantiza el éxito (no hay balas de plata ni soluciones mágicas). Cada tipo de herramienta puede necesitar esfuerzos adicionales para lograr beneficios reales y duraderos. En el uso de herramientas de prueba, al igual que en cualquier otra herramienta, hay beneficios potenciales y oportunidades, pero también hay riesgos. Entre los potenciales beneficios del uso de herramientas se incluyen: •

• • • •

Reducción del trabajo repetitivo (por ejemplo, correr pruebas de regresión, volver a introducir los mismos datos de prueba y verificación del cumplimiento de estándares de codificación). Las actividades repetitivas suelen generar errores cuando se hacen a mano. Mayor consistencia (puedes estar seguro que una máquina va a ejecutar exactamente la misma prueba, en el caso de una persona no siempre está tan claro). Posibilidad de repetición (por ejemplo, pruebas ejecutadas por una herramienta y pruebas obtenidas a partir de requisitos). Evaluación objetiva (por ejemplo, medidas estáticas, cobertura) no hay posibilidad de que quede información sin registrar por olvido. Facilidad de acceso a la información de las pruebas y a los casos de prueba (por ejemplo, estadísticas y gráficos acerca del progreso de las pruebas, de ratios de incidencias y de prestaciones). 366

VII – Herramientas de pruebas 02.1 – Uso efectivo herramientas Beneficios y riesgos de usar una herramienta de soporte. •

Entre los riesgos asociados al uso de herramientas se incluyen: •

Expectativas no realistas acerca de la herramienta (incluyendo funcionalidad y facilidad de uso). Una herramienta no resuelve: • Un problema organizativo. Lo más que puede hacer es ayudar a su resolución, reduciendo esfuerzos. • Una mala capacitación de un probador. Se puede gestionar perfectamente casos de prueba incorrectos o incompletos

•

•

•

•

Subestimación del tiempo, coste y esfuerzo necesario para la introducción inicial de una herramienta (incluyendo formación y soporte experto externo). No sólo es que no se le saque todo el partido al principio, es que, inicialmente, puede requerir más tiempo hacer el trabajo que cuando se hacía manualmente Subestimación del tiempo y esfuerzo necesario para lograr de la herramienta beneficios significativos y continuados (incluyendo la necesidad de cambios en el proceso de prueba y mejora continua en la forma de utilizar la herramienta). Los beneficios se obtienen a largo plazo Subestimación del esfuerzo necesario para mantener los elementos de prueba generados por la herramienta. Disponer para cada incidencia de información del módulo que ha generado un error resultar muy útil para realizar análisis históricos o de tendencias de la calidad del módulo, pero hay que identificarlo y documentarlo Demasiada dependencia de la herramienta. A veces parece haber una fiebre por amortizar la herramienta usándola para tareas para las que resultan más adecuadas las pruebas manuales. 367

VII – Herramientas de pruebas 02.1 – Uso efectivo herramientas Beneficios y riesgos de usar una herramienta de soporte (cont.). •

Entre los riesgos asociados al uso de herramientas se incluyen (cont.): •

Descuidar el control de versiones de los elementos de prueba dentro de la herramienta.

•

Descuidar aspectos relativos a la relación e interoperabilidad entre herramientas críticas, como herramientas de gestión de requisitos, de control de versiones, de gestión de incidencias o seguimiento de defectos y herramientas procedentes de múltiples proveedores.

•

Proveedores de herramientas que abandonan el negocio, retiran la herramienta o la venden a otro proveedor diferente.

•

Respuesta pobre por parte del proveedor para el soporte, las actualizaciones y el arreglo de defectos.

•

Suspensión de un proyecto de herramienta open-source/libre.

•

Ciertos imprevistos, como la incapacidad de soportar una plataforma nueva.

368

VII – Herramientas de pruebas 02.2 – Uso efectivo herramientas Consideraciones especiales para ciertos tipos de herramientas. •

Herramientas de ejecución de las pruebas •

Las herramientas de ejecución de las pruebas reproducen scripts diseñados para implementar pruebas que han sido almacenados de forma electrónica. Este tipo de herramienta suele requerir esfuerzos significativos para lograr beneficios significativos.

•

Los scripts pueden ser capturados grabando acciones manuales. Pero este enfoque no permitiría cubrir un número elevado de scripts de pruebas automáticas, porque los scripts capturados son una representación lineal con datos y acciones específicas en cada script. Y podrían ser inestables si ocurriese algún evento inesperado.

•

Un enfoque de pruebas “data-driven” separa los datos, normalmente en hojas de cálculo, y usa un script de pruebas más genérico que puede leer los datos de entrada y ejecutar el mismo script con diferentes datos. Los probadores que no conocen el lenguaje de script pueden entonces crear los datos de prueba para esos scripts predefinidos. También se podrían utilizar algoritmos para la generación de los datos de entrada al script.

•

Se necesita, en todos los casos, disponer de experiencia técnica en el lenguaje de script (ya sea por parte de los probadores o por especialistas en automatización de pruebas). Sea cual sea la técnica de scripting utilizada, deben almacenarse los resultados esperados de cada prueba para su posterior comparación

•

369

VII – Herramientas de pruebas 02.2 – Uso efectivo herramientas Consideraciones especiales para ciertos tipos de herramientas. •

Herramientas de análisis estático •

Las herramientas de análisis estático aplicadas al código fuente pueden ayudar a hacer que la codificación se ajuste a estándares, pero cuando se aplica a código “histórico” ya existente puede generar un montón de mensajes. Hay que plantearse en estos casos hasta qué punto merece la pena tocar un código que funciona bien desde hace mucho tiempo dado que, si bien el objetivo es facilitar el mantenimiento, un código estable puede tener muy poco mantenimiento

•

Un error puede repetirse cientos de veces en un programa. Puede que errores importantes resulten desapercibidos.

•

Una implementación gradual, empezando con filtros iniciales que excluyan algunos mensajes sería un enfoque efectivo.

370

VII – Herramientas de pruebas 02.2 – Uso efectivo herramientas Consideraciones especiales para ciertos tipos de herramientas. •

Herramientas de gestión de las pruebas •

Las herramientas de gestión de las pruebas tienen que disponer de una interfaz con otras herramientas u hojas de cálculo, con el objeto de producir información en el mejor formato posible para las necesidades de la organización.

•

Los informes tienen que diseñarse y mantenerse de forma que proporcionen beneficio. No basta con hacer un informe y sacarlo sistemáticamente sin pensar de cuando en cuando si la información obtenida o la forma de representarla sigue siendo útil

•

Como en el resto de los casos, hay que tener un proceso de pruebas bien definido antes de introducir la herramienta

371

VII – Herramientas de pruebas 03 – Introducción de una herramienta en una organización Generalidades. • ¿Que tipo apoyo mediante herramientas es deseable/ necesitado? • ¡Para esto debe analizarse los más detalladamente posible la situación del proyecto! • Consideraciones previas: • Una herramienta no puede remplazar un proceso de pruebas inexistente o compensar una forma de procedimiento descuidada. • En principio las herramientas son tan poderosas como aquel que las implementa (“A fool with a tool is still a fool”)

372

VII – Herramientas de pruebas 03 – Introducción de una herramienta en una organización Elección de una herramienta. • Cuando queda determinado qué área de las pruebas se debe contar con el apoyo de una herramienta hay que considerar lo siguiente: • La adquisición e introducción de una herramienta lleva unos costes asociados – estos son a menudo muy altos. • La implantación debe rentabilizarse a largo plazo.

373

VII – Herramientas de pruebas 03 – Introducción de una herramienta en una organización Elección de una herramienta. •

Entre los principales aspectos a considerar a la hora de seleccionar una herramienta para una organización se incluyen: • • •

Evaluación de la madurez, fortalezas y debilidades de la organización Identificación de las oportunidades que para la mejora de un proceso de prueba proporcionaría el soporte de herramientas Definición de requisitos claros y criterios objetivos. Establecimiento de pesos. Entre los criterios se pueden considerar: • Adaptación a la operativa y a las necesidades específicas • Flexibilidad • Soporte local (incluyendo formación, soporte y aspectos comerciales)

• • • • • • • •

Hacer un estudio de mercado (selección previa) Evaluación de las necesidades de formación teniendo en cuenta los conocimientos de automatización de pruebas del equipo de pruebas actual. Prueba(s) piloto y/o demostraciones por parte del vendedor para comprobar la funcionalidad requerida y determinar si el producto satisface sus objetivos Estimación del ratio coste-beneficio basándose en una propuesta de negocio sólida. Evaluación, tomando en consideración los criterios y pesos Informe de resultados Revisión de resultados Selección de la herramienta 374

VII – Herramientas de pruebas 03 – Introducción de una herramienta en una organización Introducción (implantación). • Se debería establecer e instalar previamente un proceso de pruebas funcional. • Esto es, entender qué se está haciendo y por qué se hace/se debe hacer.

• La rentabilidad de la implantación de herramientas debería ser comprobada. • ¿En qué áreas del proceso de pruebas merece la pena la implantación de herramientas?

• Considerar los retrasos y problemas de la implantación. • Un programa nuevo debe ser previamente estudiado – en la fase de aprendizaje disminuye por norma general la productividad – una formación insuficiente puede causar una disminución de la calidad. • Esto significa que tras la implantación se pueden producir de todas maneras retrasos o errores en las pruebas.

375

VII – Herramientas de pruebas 03 – Introducción de una herramienta en una organización Introducción (implantación). • La introducción de una nueva herramienta debe llevarse a cabo en seis pasos: • Proyecto piloto • Revisión de las experiencias /resultados • Adaptación de los procesos / de las herramientas • Formación a los usuarios • Introducción para la implantación general • Formación o entrenamiento que acompañe a la implantación

376

VII – Herramientas de pruebas 03 – Introducción de una herramienta en una organización Introducción (implantación). • La introducción mencionada anteriormente parece en principio muy laboriosa, sin embargo es necesaria. • El proyecto piloto proporciona informaciones importantes para la implantación posterior. • Mediante revisiones se pueden aclarar las medidas, o eventualmente las adaptaciones, necesarias. • ¡La formación temprana es generalmente indispensable! • La introducción se hará solo cuando se pueda asegurar una implantación correcta.

377

VII – Herramientas de pruebas 03 – Introducción de una herramienta en una organización Introducción (implantación). Factores de éxito •

Entre los factores de éxito asociados al despliegue de la herramienta en una organización se incluyen: • •

• • • • • •

Desplegar de forma incremental la herramienta. Adaptar y mejorar procesos adaptados al uso de la herramienta (quede claro, el proceso marca la selección de la herramienta, una vez seleccionada, se adaptan para aprovechar las capacidades al máximo y mejorar la eficiencia). Proporcionar formación y soporte de consultas a los nuevos usuarios. Definir líneas guía para su uso. Elaborar manuales de usuario adaptados a la organización. Implementar una forma de aprender lecciones del uso de la herramienta. Establecer un mecanismo de mejora continua. Monitorizar el uso y los beneficios que proporciona la herramienta. Calcular el ROI. Proporcionar soporte al equipo de pruebas para una herramienta dada Recopilar lecciones aprendidas de todos los equipos.

378

VII – Herramientas de pruebas 03 – Introducción de una herramienta en una organización Costes de la introducción (implantación). • La introducción de una herramienta puede estar unida a costes relevantes. • Adquisición, • Mantenimiento, • Eventualmente hardware adicional requerido y • Formación a los colaboradores. • Estos costes están en oposición a las ventajas esperadas con la implantación de la herramienta. • En este punto debe estimarse en base a criterios técnicos cuando es rentable la implantación y cuando no.

379

VII – Herramientas de pruebas 03 – Introducción de una herramienta en una organización Amortización de los costes de adquisición. • La gran pregunta desde el punto de vista económico es cuándo se amortiza una herramienta – esta pregunta no tiene lamentablemente fácil respuesta. • Los costes de la primera implantación (de una herramienta de automatización) se ven normalmente aumentados todavía más por la “nueva programación de los casos de prueba”. • Se producen costes adicionales por la formación de los colaboradores. • Sólo con la automatización de más casos de prueba se suma el ahorro obtenido por caso de prueba. • La mejora de la calidad de las pruebas individuales no se puede expresar normalmente en términos monetarios. • Pero la amortización sólo engloba los resultados económicos y no los efectos sobre la calidad.

¡Solo una implantación duradera, a largo plazo y sostenida de una herramienta de pruebas posibilita una amortización de los costes de adquisición!

380

VII – Herramientas de pruebas 03 – Introducción de una herramienta en una organización Amortización de los costes de adquisición. • Sólo mediante una implantación eficiente se consigue una ventaja en costes respecto de la actividad manual. • Las herramientas para, p.ej., la ejecución automatizada de casos de prueba necesitan un cierto esfuerzo para la primera preparación de los casos de prueba. • Aquí se producen mejoras en los costes cuando se repite la ejecución de las pruebas – éstos mejoran cada vez más con el número de repeticiones.

• Otras herramientas deberían implantarse para “cubrir áreas” y conseguir el mayor ahorro posible. • En determinados casos, en función del volumen o de la complejidad de una prueba, ésta sólo puede realizarse con el apoyo de herramientas. • Si una herramienta se necesita obligatoriamente para las pruebas entonces los aspectos económicos no juegan ya un papel determinante.

381

VII –Herramientas de pruebas 04 – Resumen Afirmaciones importantes del capítulo: • Hoy en día se dispone de herramientas para cada fase del proceso de pruebas para: • Elaborar la automatización de las pruebas. • Mejorar cualitativamente los trabajos de pruebas. • Acortar los tiempos de ejecución de las pruebas.

• Solo un proceso de pruebas organizado y establecido es adecuado para la implantación de herramientas. • Es indispensable una elección de herramientas antes de la introducción para poder calcular unos costes y riesgos considerables. • Un acompañamiento constante durante la introducción de la herramienta escogida, con entrenamiento y formación de los usuarios, es necesario para una implantación regular y de este modo para el beneficio económico de un proceso de pruebas automatizado.

382

383

Les agradecemos el interés mostrado y les deseamos una evaluación final exitosa para el “Probador Certificado – Nivel Básico”

Departamento de Formación