1. Pruebas
1.1. Relacionadas al cambio
1.1.1. Las pruebas relacionadas al cambio incluyen tanto:
1.1.1.1. Pruebas de confirmación (retesting):
1.1.1.1.1. Para verificar que los defectos previamente identificados y corregidos se hayan solucionado correctamente.
1.1.1.2. Pruebas de regresión:
1.1.1.2.1. Para asegurarse de que los cambios no hayan introducido defectos en funcionalidades previamente existentes.
2. Falla
2.1. ocurre cuando el defecto se manifiesta durante la ejecución del software, es decir, cuando el sistema acepta valores no válidos.
3. error
3.1. sería el acto humano que causó el defecto, en este caso, la distracción del programador.
4. defecto
4.1. es una imperfección o error en el código o en el software que provoca un comportamiento incorrecto o no deseado.
5. Defectos típicos
5.1. Desviación de los estándares
5.1.1. situaciones donde el sistema o el producto no cumple con normas, guías o estándares establecidos.
5.2. Vulnerabilidad de seguridad
5.2.1. Se refiere a fallas o debilidades en el sistema que pueden ser explotadas para comprometer la integridad, confidencialidad o disponibilidad.
5.3. Contradicción
5.3.1. - Ocurre cuando hay criterios o requisitos que se oponen entre sí o generan confusión.
5.4. Brechas de cobertura
5.4.1. se refieren a casos de uso, escenarios o funcionalidades que no han sido considerados o cubiertos en las pruebas o especificaciones.
6. Tecnicas de prueba
6.1. Predicción de errores
6.1.1. Identificar defectos que pueden surgir debido a situaciones inusuales o condiciones que no se presentan frecuentemente.
6.2. Pruebas de decisión
6.2.1. Evaluar el comportamiento del sistema bajo diferentes condiciones de entrada o situaciones, verificando si las decisiones lógicas en el código están correctamente implementadas.
7. Beneficio de las pruebas
7.1. Incremento del costo total de calidad
7.1.1. Se refiere al aumento de los gastos asociados con garantizar la calidad del producto, incluyendo costos de prevención, evaluación y fallos internos/externos. Ejemplo: Tener que rehacer módulos completos debido a defectos críticos descubiertos muy tarde en el ciclo de desarrollo.
7.2. Reducción de costos de las pruebas
7.2.1. Se refiere a la disminución de los recursos financieros necesarios para realizar pruebas, gracias a estrategias efectivas como el uso de pruebas automatizadas o la identificación temprana de errores mediante revisiones estáticas.
7.3. Reducción del costo total de la calidad
7.3.1. La reducción de todos los costos relacionados con la calidad, incluyendo la prevención de defectos, las evaluaciones (pruebas) y los costos asociados a errores no detectados que llegan al cliente. Ejemplo: Evitar errores críticos en producción mediante revisiones tempranas que permiten corregir problemas con costos mínimos.
7.4. Incremento de la productividad del desarrollo
7.4.1. El equipo puede entregar características nuevas o corregir errores de manera más rápida y eficiente. Las prácticas de revisión temprana permiten identificar y corregir problemas antes de que se conviertan en errores costosos y difíciles de manejar. Ejemplo: Detectar inconsistencias en los requisitos antes de empezar a programar, evitando retrabajo y agilizando el desarrollo.
8. Diferenciar niveles de prueba con tipos de prueba
8.1. Prueba de rendimiento
8.1.1. Son un tipo de prueba no funcional porque evalúan características como la velocidad, la escalabilidad y la capacidad de respuesta del sistema. Es una característica de prueba NO FUNCIONAL
8.2. Prueba de componente
8.2.1. Se centra en probar módulos individuales o unidades de software, y no está relacionado con el rendimiento o la integración de interfaces. Cuadrante Q1
8.3. Prueba funcionales
8.3.1. Verifican que el sistema cumpla con los requisitos funcionales establecidos. No abordan aspectos como el rendimiento o los cuellos de botella de red. Cuadrante Q2
8.4. Prueba de integración
8.4.1. El rendimiento de interfaces de red
8.5. Prueba de Usabilidad
8.5.1. Cuadrante Q3
8.6. Prueba de Fiabilidad
8.6.1. Cuadrante Q4
9. Basadas en lista de comprobación
9.1. Implican verificar que el software cumpla con ciertos criterios o mejores prácticas, lo cual coincide con la descripción dada.
10. Herramientas de getión de pruebas.
10.1. Las herramientas de gestión de pruebas son especialmente útiles para recopilar, almacenar y generar informes sobre métricas de prueba. Estas métricas pueden incluir la cantidad de casos de prueba ejecutados, el número de casos de prueba exitosos y fallidos, el estado de los defectos y la cobertura de pruebas, entre otros.
11. Herramientas de seguridad, cobertura y análisis estático están más enfocadas en tareas específicas como análisis de vulnerabilidades, cobertura de código y análisis de calidad estática, respectivamente, pero no en la generación de informes completos de métricas.
12. Que es calidad?
12.1. El grado en el que un componente, sistema o proceso cumple con los requisitos especificados y/o las necesidades o expectativas del usuario/cliente.
13. Pruebas demuestran la presencia de defectos
13.1. que las pruebas pueden mostrar la presencia de defectos, pero no pueden demostrar que no hay defectos. En otras palabras, incluso si no se encuentran errores durante una iteración, eso no garantiza que el software esté libre de defectos.
14. Niveles de pruebas
14.1. Integración
14.1.1. Defectos en las interfaces e interacciones
14.2. Componente
14.2.1. Defectos en módulos u objetos comprobables por separado
14.3. Aceptación
14.3.1. No centrada en identificar defectos
14.4. Sistema
14.4.1. Defectos en todo el objeto de prueba
15. Trazabilidad
15.1. Seleccionar pruebas de regresión
15.1.1. Se pueden seleccionar las pruebas de regresión adecuadas para garantizar que las nuevas modificaciones no hayan introducido errores.
15.2. Evaluación de la integridad de la ejecución de la prueba
15.2.1. La trazabilidad garantiza que las pruebas estén documentadas adecuadamente, lo que permite auditar su ejecución y verificar la cobertura de los requisitos.
15.3. Identificar que historias de usuario tienen informes de defectos abiertos
15.3.1. Esto ayuda a mantener actualizada la información sobre el estado de cada historia y su impacto en el proyecto.
15.4. Evaluar si el numero de pruebas para cada requisito es consistente con el nivel de riesgo del producto
15.4.1. Esto ayuda a equilibrar el esfuerzo de prueba según el nivel de criticidad de cada requisito.