Syllabus 2011 Español.pdf

Probador Certificado

Programa de Estudio de Nivel Básico

Versión 2011

1.Fundamento de la prueba (K2)

155 minutos

Objetivos de aprendizaje para Fundamentos de Prueba Los objetivos identifican lo que se podrá hacer tras la finalización de cada modulo 1.1 ¿Porque son las pruebas necesarias? (K2) LO-1.1.1 Describir con ejemplos la manera en que un defecto puede causar daños a la persona, al entorno o a la compañía (K2) LO-1.1.2 Diferencia entre la causa principal de un defecto y sus consecuencias (K2) LO-1.1.3 Por medio de ejemplos, explicar la razón de porque son necesarias las pruebas (K2) LO-1.1.4 Describir porque las pruebas son parte de la garantía de calidad y dar ejemplos de cómo contribuyen las pruebas a una mayor calidad (K2) LO-1.1.5 Por medio de ejemplos explicar y comparar los términos de errores, defectos, fallos, mal funcionamiento y los términos de error correspondientes y virus (K2) 1.2 ¿Que significan Pruebas? (K2) LO-1.2.1 Tener en cuenta los objetivo comunes de pruebas (K1) LO-1.2.2 Dar ejemplos para los objetivos de las pruebas en fases diferentes del ciclo de vida del software (K2) LO-1.2.3 Establecer la diferencia entre las pruebas y depuración (K2) 1.3 Siete Principios de Pruebas (K2) LO-1-3.1 Explicado los siete principios en pruebas (K2) 1.4 Fundamento del Proceso de Prueba (K1) LO-1.4.1 Tener en cuenta las cinco actividades fundamentales de la prueba y las respectivas funciones desde la planeación de cierre (K1) 1.5 Psicología de las Pruebas (K2) LO-1.5.1 Tener en cuenta los factores psicológicos que tienen influencia en el éxito de la prueba (K1) LO-1.5.2 Comparar la manera de pensar del probador y de un desarrollador (K2)

1.1 Porque son necesarias las pruebas (K2)

Términos Virus, defectos, errores, fallas, desperfectos, errores, calidad, riesgo

20 minutos

1.1.1 Contexto del Sistema del Software (K1) Los sistemas del software son parte integral de la vida, desde de aplicaciones comerciales (por ejemplo banca) hasta productos de consumo (por ejemplo, carros). La mayoría de gente que ha tenido experiencia con el software, no les ha funcionado como esperaban. El software que no funciona correctamente, puede causar varios problemas, incluyendo perdida de dinero, tiempo, reputación del negocio e incluso podría causar daño o muerte. 1.1.2 Causas de los Defectos del Software (K2) Un ser humano puede cometer errores, que generan defectos (fallas, virus) en el código del programa o en un documento. Sí se ejecuta un defecto en el código, pueden haber fallas en el sistema al realizar lo que debe hacer (o lo que no debe hacer), generando fallas. Los defectos en el software, sistemas o documentos pueden resultar en fallas, sin embargo no sucede con todos los defectos. Los defectos se dan debido a que la gente es falible y porque hay presión de tiempo, códigos complejos, complejidad de infraestructura, cambios de tecnologías y / o varias interacciones del sistema. Las fallas se pueden dar por condiciones ambientales respectivamente. Por ejemplo, radiación, magnetismo, campos electrónicos, y polución pueden causar desperfectos en firmware o influencia en la ejecución del software cambiando las condiciones del hardware. 1.1.3 Función de las Pruebas en el Desarrollo, Mantenimiento y Operaciones del Software (K2) Las pruebas rigurosas de sistemas y documentación ayudan a reducir el riesgo de problemas que ocurren durante la operación y contribuyen a la calidad del sistema del software, si se corrigen los defectos encontrados antes de lanzar el sistema para uso operativo. También puede requerirse que el software cumpla los requisitos contractuales y legales o estándares específicos industriales. 1.1.4 Pruebas y Calidad (K2) Con la ayuda de las pruebas, es posible medir la calidad del software en términos de defectos encontrados para los requisitos y características funcionales y no funcionales del software (por ejemplo, confiabilidad, uso, eficiencia, mantenimiento y portabilidad).Para mayor información sobre pruebas no funcionales, véase Capitulo 2; para mayor información sobre características de Software, véase "Software Engineering-Sotfware Product Quality" (ISO 9126). Las pruebas dan confianza en la calidad del software si encuentran pocos o ningún defecto. Una prueba designada adecuadamente que está aprobada, reduce todo el nivel de riesgo

en un sistema. Cuando en la prueba se encuentran defectos, la calidad del sistema del software aumenta cuando se corrigen dichos defectos. Se deben aprender lecciones de proyectos anteriores. Al comprender la causa principal de los defectos encontrados en otros proyectos, se pueden mejorar procesos que a su vez deben prevenir que dichos defectos vuelvan a ocurrir y como consecuencia mejoren la calidad de futuros sistemas. Lo anterior es una garantía de calidad. Las pruebas deben integrarse como una de las actividades de garantía de calidad (Es decir, junto con estándares de desarrollo, capacitación and análisis de defectos). 1.1.5 ¿Cuánto testing es necesario? (K2) Cuando se toma la decisión de cuanto testing es suficiente, se debe considerar el nivel de riesgo, incluyendo riesgos técnicos, de seguridad y comerciales y restricciones del proyecto como tiempo y presupuesto. El riesgo se examina más detalladamente en el Capítulo 5. Testing debe dar la suficiente información a accionistas parque tomen decisiones fundamentadas respecto al lanzamiento del software o sistema que se está probando, para la próxima fase de desarrollo o entrega a clientes.

1.2 ¿Que es Testing?(K2)

30 minutos

Terminos Depuramiento, requisitos, revisión, caso de prueba, testing, objetivo de prueba Antecedentes Una percepción normal de testing es aquella que solo consiste en realizar pruebas, es decir, ejecutar el software. Esto hace parte del testing pero no de todas las actividades del mismo. Las actividades de pruebas existen antes y después de la ejecución de pruebas. Estas actividades incluyen la planeación, control, selección de condiciones de pruebas diseño y ejecución de casos de prueba, revisión de resultados, evaluación de fin de pruebas, reportes del proceso de testing y sistema conforme dicha prueba y finalización del cierre de actividades después de haber terminado la fase de prueba. Testing también incluye la revisión de documentos (incluyendo el código fuente) y dirección de análisis estáticos Se puede utilizar el testing dinámico y estático como medio para lograr objetivos similares y suministraran información que puede utilizarse para mejorar el sistema que se está probando y los procesos de desarrollo y testing. Testing puede tener los siguientes objetivos: - Encontrar defectos - Ganar confianza respecto al nivel de calidad - suministrar información para la toma de decisiones.

-

Prevenir defectos

El proceso pensado y actividades relacionadas en el diseño de pruebas en el ciclo de vida (verificación de pruebas base por medio de diseños de pruebas) pueden ayudar a prevenir que se introduzcan defectos en el código. La revisión de documentos (por ejemplo, requisitos) y la identificación y resolución de asuntos ayudan también a prevenir defectos que aparecen en el código. En diferentes puntos de vista en testing, se toman en cuenta distintos objetivos. Por ejemplo en el desarrollo del testing (por ejemplo, componentes, integración, y testing del sistema), es posible que el principal objetivo sea identificar la mayor cantidad de fallas posibles de manera que se puedan identificar defectos en el software y se solucionen. En las pruebas de validación, el principal objetivo puede ser confirmar que el sistema funcione como se había esperado, ganar confianza y cumplir los requisitos. En algunos casos el principal objetivo de testing puede ser evaluar a la calidad del software (sin la intención de arreglar defectos), informar a accionistas del riesgo que corren al lanzar el sistema en un momento dado. El mantenimiento del testing generalmente incluye pruebas donde no se han presentado defectos nuevos durante el desarrollo de los cambios. En el testing operativo, el principal objetivo es evaluar las características del sistema como la confiabilidad y disponibilidad. Son diferentes la depuración y testing. El testing dinámico puede mostrar fallas causadas por defectos. La depuración es la actividad de desarrollo que encuentra, analiza y remueve la causa de la falla. El re-testing posterior hecho por un probador, garantiza que el arreglo ciertamente resuelve la falla. La responsabilidad de estas actividades es que normalmente los probadores y desarrolladores hagan el proceso de depuración. El proceso de testing y actividades de testing se explican en la sección 1.4

1.3 Siete Principios de Testing (K2)

35 minutos

Términos Testing Exhaustivo Principios Se han sugerido varios principios de testing los últimos 40 años así como se han ofrecido pautas comunes para todo el proceso de testing. Principio 1- Testing muestra la presencia de defectos Testing puede mostrar que los defectos están presentes, pero no puede comprobar que no haya defectos. Testing reduce las probabilidades de defectos no descubiertos que permanecen en el software, pero incluso si no se encuentran defectos, no es prueba de corrección. Principio 2 -Testing exhaustivo es imposible Hacer pruebas de todo (todas las combinaciones de entradas y prerrequisitos) no es viable salvo casos triviales. En lugar de pruebas exhaustivas, se debe utilizar un análisis de riesgo y prioridades que se enfocan en esfuerzo de testing (testing efforts).

Principio 3 - Testing anticipado Para encontrar defectos por anticipado, las actividades deberán empezar lo más temprano posible en el desarrollo del ciclo de vida del software o el sistema, y deberá enfocarse en objetivos definidos Principio 4 - Agrupación de defecto Las pruebas se enfocaran proporcionalmente a la densidad del defecto de modulos esperado y observado posteriormente. Pocos modulos generalmente contienen la mayoría de defectos descubiertos durante el testing previo al lanzamiento, o son responsables de la mayoría de fallas operativas. Principio 5 Paradoja Pesticida (Pesticide paradox) Si se repiten las mismas pruebas una y otra vez, los mismos casos de pruebas finalmente ya no encontraran defectos nuevos. Para superar esta "paradoja pesticida", se necesitan revisar y examinar regularmente los casos de prueba y además se deberán redactar nuevas y diferentes pruebas que ejerciten distintas partes del software o sistema que potencialmente encuentren más defectos Principio 6 - Testing es un contexto dependiente Testing se realiza de una manera diferente en diferentes contextos. Ejemplo, se prueba el software crítico relacionado con seguridad de una manera diferente al portal ecommerce Principio 7 - Falta de errores Encontrar y arreglar errores no ayuda si el sistema desarrollado no sirve o no cumple las necesidades y expectativas del usuario.

1.4 Proceso fundamental de la Prueba (K1)

35 minutos

Terminos La confirmación de testing, re-testing criterios de salida, incidentes, pruebas de regresión, bases de pruebas, condiciones de pruebas, cubrimiento de pruebas, datos de pruebas, ejecución de pruebas, log de pruebas, plan de pruebas procedimiento de pruebas, política de pruebas, conjunto de pruebas, reporte de resumen de pruebas, testware Antecedentes La parte más visible de testing es la ejecución de pruebas. Sin embargo, para ser efectivo y eficiente, los planes de prueba deben incluir el tiempo que se debe gastar en la planeación de pruebas, diseño de casos de pruebas, preparación de la ejecución y evaluación de resultados

El proceso fundamental de pruebas consiste en las siguientes actividades principales: - Planeación de pruebas y control - Análisis y diseño de pruebas - Implementación evaluación de pruebas - Evaluación de criterios de salida y reporte - Actividades de cierre del testing Siendo lógicamente secuencial, las actividades en el proceso pueden sobreponer u ocurrir al mismo tiempo. Se requiere generalmente adaptar estas actividades en el contexto de sistema y el proyecto. 1.4.1 Planeación y control de pruebas (K1) La planeación de pruebas es la actividad que define los objetivos de testing y la especificación de actividades de prueba con el fin de cumplir los objetivos misión. El control de pruebas es la actividad continua de comparar el progreso real del plan, y el reporte del estado, que incluyen desviaciones desde el plan. Este control incluye tomar las acciones necesarias que cumplen la misión y objetivos del proyecto. Para controlar el testing, estas actividades deben monitorearse a través del proyecto. La planeación de pruebas considera la retroalimentación a partir del monitoreo y control de actividades. Las funciones de planeación y control se definen en el Capitulo 5 de este programa 1.4.2 Análisis y Diseño de Pruebas (K1) El análisis y diseño de pruebas es la actividad en la cual se transforman los objetivos generales de testing en condiciones de prueba tangibles y en casos de pruebas El análisis y diseño de pruebas tiene las siguientes actividades principales: - Revisar las bases de pruebas (como requisitos, integridad del software nivel 1 ( nivel de riesgo), reporte de análisis de riesgo, arquitectura, diseño, interface, especificaciones) . - Evaluación de comprobabilidad de la base de pruebas y objetos de pruebas - Identificación y prioridad de las condiciones de pruebas basadas en el análisis del objeto de pruebas, la especificación, comportamiento y estructura del software. - Diseño y Prioridad de altos niveles de casos de pruebas - Identificación de información de pruebas necesaria para apoyar las condiciones de pruebas y casos de pruebas - Diseño de la configuración del entorno de la prueba e identificación de cualquier infraestructura requerida y herramientas. - Creación de trazabilidad bidireccional entre las base de prueba y casos de prueba

1. el grado al cual el software cumple o debe cumplir con un conjunto de características de software elegido por accionistas de un sistema basado en software ( por ejemplo, complejidad del software, evaluación de riesgo, nivel del seguridad, desempeño deseado, confiabilidad o costo) que se definen para reflejar la importancia del software a sus accionistas.

1.4.3 Implementación y ejecución de pruebas (K1) La implementación y ejecución de pruebas es cuando los procedimientos de pruebas o escritos se especifican combinando los casos de pruebas en un orden particular e incluyendo cualquier otra información necesaria para ejecutar pruebas, se configura el entono y se realizan pruebas. La implementación y ejecución de pruebas tienen las siguientes tareas importantes: -

-

-

-

Finalizar, implementar y darle prioridad a los casos de pruebas ( incluyendo la identificación de información pruebas) Desarrollar y darle prioridad a procedimientos de pruebas, crear información de pruebas u opcionalmente preparar test. Harnesses (herramienta de pruebas específicas que permite probar [...] un servicio de manera aislada) y redactar scripts (escrito) de pruebas automatizadas. Crear grupos de pruebas a partir de procedimientos de pruebas para una eficiente ejecución de pruebas Verificar que el entorno de pruebas se haya configurado correctamente. Verificar y actualizar la trazabilidad bidireccional entre las bases de pruebas y casos de pruebas. Ejecutar procedimientos de pruebas manualmente o utilizando las herramientas de ejecución de pruebas de acuerdo a la secuencia planeada Registrar los resultados de la ejecución de pruebas y registro de identidades y versiones del software conforme la prueba, herramientas de pruebas y testware Comparar resultados reales con los resultados esperados Reportar discrepancias como incidentes y analizarlos para establecer su causa ( por ejemplo, un defecto en el código, en datos específicos de pruebas documentos pruebas o errores en la manera en que se ejecuto la prueba) Repetir las actividades de pruebas como resultado de las acciones tomadas de cada discrepancia, por ejemplo, la re ejecución de una prueba que fallo previamente con el fin de confirmar una solución ( confirmación de testing), ejecución de una prueba corregida y / o ejecución de pruebas para asegurar que los defectos no han sido ingresados en áreas inalteradas del software o que la solución de defectos no descubrieron otros defectos ( Testing de regresión)

1.4.4 Evaluación de criterios de salida y Reportes (K1) La evaluación de criterios salida es la actividad donde se evalúa la ejecución de pruebas con respecto a los objetivos definidos. Lo anterior debería realizarse para cada nivel de prueba (ver sección 2.2) La evaluación de los criterios de salida tienen las siguientes tareas importantes: -

