ISTQB

Actividades y Tareas de Prueba

a) Planificación de la Prueba

Tareas principales: 

• Determinar el alcance y los riesgos.
•  Identificar los objetivos de la prueba y los criterios de salida.
• Adquirir y programar recursos de prueba: personas, infraestructura de prueba, presupuesto de prueba.

El producto de trabajo de esta fase es el plan de prueba o el plan maestro de prueba y acordado con todos los implicados relevantes.

b) Monitorización y Control de la Prueba

La monitorización de la prueba (o seguimiento de la prueba) implica la comparación continua del avance real con respecto al plan de prueba utilizando cualquier métrica de monitorización de la prueba definida en el plan de prueba.

El control de la prueba implica tomar las medidas (acciones) necesarias para cumplir los objetivos del plan de prueba (que puede actualizarse con el tiempo).

La monitorización y el control de la prueba se apoyan en la evaluación de los criterios de salida a los que se hace referencia como definición de hecho en algunos ciclos de vida.

Por ejemplo, la evaluación de los criterios de salida para la ejecución de la prueba como parte de un nivel de prueba dado puede incluir:

• Comprobar los resultados y los registros de la prueba en relación con los criterios de cobertura especificados.
• Evaluar el nivel de calidad de los componentes o sistemas en base a los resultados y los registros de prueba.
• Determinar si se necesitan más pruebas (por ejemplo, si las pruebas originalmente destinadas a alcanzar un cierto nivel de cobertura de riesgo de producto no lo alcanzaran, sería necesario redactar y ejecutar pruebas adicionales).

El avance de la prueba con respecto al plan se comunica a los implicados por medio de informes de avance de la prueba, incluyendo las desviaciones con respecto al plan y la información que permita apoyar cualquier decisión de interrumpir la prueba.

c) Análisis de la prueba

El análisis de la prueba consiste en revisar la información que describe lo que el sistema debe hacer (la base de prueba) para decidir qué se va a probar. El objetivo es identificar lo que se puede probar y establecer las condiciones de prueba de manera clara y medible.

Este proceso incluye las siguientes actividades clave:

1. Revisar la base de prueba: Se examinan documentos como:

   • Requisitos funcionales y no funcionales (lo que el sistema debe hacer).
   • Diagramas de diseño y arquitectura del sistema.
   • Código y estructuras internas (base de datos, interfaces).
   • Informes de análisis de riesgos (qué puede fallar).

2. Buscar errores en la base de prueba: Durante la revisión, se identifican problemas como:

   • Ambigüedades (no está claro lo que se pide).
   • Omisiones (algo importante no está mencionado).
   • Inconsistencias (partes del documento que se contradicen).
   • Errores o información innecesaria.

3. Definir qué probar: Se eligen las características más importantes para ser probadas y se priorizan según el riesgo o la importancia de esas funciones para el sistema.

4. Asegurar la trazabilidad: Se registra la relación entre los requisitos y las condiciones de prueba para verificar si se cubre todo lo necesario.

Además, se pueden aplicar técnicas como:

• Caja negra: Para verificar que el sistema cumple su función sin mirar cómo está construido internamente.
• Caja blanca: Para revisar el comportamiento interno del sistema.
• Basado en experiencia: Usando el conocimiento del probador para prever posibles fallos.

Al hacer un análisis de prueba detallado, también se puede encontrar errores en las primeras etapas, lo que es muy beneficioso, especialmente si no se han hecho revisiones formales antes.

d) Diseño de la prueba

El diseño de la prueba se encarga de transformar las condiciones de prueba (decididas durante el análisis) en casos de prueba que se utilizarán para verificar el sistema. En resumen, mientras que el análisis de la prueba decide qué se va a probar, el diseño de la prueba decide cómo se va a probar.

Las actividades clave en el diseño de la prueba incluyen:

1. Crear y priorizar casos de prueba: Se diseñan los casos de prueba, que son descripciones detalladas de las situaciones que se deben probar, y se priorizan según su importancia o riesgo.

