foundation level syllabus (2010)spanish

5/10/2018 Foundation Level Syllabus (2010)Spanish - slidepdf.com

http://slidepdf.com/reader/full/foundation-level-syllabus-2010spanish-55a0c65f5b349

Certified Tester Foundation Level Syllabus

International SoftwareTesting Qualifications Board

Versión 2005 Julio de2005© Spanish Software Testing Qualifications Board

1-88

Certified Tester

Foundation Level Syllabus

Version 2005

International Software Testing Qualifications Board






2-88

Copyright © 2005, los autores (Thomas Müller (presidente), Rex Black, Sigrid Eldh,Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson y Erik VanVeendendal), todos los derechos reservados.

Los autores están transfiriendo el copyright al International Software Testing

Qualifications Board (en adelante ISTQB). Los autores (como propietarios actuales delcopyright) e ISTQB (como el propietario futuro del copyright) han acordado las siguientescondiciones de uso:

1) Cualquier compañía o grupo de compañías puede utilizar esta programación o plan deestudio como base para el curso de aprendizaje si reconocen a los autores y al ISTQB comodueños de la fuente y del copyright del programa y a condición de que cualquier anuncio detal curso de aprendizaje puede mencionar la programación únicamente después de su presentación para la acreditación oficial de los materiales por parte de un equipo nacionalISTQB reconocido;

2) Cualquier persona o grupo de personas puede usar esta programación como base paraartículos, libros, u otros escritos si los autores y el ISTBQ son reconocidos como fuente ycopyright de la propia programación;

3) Cualquier equipo nacional ISTBQ reconocido ( ISTQB-recognized National Board ) puede traducir esta programación y dar licencia de la misma (o su traducción) a terceros.






3-88

Histórico de revisiones

Versión Fecha Observación

ISTQB 2005 01-July-2005 Certified Tester Foundation Level Syllabus

ASQF V2.2 July-2003 ASQF Syllabus Foundation Level Version 2.2“Lehrplan„Grundlagen des Softwaretestens“

ISEB V2.0 25-Feb-1999ISEB Software Testing Foundation SyllabusV2.0 25 February 1999






4-88

Tabla de contenidos

Histórico de revisiones 03Tabla de contenidos 04Agradecimientos 07

Introducción al plan de estudio 081. Fundamentos del testing (K2) 11

1.1 ¿Porqué es necesario el testing? (K2) 121.1.1 Contexto de los sistemas software (K1) 121.1.2 Causa de los defectos software (K2) 121.1.3 Role del testing en desarrollo software, mantenimiento y operaciones (K2) 121.1.4 Testing y calidad (K2) 121.1.5 ¿Cuánto testing es suficiente? (K2) 13

1.2 ¿Qué es el testing? (K2) 141.3 Principios generales del testing (K2) 161.4 Procesos fundamentales del test (K1) 17

1.4.1 Planificación del test y control (K1) 171.4.2 Análisis y diseño de test (K1) 181.4.3 Implementación y ejecución del test (K1) 181.4.4 Evaluación de los criterios de salida e informes (K1) 191.4.5 Actividades del cierre del test (K1) 19

1.5 La psicología del testing (K2) 202. Testing a través del ciclo de vida del software (K2) 22

2.1 Modelos de desarrollo software (K2) 232.1.1 V-model (K2) 232.1.2 Modelo de desarrollo iterativo (K2) 232.1.3 Test del modelo del ciclo de vida (K2) 24

2.2 Niveles de test (K2) 252.2.1 Test de componente (K2) 252.2.2 Test de integración (K2) 262.2.3 Test de sistema (K2) 262.2.4 Test de aceptación (K2) 27

2.3 Tipos de test: targets de los test (K2) 292.3.1 Test de funcionamiento o funcional (K2) 292.3.2 Test de características del producto software o test no funcional (K2) 302.3.3 Test de estructura-arquitectura del software o test estructural (K2) 302.3.4 Test relacionado con cambios o test de confirmación o de regresión (K2) 31

2.4 Test de mantenimiento 32

3. Técnicas estáticas (K2) 333.1 Revisiones y el proceso de test (K2) 343.2 Proceso de revisión (K2) 35

3.2.1 Fases de una revisión formal (K1) 353.2.2 Roles y responsabilidades (K1) 353.2.3 Tipos de revisión (K2) 363.2.4 Factores de éxito para revisiones (K2) 37

3.3 Análisis estático por herramientas (K2) 38






5-88

4. Técnicas de diseño de test (K3) 404.1 Identificación de las condiciones de prueba y diseño de los casos de prueba (K3) 424.2 Categorías de las técnicas de diseño de pruebas (K2) 444.3 Técnicas basadas en especificación o de caja negra (K3) 45

4.3.1 Particionamiento por equivalencia (K3) 45

4.3.2 Análisis de valores límite (K3) 454.3.3 Pruebas de tablas de decisión (K3) 454.3.4 Pruebas de transición de estado (K3) 464.3.5 Pruebas de casos de uso (K2) 46

4.4 Técnicas basadas en estructura o de caja blanca (K3) 484.4.1 Pruebas de sentencia y cobertura (K3) 484.4.2 Pruebas de decisión y cobertura (K3) 484.4.3 Otras técnicas basadas en estructura (K1) 48

4.5 Técnicas basadas en la experiencia (K2) 504.6 Elección de las técnicas de pruebas (K2) 51

5. Gestión de tests (K3) 52

5.1 Organización del test (K2) 545.1.1 Organización del test e independencia (K2) 545.1.2 Tareas del líder del test y el tester (K1) 55

5.2 Planificación de test y estimación (K2) 575.2.1 Planificación del test (K2) 575.2.2 Actividades de planificación del test (K2) 575.2.3 Criterios de salida (K2) 585.2.4 Estimación del test (K2) 585.2.5 Técnicas de test (estrategias de test) (K2) 58

5.3 Monitorización y control del progreso del test (K2) 605.3.1 Monitorización del proceso de test (K1) 60

5.3.2 Informe de test (K2) 605.3.3 Control de test (K2) 615.4 Gestión de configuración (K2) 625.5 Riesgo y testing (K2) 63

5.5.1 Riesgo de proyecto (K1, K2) 635.5.2 Riesgo de producto (K2) 63

5.6 Gestión de incidencias (K3) 656. Herramientas de soporte para testing (K2) 67

6.1 Tipos de herramientas de test (K2) 686.1.1 Clasificación de herramientas de test (K2) 686.1.2 Herramientas de soporte para la gestión de pruebas (K1) 69

6.1.3 Herramientas de soporte para tests estáticos (K1) 706.1.4 Herramientas de soporte para test de especificación (K1) 716.1.5 Herramientas de soporte para la ejecución de test y carga (K1) 716.1.6 Herramientas de soporte para la ejecución y control (K1) 736.1.7 Herramientas de soporte para áreas específicas de aplicación (K1) 736.1.8 Herramientas de soporte usando otras herramientas (K1) 74

6.2 Uso efectivo de herramientas: beneficios y riesgos (K2) 75






6-88

6.2.1 Beneficios y riesgos potenciales de las herramientas de soporte para testing (K2)

6.2.2 Consideraciones especiales para algunos tipos de herramientas (K1) 756.3 Introducir una herramienta en una organización (K1) 77

7. Referencias 78

Apéndice A - Trasfondo del plan de estudio (syllabus) 80Apéndice B - Objetivos del aprendizaje / Nivel de conocimiento 83Apéndice C - Reglas aplicadas al plan de estudios de ISTBQ Foundation 85Apéndice D - Información para los formadores 87






7-88

Agradecimientos

Este documento ha sido desarrollado por el ISTQB-FL: Thomas Müller (Presidente),Rex Black, Sigrid Eldh, Dorothy Gram., Klaus Olsen, Marte Pyhäjärvi, Geoff Thompson y

Eric van Veendendal. El equipo de trabajo quiere agradecer al grupo de revisión y a todaslas plataformas nacionales sus aportaciones al actual plan de estudios.

En particular agradecer a Anastasios Kyriakopoulos (Austria), Klaus Olsen, ChristineRosenbeck-Larsen (Dinamarca), Matthias Daigl, Uwe Hehn, Tilo Linz, Horst Pohlmann,Ina Schieferdecker, Sabine Uhde, Stephanie Ulrico (Alemania), Vipul Kocher (India),Shmuel Knishinsky, Ester Zabar (Israel), Anders Claesson, Mattias Nordin, Ingvar Nordström, Stefan Ohlsson, Kennet Osbjer, Ingela Skytte, Klaus Zeuge (Suecia), ArminBorn, Sandra Harries, Silvio Moser, Reto Müller, Joerg Pietzsch (Suiza), Aran Ebbett,Isabel Evans, Julie Gardiner, Andrew Goslin, Brian Hambling, James Lyndsay, HelenMoore, Peter Morgan, Trevor Newton, Angelina Samaroo, Shane Saunders, Mike Smith,

Richard Taylor, Neil Thompson, Pete Williams (Reino Unido) y Dale Perry (EstadosUnidos).






8-88

Introducción al plan de estudios

Propósito de este documento

El plan de estudios que presenta este documento constituye la base para la obtencióndel nivel básico “ Foundation Level ” del “ Internacional Software Testing Qualification”. La“ Internacional Software Testing Qualification Board ” en adelante ISTQB, proporciona estedocumento a los organismos examinadores nacionales para que puedan acreditar a lasentidades que imparten formación en esta materia y para obtener una traducción de lascuestiones de examen en la lengua local.

Información acerca de la historia y antecedentes de este programa de formación seencuentra en el Apéndice A.

El Certificado de Tester (Nivel Básico) en la prueba del Software

El Nivel Básico de calificación está dirigido a cualquiera que esté implicado en la prueba de Software. Esto incluye a personas que actúen como probadores, analistas de test,ingenieros de test, especialistas en test, directores de test, probadores de aceptación deusuarios y desarrolladores de software. Este nivel de calificación es también apropiado paratodo aquel que desee un conocimiento básico de la prueba del software, como jefes de proyecto, gestores de calidad, gestores en desarrollo de software, analistas de negocio,directores en Tecnologías de Información y especialistas en gestión. La certificación en elnivel básico proporciona la posibilidad de acceder a un nivel superior en la “Testing

Software Qualification”.

Objetivos de aprendizaje/ Nivel de conocimiento

Los niveles cognoscitivos están expresados en cada sección según este plan deestudios:

• K1: recordar, reconocer, retirar;• K2: entender, explicar, dar razones, comparar, clasificar, resumir;• K3: Aplicar.

Más detalles y ejemplos acerca de los objetivos de aprendizaje se pueden encontrar enel Apéndice B.

Todos los términos que aparecen al final de cada capítulo bajo el encabezamiento“Términos” deben ser recordados (K1), incluso cuando no aparezcan explícitamentemencionados en los objetivos de aprendizaje.






9-88

El examen

El examen de certificación en el nivel básico estará basado en el presente plan deformación. Las respuestas a las cuestiones de examen requieren el uso de material basadoen más de una de las secciones de este plan de estudios. Todas y cada una de las secciones

de este documento están sujetas a examen.

El formato de examen es de selección múltiple.

Los exámenes pueden ser realizados como parte de un curso de certificación o deforma independiente en los centros de examen.

Acreditación

Los proveedores de cursos cuyo material sigue este plan de formación, deben estar acreditados por una plataforma nacional reconocida por la ISTQB. Las directrices deacreditación podrán ser obtenidas en la plataforma u organismo que lleva a cabo laacreditación. Un curso acreditado es reconocido si se ajusta a este plan de estudios y permite la realización de un examen ISTQB como parte del curso.

Nivel de detalle

El nivel de detalle en este plan de estudios permite una enseñanza y evaluaciónconsistente internacionalmente. Para conseguir esta meta, el plan de estudios se componede:

•

Objetivos generales de instrucción describiendo las intenciones del nivel básico.• Un índice con la información a impartir, incluyendo una descripción y referencias a

fuentes adicionales si fuera necesario.• Objetivos de aprendizaje para cada área de conocimiento, describiendo el

aprendizaje cognoscitivo resultante y el nivel de conocimiento que se alcanzará.• Una lista de términos que el estudiante debe ser capaz de entender y recordar.• Una descripción de los conceptos clave a enseñar, incluyendo referencias/fuentes

tales como literatura aceptada o estándares.

El contenido del plan de estudios no es una descripción completa del área deconocimiento de la prueba del software, si no que refleja el nivel de detalle que debe ser

cubierto en los cursos de formación del Nivel Básico.

Como está organizado el plan de estudios

Existen seis capítulos principales. Los encabezados de cada capítulo muestran el nivelde los objetivos de aprendizaje que son cubiertos en el capítulo y el tiempo que debe ser empleado en el mismo. Por ejemplo:






10-88

2. Prueba durante el ciclo de vida del software (K2) | 135 minutos

El ejemplo anterior muestra que el Capítulo 2 tiene objetivos de aprendizaje K1 (seasume cuando aparecen niveles superiores) y K2 (pero no K3), y además se prevé un periodo de 135 minutos para enseñar la materia del capítulo.

Dentro de cada capítulo existen numerosas secciones. Cada sección también tieneobjetivos de aprendizaje y el tiempo requerido. Las sub-secciones que no tienen un tiempodeterminado se incluyen dentro del tiempo de la sección.






11-88

1. Fundamentos de la prueba (K2) | 155 minutos

Objetivos de aprendizaje para Fundamentos de la prueba

Los objetivos identifican lo que será capaz de hacer al finalizar cada módulo.

1.1 ¿Por qué es la prueba necesaria? (K2)

• Describir, con ejemplos, la manera en el que un defecto en el software puede causar daños a una persona, al medioambiente o a la compañía. (K2)

• Distinguir entre la raíz de la causa del defecto y sus efectos. (K2)• Dar razones por las que la prueba del software es necesaria utilizando ejemplos.

(K2)• Describir por que la prueba forma parte de la garantía de calidad y dar ejemplos de

cómo la prueba contribuye a aumentar la calidad. (K2)• Recordar términos erróneos, defectos, fallos y correspondientes condiciones de

error y bug . (K1)1.2 ¿Qué es la prueba? (K2)

• Recordar los objetivos comunes de la prueba. (K1)• Describir el propósito de la prueba en el desarrollo de software, mantenimiento y

operaciones como una forma de encontrar defectos, proporcionar confianza einformación y prevenir defectos. (K2)

1.3 Principios generales de la prueba (K2)

• Explicar los principios fundamentales de la prueba. (K2)

1.4 Procesos fundamentales del test (K1)• Recordar las actividades fundamentales del test desde la planificación hasta el cierre

de las actividades de test y las principales tareas de cada actividad. (K1)

1.5 La psicología de la prueba (K2)

• Recordar que el resultado de la prueba está influenciada por factores psicológicos(K1):

o Objetivos claros;o Balance de la auto-prueba y la prueba independiente;o Reconocimiento de comunicación cortés y realimentación sobre defectos.

•

Contrastar la perspectiva de un probador con la de un desarrollador. (K2).






12-88

1.1 Por qué es necesaria la prueba (K2) | 20 minutos

Términos

Bug, defecto, error, fracaso, fallo, equivocación, calidad,, riesgo, software, prueba.

1.1.1 Contexto de los Sistemas Software (K1)

Los sistemas software experimentan un auge importante en la vida diaria, desdeaplicaciones de negocios (ej. Banca….) hasta productos de consumo (ej. automóviles…).Mucha gente ha tenido alguna experiencia con software cuyo funcionamiento no ha sido elesperado. El software que no funciona de la forma adecuada puede conducir a muchos problemas como, la pérdida de capital, tiempo, reputación en los negocios e incluso causar daños o la muerte a personas.

1.1.2 Causas de los Defectos Software (K2)

El ser humano puede tener un error (equivocación), que se traduce en un defecto(fallo, bug ) en el código, en el software, en un sistema o en un documento. Si un defecto enel código se ejecuta, el sistema fallará al realizar aquello que debe hacer (o que no debehacer), provocando un fallo. Los defectos en software, sistemas o documentos puedentraducirse en fallos aunque no siempre es así.

Los defectos se originan debido a que el ser humano es falible y debido a la presióntemporal, complejidad del código o infraestructura, cambios tecnológicos y/o multitud deinteracciones entre sistemas.

Los fallos pueden ser causados también por las condiciones ambientales: radiación,magnetismo, campos eléctricos y contaminación. Estas condiciones pueden causar fallos enel firmware o influir en la ejecución de software modificando las condiciones del hardware.

1.1.3 Role de la prueba en el desarrollo software, mantenimiento y operaciones

(K2)

La prueba rigurosa de los sistemas y la documentación puede reducir el riesgo de problemas en un entorno operacional y contribuye a la calidad del sistema software,siempre que los defectos sean detectados y corregidos antes de que el sistema este

finalizado y listo para su uso operacional.La prueba del software puede también ser requerida para cumplir con requisitoscontractuales, legales o estándares industriales específicos.

1.1.4 Prueba y Calidad

Con la ayuda de la prueba, es posible medir la calidad del software en términos dedefectos encontrados, tanto para características o requisitos software funcionales o no






13-88

funcionales (p. ej. Fiabilidad, usabilidad, eficiencia y mantenimiento). Para másinformación de prueba no funcional mirar el capítulo 2; para más información sobrecaracterísticas software mirar “Ingeniería del software- Calidad del producto Software”(ISO 9126).

La prueba puede proporcionar confianza en la calidad del software si detecta pocos oningún defecto. Un test diseñado de forma apropiada que resulte satisfactorio reduce elnivel de riesgo global del sistema. Cuando la prueba encuentra defectos, la calidad delsistema software se incrementa cuando esos defectos son solventados.

Las lecciones deberían ser aprendidas de proyectos anteriores. Es decir, entendiendola raíz de la causa de defectos encontrados en otros proyectos, los procesos pueden ser mejorados, lo que debe evitar que esos defectos vuelvan a producirse y así, mejorar lacalidad de sistemas futuros.

La prueba debe estar integrada como una de las actividades de la garantía de calidad

(ej. junto al desarrollo de estándares, formación y análisis de defectos.)

1.1.5 ¿Cuánta prueba es suficiente? (K2)

La decisión de cuanta prueba es suficiente debe tener en cuenta el nivel de riesgos,incluyendo el producto y proyecto técnico y de negocio, y las restricciones del proyecto encuanto a tiempo y presupuesto. (Los riesgos son tratados en mayor detalle en capítulo 5).