Revisar registradores de pruebas respecto a criterios de salida especificados en la planeación de pruebas Evaluar si se necesitan más pruebas o si los criterios de salida específicos deben cambiarse Redactar un reporte de resumen de pruebas para accionistas

1.4.5 Actividades de Cierre de Pruebas (K1) Las actividades de cierre recopilan información de actividades de pruebas finalizadas para consolidar experiencia, testware hechos y cifras. Las actividades del cierre de pruebas se dan en fases del proyecto cuando se lanza un sistema de software, finaliza un proyecto de pruebas (o se cancela) se logra un hito o se completa una conformidad de mantenimiento. Las actividades de cierre incluyen las siguientes tareas principales: -

-

Revisar que los resultados planeados se hayan entregado Cerrar los reportes de incidentes o levantar registros de cambios para cualquiera de ellos que permanezcan abiertos. Documentar la aceptación del sistema Finalizar y archivar el testware, el entorno de pruebas e infraestructura de pruebas para un futuro re uso o entrega de testware para la organización de mantenimiento Analizar las lecciones aprendidas para determinar cambios necesarios para futuras salidas y proyectos. - Uso de información recopilada que mejoren el test maturity. (vencimiento de la prueba).

1.5 Psicología de testing (K2)

25 minutos

Terminos Error guessing (calculo de errores), independencia Antecedentes La manera en que se analiza mientras el proceso de prueba y revisión es diferente a aquella que se utiliza mientras se desarrolla el software .Con la correcta actitud los desarrolladores pueden probar sus propios códigos, pero la división de esta responsabilidad a un probador se realiza comúnmente para ayudar a enfocarse en esfuerzos y suministra beneficios adicionales, como una perspectiva independiente por

recursos de testing capacitados y profesionales. Testing independiente puede llevarse acabo en cualquier nivel del testing. Un cierto grado de independencia (evitando la influencia del autor) generalmente hace que el probador sea más eficiente para encontrar defectos y fallas. La independencia no es, sin embargo, un reemplazo de familiaridad y desarrolladores pueden eficientemente encontrar muchos defectos en sus propios códigos. Muchos niveles e independencia se pueden definir tal como se muestra de bajo a alto: - Las pruebas diseñadas por personas que han redactado el software conforme la prueba (nivel bajo de independencia ) - Pruebas diseñadas por otras personas ( por ejemplo, el equipo de desarrollo) - Pruebas diseñadas por personas de un grupo organizacional diferente ( por ejemplo, equipo de prueba independiente) o especialistas de pruebas ( por ejemplo, uso o desempeño de especialistas en pruebas) - Pruebas diseñadas por personas de diferentes organizaciones o compañías ( es decir, outsourcing o certificación por un organismo externo) La gente y los proyectos se rigen por proyectos. La gente tiende a nivelar sus planes con los objetivos planteados por el manejo y otros accionistas, por ejemplo encontrar defectos o confirmar que el software cumple sus objetivos. Por lo tanto, es importante establecer claramente los objetivos de testing. Identificar fallas en el proceso de testing puede percibirse como una crítica del producto y el autor. Como resultado, el testing se ve como una actividad destructiva a pesar de ser muy constructiva en el manejo de riesgos del producto. La búsqueda de fallas en un sistema requiere curiosidad, pesimismo profesional, ojo crítico, atención a detalles, buena comunicación con desarrolladores, y experiencia donde basar error guessing. SI hay errores, defectos o fallas se comunican de manera constructiva, se deben evitar malos sentimientos entre los probadores y analistas, diseñadores y desarrolladores. Esto aplica a los defectos encontrados en la revisión así como en el testing. El probador y líder de pruebas necesitan habilidades interpersonales para dar información objetiva respecto a defectos, progreso, y riesgos de manera constructiva. Para el autor del software o documento, la información defectuosa puede ayudarles a mejorar sus habilidades. Los defectos que se encuentra y se arreglan en el testing, ahorra tiempo y dinero más adelante y reducen riesgos. Es posible que haya problemas de comunicación, especialmente si los probadores se ven solo como mensajeros de noticias no esperadas sobre defectos. Sin embargo, existen varias maneras de mejorar la comunicación y relación entre probadores y otros:

-

Comenzar con colaboración en lugar de disputas - recordarle a todos el objetivo común de mejores sistemas de calidad.

-

-

Comunicar resultados sobre el producto de una manera neutral y basada en hechos sin criticar a quien creo el producto, redactar reportes de incidentes objetivos y reales y revisar resultados. Tratar de comprender como se siente la otra persona y porque sus reacciones. Confirmar que la otra persona ha comprendido lo que se ha dicho y viceversa.

1.6 Código de Ética

10 minutos

La participación del testing software permite adquirir información confidencial y privilegiada. Un código de ética es necesario, entre otras razones que garanticen que la información no debe utilizarse inapropiadamente. Reconocer el ACM y IEEE código de ética para ingenieros, el ISTQB dice el siguiente código de ética: PUBLICO - Probador de software certificado actuara consistentemente con el interés público CLIENTE Y EMPLEADOR - Probador de software certificado actuara de una manera tal que sea el mejor beneficio para el cliente y empleador, compatible con el interés público PRODUCTO - Probador de software certificado garantizara que los entregables que suministran (sobre los productos y sistemas que prueban) cumplen los estándares de más alto nivel posible DICTAMEN - Probador de software certificado en su dictamen profesional.

mantendrá la integridad e independencia

MANEJO - Probador de software certificado y lideres se suscribirá y promoverán un enfoque ético al manejo del testing del software PROFESION - Probador de software certificado fomentara la integridad y reputación de la profesión compatible con el interés público COLEGAS - Probador de software certificado será justo y apoyara a sus colegas y promoverá cooperación con los desarrolladores de software. SELF- Probador de software certificado participara en educación permanente respecto a la práctica de su profesión y promoverá un enfoque ético a la práctica de la profesión References 1.1.5 Black, 2001, Kaner, 2002 1.2 Beizer, 1990, Black, 2001, Myers, 1979 1.3 Beizer, 1990, Hetzel, 1988, Myers, 1979 1.4 Hetzel, 1988

1.4.5 Black, 2001, Craig, 2002 1.5 Black, 2001, Hetzel, 1988

2. Testing a través del Ciclo de vida del Software (K2)

115 minutos

Objetivos de estudio para Testing a través del ciclo vida del Software Estos objetivos identifican lo que se podrá hacer realizar siguiendo el terminación de cada módulo.

proceso de