2. Definir los datos de prueba: Se identifican los datos necesarios para ejecutar los casos de prueba de forma efectiva (por ejemplo, valores que simulan entradas o comportamientos reales).

3. Diseñar el entorno de prueba: Se define el entorno necesario para realizar las pruebas, como la infraestructura (hardware, software, herramientas) y cualquier recurso adicional.

4. Asegurar la trazabilidad: Se garantiza que los casos de prueba estén correctamente vinculados a los requisitos, condiciones de prueba y procedimientos para verificar que todo está cubierto.

Durante el diseño, es común utilizar técnicas de prueba (como pruebas de caja negra o caja blanca) para crear casos de prueba más precisos. Además, al igual que en el análisis, este proceso puede descubrir defectos en la base de prueba, lo cual es un gran beneficio ya que se corrigen errores antes de que afecten el sistema.

e) Implementación de la prueba

La implementación de la prueba asegura que todo esté listo para ejecutar las pruebas. Mientras que el diseño de la prueba define cómo se van a probar las cosas, la implementación se encarga de preparar todos los elementos necesarios para llevar a cabo la prueba.

Las actividades principales en la implementación de la prueba incluyen:

1. Desarrollar procedimientos de prueba: Se crean procedimientos detallados para ejecutar los casos de prueba, y si se usa automatización, se generan los guiones correspondientes.

2. Crear juegos de prueba: Se agrupan varios casos de prueba y guiones automatizados en juegos de prueba que se ejecutarán de manera eficiente.

3. Organizar la secuencia de pruebas: Se establece un calendario de ejecución para asegurar que las pruebas se realicen en el orden y tiempo adecuados.

4. Configurar el entorno de prueba: Se construye y configura el entorno necesario, como arneses de prueba, simuladores, o infraestructura técnica, y se verifica que todo esté listo.

5. Preparar los datos de prueba: Se cargan los datos que se usarán durante las pruebas en el entorno correspondiente.

6. Verificar la trazabilidad: Se revisa la trazabilidad para garantizar que todos los elementos (requisitos, casos de prueba, procedimientos) estén correctamente relacionados.

f) Ejecución de la prueba

La ejecución de la prueba es el proceso donde los casos de prueba se llevan a cabo siguiendo el calendario planificado. Las actividades principales durante la ejecución de la prueba son:

1. Registro de información relevante: Documentar los elementos probados (como versiones del software) y las herramientas utilizadas.
2. Ejecución de las pruebas: Se puede hacer manualmente o mediante herramientas automatizadas.
3. Comparación de resultados: Comparar los resultados obtenidos con los resultados esperados para determinar si las pruebas pasan o fallan.
4. Análisis de anomalías: Identificar las causas de los fallos, como defectos en el código o falsos positivos.
5. Informar sobre defectos: Registrar los problemas encontrados para que puedan ser corregidos.
6. Registro del estado de la prueba: Marcar si la prueba fue exitosa, fallida o bloqueada.
7. Reejecución de pruebas: Repetir las pruebas después de corregir defectos o realizar pruebas adicionales, como regresión o confirmación.
8. Actualización de la trazabilidad: Mantener la conexión entre la base de prueba, los casos de prueba y los resultados.

Este proceso asegura que las pruebas se realicen correctamente y que se puedan identificar y corregir defectos.

g) Compleción de la prueba

La compleción de la prueba es la fase final en el proceso de pruebas, donde se recopilan todos los datos y experiencias para cerrar formalmente las actividades de prueba. Las actividades principales incluyen:

1. Cierre de defectos: Asegurarse de que todos los defectos estén resueltos o, si no es posible, documentar los que siguen pendientes para futuras revisiones.
2. Informe resumen: Crear un informe que resuma los resultados de la prueba y compartirlo con los implicados.
3. Archivado: Guardar el entorno de prueba, datos y productos para posibles reutilizaciones.
4. Transferencia de productos: Entregar productos de prueba útiles a los equipos de mantenimiento o a otros proyectos.
5. Lecciones aprendidas: Evaluar qué funcionó y qué no, para mejorar en futuras pruebas o proyectos.
6. Mejorar el proceso: Usar toda la información para hacer más eficiente y madura la gestión de pruebas en el futuro.