La prueba debe proporcionar suficiente información a los responsables de tomar decisiones argumentadas respecto a la versión de software o sistema bajo test, para las próximas etapas de desarrollo o entregas a consumidores.






14-88

1.2 ¿Qué es prueba? (K2) | 30 minutos

Términos

Código, depuración, desarrollo (de software), requisitos, revisión, bases del test, casode prueba, prueba, objetivos del test.

Conocimientos previos

Una percepción común de la prueba es que sólo consiste en la ejecución de tests, por ejemplo ejecutar el software. Esto es parte de la prueba, pero no todas las actividades de la prueba.

Las actividades de test existen antes y después de la ejecución del test, actividadescomo la planificación y control, elección de las condiciones del test, diseño de los casos de prueba y chequeo de resultados, criterios de evaluación de las conclusiones, informes sobrelos procesos de test y los sistemas bajo test y la finalización o cierre (p.ej. después decompletar la fase de test). La prueba también implica la revisión de documentos(incluyendo el código fuente) y el análisis estático.

Tanto la prueba dinámica como la estática pueden ser utilizadas como estrategia paraalcanzar objetivos similares, y proporcionarán información útil para mejorar el sistema atestear y los procesos de desarrollo y test.

Pueden existir diferentes objetivos del test:• Encontrar defectos;• Ganar confianza acerca del nivel de calidad y proporcionar información;•

Evitar defectos.La idea del proceso de diseño de test temprano en el ciclo de vida (verificando las

bases del test a través de su diseño) puede ayudar a prevenir la introducción de defectos enel código. La revisión de documentos (ej. requisitos) también pueden ayudar a prevenir laaparición de defectos en el código.

Diferentes puntos de vista en la prueba tienen en cuenta diferentes objetivos. Por ejemplo, en el desarrollo del test (ej. componentes, integración y sistema de test), el principal objetivo puede ser causar tantos fallos como sean posibles para que los defectosen el software sean identificados y solventados. En el test de aceptación, el principal

objetivo puede ser confirmar que el sistema trabaja de la forma esperada, para obtener confianza en que se ajusta a los requisitos. En algunos casos el principal objetivo del test puede ser valorar la calidad del software (sin la intención de solventar defectos), para proporcionar información a los responsables de riesgos y determinar la publicación delsistema en el momento adecuado. El test de mantenimiento a menudo testea que nuevoserrores no han sido introducidos durante el desarrollo de cambios. Durante el testoperacional, el principal objetivo puede ser valorar características del sistema comofiabilidad y disponibilidad.






15-88

Los procesos de depuración y test son diferentes. La prueba puede mostrar fallos queson causados por defectos. El proceso de depurado es la actividad de desarrollo queidentifica la causa de un defecto, permite reparar el código y chequea que el defecto ha sidorectificado correctamente. La prueba de confirmación subsecuente realizado por un probador asegura que la corrección efectivamente a resuelto el fallo. La responsabilidad es

diferente para cada actividad, ej. Los probadores hacen test y los desarrolladores depuran.

El proceso de prueba y sus actividades se explican en la sección 1.4.






16-88

1.3 Principios generales de la prueba (K2) | 35 minutos

Términos

Prueba exhaustiva.

Principios

Numerosos principios de la prueba han sido sugeridos a lo largo de los últimos 40años y ofrecen una guía general común para toda la prueba.

Principio 1- La prueba muestra la presencia de defectos

La prueba puede mostrar que los defectos están presentes, pero no pueden probar queno existen defectos. La prueba reduce la probabilidad de existencia de defectos nodescubiertos pero, incluso cuando los defectos no son encontrados, eso no demuestra suausencia.

Principio 2-la prueba exhaustiva es imposible

Probar todo (todas las combinaciones de entrada y precondiciones) no es factibleexcepto para casos triviales. En lugar de test exhaustivos, utilizamos riesgos y prioridades para enfocar los esfuerzos del test.

Principio 3-Prueba temprana

Las actividades de test deben comenzar tan pronto como sea posible en el ciclo de vida deldesarrollo del software o sistema y deben ser enfocados sobre objetivos definidos.

Principio 4 –Agrupamiento de Defectos

Un número pequeño de módulos contienen la mayoría de los defectos descubiertosdurante la prueba, o muestran la mayoría de los fallos operacionales.

Principio 5- La paradoja del pesticida

Si el mismo test se repite una y otra vez, eventualmente el mismo grupo de casos detest ya no encontrará nuevos errores. Para vencer esta “paradoja del pesticida”, los casos de prueba necesitan ser regularmente revisados y estudiados, y se necesitan escribir nuevoscasos de prueba para ejercitar diferentes partes del software o sistema para encontrar masdefectos potenciales.

Principio 6-La prueba depende del contexto

La prueba se realiza de manera diferente en diferentes contextos. Por ejemplo, elsoftware de seguridad crítico se prueba de forma diferente a la de un sitio de comercioelectrónico.

Principio 7- La falacia de la ausencia de errores

Encontrar y solventar defectos no ayuda si el sistema construido está inutilizado y nosatisface las necesidades y expectativas de los usuarios.






17-88

1.4 Procesos fundamentales del test (K1) |35 minutos

Términos

Prueba de confirmación, criterio de salida, incidente, Prueba de regresión, bases deltest, condiciones del test, cobertura del test, datos del test, ejecución del test, registro deltest, planificación del test, estrategia del test, informe resumen de test, componentes deltest.


La parte más visible del test es su ejecución, pero para ser efectivo y eficiente, la planificación debe incluir también el tiempo que se debe invertir en su planificación, diseñode los casos de prueba, preparación de su ejecución y evaluación del estado.

El proceso fundamental del test consiste en las siguientes actividades principales:• planificación y control;•

análisis y diseño;• implementación y ejecución;• evaluación de criterios de salida e informes;• cierre de las actividades de test.

Aunque son lógicamente secuenciales, las actividades durante el proceso de test pueden solaparse o tener lugar de manera concurrente.

1.4.1 Planificación del test y control (K1)

La planificación del test es la actividad que identifica la misión del test, definiendo los

objetivos del test y la especificación de las actividades de cara a cumplir los objetivos ycompletar la misión.

El control del test es la actividad en curso que compara el progreso actual con la planificación, informando de su estado y las desviaciones respecto a la planificación. Estoimplica iniciar las acciones necesarias para ajustarse a la misión y objetivos del proyecto.De cara al control del test, estas acciones deben ser monitorizadas a lo largo del proyecto.La planificación del test tiene en cuenta la realimentación de las actividades demonitorización y control.

La planificación del test posee las tareas fundamentales:• Determinación del alcance y riesgos, e identificación de objetivos de la prueba.• Determinación de la propuesta del test (técnicas, ítems, cobertura, identificación y

definición de la interfaz entre los equipos implicados en la prueba, componentes deltest).

• Determinación de los recursos requeridos (ej. personal, entorno del test, PCs).• Implementación de las políticas del test y/o la estrategia.• Planificación del análisis del test y las tareas de diseño.• Planificación de la implementación del test, ejecución y evaluación.






18-88

• Determinación del criterio de salida.

El control del test se basa en las siguientes tareas fundamentales:• medida y análisis de resultados;• monitorización y documentación del progreso, cobertura del test y criterios de

salida;• iniciación de acciones de corrección.• toma de decisiones.

1.4.2 Análisis y diseño de test (K1)

El análisis y diseño de test es la actividad donde los objetivos generales de la pruebason transformados en condiciones de test tangibles y diseños de test.

El análisis y diseño del test contiene las siguientes tareas fundamentales:• Revisión de las bases del test (requisitos, arquitecturas, diseño, interfaces).• Identificación de las condiciones de test o requisitos y datos requeridos del test

basados en los ítems del test, la especificación, comportamiento y estructura.• Diseño del test.• Evaluación de testeabilidad? de los requisitos y sistema.• Diseño del entorno de test e identificación de cualquier infraestructura o

herramienta requerida.

1.4.3 Implementación y ejecución del test (K1)

La implementación y ejecución del test es la actividad donde las condiciones sontransformadas en casos de prueba y componentes, y se configura el entorno de pruebas.

La implementación y ejecución contiene las siguientes tareas fundamentales:• Desarrollo y priorización de los casos de prueba, creación de los datos, escribir

procedimientos del test y opcionalmente preparar el aprovechamiento de los test ygeneración de scripts.

• Creación de grupos a partir de los casos de prueba para una ejecución eficiente.• Ejecución de los casos de prueba de forma manual o utilizando herramientas para

su ejecución, de acuerdo con la secuencia planificada.

• Registro de los resultados de la ejecución del test y grabación de identidades yversiones del software bajo test, herramientas de test y componentes del test.• Comparar resultados actuales con los resultados esperados.• Documentar discrepancias e incidencias y analizarlas para establecer su causa (p.ej.

un defecto en el código, en el especificación de los datos del test, en ladocumentación, o un error en el proceso seguido en la ejecución del test).

• Repetir las actividades del test en función de las decisiones tomadas para cadadiscrepancia. Por ejemplo, repetir la ejecución de un test que ha fallado






19-88

previamente con el objetivo de confirmar su corrección (test de confirmación),ejecución de un test corregido y/o ejecución de pruebas para asegurar que no se hanintroducido defectos en las áreas modificadas del software o que los defectoscorregidos no propician otros defectos (test de regresión).

1.4.4 Evaluación de los criterios de salida e informes (K1)

Evaluar los criterios de salida es la actividad donde la ejecución del test se contrastacon los objetivos definidos.

La evaluación de los criterios de salida posee las siguientes tareas:• Chequeo de los registros del test contrastándolos con los criterios de salida

especificados en la planificación del test.• Valorar si son necesarios más test o si los criterios de salida deben ser modificados.• Generar un informe resumido del test para los responsables.

1.4.5 Actividades del cierre de test (K1)

Las actividades de cierre del test recogen todos los datos de las actividades de testcompletadas para consolidar experiencia, testware, hechos y números. Por ejemplo, cuandoun sistema software se publica, se ha completado (o cancelado) un proyecto de test, se haalcanzado un hito o se ha completado una etapa de mantenimiento.

Las actividades de cierre de test incluyen las siguientes tareas:

• Chequear que entregables planificados han sido entregados, el cierre de los informesde incidencias o aumento de los registros de cambio para cualquier informe quecontinúe abierto y documentación de la aceptación del sistema.

• Finalización y archivo del testware, el entorno de test y su infraestructura para sufutura reutilización.

• Entrega del testware a la organización de mantenimiento.• Análisis de las lecciones aprendidas para futuras revisiones y proyectos, y la mejora

de la experiencia en test.






20-88

1.5 La psicología de la prueba (K2) | 35 minutos

Términos

Prueba independiente.


La mentalidad a utilizar durante la prueba y la revisión es diferente a la utilizadadurante el análisis o desarrollo. Con la mentalidad correcta los desarrolladores son capacesde probar su propio código, pero la separación de esta responsabilidad para un probador estípicamente utilizada para ayudar a dirigir el esfuerzo y proporcionar beneficiosadicionales, como la visión independiente a través de unos medios de prueba formados y profesionales. La prueba independiente debe ser practicada a cualquier nivel de test.

Un cierto grado de independencia (evitando el prejuicio del autor) es a menudoefectivo en la búsqueda de defectos y fallos. Sin embargo, la independencia no es una

sustitución de la familiaridad, por lo que los desarrolladores pueden encontrar de formaeficiente muchos defectos en su propio código. Se pueden definir diferentes niveles deindependencia:

• Tests diseñados por la persona(s) que escribió el software bajo test (bajo nivel deindependencia).

• Tests diseñados por otra persona(s) (p. ej. del grupo de desarrollo).• Tests diseñados por una(as) persona(s) de otro grupo diferente (ej. un equipo de test

independiente).• Tests diseñados por una persona(s) de una organización o compañía independiente

(ej. outsourcing o certificación por una entidad externa).

Los proyectos y la gente se mueven por objetivos. La gente tiende a ajustar sus planesa los objetivos marcados por la dirección y otros responsables, por ejemplo, encontrar defectos o confirmar que el software funciona. Por tanto, es importante clarificar el estadode los objetivos de la prueba.

Identificar fallos durante la prueba puede ser interpretada como una crítica contra el producto o su autor. De esta manera, la prueba se percibe a menudo como una actividaddestructiva, aunque es muy constructivo en el manejo de riesgos del producto. La búsquedade fallos en un sistema requiere curiosidad, pesimismo profesional, una visión crítica,atención a los detalles, buena comunicación con los desarrolladores y experiencia como base para intuir/adivinar errores.

Si los errores, defectos o fallos se comunican de una manera constructiva, se puedenevitar fricciones entre los probadores y los analistas, diseñadores y desarrolladores. Esto seaplica tanto en la revisión como en la prueba.

El tester y su líder necesitan buenas técnicas interpersonales para comunicar información de facto acerca de defectos, progreso y riesgos, de una forma constructiva.Para el autor del software o documentación, la información de defectos puede ayudarle a






21-88

mejorar sus habilidades. Los defectos encontrados y solventados durante la pruebasupondrán un ahorro en tiempo y dinero y una reducción en los riesgos.

Los problemas de comunicación pueden ocurrir, particularmente si los probadores sonvistos solamente como mensajeros de malas noticias sobre defectos. Sin embargo, existen

diversos caminos para mejorar la comunicación y relación entre probadores y otros:

• Comenzar con colaboración en lugar de batallas – mentalizar a todos con la metacomún de sistemas de calidad.

• Comunicar fallos del producto de una manera neutral, orientada al hecho sin criticar la persona que realizó el producto, por ejemplo, escribir objetivo e informe deincidente hallado y revisión de fallos.

• Intentar entender cómo piensa la otra persona y por qué reacciona de tal manera.• Confirmar que la otra persona ha comprendido aquello que tú has querido decir y

viceversa.

Referencias

1.1.5 Black, 2001, Kaner, 20021.2 Beizer, 1990, Black, 2001, Myers, 19791.3 Beizer, 1990, Hetzel, 1998, Myers, 19791.4 Hetzel, 19981.4.5 Black, 2001, Craig, 20021.5 Black, 2001, Hetzel, 1998






22-88

2. Pruebas a través del ciclo de vida del software (K2) | 135

minutos

Objetivos de aprendizaje para las pruebas a través del ciclo de vida del software.

Los objetivos identifican lo que será capaz de hacer al finalizar cada módulo.

2.1 Modelos de desarrollo software (K2)• Entender la relación existente entre el desarrollo, las actividades de test, y el trabajo

en el ciclo de vida de desarrollo de productos, y dar ejemplos basados en proyectos,características del producto y el contexto.(K2)

• Reconocer el hecho de que los modelos de desarrollo software deben ser adaptadosal contexto del proyecto y las características del producto.(K1)

• Recodar los diferentes niveles de prueba, y las características de un test correcto encualquier modelo del ciclo de vida.(K1)

2.2 Niveles de test (K2)• Comparar los diferentes niveles de test o prueba en cuanto a: objetivos importantes,

objetos típicos de la prueba, típicos targets de la prueba (Ej. funcional o estructural)y de productos relacionados con el trabajo, la gente que prueba, los tipos de defectosy fallos que deben ser identificados.(K2)

2.3 Tipos de test: targets del test (K2)• Comparar cuatro tipos de test de software (funcional, no funcional, estructural y

change-related ) mediante ejemplos.(K2)• Reconocer que pruebas funcionales y estructurales se llevan a cabo en cualquier

nivel de test. (K1)• Identificar y describir los tipos no funcionales de test basados en requisitos no

funcionales. (K2).• Identificar y describir los tipos de test basados en el análisis estructural o de

arquitectura del sistema software. (K2).• Describir el propósito de la prueba de confirmación (confirmation testing ) y de la

prueba de regresión (regresión testing ). (K2).

2.4 Prueba de mantenimiento• Compara la prueba de mantenimiento (que testea un sistema existente) al utilizado

para testear una nueva aplicación con respecto a los tipos de test, a los disparadores

de los test (triggers) y a la cantidad de pruebas. (K2).• Identificar las razones por las que se utilizan las pruebas de mantenimiento

(modificación, migración y retiro). (K1).• Describir el papel (rol) de la prueba de regresión y el análisis de impacto en

mantenimiento. (K2).






23-88

2.1 Modelos de desarrollo software (K2) | 20 minutos

TérminosSoftware con fines comerciales (COTS), modelo incremental de desarrollo, nivel de

prueba, validación, verificación, V-model.

Conocimientos previosEl test no existe aislado, las actividades de prueba se relacionan con las actividades

del desarrollo del software. Para distintos modelos del ciclo vital del desarrollo se necesitandiversos enfoques de prueba.

2.1.1 V-model (K2)

Aunque existen distintas variantes del V-model, un tipo común de V-model utilizacuatro niveles de prueba, correspondientes a los cuatro niveles del desarrollo. Los cuatro

niveles usados en el plan de estudios ( syllabus

) son:Prueba de componente (component testing ).Prueba de integración (integration testing ).Prueba de sistema ( system testing ).Prueba de aceptación (acceptance testing ).

En la práctica, un V-model puede tener más, menos o distintos niveles de desarrollo yde prueba, dependiendo del proyecto y del producto software. Por ejemplo, puede haber pruebas de integración de componente después de las pruebas de componente, y prueba deintegración de sistema después de una prueba de sistema.

Los trabajos en productos software (tales como escenarios de negocio o casos de uso,especificaciones de requisito, documentos del diseño y código) llevados a cabo durante eldesarrollo son a menudo la base de las prueba, en unos o más niveles de test. Lasreferencias para los productos genéricos de trabajo incluyen Capability Maturity Model

Integration (CMMI) o procesos del ciclo de vida del sotware (Software lifecycle processes,IEEE/IEC 12207).La verificación y la validación (y el diseño temprano de pruebas) se pueden realizar durante el desarrollo de los productos software.

2.1.2 Modelo de desarrollo iterativo (K2)

El desarrollo iterativo es el proceso de establecer requisitos, de diseñar, de construir yde probar un sistema, realizado como una serie de progresos más pequeños. Los ejemplosson: desarrollo orientado a prototipos, desarrollo de aplicaciones rápido (RAD), procesounificado racional (RUP) y modelos de desarrollo ágil. El incremento producido por unaiteración puede ser probado en varios niveles como parte de su desarrollo. Un incremento,añadido a otros desarrollados previamente, forma un sistema parcial cada vez mayor, quedebe también ser probado. La prueba de regresión es cada vez más importante en todas las






