Introducción
Para estudiar cada uno de los capítulos del Programa de Estudios del ISTQB CTFL v3.1. y no sólo comprender su alcance sino además las relaciones existentes entre sus conceptos se pueden aplicar varios métodos, uno de ellos es conociendo y comprendiendo los objetivos de aprendizaje de cada uno de los principales ítems de cada capítulo. Aquí te comparto el alcance de los objetivos de aprendizaje del Capítulo IV – Gestión de la Prueba.
Objetivos de Aprendizaje para Gestión de la Prueba
5.1. Organización de la Prueba
NB-5.1.1 (K2) Explicar las ventajas y desventajas de la prueba independiente.
NB-5.1.2 (K1) Identificar las tareas del jefe de la prueba y del probador.
5.2. Planificación y Estimación de la Prueba
NB-5.2.1 (K2) Resumir el objetivo y el contenido de un plan de prueba.
NB-5.2.2 (K2) Diferenciar entre varias estrategias de prueba.
NB-5.2.3 (K2) Proporcionar ejemplos de posibles criterios de entrada y salida.
NB-5.2.4 (K3) Aplicar conocimientos sobre priorización, y dependencias técnicas y lógicas, para programar la ejecución de la prueba para un conjunto determinado de casos de prueba.
NB-5.2.5 (K1) Identificar los factores que influyen en el esfuerzo asociado a la prueba.
NB-5.2.6 (K2) Explicar la diferencia entre dos técnicas de estimación: la técnica basada en métricas y la técnica basada en expertos.
5.3. Monitorización y Control de la Prueba
NB-5.3.1 (K1) Recordar métricas utilizadas para probar.
NB-5.3.2 (K2) Resumir los objetivos, el contenido y las audiencias de los informes de prueba.
5.4. Gestión de la Configuración
NB-5.4.1 (K2) Resumir cómo la gestión de configuración proporciona soporte a la prueba.
5.5. Riesgos y Prueba
NB-5.5.1 (K1) Definir el nivel de riesgo mediante el uso de probabilidad e impacto.
NB-5.5.2 (K2) Distinguir entre riesgos de proyecto y de producto.
NB-5.5.3 (K2) Describir, utilizando ejemplos, cómo el análisis de riesgo de producto puede influir en la intensidad y el alcance de la prueba.
5.6. Gestión de Defectos
NB-5.6.1 (K3) Redactar un informe de defecto, que cubra los defectos encontrados durante la prueba.
5.1. Organización de la Prueba
NB-5.1.1 (K2) Explicar las ventajas y desventajas de la prueba independiente.
La prueba independiente en el contexto de pruebas de software se refiere a la realización de pruebas por parte de un equipo o individuo que no está directamente involucrado en el desarrollo del software. A continuación se detallan las ventajas y desventajas de la prueba independiente:
Ventajas de la prueba independiente:
1. Detección de diferentes tipos de fallos: Los probadores independientes pueden reconocer diferentes tipos de fallos en comparación con los desarrolladores, debido a sus diferentes contextos, perspectivas técnicas y sesgos. Esto aumenta la probabilidad de encontrar una variedad más amplia de defectos en el software.
2. Verificación de suposiciones: Un probador independiente puede verificar, cuestionar o refutar las suposiciones hechas por los implicados durante la especificación e implementación del sistema. Esto ayuda a identificar posibles problemas que podrían haber sido pasados por alto por el equipo de desarrollo.
Desventajas de la prueba independiente:
1. Aislamiento y falta de colaboración: Los probadores independientes pueden estar aislados del equipo de desarrollo, lo que puede conducir a una falta de colaboración, retrasos en la retroalimentación al equipo de desarrollo o una relación de confrontación con el equipo de desarrollo. Esta falta de comunicación puede afectar la eficiencia y efectividad de las pruebas.
2. Pérdida de sentido de responsabilidad: Existe el riesgo de que los desarrolladores pierdan el sentido de la responsabilidad con respecto a la calidad del software si confían en exceso en los probadores independientes para encontrar defectos. Esto podría llevar a una disminución en la calidad del trabajo realizado por los desarrolladores.
3. Cuellos de botella y retrasos: Los probadores independientes pueden ser vistos como un cuello de botella o ser culpados por los retrasos en el lanzamiento o liberación del software. Esto puede generar tensiones en el equipo y afectar la percepción de la prueba independiente.
4. Falta de información relevante: Los probadores independientes pueden carecer de información importante sobre el objeto de prueba, lo que puede limitar su capacidad para realizar pruebas efectivas. La falta de acceso a información crítica puede afectar la calidad y cobertura de las pruebas realizadas de manera independiente.
En resumen, la prueba independiente ofrece ventajas como la detección de diferentes tipos de fallos y la verificación de suposiciones, pero también presenta desventajas como el aislamiento, la falta de colaboración, la pérdida de sentido de responsabilidad, los posibles cuellos de botella y la falta de información relevante. Es importante equilibrar estas ventajas y desventajas al implementar la prueba independiente en un proyecto de desarrollo de software.
NB-5.1.2 (K1) Identificar las tareas del jefe de la prueba y del probador.
Las tareas del jefe de la prueba y del probador en el contexto de pruebas de software pueden variar según el contexto del proyecto, el producto, las competencias de las personas en los roles y la organización. A continuación se detallan algunas de las tareas asociadas a cada uno de estos roles:
Tareas del Jefe de la Prueba:
1. Responsabilidad general del proceso de la prueba: El jefe de la prueba asume la responsabilidad general del proceso de la prueba, lo que incluye la planificación, ejecución, seguimiento y control de las actividades de prueba.
2. Liderazgo de las actividades de la prueba: El jefe de la prueba lidera las actividades de prueba, coordinando y dirigiendo al equipo de prueba para asegurar la calidad del software.
3. Gestión de equipos de prueba: En proyectos u organizaciones más grandes, el jefe de la prueba puede gestionar varios equipos de prueba, supervisando a líderes de prueba o probadores líderes en cada equipo.
4. Promoción y defensa de los probadores y la profesión de prueba: El jefe de la prueba promueve y defiende a los probadores, al equipo de prueba y a la profesión de prueba dentro de la organización.
5. Desarrollo de competencias y carreras profesionales: El jefe de la prueba se encarga de desarrollar las competencias y las carreras profesionales de los probadores a través de planes de formación, evaluaciones del desempeño, entrenamiento, entre otros.
Tareas del Probador:
1. Ejecución de pruebas: Los probadores son responsables de ejecutar pruebas de software, siguiendo los procedimientos y casos de prueba establecidos para evaluar la calidad del software.
2. Identificación y reporte de defectos: Los probadores identifican defectos y fallos en el software durante las pruebas, y reportan estos hallazgos de manera clara y detallada para su corrección.
3. Diseño de casos de prueba: Los probadores pueden participar en el diseño de casos de prueba, contribuyendo con su conocimiento para asegurar una cobertura adecuada de los requisitos y escenarios de prueba.
4. Colaboración en actividades de prueba estática: Los probadores pueden participar en actividades de prueba estática, como revisiones de documentos, para identificar posibles problemas en las fases tempranas del ciclo de vida del software.
5. Participación en la mejora continua: Los probadores pueden contribuir a la mejora continua de los procesos de prueba, proponiendo ideas y soluciones para optimizar las actividades de prueba.
Es importante tener en cuenta que estas tareas pueden variar según el contexto específico del proyecto y la organización, pero proporcionan una visión general de las responsabilidades asociadas a los roles de jefe de la prueba y probador en el ámbito de pruebas de software.
5.2. Planificación y Estimación de la Prueba
NB-5.2.1 (K2) Resumir el objetivo y el contenido de un plan de prueba.
El objetivo de un plan de prueba es establecer un enfoque sistemático y estructurado para la realización de pruebas de software, con el fin de garantizar que el software cumpla con los requisitos y expectativas del cliente. El plan de prueba describe cómo se llevarán a cabo las pruebas, qué se probará, quién realizará las pruebas, cuándo se realizarán las pruebas y cómo se informarán los resultados.
El contenido de un plan de prueba puede variar según el contexto del proyecto y la organización, pero generalmente incluye los siguientes elementos:
1. Introducción: Una descripción general del software que se va a probar, los objetivos del plan de prueba y los roles y responsabilidades de los implicados en el proceso de prueba.
2. Objetivos y alcance de la prueba: Una descripción detallada de los objetivos y alcance de las pruebas, incluyendo los requisitos y funcionalidades que se probarán, los tipos de pruebas que se realizarán y los criterios de aceptación.
3. Estrategia de prueba: Una descripción de la estrategia de prueba que se utilizará, incluyendo los enfoques de prueba, los niveles de prueba, los tipos de prueba y los entornos de prueba.
4. Planificación de la prueba: Una descripción detallada de la planificación de la prueba, incluyendo el calendario de pruebas, los recursos necesarios, los riesgos y las contingencias.
5. Diseño de casos de prueba: Una descripción de cómo se diseñarán los casos de prueba, incluyendo los criterios de diseño, la cobertura de prueba y la trazabilidad de los requisitos.
6. Ejecución de pruebas: Una descripción de cómo se ejecutarán las pruebas, incluyendo los procedimientos de prueba, la documentación de los resultados y la gestión de los defectos.
7. Criterios de aceptación: Una descripción de los criterios de aceptación que se utilizarán para determinar si el software es aceptable para su entrega al cliente.
8. Entregables: Una lista de los entregables que se generarán durante el proceso de prueba, incluyendo informes de prueba, documentación de casos de prueba y documentación de defectos.
En resumen, el objetivo de un plan de prueba es establecer un enfoque sistemático y estructurado para la realización de pruebas de software, y su contenido incluye una descripción detallada de los objetivos y alcance de las pruebas, la estrategia de prueba, la planificación de la prueba, el diseño de casos de prueba, la ejecución de pruebas, los criterios de aceptación y los entregables.
NB-5.2.2 (K2) Diferenciar entre varias estrategias de prueba.
Existen varias estrategias de prueba que se pueden utilizar en el proceso de pruebas de software, y cada una de ellas tiene sus propias características y objetivos. A continuación se describen algunas de las estrategias de prueba más comunes:
1. Pruebas basadas en riesgos: Esta estrategia de prueba se enfoca en identificar y priorizar los riesgos asociados con el software y luego diseñar y ejecutar pruebas para mitigar esos riesgos. El objetivo es maximizar la cobertura de prueba y minimizar el riesgo de defectos críticos.
2. Pruebas exploratorias: Esta estrategia de prueba se basa en la experiencia y el conocimiento del probador para explorar el software y encontrar defectos. El objetivo es descubrir defectos que no se habían previsto en los casos de prueba y mejorar la calidad del software.
3. Pruebas de regresión: Esta estrategia de prueba se enfoca en asegurar que los cambios realizados en el software no hayan introducido nuevos defectos o afectado la funcionalidad existente. El objetivo es garantizar que el software siga funcionando correctamente después de los cambios.
4. Pruebas de aceptación: Esta estrategia de prueba se enfoca en validar que el software cumpla con los requisitos del cliente y las expectativas del usuario final. El objetivo es asegurar que el software sea aceptable para su entrega al cliente.
5. Pruebas de carga: Esta estrategia de prueba se enfoca en evaluar el rendimiento del software bajo diferentes cargas de trabajo. El objetivo es identificar cuellos de botella y problemas de rendimiento antes de que el software sea entregado al cliente.
6. Pruebas de seguridad: Esta estrategia de prueba se enfoca en evaluar la seguridad del software y detectar posibles vulnerabilidades. El objetivo es garantizar que el software sea seguro y proteger la información del usuario.
En resumen, cada estrategia de prueba tiene sus propios objetivos y enfoques, y se pueden utilizar en diferentes momentos del ciclo de vida del software para garantizar la calidad del software. Es importante seleccionar la estrategia de prueba adecuada para el contexto específico del proyecto y la organización.
NB-5.2.3 (K2) Proporcionar ejemplos de posibles criterios de entrada y salida.
Criterios de entrada y salida son fundamentales para el control efectivo de la calidad del software y de las pruebas. A continuación se presentan ejemplos de posibles criterios de entrada y salida:
Ejemplos de criterios de entrada:
1. Disponibilidad de requisitos y especificaciones del software.
2. Disponibilidad de casos de prueba diseñados y aprobados.
3. Disponibilidad de entorno de prueba configurado y listo para su uso.
4. Disponibilidad de datos de prueba y otros recursos necesarios.
5. Finalización de la construcción del software y disponibilidad de la versión a probar.
6. Aprobación de la documentación de diseño y arquitectura del software.
Ejemplos de criterios de salida:
1. Ejecución de todas las pruebas planificadas.
2. Logro de un nivel de cobertura de prueba definido (por ejemplo, de requisitos, riesgos, código).
3. Número de defectos no resueltos dentro de un límite acordado.
4. Número estimado de defectos restantes es suficientemente bajo.
5. Cumplimiento de los criterios de aceptación del cliente.
6. Niveles de fiabilidad, eficiencia de desempeño, usabilidad y seguridad satisfactorios.
Estos ejemplos ilustran cómo los criterios de entrada y salida pueden ser utilizados para controlar y gestionar el proceso de pruebas de software, asegurando que las pruebas se realicen de manera efectiva y que los resultados cumplan con los estándares de calidad establecidos.
NB-5.2.4 (K3) Aplicar conocimientos sobre priorización, y dependencias técnicas y lógicas, para programar la ejecución de la prueba para un conjunto determinado de casos de prueba.
Aplicar conocimientos sobre priorización y dependencias técnicas y lógicas es fundamental para programar la ejecución de pruebas de manera efectiva. Aquí se explica cómo se pueden aplicar estos conocimientos para programar la ejecución de un conjunto determinado de casos de prueba:
1. Priorización de casos de prueba: Los casos de prueba deben ser priorizados en función de su importancia y su impacto en el sistema. Se deben considerar factores como la criticidad de la funcionalidad probada, la probabilidad de encontrar defectos y los requisitos del negocio. Los casos de prueba críticos y aquellos que cubren funcionalidades clave deben tener prioridad alta, mientras que los casos de prueba menos críticos pueden tener prioridad más baja.
2. Dependencias técnicas y lógicas: Al programar la ejecución de casos de prueba, es importante tener en cuenta las dependencias técnicas y lógicas entre ellos. Algunos casos de prueba pueden depender de la ejecución exitosa de otros casos de prueba o de ciertas condiciones en el sistema. Por lo tanto, es crucial identificar y comprender estas dependencias para programar la ejecución de manera adecuada.
3. Programación de la ejecución: Una vez que se ha priorizado y se han identificado las dependencias entre los casos de prueba, se puede programar la ejecución de manera que se maximice la eficiencia y se minimicen las interrupciones. Los casos de prueba con dependencias deben programarse de manera que los casos de prueba en los que dependen se ejecuten primero. Además, se debe considerar la agrupación de casos de prueba similares para optimizar el tiempo de ejecución y los recursos.
Al aplicar estos conocimientos, se puede garantizar que la ejecución de pruebas se realice de manera efectiva, maximizando la cobertura y la detección de defectos, y minimizando el impacto en el tiempo y los recursos. La priorización y la gestión de dependencias son aspectos clave para la planificación y programación exitosa de la ejecución de pruebas.
NB-5.2.5 (K1) Identificar los factores que influyen en el esfuerzo asociado a la prueba.
Varios factores pueden influir en el esfuerzo asociado a la prueba de software. Algunos de estos factores incluyen:
1. Tamaño y complejidad del software: El tamaño y la complejidad del software influyen en la cantidad de pruebas que deben realizarse, así como en la dificultad para identificar y corregir defectos.
2. Cambios en el software: Los cambios en el software, como nuevas funcionalidades o correcciones de errores, pueden aumentar el esfuerzo de prueba al requerir pruebas adicionales para garantizar que los cambios no introduzcan nuevos defectos.
3. Disponibilidad y calidad de la documentación: La disponibilidad de documentación clara y detallada sobre los requisitos, el diseño y la arquitectura del software puede reducir el esfuerzo asociado a la comprensión del sistema y la creación de casos de prueba.
4. Experiencia y habilidades del equipo de pruebas: La experiencia y las habilidades del equipo de pruebas pueden influir en la eficiencia y efectividad de las actividades de prueba, lo que a su vez puede afectar el esfuerzo requerido.
5. Herramientas y entornos de prueba: El uso de herramientas de prueba adecuadas y entornos de prueba bien configurados puede reducir el esfuerzo asociado a la ejecución y gestión de pruebas.
6. Plazos y recursos disponibles: Los plazos ajustados y la disponibilidad limitada de recursos pueden aumentar el esfuerzo asociado a la prueba al requerir una planificación y ejecución más eficientes.
7. Niveles de colaboración y comunicación: La colaboración efectiva entre los equipos de desarrollo, pruebas y negocio, así como una comunicación clara, pueden influir en la eficiencia de las actividades de prueba.
Estos factores pueden variar en cada proyecto de software y deben ser considerados al estimar el esfuerzo asociado a las actividades de prueba. La comprensión de estos factores es crucial para planificar y ejecutar pruebas de manera efectiva.
NB-5.2.6 (K2) Explicar la diferencia entre dos técnicas de estimación: la técnica basada en métricas y la técnica basada en expertos.
La diferencia entre la técnica basada en métricas y la técnica basada en expertos radica en la forma en que se realiza la estimación del esfuerzo o de otros aspectos relacionados con las pruebas de software.
1. Técnica basada en métricas:
La técnica basada en métricas se centra en la recopilación y el análisis de datos cuantitativos para realizar estimaciones. Se utilizan métricas históricas, como el tiempo requerido para completar pruebas similares en proyectos anteriores, la cantidad de defectos encontrados, la cobertura de pruebas alcanzada, entre otros. Estas métricas se utilizan para predecir el esfuerzo necesario para llevar a cabo las pruebas en un nuevo proyecto. La técnica basada en métricas se apoya en datos concretos y medibles para realizar estimaciones.
2. Técnica basada en expertos:
Por otro lado, la técnica basada en expertos se basa en la experiencia y el juicio de personas con conocimientos y habilidades específicas en el área de pruebas de software. En esta técnica, se recurre a la opinión de expertos en pruebas para estimar el esfuerzo necesario. Los expertos pueden tener en cuenta factores cualitativos, como la complejidad del sistema, la disponibilidad de recursos, la complejidad de los requisitos, entre otros, para realizar sus estimaciones. Esta técnica se apoya en la intuición y el conocimiento acumulado de los expertos en pruebas.
En resumen, la técnica basada en métricas utiliza datos cuantitativos históricos para realizar estimaciones, mientras que la técnica basada en expertos se apoya en la experiencia y el juicio de personas con conocimientos especializados en pruebas de software. Ambas técnicas tienen sus ventajas y limitaciones, y su aplicación puede variar según el contexto y la disponibilidad de datos históricos y expertos en el área de pruebas.
5.3. Monitorización y Control de la Prueba
NB-5.3.1 (K1) Recordar métricas utilizadas para probar.
Las métricas utilizadas en las pruebas de software pueden variar dependiendo de los objetivos específicos de las pruebas y del contexto del proyecto. Algunas de las métricas comunes utilizadas en las pruebas de software incluyen:
1. Cobertura de prueba: Esta métrica evalúa la proporción del software que ha sido sometida a pruebas en relación con el total de funcionalidades, requisitos, código o caminos posibles. Puede incluir la cobertura de código, cobertura de requisitos, cobertura de decisiones, entre otros.
2. Densidad de defectos: Esta métrica indica la cantidad de defectos encontrados en relación con una unidad de tamaño, como líneas de código, funciones o requisitos. Puede proporcionar información sobre la calidad del software y la efectividad de las pruebas.
3. Tasa de fallos: Esta métrica mide la frecuencia de fallos o defectos encontrados durante las pruebas en relación con la cantidad de pruebas ejecutadas. Puede ayudar a evaluar la estabilidad y confiabilidad del software.
4. Eficiencia de las pruebas: Esta métrica evalúa la efectividad de las actividades de prueba en relación con los objetivos establecidos. Puede incluir el número de defectos encontrados por hora de prueba, el porcentaje de casos de prueba exitosos, entre otros.
5. Tiempo y recursos: Estas métricas evalúan el tiempo y los recursos utilizados en las actividades de prueba en relación con los resultados obtenidos. Pueden incluir el tiempo dedicado a la preparación y ejecución de pruebas, el número de recursos involucrados, entre otros.
6. Costo de la prueba: Esta métrica evalúa el costo asociado a las actividades de prueba en relación con los beneficios obtenidos, como la detección de defectos. Puede incluir el costo por defecto encontrado, el costo por caso de prueba ejecutado, entre otros.
Estas son solo algunas de las métricas comunes utilizadas en las pruebas de software. La selección de métricas adecuadas dependerá de los objetivos específicos de las pruebas y de las necesidades del proyecto. El uso de métricas puede proporcionar información valiosa para evaluar la calidad del software, la efectividad de las pruebas y la eficiencia de las actividades de prueba.
NB-5.3.2 (K2) Resumir los objetivos, el contenido y las audiencias de los informes de prueba.
Los informes de prueba tienen como objetivo resumir y comunicar la información relevante sobre las actividades de prueba, tanto durante como al final de una actividad de prueba. Los informes de prueba pueden ser de dos tipos: informes de avance de la prueba y informes resumen de la prueba.
Los informes de avance de la prueba se emiten periódicamente durante la monitorización y el control de la prueba. Estos informes pueden incluir información sobre el estado de las actividades de prueba, el avance con respecto al plan de prueba, los factores que impiden el avance, las pruebas previstas para el próximo período objeto de informe y la calidad del objeto de prueba. Los informes de avance de la prueba están dirigidos a los implicados en el proyecto, como el equipo de pruebas, el equipo de desarrollo, el equipo de gestión y otros interesados.
Los informes resumen de la prueba se preparan al final de una actividad de prueba y proporcionan una visión general de los resultados de la prueba. Estos informes pueden incluir información sobre el esfuerzo de prueba, la cobertura de prueba, la densidad de defectos, la tasa de fallos, la eficiencia de las pruebas, el tiempo y los recursos utilizados, el costo de la prueba y otros aspectos relevantes. Los informes resumen de la prueba están dirigidos a los interesados en la calidad del software, como el equipo de gestión, los clientes, los usuarios finales y otros interesados.
En resumen, los informes de prueba tienen como objetivo comunicar la información relevante sobre las actividades de prueba y los resultados obtenidos. Los informes de avance de la prueba se emiten periódicamente durante la monitorización y el control de la prueba, mientras que los informes resumen de la prueba se preparan al final de una actividad de prueba. Los informes de prueba están dirigidos a los implicados en el proyecto y a los interesados en la calidad del software.
5.4. Gestión de la Configuración
NB-5.4.1 (K2) Resumir cómo la gestión de configuración proporciona soporte a la prueba.
La gestión de configuración es un proceso que se encarga de establecer y mantener la integridad del componente o sistema, los productos de prueba y sus relaciones entre sí a lo largo del ciclo de vida del proyecto y del producto. La gestión de configuración proporciona soporte a la prueba de software de varias maneras:
1. Identificación y control de versiones: La gestión de configuración ayuda a identificar y controlar las diferentes versiones de los componentes y productos de prueba, lo que permite a los equipos de prueba trabajar con la versión correcta del software y evitar problemas de compatibilidad.
2. Trazabilidad de requisitos: La gestión de configuración permite mantener una trazabilidad consistente de los requisitos en una herramienta de gestión de requisitos, lo que ayuda a garantizar que todas las funcionalidades del software se prueben adecuadamente.
3. Gestión de defectos: La gestión de configuración ayuda a gestionar los defectos encontrados durante las pruebas, lo que permite un seguimiento adecuado de los defectos y su resolución.
4. Adaptación de la planificación: La gestión de configuración permite adaptar la planificación de las pruebas en función de los resultados y avance de la prueba, lo que ayuda a controlar la prueba y tomar las medidas necesarias para garantizar la calidad del software.
5. Selección e implementación de herramientas: La gestión de configuración apoya la selección e implementación de herramientas para dar soporte al proceso de prueba, lo que permite una gestión más eficiente y efectiva de las actividades de prueba.
En resumen, la gestión de configuración proporciona soporte a la prueba de software al permitir la identificación y control de versiones, mantener la trazabilidad de requisitos, gestionar los defectos, adaptar la planificación y seleccionar e implementar herramientas adecuadas. La gestión de configuración es esencial para garantizar la calidad del software y la efectividad de las actividades de prueba.
5.5. Riesgos y Prueba
NB-5.5.1 (K1) Definir el nivel de riesgo mediante el uso de probabilidad e impacto.
El nivel de riesgo se define mediante el uso de la probabilidad y el impacto. La probabilidad se refiere a la posibilidad de que ocurra un evento en el futuro, mientras que el impacto se refiere al daño que ese evento podría causar. Al combinar la probabilidad y el impacto, se puede determinar el nivel de riesgo asociado con un evento. Por ejemplo, un evento con una alta probabilidad y un impacto significativo se consideraría de alto riesgo, mientras que un evento con una baja probabilidad y un impacto menor se consideraría de bajo riesgo.
En resumen, el nivel de riesgo se determina evaluando la probabilidad de que ocurra un evento y el impacto que ese evento tendría si ocurriera.
NB-5.5.2 (K2) Distinguir entre riesgos de proyecto y de producto.
Los riesgos de proyecto y de producto son dos tipos diferentes de riesgos que se pueden encontrar en el desarrollo de software.
Los riesgos de proyecto se refieren a los riesgos asociados con la gestión y ejecución del proyecto en sí. Estos riesgos pueden incluir retrasos en la planificación, cambios en los requisitos, problemas de recursos, problemas de comunicación, entre otros. Los riesgos de proyecto pueden afectar la capacidad del proyecto para cumplir con los objetivos establecidos, como el presupuesto, el cronograma y la calidad.
Por otro lado, los riesgos de producto se refieren a los riesgos asociados con las características y la calidad del producto de software. Estos riesgos pueden incluir defectos críticos, problemas de rendimiento, vulnerabilidades de seguridad, problemas de usabilidad, entre otros. Los riesgos de producto pueden afectar la capacidad del software para cumplir con los requisitos y expectativas del usuario final.
En resumen, los riesgos de proyecto se refieren a los riesgos asociados con la gestión y ejecución del proyecto, mientras que los riesgos de producto se refieren a los riesgos asociados con las características y la calidad del producto de software. Es importante identificar y gestionar tanto los riesgos de proyecto como los de producto para garantizar el éxito del proyecto y la calidad del software.
NB-5.5.3 (K2) Describir, utilizando ejemplos, cómo el análisis de riesgo de producto puede influir en la intensidad y el alcance de la prueba.
El análisis de riesgo de producto puede influir en la intensidad y el alcance de la prueba de varias maneras. A continuación, se presentan algunos ejemplos de cómo el análisis de riesgo de producto puede influir en la intensidad y el alcance de la prueba:
1. Priorización de pruebas: El análisis de riesgo de producto puede ayudar a identificar las áreas críticas o de alto riesgo en el producto de software. Estas áreas pueden requerir una mayor intensidad de pruebas para mitigar los riesgos asociados. Por ejemplo, si el análisis de riesgo identifica una funcionalidad crítica que tiene un alto impacto en el negocio y una probabilidad moderada de falla, se puede priorizar la intensidad de las pruebas en esa área para garantizar su correcto funcionamiento.
2. Selección de técnicas de prueba: El análisis de riesgo de producto puede influir en la selección de técnicas de prueba adecuadas para abordar los riesgos identificados. Por ejemplo, si el análisis de riesgo identifica un alto riesgo de seguridad en el producto, se pueden seleccionar técnicas de prueba de seguridad específicas para abordar ese riesgo, como pruebas de penetración o pruebas de vulnerabilidad.
3. Definición de escenarios de prueba: El análisis de riesgo de producto puede influir en la definición de escenarios de prueba realistas que aborden los riesgos identificados. Por ejemplo, si el análisis de riesgo identifica un riesgo relacionado con el rendimiento del sistema bajo cargas pesadas, se pueden definir escenarios de prueba que simulen estas condiciones para evaluar el comportamiento del sistema en situaciones críticas.
4. Cobertura de prueba: El análisis de riesgo de producto puede influir en la cobertura de prueba, asegurando que se prueben exhaustivamente las áreas de alto riesgo identificadas. Por ejemplo, si el análisis de riesgo identifica un riesgo relacionado con la interoperabilidad del software con ciertos dispositivos, se puede garantizar que se realicen pruebas exhaustivas con esos dispositivos para mitigar el riesgo.
En resumen, el análisis de riesgo de producto puede influir en la intensidad y el alcance de la prueba al priorizar pruebas, seleccionar técnicas de prueba, definir escenarios de prueba y garantizar una cobertura exhaustiva en las áreas de alto riesgo identificadas.
5.6. Gestión de Defectos
NB-5.6.1 (K3) Redactar un informe de defecto, que cubra los defectos encontrados durante la prueba.
Redactar un informe de defecto durante el proceso de prueba es una parte crucial de la gestión de defectos. A continuación se presentan los elementos clave que deben incluirse en un informe de defecto:
1. Título y resumen: El informe debe incluir un título descriptivo que resuma el defecto encontrado durante la prueba. El resumen debe proporcionar una visión general concisa del defecto para facilitar su identificación y seguimiento.
2. Detalles del informe: Deben incluirse la fecha del informe, la organización emisora y el autor del informe para establecer un registro claro de cuándo y quién identificó el defecto.
3. Identificación del elemento de prueba: Es importante especificar el elemento de configuración que se está probando y el entorno en el que se detectó el defecto. Esto ayuda a contextualizar el defecto dentro del entorno de prueba.
4. Fase del ciclo de vida de desarrollo: Se debe indicar en qué fase del ciclo de vida de desarrollo se observó el defecto, ya sea durante la fase de diseño, implementación, pruebas unitarias, pruebas de integración, pruebas de sistema, entre otras.
5. Descripción del defecto: Proporcionar una descripción detallada del defecto que permita su reproducción y resolución. Esto puede incluir registros, capturas de pantalla, volcados de bases de datos o grabaciones que ayuden a ilustrar el defecto.
6. Resultados esperados y reales: Comparar los resultados esperados con los resultados reales observados durante la prueba para resaltar la discrepancia que indica la presencia del defecto.
7. Alcance o grado de impacto: Evaluar el impacto del defecto en relación con los intereses de los implicados, lo que puede incluir la severidad del defecto y su impacto en el funcionamiento del sistema.
8. Urgencia/prioridad de la corrección: Establecer la urgencia y prioridad de corregir el defecto, lo que puede influir en la planificación y la asignación de recursos para su resolución.
9. Estado del informe de defecto: Mantener un registro del estado del informe de defecto, como si está abierto, diferido, duplicado, a la espera de corrección, a la espera de prueba de confirmación, reabierto o cerrado.
Al incluir estos elementos en un informe de defecto, se proporciona a los desarrolladores y otros interesados la información necesaria para identificar, aislar y corregir los defectos, así como para realizar un seguimiento de la calidad del producto y obtener ideas para la mejora de los procesos de desarrollo y prueba.
Comentario final
¿Te ha sido útil el contenido? Me ayudarías y mucho si consideras que vale compartir este artículo entre tus amigos y poder así enterarte cuando publique contenidos relacionados con las certificaciones, con las buenas prácticas, con herramientas y con testing aplicado en inteligencia artificial.
Buscame y seguime en LinkedIn para conocer las opiniones de colegas respecto de los contenidos que publico y por supuesto me ayudarías y mucho si consideras que vale dejar un like, dejar comentarios, compartirlo con tus amigos.
