ISTQB – Apuntes Sin Límites

Análisis de impacto

El análisis de impacto es una evaluación crucial que se realiza antes de un lanzamiento de mantenimiento para entender cómo los cambios en el sistema pueden afectar su funcionamiento y sus componentes.

Su objetivo principal es identificar los efectos previstos y los posibles efectos secundarios que podrían surgir como resultado de los cambios, y señalar qué partes del sistema serán impactadas.

En el ámbito de las pruebas, el análisis de impacto permite anticipar cómo los cambios afectarán las pruebas existentes. Los efectos secundarios y las áreas del sistema impactadas deben ser sometidos a pruebas de regresión para asegurarse de que no surjan nuevos problemas. En algunos casos, es necesario actualizar los casos de prueba antes de volver a ejecutarlos.

Este análisis es especialmente útil para decidir si se debe seguir adelante con el cambio, ya que proporciona una visión clara de las posibles consecuencias en el resto del sistema.

Sin embargo, puede ser un proceso complejo, sobre todo si:

Las especificaciones y documentación del sistema están desactualizadas o no existen.
Los casos de prueba no están debidamente documentados o actualizados.
No se mantiene la trazabilidad entre las pruebas y los requisitos.
Las herramientas utilizadas para el análisis son ineficientes o inexistentes.
El equipo carece de experiencia en el sistema o el dominio.
No se ha diseñado el software teniendo en cuenta la mantenibilidad.

Este proceso asegura que se minimicen riesgos, evitando problemas inesperados tras la implementación del cambio.

Los modelos de ciclo de vida de desarrollo de software

Características clave de las pruebas en cualquier modelo:

Pruebas asociadas a cada actividad de desarrollo.
Objetivos específicos para cada nivel de prueba.
Análisis y diseño de pruebas comienzan junto a la actividad de desarrollo correspondiente.
Participación temprana de los probadores en revisiones de productos (requisitos, diseño).
Prueba temprana: Iniciar las pruebas en las primeras etapas del desarrollo.

Modelos de desarrollo secuencial:

Modelo en Cascada:
- Fases lineales, una tras otra (análisis, diseño, codificación, pruebas).
- Las pruebas ocurren al final de todo el desarrollo.
Modelo en V:
- Las pruebas se integran durante todo el proceso.
- Pruebas asociadas a cada fase de desarrollo.
- Favorece la prueba temprana con niveles de prueba secuenciales.

Modelos de desarrollo iterativos e incrementales:

Desarrollo Incremental:
- Requisitos, diseño, construcción y pruebas en fragmentos (crecimiento incremental).
- Los incrementos pueden ser pequeños (una función) o grandes (grupos de funciones).
Desarrollo Iterativo:
- Se realizan varios ciclos de especificación, diseño, construcción y pruebas.
- Las iteraciones generan software operativo, con funciones que se ajustan o cambian en cada ciclo.

Ejemplos de modelos iterativos:

Rational Unified Process: Iteraciones largas (2-3 meses), incrementos grandes.
Scrum: Iteraciones cortas (días o semanas), incrementos pequeños.
Kanban: Mejoras continuas, liberación de prestaciones cuando están listas.
Espiral (o Prototipado): Creación de incrementos experimentales, algunos de los cuales se reelaboran o abandonan.

Beneficios de los modelos iterativos e incrementales:

Entrega continua: Pruebas automáticas y frecuentes.
Equipos auto-organizados: Cambia la organización de pruebas y la colaboración con desarrolladores.
Pruebas de regresión cada vez más importantes con el crecimiento del sistema.

Diferencias entre los Niveles de Prueba

Prueba de Componente (o Unidad):
- Objetivo: Verificar el funcionamiento de componentes individuales (módulos, clases, funciones).
- Responsables: Desarrolladores.
- Tipos de Prueba: Funcional, no funcional, estructural (cobertura de código, pruebas de regresión automatizadas).
Prueba de Integración:
- Objetivo: Verificar la interacción entre componentes o sistemas, asegurando que trabajen juntos según lo especificado.
- Responsables:
  - Integración de Componentes: Desarrolladores.
  - Integración de Sistemas: Probadores (testers).
- Tipos de Prueba: Funcional, no funcional, estructural (pruebas de interfaces, comunicación entre sistemas).
Prueba de Sistema:
- Objetivo: Validar el comportamiento y la capacidad de todo el sistema, incluyendo tanto las pruebas funcionales como no funcionales.
- Responsables: Probadores (testers) independientes.
- Tipos de Prueba: Funcional, no funcional (rendimiento, seguridad, usabilidad).
Prueba de Aceptación:
- Objetivo: Validar si el sistema cumple con los requisitos de negocio y es adecuado para su despliegue.
- Responsables: Clientes, usuarios finales, propietarios del producto.
- Tipos de Prueba:
  - Prueba de Aceptación de Usuario (UAT): Usuarios finales.
  - Prueba Operativa: Personal de operaciones.
  - Prueba Contractual y Normativa: En base a contratos o regulaciones.
  - Pruebas Alfa/Beta: Usuarios externos para retroalimentación.