24-88

iteraciones tras la primera. La verificación y la validación se pueden realizar en cadaincremento.

2.1.3 Pruebas dentro del modelo de ciclo de vida (K2)

En cualquier modelo de ciclo de vida se distinguen las siguientes características paraun buen test:• Para cada actividad del desarrollo tiene que existir una actividad de prueba.• Cada nivel de test tiene objetivos específicos del nivel.• El análisis y diseño de los tests para un nivel dado de la prueba debe comenzar

durante la actividad correspondiente del desarrollo.• Los testadores deben estar implicados en la revisión de los documentos tan pronto

como los borradores estén disponibles en el ciclo de vida del desarrollo.

Los niveles de test se pueden combinar o reorganizar dependiendo de la naturaleza del proyecto o la arquitectura del sistema. Por ejemplo, para la integración de un producto de

software con fines comerciales (COTS) en un sistema, el comprador puede realizar la prueba de integración a nivel de sistema (Ej. integración a la infraestructura y a otrossistemas, o al despliegue del sistema) y prueba de aceptación (funcional y/o no funcional, yel usuario y/o la prueba operacional).






25-88

2.2 Niveles de test (K2) | 60 minutos

TérminosPrueba alfa (alfa testing ), prueba beta (beta testing ), prueba de componente

(component testing , también conocido como unidad, módulo o programa a probar), pruebade aceptación del contrato, drivers, prueba de campo ( field testing ), requisitos funcionales,integración, prueba de integración (integration testing ), requisitos no funcionales, pruebaoperacional o de aceptación (operational testing ), prueba de aceptación de norma, pruebade robustez, stubs, prueba de sistema, test-driven development , entorno de prueba, pruebade aceptación de usuarios.

Conocimientos previosPara cada uno de los niveles de prueba se pueden identificar los siguientes aspectos:

objetivos genéricos, productos de trabajo que hacen referencia para derivar los casos de la prueba (base del test), el objeto de la prueba (qué se está probando), los defectos y las fallosde ser encontrado, los requisitos que sustentan el test y la ayuda de la herramienta, yenfoques específicos y las responsabilidades.

2.2.1 Prueba de componente (component testing ) (K2)

La prueba de componente realiza la búsqueda de defectos y verificación delfuncionamiento del software que puede ser testeado por separado (Ej. módulos, programas,objetos, clases, los etc.). Puede ser llevado a cabo sin tener en cuenta el resto del sistema,dependiendo del contexto del ciclo de vida del desarrollo y del sistema. Pueden utilizarse stubs, drivers y simuladores.

La prueba de componente puede incluir pruebas de funcionalidad, de característicasespecíficas no funcionales, tales como recurso-comportamiento (Ej. escapes de la memoria)o prueba de robustez, así como prueba estructural (Ej. cobertura de rama, branch

coverage). Los casos de prueba se derivan de elaboraciones del producto tales como unaespecificación del componente, el diseño software o el modelado de datos

Normalmente, la prueba de componente ocurre con arreglo al código que es probadoy con la ayuda del entorno del desarrollo, tal como un marco de prueba de unidad o unaherramienta de puesta a punto, y generalmente implica en la práctica al programador queescribió el código. Los defectos son usualmente fijos y son encontrados con facilidad, sininforme formal de incidencia.

Un enfoque de la prueba de componente es preparar y automatizar casos de pruebaantes de introducir código. Esto se llama un primer enfoque de prueba (test-first approach)o un desarrollo de prueba dirigido (test-driven development ). Este enfoque es altamenteiterativo y se basa en los ciclos de desarrollo de los casos de la prueba, y una vez se vanconstruyendo e integrando nuevas porciones de código, se ejecutan las pruebas delcomponente hasta que pasan.






26-88

2.2.2 Prueba de integración (integration testing ) (K2)

La prueba de integración se encarga de probar la interconexión entre loscomponentes, interacciones a diversas partes de un sistema, tales como sistema operativo,

sistema de ficheros, hardware o interfaces entre sistemas. Puede haber más de un nivel de prueba de integración y se puede realizar con objetos de prueba de diferentes tamaños. Por ejemplo:

• Una prueba de integración de componentes testea las interacciones entre loscomponentes software, y se hace después de llevar a cabo las pruebas decomponentes.

• Una prueba de integración de sistemas testea las interacciones entre diversossistemas y deben ser hechas después de probar del sistema. En este caso, laorganización del desarrollo debe controlar solamente un lado del interfaz, pues loscambios pueden producir desestabilización. Los procesos de negocio

implementados como flujos de trabajo (workflows) pueden implicar a un conjuntode sistemas. Las ediciones multiplataforma pueden ser significativas.

Cuanto mayor es el alcance de la integración, mas complejo se vuelve aislar los fallosde un componente específico o del sistema, lo que puede conducir a un riesgo creciente.

Las estrategias sistemáticas de integración se pueden basar en la arquitectura delsistema (tanto top-down como bottom-up), en las tareas funcionales, en las secuencias deltratamiento transaccional, o en otros aspecto del sistema o del componente. Para reducir elriesgo de descubrir defectos con tardía, la integración debe normalmente ser incrementalmás que un "big ban".

Las pruebas de características no funcionales específicas (Ej. funcionamiento) puedenser incluida en las pruebas de integración.

En cada etapa de la integración, los testadores se concentran solamente en laintegración sí misma. Por ejemplo, si están integrando el módulo A con el módulo B seinteresan en la prueba de comunicación entre módulos, no por la funcionalidad decualquiera de ellos. Pueden utilizarse tanto enfoques funcionales como estructurales.

Idealmente, los testadores deberían entender la arquitectura y la influencia de la planificación de la integración. Si las pruebas de integración se planifican antes de que se

construyan los componentes o los sistemas, éstos podrían ser construidos en ordenconseguir pruebas más eficientes.

2.2.3 Prueba de sistema (system testing ) (K2)

La prueba de sistema se refiere al comportamiento de un sistema-producto completosegún lo definido en el alcance del proyecto o programa.






27-88

En la prueba de sistema, el entorno de prueba debe corresponder al entorno final oentorno de producción tanto como sea posible para reducir al mínimo el riesgo de fallosespecíficos del entorno que no sean encontrados en las pruebas.

La prueba de sistema puede incluir pruebas basadas en riesgos y/o en especificaciones

de requisitos, procesos de negocio, casos de uso, u otras descripciones del comportamientodel sistema, interacciones de alto nivel con el sistema operativo, y recursos de sistema.

En la prueba de sistema se deben probar los requisitos funcionales y no funcionalesdel sistema. Los requisitos pueden estar especificados mediante texto y/o con modelos. Lostestadores también necesitan ocuparse de requisitos incompletos o no documentados. La prueba de requisitos funcionales del sistema hará uso de las técnicas más apropiadas (cajanegra) en función de los aspectos que se desean probar del sistema. Por ejemplo, se puedecrear una tabla de decisión con las combinaciones de los efectos descritos en reglas denegocio. Las técnicas basadas en estructura (caja blanca) se pueden utilizar para probar conminuciosidad un elemento estructural, como por ejemplo una estructura de menú o

navegación de una página Web. (Véase el Capítulo 4.)

La prueba de sistema es realizado a menudo por un equipo independiente de test.

2.2.4 Prueba de aceptación (acceptance testing ) (K2)

La prueba de aceptación es responsabilidad de los usuarios finales (clientes), aunqueotros stakeholders pueden estar involucrados.

La meta de la prueba de aceptación es establecer confianza en el sistema, en partes delmismo o en las características no funcionales específicas del sistema. Encontrar defectos

no es el objetivo principal de la prueba de aceptación. La prueba de aceptación puededeterminar la preparación del sistema para su despliegue y uso, aunque no esnecesariamente el último nivel de pruebas. Por ejemplo, una prueba de integración de unsistema a gran escala puede llevarse a cabo después de una prueba de aceptación.

La prueba de aceptación puede llevarse a cabo en más de un simple nivel de test, por ejemplo:

• Un producto software con fines comerciales debe pasar una prueba de aceptacióncuando es instalado o integrado.

• Durante la prueba de componente se puede realizar una prueba de aceptación de lausabilidad del mismo.

• Puede realizarse una prueba de aceptación de una nueva funcionalidad incorporadaantes de probar el sistema (prueba de sistema).

La forma típica de prueba de aceptación incluye lo siguiente:

Prueba de aceptación de usuario (User acceptance testing) Verifica típicamente la aptitud para el uso del sistema de los usuarios de negocio.






28-88

Prueba de aceptación del funcionamiento (Operacional acceptance testing) La aceptación del sistema por parte de los administradores del mismo incluye:

• Prueba de copia de seguridad y restauración del sistema• Recuperación ante desastre• Gestión de usuarios• Tareas de mantenimiento• Chequeos periódicos de las vulnerabilidades de seguridad.

Prueba de aceptación del contrato y normativa (Contract and regulation acceptance

testing) La prueba de aceptación del contrato se realiza según los criterios de aceptación de un

contrato para producir software de cliente. Los criterios de aceptación deben ser definidoscuando se acuerda el contrato. La prueba de aceptación de la normativa se realiza segúncualquier regulación a las cuales deba ser adherido, por ejemplo regulacionesgubernamentales, legales o de seguridad.

Pruebas alfa y beta En los productos software con fines comerciales, o COTS, se requiere a menudo la

obtención de las observaciones de los clientes potenciales o existentes en su mercado antesde que el producto software salga a la venta comercialmente. Una prueba alfa se realiza enla propia organización desarrolladora. Una prueba beta es realizada por la gente en sus propias localizaciones. Ambas son realizadas por clientes potenciales, no por losdesarrolladores del producto.

Las organizaciones pueden utilizar otros términos, como por ejemplo, prueba de laaceptación de fábrica ( factory acceptance testing ) y prueba de aceptación en suemplazamiento ( site acceptance testing ), para sistemas que son testados antes y después de

llevarse al emplazamiento del cliente.






29-88

2.3 Tipos de test: targets de las pruebas (K2) | 60 minutos

TérminosAutomatización, prueba de caja negra, cobertura del código, prueba de confirmación,

prueba funcional, prueba de interoperabilidad, prueba de carga, prueba de capacidad demantenimiento, prueba de funcionamiento, prueba de portabilidad, prueba de regresión, prueba de confiabilidad, prueba de seguridad, prueba basada en especificación, prueba detensión ( stress testing ), prueba estructural, test suite, prueba de usabilidad, prueba de caja blanca.

Conocimientos previosUn grupo de actividades de test se puede dirigir a verificar el sistema de software (o

una parte de un sistema) basada en una razón o target específico a probar.

Un tipo de test se centra en un objetivo particular a probar, pudiéndose tratar, por ejemplo, de una prueba de funcionalidad del software, de una característica de calidad,como confiabilidad o usabilidad, de la estructura o alguna arquitectura no funcional delsoftware o sistema, o relacionado con los cambios, es decir confirmando que los defectoshan estado fijados (prueba de confirmación) y buscando los cambios involuntarios (pruebade regresión).

Un modelo de software se puede desarrollar y/o utilizar en una prueba estructural yfuncional. Por ejemplo, en una prueba funcional se puede utilizar un modelo de flujo de procesos, un modelo de transición de estados o una especificación en lenguaje llano, y enuna prueba estructural se puede utilizar un modelo de flujo de control o un modelo deestructura de menú.

2.3.1 Prueba de funcionamiento o funcional (test of function o functional testing )

(K2)

Las funciones que un sistema, subsistema o componente deben realizar se puedendescribir en documentos de trabajo tales como una especificación de requisitos, casos deuso, o una especificación funcional, o bien no estar documentadas. Las funciones definen"qué" hace el sistema.

Las pruebas funcionales se basan en estas funciones y características (descritas endocumentos o entendidas por los testadores), y se pueden realizar en todos los niveles de

prueba (Ej. las pruebas de componentes están basados en las especificaciones de loscomponentes).

Las técnicas basadas en especificación se pueden utilizar para derivar condiciones de prueba y para probar casos de la funcionalidad del software o del sistema. (Véase ElCapítulo 4.) La prueba funcional considera el comportamiento externo del software (pruebade caja negra).






30-88

Un tipo de prueba funcional, es un test de seguridad, en el que se investiga lasfunciones (Ej. un cortafuego) referentes a la detección de amenazas, tales como virus, ointrusos malévolos.

2.3.2 Prueba de características del producto software o prueba no funcional

(test of software producto characteristics or non-functional testing ) (K2)

La prueba no funcional incluye, pero no se limita a, prueba de funcionamiento, pruebade carga, prueba de tensión ( stress testing ), prueba de usabilidad, prueba deinteroperabilidad, prueba de mantenimiento, prueba de confiabilidad y prueba de portabilidad. La prueba no funcional testea “cómo” trabaja el sistema.

La prueba no funcional se puede realizar en todos los niveles de test o prueba. Elconcepto de prueba no funcional describe las pruebas requeridas para medir característicasde los sistemas y del software que se pueden cuantificar en una escala variable, viendocomo responde en tiempo a las pruebas de funcionamiento. Estas pruebas se pueden referir

a un modelo de calidad, como por ejemplo el definido en la normativa ISO 9126 de“Ingeniería del Software - Calidad del Producto Software” (Software Engineering – Software Product Quality).

2.3.3 Prueba de la estructura-arquitectura de software o prueba estructural

(Testing of software structure-architecture or structural testing ) (K2)

La prueba estructural (caja blanca) se puede realizar en todos los niveles de test o prueba. Las técnicas estructurales se utilizan mejor después de técnicas basadas enespecificación, con el propósito de ayudar a medir con detalle la prueba por medio delcálculo de la cobertura de un tipo de estructura.

La cobertura es el grado que una estructura ha sido ejercitada por test suite, expresadacomo porcentaje de los elementos que se han cubierto. Si la cobertura no es del 100%,entonces se pueden diseñar más tests para probar los elementos que fallaron y, por lo tanto,aumentar la cobertura. Las técnicas de cobertura se detallan en el capítulo 4.

En todos los niveles de test, pero especialmente en las pruebas de componente y en la prueba de integración de componentes, se pueden utilizar estas herramientas para medir lacobertura del código de los elementos, tales como declaraciones o decisiones. La pruebaestructural se puede basar en la arquitectura del sistema, también denominada jerarquía.

Los enfoques de las pruebas estructurales se pueden aplicar también al sistema, a laintegración de sistema o a los niveles de prueba de aceptación (Ej. en los modelos denegocio o las estructuras de menú).

2.3.4 Pruebas relacionadas con cambios, o prueba de confirmación o de

regresión (testing related to changes, confirmation and regresión testing ) (K2)






31-88

Cuando un defecto se detecta y se resuelve ( fixed ) entonces el software debe ser reexaminado para confirmar que el defecto original se ha eliminado con éxito. A este tipode prueba se le denomina prueba de confirmación. La eliminación de los errores, resolucióndel defecto (defect fixing ), es una actividad del desarrollo, no una actividad de prueba.

La prueba de regresión (regression test ) es la prueba repetida de un programa ya probado, después de alguna modificación, para descubrir cualquier defecto introducidocomo resultado de los cambios. Estos defectos pueden estar en el software que es probado,o en otro componente software relacionado o sin relación. Se realiza cuando se cambia elsoftware, o su entorno. El grado de la prueba de regresión se basa en el riesgo de noencontrar defectos en el software con el que trabajaba previamente.

Los tests deben ser repetibles si van a utilizarse como parte de las pruebas deconfirmación o regresión.

La prueba de regresión se puede realizar en todos los niveles de prueba, y se aplica en pruebas funcionales, no funcionales y estructurales. Los test suites de regresión se ejecutanmuchas veces y se desarrollan por lo general lentamente, así pues se establece como unfuerte candidato para automatización.






32-88

2.4 Prueba de Mantenimiento (K2) | 15 minutos

TérminosAnálisis de impacto, prueba de mantenimiento, migración, modificaciones y retirada.

Conocimientos previosUna vez que esté desplegado un sistema de software esté a menudo en servicio por

años o décadas. Durante este tiempo el sistema y su entorno normalmente son corregidos,cambiados o ampliados. La prueba de mantenimiento se realiza sobre un sistemaoperacional existente, y es accionado al llevarse a cabo modificaciones, migración, oretirada del software o del sistema.

Las modificaciones incluyen ampliaciones planificadas (Ej. released-based ), cambioscorrectivos y de emergencia, y cambios de entorno, tales como mejoras previstas delsistema operativo o de la base de datos, o parches para las vulnerabilidades aparecidas odescubiertas del sistema operativo.

La prueba de mantenimiento para la migración (Ej. cambio de plataforma) debeincluir pruebas operacionales del nuevo entrono, así como del software que ha cambiado.

La prueba de mantenimiento para la retirada de un sistema puede incluir la prueba demigración de datos o el almacenamiento de la información requeridos tras largos períodosde retención de datos.

Además de probar lo que se ha cambiado, la prueba de mantenimiento incluye la prueba de regresión extensiva (extensive regresion testing ), que testea las partes del sistemaque no se han cambiado. El alcance de la prueba de mantenimiento se relaciona con elriesgo de cambio, el tamaño del sistema existente y con el tamaño del cambio.Dependiendo de los cambios, la prueba de mantenimiento se puede hacer para nivelescualesquiera o para todos los niveles de prueba, y para cualesquiera o todos los tipos de la prueba.

La forma de determinar cómo el sistema existente puede verse afectado por loscambios se llama análisis del impacto, y se utiliza para ayudar a decidir la cantidad de pruebas de regresión que es necesario llevar a cabo.

La prueba de mantenimiento puede ser difícil si faltan especificaciones o estánanticuadas.

Referencias

2.1.3 CMMI, Craig, 2002, Hetzel, 1998, IEEE 122072.2 Hetzel, 19982.2.4 Copeland, 2004, Myers, 19792.3.1 Beizer, 1990, Black, 2001, Copeland, 20042.3.2 Black, 2001, ISO 9126






33-88

2.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 19982.3.4 Hetzel, 1998, IEEE 8292.4 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829






34-88

3. Técnicas estáticas (K2) | 60 minutos

Objetivos de aprendizaje para técnicas estáticasLos objetivos identifican lo que será capaz de hacer al finalizar cada módulo.