Esta fase asegura que todo quede bien documentado y que el conocimiento adquirido sea útil para proyectos futuros.

Modelos de ciclo de vida de desarrollo 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.

Desarrollo Secuencial:

• Flujo lineal: Las actividades (como requisitos, diseño, desarrollo y pruebas) se realizan una tras otra. No se pasa a la siguiente fase hasta que la anterior esté completamente terminada.
• Modelo en Cascada: Un ejemplo típico de este tipo. Aquí, las pruebas solo ocurren al final, después de que se haya completado todo el desarrollo. Esto puede retrasar la detección de errores hasta las últimas etapas.
• Modelo en V: A diferencia del Cascada, las pruebas están integradas en cada fase del desarrollo. Por ejemplo, mientras se diseñan los requisitos, ya se pueden planear las pruebas de aceptación. Esto permite aplicar el principio de «pruebas tempranas» (detectar fallos lo antes posible). Aunque las pruebas se planifican antes, su ejecución sigue siendo secuencial.

Ventajas:

• Aseguran que todo el software esté terminado y probado antes de la entrega.
• Ideal para proyectos con requisitos claros y fijos desde el principio.

Desventajas:

• Puede tomar meses o años antes de tener un producto completo.
• Los errores pueden detectarse muy tarde en el proceso, lo que puede ser costoso de corregir.

Desarrollo Iterativo e Incremental:

• Aquí, el software se desarrolla en partes (o incrementos), y cada parte se diseña, construye y prueba. No tienes que esperar hasta que todo esté terminado; el sistema va creciendo poco a poco.
• Incremental: El sistema se construye por partes (incrementos). Cada incremento añade nuevas funciones o mejoras al sistema.
• Iterativo: Se repite el ciclo de desarrollo (requisitos, diseño, desarrollo y pruebas) en varias rondas o iteraciones. Con cada iteración, el software se mejora, ajusta y expande.

Ejemplos de metodologías iterativas/incrementales:

• Rational Unified Process (RUP): Iteraciones largas (2-3 meses), con grandes grupos de funcionalidades. Se adapta mejor a proyectos complejos.
• Scrum: Iteraciones más cortas (días o semanas). Cada iteración añade pequeñas funcionalidades o mejoras. Es muy común en equipos ágiles.
• Kanban: No necesariamente tiene iteraciones fijas. Las funcionalidades se liberan cuando están listas.
• Espiral o Prototipado: Se desarrollan incrementos experimentales. A veces se prueba algo, se abandona o se ajusta en la siguiente iteración.

Ventajas:

• Puedes entregar software funcional en semanas o días, aunque solo con una parte de las funcionalidades.
• Permite ajustarse mejor a los cambios en los requisitos durante el desarrollo.
• Detecta y corrige errores desde el principio, lo que ahorra tiempo y costos.

Desventajas:

• El software completo con todas las funcionalidades puede tardar meses o años en estar listo.
• Se necesita más organización, ya que las pruebas se ejecutan en cada iteración.

Comparación clave:

• Desarrollo Secuencial:

  • Se entrega el software completo al final, pero puede llevar mucho tiempo.
  • Las pruebas tienden a ejecutarse solo al final, lo que retrasa la identificación de errores.

• Desarrollo Iterativo e Incremental:

  • Se entrega el software por partes, en iteraciones más cortas.
  • Las pruebas se realizan en cada iteración, lo que permite detectar errores antes y ajustar el desarrollo en función de los resultados.

Diferencias entre los Niveles de Prueba

1. 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).

2. 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).

3. 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).

4. 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:

Defectos Característicos por Nivel de Prueba

1. 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.

2. 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.

3. 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.

4. 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

1. 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.