2.1 Modelos de Desarrollo del Software (K2) LO-2.1.1 Explicar la relación entre desarrollos, actividades de prueba, productos de trabajo en el ciclo de vida del desarrollo dando ejemplos, utilizando proyectos y tipos de productos (K2) LO-2.1.2 Reconocer que se deben adaptar los modelos de desarrollo del software al contexto del proyecto y características del producto (K1) LO-2.1.3 Recordar las características de un buen proceso de testing que se aplican a cualquier modelo de ciclo de vida (K1) 2.2 Niveles de Prueba (K2) LO-2.2.1 Comparar los diferentes niveles de pruebas: objetivos principales, objetos típicos de testing, objetivos típicos de testing (por ejemplo, funcionales o estructurales) y productos de trabajo relacionado, personas que prueban, tipos de defectos y fallas que debe identificarse (K2) 2.3 Tipos de Prueba (K2) LO-2.3.1 Comparar por medio de ejemplos los cuatro tipos de pruebas del software (funcional, no funcional, estructural y relacionado con cambios) (K2) LO-2.3.2 Reconocer que las pruebas funcionales y estructurales ocurren en cualquier nivel de prueba (K1). LO-2.3.3 Identificar y describir tipos de prueba no funcional basados en requisitos no funcionales (K2) LO-2.3.4 Identificar y describir tipos de prueba basados en análisis de una estructura o arquitectura del sistema del software (K2) LO-2.3.5 Describir el propósito de testing de confirmación y testing de regresión (K2) 2.4 Testing de Mantenimiento (K2) LO-2.4.1 Comparar el testing de mantenimiento (probando un sistema vigente) con la prueba de una aplicación nueva respecto a los tipos de prueba, activadores de pruebas y cantidad de pruebas (K2) LO-2.4.2 Reconocer indicadores para testing de mantenimiento (modificación, migración y retiros (K1) LO-2.4.3 Describir la función del testing de regresión y análisis de impacto en mantenimiento (K2)

2.1 Modelos de Desarrollo del Software (K2)

20 minutos

Términos Comerciales Off-The-Shelf (COTS), modelo de desarrollo iterativo-gradual, validación, verificación, modelo V. Antecedentes Las pruebas no son hechos aislados; las actividades de pruebas se relacionan a las actividades de desarrollo del software. Diferentes modelos de ciclo de vida de desarrollo necesitan distintos enfoques al testing. 2.1.1 modelo -V (Modelo de Desarrollo Secuencial) (K2) Aunque existen las variantes del modelo, un tipo común del modelo V utiliza cuatro niveles de prueba, correspondientes a los cuatro niveles de desarrollo. Los cuatro niveles utilizados en este programa son los siguientes: - Componentes (unidad) de testing - Testing de integración - Testing del Sistema - Testing de aceptación En la práctica, un modelo - V puede tener más, menos o diferentes niveles de desarrollo y pruebas dependiendo del proyecto y producto del software. Por ejemplo, puede existir un testing de integración del componente después de un testing del componente, y testing de integración del sistema después de testing en el sistema. Productos de trabajo del software (como escenarios comerciales, casos de uso, especificaciones de requisitos, documentos y códigos de diseño) que se producen durante la fase de desarrollo son generalmente la base de pruebas en uno o más niveles de la misma. Las referencias para productos de trabajo genérico incluyen la Capability Maturity Model Integration (CMMI) (Integración de Modelos de Madurez de Capacidades) o "procesos del ciclo de vida del software"(IEEE/IEC 12207). Se puede llevar a cabo la verificación y validación (diseño de prueba inicial) durante la fase de desarrollo de los productos de trabajo del software. 2.1.2 Modelos de Desarrollo Iterativo-progresivo (K2) Un desarrollo iterativo-progresivo es el proceso que establece requisitos, diseños, construcción y pruebas de un sistema en una serie de ciclos cortos de desarrollo, Por ejemplo, prototipo, Rapid Application Development (RAD) (Desarrollo Rápido de Aplicaciones) Rational Unified Process (RUP) (Proceso Unificado Racional), y modelos agiles de desarrollo. Un sistema que se produce utilizando estos modelos se pueden probar en varios niveles de prueba en cada iteración. Un incremento, junto a otros desarrollados previamente, forma un creciente sistema parcial que también debe probarse .Las pruebas de regresión son sumamente importantes en todas las iteraciones después de realizar la primera. Se pueden llevar a cabo la verificación y validación en cada progreso.

2.1.3 Testing en un Modelo del Ciclo de Vida (K2) En cualquier ciclo de vida, existen varas características de una buena prueba: - En cada actividad de desarrollo, existe una actividad de prueba correspondiente - Cada nivel de prueba tiene objetivos específicos de prueba a dicho nivel

-

El análisis y diseños de pruebas en un nivel dado debe comenzar durante la correspondiente actividad de desarrollo. Los probadores deben participar en la revisión de documentos tan pronto como estén disponibles los bosquejos en el ciclo de vida del desarrollo.

Se pueden combinar o reorganizar niveles de prueba dependiendo de la naturaleza del proyecto o arquitectura del sistema. Por ejemplo, en la integración a un sistema de un producto de software comercial Off-The-Shelf (COTS), el comprador podrá realizar la prueba de integración en el nivel del sistema (por ejemplo, la integración de infraestructura y otros sistemas o despliegue del sistema) y pruebas de aceptación (funcional y / o no funcional y el usuario y / o prueba operativa.

2.2 Niveles de Prueba (K2)

40 minutos

Términos Pruebas Alpha, beta, de componentes, driver, de campo, requisito funcional, integración, pruebas de integración, requisitos no funcionales, pruebas de resistencia, STUB, pruebas del sistema, ambiente de pruebas nivel de prueba, desarrollo guiado por pruebas, pruebas de aceptación del usuario. Antecedentes En cada nivel de prueba, se puede identificar lo siguiente: objetivos genéricos, producto (s) de trabajo que se referencian en casos de prueba derivados (es decir, bases de pruebas), objeto de prueba (es decir, lo que se está probando), defectos comunes y fallas que deben encontrarse, requisitos de test harness (herramienta de pruebas específica que permite probar un servicio de manera aislada) y soporte de herramientas y enfoques y responsabilidades específicas. Prueba de datos de configuración de un sistema se tendrá en cuanta en la planeación de pruebas. 2.2.1 Pruebas del componente (K2) Bases de Prueba o Requisitos del componente o Diseño detallado o Código Objetos de prueba comunes:

o o o

Componentes Programas Conversión de datos / programas de migración - Módulos de data base

Testing de componentes (también conocido como unidad, modulo o prueba de programa) busca defectos y verifica el funcionamiento de los módulos, programas, objetos y clases del software, etc. que se prueban por separado. Se puede realizar de forma aislada del resto del sistema, dependiendo del contexto del ciclo de vida del desarrollo y del sistema. Se pueden utilizar stubs, drivers, y simuladores. Testing de componentes puede incluir pruebas de funcionalidad y características específicas no funcionales, como comportamiento de recursos (por ejemplo, busca de pérdidas de memoria) o pruebas de resistencia, así como pruebas estructurales (por ejemplo, decisión de cobertura).Los casos de prueba se derivan de los productos de trabajo como la especificación del componente, diseño del software o modelo de datos, Normalmente, la prueba del componente ocurre con el acceso al código que se está probando y con el apoyo de un entorno de desarrollo, como un marco de pruebas de unidad o herramienta de depuramiento. En la práctica, las pruebas del componente generalmente involucra al programador que redacto el código. Lo defectos normalmente se solucionan cuando se encuentran sin manejar dichos defectos formalmente. Un enfoque al testing del componente es preparar y automatizar los casos de prueba antes de la codificación. Lo anterior se denomina como un enfoque de primeras pruebas, y desarrollo guiado por pruebas. Este enfoque es altamente iterativo y se basa en ciclo de casos de prueba desarrollados, luego en la construcción e integración de pequeñas piezas de códigos y ejecución de pruebas de componentes corrigiendo cualquier inconveniente e iteración hasta que pasen. 2.2.2 Pruebas de Integración (K2) Bases de pruebas: o Diseño del software y del sistema o Arquitectura o Flujos de trabajo o Casos de uso Objetos de prueba comunes: o Subsistemas o Implementación de base de datos o Infraestructura o Interfaces o Configuración del sistema y datos de configuración El testing de integración prueba interfaces entre componentes, interacciones con distintas partes de un sistema, como el sistema operativo, sistema del archivo, y hardware e interfaces entre sistemas.

Puede haber más de un nivel de testing de integración y puede llevarse a cabo en objetos e prueba de diversos tamaños de la siguiente manera: 1. Las pruebas de integración de componentes prueban las interacciones entre los componentes del software y se realiza después de las pruebas del componente. 2. las pruebas de integración del sistema prueban las interacciones entre distintos sistemas o entre el hardware y software y puede realizarse después de probar el sistema. En este caso, la organización de desarrollo podrá controlar únicamente un lado de la interface. Esto podría considerarse un riesgo. Los procesos comerciales que se implementan como workflows (flujo de trabajo) relacionaran una serie de sistemas. Problemas con multiplataforma pueden ser relevantes Entre mayor sea alcance de integración, más difícil es asilar defectos a un componente o sistema específicos, lo que puede aumentar riesgos y gastar más tiempo para resolver el problema. Las estrategias de integración del sistema se pueden basar en la arquitectura del sistema (como un planteamiento ascendente y un planteamiento descendente), tareas funcionales, secuencias de trámites de transacciones, o algunos otros aspectos del sistema o componentes. Con el fin de prontamente mitigar el aislamiento de fallas y detectar defectos, la integración debe ser normalmente incremental en lugar de ser un "big bang" Las pruebas de características no funcionales especificas (por ejemplo, desempeño) pueden incluirse en las pruebas de integración así como pruebas funcionales. En cada etapa de integración, los probadores se concentran únicamente en la integración misma. Por ejemplo, si están integrando el modulo A con el modulo B, están interesados en probar la comunicación que existe entre dichos módulos, no en la funcionalidad del módulo tal como se realizó en las pruebas del componente. Se pueden utilizar los enfoques funcionales y estructurales. Es ideal que los probadores comprendan la planeación de integración de la arquitectura e influencia. Si se planean las pruebas de integración antes de construir componentes o sistemas, dichos componentes pueden construirse en el orden solicitado para una mayor eficiencia en las pruebas. 2.2.3 Pruebas del sistema (K2) Bases de Prueba: o Especificación de requisitos del sistema y software o Casos de uso o Especificación funcional o Reportes de análisis de riesgo Objetos de prueba comunes: o Manuales del sistema, usuario y operación o Configuración del sistema y datos de configuración

Las pruebas del sistema se interesan por el comportamiento de todo el sistema/producto. El alcance de las pruebas estará claramente abordado en el Plan de Pruebas Master y/ o de Nivel para ese nivel de prueba. En las pruebas del sistema, el entorno de la prueba corresponde al objetivo final o entorno de producción tanto como sea posible con el fin de minimizar el riesgo de fallas de entorno específicas que no se encuentran en las pruebas. Pruebas del sistema pueden incluir pruebas basadas en riesgos y/o en especificaciones de requisitos, procesos comerciales, casos de uso, u otras descripciones de texto de alto nivel o modelos de comportamiento del sistema, interacciones con el sistema operativo y recursos de sistemas. Las pruebas del sistema deben investigar los requisitos no funcionales del sistema y características de la calidad en los datos. También necesitan los probadores hacerse cargo de requisitos incompletos o indocumentados las pruebas del sistema de requisitos funcionales comienza con el uso de las más adecuadas técnicas basadas en especificaciones (caja negra) para que se pruebe el aspecto del sistema. Por ejemplo, se puede crear una tabla de decisiones para la combinación de efectos descritos en las normas comerciales. Técnicas basadas en estructuras (caja blanca) se pueden usar para tener acceso a la rigurosidad de la prueba respecto al elemento estructural, como la estructura del menú o navegación de la página web (ver Capitulo 4) Un equipo de prueba independiente generalmente lleva a cabo las pruebas del sistema. 2.2.4 Pruebas de aceptación (K2) Bases de pruebas o Requisitos del usuario o Requisitos del sistema o Casos de uso o Procesos comerciales o Reporte de análisis de riesgo Objetos de prueba comunes o Procesos comerciales en un sistema completamente integrado o Procesos operativos y de mantenimiento o Procedimientos del usuario o Formas o Reportes o Datos de configuración Frecuentemente es responsabilidad de los clientes o usuarios de un sistema, las pruebas de aceptación; otros accionistas pueden participar respectivamente. El objetivo en las pruebas de aceptación es establecer confianza en el sistema, partes del sistema o características específicas no funcionales del sistema. Encontrar defectos no es

el enfoque principal en estas pruebas. Estas pruebas pueden evaluar la disponibilidad del sistema para su despliegue y uso, aunque no es necesariamente el nivel final de la prueba. Por ejemplo, una prueba de un sistema de integración a larga escala puede venir después de una prueba de aceptación para un sistema. Las pruebas de aceptación pueden darse en varios momentos del ciclo de vida, por ejemplo; o Un producto software COTS puede ser prueba de aceptación cuando se instala o se integra. o Pruebas de aceptación del uso de un componente puede realizarse durante la prueba del componente o Pruebas de aceptación de una ampliación funcional pude venir antes de probar el sistema. Formas comunes de pruebas de aceptación incluyen el siguiente: Pruebas de aceptación del usuario Comúnmente verifica el ajuste para el uso del sistema por parte de usuarios comerciales. Testing Operativo (de aceptación) La aceptación del sistema por parte de los administradores del mismo, que incluyen: o Testing de backup/restaurar o Plan de recuperación de desastres o Manejo de uso o Tareas de mantenimiento o Carga de datos y tareas de migración o Revisiones periódicas de vulnerabilidades de seguridad Testing de aceptación de contrato y norma Las pruebas de aceptación de contrato se desarrollan respecto a los criterios de aceptación de un contrato para producir un software adaptado a las medidas del cliente. Se deben definir los criterios de aceptación cuando las partes acuerden el contrato. El testing de aceptación de normas se desarrolla respecto a cualquier norma que deba adherirse a dicho gobierno, normas jurídicas o de seguridad. Testing de alpha y beta (o de campo) El software de desarrolladores del mercado o COTS, frecuentemente desea recibir retroalimentación de clientes potenciales o vigentes en su mercado antes de poner a la venta el producto del software. Se desarrolla el testing alpha en los sitios de las organizaciones de desarrollo pero no solamente por el equipo de desarrollo. El testing beta o de campo, se desarrolló por parte de clientes o clientes potenciales en sus propias sedes. Las organizaciones pueden utilizar otros términos respectivamente, como pruebas de aceptación de fábrica y pruebas de aceptación de sitio para sistemas que se prueben antes y después de llevarlos a las instalaciones del cliente.

2.3 Tipos de prueba (K2)

40 minutos

Términos El testing dl Black-box (caja negra, recuadro negro) cubrimiento del código, testing funcional, testing de interoperabilidad, testing de carga, testing de mantenimiento, testing de desempeño, testing de fiabilidad, testing de seguridad, testing de tensión, testing estructural, testing de uso, testing de caja blanca Antecedentes Un grupo de actividades de prueba puede estar dirigido a la verificación del sistema del software (o una parte del sistema) basado en razones especificas u objetivos de prueba Un tipo de prueba se enfoca en un objetivo especial de prueba que puede ser lo siguiente: o Una función que desarrolla el software. o Una característica de calidad no funcional, como confiabilidad o uso o La estructura o arquitectura del software o sistema. o Cambios relacionados, es decir, confirmación de defectos que se han solucionado (testing de confirmación) y búsqueda de cambios accidentales. Se puede desarrollar y / o usar un modelo de software en un testing estructural (por ejemplo, modelo de flujo de control o modelo de estructura del modelo), testing no funcional (por ejemplo, modelo de desempeño, modelo de seguridad contra amenazas) y testing funcional (por ejemplo, un modelo de procesos de flujo, un modelo de transición de estado, o una especificación simple del idioma. 2.3.1 Testing de Función (Testing Funcional) (K2) Las funciones donde se deben desarrollar un sistema, subsistema, o componentes pueden describirse en productos de trabajo como especificación de requisitos, casos de uso o especificación funcional, o pueden estar indocumentados. Las funciones son lo "Que" realiza el sistema. Las pruebas funcionales se basan en funciones y características (descritas en documentos y comprendidas por los probadores) y su interoperabilidad con sistemas específicos y podrán desarrollarse en todos los niveles de prueba (por ejemplo, pruebas para componentes se pueden basar en una especificación de un componente). Las técnicas basadas en especificación se pueden utilizar para derivar condiciones de pruebas y casos de pruebas desde la funcionalidad del sistema o software (ver Capitulo 4). EL testing funcional tiene en cuenta el comportamiento externo del software (testing de caja negra).

Un tipo de testing funcional, seguridad, pruebas investiga las funciones (por ejemplo un firewall) relacionado con la detección de amenazas como virus de factores externos maliciosos. Otro tipo de testing funcional, testing de interoperabilidad, evalúa la capacidad del producto del software que interactúa con uno o más componentes o sistemas más específicos. 2.3.2 Testing de las características del software no funcionales (Testing no funcional) (K2) Testing no funcional incluye, pero no se limita a testing de desempeño testing descarga, testing de tensión, testing de uso testing de mantenimiento, testing de confianza, testing de portabilidad. Este testing se refiere a "como" funciona el sistema. Testing no funcional puede desarrollarse en todos los niveles de prueba. Testing no funcional describe las pruebas requeridas para medir las características de sistemas y software que pueden cuantificarse en una escala variable. Estas pruebas pueden referenciarse al modelo de calidad como el que se definió en Software Engineering – Software Producto Quality’ (ISO 9126). Testing no funcional tiene en cuenta el comportamiento externo del software y en la mayoría de casos utiliza técnicas de diseño de pruebas de caja negra para cumplir dicha función. 2.3.3 Testing de la Estructura/Arquitectura del Software (Testing Estructural) (K2) Testing estructural (de caja blanca) se puede desarrollar en todos los niveles de prueba. Técnicas estructurales son las que se utilizan de la mejor manera posterior a las técnicas basadas en especificaciones, con el fin de ayudar medir l minuciosidad de la prueba por medio de la evaluación de cobertura de un tipo de estructura. El cubrimiento es la medida en que se ha ejercitado una estructura por parte de un conjunto de pruebas, expresada como un porcentaje de las partidas que se cubren. Si el cubrimiento no es del 100%, se pueden diseñar más pruebas para aquellas partidas que faltaron para aumentar el cubrimiento. Las técnicas de cubrimiento se tratan el l Capitulo 4. En todos los niveles de prueba, pero especialmente en el testing del componente y testing de integración del componente, se pueden utilizar para medir el cubrimiento de códigos de elementos como estados o decisiones. El testing estructural puede basarse en la arquitectura del sistema, como una denominada jerarquía. Los enfoques de testing estructurales pueden aplicarse también en el sistema, integración del este, a o niveles de pruebas de aceptación (por ejemplo, a modelos comerciales o estructuras del menú). 2.3.4 Testing Relacionado con Cambios: Re testing y Testing de Regresión (K2) Después de detectar un defecto y solucionarlo, se debe probar nuevamente el software para confirmar que el defecto original se ha removido exitosamente. Lo anterior se denomina confirmación. La depuración (ubicación y solución de un defecto) es una actividad de desarrollo, no una actividad de pruebas.

Las pruebas de regresión es el testing repetido de un programa que ya se ha probado, después de una modificación, que descubre cualquier defecto introducido o descubierto como resultad del cambio (s).Estos defectos pueden ser ya sea en el software que se está probando o en otro componente del software relacionado o no relacionado. Se desarrolla cuando el software o su entorno se cambian. El alcance de testing de regresión se basa el riesgo de no encontrar defectos en el software que funcionaba anteriormente. Se deben repetir las pruebas si se usan para el testing de confirmación y ayuda al testing de regresión. El testing de regresión puede desarrollarse en todos los niveles de prueba e incluye testing estructural funcional y no funcional. Los conjuntos de pruebas de regresión se realizan muchas veces y generalmente evolucionan lentamente, de manera que el testing de regresión es un fuerte candidato para el proceso de automatización.

2.4 Testing de mantenimiento (K2)

15 minutos

Términos Análisis de impacto, testing de mantenimiento Antecedentes Cuando se haya desplegado, un sistema del software esta frecuentemente en servicio durante años o décadas. Durante este tiempo se corrigen, cambian o extienden el sistema, sus datos de configuración, o su entorno. La planeación de salidas anticipadas es crucial para pruebas de mantenimiento exitosas. Se debe hacer una distinción entre salidas planeadas y "hot fixes" (arreglos).Se realiza el testing de mantenimiento en un sistema operativo vigente, y se activa por modificaciones, migraciones o retiro de software o sistema. Las modificaciones incluyen cambios de mejora planeados (por ejemplo, basados en salidas), cambios correctivos y de emergencia, y cambios de entorno como actualizaciones planeadas del sistema operativo y de la base de datos, actualización planee del software comercial Off-The-Shelf o remiendos que corrigen vulnerabilidades recientemente expuestas o descubiertas del sistema operativo El testing de mantenimiento para migración (por ejemplo, de una plataforma a otra) debe incluir pruebas operativas del nuevo entorno así como el software que se ha cambiado. El testing de migración (testing de conversión) también se necesita cuando los datos provenientes de otra aplicación se van a migrar al sistema que se está manteniendo. El testing de mantenimiento para retiro de un sistema puede incluir la prueba de migración de datos o archivo si se requieren largos periodos de retención de datos. Además de las pruebas lo que se ha cambiado, el testing de mantenimiento incluye testing de regresión a partes de sistemas que no se han cambiado. El alcance del testing de mantenimiento se relaciona con el riesgo de cambio, tamaño del sistema vigente y el

tamaño del cambio. Dependiendo de los cambios, el testing de mantenimiento puede realizarse en cualquier o todos los niveles de prueba y para cualquier o todos tipos de pruebas. Determinar como el sistema vigente puede afectarse por cambios se denomina análisis de impacto y se utiliza para ayudar a decidir cuantas pruebas de regresión se hacen. El análisis de impacto puede utilizarse para determinar la regresión del conjunto de pruebas. El testing de mantenimiento puede ser difícil si están obsoletos o faltan especificaciones o no están disponibles probadores con conocimiento de dominio Referencias 2.1.3 C M MI, Craig, 2 002, Hete l, 1988, IEE E 12207 2.2 Él t z el, 1 988 2.2.4 C o pelo un nd, 20 0 4, Myers, 1 9 79 2.3.1 B e iz e r, 1990, Falta B, 2001, Cop e la nd, 2 00 4 2.3.2 Bl cción, 2001, I S O 9126 2.3.3 B e iz e r, 1990, C opa ly, 2 0 04, Hetzel, 1988 2.3.4 H e tze l, 1988, me Eee S T D 8 febrero 9 a 19 9 8 2.4 B la c k, 2001, C r un ig, 2 0 02, H e tzel, 1988, I eee S T D 8 2 9-1998

3.

Técnicas Estáticas (K2)

60 minutos

Objetivos de estudio para las técnicas estáticas

Estos objetivos identifican lo que se podrá hacer tras la finalización de cada módulo. 3.1 Técnicas estáticas y Proceso de Prueba (K2) LO-3.1.1 Reconocer los productos software de trabajo que pueden examinar distintas técnicas estáticas (K1) LO-3.1.2 Describir la importancia y valor de las técnicas estáticas en la evaluación de productos software de trabajo (K2) LO-3.1.3 Explicar la diferencia entre técnicas estáticas y dinámicas, teniendo en cuenta los objetivos, los tipos de defectos que deben identificarse y la función de estas técnicas en el ciclo de vida del software 3.2 Proceso de Revisión (K2) LO-3.2.1 Recordar las actividades, funciones y responsabilidades de una revisión formal común (K1) LO-3.2.2 Explicar las diferencias entre los tipos de revisiones: revisión informal, revisión técnica, recorrido e inspección (K2) LO-3.2.3 Explicar los factores para una revisión exitosa (K2) 3.3 Análisis Estático hecho por Herramientas (K2) LO-3.3.1 Recordar los defectos y errores comunes que identifica el análisis estático y compararlos con las revisión y pruebas dinámicas (k1)

LO-3.3.2 LO-3.3.3

3.1

Describir con ejemplos los beneficios comunes del análisis estático (K2) Hacer una lista de defectos comunes de códigos y diseños que puedan identificar las herramientas de análisis estático (K1) Técnicas Estáticas y Proceso de Prueba

15 minutos

Términos Pruebas dinámicas, pruebas estáticas Antecedentes A diferencia de las pruebas dinámicas, que requieren la ejecución del software, las técnicas de pruebas dinámicas cuentan con la exanimación manual (revisiones) y un análisis automatizado (análisis estático) del código u otra documentación del proyecto sin la ejecución del código. Las revisiones son una forma de probar los productos software de trabajo (incluyendo códigos) y pueden desarrollarse correctamente antes de ejecutar la prueba dinámica. Los defectos detectados durante las primeras revisiones en el ciclo de vida (por ejemplo, defectos encontrados en los requisitos) son más económicos de remover que aquellos que se detectan realizando pruebas en el código de ejecución. Se podría realizar una revisión completa como un manual de actividades, pero también hay soporte de herramientas. La principal actividad del manual es examinar un producto de trabajo y hacer comentarios respecto a eso. Se puede revisar cualquier producto de software de trabajo, incluyendo especificación de requisitos especificaciones de diseño, código, planes de prueba, especificaciones de prueba, casos de prueba, comandos de prueba, guías de usuario o páginas web. Los beneficios de las revisiones incluyen una detección y corrección temprana de defectos, mejoras en la productividad de desarrollo, calendarios de desarrollo reducidos, costos y tiempos de pruebas reducidos, reducciones de costo de duración, menos defectos y mejor comunicación. Las revisiones pueden encontrar omisiones, por ejemplo en requisitos que probablemente no se encuentran en las pruebas dinámicas. Las revisiones, análisis estáticos, y pruebas dinámicas tienen el mismo objetivo; identificar defectos. Son complementarios; las distintas técnicas pueden encontrar diferentes tipos de defectos de manera efectiva y eficiente. En comparación a las pruebas dinámicas, las técnicas estáticas encuentras las causas de las fallas (defectos) en lugar de fallas como tal. Los defectos comunes que son más fáciles de encontrar en las revisiones que en las pruebas dinámicas incluyen lo siguiente: desviaciones de estándares, defectos de requisitos, defectos de diseño, mantenimiento insuficiente y especificaciones de interfaces incorrectas.

3.2

Proceso de Revisión (K2)

25 minutos

Términos Criterios de ingreso, revisión formal, inspección, métrica, moderador, revisión por expertos, revisador, escritos, revisión técnica, recorridos. Antecedentes Los diferentes tipos de revisiones varían de instrucciones informales que se caracterizan por no ser escritas para revisores a resultados sistemáticos documentados de la revisión, procedimientos sistemáticos documentados para dirigir revisiones que se caracterizan por la participación en equipo. La formalidad de un proceso de revisión se relaciona con factores como la madurez del proceso de desarrollo, cualquier requisito legal o reglamentario o la necesidad de un seguimiento de auditoria. La manera en que se lleva a cabo una revisión depende de los objetivos de revisión acordados (por ejemplo, encontrar defectos, comprender mejor, educar probadores y a nuevos miembros en el equipo y decidir por consenso). 3.2.1 Actividades de una Revisión Formal (K1) Una revisión formal común tiene las siguientes actividades principales: 1. Planeación o Definición de criterios de revisión o Selección de personal o Asignación de funciones o Definición de criterios de entrada y salida para tipos de revisión más formal (inspecciones) o Selección de cuales documentos se deben revisar o Revisión de criterios de entrada ( para tipos de revisión más formal) 2. Kick-off o Distribución de documentos o Explicación de objetivos, procesos y documentos de los participantes 3. Preparación individual o Preparación para reuniones de revisión por medio de la revisión de documentos o Observación de defectos, preguntas y comentarios potenciales 4. Exanimación / evaluación / registro de resultados (reunión de revisión) o Discusión o registros con resultados o actas documentados ( para más tipos de revisión formal) o Observar defectos, recomendaciones respecto al manejo de defectos , toma de decisiones respecto a los defectos

Exanimación / evaluación y registro de problemas en reuniones o monitoreo de cualquier grupo de comunicaciones electrónico 5. Reelaboración o Solución de defectos encontrados ( realizados comúnmente por el autor) o Registro de estados actualizados de defectos ( en revisiones formales) 6. Seguimiento o Revisión de que se han tratado defectos o Recopilación de métricas o Revisión de criterios de salida ( para tipos de revisión más formal) o

3.2.2 Funciones y Responsabilidades (K1) Una revisión formal común incluirá las siguientes funciones: o Gerente: decide la ejecución de revisiones, distribuye tiempo en la programación del proyecto y determina si se han cumplido los objetivos de revisión. o Moderador: la persona que guía la revisión del documento o conjunto de documentos, incluyendo la planeación de revisión, realizar reuniones, y seguimiento posterior a reuniones. Si es necesario, el moderador podrá mediar entre varios puntos de vista y generalmente es la persona responsable del éxito de la revisión. o Autor: el escritor o persona con la responsabilidad principal de documento (s) a revisarse. o Revisores: personas con experiencia técnica o comerciales específicas (también denominados correctores o inspectores) quienes después de la preparación necesaria, identifiquen y describan resultados (por ejemplo, defectos) en el producto conforme la revisión. deben escogerse los revisadores para representar diferentes perspectivas y funciones en el proceso de revisión, y deben participar en las reuniones de revisión. o Notario - escriba ( o registrador): documenta todos los asuntos, problemas y abiertamente señala que se identificaron en la reunión: La observación de los productos software o productos de trabajo relacionados desde distintas perspectivas y uso de listas, se pueden realizar revisiones más efectivas y eficientes. Por ejemplo, una lista basada en varias perspectivas como el usuario, mantenedor, probador u operaciones o una lista de problemas de requisitos comunes pueden ayudar a descubrir problemas no detectados con anterioridad. 3.2.3 Tipos de Revisiones (K2) Un solo producto software o producto de trabajo relacionado puede estar sujeto a varias revisiones. Si se utiliza más de un tipo de revisión, puede variar el orden. Por ejemplo, se puede llevar a cabo una revisión informal antes de una revisión técnica; o se puede realizar una inspección sobre una especificación de requisitos antes de hacer el recorrido con los clientes. Las siguientes son las principales características, opciones y propósitos de los tipos de revisión comunes:

Revisión informal o Proceso no formal o Se realiza mediante una programación en pareja o liderazgo técnico que revise diseños y códigos (La Programación en Pareja (o "Pair Programming" en inglés) requiere que dos programadores participen en un esfuerzo combinado de desarrollo en un sitio de trabajo) o Se pueden documentar los resultados o Variación de utilidad dependiendo de los revisores o Propósito principal: forma de bajo costo para obtener beneficios Recorrido Realizar una reunión por parte del autor Se realiza mediante escenarios, simulacros, participación de grupo Sesiones abiertas  Preparación de pre-reuniones opcionales de revisores  Preparación opcional de un reporte de revisión que incluya una lista de resultados o Notario - escribiente opcionales (que no sea el autor) o Puede que varíe de muy informal a muy formal o Propósito principal: Aprender, comprender, encontrar defectos o o o

Revisión técnica o Proceso documentado, de detección de defectos definido que incluya compañeros y expertos técnicos con participación opcional de gerencia o Se puede desarrollar como una revisión hecha por expertos sin la participación de la gerencia o Preferiblemente dirigido por un moderador capacitado (no el autor) o Preparación de pre-reuniones por parte de revisores o Uso opcional de listas o Preparación de un reporte de revisión que incluya la lista de resultados, el veredicto si el producto software cumple sus requisitos y cuando corresponda, recomendaciones relacionadas con los resultados o Puede variar en la práctica de demasiado informal a muy formal o Propósitos principales: discusiones, toma de decisiones, evaluación de alternativas, encontrar defectos, solución de problemas técnicos, y revisión de conformidad con las especificaciones, planes, normas y estándares. Inspección o o o o

Guiada por un moderador capacitado (no el autor) Dirigida normalmente como una exanimación hecha por expertos Funciones definidas Incluye recopilación de métricas

o o o o o o o

Proceso formal basado en normas y listas Criterios de entrada y salida determinados para la aceptación del producto software Preparación de pre-reuniones Reporte de inspección que incluya una lista de resultados Proceso formal de seguimiento ( con componentes opcionales de procesos de perfeccionamiento) Lector opcional Propósito principal: encontrar defectos

Los recorridos, revisiones técnicas e inspecciones se pueden desarrollar en un grupo de colegas, es decir, colegas del mismo nivel organizacional. Este tipo de revisión se denomina “revisión entre colegas”. 3.2.4 Los factores de éxito para la revisión (K2) Los factores de éxito para la revisión incluyen: o Cada revisión tiene objetivos claramente predefinidos o Participación de la gente apropiada para los objetivos de revisión o Los probadores se consideran revisores que contribuyen a la revisión y además aprenden del producto, lo que les permite preparar pruebas con anticipación o Los defectos encontrados se presentados y expresados objetivamente o se tratan los problemas del personal y aspectos psicológicos ( por ejemplo, hacer que sea una experiencia positiva para el autor) o la revisión se realiza en un ambiente de confianza, el resultado no se utilizara para la evaluación de participantes o Se aplican las técnicas de revisión que sean pertinentes para lograr los objetivos y al tipo y nivel de productos software de trabajo y revisores o Se utilizan listas o funciones si es apropiado para incrementar la efectividad en la identificación de defectos o Se da capacitación en las técnicas de revisión, especialmente en las técnicas más formales como la inspección o La gerencia apoya un buen proceso de revisión (por ejemplo, la incorporación de tiempo adecuado para actividades de revisión en programas de proyecto) o Existe un énfasis en el aprendizaje y proceso de perfeccionamiento 3.3

Análisis Estático con Herramientas (K2)

20 minutes

Términos Compilador, complejidad, flujo de control, flujo de datos, análisis estático Antecedentes El objetivo del análisis estático es encontrar defectos en el código fuente de software y modelos software. El análisis estático se desarrolla sin realmente ejecutar el software que

está examinando la herramienta; las pruebas dinámicas ejecutan el código del software. El análisis estático puede localizar los defectos que son difíciles de encontrar en las pruebas dinámicas. Al igual que en las revisiones, el análisis estático encuentra defectos en lugar de fallas. Las herramientas del análisis estático analizan el código del programa (por ejemplo, flujo de control y flujo de datos), así como mensajes generadas como HTML y XML. El valor del análisis estático es: o Detección temprana de defectos antes de ejecutar la prueba o Advertencia temprana sobre aspectos sospechosos del código o diseño por el cálculo de métricas, como una medida de alta complejidad o Identificación de defectos que no se encuentran fácilmente en las pruebas dinámicas o Detectar dependencias e inconsistencias en los modelos software como vínculos o Mantenimiento perfeccionado del código y diseño o Prevención de defectos, si se aprenden lecciones en la etapa de desarrollo Los Defectos comunes que descubre el análisis estático incluyen lo siguiente: o Referencia de una variable con un valor no definido o Interfaces inconsistentes entre módulos y componentes o Variables que no se utilizan o se declaran inapropiadamente o Código faltante o erróneo ( circuitos potencialmente infinitos) o Construcciones demasiado complicadas o Violaciones de las normas de programación o Vulnerabilidades de seguridad o Errores de sintaxis del código y modelos software Las herramientas del análisis estático se utilizan comúnmente por parte de desarrolladores (revisión en contraste con normas predefinidas o estándares de programación) antes y durante las pruebas del componente e integración o cuando se ingresa el código a las herramientas de manejo del configuración y por parte de los diseñadores durante la formación del software. Las herramientas del análisis estático pueden producir un gran número de mensajes de advertencia que necesitan manejarse correctamente que permita el uso más efectivo de la herramienta. Los compiladores pueden ofrecer soporte en al análisis estático, incluyendo el cálculo de métricas Referencias 3.2 IEEE 1028 3.2.2 Gilb, 1993, van Veenendaal, 2004 3.2.4 Gilb, 1993, IEEE 1028 3.3 van Veenendaal, 2004

4.

Técnicas de diseño de Prueba (K4)

285 Minutos

Objetivos de Estudio para técnicas de diseño de prueba

Los objetivos identifican lo que se podrá hacer tras la finalización de cada modulo 4.1 Proceso de desarrollo de testing (K3) LO-4.1.1 Establecer la diferencia entre una especificación de diseño de prueba, especificación de caso de prueba y especificación de procedimiento de prueba (K2) LO-4.1.2 Comparar los términos condiciones de prueba, caso de prueba y procedimiento de prueba (K2) LO-4.1.3 Evaluar la calidad de los casos de pruebas en términos de una clara trazabilidad de requisitos y resultados esperados LO-4.1.4 Transformar casos de pruebas en una especificación de procedimiento de prueba bien estructurado a un nivel adecuado detalle pertinente al conocimiento de los probadores (K3) 4.2 Categorías de las Técnicas de Diseño de Prueba (K2) LO-4.2.1 Recordar las razones por las cuales las técnicas de diseño de testing basadas en especificaciones (caja negra) y basadas en estructuras (caja blanca) son útiles y nombrar las técnicas comunes para cada una (K1) LO-4.2.2 Explicar las características, semejanzas y diferencias entre pruebas basadas en especificaciones, pruebas basadas en estructuras y pruebas basadas en experiencia (K2) 4.3 Técnicas basadas en especificaciones o Caja negra (K3) LO-4.3.1 Redactar casos de pruebas a partir de los modelos del software proporcionados utilizando una división equivalente, análisis de valor límite, tablas de decisión y diagramas / tablas de transición de estado. (K3) LO-4.3.2 Explicar el propósito principal de cada una de las cuatro técnicas de testing, que nivel y tipo de prueba podría utilizar la técnica, y como se puede medir la cobertura (K2) LO-4.3.3 Explicar el concepto de pruebas de casos de uso y sus beneficios 4.4 Técnicas basadas en estructuras o Caja Blanca LO-4.4.1 Describir el concepto y valor de la cobertura de código (K2) LO-4.4.2 Explicar los conceptos de cobertura de estado y decisiones y dar razones por las cuales estos conceptos también se pueden utilizar a niveles de prueba en lugar de pruebas del componente (por ejemplo, sobre procedimientos empresariales en el nivel del sistema (K2) LO-4.4.3 Redactar casos de prueba a partir de flujos de control proporcionados utilizando técnicas de diseño de pruebas de estado y decisión (K3) LO-4.4.4 Cobertura de estado y decisión para totalidad respecto a los criterios de salida definidos 4.5 Técnicas basadas en Experiencia (K2) LO-4.5.1 Recordar los motivos para escribir los casos de pruebas basados en la intuición, experiencia y conocimiento respecto a defectos comunes (K1) LO-4.5.2 Comparar las técnicas basadas en experiencia con técnicas de pruebas basadas en especificaciones

4.6 Selección de Técnicas de Prueba (K2) LO-4.6.1 Clasificar las técnicas de diseño de acuerdo a sus capacidades en un contexto determinado, para las bases de pruebas modelos y características de software respectivos (K2) 4.1

El Proceso de Desarrollo de Prueba(K3)

15 minutos

Términos Especificación de caso de pruebas, diseño de prueba, programación de ejecución de prueba, especificación del procedimiento de prueba, script de prueba, trazabilidad. Antecedentes El Proceso de desarrollo de prueba descrito en esta sección se puede realizar de diferentes maneras, a partir de una manera informal con poca o ningún tipo de documentación a muy formal (tal como se describe más adelante). El nivel de formalidad depende del contexto de la prueba, que incluye la madurez de la prueba y procesos de desarrollo, limitaciones de tiempo, requisitos de seguridad o normativos y personas involucradas. Durante los análisis de prueba, se analiza la documentación de bases de prueba para determinar que se debe probar, es decir identificar las condiciones de prueba. Una condición de prueba se define como un elemento o caso que se podría verificar por uno o más casos de prueba (por ejemplo, una función, transacción, elemento de calidad de característica o estructural). El establecimiento de trazabilidad a partir de las condiciones de prueba nuevamente a las especificaciones y requisitos permite un análisis de impacto efectivo cuando cambian los requisitos y se determina la cobertura de requisitos en un conjunto de pruebas. En un análisis de prueba se implementa un enfoque de prueba detallado con el fin de escoger las técnicas de diseño de pruebas a utilizar, basadas, entre otras en consideraciones, riesgos identificados (ver capítulo 5 para más información sobre análisis de riesgo). En el diseño de prueba se crean y especifican los casos de prueba y datos de prueba. Un caso de prueba consiste en un conjunto de valores de entrada, precondiciones de ejecución, resultados esperados y post condiciones de ejecución, definida que cubra ciertos objetivos de prueba o condiciones de pruebas. El Estándar para la Documentación de Prueba de Software (Standard for Software Test Documentation’) (IEEE STD 829-1998) describe el contenido de las especificaciones de diseño de prueba (que contienen condiciones de prueba) y especificaciones de casos de prueba. Los resultados esperados se deben producir como parte de la especificación de un caso de prueba e incluir salidas, cambios a la información y estados, y otras consecuencias de la prueba. Si no se han definido los resultados esperados, un resultado plausible, pero erróneo, se puede interpretar como correcto. Los resultados deben definirse preferiblemente antes de la ejecución de la prueba.

En la implementación de la prueba, se desarrollan, implementan, se da prioridad y se organizan los casos de prueba en la especificación de procedimiento de prueba (IEEE STD 829-1998). El procedimiento de prueba específica la secuencia de acciones para la ejecución de una prueba. Si una prueba se realiza con una herramienta de ejecución de prueba, se especifica la secuencia de acciones en un script de prueba (que es un procedimiento de prueba automatizado). Varios de los procedimientos de prueba y script de prueba automatizados posteriormente formados en un programa de ejecución de prueba que define el orden en el cual se ejecutan varios procedimientos de prueba y posibles scripts de prueba automatizados. El programa de ejecución de prueba tomara en cuenta dichos factores como pruebas de regresión, prioridad y dependencias técnicas y lógicas. 4.2 (K2)

Categorías de las Técnicas de Diseño de Pruebas

15 Minutos

Términos Técnica de diseño de prueba de caja negra, experiencia basada en técnicas de diseño de pruebas, técnica de diseño o de prueba, técnica de diseño de prueba de caja blanca. Antecedentes El propósito de una técnica de diseño de prueba es identificar condiciones de prueba, casos de prueba y datos de prueba. Es una distinción clásica que señala técnicas de prueba como caja negra y caja blanca. Las técnicas de diseño de prueba de caja negra (también denominada técnicas basadas en especificación) son una forma de derivar y seleccionar condiciones de prueba, casos de prueba o datos de prueba en un análisis de documentación de bases de prueba. Lo anterior incluye pruebas funcionales y no funcionales. Las pruebas de caja negra (Black-box testing), por definición, no utiliza ningún tipo de información respecto a la estructura interna del componente o sistema que debe probarse. Las técnicas de diseño de prueba (también denominadas técnicas estructurales o basadas en estructura) se basan en un análisis de la estructura del componente o sistema. Las pruebas de caja negra y blanca (Black-box and White-box testing) también pueden combinarse con técnicas basadas en experiencia para así tomar ventaja de la experiencia de desarrolladores, probadores y usuarios para determinar lo de se debe probar. Algunas técnicas claramente caen en una sola categoría; otras tienen elementos de más de una categoría. Este programa se refiere a las técnicas de diseño de prueba basadas en especificaciones como técnicas de caja negra y técnicas de diseño de prueba basadas en estructuras como técnicas de caja blanca. Adicionalmente, se cubren las técnicas de diseño de pruebas basadas en experiencia.

Las características comunes de las técnicas de diseño de pruebas basadas en la especificación incluyen lo siguiente: o Modelos formales o informales, se utilizan para la especificación del problema a resolver, el software o sus componentes o Se pueden derivar los casos de prueba sistemáticamente de estos modelos Las características comunes de las técnicas de diseño de prueba basadas en la estructura incluyen lo siguiente: o La información de cómo se construye el software se utiliza para derivar los casos de prueba (por ejemplo, el código e información detallada de diseño) o El grado de cobertura del software se puede medir para los casos de prueba vigentes y los casos de pruebas adicionales pueden derivarse sistemáticamente para aumentar el cubrimiento Las características comunes de las técnicas de diseño de prueba basadas en la experiencia incluyen lo siguiente: o El conocimiento y experiencia de la gente se utiliza para derivar los casos de pruebas o Es una fuente de información el conocimiento de probadores, desarrolladores usuarios y otras partes interesadas respecto al software, su uso y entorno o Otra fuente de información es conocer los probables defectos y su distribución

4.3 Técnicas basadas en la especificación o Caja negra (K3)

150 minutos

Términos Análisis de valor límite, testing de tablas de decisión, división de equivalencia, pruebas de transición de estado pruebas de casos de uso. 4.3.1 División de Equivalencia (K3) En la división de equivalencia, las entradas al software o sistema se dividen en grupos que se espera muestren un comportamiento similar, así que se deben procesar de la misma manera. Las divisiones de equivalencia (o clases) pueden encontrarse para información valida, es decir, valores que deben aceptarse y datos inválidos, y los valores que deben rechazarse. También se pueden identificar las divisiones para salidas, valores internos, valores relacionados con el tiempo (por ejemplo, antes y después de un caso) y para los parámetros de interface (por ejemplo, componentes integrados que se están probando durante el testing de integración). Se pueden diseñar pruebas que cubran todas las divisiones validas e invalidas. Las divisiones de equivalencia son pertinentes en todos los niveles de pruebas.

La división de equivalencia se puede utilizar para lograr los objetivos de cobertura de entrada y salida. Se puede aplicar al aporte humano, entrada por interfaces a un sistema o parámetros de interface en pruebas de integración. 4.3.2 Análisis de Valor Limite (K3) El comportamiento al límite de cada división de equivalencia es más probable que sea incorrecta que el comportamiento dentro de la división de manera tal que los limites son una área donde las pruebas probablemente produzcan defectos. Los valores máximos y mínimos de una división son sus valores límite. Un valor límite para una división valida es un valor límite valido; el límite de una división inválida es un valor límite inválido. Se pueden diseñar las pruebas para cubrir valores límites validos e inválidos. Cuando se diseñan casos de pruebas, se elige una prueba para cada valor límite. El análisis de valor límite se puede aplicar en todos los niveles de prueba. Es relativamente fácil de aplicar y su capacidad de encontrar defectos es alta. Las especificaciones detalladas son útiles en la determinación de límites interesantes. Frecuentemente se considera esta técnica como una extensión de división de equivalencia u otras técnicas de diseño de prueba de caja negra. Se puede utilizar en clases de equivalencia para el ingreso del usuario en la pantalla así como por ejemplo en periodos de prueba (por ejemplo, tiempo de espera, requisitos de velocidad transaccional) o clasificación de tablas (por ejemplo, tamaño de tablas es de 256*256) 4.3.3 Pruebas de Tablas de Decisión (K3) Las tablas de decisión son una buena manera de capturar los requisitos del sistema que contienen condiciones lógicas y documentar el diseño del sistema interno. Se pueden utilizar para registrar normas empresariales complejas que debe implementar un sistema. Cuando se crean tablas de decisión, se analiza la especificación y se identifican las condiciones y acciones del sistema. Las condiciones y acciones de ingreso se indican comúnmente de forman que sean verdaderas o falsas (Boolean). La tabla de decisión contiene las condiciones de activación, frecuentemente combinaciones de falso y verdadero para todas las condiciones de ingreso acciones resultantes en cada combinación de condiciones. Cada columna de la tabla corresponde a una norma empresarial que define una combinación única de condiciones y que resulta en la ejecución de acciones asociadas con dicha norma. La cobertura estándar utilizada comúnmente con las pruebas de tabla de decisión debe tener por lo menos una prueba por columna en la tabla que normalmente involucra la cobertura de todas las combinaciones de las condiciones de activación. La fortaleza de las pruebas de tabla de decisión genera combinaciones de las condiciones que de otra manera no podrían haberse ejercido durante la prueba. Se puede aplicar en todas las situaciones cuando la acción del software depende de varias decisiones lógicas. 4.3.4 Pruebas de Transición de Estado Un sistema puede presentar distintas respuestas dependiendo de las condiciones vigentes o historia anterior (su estado). En este caso, el aspecto del sistema puede mostrarse con

un diagrama de transición de estado. Le permite al probador observar el sistema en términos de sus estados, transiciones entre estados, ingresos o casos que activan los cambios de estado (transiciones) y las acciones que puedan resultar de aquellas transiciones. Los estados del sistema u objetos con forma la prueba se dan por separado, son identificables y en números finitos. Una tabla de estado muestra la relación entre los estados e ingresos y pueden resaltar las posibles transiciones que sean inválidas. Se pueden diseñar pruebas que cubran una secuencia normal de estados, todos los estados, que ejerzan todas las transiciones, secuencias específicas de transiciones o que prueben transiciones inválidas. Se utilizan demasiado las pruebas de transición dentro de la industria del software integrado y automatización técnica en general. Sin embargo, la técnica también es adecuada para la formación de un objeto de negocio que tenga estados específicos o probar flujos de dialogo de pantallas (por ejemplo, en aplicaciones de internet o escenarios empresariales). 4.3.5 Pruebas de Caso de Uso (K2) Se pueden derivar las pruebas de los casos de uso. Caso de use describe las interacciones entre los actores (usuarios o sistemas) que producen un resultado del valor al usuario del sistema o el cliente. Se pueden describir los casos de uso a un nivel abstracto (caso de uso empresarial, technology-free, nivel de proceso empresarial) o a nivel del sistema (caso de uso del sistema en el nivel de funcionalidad del sistema). Cada caso de uso tiene requisitos que necesitan cumplirse para que el caso de uso funcione exitosamente. Cada caso de uso termina con post condiciones que son los resultados visibles y estado final del sistema después de haberse completado el caso de uso. Un caso de uso generalmente tiene una escenario principal (es decir, muy probable) y escenarios alternativos. Los casos de uso describen los “flujos de procesos” por medio de un sistema basado en su posible uso real, de manera que los casos de prueba derivados de los casos de uso, son más útiles en descubrir defectos en los flujos de proceso durante el uso del sistema en el mundo real. Los casos de uso son muy útiles para el diseño de pruebas de aceptación con la participación del cliente / usuario. También ayudan a descubrir defectos de integración causados por la interacción e interferencia de distintos componentes, que no podría ver una prueba del componente. El diseño de casos de prueba a partir de casos de uso se puede combinar con otras técnicas de prueba basadas en la especificación.

4.4 Técnicas basadas en la estructura o de Caja blanca (K4)

60 minutos

Términos Cubrimiento de código, cubrimiento de decisión, cubrimiento de instrucciones, pruebas basadas en la estructura Antecedentes Las pruebas basadas en la estructura o de Caja blanca se basan en una estructura identificas del software o del sistema, tal como se observa en los siguientes ejemplos: o Nivel del componente: la estructura de un componente software, es decir, instrucciones, decisiones, sedes o incluso distintos modelos o Nivel de integración: la estructura puede ser un call tree ( un diagrama en los cuales los módulos se comunican con otros módulos ) o Nivel del sistema: la estructura puede ser una estructura del menú, proceso comercial o estructura de página web En esta sección se discuten tres técnicas de diseño de prueba de relacionado con el código para en cubrimiento de código, basadas en instrucciones sedes y decisiones. Para las pruebas de decisión, se puede utilizar un diagrama de flujo de control para visualizar las alternativas de cada decisión. 4.4.1 Pruebas y cobertura de instrucciones (K4) En las pruebas del componente, la cobertura de instrucción es la evaluación del porcentaje de las instrucciones ejecutables que un conjunto de casos de prueba han ejercido. La técnica de pruebas de instrucción deriva casos de prueba que ejecuten instrucciones específicas, normalmente que aumenten el cubrimiento de instrucción Se determina el cubrimiento de instrucción por el número de instrucciones ejecutables que cubren (diseñan o ejecutan) los casos de prueba divididas por el número de instrucciones ejecutables en el código conforme la prueba. 4.4.2 Pruebas de Decisión y Cobertura (K4) EL cubrimiento de decisión relacionado con las pruebas branch (sede), es la evaluación del porcentaje de resultados de decisión (por ejemplo, opciones de Falso y Verdadero de una evaluación IF) que un conjunto de pruebas han ejercido. La técnica de pruebas de decisión deriva casos de prueba que ejecutan resultados de decisión específica. Branches se origina de los puntos de decisión en código y muestran la transferencia de control a diferentes ubicaciones en el código. La cobertura de decisión se determina por el número de todos los resultados de decisión cubiertos (diseñados o ejecutados) por los casos de prueba que se dividen por el número de todos los resultados de decisión posibles en el código conforme la prueba.

Las pruebas de decisión son una forma de prueba de flujo de control ya que sigue un flujo de control por medio de los puntos de decisión. El cubrimiento de decisión es más fuerte que el cubrimiento de instrucción; el 100% de cubrimiento de decisión garantiza un 100% de cubrimiento de instrucción, pero no viceversa. 4.4.3 Otras Técnicas basadas en la Estructura (K1) Existen mayores niveles de cobertura estructural que van más allá de la cobertura de decisión, por ejemplo, cobertura de condición y múltiple cobertura de condición. También se puede aplicar el concepto de cobertura en otros niveles de prueba. Por ejemplo, a nivel de integración, el porcentaje de modulos, components o clases que se han ejercido por un conjunto de caso de pruebas se podría expresar como modulo, componente o cobertura de clase. La herramienta de soporte es útil para las pruebas estructurales del código. 4.5

Técnicas Basadas en la experiencia (K2)

30 Minutos

Términos Testing exploratorio, (falla) ataque Antecedentes En las pruebas basadas en la experiencia se derivan pruebas de la capacidad e intuición del probador así como su experiencia con aplicaciones y tecnologías similares. Cuando se aumentaban las técnicas sistemáticas, dichas técnicas pueden ser útiles en la identificación de pruebas especiales que no se capturan fácilmente por parte de las técnicas formales, especialmente cuando se aplican después de enfoques más formales. Sin embargo, esta técnica puede ceder ampliamente variando los grados de efectividad, dependiendo de la experiencia del probador. Una técnica basada en la experiencia normalmente utilizada, es un error guessing (método de prueba en el cual se utilizan casos de prueba para encontrar virus en programas establecidos basados en la experiencia en pruebas anteriores). Generalmente los probadores anticipan defectos basándose en la experiencia. Un enfoque estructurado a la técnica de error guessing es enumerar una lista de posibles defectos y diseñar pruebas que ataquen estos defectos. Este enfoque sistemático se denomina fault attack. Estas listas de defectos y fallas se pueden construir basadas en la experiencia, información disponible sobre defectos y fallas y de conocimiento común de las razones por las que falla el software. Las pruebas exploratorias son un diseño de prueba concurrente, ejecución de prueba, test logging, y aprendizaje, basado en un test charter que contenga objetivos de prueba y se llevan a cabo en espacios de tiempo. Es un enfoque que es útil donde haya especificaciones pocas o inadecuadas y fuerte presión de tiempo o con el fin de aumentar o complementar otras pruebas más formales. Pueden servir estas pruebas para controlar el proceso de prueba que ayude a garantizar que se encuentren los defectos más graves.

4.6

Selección de Técnicas de Prueba (K2)

15 minutos

Términos No hay términos específicos Antecedentes La elección de cuales técnicas de prueba se deben utilizar, depende de un numero de factores que incluyen el tipo de sistema, estándares normativos, requisitos del cliente o contractuales, nivel de riesgo, tipo de riesgo, objetivo de prueba, documentación disponible, conocimiento de los probadores, tiempo y presupuesto, ciclo de vida del desarrollo, modelos de caso de uso y experiencia previa con tipos de defectos encontrados. Algunas técnicas son más aplicables en algunas situaciones y niveles de prueba; otras son aplicables a todos los niveles de prueba. Cuando se crean casos de prueba, los probadores generalmente utilizan una combinación de técnicas de prueba incluyendo técnicas de proceso, normas y basadas en datos que garanticen un cubrimiento adecuado del objeto conforme la prueba. Referencias 4.1 Craig, 2002, Hetzel, 1988, IEEE STD 829-1998 4.2 Beizer, 1990, Copeland, 2004 4.3.1 Copeland, 2004, Myers, 1979 4.3.2 Copeland, 2004, Myers, 1979 4.3.3 Beizer, 1990, Copeland, 2004 4.3.4 Beizer, 1990, Copeland, 2004 4.3.5 Copeland, 2004 4.4.3 Beizer, 1990, Copeland, 2004 4.5 Kaner, 2002 4.6 Beizer, 1990, Copeland, 2004 5.

Manejo de Prueba (K3)

170 minutos

Objetivos de Estudio para el Manejo de Prueba 5.1 Organización de Prueba (K2) LO-5.1.1 Reconocer la importancia de pruebas independientes (K1) LO-5.1.2 Explicar los beneficios e inconvenientes de pruebas independientes en una organización (K2) LO-5.1.3 Reconocer los distintos miembros del equipo para tenerlos en cuenta en la creación de un equipo de prueba (K1) LO-5.1.4 Recordar las tareas de un líder y probador común (K1) 5.2 Planeación y Cálculo de Prueba (K3) LO-5.2.1 Reconocer los distintos niveles y objetivos de la planeación de prueba (k1) LO-5.2.2 Resumir el propósito y contenido del plan de prueba, especificación de diseño

de prueba y documentos de procedimiento de prueba de acuerdo al Estándar para Documentación de Software de Prueba (IEEE Std 829-1998) (K2) LO-5.2.3 Establecer la diferencia entre los enfoques de prueba conceptualmente diferentes como lo es el analítico, basado en modelos, metódico, proceso/estándar, dinámico/ heurístico, consultivo y contrario a regresión (K2) LO-5.2.4 Establecer la diferencia entre el objeto de la planeación de prueba en un sistema y ejecución de programación de pruebas (K2) LO-5.2.5 Redactar un programa de ejecución e prueba para un conjunto de casos de pruebas, teniendo en cuenta la prioridad y dependencias técnicas y lógicas (K3) LO-5.2.6 Hacer una lista de preparación de pruebas y actividades de ejecución que deben tenerse en cuenta durante la planeación de pruebas (K1) LO-5.2.7 Recordar factores comunes que tienen influencia en el esfuerzo relacionado con pruebas (K1) LO-5.2.8 Establecer la diferencia entre dos enfoques de cálculos conceptualmente diferentes: el enfoque basado en métricas y el enfoque basado en expertos (K2) LO-5.2.9 Reconocer / justificar criterios adecuados de entrada y salida en niveles específicos de prueba y grupos de casos de prueba (por ejemplo, en pruebas de integración, pruebas de aceptación o casos de prueba en pruebas de uso) (K2) 5.3 Seguimiento y Control del Progreso de Prueba (2) LO-5.3.1 Recordar las métricas comunes utilizadas para hacer seguimiento de la preparación y ejecución de pruebas (K1) LO-5.3.2 Explicar y comparar métricas de prueba para reportar pruebas y control pruebas (por ejemplo, defectos encontrados y solucionados, pruebas aprobadas y perdidas) relacionado al propósito y uso (K2) LO-5.3.3 Resumir el propósito y contenido del documento resumen del reporte de prueba de acuerdo al “Standard for Software Test Documentation’ (IEEE Std 829-1998) (K2) 5.4 Manejo de configuración (K2) LO-5.4.1 Resumir como el manejo de configuración respalda las pruebas (K2) 5.5 Riesgo y Pruebas (K2) LO-5.5.1 Describir un riesgo como un posible problema que podría amenazar el logro de uno o más objetivos del proyecto de la partes interesadas (K2) LO-5.5.2 Recordar que el nivel de riesgo se determina por probabilidad (que pueda suceder) e impacto (daños que resulten en caso de suceder) (K1) LO-5.5.3 Establecer la diferencia entre los riesgos del proyecto y producto (K1) LO-5.5.4 Reconocer los riesgos comunes del producto y proyecto (K2) LO-5.5.5 Describir con ejemplos como se puede utilizar el análisis de riesgo y manejo de riesgo en la planeación de pruebas. 5.6 Manejo de Incidentes (K3) LO-5.6.1 Reconocer el contenido de un reporte de incidentes de acuerdo al Standard for Software Test Documentation’ (IEEE Std 829-1998) (K1) LO-5.6.2 Redactar un reporte de incidentes que cubran la observación de una falla durante la prueba (K3)

5.1

Organización de Pruebas (K2)

30 minutos

Términos Probador, líder de pruebas, gerente de pruebas 5.1.1 Organización e independencia de Prueba (K2) La efectividad en encontrar defectos por medio de pruebas y revisiones se puede mejorar con el uso de probadores independientes. Las opciones de independencia incluyen lo siguiente: o No hay probadores independientes, desarrolladores prueban su propio código o Probadores independientes en equipos de desarrollo o Un equipo de prueba independiente o un grupo en la organización que le reporte a la gerencia del proyecto o gerencia ejecutiva. o Probadores independientes a partir de la organización empresarial o comunidad del usuario o Especialistas de prueba independiente en tipos específicos de pruebas como probadores de uso, probadores de seguridad o probadores de certificación (quienes certifican un producto software en relación a los estándares y normas) o Probadores independientes contratados o externos a la organización En proyectos grandes, complejos o críticos para la seguridad, es mucho mejor tener niveles múltiples de pruebas con algunos o todos los niveles que realizaron probadores independientes. El personal de desarrollo podrá participar en las pruebas, especialmente en niveles inferiores, pero la falta de objetividad frecuentemente limita su efectividad. Los probadores independientes tendrán la autoridad de solicitar definir procesos de prueba y normas, pero deben asumir funciones relacionadas con el proceso únicamente en la presencia de un claro mandado de gerencia. Los beneficios de independencia incluyen lo siguiente: o Los probadores independientes ven otros y distintos defectos que son imparciales o Un probador independiente puede verificar suposiciones que han hecho personas durante la especificación e implementación del sistema Las desventajas incluyen lo siguiente: o Aislamiento del equipo de desarrollo ( si se trata como independencia total) o Los desarrolladores podrían perder el sentido de responsabilidad en cuanto a la calidad o Los probadores independientes pueden verse como obstáculos o ser culpables por retrasos en el lanzamiento. Las tareas de prueba se pueden realizar por personas con una función de prueba específica, u otra persona que desempeñe otra función como un gerente de proyecto, gerente de

calidad, desarrollador, un experto en negocios y en el sector, infraestructura u operaciones IT. 5.1.2 Tareas de un Lider de Pruebas y Probador (K1) En este programa se cubren dos puestos de prueba, líder de pruebas y probador. Las actividades y tareas que realizan personal en estas dos funciones dependen del contexto del proyecto y producto, el personal en distintas funciones y la organización. Algunas veces se le denomina a un líder de prueba un gerente de prueba o coordinador de prueba. La función del líder de pruebas puede desarrollarse por un gerente de proyectos, gerente de desarrollo, gerente de garantía de calidad o el gerente de un grupo de prueba. En grupos más grandes, pueden haber dos puestos de trabajo: líder de pruebas y gerente de pruebas. Comúnmente el líder planea, monitorea y controla las actividades de pruebas y tareas como se define en la sección 1.4. Las tareas comunes de un líder de prueba son las siguientes: o Coordinar la estrategia de pruebas y realizar planeación con gerentes de proyectos y otras personas o Redactar o revisar una estrategia de pruebas en el proyecto así como una política de pruebas en la organización. o Contribuir la perspectiva de pruebas a otras actividades del proyecto como la planeación de integración o Planear pruebas teniendo en cuenta el contexto y comprendiendo los objetivos de las pruebas y riesgos que incluyen la selección de enfoques de prueba, calculando el tiempo, esfuerzo y costo de las pruebas, adquiriendo recursos, definiendo niveles y ciclos de prueba y planeación en la gestión de incidentes o Iniciar la especificación, preparación, implementación y ejecución de pruebas, monitorear los resultados de las prueba y revisar los criterios de salida o Adaptar la planeación basada en los resultados de las pruebas y su progreso (que algunas veces se documentan en los reportes de estados) y tomar las medidas necesarias para compensar problemas causados. o Configurar un manejo de configuración adecuado de testware para trazabilidad o Presentar métricas apropiadas para la medición del progreso de las pruebas y evaluación de calidad de las pruebas y el producto o Decidir lo que se debe automatizar, a que grado y como o Seleccionar herramientas que respalden las pruebas y organizar capacitaciones en el uso de herramientas para probadores o Decidir la implementación del entorno de las pruebas o Redactar reportes resumido de pruebas basados en la información recopilada en el proceso de pruebas Las tareas más comunes de un probador son las siguientes: o Revisar y contribuir planes de prueba

o o o o o o o o o

Analizar, revisar y evaluar requisitos, especificaciones y modelos para testabilidadcomprobabilidad Crear especificaciones de prueba Configurar el ambiente de prueba (frecuentemente coordinar la administración del sistema y manejo de la red) Preparar y adquirir datos de prueba Implementar pruebas en todos los niveles, ejecutar y registrar pruebas, evaluar los resultados y documentar desviaciones de los resultados esperados Utilizar administración de pruebas o herramientas de gestión y se requiere un monitoreo de pruebas Automatizar pruebas (pueden respaldarse por un desarrollador o un experto en automatización de pruebas) Medir el desempeño de los componentes y el sistema (si corresponde) Revisar pruebas desarrolladas por otras

La gente que trabaja en análisis de pruebas, diseño de pruebas, tipos de pruebas específicos o automatización de pruebas, pueden ser especialistas en estas funciones. Dependiendo del nivel de prueba y los riesgos relacionados con el producto y el proyecto, distintas personas pueden asumir la función de probadores, manteniendo el grado de independencia. Comúnmente, los probadores en niveles del componente e integración seria desarrolladores, probadores en el nivel de aceptación seria experto en negocios y usuarios y probador para pruebas de aceptación operativa serian operadores

5.2

Planeación de Pruebas y Calculo (K3)

40 minutos

Términos Enfoque de pruebas, estrategia de pruebas 5.2.1 Planeación de Pruebas (K2) Esta sección cubre el propósito de planeación de pruebas dentro de proyectos de desarrollo e implementación y actividades de mantenimiento. Se puede documentar la planeación en un plan de prueba maestro y en planes de prueba por separado en niveles de prueba como pruebas del sistema y de aceptación. El resumen de un documento de planeación de prueba se cubre por parte del ‘Standard for Software Test Documentation’ (IEEE Std 829-1998). La planeación está bajo la influencia de la política de prueba de la organización, el alcance de pruebas, objetivos, riesgos, limitaciones, criticidad, comprobabilidad y disponibilidad de recursos. A medida que progresan el proyecto y planeación de prueba, hay más información disponible y más detalles que se pueden incluir en el plan.

Esta planeación es una actividad continua y se desarrolla en los procesos del ciclo de vida y actividades. Se utiliza la retroalimentación de actividades de prueba para reconocer evolución de riesgos de manera que se pueda ajustar la planeación. 5.2.2 Actividades planeación de pruebas (K3) En todo un sistema o parte de un sistema se puede incluir en estas actividades: o Determinación del alcance y riesgos e identificación de los objetivos de pruebas o Definición de todo el enfoque de pruebas, que incluye la definición de niveles de prueba y criterios de entrada y salida o Integración y coordinación de las actividades de prueba en las actividades del ciclo de vida del software (adquisición, suministro, desarrollo, operación y mantenimiento) o Toma de decisiones de lo que se debe probar, que funciones desarrollaran las actividades de prueba, como se deben desarrollar las actividades y como se evaluaran los resultados de la prueba o Programación de los análisis de prueba y actividades de diseño o Programación de implementación, ejecución y evaluación de la prueba o Asignación de recursos en distintas actividades ya definidas o Definición de la cantidad, nivel de detalle, estructura y plantillas para la documentación de la prueba o Selección de métricas en el monitoreo y control de la preparación y ejecución de la prueba, solución de defectos y situaciones de riesgo o Configuración del nivel de detalles de procedimientos de la prueba con el fin de suministrar suficiente información que respalde la preparación y ejecución reproducible de prueba 5.2.3 Criterios de entrada (K2) Definen cuando iniciar las pruebas al principio de un nivel de prueba o cuando está listo un conjunto de pruebas Comúnmente estos criterios podrán cubrir lo siguiente: o Disponibilidad y preparación del entorno de la prueba o Preparación de herramienta de prueba en el entorno de la misma o Disponibilidad del código que se puede probar o Disponibilidad de datos de prueba 5.2.4 Criterios de salida (K2) Definen cuando detener las pruebas al final de un nivel de prueba cuando han logrado un objetivo específico un conjunto de pruebas Comúnmente o o o o

estos criterios podrán cubrir lo siguiente: Medidas rigurosas, como el cubrimiento del código, funcionalidad o riesgo Calculo de la densidad de defectos o medidas de confiabilidad Costos Riesgos residuales, como defectos sin solucionar o falta de cubrimiento de la prueba en algunas áreas o Programaciones como las que se basan en mercado en tiempo real

5.2.5 Calculo de la Prueba (K2) Los siguientes son dos enfoques en el cálculo de una prueba: o El enfoque basado en métricas: cálculo de esfuerzo de pruebas basado en métricas de proyectos antiguos o similares o valores comunes o Enfoque basado en recomendaciones expertas: cálculo de tareas basándose en caculos hechos por parte del propietario de tareas o expertos Una vez se calcule el esfuerzo de la prueba, se pueden identificar los recursos y elaborar una programación Este esfuerzo podrá depender de un número de factores que incluyen lo siguiente: o Características del producto: la calidad de la especificación y otra información utilizada en los modelos de la prueba (bases de la prueba), el tamaño del producto, la complejidad del dominio del problema, los requisitos de confiabilidad y seguridad y los requisito para documentación o Características del proceso de desarrollo: la estabilidad de la organización, herramientas utilizadas, proceso de la prueba, destrezas de la gente involucrada y presión de tiempo o El resultado de la prueba: el número de defectos y la cantidad de revisión requerida 5.2.6 Estrategia de la Prueba, Enfoque de la Prueba (K2) El enfoque de la prueba es la implementación de la estrategia de la prueba en un proyecto específico. El enfoque de la prueba se define y mejora en los planes de la prueba y diseño de la misma. Comúnmente incluye las decisiones tomadas basándose en el objetivo del proyecto (la prueba) y evaluación de riesgos. Es el punto de inicio para la planeación del proceso de la prueba, la selección de las técnicas de diseño de la prueba y tipos de la prueba que se deben aplicar y la definición de criterios de entrada y salida El enfoque seleccionado depende del contexto y podrá tener en cuenta riesgos, peligros y seguridad, recursos y destrezas disponibles, tecnología, origen del sistema (por ejemplo, a medida vs COTS) objetivos de la prueba y normas Los enfoques comunes incluyen lo siguiente: o Enfoques analíticos como pruebas basadas en riesgo cuando se dirigen las pruebas a áreas de mayor riesgo o Enfoques basados en modelos, como pruebas estocásticas que utilizan información estadística respecto a tasa de fallos (como modelos de crecimiento de confiabilidad) o uso ( perfiles operativos) o Enfoques metódicos, como los basados en fallas (error guessing y ataques de falla), basados en la experiencia, basados en listas de verificación y basados en características de calidad o Enfoques de proceso o de cumplimiento de normas como las que se especifican en las normas específicas de industria o varias metodologías flexibles o Enfoques dinámicos y heurísticos como pruebas exploratorias cuando las pruebas son más reactivos a casos que planeados previamente y cuando la ejecución y evaluación son tareas concurrentes o Enfoques de consultoría como aquellos en los cuales se dirige el cubrimiento de la

o

prueba principalmente por la asesoría y orientación de tecnología y /o expertos en dominio empresarial fuera del equipo de prueba Enfoques de regresión – aversos como aquellos que incluyen el reusó de material de prueba vigente, automatización extensiva de pruebas funcionales de regresión y conjunto estándar de prueba

Se podrán combinar distintos enfoques; por ejemplo, un enfoque dinámico basado en riesgos. 5.3 (K2)

Monitoreo y Control en el Proceso de la Prueba

20 minutos

Términos Densidad del defecto, porcentaje de fallas, control de la prueba, monitoreo de la prueba, informe de resumen de la prueba 5.3.1 Monitoreo Progreso de la Prueba (K1) El propósito de este monitoreo es dar retroalimentación y visibilidad respecto a las actividades de la prueba. La información que se debe monitorear podrá recopilarse manual o automáticamente y se podrá utilizar para medir los criterios de salida, como la cobertura. También se podrán utilizar las métricas para evaluar el progreso respecto a la programación y presupuesto planeado. Las métricas comunes de la prueba incluyen: o Porcentaje de trabajo realizado en la preparación de caso de la prueba (o el porcentaje de casos de la prueba planeados que se han preparado o Porcentaje del trabajo realizado en la preparación del entorno de la prueba o Ejecución caso de la prueba (número de casos de la prueba funcionando / sin funcionar y casos de prueba aprobados / fallidos) o Detectar información ( densidad del defecto, defectos encontrados y solucionados, porcentaje de fallas y resultados de pruebas hechas nuevamente) o Cobertura de la prueba de requisitos, riesgos o código o Confianza subjetiva de probadores en el producto o Fechas de objetivos de la prueba o Costos de pruebas que incluyen el costo comparado con el beneficio de encontrar el próximo defecto o dirigir la próxima prueba 5.3.2 Informe de la Prueba (K2) Se ocupa de resumir información respecto al esfuerzo hecho en pruebas incluyendo lo siguiente: o Lo que sucedió en un periodo de pruebas, como fechas, cuando se cumplieron los criterios de salida o Información y métricas analizadas que respalden recomendaciones y decisiones respecto a acciones futuras como una evaluación de defectos restantes, el beneficio económico de pruebas continuas, riesgos pendientes y el nivel de confianza en el software probado. El esbozo de un resumen del informe de la prueba se suministra en Standard for Software Test Documentation’ (IEEE Std 829 1998). Se deben recopilar las métricas durante y al final del nivel de la prueba con el fin de evaluar:

o o o

La adecuación de los objetivos de la prueba en ese nivel de prueba La adecuación de los enfoques de la prueba tomada La efectividad de las pruebas respecto a los objetivos

5.3.3 Control de la Prueba (K2) Describe todas las acciones de orientación y correctivas tomadas como resultado de la información y métricas recopiladas y reportadas. Las acciones podrán cubrir cualquier actividad de la prueba y podrá afectar cualquier actividad o tarea del ciclo de vida del software. Los ejemplos de acciones de control de la prueba incluyen lo siguiente o Tomar decisiones basándose en información tomada del monitoreo de la prueba o Darle prioridad nuevamente a las pruebas cuando ocurren un riesgo identificado ( un software entregado tarde) o Cambios en la programación de la prueba debido a la disponibilidad o no disponibilidad de un entorno de la prueba o La configuración de un criterio de entrada que requiere soluciones que se han probado nuevamente ( confirmación probada) por parte de un desarrollador antes de aceptarlos en una construcción

5.4

Gestión de Configuración (K2)

10 minutos

Términos Gestión de configuración, control de versión Antecedentes El propósito de la gestión es establecer y mantener la integridad de los productos (componentes, datos y documentación) del software o sistema por medio del ciclo de vida proyecto y producto Para las pruebas, la gestión de configuración podrá involucrarse garantizando lo siguiente: o Se identifican todas las partidas del testware, versión controlada, monitoreadas para cambios, relacionados entre sí y con las partidas de desarrollo (objetos de prueba) de manera que se pueda mantener la trazabilidad a través del proceso o Se hacen referencia inequívocamente a todos los documentos identificados y partidas del software en la documentación de la prueba Para el probador, la gestión de configuración ayuda a identificar únicamente (y a reproducir) la partida probada, documentos de la prueba, pruebas y harness de la prueba. En la planificación de la prueba los procedimientos e infraestructura (herramientas) de la gestión de configuración deben escogerse, documentarse e implementarse

5.5

Riesgo y pruebas (K2)

30 minutos

Términos Riesgo del Producto, riesgo del proyecto, risk, pruebas basadas en riesgo Antecedentes Se puede definir el riesgo como la chance de haber un caso, peligro, amenaza o situación que ocurre o resulta en consecuencias no deseables o problema potencial. El nivel de riesgo se determinara por la probabilidad de un caso adverso que ocurra y el impacto (el daño que resulte de dicho caso). 5.5.1 Riesgos del Proyecto (K2) Son los riesgos que rodean la capacidad del Proyecto para entregar sus objetivos, como lo son: o Factores organizacionales: Destreza, capacitación y escasez de personal Asuntos del personal Asuntos de políticas como: Problemas con los probadores al comunicar sus necesidades y resultados de prueba Fallas hechas por el equipo al hacer seguimiento de información encontrada en las pruebas y revisiones (por ejemplo, que no haya perfeccionamiento de desarrollo y prácticas de pruebas) Mal comportamiento respecto a las expectativas de las pruebas (por ejemplo no apreciar el valor de encontrar defectos en las pruebas) o Asuntos Técnicos  Problemas en la definición de requisitos correctos  En la medida en que los requisitos no se puedan cumplir dadas las restricciones vigentes  Entorno de la prueba que no esté listo a tiempo  Conversión tardía de datos, planificación de migración y conversión / herramientas de migración de datos de desarrollo y pruebas  Baja calidad del diseño, código, datos de configuración datos de prueba y pruebas o Proveedor:  Falla de terceros  Asuntos contractuales Cuando de analiza, gestiona y mitigan estos riesgos, el gerente de la prueba sigue los principios bien establecidos de gestión del Proyecto. El resumen del Standard for Software Test Documentation’ (IEEE Std 829-1998) en planes de la prueba, exige que se indiquen riesgos y contingencias 5.5.2 Riesgos de Productos (K2) Las áreas de fallas potenciales (futuros eventos o peligros adversos) en el software o sistema

se conocen como riesgos de productos ya que son un riesgo para la calidad del producto. Incluyen lo siguiente  

Software entregado que este propenso a fallas El potencial que el software/hardware pueda causar daño a una persona o a la compañía Malas características del software (por ejemplo, funcionalidad, confiabilidad, uso y desempeño) Mal integridad y calidad de datos (por ejemplo, asuntos de migración de datos, problemas en la

 

Conversión de datos, problemas en la transferencia de datos, violación de reglas de datos) El software que no desarrolle sus funciones previstas



Los riesgos se utilizan para decidir donde iniciar la prueba y donde se deben hacer más pruebas; se utilizan las pruebas para reducir el riesgo de un efecto adverso o reducir el impacto de un efecto adverso. Estos riesgos son un tipo especial de riesgo para el éxito de un proyecto. Las pruebas como una actividad de control de riesgo suministran retroalimentación respecto riesgos residuales midiendo la efectividad en remover defectos críticos y de planes de contingencia. Un enfoque de pruebas basado en riesgos suministra oportunidades proactivas de reducir los niveles de riesgo en el producto, comenzando en las fases iniciales de un proyecto. Involucra la identificación de riesgos del producto y su uso en la guía de planificación de la prueba y control, especificación, preparación y ejecución de pruebas. Los riesgos identificados en un enfoque basado en riesgos se pueden utilizar para lo siguiente: o o o o

Determinar las técnicas de prueba que deben utilizarse Determinar el grado de prueba que debe llevarse a cabo Darle prioridad a las pruebas en un intento por encontrar defectos críticos lo más pronto posible Determinar si cualquier actividad que no requiere pruebas se pueda utilizar para reducir el riesgo (por ejemplo, dar capacitación el diseñadores sin experiencia)

Los sorteos de pruebas basadas en riesgos en conocimiento colectivo y perspectivas de los participantes del proyecto para determinar los riesgos y los niveles de pruebas requeridos para reconocer dichos riesgos. Para garantizar la probabilidad de falla en un producto se minimice, las actividades de gestión de riesgo suministra un enfoque disciplinado para: o Evaluar ( y reevaluar regularmente) lo que puede salir mal (riesgos) o Determinar los riesgos que deben tratarse o Implementar acciones para tratar con dichos riesgos

Adicionalmente, las pruebas podrán respaldar la identificación de nuevos riesgos y también podrá ayudar a determinar que riesgos se deben reducir y disminuir la incertidumbre sobre riesgos. 5.6

Gestión de Incidentes (K3)

40 minutos

Términos Registro de incidentes, gestión de incidentes, informe de incidentes Antecedentes Puesto que uno de los objetivos de las pruebas es encontrar defectos, las discrepancias entre los resultados reales y esperados deben registrarse como incidentes. Se debe investigar un incidente que pueda resultar en un defecto. Las acciones pertinentes para eliminar incidentes y defectos deben definirse. Se deben monitorear los incidentes y defectos a partir del descubrimiento y clasificación para corrección y confirmación de la solución. Con el fin de manejar todos los incidentes y finalizarlos, una organización debe establecer un proceso de gestión de incidentes y normas de clasificación. Pueden surgir incidentes durante la fase de desarrollo, revisión, pruebas o uso de un producto software. Podrán surgir por asuntos ocurridos en el código o el sistema en funcionamiento o cualquier tipo de documentación incluyendo requisitos, documentos de desarrollo, documentos de la prueba e información del usuario como “Ayuda “o guías de instalación. Los informes de incidentes tienen los siguientes objetivos: o Darles retroalimentación a los desarrolladores y otras partes retroalimentación respecto al problema que permita la identificación, asilamiento y corrección que sea necesaria o Darles a los líderes de la prueba los medios de monitorear la calidad del sistema conforme la prueba y el progreso de las pruebas o Dar ideas para el perfeccionamiento de los proceso de pruebas Los detalles del informe del incidente podrán incluir: o Fecha de emisión, organización que emite y autor o Resultados esperados y reales o Identificación de la partida de prueba (partida de configuración) y entorno o Proceso del ciclo de vida del software o sistema donde se observó el incidente o Descripción del incidente que permita la reproducción y resolución, incluyendo registros, memorias de base de datos y captura de pantallas o Alcance o grado de impacto en los intereses de los participantes o Severidad del impacto en el sistema o Urgencia / prioridad a solucionar

o o o o

o

Estado del incidente ( por ejemplo, abierto, diferido, duplicado, en espera a ser solucionado, pruebas hechas nuevamente ya solucionadas en espera, cerrado) Conclusiones, recomendaciones y aprobaciones Asuntos a nivel global, como otras áreas que puedan resultar afectadas por los cambios que resulten de incidentes Cambio de historial, como la secuencia de las acciones tomadas por parte de los miembros del equipo respecto al incidente que se debe aislar y confirmarse como solucionado Referencias, incluyendo la identidad del caso de la especificación del caso de la prueba que revelo el problema

La estructura de un informe de incidentes también se cubre en Standard for Software Test Documentation (IEEE std 829-1998). References 5.1.1 Black, 2001, Hetzel, 1988 5.1.2 Black, 2001, Hetzel, 1988 5.2.5 Black, 2001, Craig, 2002, IEEE Std 829-1998, Kaner 2002 5.3.3 Black, 2001, Craig, 2002, Hetzel, 1988, IEEE Std 8291998 5.4 Craig, 2002 5.5.2 Black, 2001 , IEEE Std 829-1998 5.6 Black, 2001, IEEE Std 829-1998 6.

Herramientas de Soporte para Pruebas (K2)

80 minutos

Objetivos de estudio en herramientas de soporte para pruebas

Los objetivos identifican lo que se podrá hacer tras la finalización de cada modulo 6.1 Tipos de Herramientas de Prueba (K2) LO-6.1.1 Clasificar los diferentes tipos de herramientas de prueba de acuerdo a sus propósitos y actividades del proceso fundamental de la prueba y el ciclo de vida del software (K2) LO-6.1.3 Explicar el termino herramienta de prueba y el propósito de las herramientas de soporte en pruebas (K2) 6.2 Uso Efectivo de Herramientas: Beneficios y Riesgos Potenciales (K2) LO-6.2.1 Hacer un resumen de los beneficios y riesgos potenciales de automatización de la prueba y herramientas de soporte en pruebas K2) LO-6.2.2 Tener en cuenta consideraciones especiales en las herramientas de ejecución de la prueba, análisis estático y herramientas de gestión de la prueba (K1)

6.3 Presentación de la Herramienta en una Organización (K1) LO-6.3.1 Mencionar los principios fundamentales en la introducción de la herramienta en una organización (K1) LO-6.3.2 Mencionar los objetivos de una prueba de concepto para la evaluación de la herramienta y una fase experimental para implementación de la herramienta (K1) LO-6.3.3 Reconocer que son requeridos los factores para herramientas de soporte apropiadas en lugar de simplemente adquirir una herramienta (K1) 6.1

Tipos de Herramientas de Prueba (K2)

45 minutos

Términos Herramienta de gestión de configuración, herramienta de cobertura, herramienta de depuración, herramienta de análisis dinámico, herramienta gestión de incidentes, herramienta pruebas de carga, herramienta de modelos, herramienta de monitoreo, herramienta desempeño de la prueba, efecto de sondeo, herramienta gestión de requisitos, herramienta de revisión, herramienta de análisis estático. Herramienta prueba de tensión, comparador de la prueba, preparación datos de la prueba, herramienta diseño de la prueba, harness de la prueba, herramienta ejecución de la prueba, herramienta gestión de la prueba, herramienta marco de pruebas unitarias. 6.1.1 Herramientas de soporte en Pruebas (K2) Las herramientas de prueba se pueden utilizan para realizar una o más actividades que respaldan las pruebas. Incluyen lo siguiente: 1. Herramientas que se utilizan directamente en pruebas como las herramientas de ejecución de la prueba, herramientas de generación de datos de prueba y herramientas de comparación de resultados 2. Herramientas que ayuden en la gestión de procesos de pruebas como aquellos que se utilizan para gestionar pruebas, resultados de pruebas, requisitos, incidentes, defectos, etc., y que además ayuden en los reportes y seguimiento de ejecución de prueba. 3. Herramientas que se utilicen en el reconocimiento o en términos simples: exploración (por ejemplo, herramientas que monitorean la actividad del archivo en una aplicación) 4. Cualquier herramienta que ayude en las pruebas ( una hoja de cálculo también una herramienta de prueba en este significado) La herramienta de apoyo en pruebas puede tener uno o más de los siguientes propósitos dependiendo del contexto: o Mejorar la eficiencia de las actividades de prueba por medio de la automatización repetitiva de tareas o por medio del apoyo en las actividades del manual de prueba como la planificación de prueba, diseño de prueba, reporte y seguimiento de prueba. o Automatizar actividades que requieran recursos importantes cuando se realicen manualmente ( por ejemplo, pruebas estáticas)

o o

Automatizar actividades que no se puedan ejecutar manualmente ( por ejemplo, pruebas de desempeño de gran escala de las aplicaciones servidor-cliente) Aumentar la confiabilidad de las pruebas ( por ejemplo, por medio de la automatización de grandes comparaciones de datos o por medio de la simulación de comportamiento

El término “marco de referencia de prueba” se utiliza frecuentemente en la industria, como mínimo de las tres siguientes maneras: o Bibliotecas de pruebas reusables y extensibles que se puedan utilizar para construir herramientas de prueba ( denominadas harnesses de prueba respectivamente ) o Un tipo de diseño de automatización de prueba ( por ejemplo, orientado a los datos y basabas en palabras clave) o Todo el proceso de ejecución de pruebas Para efectos de este programa, el término “marco de referencia de prueba” se utiliza en sus dos primeros significados, tal como se describe en la Sección 6.1.6 6.1.2

Clasificación de la Herramienta de Prueba (K2)

Existe un número de herramientas que soportan distintos aspectos de pruebas. Se pueden clasificar las herramientas basándose en varios criterios como propósitos / shareware / comercial/ gratis / de fuente abierta, tecnología utilizada entre otras. Se clasifican las herramientas en este programa de acuerdo a las actividades de pruebas que soportan. Algunas herramientas claramente soportan un actividad; otras soportan más de una actividad, pero se clasifican conforme la actividad con la cual se asocian más estrechamente. Las herramienta provenientes de un solo proveedor, particularmente aquellas que se han designado para trabajar juntas, podrán combinarse en un solo paquete. Algunos tipos de herramientas de prueba pueden ser intrusivos, lo que significa que pueden afectar el resultado real de la prueba. Por ejemplo, el momento real puede ser diferente debido a las instrucciones extras que ejecuta la herramienta, o puede que se obtenga una medida diferente de la cobertura del código. La consecuencia de la herramienta intrusiva se denomina el efecto de sondeo. Algunas herramientas ofrecen un apoyo más apropiado para desarrolladores (por ejemplo, herramientas que se utilizan durante las pruebas del componente e integración del componente). Dichas herramientas se marcan con “(D)” en la siguiente lista. 6.1.3

Herramienta de Soporte en la Gestión de Pruebas (K1)

Las herramientas de gestión se aplican a todas las actividades de prueba en todo el ciclo de vida del software.

Herramientas de Gestión de Prueba Estas herramientas suministran interfaces para la ejecución de pruebas, seguimiento de defectos y gestión de requisitos, junto con el soporte para análisis cuantitativo y reporte de objetos de prueba. También soportan el rastreo de objetos de prueba a las especificaciones del requisito y podrían tener una capacidad independiente de control de versión independiente o una interface a una externa. Requisitos Herramientas de Gestión Estas herramientas almacenan enunciación de requisitos, características para requisitos (que incluyen prioridades), suministra identificadores únicos y soportan el seguimiento de los requisitos en pruebas individuales. Estas herramientas podrán también ayudar a identificar requisitos inconsistentes o que hagan falta. Herramientas Gestión de Incidentes (Herramientas Monitoreo de Defectos) Estas herramientas almacenan y manejan informes de incidentes, es decir, defectos, fallas, solicitudes de cambio o problemas y anomalías percibidas y ayudan en la gestión del ciclo de vida de incidentes, opcionalmente con el soporte en análisis estadístico. Herramientas Gestión de Configuración Aunque no sean estrictamente herramientas de prueba, son necesarias para la gestión de almacenamiento y versión del testware y software relacionado especialmente cuando se configura más de un entorno de hardware/software en términos de versiones de sistemas operativos, compiladores, navegadores, etc. 6.1.4

Herramientas de Soport en Pruebas Estáticas (K1)

Las pruebas estáticas suministran una manera rentable de encontrar más defectos con anticipación en el proceso de desarrollo. Herramientas de Revisión Estas herramientas ayudan con la revisión de procesos, listas de control, pautas de revisión y se utilizan para almacenar y hacer comentarios de revisión sobre defectos y esfuerzos. Pueden ser una ayuda adicional al suministrar apoyo en las revisiones en línea en equipos grandes o dispersos geográficamente. Herramientas Análisis Estático (D) Estas herramientas le ayudan a los desarrolladores y probadores a encontrar defectos antes de las pruebas dinámicas suministrando soporte para reforzar los estándares de codificación (incluyendo la codificación segura), análisis de estructuras y dependencias. También pueden ayudar a planear o analizar riesgos suministrando métricas en el código (por ejemplo, complejidad) Herramientas de Modelación (K1) Estas herramientas se utilizan para validar los modelos del software (por ejemplo, modelo de datos físicos (MDF) en una base de datos relacional), enumerando inconsistencias y encontrando defectos. Estas herramientas normalmente ayudan a generar algunos casos de

prueba basados en el modelo 6.1.5 Herramientas de Soporte en la Especificación de la Prueba (K1) Herramientas Diseño de Prueba Estas herramientas se utilizan para generar entradas de prueba o pruebas ejecutables y / o oráculos de prueba a partir de requisitos, interfaces graficas de usuarios, modelos de diseño (estado, datos, u objeto) o códigos. Herramientas Preparación Datos de Prueba Manipulan las bases de datos archivos o transmisiones de datos para configurar datos de prueba que se utilizan durante la ejecución de pruebas que garantizan la seguridad por medio de la confidencialidad de datos. 6.1.6 Herramientas de Soporte Para Ejecución de Pruebas y Registro (K1) Herramientas Ejecución de Prueba Estas herramientas permiten que las pruebas se ejecuten automáticamente, o semi automáticamente, utilizando entradas o salidas esperadas, por medio del uso de lenguaje scripting y generalmente suministran un log de prueba en cada ejecución de prueba. También pueden utilizarse para registrar pruebas y soportar los lenguajes scripting o configuración basada en GUI para la parametrización de datos y otra configuración en las pruebas. Herramientas Marco de prueba Harness/ Unidad de Pruebas (D) Una unidad de prueba harness o marco facilita las pruebas del componente o partes de un sistema por medio de la simulación del entorno en el cual el objeto de la prueba funcionara a través del suministro de objetos simulados como stubs o drivers. Comparadores de Prueba Determinan las diferencias entre archivos, bases de datos o resultados de pruebas. Las herramientas de ejecución de prueba incluyen comúnmente comparadores dinámicos, pero se pueden realizar comparaciones posteriores a la ejecución por parte de una herramienta de comparación separada. Un comparador de prueba puede utilizar un oráculo de prueba, particularmente si esta automatizado. Herramientas Medidas de Cobertura (D) Estas herramientas que por a través de medios intrusivos o no intrusivos, mide el porcentaje de tipos específicos de estructuras de códigos que se han ejercitado (por ejemplo, estados, sedes o decisiones y llamados de modulo o funciones) por parte de un conjunto de pruebas. Herramientas de Prueba de Seguridad Se utilizan para evaluar las características de seguridad del software. Lo anterior incluye la evaluación de la habilidad del software para proteger la confidencialidad de datos, integración, autenticación, autorización, disponibilidad y no repudio. Las herramientas de seguridad se enfocan generalmente en una tecnología, plataforma y propósito en particular.

6.1.7 Herramienta de Apoyo para Desempeño y Seguimiento (K1) Herramientas de Análisis Dinámico (D) Encuentran defectos solo cuando se está ejecutando el software, como en dependencias de tiempo o pérdida de memoria. Se utilizan comúnmente en el componente y las pruebas de integración del componente y cuando se prueba el middleware. Herramientas Prueba de desempeño /Prueba de Carga / Pruebas de Tensión Las herramientas de prueba de desempeño monitorean cómo se comporta el sistema conforme una variedad de uso simulado en términos de un número de usuarios simultáneos, su modelo de incremento, frecuencia y porcentaje relativo de transacciones. La simulación de carga se logra por medio de la creación de un usuario virtual que lleva a cabo un conjunto seleccionado de transacciones, extendidos a varias máquinas de prueba comúnmente conocidas como generadores de carga. Herramientas de Seguimiento Continuamente analizan, verifican e informan el uso de recursos específicos del sistema y advierten de posibles problemas en el servicio 6.1.8 Herramienta de Soporte para Necesidades Especificas de Prueba (K1) Evaluación calidad de datos Data se encuentra en el centro de algunos proyectos como proyectos de conversión / migración de datos y aplicaciones como data warehouses y sus atributos pueden variar en términos de criticidad y volumen. En dichos contextos, se necesitan emplear las herramientas en la evaluación de calidad de dtapsy verificar las normas de conversión y migración de datos para garantizar que los datos procesados son los correctos, completos y cumplen con los estándar del contexto especifico pre definido. Existen otras herramientas de prueba para prueba de usabilidad. 6.2 Uso Efectivo de Herramientas: Beneficios y Riesgos Potenciales (K2)

20 minutos

Términos Pruebas dirigidas a datos, pruebas dirigidas a palabras claves, script (En informática un "script", archivo de órdenes, archivo de procesamiento por lotes o guion es un programa usualmente simple, que por lo regular se almacena en un archivo de texto plano) 6.2.1 Beneficios y Riesgos Potenciales de Herramientas de soporte en Pruebas (Todas las Herramientas) (K2) Con el simple hecho de comprar o alquilar una herramienta no se garantiza el éxito de dicha herramienta. Todo tipo de herramienta requiere un esfuerzo adicional en el que se logren beneficios reales y duraderos. Existen beneficios y oportunidades potenciales en las pruebas utilizando herramientas; pero también hay riesgos.

Los beneficios potenciales de uso de herramientas incluyen: o Se reduce el trabajo repetitivo ( por ejemplo, funcionamiento pruebas de regresión, re ingreso de los mismos datos de prueba y revisión de los estándares de codificación) o Mayor consistencia y respetabilidad (por ejemplo, pruebas que ejecuta una herramienta en el mismo orden con la misma frecuencia y pruebas derivadas de requisitos) o Evaluación objetiva, ( por ejemplo, medidas estáticas, cobertura) o Fácil acceso a información de prueba o proceso de pruebas ( por ejemplo, estadísticas y graficas del progreso de pruebas, tasas de incidentes y desempeño) Los riesgos de usos de herramientas incluyen o Expectativas poco realistas en la herramienta (que incluyen funcionalidad y facilidad de uso) o Subestimar el tiempo, costos y esfuerzo necesario para lograr beneficios significativos y continuos con la herramienta ( que incluye capacitación y conocimiento externo) o Subestimar el esfuerzo requerido para mantener los activos de las pruebas generadas por la herramienta o Confiar en la herramienta excesivamente (reemplazar el diseño de prueba o uso de pruebas automatizadas cuando las pruebas manuales serían más apropiadas) o Descuidar el control de versiones de activos de la prueba dentro de la herramienta o Descuido de asuntos de relaciones e interoperabilidad entre herramientas críticas, como requisitos herramientas de gestión, herramientas control de versiones, herramientas gestión de incidentes, herramientas seguimiento de defectos y herramientas de varios vendedores o Riesgo de que el fabricante de la herramienta salga del negocio, retire la herramienta o venda dicha herramienta a otro fabricante o Poca respuesta por parte del fabricante en cuanto a soporte, actualizaciones y solución de defectos o Riesgo de suspensión de proyecto de fuentes abiertas / libre de herramientas o Imprevistos como la incapacidad de soporte de una nueva plataforma

6.2.2 Consideraciones especiales para algunos Tipos de Prueba (K1) Herramientas de Ejecución de Prueba Ejecutan los objetos de la prueba por medio de scripts de prueba automatizados. Este tipo de herramienta generalmente requiere esfuerzos significativos con el fin de lograr beneficios significativos. Al capturar pruebas por medio del registro de acciones de un probador manual puede resultar atractivo, pero este enfoque no logra grandes cifras de scripts de prueba

automatizados. Un script capturado es una representación lineal con datos específicos y acciones como parte de cada script. Es posible que este tipo de script sea inestable al ocurrir casos inesperados. Un enfoque de prueba dirigida a datos generalmente divide en una hoja de cálculo las entradas de prueba (los datos) y utiliza un script de prueba más genérico que pueda leer los datos de entrada y ejecutar el mismo script de prueba con datos diferentes. Los probadores que no conozcan el script, pueden crear los datos de prueba en estos scripts predefinidos. Existen otras técnicas utilizadas en las técnicas basadas en datos donde en lugar de haber combinaciones de datos codificados ubicados en una hoja de cálculo, se generan los datos por medio de algoritmos basados en parámetros configurables al momento de la ejecución y se suministran a la aplicación. Por ejemplo, es posible que una herramienta utilice un algoritmo que genere una identificación aleatoria de un usuario y se utiliza una semilla para repetitividad en el modelo para controlar aleatoriedad. En un enfoque de pruebas basados en palabras claves, la hoja de cálculo contiene palabras claves que describen las acciones que deben tomarse (también denominadas palabras de acción) y datos de prueba. Los probadores (incluso si no conocen el lenguaje del script) pueden definir pruebas por medio de las palabras claves que pueden diseñarse de acuerdo a la aplicación que se está probando. Los conocimientos técnicos en el script son necesarios en todos los enfoques (ya sea por parte de los probadores o especialistas en la automatización de la prueba) Independientemente de la técnica del script utilizada, los resultados esperados en cada prueba necesitan almacenarse en una futura comparación. Herramientas de Análisis Estático Estas herramientas aplicadas al código fuente pueden hacer cumplir los estándares de codificación, pero si se aplican a un código vigente, pueden generar una gran cantidad de mensajes. Los mensajes de advertencia no detienen el código de traducirse en un programa ejecutable, pero debe idealmente estar dirigido de manera que el mantenimiento del código sea más fácil en un futuro. Es un enfoque efectivo una implementación manual de la herramienta de análisis con filtros iniciales para excluir algunos mensajes. Herramientas Gestión de Prueba Necesitan una interrelación con otras herramientas u hojas de cálculo con el fin de producir información útil en un formato que se ajuste a las necesidades de la organización. 6.3 Presentación Organización (K1)

de

una

Herramienta

a

una

15 minutos

Términos No hay términos específicos Antecedentes Las consideraciones principales en la selección de una herramienta en una organización incluyen:

o

o o

o o o o

Evaluación de una madurez organizacional, fortalezas y debilidades e identificación de oportunidades en un proceso de prueba perfeccionado que soportan las herramientas Evaluación de requisitos claros y criterios objetivos Una prueba de concepto utilizando una herramienta de prueba durante la fase de evaluación para establecer si dicha herramienta funciona efectivamente con el software conforme la prueba y dentro de la infraestructura o para identificar los cambios necesarios a dicha infraestructura para utilizar la herramienta efectivamente Evaluación del fabricante ( que incluye capacitación, soporte y aspectos comerciales) o proveedores de soporte de servicio en caso de herramientas no comerciales Identificación de requisitos internos para capacitación y asesoramiento en el uso de la herramienta. Evaluación de las necesidades de capacitación teniendo en cuenta las destrezas de automatización de prueba del equipo Calculo de la relación costo beneficio basándose en un caso de negocio concreto

La presentación de la herramienta seleccionada en una organización comienza con un proyecto piloto que tiene los siguientes objetivos: o Aprender más detalladamente sobre la herramienta o Evaluar como la herramienta se ajusta a los procesos y practicas vigentes y determinar que se debería cambiar o Decidir en cuanto a las maneras estándares de utilizar, gestionar, almacenar y mantener la herramienta y activos de la prueba (por ejemplo, decidir la convenciones para fijar nombres en archivos y pruebas, creación de bibliotecas y definición de la modularidad de los conjuntos de pruebas) o Evaluar si los beneficios se van a lograr con un costo razonable Los factores de éxito para el despliegue de la herramienta dentro de una organización incluyen: o Extensión gradual de la herramienta al resto de la organización o Adaptación y perfeccionamiento de procesos que se ajusten al uso de la herramienta o Suministro de formación y capacitación / tutoría a nuevos usuarios o Definición del uso de directrices o Implementación de una forma de reunir información de uso desde el uso real o Monitoreo de la herramienta de uso y beneficios o Suministro de soporte al equipo de prueba en una herramienta dada o Reunión de lecciones aprendidas de todos los equipos Referencias 6.2.2 Buwalda, 2001, Fewster, 1999 6.3 Fewster, 1999