3.1 Revisiones y el proceso de test (K2)• Reconocer los productos software que puedan ser examinados mediante las

diferentes técnicas estáticas.(K1)• Describir la importancia y el valor de considerar técnicas estáticas para el

asesoramiento de productos software.(K2)• Explicar la diferencia entre técnicas estáticas y dinámicas.(K2)

3.2 Proceso de revisión (K2)• Repasar las fases, roles y responsabilidades de una revisión formal típica.(K1)• Explicar las diferencias entre los diferentes tipos de revisión: revisión informal,

revisión técnica, walkthrough e inspección.(K2)• Explicar los factores para un funcionamiento de revisiones satisfactorio.(K2)

3.3 Análisis estático por herramientas (K2)• Describir los objetivos del análisis estático y compararlos con las pruebas

dinámicas.(K2)• Repasar los defectos típicos y los errores identificados por el análisis estático y

compararlos con las revisiones y las pruebas dinámicas.(K1)• Enumerar los beneficios típicos del análisis estático.(K1)• Enumerar los defectos típicos del código y diseño que se hayan podido identificar

mediante herramientas de análisis estático.(K1)






35-88

3.1 Revisiones y procesos de prueba (K2) | 15 minutos

TérminosPruebas dinámicas, revisiones, análisis estático.

Conocimientos previosLas técnicas de prueba estáticas no ejecutan el software que está siendo probado; son

manuales (revisiones) o automáticas (análisis estático).

Las revisiones son una forma de probar productos software (incluyendo código) y pueden ser ejecutadas antes de la ejecución de la prueba dinámica. Los defectos detectadosdurante las revisiones al inicio del ciclo de vida son a menudo, mucho más fáciles deeliminar que aquellos detectados durante las pruebas en ejecución (Ej. defectos encontradosen requisitos).

Una revisión podría hacerse completamente como una actividad manual, aunquetambién hay herramientas de soporte. La principal actividad manual es la de examinar un producto y hacer comentarios sobre el. Cualquier producto software puede ser revisado,incluyendo la especificación de requisitos, especificación de diseño, código, plan de pruebas, especificación de pruebas, casos de uso, scripts de prueba, manual de usuario o páginas Web.

Los beneficios de las revisiones incluyen la pronta detección de defectos y sucorrección, mejoras en la productividad del desarrollo, escalas de tiempo de desarrolloreducidas, coste de pruebas y de tiempo reducidos, reducciones en el coste del ciclo devida, menos defectos y una comunicación mejorada. Las revisiones pueden encontrar omisiones, por ejemplo, en los requerimientos, que son improbables de encontrar en las

pruebas dinámicas.

Revisiones, análisis estáticos y pruebas dinámicas tienen el mismo objetivo – identificación de defectos. Son complementarios: las diferentes técnicas pueden encontrar diferentes tipos de defectos efectivamente y eficientemente. En contraste a las pruebasdinámicas, las revisiones encuentras defectos más que fallos.

Los defectos típicos que son más fáciles de encontrar en las revisiones que en las pruebas dinámicas son: desviaciones de estándares, defectos de requisitos, defectos dediseño, mantenibilidad insuficiente y la especificación de la interfaz incorrecta.






36-88

3.2 Proceso de revisión (K2) | 25 minutos

Términos Criterios de entrada, criterios de salida, revisión formal, revisión informal, inspección,

kick-off , métricas, moderador/líder de inspección, revisión par, revisor, reunión de revisión,

proceso de revisión, scribe, revisión técnica, walkthrough.

Conocimientos previosLas revisiones varían de informales a muy informales (bien estructuradas y

reguladas). La formalidad de un proceso de revisión está relacionada con factores como lamadurez del proceso de desarrollo, cualquier requisito regulador o legal o la necesidad deun rastro para la auditoria.

La manera en la que una revisión se lleva a cabo depende del objetivo acordado de larevisión (Ej. Encontrar defectos, ganar entendimiento, o discusión y decisión por consenso).

3.2.1 Fases de una revisión formal (K1)

Una revisión formal típica tiene las siguientes fases principales:

• Planificación: selección del personal, asignación de roles; definición de criterios deentrada y salida para otros tipos de revisión formal (Ej. inspección); y seleccionar las partes del documento a las que mirar.

• Kick-off: distribución de documentos; explicación de los objetivos, procesos ydocumentos a los participantes; y comprobando los criterios de entrada (para mástipos de revisión formal).

• Preparación individual: trabajo realizado por su cuenta de cada participante antes dela reunión de revisión, haciendo notar defectos en potencia, preguntas ycomentarios.

• Reunión de revisión: discusión, con resultados documentados o minutos (para mástipos de revisión formal). Los participantes reunidos pueden simplemente anotar defectos, hacer recomendaciones para manejar los defectos, o hacer decisionessobre los defectos.

• Rework: arreglar los defectos encontrados, normalmente hecho por el autor.• Follow-up: comprobación de los defectos que se hayan definido, recogida de

métricas y chequeo de los criterios de salida (para más tipos de revisión formal).

3.2.2 Roles y responsabilidades (K1)

Una típica revisión formal incluiría los roles siguientes:

• Manager: decide sobre la ejecución de las revisiones, gestiona el tiempo en la programación del proyecto y determina si los objetivos de la revisión se hancumplido.






37-88

• Moderador: la persona que lidera la revisión del documento o del conjunto dedocumentos, incluyendo la planificación de la revisión, preparar la reunión, yquedarse al tanto después de la reunión. Si fuera necesario, el moderador puedemediar entre varios puntos de vista y será a menudo la persona sobre la que dependael éxito de la reunión.

• Autor: el escritor o persona encargada responsable de la revisión de los documentos.• Revisores: individuos con conocimientos técnicos o de negocio (también

denominados comprobadores o inspectores) que, después de una preparaciónnecesaria, identifican y describen los descubrimientos (Ej. defectos) en el productoque esta bajo revisión. Los revisores deben ser seleccionados para representar lasdiferentes perspectivas y roles el proceso de revisión y toman parte el las reunionesde revisión.

• Scribe (o grabador): documenta todas las cuestiones, problemas y cuestiones sinresolver identificadas en la reunión.

Mirando a los documentos desde diferentes perspectivas, y usando checklists, se

pueden hacer las revisiones más efectivas y eficientes, por ejemplo, un checklist basado en perspectivas como usuario, mantenedor, probador o operaciones, o un checklist típico de problemas de requisitos.

3.2.3 Tipos de revisión (K2)

Un simple documento puede ser el objetivo de más de una revisión. Si se usa más deun tipo de revisión, el orden puede variar. Por ejemplo, una revisión informal se puedellevar a cabo antes de una revisión técnica, o una inspección se puede llevar a cabo debido ala especificación de un requisito antes de un walkthrough con clientes. Las principalescaracterísticas, opciones e intenciones de los tipos de revisión comunes son:

Revisión informal

Características clave:• No hay proceso formal.• Puede haber programación en pareja o un líder técnico revisando el diseño y el

código.• Opcionalmente puede ser documentado.• Puede variar su utilidad dependiendo del revisor.• Propósito principal: manera económica de obtener algún resultado.

Walkthrough:

Características clave:• Reunión liderada por el autor;• Escenarios, dry runs, grupos peer ;• Sesiones open-ended;• Opcionalmente una preparación de la reunión previa de los revisores, documento de

revisión, lista de descubrimientos y scribe (que no es el autor).• Puede variar en la práctica de algo formal a muy formal.






38-88

• Propósitos principales: aprender, ganar entendimiento, averiguación de defectos.

Revisión técnica

Características clave:• documentado, proceso de detección de defectos definido que incluya peers y

expertos técnicos.• Puede ser realizado como una revisión peer sin la participación de un jefe;• Idealmente liderado por un moderador preparado(no el autor);• Preparación antes de la reunión;• Opcionalmente el uso de checklists, documento de revisión, listado de

averiguaciones y participación de jefes.• Puede variar en la practica de algo formal a muy formal;• Propósitos principales: discusiones, toma de decisiones, evaluación de alternativas,

averiguación de defectos, resolución de problemas técnicos y comprobación devalidez con las especificaciones y los estándares.

InspecciónCaracterísticas clave:

• liderado por un moderador preparado(no el autor);• generalmente examinaciones peer ;• roles definidos;• métricas incluidas;• proceso formal basado en reglas y checklists con criterios de entrada y salida;• preparación previa a la reunión;• documento de inspección, lista de averiguaciones;• proceso formal follow-up;• opcionalmente, mejora del proceso y lector;• Propósito principal: encontrar defectos.

3.2.4 Factores de éxito para revisiones (K2)

Los factores de éxito para las revisiones incluyen:• Cada revisión tiene un objetivo predefinido claro.• Las personas involucradas para la revisión son las adecuadas.• Los defectos encontrados son bienvenidos, y expresados objetivamente.• Se trata con los problemas de las personas y los aspectos psicológicos (Ej.

haciéndolos una experiencia positiva para el autor).• Las técnicas de revisión son aplicadas tal que sean adecuadas al tipo y nivel de los

productos software y revisores.• Checklists y roles son usados apropiadamente para incrementar la efectividad de la

identificación de defectos.• Se da una preparación en las técnicas de revisión, especialmente las técnicas

formales, como la inspección.






39-88

• La gestión soporta un buen proceso de revisión (Ej. mediante la incorporación detiempo adecuada para las actividades de revisión en la programación de proyectos).

• Hay un énfasis en aprender y mejorar el proceso.

3.3 Análisis estático por herramientas (K2) | 20 minutos

TérminosCompilador, complejidad, control de flujo, flujo de datos, análisis estático.

Conocimientos previosEl objetivo del análisis estático es el de encontrar defectos en el código fuente del

software y el los modelos software. El análisis estático se realiza sin necesidad de ejecutar el software examinado por la herramienta; las pruebas dinámicas si ejecutan el códigosoftware. El análisis estático puede localizar defectos que son difíciles de encontrar en las pruebas. Como con las revisiones, el análisis estático encuentra defectos más que fallos.Las herramientas de análisis estático analizan el código del programa (Ej. control de flujo ycontrol de datos), al igual que generan una salida como HTML y XML.

El valor del análisis estático es:• Detección temprana de defectos antes de la ejecución de pruebas.• Avisos tempranos sobre aspectos sospechosos del código o el diseño, mediante el

cálculo de métricas, como las medidas de gran complejidad.• Identificación de defectos difícilmente encontrados por las pruebas dinámicas.• Detección de dependencias e inconsistencias en los modelos software, como

enlaces.• Mantenibilidad mejorada del código y del diseño.•

Prevención de defectos, si las lecciones son aprendidas durante el desarrollo.

Defectos típicos descubiertos por las herramientas de análisis estático incluyen:• referenciar una variable con un valor indefinido;• interfaz inconsistente entre módulos y componentes;• variables nunca usadas;• código inalcanzable(muerto);• violaciones de programa estándar;• vulnerabilidades de seguridad;• violación de la sintaxis de código y modelos software.

Las herramientas de análisis estático son típicamente usadas por desarrolladores(comprobando contra reglas predefinidas y estándares de programación) antes y durante las pruebas de componentes y de integración, y por diseñadores durante el modelado delsoftware. Las herramientas de análisis estático pueden producir un alto número de mensajesde aviso, que deberán ser bien gestionados para permitir el uso más efectivo de laherramienta.






40-88

Los compiladores pueden ofrecer soporte para el análisis estático, incluyendo loscálculos de métricas.

Referencias

3.2 IEEE 10283.2.2 Gilb, 1993, van Veenendaal, 20043.2.4 Gilb, 1993, IEEE 10283.3 Van Veenendaal, 2004






41-88

4. Técnicas de diseño de test (K3) | 255 minutos

Objetivos de aprendizaje para técnicas de diseño de test Los objetivos identifican lo que será capaz de hacer al finalizar cada módulo.

4.1 Identificación de las condiciones de test y diseño de los casos de

prueba (K3)

• Diferenciar entre la especificación del diseño de test, especificación de los casos de prueba y especificación del procedimiento de test (K1).

• Comparar los términos condiciones de prueba, casos de prueba y procedimiento de prueba (K2).

• Escribir los casos de prueba: (K3)- mostrar una trazabilidad clara de los requisitos- incluir un resultado esperado

• Traducir los casos de prueba a una especificación de procedimientos de prueba bienestructurados, con nivel de detalle acorde a los conocimientos de los probadores.• Redactar una secuencia de ejecución de pruebas para un determinado conjunto de

casos de prueba, considerando las prioridades así como las dependencias lógicas ytécnicas.

4.2 Categorías de las técnicas de diseño de pruebas (K2)

• Recordar las razones tanto las basadas en especificación (caja negra) como enestructura (caja blanca) que sean útiles para el diseño de casos de prueba, y hacer una lista de las técnicas comunes para cada uno. (K1)

• Explicar las características y diferencias entre pruebas basadas en especificación, enestructura y en experiencia. (K2).

4.3 Técnicas basadas en especificación o de caja negra (K3)

• Escribir los casos de prueba para un determinado modelo software usando lassiguientes técnicas de diseño de pruebas: (K3)- Particionado equivalente- Análisis y acotación de valores- Tablas de decisión- Diagramas de transición de estado

• Comprender el propósito de cada una de las cuatro técnicas, el nivel y tipo de

pruebas que puede usar la técnica, y cómo ha de ser ponderada la cobertura (K2).• Comprender el concepto de usar casos de prueba y sus beneficios (K2).






42-88

4.4 Técnicas basadas en estructura o de caja blanca (K3)

• Describir el concepto e importancia de la cobertura de código (K2)• Explicar los conceptos de cobertura de estado y decisión, y ayudan a entender que

estos conceptos pueden ser también usados en otros niveles de prueba además de las pruebas de componentes (por ejemplo, en procedimientos de negocio a nivel desistema) (K2)

• Escribir los casos de prueba de un control de flujo dado usando las siguientestécnicas de diseño de pruebas: (K3)- pruebas de estado- pruebas de decisión

• Valorar la cobertura de estado y decisión (K3)

4.5 Técnicas basadas en la experiencia (K2)

• Escribir casos de prueba basados en la intuición, experiencia y conocimiento defallos típicos (K1)

• Comparar las técnicas de prueba basadas en la experiencia con las técnicas basadasen especificación

4.6 Elección de las técnicas de prueba (K2)

• Hacer una lista de factores que influyen en la selección de la técnica de diseño de pruebas apropiada para un determinado problema, tal como tipo de sistema, riesgos,modelado de casos de uso, requerimientos de los modelos o conocimientos del probador. (K2)






43-88

4.1 Identificación de las condiciones y diseño de los casos de prueba (K3) |

15 minutos

Términos

Casos de prueba, especificación de casos de prueba, condiciones de prueba, datos de prueba, especificación del procedimiento de pruebas, script de pruebas, trazabilidad.


El proceso de identificación de las condiciones y diseño de pruebas consiste en unaserie de pasos:

• Diseño de las pruebas mediante la identificación de condiciones de prueba,• Especificación de los casos de prueba,• Especificación de los procedimientos de pruebas

El proceso se puede realizar de distintas maneras, puede ser desde informal condocumentación escasa o inexistente, hasta muy formal (como se describe en este apartado).

El nivel de formalización depende del contexto de las pruebas, incluyendo laorganización, la madurez de los procesos de prueba y desarrollo, restricciones temporales yel personal involucrado.

Durante el diseño de las pruebas, se analiza la documentación básica para determinar qué hay que probar, ej. identificar las condiciones de prueba. Una condición de prueba sedefine como un elemento o evento que puede ser verificado mediante uno o varios casos de prueba (ej. una función, una transacción, una cualidad característica o un elemento

estructural).Establecer la trazabilidad desde las condiciones de prueba hacia la especificación y

requisitos permite tanto el análisis de impactos, cuando los requisitos cambien, como lacobertura de requisitos a determinar por un conjunto de pruebas. Durante el diseño de pruebas se implementa el esquema detallado de las pruebas, basándose entre otrasconsideraciones, en los riesgos que se hayan identificado (para ver más sobre análisis deriesgo, consultar el Capítulo 5).

Durante la especificación de casos de pruebas, los casos de prueba y los datos de las pruebas se desarrollan y describen en detalle mediante técnicas de diseño de pruebas. Un

caso de prueba consiste en un conjunto de valores de entrada, precondiciones de ejecución,resultados esperados y/o condiciones post-ejecución, desarrollados para cubrir determinadas condiciones de prueba. La documentación del “Estándar para pruebas desoftware” (IEEE 829) describe el contenido de las especificaciones para el diseño de casosde prueba.

Los resultados esperados deben formar parte de la especificación de un caso de prueba e incluir salidas, cambios de datos y estados, y cualquier otra consecuencia de la prueba. Si los resultados esperados no se definen, puede ocurrir que un resultado de la






44-88

prueba aparentemente correcto, pero erróneo, sea interpretado como bueno. Los resultadosesperados deben ser definidos antes de la ejecución de la prueba.

En la especificación del procedimiento de pruebas, se ponen los casos de prueba enorden de ejecución. El procedimiento de pruebas (o manual del script de pruebas)

especifica la secuencia de acciones para la ejecución de una prueba. Si las pruebas seejecutan usando alguna herramienta de ejecución de pruebas, la secuencia de acciones seespecifica en un script de pruebas (que es un procedimiento de pruebas automatizado).

Las distintas pruebas y scripts de automatización de pruebas se estructuran dentro deuna secuencia de ejecución de pruebas que define el orden en que los distintos procedimientos de pruebas, y los posibles scripts de automatización, son ejecutados, cuandoson llevados a cabo por alguien. La secuencia de ejecución de pruebas tendrá en cuentafactores tales como pruebas de regresión, priorización y dependencias técnicas y lógicas.






45-88

4.2 Categorías de las técnicas de diseño de pruebas (K2) | 15 minutos

Términos

Técnicas de caja negra, técnicas basadas en la experiencia, técnicas basadas en

especificación, técnicas basadas en estructura, técnicas de caja blanca


El propósito de las técnicas de diseño de prueba es identificar las condiciones de prueba y los casos de prueba.

La denominación de las técnicas de prueba como de caja negra o de caja blanca esuna distinción clásica. Las técnicas de caja negra (también conocidas como técnicas basadas en especificación) son un modo de seleccionar y modificar condiciones o casos de prueba basándose en la documentación básica de las pruebas, ya sean funcionales o no, deun componente o sistema sin tener en cuenta su estructura interna. Las técnicas de caja blanca (también conocidas como técnicas estructurales o basadas en estructura) se basan enel análisis de la estructura interna del componente o sistema.