Resumen de Responsables y Tipos de Prueba:

Nivel de Prueba	Responsable	Tipos de Prueba
Prueba de Componente	Desarrolladores	Funcional, no funcional, estructural
Prueba de Integración	Desarrolladores/Testers	Funcional, no funcional, interfaces
Prueba de Sistema	Testers independientes	Funcional, no funcional (rendimiento, seguridad)
Prueba de Aceptación	Clientes, usuarios, operadores	Funcional, no funcional, contractual, normativa

Defectos Característicos por Nivel de Prueba

Prueba de Componente (o Unidad):
- Defectos comunes:
  - Errores en cálculos o lógica interna.
  - Condiciones no manejadas adecuadamente (por ejemplo, divisiones por cero).
  - Funcionalidad incorrecta dentro de un módulo o función.
  - Errores de límites de datos (overflow, underflow).
  - Defectos en el manejo de excepciones.
Prueba de Integración:
- Defectos de integración de componentes:
  - Datos incorrectos o mal formateados entre componentes.
  - Secuenciación incorrecta o sincronización de las llamadas entre interfaces.
  - Incompatibilidad de interfaces entre módulos.
  - Errores de comunicación no gestionados adecuadamente.
- Defectos de integración de sistemas:
  - Inconsistencias en la estructura de mensajes entre sistemas.
  - Fallos en la comunicación entre sistemas o servicios (por ejemplo, microservicios).
  - Suposiciones incorrectas sobre los datos transmitidos entre sistemas.
  - Incumplimiento de requisitos de seguridad en la interacción entre sistemas.
Prueba de Sistema:
- Defectos comunes:
  - Comportamiento incorrecto o inesperado del sistema.
  - Cálculos o procesamiento incorrecto de datos.
  - Flujos de datos y control incorrectos dentro del sistema.
  - Incapacidad para completar tareas funcionales extremo a extremo.
  - Fallos en entornos de producción simulados o reales.
  - El sistema no opera como lo indica la documentación o los manuales de usuario.
Prueba de Aceptación:
- Defectos comunes:
  - Los flujos de trabajo no cumplen con los requisitos de negocio o de usuario.
  - Las reglas de negocio no están implementadas correctamente.
  - El sistema no cumple con los requisitos contractuales o regulatorios.
  - Vulnerabilidades de seguridad.
  - Eficiencia de rendimiento inadecuada bajo carga.
  - Funcionamiento deficiente en plataformas o entornos operativos específicos.

Bases de Prueba por Nivel de Prueba

Prueba de Componente (o Unidad):
- Bases de prueba:
  - Diseño técnico del componente.
  - Código fuente.
  - Especificaciones detalladas del componente.
  - Modelos de clases, diagramas de flujo o pseudocódigo.
  - Casos de prueba unitarios definidos por los desarrolladores.
Prueba de Integración:
- Bases de prueba para integración de componentes:
  - Diseño de software.
  - Especificaciones de interfaces y protocolos de comunicación.
  - Diagramas de secuencia.
  - Arquitectura a nivel de componentes.
- Bases de prueba para integración de sistemas:
  - Especificaciones de interfaces externas.
  - Casos de uso que involucren la interacción entre sistemas.
  - Modelos de arquitectura de sistema o microservicios.
  - Diagramas de flujo de trabajo entre sistemas.
Prueba de Sistema:
- Bases de prueba:
  - Especificaciones de requisitos del sistema (funcionales y no funcionales).
  - Casos de uso del sistema.
  - Épicas e historias de usuario.
  - Modelos de comportamiento del sistema (diagramas de estado, diagramas de actividad).
  - Manuales de usuario y documentación del sistema.
  - Informes de análisis de riesgos.
Prueba de Aceptación:
- Bases de prueba:
  - Requisitos de negocio y usuario.
  - Procesos de negocio documentados.
  - Normativas, contratos y estándares regulatorios.
  - Casos de uso a nivel de negocio.
  - Requisitos no funcionales (rendimiento, seguridad, usabilidad).
  - Documentación del sistema y manuales del usuario.
  - Procedimientos de instalación y despliegue.
  - Procedimientos de recuperación de desastres o copia de seguridad.

¿Te ha resultado útil??

0 / 0