Principios, Objetivos y Riesgos

Principios del Testing

Principio 1: El Testing muestra la presencia de defectos, no la ausencia de ellos

El Testing reduce la probabilidad de defectos no descubiertos pero no es una prueba de corrección.

Principio 2: El Testing exhaustivo es imposible

No es posible probar todo (puede haber millones de escenarios y puede haber defectos que no hemos encontrado).

Principio 3: Early testing saves time and money (shift left) El Testing temprano ahorra tiempo y dinero

Las pruebas estáticas y dinámicas deberían comenzar lo antes posible.

Principio 4: Los defectos se agrupan

Un pequeño número de módulos suele contener la mayoría de los defectos, ya sea porque esos módulos son muy complejos o porque son muy importantes. Principio de Pareto: el 80% de los defectos serán encontrado en el 20% de los módulos.

Principio 5: Cuidado con la paradoja de los pesticidas

Paradoja de los pesticidas: Si se repiten las mismas pruebas una y otra vez ya no encontrarán defectos

Principio 6: El Testing es contexto-dependiente

Las pruebas se realizan de manera diferente en diferentes contextos, lo que afecta el tiempo y el esfuerzo dedicado a las pruebas (diferentes presupuestos/tiempo asignado, riesgo, alcance).

Principio 7: La ausencia de errores es una mentira

Es una mentira esperar que simplemente encontrar y corregir muchos errores garantice el éxito de un sistema.

Objetivos del testing

• Evaluación del producto: cualquier cosa que estemos desarrollando (código, diseños, etc), ¿está desarrollado correctamente?
• Cumplimiento de requisitos: asegurarse de que se cumplan los requisitos del cliente.
• Generar confianza: asegúrese de que los componentes sigan funcionando como se esperaba.
• Encontrar defectos: objetivo principal.
• Prevención de defectos: se puede hacer verificando los requisitos y agregando detalles, de modo que el desarrollador tiene claros los requisitos y conoce todos los escenarios.
• Proporcionar información a los stakeholders: obtienen información sobre el estado del proyecto.
• Reducir el riesgo: encontrar defectos tempranamente reduce el riesgo de que pase a producción.
• Cumplimiento de las leyes: no se infringen los contratos/leyes/reglamentos de prueba.

Riesgos y Testing

Riesgo: la posibilidad de que ocurra un evento en el futuro que tenga consecuencias negativas. El nivel de riesgo está determinado por la probabilidad del evento y el impacto del mismo.

Hay 2 tipos de riesgos:

• Riesgos de producto/calidad: la posibilidad de que un producto de trabajo no satisfaga las necesidades de sus usuarios o partes interesadas. Tendrían un impacto directo en nuestro progreso o producto.Ejemplos: la aplicación no realiza las funciones previstas, los tiempos de respuesta pueden ser inadecuados para una sistema de alto rendimiento, UX(Experiencia de usuario) no cumple con las expectativas del producto.
• Riesgos del proyecto: situaciones que pueden tener un efecto negativo en la capacidad del proyecto para lograr sus objetivos. Puede implicar retraso o cancelación.Ejemplos: cuestiones de proyectos, cuestiones organizativas, cuestiones políticas, cuestiones técnicas, cuestiones de proveedores.

Gestión de defectos

Objetivos del informe de defectos:

• Proporcionar a los desarrolladores y otras partes información sobre cualquier evento adverso que haya ocurrido.
• Proporcionar a los gerentes de pruebas un medio para rastrear la calidad del producto del trabajo y el impacto en las pruebas.
• Aportar ideas para el desarrollo y mejora de procesos de pruebas.

Componentes del informe de defectos:

• ID, título, resumen, fecha, autor, elemento de prueba, entorno de prueba.
• Pasos para reproducir el defecto.
• Conclusiones, recomendaciones y aprobaciones.
• Historial de cambios.
• Problemas globales/otras áreas que pueden verse afectadas por una solución.

Evaluación de Riesgos y Áreas Críticas del Proyecto

Objetivo: Identificar y priorizar las áreas del proyecto que presentan mayores riesgos, asegurando una asignación efectiva de recursos y tiempo en las pruebas.
Descripción: La evaluación de riesgos se lleva a cabo mediante la identificación de componentes críticos del proyecto que pueden impactar negativamente en la calidad del producto final. Este proceso incluye:

1. Análisis de Riesgos: Se evalúan los diferentes riesgos asociados a cada componente del proyecto, considerando factores como complejidad técnica, cambios frecuentes en los requisitos, y la experiencia del equipo de desarrollo.
2. Clasificación de Áreas Críticas: Se identifican las áreas que tienen un mayor potencial de fallos y que, por lo tanto, requieren atención prioritaria durante las fases de prueba. Esto puede incluir funciones clave, integraciones con otros sistemas, o cualquier cambio significativo en el código.
3. Priorización de Pruebas: Basado en la evaluación de riesgos, se establece un enfoque de prueba que prioriza las áreas críticas, asegurando que se realicen pruebas exhaustivas donde más se necesita.

Revisión de Flujos de Usuario

Objetivo: Garantizar que los flujos de usuario sean consistentes, lógicos y alineados con las expectativas del usuario final.
Descripción: La revisión de flujos de usuario es un proceso esencial para asegurar que la experiencia del usuario sea fluida y satisfactoria. Este proceso incluye:

1. Análisis de Flujos: Se revisan todos los flujos de usuario documentados para verificar que cada paso tenga sentido y que las interacciones sean intuitivas. Esto incluye validar la navegación, las decisiones y los resultados esperados en cada etapa del flujo.
2. Consistencia y Lógica: Se evalúa la consistencia en la terminología y las acciones a lo largo de los diferentes flujos, asegurando que los usuarios no enfrenten confusiones o contradicciones. Se busca que cada flujo cumpla con las pautas de diseño y las mejores prácticas de usabilidad.
3. Recomendaciones de Mejora: A partir de la revisión, se proporcionan recomendaciones para optimizar los flujos de usuario, garantizando que se alineen con los objetivos del proyecto y las necesidades del usuario final.