Algunas técnicas pertenecen claramente a una única categoría, otras tienen elementos pertenecientes a más de una categoría. Este manual de estudios hace referencia a lastécnicas basadas en especificación o basadas en experiencia como técnicas de caja negra, ya las técnicas basadas en estructura como técnicas de caja blanca.

Características comunes de las técnicas basadas en especificación

• Los modelos, tanto los formales como los informales, se usan para especificar el problema a resolver, el software o sus componentes.

• A partir de estos modelos, los casos de prueba se obtienen sistemáticamente.

Características comunes de las técnicas basadas en especificación

• La información de cómo está hecho el software se usa para implementar los casosde prueba, por ejemplo, el código y diseño.

• La extensión de la cobertura del software puede medirse para algunos casos de prueba, pudiéndose obtener casos de prueba futuros que incrementen la cobertura.

Características comunes de las técnicas basadas en la experiencia

• El conocimiento y experiencia de las personas se usan para obtener los casos de

prueba:- Conocimientos de los probadores, desarrolladores y usuarios del software, se usaen este entorno- Conocimiento de errores comunes y su distribución






46-88

4.3 Técnicas basadas en especificación o de caja negra (K3) | 120 minutos

Términos

Análisis de valores límite, tabla de decisión de pruebas, particionamiento por

equivalencia, pruebas de transición de estado, pruebas de casos de uso.

4.3.1 Particionamiento por equivalencia (K3)

Las entradas del software o del sistema se dividen en grupos de los que se espera uncomportamiento similar, por los que se procesarán de forma parecida. Las particiones por equivalencia (o por clases) se pueden hallar tanto para datos correctos como incorrectos, por ejemplo, valores que deben ser rechazados. También se pueden identificar particiones para las salidas, valores internos, valores relacionados con el tiempo (por ejemplo, antes odespués de un evento) y para parámetros de interfaces (por ejemplo, durante las pruebas deintegración). Las pruebas se pueden diseñar para cubrir las particiones. La partición por

equivalencia (EP) se aplica a todos los niveles de prueba.

La partición por equivalencia, como técnica en sí, puede ser usada para conseguir cobertura de entrada y salida. Se puede aplicar a las entradas de usuarios, entradas víainterfaces del sistema, o parámetros de interfaz en las pruebas de integración.

4.3.2 Análisis de valores límite (K3)

El comportamiento en las fronteras de cada particionamiento de equivalencia puedeser incorrecto, por eso la acotación de valores trata de corregir defectos. Los valoresmáximo y mínimo de una partición son sus valores límite. Un valor límite de una particiónválida es un valor límite válido. Los límites de una partición no válida son valores límite noválidos. Las pruebas pueden ser diseñadas para cubrir tanto valores límite válidos y noválidos. Cuando se diseñan casos de prueba, se elige un valor en cada límite.

El análisis de valores límite es aplicable a todos los niveles de prueba. Esrelativamente fácil de aplicar, y tiene gran capacidad de encontrar defectos.

Esta técnica es considerada a menudo como una extensión de la partición por equivalencia y puede ser usada para entradas de usuarios tales como, por ejemplo,temporización o tablas de límites. Los valores límite deben ser también usados para las pruebas de selección de datos.

4.3.3 Pruebas de tablas de decisión (K3)

Las tablas de decisión son un buen método de capturar requisitos del sistema quecontengan condiciones lógicas, así como para documentar el diseño interno del sistema.Deben usarse para guardar reglas complejas de negocio que se van a implementar por unsistema. Se analizan las especificaciones, y se definen las condiciones y acciones delsistema. Las condiciones de entrada y las acciones más indicadas son en muchas ocasiones






47-88

combinaciones de estados distintos de un simple “verdadero” o “falso”. La tabla dedecisión contiene condiciones de disparo, combinaciones de ‘verdadero’ y ‘falso’ paratodas las condiciones de entrada, y las acciones resultantes para cada combinación decondiciones ejecutadas. El convenio más usado para el uso de pruebas de tablas de decisiónes tener al menos una prueba por columna, que típicamente cubre todas las combinaciones

de condiciones de disparo.

La fuerza de las pruebas con tablas de decisión es que crea combinaciones decondiciones que no serían probadas de otra manera durante las pruebas. Deben ser aplicadas a todas las situaciones cuando las salidas del software dependen de variasentradas y decisiones lógicas.

4.3.4 Pruebas de transición de estado (K3)

Un sistema puede producir distintas respuestas dependiendo en las condicionesactuales o de su historia (su estado). En este caso, ese comportamiento del sistema puede

ser descrito como un diagrama de transición entre estados. Eso permite al probador tener una visión del software en términos de sus estados, transiciones entre estados, las entradas oeventos que disparan estos cambios de estado, y las consecuencias o salidas de estastransiciones. Los estados del sistema y objeto bajo pruebas se separan, de formaidentificable y finita. Una tabla de estados muestra la relación entre los estados u susentradas, y puede poner en evidencia transiciones posibles que son incorrectas. Las pruebas se pueden diseñar para cubrir una secuencia de estados típica, cubrir todos losestados, probar cada transición, probar secuencias de transiciones específicas, otransiciones incorrectas.

Las pruebas de transición de estado son muy usadas dentro de la industria del

software embebido y automatización de mecanismos en general. Sin embargo, esta técnicatambién se adapta al modelado de objetos de negocio como por ejemplo aplicaciones deInternet o escenarios de negocio.

4.3.5 Pruebas de casos de uso (K3)

Las pruebas se pueden especificar a partir de escenarios de casos de uso. Un caso deuso describe interacciones entre actores, incluyendo usuarios y el sistema, que producen unresultado o un valor. Cada caso de uso tiene precondiciones, que un caso de uso ha decumplir para que funcione correctamente. Cada caso de uso termina con post-condiciones,que son los resultados observables y el estado final del sistema después de que el caso de

uso se haya completado. Un caso de uso suele tener un escenario principal de ejecución (ej.el más probable), y a veces, ramificaciones alternativas.

Los casos de uso describen el flujo del proceso en un sistema basado en su estado realmás probable, por eso los casos de prueba derivados de los casos de uso son útiles sobretodo para descubrir defectos en el flujo de procesos reales del sistema. Los casos de uso,denominados frecuentemente escenarios, son muy útiles para el diseño de pruebas ensistemas con interacción tipo cliente-servidor. También ayudan a descubrir fallos de






48-88

integración causados por la interacción e interferencia de distintos componentes, que pruebas individuales de esos componentes no revelarían.






49-88

4.4 Técnicas basadas en estructura o de caja blanca (K3) | 60 minutos

Términos

Cobertura de código, cobertura de decisión, cobertura de sentencias, pruebas

estructurales, pruebas basadas en estructura, pruebas de caja blanca

Conocimientos previosLas pruebas basadas en estructura o de caja blanca están basadas en una identificación

estructural del software o sistema, como puede verse en los siguientes ejemplos:• A nivel de componente: la estructura es la del código en sí misma, por ejemplo,

sentencias, decisiones o ramificaciones.• A nivel de integración: la estructura puede ser un árbol de invocaciones (un

diagrama en que cada módulo invoca a otros módulos).• A nivel de sistema: el sistema puede ser una estructura de menús, un proceso de

negocio o una estructura tipo página Web.

4.4.1 Pruebas de sentencias y cobertura (K3)

En las pruebas de componentes, la cobertura de las sentencias es la valoración del porcentaje de sentencias ejecutadas que han sido procesadas por un conjunto de pruebas.Las pruebas de sentencias derivan en casos de prueba que ejecuten determinadassentencias, normalmente para aumentar la cobertura de sentencias.

4.4.2 Pruebas de decisión y cobertura (K3)

La cobertura de decisión, referida a las pruebas de ramificación, es la valoración del porcentaje de resultados de decisiones (por ejemplo, las salidas Verdadero y Falso de unasentencia IF) que han sido procesadas por un conjunto de pruebas. Las pruebas de decisiónderivan en casos de prueba que ejecutan decisiones específicas, normalmente para aumentar la cobertura de decisión.

Las pruebas de decisión son un caso de pruebas de control de flujo ya que generan uncontrol de flujo específico a través de los puntos de decisión. La cobertura de decisión esmás amplia que la de sentencias: el 100% de la cobertura de decisión garantiza el 100% dela cobertura de sentencias, pero no viceversa.

4.4.3 Otras técnicas basadas en estructura (K1)

Existen niveles más amplios de cobertura estructural más allá de la cobertura dedecisión, por ejemplo, cobertura condicional y cobertura de condición múltiple.

El concepto de cobertura puede aplicarse a otros niveles de prueba (por ejemplo anivel de integración) donde el porcentaje de módulos, componentes o clases que se van a






50-88

procesar por las pruebas pueda ser expresado como una cobertura de módulo, componenteo clase.

El uso de alguna herramienta es muy útil para realizar pruebas estructurales delcódigo.






51-88

4.5 Técnicas basadas en la experiencia (K2) | 30 minutos

Términos

Predicción de errores, pruebas de exploración


Puede que la técnica de pruebas más extendida sea la de predicción de errores. Las pruebas derivadas de la destreza e intuición del probador y su experiencia con aplicacionesy tecnologías similares. Cuando se usan para argumentar técnicas sistemáticas, las pruebasintuitivas pueden ser útiles para identificar determinadas pruebas que no son capturadasfácilmente mediante técnicas formales, especialmente cuando se aplican junto con losesquemas más formales de prueba. Sin embargo, estas técnicas pueden producir una ampliavariación de efectividad, dependiendo de la experiencia del probador. Un esquemaestructurado de la técnica de predicción de errores es una enumeración de la lista de posibles errores y el diseño de pruebas ligadas a estos errores. Esta lista de defectos y fallos puede ser construida a partir de la experiencia, datos disponibles de fallos y errores y delconocimiento sobre el por qué falla el software.

Las pruebas de exploración son concurrentes al diseño de pruebas, ejecución de las pruebas, aprendizaje de pruebas, basados en un documento de test que contenga losobjetivos de las pruebas, y llevadas a cabo dentro de marcos temporales. Es un esquemaque es más útil cuando hay una especificación pobre o inadecuada y fuentes compromisosde tiempo, o bien para argumentar o completar otro tipo de pruebas más formales. Las pruebas de exploración pueden servir como prueba del proceso de test, para ayudar aasegurarse de que los defectos más graves se van a encontrar.






52-88

4.6 Elección de las técnicas de prueba (K2) | 15 minutos

Términos

No existen conceptos principales


La elección de las técnicas de prueba a utilizar depende de varios factores, incluyendoel tipo de sistema, los estándares que regulan las pruebas, los requisitos contractuales delsistema o del cliente, el nivel de riesgo aceptable, los tipos de riesgos, los objetivos de las pruebas, la documentación disponible, el conocimiento de los probadores, el tiempo y presupuesto, el ciclo de vida del desarrollo, los modelos de casos de uso y la experiencia previa en los tipos de fallos encontrados.

Algunas técnicas de prueba son sólo aplicables a determinadas situaciones y nivelesde pruebas, otras son aplicables a todos los niveles.

Referencias

4.1 Craig, 2002, Hetzel, 1998, IEEE 8294.2 Beizer, 1990, Copeland, 20044.3.1 Copeland, 2004, Myers, 19794.3.2 Copeland, 2004, Myers, 19794.3.3 Beizer, 1990, Copeland, 20044.3.4 Beizer, 1990, Copeland, 20044.3.5 Copeland, 20044.4.3 Beizer, 1990, Copeland, 20044.5 Kaner, 20024.6 Beizer, 1990, Copeland, 2004






53-88

5. Gestión de tests (K3) | 180 minutos

Objetivos de aprendizaje para gestión de testsLos objetivos identifican lo que será capaz de hacer al finalizar cada módulo.

5.1 Organización del test (K2)• Reconocer la importancia de la prueba independiente. (K1)• Listar las ventajas y desventajas de la prueba independiente dentro de una

organización. (K2)• Reconocer los distintos miembros de equipo a ser considerados para la creación de

un equipo de Test. (K1)• Recordar las tareas de un típico líder de test y un tester. (K1)

5.2 Planificación del test y estimación (K2)• Reconocer los distintos niveles y objetivos de la planificación de un test. (K1)

• Resumir el propósito y el contenido de un plan de test, de una especificación dediseño de un test y de un documento del procedimiento de un test acorde con el“Standard for Software Test Documentation” (IEEE 829). (K2)

• Recordar los típicos factores que influyen en el esfuerzo relacionado con las pruebas. (K1)

• Diferenciar entre dos enfoques de estimación conceptualmente diferentes: el“metrics-based ” y el “expert-based ”. (K2)

• Diferenciar el foco de la planificación del test para un proyecto, para niveles de testindividuales (ej. test de sistema), o para objetivos específicos del test (ej. test deutilidad), y ejecución del test. (K2)

• Listar preparación para el test y las tareas a ser ejecutadas que necesiten

planificación. (K1)• Recordar/Justificar criterios adecuados para la finalización de niveles específicos de

prueba y grupos de casos de prueba (ej. prueba de integración, prueba deaceptación, o casos de prueba para las pruebas de utilidad). (K2)

5.3 Monitorización del progreso del test y control (K2)• Recordar las métricas comunes para la monitorización de la preparación y ejecución

del test. (K1)• Entender e interpretar las métricas de un test para la generación de un informe del

test y control del test (ej. Defectos encontrados y corregidos, y tests aprobados osuspendidos). (K2)

• Resumir el propósito y el contenido del documento informe de las pruebas acordecon el “Standard for Software Test Documentation” (IEEE 829). (K2)

5.4 Gestión de la configuración (K2)• Resumir como la gestión de la configuración apoya la prueba. (K2)






54-88

5.5 Riesgo y prueba (K2)• Describir un riesgo como un posible problema que amenace el logro de uno o más

objetivos del proyecto de un stakeholder . (K2)• Recordar que los riegos son determinados por la probabilidad (de que vayan a

ocurrir) y de su impacto (resultado si es que llegan a ocurrir). (K1)• Distinguir entre Riesgos de Proyecto y Producto. (K2)• Reconocer los riesgos típicos de proyectos y productos. (K1)• Describir, usando ejemplos, como el análisis del riesgo y la gestión del riesgo

puedan ser utilizados para la planificación del Test. (K2)

5.6 Gestión de Incidencias (K3)• Reconocer el contenido del informe de Incidencias del “Standard for Software Test

Documentation” (IEEE 829). (K1)• Escribir un informe de Incidencias que cubra la observación de un fallo durante las

pruebas. (K3)






55-88

5.1 Organización del test (K2) | 30 minutos

TérminosTester (probador), líder de las pruebas, mánager de las pruebas

5.1.1 Organización del test e independencia (K2)

La eficiencia de hallar defectos mediante pruebas y revisiones puede ser mejorada alusar probadores independientes. Las opciones para la independencia son:

• Probadores independientes dentro del equipo de desarrollo.• Equipo de test independiente o grupo dentro de la organización, el cual informe al

gestor de proyecto o al gestor ejecutivo.• probadores independientes de la organización comercial (empresa), coumidad de

usuarios e IT.• Especialistas independientes de tests para objetivos específicos como probadores de

usabilidad, probadores de seguridad o probadores de certificación (los cualescertifican un producto software según estándares y normativa).

• Probadores independientes subcontratados (outsourced ) o de una organizaciónexterna.

Para proyectos mayores, complejos o de seguridad crítica ( safety critical ), usualmentees mejor tener múltiples niveles de prueba, dónde alguno o todos los niveles estén hecho por probadores independientes. El staff de desarrollo puede participar en las pruebas,especialmente en los niveles inferiores, pero su falta de objetividad a menudo limita sueficiencia. Los probadores independientes pueden tener la autoridad para requerir y definir procesos de test y reglas, pero los probadores deberían de tomar tal papel relacionado con el proceso solo en la presencia de un management mandate.

Las ventajas de la independencia incluyen:

• Los probadores independientes ven otros y diferentes defectos, y son imparciales.• Un probador independiente puede verificar las suposiciones que se hicieron a la

hora de especificar e implementar el sistema.

Las desventajas:

•

Aislamiento del equipo de desarrollo (si se trata de forma totalmenteindependiente).• Los probadores independientes pueden ser “cuellos de botella” como el último

punto de comprobación.• Los desarrolladores pierden un sentido de responsabilidad por la calidad.






56-88

Las tareas de prueba podrían ser realizadas por individuos en un papel específico de prueba, o podrían ser realizados por alguien con otro papel, como el jefe de proyecto, jefede calidad, desarrollador, business and domain expert , infraestructura o IT operations.

5.1.2 Tareas del líder del test y el probador (K1)

Esta programación cubre dos de las posiciones de test, la del líder y el probador. Lasactividades y tareas realizadas por los individuos en estos dos cargos dependen del proyectoy el contexto del producto, de las personas en los papeles, y de la organización.

A veces el líder es llamado el test manager o mánager de las pruebas. El papel dellíder puede ser realizado por un jefe de proyecto, un jefe de desarrollo, un gestor asegurador de la calidad o el gestor del equipo de test. En proyectos grandes pueden existir dos posiciones: líder de las pruebas y gestor de las pruebas. Típicamente el líder de las pruebas planea, monitoriza y controla las actividades de prueba y las tareas definidas en lasección 1.4.

Las tareas típicas de un líder de pruebas pueden incluir:

• Coordinar la estrategia y plan de test junto con los gerentes del proyecto y demás.• Escribir o repasar la estrategia de test del proyecto, y la política de test para la

organización.• Planear los tests – en vista del contexto y entendiendo el riesgo – incluyendo la

selección de técnicas de test. Estimar el tiempo, esfuerzo y coste de las pruebas,adquiriendo recursos, definiendo niveles de test, ciclos, técnicas, y objetivos, y planificar la gestión de incidencias.

• Iniciar la especificación, preparación, implementación y ejecución de los tests, y

monitorizar y controlar la ejecución.• Adaptar el planeamiento basado en los resultados y progreso de los test (a veces

documentado en informes de estado) y tomar cualquier acción necesaria paracompensar los problemas.

• Preparar adecuadamente la gestión de configuración del testware para trazabilidad.• Introducir métricas convenientes para medir el progreso del test y evaluando la