2. 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.

3. 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.

4. 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.

Proceso de Revisión de Productos de Trabajo

El proceso de revisión de productos de trabajo consta de cinco actividades principales:

1. Planificar:
   • Se define el alcance, objetivos y elementos a revisar.
   • Se estima el esfuerzo y se seleccionan los participantes.
   • Se establecen criterios de entrada y salida para revisiones formales.
2. Iniciar Revisión:
   • Se distribuye el material necesario.
   • Se explica el proceso a los participantes.
3. Revisión Individual:
   • Cada participante revisa el producto de trabajo por su cuenta.
   • Se identifican posibles defectos y recomendaciones.
4. Comunicar y Analizar Cuestiones:
   • Se discuten los hallazgos en grupo.
   • Se evalúan los defectos y la calidad del producto.
   • Se decide si el producto se acepta, necesita cambios o se rechaza.
5. Corregir e Informar:
   • Se corrigen los defectos encontrados.
   • Se documentan las correcciones y se actualizan los estados.
   • Se verifica si se cumplen los criterios de salida.

Este proceso ayuda a mejorar la calidad de los productos de trabajo, detectando y corrigiendo defectos de manera sistemática. Es importante porque permite identificar problemas temprano en el ciclo de desarrollo, lo que ahorra tiempo y recursos a largo plazo.

Roles y Responsabilidades en una Revisión Formal

Una revisión formal típicamente incluye estos roles principales:

1. Autor (bajo revisión) – crear:
   • Crea el producto de trabajo.
   • Corrige los defectos identificados.
2. Dirección – supervisar:
   • Planifica la revisión y decide la ejecución de las revisiones.
   • Asigna recursos y supervisa la rentabilidad.
   • Toma decisiones cuando los resultados no son adecuados.
3. Facilitador (o Moderador):
   • Asegura que las reuniones de revisión sean efectivas.
   • Media entre diferentes puntos de vista.
   • Es clave para el éxito de la revisión.
4. Líder de Revisión – organizar:
   • Tiene la responsabilidad general de la revisión.
   • Decide quién participa y organiza cuándo y dónde se realizará.
5. Revisores – detectar:
   • Pueden ser expertos en la materia o personas del proyecto.
   • Identifican posibles defectos en el producto.
   • Representan diferentes perspectivas (probador, programador, usuario, etc.).
6. Escriba (o Grabador):
   • Recopila los defectos encontrado y registra nuevos defectos.

Tipos de Revisión

1. Revisión Informal:
   • Objetivo principal: Detectar defectos potenciales
   • Proceso: No formal, sin documentación necesaria
   • Participantes: Puede ser solo un compañero del autor
   • Características: Flexible, rápida, común en desarrollo Ágil
2. Revisión Guiada:
   • Objetivos: Detectar defectos, mejorar el producto, considerar alternativas
   • Proceso: Semi-formal, dirigida por el autor
   • Participantes: Requiere un escriba
   • Características: Puede incluir escenarios o simulaciones
3. Revisión Técnica:
   • Objetivos: Lograr consenso, detectar defectos
   • Proceso: Más formal, preparación individual requerida
   • Participantes: Pares técnicos y expertos
   • Características: Reunión opcional, facilitador recomendado
4. Inspección:
   • Objetivos: Detectar defectos, evaluar calidad, prevenir futuros defectos
   • Proceso: Muy formal, con roles definidos y criterios de entrada/salida
   • Participantes: Roles específicos, incluyendo facilitador capacitado
   • Características: Usa métricas, sigue un proceso definido, resultados documentados formalmente

Puntos clave para diferenciarlos:

• Nivel de formalidad: Aumenta desde la Revisión Informal hasta la Inspección
• Preparación requerida: Mínima en Informal, extensa en Inspección
• Roles de los participantes: Más definidos y especializados en las revisiones más formales
• Documentación: Aumenta con la formalidad del proceso
• Objetivos: Se vuelven más amplios y específicos en las revisiones más formales