calidad de la prueba y el producto.• Decidir que debería de ser automatizado, hasta que punto, y como.• Seleccionar las herramientas para asistir las pruebas y organizar cualquier

formación para los probadores en uso de las herramientas.• Decidir acerca de la implementación del entorno de test.• Planificar horaria de los tests.• Escribir un informe con el sumario de los tests basados en la información recogida

durante las pruebas.

Las típicas tareas de un probador serían:

• Repasar y contribuir a los planes de test.






57-88

• Analizar, repasar y determinar los requerimientos de usuario, especificaciones ymodelos para la testability (¿testabilidad?).

• Crear especificaciones de prueba.• Configurar el entorno de prueba (a menudo coordinando con la gerencia del sistema

de administración y red)• Preparar y adquirir datos de prueba.• Implementar los tests en todos los niveles de test, ejecutar y registrar los tests,

evaluar los resultados y documentar las desviaciones de los resultados esperados.• Usar herramientas para la administración del test o gerencia del test y monitorizar

las herramientas como sean requeridas.• Automatizar las pruebas (podría ser asistida por un desarrollador o un experto en

automatización de pruebas).• Medir el funcionamiento de los componentes y sistemas (si es aplicable)• Repasar los tests desarrollados por otros.

Las personas que trabajan en el análisis de pruebas, diseño de pruebas, tiposespecíficos de pruebas o automatización de pruebas pueden ser especialistas en su papel detrabajo. Dependiendo del nivel de test y los riesgos asociados al producto y al proyecto,diferentes personas pueden tomar el papel de probador, manteniendo hasta un cierto nivelun grado de independencia. Típicamente, probadores en el nivel de componente eintegración serían desarrolladores, probador en el nivel de aceptación serían expertos delnegocio y usuarios, y probadores para las pruebas de aceptación operacional seríanoperadores.






58-88

5.2 Planificación del test y estimación (K2) | 50 minutos

TérminosCriterio de entrada, Criterio de salida, prueba exploratoria, técnica de test, nivel de

test, plan de prueba, proceso de prueba, estrategia de prueba.

5.2.1 Planificación del test (K2)

Esta sección cubre el propósito de la planificación de las pruebas entre proyectos dedesarrollo e implementación, y para actividades de mantenimiento. La planificación puedeser documentada en un proyecto o plan maestro del test, y en planes separados de test paralos niveles de test, como las pruebas del sistema y pruebas de aceptación. Las líneasgenerales de los documentos de la planificación del test son cubiertas por el “Standard for Software Test Documentation” (IEEE 829).

La planificación está influenciada por la política de pruebas de la organización, el

alcance de las pruebas, objetivos, riesgos, restricciones, criticidad, testability y ladisponibilidad de los recursos. Cuanto más progrese el proyecto y la planificación de las pruebas más información estará disponible y se podrá incluir más detalle en el plan.

La planificación de las pruebas es una actividad continua y es realizada en todo los procesos del ciclo de vida y actividades. El feedback de las actividades de test es usado parareconocer los riesgos que vayan cambiando para así ajustar la planificación.

5.2.2 Actividades de planificación de las pruebas (K2)

Las actividades de la planificación del test pueden incluir:

• Definición de la técnica general de las pruebas (la estrategia de las pruebas),incluyendo la definición de los niveles de test y el criterio de entrada y salida.

• Integración y coordinación de las actividades de prueba en las actividades del ciclode vida del software: adquisición, provisión, desarrollo, operación y mantenimiento.

• Toma de decisiones acerca de que va a ser probado, que papeles realizaran lasactividades de prueba, cuando y como se realizaran las actividades de prueba, comoserán evaluados los resultados de la prueba, y cuando se pararía la prueba (criteriode salida).

• Asignación de recursos para las distintas tareas definidas.• Definición de la cantidad, nivel de detalle, estructura y plantillas para la

documentación de las pruebas.• Selección de las métricas para la monitorizar y controlar la preparación y ejecución

de las pruebas, resolución de defectos y cuestiones de riesgo.• Ajuste del nivel de detalle para los procedimientos de las pruebas para así poder

proveer de suficiente información para asistir en la reproducción de la preparación yejecución del test.






59-88

5.2.3 Criterio de Salida (K2)

El propósito del criterio de salida es definir cuando la prueba debería parar, como alfinal del nivel de un test o cuando un conjunto de tests tiene una meta específica.

Típicamente el criterio de salida puede consistir en:

• Medidas detallistas, como la cobertura del código, funcionalidad o riesgo.• Estimaciones de la densidad del defecto o medidas de confiabilidad.• Coste.• Riesgos residuales, como defectos que no han sido corregidos o ciertas áreas dónde

que no cubre el test.• Programaciones horarias como aquellas basadas en tiempo al mercado.

5.2.4 Estimación del test (K2)

En esta programación se cubren dos técnicas para la estimación del esfuerzo del test:

• Estimación del esfuerzo de las pruebas basadas en métricas de proyectos antiguos osimilares o basadas en valores típicos.

• Estimación de las tareas por el autor de estas tareas o por expertos.

Una vez que se estima el esfuerzo del test, los recursos pueden ser identificados y se puede organizar una programación.

El esfuerzo de las pruebas puede depender de un número de factores, incluyendo:

• Características del producto: la calidad de la especificación y otra informaciónusada para los modelos de test (en otras palabras, la base del test), el tamaño del producto, la complejidad del dominio del problema, los requisitos para laconfiabilidad y seguridad, y los requisitos para la documentación.

• Características del proceso de desarrollo: La estabilidad de la organización,herramientas usadas, procesos de test, habilidades de las personas involucradas, y presión del tiempo.

• El resultado de las pruebas: el número de defectos y la cantidad de trabajo que serequiere rehacer.

5.2.5 Técnicas de test (estrategias de test) (K2)

Una manera de clasificar las técnicas de test o las estrategias es dependiendo del punto temporal donde el trabajo de diseño de pruebas se lleva a cabo:

• Técnicas preventivas, donde los tests están diseñados lo antes posible






60-88

• Técnicas reactivas, donde el diseño de las pruebas viene después de que se haya producido el software o sistema.

Las típicas técnicas o estrategias incluyen:

• Técnicas analíticas, como pruebas basadas en riesgo donde las pruebas son dirigidasa áreas de mayor riesgo.• Técnicas basadas en modelos, como pruebas estocásticas ( stochastic testing ) usando

información sobre porcentaje de fallos (como modelos de incremento deconfiabilidad) o uso (como perfiles operacionales).

• Técnicas metódicas, como basadas en fallos (incluyendo adivinación de errores yataques de fallos), basados en lista de comprobación, y basados en características decalidad.

• Técnicas de proceso o standard-compliant , como aquellos especificados por losestándares especificados por la industria o las varias ágiles metodologías.

• Técnicas dinámicas o heurísticas, como pruebas exploratorias donde las pruebas son

más reactivas a eventos pre-planeados, y donde la ejecución y evaluación son tareasconcurrentes.

• Técnicas consultivas, como aquellas donde la cobertura del test es conducida primariamente por el consejo y guía de la tecnología y/o expertos del dominio delnegocio fuera del equipo de test.

• Técnicas de regresión inversa, como aquellas que incluyen el re-uso de materialesde test existentes, automatización extensiva de las pruebas de regresión funcional, yconjuntos estándares de test.

Se podrían combinar distintas técnicas, por ejemplo, una técnica basada en riesgo dinámica.

La selección de la técnica de test debería considerar el contexto, incluyendo:

• Riesgo de fracaso del proyecto, peligros hacia el producto y riesgos del fracaso del proyecto para los humanos, el entorno y la compañía.

• Habilidades y experiencias de las personas en las técnicas propuestas, herramientasy métodos.

• El objetivo del esfuerzo de las pruebas y la misión del equipo de pruebas.• Aspectos regulables, como regulaciones externas e internas para el proceso de

desarrollo.• La naturaleza del producto y del negocio.






61-88

5.3 Monitorización y control del progreso del test (K2) | 20 minutos

TérminosDensidad de defecto, porcentaje de fracaso, control de test, cobertura del test,

monitorización del test, informe del test.

5.3.1 Monitorización del progreso del Test (K1)

El propósito de la monitorización del test es el de dar feedback y visibilidad acerca delas actividades de test. La información a ser monitorizada puede ser recogida manualmenteo automáticamente y puede ser usada para medir tanto el criterio de salida como lacobertura. Las métricas también pueden ser usadas para asesorar el progreso contra la programación planificada y el presupuesto. Las métricas comunes de test incluyen:

• Porcentaje del trabajo realizado en la preparación del caso de prueba (o porcentajede casos planificados de test preparados).

• Porcentaje del trabajo realizado en la preparación del entorno de prueba.• Ejecución del caso de prueba. (Ej. Número de casos de prueba ejecutados/no

ejecutados, y casos de prueba aprobados/suspendidos).• Información de defecto (Ej. Densidad del defecto, defectos encontrados y

corregidos, porcentaje de fracaso, y resultados de re-test).• Cobertura de las pruebas de requisitos, riesgos o código.• Confianza subjetiva de los probadores en el producto.• Fechas de los hitos del test.• Costes de las pruebas, incluyendo una comparación del coste con el beneficio de

encontrar el próximo defecto o ejecutar el próximo test.

5.3.2 Informe de test (test reporting) (K2)

El informe de test se conforma con el resumen de la información acerca del esfuerzode las pruebas, incluyendo:

• El qué pasó durante un período de prueba, como las fechas cuando el criterio desalida fue alcanzado.

• La información analizada y métrica para apoyar las recomendaciones y decisionessobre futuras acciones, como un asesoramiento de los defectos restantes, el beneficio económico de las pruebas continuo, riesgos pendientes, y el nivel de

confianza en software probado.

Las líneas generales de un informe de resumen del test es entregado en el “ Standard

for Software Test Documentation” (IEEE 829).

Las métricas deberían de ser recogidas durante y al final de un nivel de test para poder asegurar:






62-88

• Si los objetivos de test para ese nivel son los adecuados• Si las técnicas de test seleccionadas son las adecuadas• La efectividad de las pruebas con respecto a sus objetivos

5.3.3 Control del Test (K2)

El control de test describe cualquier guía o acciones correctivas tomadas comoresultado de la información y métricas recogidas e informadas. Las acciones pueden cubrir cualquier actividad del test y pueden afectar cualquier otra actividad o tarea de un ciclo devida de otro software.

Ejemplos de acciones del control de test son:

• Volver a priorizar las pruebas cuando un riesgo identificado ocurra (Ej. SoftwareEntregado tarde).

• Cambiar la programación de las pruebas por la disponibilidad de un entorno de

pruebas.• Configurar un criterio de entrada que requiera correcciones que tendrían que ser re-

testeadas por un desarrollador antes de aceptarlas en el build .






63-88

5.4 Gestión de Configuración (K2) | 10 minutos

TérminosGestión de Configuración, Control de versiones.

Conocimientos previosEl propósito de la gerencia de configuración es para establecer y mantener la

integridad de los productos (componentes, datos y documentación) del software o sistema através del proyecto y el ciclo de vida del producto.

Para las pruebas, la gestión de configuración puede involucrar el asegurar que:

• Todos los artículos del testware son identificados, sus versiones son controladas, loscambios son seguidos, relacionados entre si y relacionados con artículos dedesarrollo (objetos de test) para que la trazabilidad pueda ser mantenida a través del proceso de test.

• Todos los documentos identificados y artículos de software son referenciadosinequívocamente en la documentación del test.

Para el probador, la gerencia de configuración le ayuda a identificar de maneraindividual (y reproducir) el articulo probado, los documentos de test, los tests y el test harness.

Durante la planificación del test, los procedimientos de la gerencia de configuración yla infraestructura (herramientas) deberían de ser elegidos, documentados e implementados.






64-88

5.5 Riesgo y pruebas (K2) | 30 minutos

TérminosRiesgo del producto, riesgo del proyecto, riesgo, pruebas basadas en riesgo.

Conocimientos previosEl riesgo puede ser definido como la ocurrencia de un evento, peligro, amenaza o

situación y sus indeseables consecuencias, un problema potencial. El nivel de riesgo serádeterminado por la probabilidad de ocurrencia de un evento adverso y el impacto (el dañoocasionado por dicho evento).

5.5.1 Riesgos de Proyecto (K1, K2)

Los riesgos de proyectos son los riesgos que rodean a la capacidad de entrega de losobjetivos del proyecto, como:

• Problemas del Proveedor:o Fracaso de terceroso Problemas contractuales

• Factores de Organizacióno Escasez de habilidades y plantilla.o Problemas personales y de formación.o Problemas políticos, como

Problemas con testers comunicando sus necesidades y resultados deltest;

Detectar mediante pruebas y revisiones la ocurrencia a continuaciónde un fracaso (Ej. No mejorar el desarrollo y las prácticas de pruebas).

o Actitud incorrecta o expectativa hacia las pruebas (Ej. Sin apreciar el valor de detectar fallos durante las pruebas).

• Problemas técnicos:o Problemas en identificar los requisitos correctos;o El grado al que se tiene que llegar para alcanzar los requisitos dadas las

limitaciones.o La calidad del diseño, código y tests.

Cuando analiza, maneja y mitiga estos riesgos, el gerente del test está siguiendo principios bien establecidos de gerencia de proyectos. El “Standard for Software Test Documentation” (IEEE 829) indica que los planes de prueba requieren tener establecidoriesgos y contingencias.

5.5.2 Riesgos de producto (K2)

Las áreas fracasadas potencialmente (futuros eventos adversos o peligros) en elsoftware o sistema son conocidas como riesgos de producto, ya que estos son riesgos decalidad del producto, como:






65-88

• Entrega de software propenso a errores.• El potencial que el software/hardware puede causar daño a un individuo o

compañía.• Software de características pobres (Ej. Funcionalidad, seguridad, confiabilidad,

usabilidad y funcionalidad).• Software que no realiza las funciones que debería.

Los riesgos son usados para decidir donde se puede empezar las pruebas y donde se puede testear más; las pruebas son usadas para reducir el riesgo de la ocurrencia de unefecto adverso, o para reducir el impacto de un efecto adverso.

Los riesgos de producto son un tipo especial de riesgo para el éxito de un proyecto.Las pruebas como actividad para controlar el riesgo proporciona feedback acerca de riesgoresidual midiendo la efectividad del retiro de un defecto crítico y su plan de contingencia.

Una técnica de pruebas basadas en el riesgo proporciona oportunidades pro-activas para reducir los niveles de riesgo en el producto, empezando en las fases iniciales del proyecto. Involucra la identificación de los riesgos del producto y el uso de estos en guiar la planificación de las pruebas, especificación, preparación y ejecución de tests. En unatécnica basada en el riesgo los riesgos identificados pueden ser usados para:

• Determinar las técnicas de prueba a ser empleadas.• Determinar el grado de prueba a ser llevado a cabo.• Priorizar las pruebas en un intento de búsqueda de defectos críticos lo antes posible.• Determinar si cualquier actividad que no sea de prueba podría ser empleada para

reducir el riesgo (Ej. Proveer una formación a diseñadores sin experiencia).

Las pruebas basadas en riesgo se enfocan al conocimiento colectivo y penetración delos stakeholders para determinar el riesgo y el nivel de prueba requerido para tratar esosriesgos.

Para asegurar la reducción al mínimo de la posibilidad de fracaso de un producto, lasactividades de gestión de riesgo proporcionan una técnica disciplinada para:

• Asesorar (y re-asesorar frecuentemente) que puede pasar mal (riesgos).• Determinar que riesgos son importantes para ser tratados.• Implementar acciones para tratar estos riesgos.

Además, las pruebas podrían asistir en la identificación de nuevos riesgos, podríaayudar a determinar que riesgos deberían de ser reducidos, y podría reducir incertidumbreacerca de riesgos.






66-88

5.6 Gestión de Incidentes (K3) | 40 minutos

TérminosRegistro de incidencias.

Conocimientos previosComo uno de los objetivos de las pruebas es encontrar defectos, las discrepancias

entre el resultado actual y el esperado necesitarían ser registradas como incidentes. Losincidentes deberían ser seguidos desde su descubrimiento y clasificación hasta sucorrección y confirmación de la solución. Para poder gestionar todos los incidentes hasta sudesenlace, una organización debe establecer un proceso y reglas para la clasificación.

Los incidentes pueden se generados durante el desarrollo, repaso, prueba o el uso deun producto software. Pueden ser generados por cuestiones de código o funcionamiento delsistema, o en cualquier tipo de documentación incluyendo documentos de desarrollo,documentos de las pruebas o información del usuario como “Ayuda” o guías de Instalación.

Los informes de incidencias tienen los siguientes objetivos:

• Abastecer a los desarrolladores y otras partes con feedback acerca del problema para poder ser identificado, aislado y corregido como se necesite.

• Proporcionar a los líderes de las pruebas una razón para el seguimiento de la calidaddel sistema bajo test y el progreso de las pruebas.

• Proporcionar ideas para el entorno del proceso de test.

Típicamente un probador o un repasador registra la siguiente información, si es que sesabe, sobre un incidente:

• Fecha de expedición, organización expedidora, autor, consentimientos y estado.• Alcance, severidad y prioridad del incidente.• Referencias, incluyendo la identidad de la especificación del caso de test que reveló

el problema.

Los detalles de un informe de incidencias pueden incluir:

• Resultados esperados y actuales.• Fecha en el que el incidente fue descubierto.• Identificación o configuración del artículo del software o sistema.• Ciclo de Vida del Software o sistema en donde el incidente fue observado.• Descripción de la anomalía para habilitar la resolución.• Grado de Impacto sobre los intereses de los stakeholders.• Severidad del impacto en el sistema.• Urgencia/Prioridad para ser corregido.• Estado de la incidencia (Ej. Abierta, diferida, duplicada, esperar a se corregida,

esperando confirmación de corrección del test o cerrada).






67-88

• Cambiar historial, como la secuencia de acciones llevadas a cabo por los miembrosdel equipo de proyectos con respecto a la incidencia para aislar, reparar y confirmar si está corregido.

La estructura de un informe de incidencias está cubierta en el “Standard for Software

Test Documentation” (IEEE 829) y se denomina informe de anomalías.

Referencias

5.1.1 Black, 2001, Hetzel, 19985.1.2 Black, 2001, Hetzel, 19985.2.5 Black, 2001, Craig, 2002, IEEE 829, Kaner 20025.3.3 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829






68-88

6. Herramientas de soporte para pruebas (K2) | 80 minutos

Objetivos de aprendizaje para el soporte de pruebasLos objetivos identifican lo que será capaz de hacer al finalizar cada módulo.

6.1 Tipos de herramientas de test (K2)

• Clasificación de diferentes tipos de herramientas de acuerdo con las actividades del proceso de pruebas. (K2)

• Reconocimiento de las herramientas que pueden ayudar al desarrollo de sus pruebas(K1)

6.2 Uso efectivo de herramientas: beneficios potenciales y riesgos (K2)

• Resumir los beneficios potenciales y riesgos de la automatización y soporte de

herramientas para testing (K2).• Reconocer que las herramientas de ejecución de test pueden tener diferentes

técnicas de scripting , incluyendo los guiados por datos y por palabra clave. (K1)

6.3 Introducir una herramienta en una organización (K1)

• Exponer los principios fundamentales de la introducción de una herramienta en unaorganización

• Exponer las metas de prueba-de-conceptos/fase experimental para la evaluación deherramientas.

• Reconocer que factores, en vez de simplemente adquirir una herramienta, son

requeridos para un buen soporte de la herramienta (K1)






69-88

6.1 Tipos de herramientas de test (k2) | 45 minutos

TérminosHerramienta de gestión de la configuración, herramienta de cobertura de medida,

herramienta de depuración, herramienta de gestión de incidentes, herramienta de

depuración, herramienta de pruebas de carga, herramienta de modelado, herramienta demonitorización, herramienta de prueba de rendimiento, efecto sonda, herramienta degestión de requisitos, herramienta de soporte de revisión de procesos, herramienta deseguridad, herramienta de análisis estático, herramienta de prueba de tensión ( stress), stub, prueba de comparación, herramienta de preparación de prueba de datos, herramienta dediseño de pruebas, aprovechamiento de las pruebas, herramienta de ejecución de test,herramienta de gestión de pruebas, herramienta marco de unidad de pruebas.

6.1.1 Clasificación de herramientas de test (K2)

Hay un número de herramientas que soportan diferentes aspectos de las pruebas. Las

herramientas son clasificadas en este programa de estudios de acuerdo con las actividadesde prueba que ellas soportan.

Algunas herramientas evidentemente soportan una actividad, otras pueden soportar más de una actividad, pero son clasificadas según la actividad con la cual ellas son másestrechamente asociadas. Algunas herramientas comerciales a menudo dan soporte parasolo un tipo de actividad: otros vendedores de herramientas comerciales ofrecen unconjunto o familias de herramientas que proporcionan soporte para muchas o todas esasactividades.

Las herramientas de prueba pueden mejorar la eficiencia de las actividades de prueba

mediante la automatización de tareas repetitivas. Las herramientas de prueba puedentambién mejorar la fiabilidad de las pruebas mediante, por ejemplo, la automatización de lacomparación de numerosos datos o la simulación de comportamientos.

Algunos tipos de herramientas de pruebas pueden ser intrusivas, en la que laherramienta puede afectar al resultado real del test. Por ejemplo, el tiempo real puede ser diferente dependiendo de cómo se mida con las diferentes herramientas de rendimiento, ose puede obtener una medida diferente de cobertura de código dependiendo de queherramienta de cobertura estemos usando. Las consecuencias de las herramientas intrusivasson llamadas efecto sonda.

Algunas herramientas ofrecen soporte mas apropiado para desarrolladores (Ej.durante la prueba de integración de componentes). Tales herramientas son marcadas con“(D)” en las clasificaciones de más abajo.






70-88

6.1.2 Herramientas de soporte para la gestión de pruebas y tests (K1)

Las herramientas de gestión se aplican a todos las actividades de prueba a través delciclo de vida del software entero.

Herramientas de gestión de pruebas

Las características de las herramientas de gestión de pruebas incluyen:

• Soporte para la gestión de pruebas y el cumplimiento de las actividades de prueba.• Interfaces para las herramientas de ejecución de test, herramientas de traza de

defectos y herramientas de gestión de requerimientos.• Control de versión independiente o una interfaz con una herramienta de gestión de

configuración externa.• Soporte para la trazabilidad de las pruebas, resultado e incidentes de los test para

documentos fuentes, tales como especificación de requisitos.• ( Logging ) Registro de resultados de tests y generación de informes de progreso.• Análisis cuantitativo (métrica) relacionado con las pruebas (ej. test ejecutados test

pasados) y el objeto de los test (ej. incidentes ocurridos), para dar informaciónsobre el objeto del test, y controlar y mejorar el proceso de prueba.

Herramienta de gestión de requerimientos

Las herramientas de gestión de requerimientos almacenan la declaración derequerimientos, comprueban la consistencia y los requerimientos no definidos (perdidos), permiten priorizar los requisitos, y permite en test individuales rastrear los requerimientos,las funciones y/o las características. La trazabilidad puede ser presentada en informes degestión en progreso de las pruebas (constantemente, según las circunstancias). La coberturade requerimientos, funciones y/o características para un conjunto de pruebas pueden ser también informados (preparadas en un informe).

Herramienta de gestión de incidentes

Las herramientas de gestión de incidentes almacenan y administran los informes deincidentes, por ejemplo los defectos, los errores o los problemas percibidos y las anomalías,y apoyan la gestión de los informes de incidentes de la siguiente forma:

• Facilitando su priorización• Asignación de acciones a las personas (fijar o confirmar tests)• Atribución de estados (por ej.: rechazados, preparados para ser comprobados, plazo

para una próxima publicación.)

Estas herramientas permiten que el proceso de incidentes sea monitorizado a lo largodel tiempo, a menudo proporcionando apoyo para análisis estadístico y proporcionandoinformes sobre los incidentes. También son conocidos como herramientas de seguimientode defectos (defect tracking tools).






71-88

Herramientas de gestión de configuración

Las herramientas de gestión de configuración no son estrictamente herramientas de prueba, pero son típicamente necesarias para seguir el rastro de las diferentes versiones ydesarrollos de software y pruebas.

Herramientas de gestión de configuración:

• Almacena información sobre versiones y desarrollos de software y testware.• Permite la trazabilidad entre los productos de testware y productos de trabajo

software y variantes de productos.• Son particularmente útiles cuando se desarrolla para más de una configuración de

entornos hardware/software (ej.: para diferentes versiones de sistemas operativos,diferentes librerías o compiladores, diferentes buscadores o computadoras.)

6.1.3 Herramientas de soporte para test estáticos (K1)

Herramientas de soporte de revisión de procesos

Las herramientas de soporte de revisión de procesos deben almacenar informaciónsobre los procesos de revisión, almacenar y comunicar los comentarios de las revisiones,informar sobre los defectos y resultados, gestionar referencias para revisar reglas y/o listasde comprobación y llevar la cuenta de la trazabilidad entre documentos y sus códigosfuente. Ellos también pueden proporcionar ayuda para revisiones en línea, el cual es útil siel equipo está geográficamente disperso.

Herramientas de análisis estático (D)

Las herramientas de análisis estático ayudan a los desarrolladores, probadores y personal encargado de la garantía de calidad, a encontrar defectos antes de lacomprobación dinámica. Los importantes propósitos incluyen:

• La aplicación de códigos estándares.• El análisis de estructuras y dependencias (ej.: los enlaces de páginas Web).• Ayuda en la comprensión de los códigos.

Las herramientas de análisis estático pueden calcular medidas desde el código (ej.:complejidad) el cual puede dar valiosa información, por ejemplo, para planificación oanálisis de riesgos.

Herramienta de modelado (D)

Las herramientas de modelos son capaces de validar modelos de software. Por ejemplo, un chequeador de modelo de base de datos puede encontrar defectos einconsistencias en el modelo de datos; otras herramientas de modelado pueden encontrar defectos en un modelo de estado o en un modelo de un objeto. Esta herramienta a menudo






72-88

puede ayudar a generar casos de algunos casos de prueba basados en el modelo (ver másabajo las herramientas del diseño de pruebas).

El beneficio más importante de las herramientas de análisis estático y herramientas demodelado es el coste efectivo de encontrar más defectos en un tiempo menor en el proceso

de desarrollo. Además, el proceso de desarrollo puede acelerarse y mejorarse por tener menos procesado.

6.1.4 Herramientas de soporte para especificación de pruebas(K1)

Herramientas de diseño de pruebas

Las herramientas de diseño de pruebas generan entradas de tests o verdaderos tests derequisitos, de interfaz gráfico de usuario, de modelos de diseños (estado, datos u objeto) ode código. Este tipo de herramientas pueden generar resultados esperados también (ej.: puede usar un test oracle). El test generado de un modelo de estado o de un objeto es útil

para verificar la implementación del modelo del software o sistema. Estas herramientas pueden ahorrar un tiempo valioso y proporcionar un incremento de la minuciosidad de las pruebas como consecuencia de la complejidad del test que la herramienta puede generar.

Otras herramientas en esta categoría pueden ayudar en el soporte de generación detests proporcionando plantillas estructuradas, algunas veces llamadas marco de prueba, quegenera tests o test stubs, y esto aumenta la velocidad del proceso de diseño de pruebas.

Herramientas de preparación de las pruebas de datos (D)

Las herramientas de preparación de las pruebas de datos manipulan la base de datos,

ficheros o transmisión de datos para configurar una prueba de datos para ser usado durantela ejecución de los test. Un beneficio de estas herramientas es asegurar que la transferenciade datos a un entorno de test sea hecho anónimamente, para la protección de datos.

6.1.5 Herramientas de soporte para la ejecución de test y registro (K1)

Herramientas de ejecución de test

Las herramientas de ejecución de tests permiten que los tests sean ejecutadosautomáticamente, o semiautomáticamente, usando entradas almacenadas y resultadosesperados, a través del uso de un lenguaje de scripting . El lenguaje de scripting hace

posible manipular las pruebas con esfuerzo limitado, por ejemplo, para repetir el test condiferentes datos o comprobar una parte diferente del sistema con pasos similares.Generalmente estas herramientas incluyen características de comparación dinámica y proporciona un resultado para que cada prueba se ejecute.

Las herramientas de ejecución de tests se pueden usar también para grabar tests,cuando ellas pueden ser referidas también como una herramienta de captura yreproducción. Las entradas de tests capturados durante la comprobación exploratoria o






73-88

unscripted testing pueden ser usadas para reproducir y/o documentar un test, por ejemplo,si ocurre un fallo.

Harness de la prueba/ herramientas marco para pruebas unitarias (D)

Un harness de la prueba puede facilitar la comprobación de componentes o parte deun sistema mediante la simulación del entorno en el cual ese objeto de test será ejecutado.Éste se puede hacer o porque otros componentes de ese entorno no están todavíadisponibles y son sustituidos por stubs y/o drivers, o simplemente para proporcionar unentorno predecible y controlable en el cual cualquier fallo puede ser localizado en el objeto bajo test.

Un harness puede ser creado donde parte del código, objeto, método o función,unidad o componente puede ser ejecutado, llamando al objeto para ser comprobado y/o dar feedback a ese objeto. Se puede hacer esto proporcionando un medio artificial de proveer entradas al objeto del test, y/o proveer stubs para proporcionar salidas del objeto, en vez de

los objetivos reales de salida.

Las herramientas de harness de test pueden ser usadas también para proporcionar unaestructura de ejecución en el middleware, donde los lenguajes, sistemas operativos ohardware deben ser comprobados juntos.

Ellos pueden ser llamados herramientas marco para tests unitarios cuando tienen unfoco especial en el nivel de prueba de componente. Este tipo de herramientas ayuda en laejecución de las pruebas de componentes en paralelo con el desarrollo del código.

Tests comparadores

Los tests comparadores determinan diferencias entre ficheros, bases de datos,resultados de tests. Las herramientas de ejecución de pruebas típicamente incluyencomparadores dinámicos, pero una comparación posterior a la ejecución puede hacerse por una herramienta de comparación separada. Un test comparador puede utilizar un testoráculo, especialmente si es automático.

Herramientas de medición de cobertura (D)

Las herramientas de medición de cobertura pueden ser intrusiva o no intrusivadependiendo de las técnicas de medida usadas, qué es lo que se mide y el lenguaje delcódigo. Las herramientas de cobertura de código mide el porcentaje de los tiposespecíficos de estructura de códigos que se han realizado (ej.: declaraciones, bifurcacioneso decisiones, y módulos o llamadas de función). Estas herramientas muestran perfectamente cómo el tipo de estructura medido ha sido realizado por un conjunto de pruebas.

Herramientas de seguridad






74-88

Las herramientas de seguridad comprueban los virus informáticos y deniegan ataquesa servicios. Un cortafuego, por ejemplo, no es estrictamente una herramienta de pruebas, pero puede ser usada en comprobación de seguridad. Otras herramientas de seguridadtensionan el sistema buscando específicas vulnerabilidades del sistema.

6.1.6 Apoyo de herramientas para ejecución y control (K1)

Herramientas de análisis dinámicas

Las herramientas de análisis dinámicas encuentran defectos que son evidentes solamentecuando el software se está ejecutando, tales como dependencias de tiempo o pérdida dememoria. Son típicamente usadas en pruebas de componentes y pruebas de integración decomponentes y cuando se prueba el middleware.

Herramientas de funcionamiento/ de prueba de carga/ de prueba de tensión

Las herramientas de comprobación de funcionamiento controlan e informan de cómose comporta un sistema bajo una variedad de condiciones de uso simuladas. Ellos simulanuna carga en una aplicación, una base de datos, o un entorno de sistema, tales como una redo un servidor. Las herramientas son a menudo llamadas bajo el punto de vista delfuncionamiento que evalúa, tales como la carga o stress (tensión), por lo tanto sonconocidas como herramientas de prueba de carga o herramientas de prueba de tensión. Se basan a menudo en ejecuciones repetitivas automatizadas, controladas por parámetros.

Herramientas de monitorización

Las herramientas de monitorización no son estrictamente herramientas de prueba sino

proporcionan información que puede ser usada para propósitos de prueba y que no estándisponibles de otra manera.

Las herramientas de monitorización analizan continuamente, verifican e informan deluso de los recursos específicos del sistema, y dan avisos de posibles problemas del servicio.Ellos almacenan información sobre la versión y construcción del software y testware y permite el seguimiento (trazabilidad).

6.1.7 Herramientas de soporte para áreas específicas de aplicación (K1)

Ejemplos individuales de los tipos de herramientas clasificadas arriba pueden estar

especializados para el uso en un tipo particular de aplicación. Por ejemplo, hayherramientas de comprobación de funcionalidad específicamente para aplicaciones deWEB-BASED, las herramientas de análisis estático para plataformas de desarrolloespecífico, y herramientas de análisis dinámico para aspectos de seguridad de las pruebas.

Los juegos de herramientas comerciales pueden tener áreas de aplicacionesespecíficas (TARGET) (ej.: sistemas embebidos.)






75-88

6.1.8 Herramientas de soporte usando otras herramientas (K1)

Las herramientas de pruebas incluidas aquí no son solamente los tipos deherramientas usados por los probadores- ellos pueden usar también hojas de cálculo, SQL,recursos o herramientas de depuración (D), por ejemplo.






76-88

6.2 Uso efectivo de herramientas: beneficios potenciales y riesgos (K2) | 20

minutos

TérminosGuiado por datos (pruebas), guiado por palabra clave (pruebas), lenguaje de scripting.

6.2.1 Beneficios y riesgos potenciales de las herramientas de soporte para

pruebas (para todas las herramientas) (K2)

Simplemente comprando o arrendando una herramienta no garantiza el éxito con esaherramienta. Cada tipo de herramienta requiere esfuerzo adicional para conseguir beneficios reales y duraderos. Hay oportunidades de beneficios potenciales con el uso deherramientas para testear, pero hay también riesgos.

Beneficios potenciales de usar herramientas incluyen:

• Los trabajos repetitivos se reducen (ej.: ejecución de pruebas regresivas, poniendode nuevo los mismos datos del test, y comprobando otra vez estándares de códigos.)

• Mayor consistencia y capacidad de repetición (ej.: tests ejecutados por unaherramienta, y test que provienen de requisitos)

• Valoración de objetivos (ej.: medidas estáticas, cobertura y comportamiento delsistema).

• Facilidad de acceso a información sobre los tests o pruebas (ej.: estadísticas ygráficos sobre el progreso de las pruebas, tasas de incidencias y ejecuciones.)

Los riesgos de usar herramientas incluyen:

• Expectativas irreales para la herramienta (incluyendo funcionalidad y facilidad deuso.)

• Infraestimación del tiempo, el coste y esfuerzo para la introducción inicial de laherramienta (incluyendo entrenamiento y experiencia externa)

• Infraestimación del tiempo y esfuerzo necesarios para conseguir beneficiossignificativos y continuos de la herramienta (incluyendo la necesidad de cambios enel proceso de pruebas y continua mejora de la forma en que se usa la herramienta.)

• Infra-estimación del esfuerzo requerido para mantener los recursos de las pruebasgeneradas por la herramienta.

• Sobredependencia de la herramienta (sustitución del diseño del test o donde las pruebas manuales serían mejor.)

6.2.2 Consideraciones especiales para algunos tipos de herramientas (K1)

Herramientas de ejecución de tests






77-88

Las herramientas de ejecución de tests ejecutan scripts diseñados para implementar las pruebas que están almacenadas electrónicamente. Este tipo de herramienta a menudorequiere esfuerzos significativos para conseguir beneficios significativos.

La captura de tests mediante la grabación de las acciones de un probador manual

parece atractiva, pero este enfoque no es escalable para gran número de pruebas manuales.Un script de captura es una representación lineal con datos específicos y acciones como parte de cada script . Este tipo de script puede ser inestable cuando ocurren eventosinesperados.

Una técnica guiada por datos separa salidas, de las entradas del test(los datos),usualmente en una hoja de cálculo, y usa un script más genérico que puede leer datos detest y ejecutar el mismo test con diferentes datos. Los probadores que no estánfamiliarizados con el lenguaje de scripting pueden introducir datos de test para estos scripts predeterminados. En la técnica guiada por palabra clave, la hoja de cálculo contiene palabras claves describiendo las acciones para ser tomadas (también llamadas palabras de

acción) y datos de test. Los probadores (incluso si no están familiarizados con el lenguajede scripting ), pueden definir tests usando las palabras clave, las cuales pueden ser adaptadas a la aplicación siendo testeadas.