Recuerda que un mismo producto puede pasar por varios tipos de revisión, generalmente empezando por las más informales y progresando hacia las más formales.

Aplicación de Técnicas de Revisión

Análisis de impacto

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.

Tareas del jefe de pruebas y el probador

El jefe de pruebas (test manager) se encarga de planificar, monitorizar y controlar las actividades de prueba.

• Redacción y/o revisión de la política de prueba y de la estrategia genérica de prueba.
• Organizar el equipo de prueba (desarrollo de habilidades y carreras, probadores de apoyo).
• Planificación de la prueba (de acuerdo con la política de pruebas y la estrategia de pruebas genéricas).
• Planificación de los ciclos de prueba.
• Enfoque de prueba, incluida la decisión sobre la automatización de pruebas (selección e implementación de herramientas) y entornos de prueba.
• Inicio de actividades de prueba (análisis, diseño, implementación, ejecución de pruebas y comprobación del estado de los criterios de salida).
• Monitorización y gestión del avance de la prueba.
• Introducción de un sistema de gestión de defectos y configuración adecuados.
• Informe de avances y resultados para los implicados, incluyendo la promoción y defensa de los evaluadores, el equipo de prueba y la profesión de la prueba dentro de la organización.

¿Quién asume el papel de jefe de prueba?

La forma en que se lleva a cabo la función de jefe de prueba varía en función
del ciclo de vida de desarrollo de software.

Ciclo de vida de desarrollo secuenciales, el rol de jefe de
prueba puede ser ejecutado por un jefe de prueba profesional, un jefe de
proyecto, un jefe de desarrollo o un jefe de calidad (declaración del formador:
En proyectos de mayor envergadura, algunas de las tareas están a cargo de coordinadores de pruebas que coordinan pequeños equipos de probadores.

Desarrollo Ágil: algunas de las tareas del gerente de pruebas son asumidas
por el equipo de Ágil.

Las tareas relacionadas con las pruebas diarias realizadas en el equipo, a menudo por un probador que trabaja en el equipo.

Las tareas que abarcan varios equipos o toda la organización, o que tienen que ver con la gestión de personal, pueden ser realizadas por jefes de prueba fuera del equipo de desarrollo (llamados entrenadores de prueba).

El probador (tester) se encarga de la parte operativa, análisis, diseño y ejecución de las pruebas.

• Análisis: Revisar los requisitos, historias de usuario y especificaciones para identificar las condiciones de prueba.
• Diseño: Crear casos de prueba, escenarios y definir los datos de prueba necesarios.
• Ejecución: Llevar a cabo las pruebas, comparar los resultados reales con los esperados y reportar los defectos encontrados.

Tareas:

• Asiste en la implementación de actividades de planificación de la prueba y revisa el plan de prueba.
• Analiza, revisa y evalúa la base de pruebas para determinar si es puede ser probada.
• Realiza el diseño del caso de prueba y la ejecución de la prueba (incluyendo la evaluación de los resultados e incluyendo las características funcionales y no funcionales).
• Prepara y crea datos de prueba.
• Revisa los casos de prueba diseñados por otros probadores.
• Ayuda a informar sobre la prueba.
• Ayuda en la implementación de la automatización de pruebas.
• Realizar tareas relacionadas con la automatización de pruebas y la
  infraestructura de pruebas.

Soporte de Herramientas para el Proceso de Prueba

• Gestión de pruebas: Usa herramientas ALM y de gestión de requisitos para planificar, rastrear y organizar pruebas y defectos.
• Pruebas estáticas: Herramientas de análisis y apoyo a revisiones para detectar errores sin ejecutar el código.
• Diseño e implementación: Herramientas de diseño de pruebas y datos de prueba ayudan a crear casos y datos de prueba eficaces.
• Ejecución y registro: Herramientas de regresión y cobertura para ejecutar pruebas y documentar resultados.
• Pruebas especializadas: Herramientas específicas como para rendimiento, usabilidad, seguridad y accesibilidad.