Los técnicos expertos en el lenguaje de scripting se necesitan para todos los enfoques(o por probadores o especialistas en la automatización de tests.)

Se usa cualquier técnica de scripting , los resultados esperados para cada test necesitanser almacenados para una comparación posterior.

Herramientas de pruebas de funcionamiento

Las herramientas de pruebas de funcionamiento necesitan a alguien con experienciaen las pruebas de funcionamiento para ayudar a diseñar los tests e interpretar los resultados.

Herramientas de análisis estático

Las herramientas de análisis estático aplicado a un código fuente pueden imponer códigos estándares, pero si se aplican a códigos existentes pueden generar muchosmensajes. Los mensajes de aviso no detienen el código que está siendo traducido a un programa ejecutable, pero perfectamente debería ser dirigido para que el mantenimiento delcódigo fuera más fácil en el futuro. Una implementación gradual con filtros iniciales para

excluir algunos mensajes sería una efectiva aproximación.

Herramientas de gestión de pruebas

Las herramientas de gestión de pruebas necesitan interactuar con otras herramientas uhojas de cálculos para que produzcan información en el mejor formato para las necesidadesgenerales de la organización. Los informes necesitan ser diseñados y monitorizados paraque produzcan beneficios.






78-88

6.3 Introducir una herramienta en una organización (K1) | 15 minutos

Términos Ningún término especificado

Conocimientos previosLos principales principios para introducir una herramienta en una organización

incluye:

• La evaluación del completo desarrollo de una organización, su solidez, debilidadese identificación de oportunidades para mejora de los procesos de prueba soportados por herramientas.

• Evaluación en lugar de requisitos claros y criterios objetivos.• Una prueba de concepto para comprobar la funcionalidad requerida y determinar si

el producto cumple sus objetivos.• Evaluación del vendedor (incluyendo entrenamiento, apoyo y aspectos

comerciales.)• Identificación de requisitos internos de preparación (entrenamiento) y tutorización

en el uso de la herramienta.

La prueba de concepto podría ser hecha en un proyecto piloto de pequeña escalahaciéndolo posible para minimizar impactos si se encuentran serios obstáculos y el proyecto piloto no tiene éxito.

Un proyecto piloto tiene los siguientes objetivos:• Aprender más detalles sobre la herramienta.• Ver cómo la herramienta encaja con procesos existentes y prácticos, y cómo ellos

deberían ser cambiados.• Decidir formas estándares de uso, gestión, almacenamiento y mantenimiento de la

herramienta y los recursos de tests (Ej.: decidiendo convenciones de nombres paraficheros y tests, creando bibliotecas y definiendo la modularidad de los juegos detests.

• Determinar si los beneficios serán conseguidos a un precio razonable.

Factores de éxito para el desarrollo de la herramienta más allá de una organizaciónincluye:

• Extender la herramienta al resto de la organización paulatinamente.• Adaptar y mejorar los procesos que encajen con el uso de la herramienta.• Proporcionar formación y preparación/tutorización para los nuevos usuarios.• Definir las directrices de uso.• Implementar una forma de aprender lecciones por el uso de la herramienta.






79-88

• Monitorizar el uso de la herramienta y beneficios.

Referencias

6.2.2 Buwalda, 2001, Fewster, 19996.3 Fewster 1999

7. Referencias

Estándares

Glosario de términos usado en la versión 1.0 de ISTQB.

[CMMI] Chrissis, M.B., Konrad, M. and Shrum, S. (2004) CMMI, Guidelines for ProcessIntegration and Product Improvement, Addison Wesley: Reading, MA(Pautas para la integración de procesos y mejora de productos)Ver sección 2.1

[IEEE 829] IEEE Std 829™ (1998/2005) IEEE Standard for Software Test Documentation(Estándar 829 del IEEE para la documentación del testeo de software)(Actualmente en revisión)Ver secciones 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6

[IEEE 1028] IEEE Std 1028™ (1997) IEEE Standard for Software Reviews(Estándar 1028 del IEEE para la revisión de software)Ver seccion 3.2

[IEEE 12207] IEEE 12207/ISO/IEC 12207-1996, Software life cycle processes(Estándar 12207/ISO/IEC del IEEE sobre los procesos de ciclo de vida)Ver sección 2.1

[ISO 9126] ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality(Ingeniería del software - calidad de los productos software)Ver sección 2.3

Libros

Glosario de términos usado en la versión 1.0 de ISTQB.

[Beizer, 1990] Beizer, B. (1990) Software Testing Techniques (2nd edition), Van NostrandReinhold: Boston(Técnicas de testeo de softwre)Ver secciones 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6

[Black, 2001] Black, R. (2001) Managing the Testing Process (2nd edition), John Wiley &Sons: New Cork (Manejando el proceso de pruebas)






80-88

Ver secciones 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6

[Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Automation,Addison Wesley: Reading, MA(Diseño y automatización de pruebas integradas)

Ver sección 6.2

[Copeland, 2004] Copeland, L. (2004) A Practitioner’s Guide to Software Test Design,Artech House: Norwood, MA(Una guía para profesionales para el diseño de software de pruebas)Ver secciones 2.2, 2.3, 4.2, 4.3, 4.4, 4.6

[Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing,Artech House: Norwood, MA(Pruebas sistemáticas de software)Ver secciones 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4

[Fewster, 1999] Fewster, M. and Graham, D. (1999) Software Test Automation, AddisonWesley: Reading, MA(Automatización del software de pruebas)Ver secciones 6.2, 6.3

[Gilb, 1993]: Gilb, Tom and Graham, Dorothy (1993) Software Inspection, AddisonWesley: Reading, MA(Inspección de software)Ver secciones 3.2.2, 3.2.4

[Hetzel, 1988] Hetzel, W. (1988) Complete Guide to Software Testing, QED: Wellesley,MA(Guía completa para el testeo de software)Ver secciones 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 4.1, 5.1, 5.3

[Kaner, 2002] Kaner, C., Bach, J. and Pettticord, B. (2002) Lessons Learned in SoftwareTesting, John Wiley & Sons:(Lecciones aprendidas en testeo de software)Ver secciones 1.1, 4.5, 5.2

[Myers 1979] Myers, Glenford J. (1979) The Art of Software Testing, John Wiley & Sons:

(El arte del testeo de software)Ver secciones 1.2, 1.3, 2.2, 4.3

[van Veenendaal, 2004] van Veenendaal, E. (ed.) (2004) The Testing Practitioner (Chapters6, 8, 10), UTN Publishers: The Netherlands(El profesional del testeo)Ver secciones 3.2, 3.3






81-88

Apéndice A – Trasfondo del plan de estudios (syllabus)

Historia de este documento

Este documento se preparó durante 2004 y 2005 por un grupo de trabajo compuesto por miembros designados por el ISTQB (International Software Testing QualificationsBoard). Inicialmente fue revisado por una comisión seleccionada y posteriormente por representantes de la comunidad internacional de testeo de software ( International Software

Testing Comunity).

Las reglas utilizadas en la producción de este documento están reflejadas en elapéndice C.

Este documento es el plan de estudios (syllabus) para el certificado internacional de lafundación de testeo de software, cualificación de primer nivel aprobado por el ISTQB(www.istqb.org). En la fecha de redacción (2005), los miembros del ISTQB incluyen aAustria, Dinamarca, Finlandia, Francia, Alemania, La India, Israel, Japón, Corea, Noruega,Polonia, Portugal, España, Suecia, Suiza, Los Países Bajos, Reino Unido y los EstadosUnidos de América.

Objetivos del Foundation Certificate Qualification (Certificado de

Cualificación Básico)

• Obtener reconocimiento por el testeo como especialización esencial y profesional dela ingeniería del software.

• Ofrecer un marco de trabajo estándar para la carrera de desarrollo de probadores.

• Permitir a probadores cualificados profesionalmente ser reconocidos por patrones,usuarios y peers y elevar el perfil de probador.• Fomentar prácticas de testeo consistentes y correctas para todas las disciplinas de la

ingeniería del software.• Identificar los temas sobre testeo que son relevantes y de valor para la industria.• Permitir a los proveedores de software contratar a probadores certificados y de ese

modo ganar una ventaja comercial sobre la competencia dando a conocer la políticade selección de probadores.

• Dar una oportunidad a probadores y a aquellos interesados en el testeo para adquirir reconocimiento internacional en la cualificación.

Objetivos de la cualificación internacional (adaptado del congreso del

ISTQB en Sollentuna, en noviembre de 2001)

• Ser capaces de comparar las habilidades de testeo de diferentes países.• Permitir a los probadores atravesar las fronteras de los países más fácilmente.• Permitir a los proyector multinacionales/internaciones tener una comprensión

común sobre los puntos fundamentales del testeo.






82-88

• Aumentar el número de probadores cualificados en el mundo.• Tener un mayor impacto/valor como una iniciativa base internacional que por

enfoques específicos de cada país.• Desarrollar un cuerpo internacional común para la comprensión y conocimiento

relativo a las pruebas a través de la programación o plan de estudios ( syllabus) y la

terminología, e incrementar el nivel de conocimiento acerca del testeo por todos los participantes.

• Fomentar el testeo como una profesión en más países.• Permitir a los probadores obtener una cualificación reconocida en su lengua nativa.• Permitir que se comparta conocimiento y recursos entre países.• Ofrecer reconocimiento internacional de los probadores y esta cualificación debido

a la participación de muchos países.

Requisitos de entrada para esta cualificación

El criterio de entrada para la realización del examen del Foundation Certificate in

Software Testing es que los candidatos estén interesados en el testeo de software. Noobstante, se recomienda que los candidatos también:

• Tenga unos antecedentes mínimos en desarrollo de software o testeo de software,así como 6 meses de experiencia como probador reconocido o desarrollador desoftware.

• Hayan realizado un curso que haya sido acreditado para los estándares del ISTQB(por una de las plataformas nacionales reconocidas por el ISTQB).

Trasfondo e historia del Foundation Certificate in Software Testing

(certificado básico en testeo de software)

La certificación independiente de probadores de software comenzó en Reino Unidocon la Plataforma de Evaluación de Sistemas de Información (ISEB) de la SociedadBritánica de la Computación ( British Computer Society's Information Systems Examination

Board ), cuando se montó una plataforma de testeo de software en 1998(www.bcs.org.uk/iseb). En 2002, en Alemania la ASQF comenzó a apoyar un plan decualificación de probadores (www.asqf.de). Este plan de estudios está basado en los programas de ISEB y ASQF, incluye un contenido reorganizado, actualizado y en partenuevo, y está primordialmente orientado a los temas que proporcionarán la ayuda más práctica para los probadores.

Cualquier Foundation Certificate in Software Testing (como ISEB, ASQF o una plataforma nacional reconocida por ISTQB) concedido antes que este CertificadoInternacional fuera publicado, se considerará como equivalente dicho CertificadoInternacional. El Foundation Certificate no expira y no necesita ser renovado. La fecha enque fue concedido figura en el certificado.

Dentro de cada país participante, los aspectos locales son controlado por una plataforma de testeo de software reconocida por el ISTQB. Las obligaciones de las






83-88

plataformas nacionales son especificadas por el ISTQB, pero son implementadas dentro decada país. Las obligaciones que se esperan de las plataformas nacionales son: incluir laacreditación de formadores y el ajuste de exámenes.






84-88

Apéndice B – Objetivos de Aprendizaje/Nivel de Conocimiento

Los siguientes objetivos de aprendizaje se definen para la aplicación en este plan deestudios. Cada tema del plan de estudios será examinado de acuerdo con su objetivo de

aprendizaje.

Nivel 1: Recordar (K1)El candidato reconocerá, retendrá y recordará un término o concepto.

Ejemplo

Puede reconocer la definición de avería ( failure) como:• Denegación de servicio a un usuario final o cualquier otro stakeholder .• Desviación actual del componente o sistema del que se espera una entrega, servicio

o resultado.

Nivel 2: Entender (K2)El candidato es capaz de elegir el razonamiento o explicación para expresarse a cerca deltema y es capaz de resumir, comparar, clasificar y dar ejemplos para el concepto a testear.

Ejemplo

Puede explicar la razón por la cual los tests deberían ser designados tan fáciles como sea posible:

• Para encontrar defectos cuando son más fácilmente eliminables.• Para encontrar los defectos más importantes primero.

Puede explicar las similitudes y diferencias entre testeo de integración y de sistema:• Similitudes: testean más de un componente, y pueden probar aspectos no

funcionales.• Diferencias: las pruebas de integración se centran en las interfaces e interacciones,

mientras que las pruebas de sistema se centran en aspectos del sistema completo,tales como el procesamiento al completo (end to end).

Nivel 3: Aplicar (K3)El candidato es capaz de elegir la aplicación correcta de un concepto o técnica y aplicarla aun contexto dado.

Ejemplo• Poder identificar la acotación de los valores válidos e inválidos de las particiones.• Poder elegir casos de prueba a partir de un diagrama de transición de estado con el

fin de cubrir todas las transiciones.






85-88

Referencias(Para los objetivos de aprendizaje de los niveles cognoscitivos):

Anderson, L. W. and Krathwohl, D. R. (eds) (2001) A Taxonomy for Learning, Teaching,

and Assessing: A Revision of Bloom's Taxonomy of Educational Objectives, Allyn &Bacon.(Una taxonomía para el aprendizaje, enseñanza y evaluación: Una revisión lataxonomía de Bloom de los objetivos educacionales).






86-88

Apéndice C – Reglas aplicadas al plan de estudios de ISTQB

Foundation

Las reglas listadas aquí se usan en el desarrollo y revisión del plan de estudios (semuestra una etiqueta después de cada regla en letras mayúsculas).

Reglas Generales

SG1. El plan de estudios deberá ser comprensible para personas entre 0 a 6 meses (o más)de experiencia en testeo (6-MONTH).SG2. El plan deberá ser más bien práctico que teórico (PRACTICAL).SG3. El plan deberá ser limpio y no ambiguo para los lectores esperados (CLEAR).SG4. El plan deberá ser entendible para personas de diferentes países, y fácilmentetraducible a diferentes idiomas (TRANSLATABLE).

SG5. El plan deberá usar inglés americano (AMERICAN-ENGLISH).Contenido actual

SC1. El plan deberá incluir conceptos recientes de testeo y deberá reflejar la mejor prácticaactual en testeo de software que estará consensuada en general. El plan está sujeto arevisión cada 3 a 5 años (RECENT).SC2. El plan deberá minimizar las cuestiones relacionas con el tiempo, tales como lascondiciones actuales del mercado, para permitirle está disponible durante 3 a 5 años(SHELF-LIFE: “caducidad”).

Objetivos de aprendizaje

LO1. El aprendizaje de objetivos deberán distinguir entre elementos a ser reconocidos/recordados (nivel cognitivo K1), elementos que el candidato deberá entender conceptualmente (K2) y aquellos que el candidato deba ser capaz de practicar/usar (K3)(KNOWLEDGE-LEVEL).LO2. La descripción del contenido deberá ser consistente con los objetivos de aprendizaje(LOCONSISTENT).LO3. Se ilustrarán los objetivos de aprendizaje, se publicarán ejemplos de preguntas deexamen para cada sección importante con el plan de estudios (LO-EXAM).

Estructura global

ST1. La estructura del plan de estudios deberá ser clara y permitir referencias cruzadasa/desde otras partes, desde las preguntas de examen y otros documentos relevantes(CROSS-REF).ST2. Se minimizará el solapamiento entre secciones del plan de estudios (OVERLAP).ST3. Cada sección del plan de estudios deberá tener la misma estructura (STRUCTURE-CONSISTENT).






87-88

ST4. El plan de estudios deberá contener la versión, fecha de publicación y número de página en cada página (VERSION).ST5. El plan de estudios deberá incluir una directriz para la cantidad de tiempo a emplear en cada sección (para reflejar la importancia relativa de cada tema). (TIME-SPENT)

Referencias

SR1. Las fuentes y referencias serán dadas por conceptos en el plan de estudios para ayudar a los formadores a encontrar más información acerca de un tema (REFS).SR2. Para aquellos temas para los que no haya fuentes fácilmente identificables y limpias,se deberá ofrecer más detalles en el plan de estudios. Por ejemplo, las definiciones están enel Glosario, así pues solo los términos están listados en el plan de estudios. (NON-REFDETAIL)

Fuentes de información

Los términos usados en el plan de estudios están definidos en el glosario de términosusados en el software de testeo de ISTQB. Se dispone de una versión del glosario en elISTQB.

También está publicada una lista de libros de pruebas de software paralelos a este plan de estudios. La lista principal de libros forma parte de la sección de referencias.






88-88

Apéndice D – Información para los formadores

Al encabezado de cada tema principal del plan de estudios se le asigna un tiempo enminutos. El propósito de ésto es la orientación en la proporción de tiempo a ser asignada a

cada sección de un curso acreditado, así como dar un tiempo mínimo aproximado para laenseñanza de cada sección. Los formadores podrán gastar más tiempo del indicado y loscandidatos pueden emplear también más tiempo en la lectura e investigación. El currículumde un curso no tiene porqué seguir el mismo orden que el plan de estudios.

El plan de estudios contiene referencias a estándares establecidos, los cuales deben ser usados en la preparación del material de entrenamiento. Se pueden también usar otras publicaciones, plantillas o estándares no referidos en el plan de estudio, pero no seexaminará acerca de ellos.

Las áreas específicas del plan de estudios que requieren ejercicios prácticos son las

siguientes:

4.3 Técnicas basadas en la especificación o de caja negra

Se incluirá un trabajo práctico (ejercicios cortos) que cubra las 4 técnicas: particionamiento equivalente, análisis y acotación de valores, tabla de decisión y diagramade transición de estado. Las lecturas y ejercicios relacionados con estas técnicas deberán basarse en las referencias provistas por cada técnica.

4.4 Técnicas basadas en la estructura o de caja blanca

Se incluirá un trabajo práctico (ejercicios cortos) para valorar si un conjunto de testsconsiguen una 100% en la cobertura de estado y decisión, así como casos de prueba paraun flujo de control dado.

5.6 Gestión de incidencias

Se incluirá un trabajo práctico (ejercicio corto) que cubrirá la escritura y/o valoración de uninforme de incidencia.

foundation level syllabus (2010)spanish

Documents