1. Gestión de las Actividades de Prueba

Duración: 750 minutos

Palabras Clave

En la siguiente tabla se presentan las palabras clave del capítulo. En este documento, se identifican dos tipos de palabras clave: PROCESO (que identifican palabras clave del proceso de prueba general) y ESPDOM (que identifican palabras clave específicas de dominio).

Tipo Palabra Clave	Español	Inglés
PROCESO	prueba basada en la experiencia	experience-based testing
PROCESO	prueba funcional	functional testing
ESPDOM	métrica de pregunta objetivo (MPO)	goal question metric (GQM)
PROCESO	modelo híbrido de desarrollo de software	hybrid software development model
ESPDOM	IDEAL	IDEAL
PROCESO	mejora	improvement
PROCESO	modelo de desarrollo incremental	incremental development model
ESPDOM	indicador	indicator
PROCESO	modelo de desarrollo iterativo	iterative development model
ESPDOM	medida	measure
ESPDOM	métrica	metric
PROCESO	prueba no funcional	non-functional testing
PROCESO	riesgo de producto	product risk
PROCESO	riesgo de calidad	quality risk
PROCESO	retrospectiva	retrospective
PROCESO	análisis del riesgo	risk analysis
PROCESO	evaluación del riesgo	risk assessment
PROCESO	identificación del riesgo	risk identification
PROCESO	impacto del riesgo	risk impact
PROCESO	nivel de riesgo	risk level
PROCESO	probabilidad del riesgo	risk likelihood
PROCESO	gestión del riesgo	risk management
PROCESO	mitigación del riesgo	risk mitigation
PROCESO	monitorización del riesgo	risk monitoring
PROCESO	prueba basada en el riesgo	risk-based testing
PROCESO	metodología por objetivos S.M.A.R.T.	S.M.A.R.T. goal methodology
PROCESO	modelo de desarrollo secuencial	sequential development model
PROCESO	ciclo de vida de desarrollo del software	software development lifecycle
PROCESO	compleción de la prueba	test completion
PROCESO	control de prueba	test control
PROCESO	nivel de prueba	test level
PROCESO	Test Maturity Model integration	Test Maturity Model integration
PROCESO	monitorización de la prueba	test monitoring
PROCESO	objetivo de prueba	test objective
PROCESO	plan de prueba	test plan
PROCESO	planificación de la prueba	test planning
PROCESO	proceso de prueba	test process
PROCESO	estrategia de prueba	test strategy
PROCESO	tipo de prueba	test type
PROCESO	TPI NEXT	TPI NEXT

Objetivos de Aprendizaje para «Capítulo 1»

1.1 El proceso de Prueba

TM-1.1.1 (K2): Resumir la planificación de la prueba.
TM-1.1.2 (K2): Resumir la monitorización de la prueba.
TM-1.1.3 (K2): Resumir la compleción de la prueba.

1.2 El Contexto de la Prueba

TM-1.2.1 (K2): Comparar por qué los distintos implicados están interesados en la prueba.
TM-1.2.2 (K2): Explicar por qué es importante el conocimiento de los implicados en la gestión de la prueba.
TM-1.2.3 (K2): Explicar la prueba en un modelo híbrido de desarrollo de software.
TM-1.2.4 (K2): Resumir las actividades de gestión de la prueba para varios ciclos de vida de desarrollo del software.
TM-1.2.5 (K2): Comparar las actividades de gestión de la prueba en varios niveles de prueba.
TM-1.2.6 (K2): Comparar las actividades de gestión de la prueba para varios tipos de prueba.
TM-1.2.7 (K4): Analizar un proyecto dado y determinar las actividades de gestión de la prueba que enfaticen la planificación de la prueba, la monitorización de la prueba y el control de la prueba.

1.3 Prueba Basada en el Riesgo

TM-1.3.1 (K2): Explicar las distintas medidas que se toman en la prueba basada en el riesgo para responder a riesgos.
TM-1.3.2 (K2): Aportar ejemplos de las distintas técnicas que puede utilizar un jefe de prueba para identificar riesgos relacionados con la calidad del producto.
TM-1.3.3 (K2): Resumir los factores que determinan los niveles de riesgo relacionados con la calidad del producto.
TM-1.3.4 (K4): Seleccionar las actividades de prueba adecuadas para mitigar los riesgos en función de su nivel de riesgo en un contexto determinado.
TM-1.3.5 (K2): Diferenciar entre ejemplos pesados y ligeros de técnicas de prueba basadas en el riesgo.
TM-1.3.6 (K2): Aportar ejemplos de métricas de éxito y dificultades asociadas a la prueba basada en el riesgo.

1.4 La Estrategia de Prueba del Proyecto

TM-1.4.1 (K2): Explicar las opciones típicas de un enfoque de prueba.
TM-1.4.2 (K4): Analizar una estrategia de prueba organizativa y el contexto del proyecto para seleccionar el enfoque de prueba adecuado.
TM-1.4.3 (K3): Utilizar la metodología de objetivos S.M.A.R.T. para definir objetivos de prueba y criterios de salida medibles.

1.5 Mejora del Proceso de Prueba

TM-1.5.1 (K2): Explicar cómo utilizar el modelo de IDEAL para la mejora del proceso de prueba en un proyecto determinado.
TM-1.5.2 (K2): Resumir el enfoque de mejora de proceso basado en modelos y comprender cómo aplicarlo en el contexto de un proyecto.
TM-1.5.3 (K2): Resumir el enfoque de mejora del proceso basado en el análisis y comprender cómo aplicarlo en el contexto de un proyecto.
TM-1.5.4 (K3): Aplicar una retrospectiva de proyecto o de iteración para evaluar los procesos de prueba y descubrir áreas de prueba que puedan ser objeto de mejora.

1.6 Herramientas de prueba

TM-1.6.1 (K2): Resumir las buenas prácticas para la introducción de herramientas.
TM-1.6.2 (K2): Explicar el impacto de los diferentes aspectos técnicos y de negocio en la decisión sobre un tipo de herramienta.
TM-1.6.3 (K4): Analizar una situación dada para crear un plan para la selección de una herramienta que cubra riesgos, costes y beneficios.
TM-1.6.4 (K2): Diferenciar entre las etapas del ciclo de vida de una herramienta.
TM-1.6.5 (K2): Aportar ejemplos de recopilación y evaluación de métricas mediante el uso de herramientas.

1.1 El Proceso de Prueba

Introducción

El programa de estudio de Probador Certificado de Nivel Básico V4.0 describe un proceso de prueba que incluye las siguientes actividades: planificación de la prueba, monitorización y control de la prueba, análisis de la prueba, diseño de la prueba, implementación de la prueba, ejecución de la prueba y compleción de la prueba.

El programa de estudio de Probador Certificado de Nivel Básico V4.0 establece que estas actividades del proceso de prueba a menudo se implementan de forma iterativa o en paralelo, dependiendo del modelo del ciclo de vida de desarrollo del software (CVDS) y del contexto del proyecto. Normalmente es necesario adaptar estas actividades dentro del contexto del producto y del proyecto.

En este programa de estudio, la atención se centra en las siguientes actividades clave de gestión de la prueba:

Planificación de la prueba: definir los objetivos de la prueba, el enfoque de la prueba, el alcance de la prueba, los recursos de la prueba, el calendario de la prueba, los entregables de la prueba y los participantes en la prueba (implicados de la prueba).
Monitorización y control de la prueba: seguimiento del avance, los resultados y las desviaciones de la prueba; adopción de medidas correctivas cuando sea necesario; suministro de información sobre el estado y los resultados de la prueba a los implicados relevantes.
Compleción de la prueba: finalización y archivo de los artefactos de la prueba, evaluación del proceso de prueba y del producto de la prueba, identificación de las acciones de mejora del proceso de prueba y comunicación del cierre de la prueba a las partes interesadas pertinentes.

La norma ISO/IEC/IEEE 29119-2 define los procesos de gestión de la prueba que cubren estas actividades de gestión de la prueba. Estos procesos de gestión de la prueba pueden aplicarse a diferentes niveles de prueba, como proyecto, programa o cartera. Cada nivel de prueba puede tener su propio plan de prueba que se alinee con el plan de prueba de nivel superior.

Actividades de Planificación de la Prueba

Esta sección se centra en las actividades de planificación de la prueba para distintos alcances, como todo el proyecto, un nivel de prueba, un tipo de prueba o una entrega / iteración / esprint en Ágil. Dependiendo del alcance, la planificación de la prueba puede comenzar y terminar en diferentes puntos del proceso de desarrollo. La planificación de la prueba es una actividad que consiste en identificar las actividades y los recursos necesarios para alcanzar los objetivos de prueba identificados en la política de prueba. La planificación de la prueba debe iniciarse lo antes posible en el proceso de desarrollo, preferiblemente antes de que se identifiquen los requisitos, y debe actualizarse a medida que avanza el proyecto. La planificación de la prueba suele ser un proceso iterativo que requiere una nueva planificación durante el proyecto para adaptarse a los cambios y a la retroalimentación.

Las siguientes tareas forman parte de la planificación de la prueba (similares a las que se encuentran en la norma ISO/IEC/IEEE 29119-2):

Comprender el contexto y organizar la planificación de la prueba.
Comprender el contexto de la organización (por ejemplo, la política de prueba y la estrategia de prueba de la organización), el alcance de la prueba y el elemento de prueba (es decir, el producto de trabajo que se está probando) es fundamental para la planificación de la prueba (véase el apartado 1.2., El contexto de la prueba). También implica todas las actividades necesarias para organizar el desarrollo del plan de prueba y obtener la aprobación de esas actividades y del calendario por parte de los implicados (por ejemplo, el propietario del producto, el jefe de proyecto o el director del equipo de desarrollo).
Identificar y analizar los riesgos de producto.
El análisis del riesgo implica identificar y evaluar el impacto potencial y la probabilidad de los riesgos de producto como parte de la planificación de la prueba. Para obtener más información sobre riesgos de producto, consulte la sección 1.3 de este programa de estudio, Prueba Basada en el Riesgo.
Identificar los enfoques de tratamiento de riesgos.
Se seleccionan los enfoques de tratamiento del riesgo adecuados en función del análisis del riesgo y se documentan en el plan de prueba. Estos pueden incluir acciones preventivas, correctivas o paliativas para abordar los riesgos identificados.
Definir el enfoque de prueba, estimar y asignar los recursos de prueba.
Se define el enfoque de prueba para el alcance actual de la prueba en función de la estrategia de prueba de la organización, las normas reglamentarias, las limitaciones impuestas por el proyecto y los enfoques de tratamiento de riesgos (véase el apartado 1.4, Estrategia de prueba del proyecto). Cuando se define un enfoque de prueba, es importante estimar los recursos de prueba necesarios, como el personal de prueba, las herramientas de prueba, los entornos de prueba y los datos de prueba, y asignar esos recursos a las actividades de prueba.
Establecer el plan de prueba.
El plan de prueba debe ser aceptado por todos los implicados y, por lo tanto, se deberían resolver los desacuerdos entre ellos.

Actividades de Monitorización y Control de la Prueba

Para que la gestión de la prueba proporcione un control eficiente de la misma, debe establecerse un calendario de prueba y un marco de monitorización que permita el seguimiento del estado y el avance de la prueba. Este marco debe incluir las medidas detalladas y los objetivos necesarios para relacionar el estado de los productos de trabajo y los recursos de la prueba con el plan y los objetivos estratégicos.

Para los proyectos pequeños y menos complejos, puede ser relativamente fácil relacionar los productos del trabajo de prueba y las actividades con el plan y los objetivos estratégicos, pero por lo general deben definirse objetivos más detallados para lograrlo. Esto puede incluir la definición de medidas y metas necesarias para cumplir los objetivos de prueba y la cobertura de la base de prueba.

La necesidad de relacionar el estado de los productos del trabajo de prueba y las actividades de una manera que sea comprensible y relevante para el proyecto y los implicados del negocio es un aspecto de particular importancia.

La monitorización y el control de la prueba son actividades continuas.

El control de prueba compara el avance real con el plan de prueba e implementa las acciones correctivas necesarias. Guía la prueba para cumplir las estrategias y los objetivos de la prueba (véase la sección 1.4, La estrategia de prueba del proyecto), y vuelve a examinar las actividades de planificación de la prueba cuando es necesario. Los datos de control requieren información detallada sobre la planificación de la prueba para poder reaccionar adecuadamente. Esta actividad implica:

Gestionar las desviaciones de la prueba planificada.
Tratar los riesgos recientemente identificados y modificados.
Establecer la preparación para comenzar la prueba.
Conceder y obtener la aprobación para la compleción de la prueba basándose en los criterios de salida.

La monitorización de la prueba implica recopilar y registrar los resultados de la prueba, identificar las desviaciones de la prueba planificada, identificar y analizar los nuevos riesgos que requieren pruebas y monitorizar los cambios para los riesgos identificados.

Actividades de Compleción de la Prueba

La compleción de la prueba tiene lugar normalmente en hitos del proyecto (por ejemplo, una entrega, el final de una iteración o la compleción del nivel de prueba). Se crean solicitudes de cambio o elementos de la lista de trabajo acumulado del producto para cualquier defecto no resuelto. Véase el programa de estudio de nivel básico V.4. Una vez cumplidos los criterios de salida, se deberían capturar, archivar y proporcionar las salidas clave a los implicados relevantes. La compleción de la prueba requiere las siguientes tareas:

Crear y aprobar el informe de compleción de la prueba.
Esta tarea asegura que se ha realizado toda la prueba y que se han cumplido todos los objetivos de prueba. Esta tarea implica la recopilación de información relevante de diversos productos de prueba, como planes de prueba, resultados de prueba, informes de avance de prueba, informes de compleción de prueba e informes de defectos. La información recopilada se evalúa y se resume en el informe de compleción de la prueba. El informe de compleción se aprueba y se comunica a los implicados relevantes.
Archivar los productos de prueba.
Esta tarea identifica los productos de prueba que pueden ser útiles en el futuro o que se espera que sean reutilizados, que normalmente son casos de prueba. Los hace accesibles y fáciles de ser entendidos para su futura reutilización. Además, los resultados de la prueba, los registros de prueba, los informes de prueba y otro material de prueba deben archivarse temporalmente en el sistema de gestión de la configuración.
Entrega del producto de prueba.
Esta tarea entrega productos de trabajo valiosos a quienes los necesitan. Por ejemplo, los defectos conocidos aplazados o aceptados deben comunicarse a quienes vayan a utilizar o apoyar el uso del producto de prueba.
Realizar todas las tareas necesarias para limpiar el entorno de prueba y restaurarlo a un estado predefinido.
Esta tarea asegura que el entorno de prueba esté listo para el siguiente ciclo de prueba o proyecto. Consiste en eliminar todos los datos de prueba, herramientas de prueba, controladores de prueba, stubs de prueba y guiones de prueba del entorno de prueba. También implica restaurar el entorno de prueba a su estado original o deseado.
Realizar/recopilar/documentar las lecciones aprendidas.
Esta tarea se realiza en retrospectivas en las que se discuten y documentan las lecciones importantes aprendidas durante el proceso de prueba. Esto puede incluir hallazgos para todo el ciclo de vida de desarrollo de software (SDLC). Las lecciones aprendidas pueden utilizarse para la mejora del proceso de prueba, como se describe en la sección 1.5. de este programa de estudio, Mejora del proceso de prueba.

1.2 El Contexto de la Prueba

El contexto de la prueba engloba las condiciones y restricciones únicas que influyen en el proceso de prueba, dando forma a las decisiones y estrategias de planificación, diseño y ejecución de las pruebas. Es vital que los jefes de prueba comprendan este contexto para alinear la prueba con las necesidades y objetivos específicos del proyecto de desarrollo de software. Este contexto puede diferir en función del tipo de producto, la industria, los requisitos normativos y, sobre todo, el ciclo de vida de desarrollo de software (CVDS) que se esté empleando.

Los jefes de prueba se encargan de aplicar las estrategias de prueba establecidas y de elegir las técnicas de prueba en lugar de desarrollarlas. Desempeñan un rol clave en la formulación de planes de prueba adaptados al contexto del proyecto. Al comprender y tener en cuenta estos diversos factores, los jefes de prueba pueden asegurar que la prueba sea pertinente, eficaz y eficiente a la hora de cumplir los objetivos de la prueba.

Implicados de la Prueba

Los implicados de la prueba son personas o grupos con un interés directo o indirecto en la calidad del producto. A continuación, se presenta una lista de implicados potenciales típica, modificada para reflejar sus diversos intereses en el proceso de prueba:

Desarrolladores, líderes de desarrollo y directores de desarrollo: Además de implementar el sistema sometido a prueba y actuar en función de los resultados de la prueba, estos implicados también participan en la prueba unitaria y contribuyen al proceso de prueba.
Probadores, líderes de prueba y jefes de prueba: Estas personas preparan el software de prueba, lo que incluye el desarrollo de planes de prueba y contribuir al proceso de prueba a través de actividades como el análisis de requisitos, diseño de prueba, ejecución de prueba, seguimiento e informe de defectos, automatización de la prueba e informe del avance de la prueba.
Jefes de proyecto, propietarios de producto y usuarios de negocio: Especifican los requisitos, definen el nivel de calidad exigido y recomiendan la cobertura necesaria en función de los riesgos percibidos. También revisan los productos del trabajo, participan en la prueba de aceptación de usuario (PAU) y toman decisiones basadas en los resultados de las pruebas.
Equipo de operaciones: Participan en las pruebas de aceptación operativa, garantizan que el sistema está listo para la producción y contribuyen a definir los requisitos no funcionales.
Clientes y usuarios: Los clientes compran el producto, mientras que los usuarios lo utilizan directamente. Ambos son clave en la definición de los requisitos y deben participar en la prueba de aceptación de usuario (PAU) para validar que el producto satisface sus necesidades.

Esta lista no incluye a todos los implicados potenciales. Los jefes de prueba deben realizar un análisis de los implicados como parte de la creación de la estrategia de prueba y del plan de prueba, teniendo en cuenta el alcance de la prueba en la identificación de los implicados específicos para su proyecto.

Importancia del Conocimiento de los Implicados en la Gestión de la Prueba

En la gestión de la prueba, es crucial tener en cuenta las perspectivas y la influencia de los distintos implicados. La matriz de implicados, a menudo denominada matriz de poder-interés, orienta a los jefes de prueba a la hora de priorizar el compromiso de los implicados y gestionar las expectativas de forma eficaz. La matriz de implicados es una herramienta estratégica en la gestión de la prueba que:

Utiliza la experiencia de los implicados, con usuarios finales y equipos técnicos que aportan retroalimentación y puntos de vista sobre el rendimiento y la seguridad.
Apoya la gestión del riesgo destacando los intereses y la influencia de los implicados, fomentando los esfuerzos proactivos de mitigación.
Valora las diversas perspectivas con una retroalimentación de valor.

La matriz de implicados se compone de cuatro cuadrantes:

Promotores (Alto nivel de influencia, Alto nivel de interés): Colaboradores clave con alto nivel de influencia e interés, vitales para dar forma a la estrategia y el plan de prueba.
Latentes (Alto nivel de influencia, Bajo nivel de interés): Aunque puede que no tengan un gran interés en las tareas cotidianas, sus decisiones son fundamentales para la asignación de recursos y la dirección del proyecto a alto nivel.
Defensores (Bajo nivel de influencia, Alto nivel de interés): Suelen aportar retroalimentación cualitativa y se les puede mantener comprometidos mediante actualizaciones periódicas y la participación en debates específicos.
Apáticos (Bajo nivel de influencia, Bajo nivel de interés): Aunque no estén estrechamente implicados, ponerles al día sobre hitos significativos y solicitar su entrada sobre dificultades concretas puede aportar una perspectiva única.

El rol del jefe de prueba incluye la compilación de una lista detallada de implicados y la comprensión de la conexión de cada uno de ellos con las actividades de prueba, utilizando la matriz de implicados para mejorar la efectividad de las prácticas de gestión de la prueba.

Gestión de la Prueba en un Modelo Híbrido de Desarrollo de Software

Los modelos híbridos de desarrollo de software integran elementos tanto de los enfoques secuenciales tradicionales como de las prácticas ágiles para adaptarse a las necesidades específicas de un proyecto o a las transiciones organizativas. Las siguientes son razones comunes para utilizar un modelo de desarrollo de software híbrido, aunque dependiendo de la organización y del proyecto, también puede haber otras razones:

Híbrido como transición a Ágil:
La transición de las metodologías tradicionales a Ágil puede suponer un reto debido a los cambios fundamentales en el flujo de trabajo, la cultura y la dinámica del equipo. Los modelos híbridos ofrecen un enfoque equilibrado que facilita esta transición al combinar la estructura de los métodos tradicionales con la flexibilidad de las prácticas ágiles.
Híbrido como adecuado al propósito:
Algunas organizaciones o proyectos pueden no ser capaces de pasar a Ágil. Los proyectos de alto riesgo pueden requerir tareas secuenciales para algunas cosas y prácticas ágiles para otras. Pueden utilizar un modelo híbrido según se ajuste a su propósito.

En un entorno híbrido, las actividades de gestión de la prueba pueden incluir:

La evaluación de la comprensión y la capacidad del equipo para realizar una transición fluida entre las metodologías tradicional y ágil.
Identificar los puntos fuertes y débiles en la adaptación a un enfoque híbrido.
Asegurar que el equipo es experto (competente) en combinar procesos estructurados con flexibilidad ágil.
Mejorar la colaboración entre el equipo de prueba y los implicados para gestionar mejor las pruebas dentro de los esprints y las fases de prueba tradicionales.
Participar en esfuerzos coordinados, como esprint de alineación de probadores, para mantener el foco en la prueba a la vez que se contribuye a los objetivos generales de desarrollo.
Hacer un seguimiento y revisar los esfuerzos y casos de prueba dentro de los esprints para asegurar que se alinean con las prácticas ágiles.

Actividades de Gestión de la Prueba para varios Modelos de Ciclo de Vida del Desarrollo de Software

Para alinear adecuadamente la prueba dentro del modelo de ciclo de vida de desarrollo de software (CVDS), un jefe de prueba debe comprender los distintos modelos de CVDS utilizados en su organización y utilizar ese conocimiento para alinear adecuadamente la prueba con las actividades de desarrollo.

La tabla siguiente muestra una comparación entre varias actividades de gestión de la prueba basadas en diferentes modelos de ciclo de vida de desarrollo de software (CVDS):

Aspecto	Modelo de desarrollo secuencial (p. ej., V-Model)	Modelo de desarrollo iterativo (p. ej., Scrum)
Estimación	Estimación detallada temprana para cada nivel de prueba.	Estimación iterativa, parte de la planificación de historias por iteración.
Producto de prueba	Incluye estrategia, plan, casos, calendario e informes.	Se concentra en los criterios de aceptación y la definición de hecho (DoD); documentación mínima.
Roles	El jefe de prueba supervisa las decisiones y la gestión de la prueba.	Los roles están integrados; el facilitador o entrenador sustituye al jefe de pruebas tradicional.
Herramientas	Predominan las herramientas de gestión de la prueba adaptadas a las pruebas por fases.	Las herramientas para la integración continua/entrega continua (CI/CD) y la automatización son fundamentales.
Enfoque de Prueba	Planificadas con antelación, atendiendo a las fases del proyecto.	Integradas en las iteraciones, concentrándose en la adaptabilidad y la retroalimentación.
Automatización de la prueba	Implementada de forma estratégica, puede tener lugar en varias etapas.	Integrada desde el principio, con énfasis en la regresión automatizada en la integración continua/entrega continua (CI/CD).
Monitorización y suministro de información	Suministro de información basado en hitos, con cuadros de mando automatizados opcionales.	Suministro continuo de información con cuadros de mando en tiempo real y actualizaciones diarias de estado.
Métricas	Se concentra en las métricas tradicionales de las pruebas y en la gestión de defectos (por ejemplo, ejecución de pruebas, tasas de defectos).	Incluye métricas ágiles para el seguimiento de iteraciones, además de las métricas tradicionales (por ejemplo, velocidad del equipo, gráficos de burn-down).

Actividades de Gestión de la Prueba en Distintos Niveles de Prueba

Prueba de componente:

Definir el alcance, los objetivos y los criterios de compleción de la prueba de componente.
Involucrar a los probadores en actividades que vayan más allá de los roles de prueba tradicionales, como las revisiones de código, en las que sus competencias analíticas añaden valor.
Coordinar con el equipo de desarrollo la resolución de las dificultades y la contribución a las pruebas unitarias.
Prueba de integración de componentes:

Determinar las secuencias de integración y las combinaciones de pruebas en colaboración con el equipo de desarrollo, teniendo en cuenta el modelo de vida de desarrollo de software (CVDS), las herramientas y los procesos.
Supervisar el avance para asegurar que se alinea con las estrategias de pruebas de aceptación y de sistema.
Gestionar esta fase de forma cooperativa con los desarrolladores, teniendo en cuenta también las pruebas de integración de componentes.
Prueba de integración de sistemas:

Asegurar que el alcance y los objetivos de la prueba de integración de sistemas son claros y están en sintonía con la evaluación del riesgo y los objetivos de calidad.
Mantener la supervisión del avance, los resultados y la gestión de las dificultades durante la prueba de integración de sistemas.
Prueba de sistema:

Adaptar la planificación al modelo de ciclo de vida de desarrollo de software (CVDS), con una cuidadosa asignación de recursos, selección de herramientas y establecimiento de calendarios.
Para los proyectos ágiles, integrar la prueba de sistema con la prueba de historia iterativa, evitando fases de prueba distintas y asegurar que la prueba es continua e integrada. Mientras que, en los modelos secuenciales, las pruebas pueden seguir etapas planificadas.
Prueba de aceptación:

Colaborar con los implicados para revisar y confirmar el cumplimiento de los criterios de aceptación y planificar las actividades de prueba, incluida la gestión de la prueba de usuario en prueba de aceptación de usuario (PAU).
Coordinar la logística de las pruebas de aceptación, facilitando las pruebas en las instalaciones del cliente, para asegurar que el producto satisface las necesidades del negocio y los estándares de calidad fuera del entorno de desarrollo.
Facilitar la resolución de cualquier dificultad de la prueba de aceptación de usuario (PAU) y guiar a los implicados en el proceso de aprobación del producto una vez cumplidos los criterios de aceptación.

Actividades de gestión de la prueba para distintos tipos de prueba

Una gestión de la prueba eficaz requiere un enfoque integrado que tenga en cuenta las demandas únicas de las pruebas funcionales, no funcionales, de caja negra y de caja blanca. Para los jefes de prueba que se ocupan de la prueba funcional, la atención se concentra en asegurar que todas las funcionalidades se prueben en profundidad y cumplan los requisitos definidos. La gestión de la prueba no funcional gira en torno a la verificación de atributos del sistema como el rendimiento y la seguridad. La gestión de la prueba de caja negra implica asegurar que las pruebas se concentran en el usuario y que se cubren todas las interacciones externas posibles. La gestión de la prueba de caja blanca hace hincapié en la comprensión de la estructura del código y en asegurar que las pruebas cubran a fondo la lógica interna.

Gestión de la Prueba Funcional:

Planificación Estratégica y Seguimiento del Avance: elaboración de una estrategia de prueba detallada que se alinee con requisitos funcionales y los objetivos del proyecto, así como monitorizar el avance.
Coordinación de Recursos: Asignación eficaz de los recursos humanos y técnicos para cubrir todos los aspectos funcionales del sistema.
Gestión de la Prueba No Funcional:

Comparativa de rendimiento: Establecimiento de puntos de referencia de rendimiento y gestión de las actividades de prueba que evalúan el sistema en función de estos criterios.
Verificación de la conformidad: Supervisión de las pruebas que aseguran que el sistema cumple estándares no funcionales como la seguridad, la usabilidad y la fiabilidad.
Gestión de la Prueba de Caja Negra:

Análisis de Cobertura de la Prueba: Asegurar que las pruebas de caja negra cubren todos los escenarios de usuario y requisitos de negocio.
Incorporación de retroalimentación: Gestionar el proceso de recopilación de retroalimentación de los implicados para perfeccionar los enfoques de prueba de caja negra y la corrección de defectos.
Gestión de la Prueba de Caja Blanca:

Optimización de la Cobertura de Código: Supervisión del uso de herramientas de cobertura de código para identificar vacíos en la prueba de caja blanca y dirección de los recursos para abordar estas áreas.
Integración de conocimientos técnicos: Gestionar la incorporación de conocimientos técnicos en el proceso de planificación de la prueba, asegurando que las pruebas se diseñan comprendiendo el funcionamiento interno de la aplicación.

Actividades de Gestión de la Prueba para la Planificación, Monitorización y Control

La gestión eficaz de la prueba es la piedra angular del éxito de cualquier esfuerzo de prueba, que abarca una amplia gama de actividades que requieren una planificación cuidadosa, un seguimiento atento y un control estratégico. Los jefes de prueba desempeñan un papel fundamental a la hora de garantizar que el proceso de prueba no sólo sea eficaz y eficiente, sino que también se adapte a las exigencias específicas del proyecto en cuestión.

Planificación de la Prueba:

Definición integral del alcance: Un plan de prueba debe elaborarse meticulosamente, incorporando una definición rigurosa del alcance. Esto incluye la identificación de todos los requisitos funcionales y no funcionales para asegurar una cobertura completa de la prueba. También implica tener en cuenta las implicaciones de las metodologías de prueba de caja negra y de caja blanca, asegurando que los casos de prueba desarrollados sean capaces de validar el sistema a prueba desde todos los ángulos.
Evaluación del Riesgo y Plan de Mitigación: Una parte integral del plan de prueba es un marco sólido de gestión del riesgo. Los jefes de prueba deben llevar a cabo un análisis detallado de los riesgos, señalando las posibles vulnerabilidades y desafíos que podrían afectar tanto al flujo de trabajo del proyecto como al producto final. El desarrollo de estrategias de mitigación es crucial, e implica una planificación preventiva para eludir o minimizar estos riesgos de forma eficaz.
Estrategia de Asignación de Recursos: La planificación de los recursos es otro elemento crítico. Esto va más allá de la mera asignación para definir la estructura del equipo, delimitar los roles y establecer protocolos de comunicación. En los entornos en los que los equipos están distribuidos, como ocurre con los modelos en sitio/fuera de sitio, esto adquiere especial importancia para mantener la sincronía y asegurar una colaboración sin fisuras.
Monitorización de la Prueba:

Supervisión de la Ejecución: La monitorización desempeña un papel central en el proceso de gestión de la prueba. Implica una revisión continua de la ejecución de la prueba con respecto al plan establecido, el seguimiento del avance de los casos de prueba y la gestión de cualquier defecto que pueda surgir. Ajustar las prioridades de las pruebas en función de la evaluación del riesgo y de la evolución en tiempo real asegura que la prueba se mantiene concentrada y alineada con las áreas más críticas.
Optimización de Herramientas y Entornos: La selección y el uso con criterio de las herramientas de prueba y los entornos son cruciales para apoyar la estrategia de prueba. La monitorización continua garantiza que se integren eficazmente en la canalización de integración continua/entrega continua (CI/CD), lo que facilita las pruebas continuas y los bucles de retroalimentación inmediata que son vitales para el proceso de desarrollo ágil.
Colaboración con Desarrollo: Mantener una estrecha relación de trabajo con el equipo de desarrollo es esencial para obtener resultados de la prueba satisfactorios. Esta colaboración debe respaldar un enfoque integral de la prueba, aprovechando las perspectivas tanto de caja blanca como de caja negra para abordar de forma preventiva las posibles dificultades.
Control de prueba:

Gestión Adaptativa de Procesos: El control de la prueba consiste en ajustar dinámicamente el proceso de prueba en respuesta a las nuevas perspectivas, los retos y la evolución de la dinámica del proyecto. Requiere que el jefe de prueba sea receptivo y flexible, capaz de implementar cambios en el enfoque de prueba que reflejen el estado actual del proyecto.
Gestión de Puertas de Calidad: Un enfoque de gestión de puertas de calidad estructurado es fundamental. Esto incluye definir qué constituye una puerta de calidad dentro del ciclo de vida de la prueba y tomar decisiones informadas sobre el avance de la fase de prueba, que es fundamental para mantener la integridad del producto.

1.3 Prueba Basada en el Riesgo

Introducción

La prueba basada en el riesgo implica la identificación, evaluación, monitorización y mitigación del riesgo para impulsar la prueba. Estos riesgos son identificados por diversos implicados y pueden utilizarse para seleccionar y priorizar las pruebas. Cuanto más alto sea el nivel de riesgo, antes debería comenzar la prueba y más intenso y prolongado debería ser el esfuerzo de prueba.

La Prueba como Actividad de Mitigación del Riesgo

Un riesgo de producto es una situación potencial en la que pueden existir problemas de calidad en un producto. Cuando una prueba revela defectos, la prueba ha ayudado a mitigar el riesgo de producto al proporcionar el conocimiento de los defectos y las oportunidades para tratarlos antes de la entrega. Cuando la prueba no encuentra defectos, la prueba indica que el nivel de riesgo de producto es inferior al esperado.

Entre otras cosas, el jefe de prueba es responsable de ofrecer una evaluación correcta y fiable de la calidad del producto. Para ello, debe participar activamente en la gestión de riesgos del proyecto centrándose en los riesgos del proyecto relacionados con el aseguramiento de la calidad (por ejemplo, requisitos ambiguos que provoquen problemas importantes en la validación tardía, entornos de prueba insuficientes que obstruyan la ejecución de las pruebas).

La prueba basada en el riesgo concentra la prueba en los riesgos de calidad. Sigue el proceso genérico de gestión del riesgo, que consta de las siguientes actividades principales:

Análisis del riesgo, consistente en la identificación del riesgo y la evaluación del riesgo.
Control del riesgo, consistente en la monitorización del riesgo y la mitigación del riesgo.

Para concentrar la prueba en los riesgos de calidad, deben identificarse y evaluarse los riesgos de calidad. Para ser más eficaz, el análisis del riesgo debe incluir a diversos implicados. Al ser uno de los principales implicados en el análisis del riesgo de calidad, el jefe de prueba debe comprender y monitorizar estas actividades y ser capaz de moderarlas.

La monitorización de la prueba debe incluir la monitorización del riesgo. Además de monitorizar la evolución de los riesgos de calidad conocidos, debe incluir el análisis de cualquier riesgo de calidad nuevo y el ajuste del registro de riesgos.

El jefe de la prueba es una de las varias personas que impulsan la mitigación del riesgo de calidad. La mitigación del riesgo se distribuye entre varias actividades de prueba. Por ejemplo, los resultados del análisis del riesgo de calidad se utilizan en la planificación de la prueba para concentrar la prueba en las áreas correctas utilizando las técnicas correctas. En el análisis del riesgo, los niveles de riesgo guían la selección de las condiciones de prueba que deben cubrirse. En la ejecución de pruebas, la priorización basada en los riesgos rige la secuencia de ejecución de las pruebas.

Identificación de Riesgos de Calidad

La tarea del jefe de la prueba consiste en recopilar los riesgos de los implicados. Los implicados pueden identificar los riesgos de calidad mediante una o varias de las siguientes técnicas:

Entrevistas a expertos
Evaluaciones independientes
Retrospectivas
Talleres sobre riesgos
Tormentas de ideas
Listas de comprobación
Remitirse a experiencias pasadas

Al involucrar a la muestra más amplia posible de implicados, el proceso de identificación del riesgo suele identificar la mayoría de los riesgos de producto importantes. La identificación de los que deben participar en esta fase es muy importante. Es esencial asegurarse de que la lista de implicados participantes sea completa y acordada con el jefe de proyecto. Una identificación del riesgo que omita a implicados clave puede ser muy problemática. La clave está en asegurar que todos los implicados relevantes tengan la oportunidad de participar. Si no pueden participar, al menos deberían tener la oportunidad de delegar la tarea. Cuando los implicados clave no estén representados, se puede recurrir a una reunión de inicio para determinar si faltan.

En la prueba basada en el riesgo, es importante comprender que el riesgo no se distribuye uniformemente dentro de los objetos de prueba. Por ejemplo, los componentes orientados al cliente de una aplicación de autoservicio pueden tener riesgos de usabilidad muy diferentes de los componentes de administración. Identificar los riesgos individuales de los distintos elementos de prueba es una tarea importante en la planificación de la prueba.

La identificación del riesgo a menudo produce subproductos (es decir, la identificación de dificultades que no son riesgos de producto). Algunos ejemplos son las preguntas o dificultades generales sobre el producto o el proyecto, o los problemas en los documentos de referencia, como los requisitos y las especificaciones de diseño. Los riesgos de proyecto también suelen identificarse como un subproducto de la identificación del riesgo de calidad, pero no son el foco de la prueba basada en el riesgo. A menudo, el jefe de prueba puede desempeñar un papel importante a la hora de poner de relieve estos subproductos y dejar claro que la calidad es un asunto de interés para todos. Los requisitos deficientes o ausentes suelen ser un indicador de un problema más fundamental en la planificación y la preparación, ya que el aseguramiento de la calidad interviene en todo el ciclo de vida de desarrollo de software (CVDS).

Evaluación del Riesgo de Calidad

Una vez identificados los riesgos, se pueden evaluar. La evaluación del riesgo de calidad incluye la categorización de los riesgos por tipo (riesgo de producto o riesgo de proyecto) y por características de calidad afectadas.

La determinación del nivel de riesgo suele implicar la evaluación, para cada elemento de riesgo, de la probabilidad del riesgo y del impacto del riesgo.

Entre los factores que influyen en la probabilidad del riesgo para los riesgos de calidad se incluyen:

Complejidad de la tecnología, las herramientas o la arquitectura del sistema.
Madurez de la organización.
Las dificultades del personal en cuanto a competencias, disponibilidad, motivación o trabajo autónomo, incluido el conocimiento del ciclo de vida de desarrollo de software (CVDS) en uso.
Conflictos dentro del equipo.
Problemas contractuales con los proveedores.
Equipos distribuidos geográficamente.
Débil liderazgo directivo o técnico.
Presión de tiempo, recursos, presupuesto y gestión.
Falta de actividades tempranas de aseguramiento de la calidad.
Tasas de cambio elevadas de la base de prueba, el producto o el personal.

Factores que influyen en el impacto del riesgo:

Frecuencia de uso de la prestación afectada.
Criticidad de la prestación afectada.
Criticidad del objetivo de negocio afectado.
Daño a la reputación.
Pérdida de ingresos del negocio.
Posibles pérdidas financieras, ecológicas o sociales, o responsabilidad civil.
Sanciones legales civiles o penales.
Problemas de interconexión e integración.
Carencia de soluciones provisionales razonables.
Necesidades de protección.

El jefe de prueba combina la probabilidad del riesgo y el impacto del riesgo para determinar el nivel de riesgo.

Si el análisis del riesgo se basa en datos de riesgo amplios y estadísticamente válidos, lo apropiado es una evaluación cuantitativa. Por ejemplo, la probabilidad del riesgo puede expresarse como un porcentaje y el impacto del riesgo como una cantidad. En tal caso, el nivel de riesgo puede calcularse como el producto de estos dos factores. Sin embargo, normalmente, la probabilidad del riesgo y el impacto del riesgo sólo pueden determinarse cualitativamente en escalas ordinales, por ejemplo, como muy alto, alto, medio, bajo o muy bajo. Los valores de probabilidad del riesgo y de impacto del riesgo se combinan entonces a través de una matriz de riesgo para crear un nivel de riesgo agregado. Este nivel de riesgo agregado debe interpretarse como una calificación cualitativa y relativa sobre una escala ordinal.

A menos que el análisis del riesgo se base en datos de riesgo extensos y estadísticamente válidos, el análisis del riesgo será cualitativo, basado en las percepciones subjetivas de los implicados sobre la probabilidad del riesgo y su impacto.

Mitigación del riesgo de Calidad Mediante una Prueba Adecuada

En el desarrollo de software, la prueba es la actividad más importante de mitigación del riesgo de calidad y permite reducir la probabilidad de fallos. Otras posibles medidas de mitigación del riesgo son un plan de contingencia (por ejemplo, proporcionando soluciones provisionales), la transferencia del riesgo a un tercero (por ejemplo, el proveedor de un componente) o la aceptación del riesgo.

En la planificación de la prueba, el tiempo y el esfuerzo asociados al desarrollo y la ejecución de una prueba deben ser proporcionales al nivel de riesgo: Las pruebas para niveles de riesgo más elevados deben comenzar pronto y utilizar técnicas de prueba más rigurosas, mientras que las pruebas para niveles de riesgo más bajos pueden comenzar más tarde y deben utilizar técnicas de prueba menos rigurosas. Para mitigar mejor el riesgo global a través de la prueba, el jefe de prueba debe analizar los siguientes factores contextuales y seleccionar un enfoque de prueba que resulte adecuado:

Los elementos de prueba: Diferentes elementos de prueba dentro de un objeto de prueba pueden tener diferentes niveles del mismo tipo de riesgo, por lo que no es necesario probar un objeto de prueba con un rigor uniforme.
Las características de calidad: Los riesgos que afectan a características de calidad específicas deben mitigarse mediante tipos de prueba asociados que necesitan un esfuerzo de prueba, un entorno de prueba y unas competencias de prueba específicos.
Los niveles de prueba y los tipos de prueba: Algunos riesgos sólo pueden probarse dinámicamente en determinados niveles de prueba; otros, mediante pruebas estáticas (por ejemplo, análisis estáticos y revisiones de código para la mantenibilidad), o mediante una combinación de ambas (por ejemplo, mediante una revisión de la arquitectura y pruebas dinámicas del sistema integrado para detectar vulnerabilidades de seguridad). Probar cada elemento de prueba lo antes posible mitiga el riesgo de encontrar defectos críticos en una fase tardía del ciclo de vida, lo que provocaría mayores costes de fallo interno y retrasos.
El ciclo de vida de desarrollo de software (CVDS): Las actividades de prueba tienen sus propios criterios de entrada específicos. Los distintos CVDS los cumplen en diferentes momentos.
El equipo de prueba: Las personas más cualificadas deberían probar los elementos de prueba con los niveles de riesgo más elevados.
Los requisitos normativos: Algunos estándares relacionados con la seguridad (por ejemplo, el estándar IEC 61508) prescriben las técnicas de prueba y la cobertura requerida en función del nivel de integridad. El jefe de la prueba debe asegurar que se siguen estos estándares.

Además, el nivel de riesgo debe influir en las decisiones de control de calidad, como el uso de revisiones de productos de trabajo como los casos de prueba, el nivel de independencia de la prueba respecto al desarrollo y el alcance de las pruebas de regresión realizadas.

Durante la monitorización de la prueba y el control de la prueba, la prueba basada en el riesgo permite informar sobre el avance de la prueba en términos del nivel de riesgo residual en cualquier momento. Esto ayuda al equipo de desarrollo y a los implicados a monitorizar y controlar el desarrollo del software, incluida la toma de decisiones de entrega, basándose en el nivel de riesgo residual. Para ello es necesario informar de los resultados de prueba en términos de riesgos de una manera que las partes implicadas puedan entender.

Durante la implementación de pruebas, la priorización de las pruebas se basa en los niveles de riesgo. Durante la ejecución de pruebas, esto asegura la cobertura temprana de las áreas más críticas y la mitigación de los riesgos de mayor nivel.

En algunos casos, las pruebas se priorizan para su ejecución en estricto orden descendente de los niveles de riesgo que cubren, empezando por el más alto. Este enfoque se denomina profundidad primero y es apropiado cuando es importante mitigar los riesgos de más alto nivel lo antes posible.

Alternativamente, se asigna la máxima prioridad al menos a una prueba para cada riesgo. Todas las demás pruebas se priorizan en función de sus niveles de riesgo cubiertos. Este enfoque se denomina primero amplitud (breadth-first) y es apropiado cuando los implicados desean tener una visión global de la calidad del producto lo antes posible. En la práctica, las pruebas suelen comenzar con el enfoque de profundidad primero, pero a medida que el tiempo se vuelve más limitado, se pasa al enfoque de amplitud primero, probando todos los elementos de riesgo restantes al menos una vez.

Tanto si la prueba basada en el riesgo se realiza primero en profundidad, primero en amplitud o de forma combinada, el tiempo asignado a la prueba puede consumirse sin que se realicen todas las pruebas previstas. Llegados a este punto, las pruebas basadas en el riesgo facilitan la provisión de una recomendación justificada a la dirección sobre si ampliar las pruebas o aceptar el riesgo restante.

Técnicas para la Prueba Basada en el Riesgo

Hay una serie de técnicas específicas con diversos grados de formalidad para la implementación de la prueba basada en el riesgo. La adecuación de una técnica depende de consideraciones relacionadas con el proyecto, el proceso y el producto. Existen dos tipos básicos de técnicas: pesadas o ligeras. En los sistemas de seguridad crítica, las técnicas de peso pesado se utilizan con mucha frecuencia. En aplicaciones no críticas para la seguridad, suelen emplearse técnicas ligeras.

Las técnicas de peso pesado son formales, utilizan procedimientos definidos y documentación detallada. Involucran a amplios grupos de implicados. La evaluación del riesgo dentro de las técnicas de peso pesado utiliza factores detallados de probabilidad del riesgo e impacto del riesgo, y fórmulas matemáticas para calcular la probabilidad del riesgo y el impacto del riesgo a partir de esos factores. Ejemplos de técnicas de peso pesado son:

Análisis del peligro: Amplía el proceso analítico en sentido ascendente intentando identificar los peligros que subyacen a cada riesgo.
Coste de exposición: Determina para cada elemento de riesgo de calidad la probabilidad de un fallo, el coste de una pérdida asociada a un fallo típico y el coste de la prueba para dichos fallos.
Análisis de Modos de Fallo y sus Efectos (AMFE) y sus variantes: Identifica los riesgos de calidad, sus causas potenciales y sus efectos probables y, a continuación, asigna severidad, prioridad e índices de detección.
Análisis de árbol de defectos: Relaciona los fallos potenciales con los defectos que pueden causar el fallo, después con los errores que pueden causar esos defectos, continuando hasta que se identifican las diversas causas raíz.

Por el contrario, las técnicas ligeras son menos profundas y requieren menos esfuerzo por parte del equipo de prueba y de los implicados. Al igual que las técnicas de peso pesado, también se basan en involucrar a los implicados, utilizando los resultados del análisis del riesgo como base para la planificación de la prueba y las condiciones de prueba. Sin embargo, el grupo de implicados puede no ser tan amplio y los factores de riesgo suelen reducirse a impacto del riesgo y probabilidad del riesgo en una escala ordinal. Algunas de estas técnicas, como la Prueba Sistemática de Software (SST), sólo pueden utilizarse cuando se proporcionan especificaciones de requisitos. Otras técnicas, como el Análisis y Gestión del Riesgo Pragmáticos (PRAM) y la Gestión del Riesgo de Producto (PRISMA), utilizan los requisitos y/u otras especificaciones como entrada para el análisis del riesgo, pero pueden funcionar totalmente basadas en la entrada de los implicados.

Métricas de Éxito y Dificultades Asociadas a la Prueba Basada en el Riesgo

En una retrospectiva, el equipo de prueba debe medir hasta qué punto ha obtenido los beneficios de la prueba basada en el riesgo. En muchos casos, esto implica responder a algunas o a todas las preguntas siguientes mediante el uso de métricas y consultas:

¿Participaron o estuvieron representados los implicados relevantes en el análisis del riesgo?
¿Fue adecuada la participación de los implicados en el análisis del riesgo?
Si se han producido incidentes críticos en producción que indiquen que se han escapado defectos críticos, ¿han sido resueltos?
¿Se encontraron la mayoría de los defectos de alta prioridad en una fase temprana de la ejecución de prueba?
¿El equipo de prueba ha sido capaz de explicar los resultados de la prueba a los implicados en términos de riesgo?
¿Las pruebas omitidas tenían un nivel de riesgo asociado inferior al de las ejecutadas?

En la mayoría de los casos, el éxito de la prueba basada en el riesgo da como resultado una respuesta afirmativa a todas estas preguntas. A largo plazo, deben fijarse objetivos de mejora del proceso en cuanto a métricas de éxito, además de esforzarse por mejorar la eficiencia del proceso de análisis del riesgo de calidad.

La gestión del riesgo suele encontrar dificultades inesperadas debido a complejidades que, a menudo, se ignoran:

Dificultad para evaluar el nivel de riesgo: Estimar el impacto del riesgo y la probabilidad del riesgo puede resultar muy difícil. Solución: utilizar datos históricos y pedir su evaluación a los principales implicados en el proyecto.
Comienzo entusiasta: La creación y el mantenimiento de un enfoque de prueba basado en el riesgo adecuado suelen descuidarse ante la gran presión por alcanzar el éxito a corto plazo. Solución: monitorización regular y suministro de información del riesgo a los implicados.
Déjà vu: en cada proyecto se plantea el mismo conjunto de riesgos, lo que conduce a la complacencia respecto al riesgo. Solución: implicar a las personas adecuadas en la identificación del riesgo y mitigar sólo los riesgos que se consideren importantes.
Se están omitiendo riesgos clave: La causa raíz de esta dificultad suele deberse a la implicación de personas inexpertas o inadecuadas en el proceso. Solución: involucrar a las personas adecuadas y formarlas.
Rotación de implicados: Los implicados pueden cambiar con el tiempo y también pueden surgir nuevos riesgos, por lo que el análisis del riesgo es una actividad continua e iterativa y no debe realizarse una sola vez al principio.

1.4 La Estrategia de Prueba del Proyecto

Introducción

A lo largo de este programa de estudio, la estrategia de prueba de la organización se da por supuesta. El desarrollo y mantenimiento de una estrategia de prueba de la organización se considera en el contexto de estándares sectoriales como la norma ISO/IEC/IEEE 29119-3 (donde se hace referencia como una «práctica de prueba de la organización») y los programas de estudio avanzados para la Gestión de Prueba y Liderazgo de Pruebas Ágiles a Escala.

Si no existe una estrategia de prueba de la organización o no cubre los aspectos requeridos, la gestión de la prueba debe tratar de aclarar los detalles que faltan con los implicados relevantes.

En el contexto de esta sección, la definición de una estrategia de prueba de proyecto es un ejemplo de cualquier tipo de estrategia de prueba detallada para un proyecto, una entrega, un producto o cualquier otro tipo de iniciativa de desarrollo o adquisición de sistemas. Una estrategia de prueba de proyecto (denominada «estrategia de prueba» en la norma ISO/IEC/IEEE 29119-3) describe el enfoque de prueba en un contexto específico para que puedan cumplirse los objetivos de la organización, en particular los relacionados con la calidad del producto y las actividades de prueba. También puede existir una estrategia de prueba para un único nivel de prueba o un tipo de prueba.

La estrategia de prueba de proyecto es el principal resultado de la planificación de la prueba de un proyecto y suele documentarse en un plan de prueba o como parte de otros documentos. Se recomienda documentar la estrategia de prueba, pero no necesariamente en forma de plan de prueba formal. La necesidad de documentación depende del contexto de la prueba (véase la sección 1.2, El contexto de la prueba). Cuando un proyecto sigue un modelo de desarrollo secuencial, la estrategia de prueba de proyecto suele documentarse, preferiblemente en el plan de prueba (véase ISO/IEC/IEEE 29119-3). La documentación también suele ser exigida por contratos, acuerdos, organismos reguladores o leyes.

Elección de un Enfoque de Prueba

La estrategia de prueba del proyecto guía todas las actividades de prueba dentro de un proyecto y detalla objetivos, recursos, calendarios y responsabilidades. Esta estrategia debe adaptarse a los requisitos exclusivos del proyecto. Las decisiones clave incluyen la selección de los niveles de prueba, los tipos de prueba y las técnicas de prueba para las pruebas estáticas y dinámicas y otras prácticas de prueba (por ejemplo, pruebas mediante guion, pruebas manuales, prueba continua).

En teoría, todos los tipos de prueba pueden realizarse en cualquier nivel de prueba, y cualquier técnica de prueba puede aplicarse a cualquier tipo de prueba en cualquier nivel de prueba. En la práctica, la selección y combinación adecuadas de estas opciones tienen un impacto significativo en la efectividad y eficiencia de la prueba. Por ejemplo, la mantenibilidad del código puede evaluarse a menudo de forma más eficaz y eficiente mediante el análisis estático de código o la revisión de código. Por otro lado, la eficiencia de desempeño puede evaluarse mejor mediante pruebas de sistema mediante guion debido a la interacción de los componentes internos, o la utilidad de la funcionalidad puede validarse mejor con los usuarios mediante pruebas de aceptación manuales desarrolladas en colaboración. Elegir el mejor enfoque para una estrategia de prueba puede ser un proceso complejo en el que pueden influir la estrategia de prueba de la organización, el contexto del proyecto y otros aspectos.

Por lo tanto, seleccionar y combinar los niveles de prueba, los tipos de prueba y las técnicas de prueba es fundamental para que la estrategia de prueba de un proyecto sea eficaz, ya que influye significativamente en la eficiencia y la efectividad de la prueba.

Análisis de la Estrategia de Prueba de la Organización, del Contexto del Proyecto y de Otros Aspectos

La estrategia de prueba de la organización, el contexto del proyecto y los factores o restricciones adicionales relacionados con la prueba deben comprenderse en su totalidad para habilitar el desarrollo de una estrategia de prueba del proyecto.

Para elegir el enfoque de prueba adecuado, normalmente deben analizarse los siguientes factores:

Dominio: El dominio para el que se creará o modificará el producto. Cualquier normativa, estándar o práctica específica del dominio puede cambiar el rigor de la prueba, la documentación requerida, así como su nivel de detalle. Por ejemplo, en los productos farmacéuticos y la medicina, el enfoque de prueba suele enfatizar una prueba de aceptación del usuario intensiva centrada en los riesgos para la salud del paciente, utilizando casos de prueba basados en los requisitos funcionales del usuario, mientras que la prueba de aceptación del usuario para las aplicaciones de seguros basadas en la web podría centrarse en la facilidad de uso y en aumentar la probabilidad de nuevos contratos de seguros mediante pruebas A/B.
Objetivos de la organización y características de calidad generales: Los objetivos de la organización pueden incluir la necesidad de demostrar el valor de la prueba y de aumentar el grado de automatización de la prueba o las características de calidad del proceso de prueba, como el nivel de madurez de la prueba o la eficiencia de la detección de defectos. Éstos pueden determinar los niveles de prueba y los tipos de prueba que se necesitan.
Los objetivos del proyecto y el tipo de proyecto: Los objetivos del proyecto (por ejemplo, los relativos al presupuesto, el tiempo y la calidad) y el tipo de proyecto (es decir, el desarrollo de un producto específico para el cliente frente al orientado al mercado) suelen contener restricciones y riesgos, así como oportunidades que afectan a la prueba. Por ejemplo, un presupuesto ajustado y limitaciones de tiempo pueden requerir el uso riguroso de prueba basada en el riesgo para establecer las prioridades de los casos de prueba para la ejecución de la prueba, mientras que el desarrollo de un producto específicamente para un cliente puede requerir pruebas que cubran los criterios de aceptación contractual predefinidos.
Recursos de prueba: Debe tenerse en cuenta cualquier restricción relativa a la disponibilidad de los recursos de prueba, incluidas las herramientas de prueba, la infraestructura de la prueba, la tecnología y el entorno de desarrollo utilizados en el proyecto, así como el personal de prueba disponible y sus competencias. Recursos de prueba Por ejemplo, las pruebas basadas en la experiencia requieren probadores con un buen conocimiento del dominio; las aplicaciones móviles suelen tener que probarse en un número normalmente limitado de dispositivos diferentes; el uso de herramientas de prueba puede estar limitado por el número de licencias disponibles.
El modelo de ciclo de vida de desarrollo del software utilizado para el proyecto: Para determinar los niveles de prueba adecuados, el esfuerzo de prueba, los criterios de entrada apropiados y los criterios de salida. Un ciclo de vida del software con integración continua requiere más pruebas automatizadas que el desarrollo único mediante un modelo en cascada y, por lo tanto, pueden utilizarse diferentes tipos de prueba y técnicas de prueba.
Interfaces con otros sistemas: En un sistema de sistemas, es esencial alinear la prueba con otros equipos o proyectos y seleccionar los niveles de prueba adecuados, especialmente para la prueba de integración de sistemas. Por ejemplo, las pruebas basadas en el riesgo ayudan a priorizar y escalar las pruebas de integración de sistemas.
Disponibilidad de los datos de prueba: Se deben tener en cuenta las restricciones en la disponibilidad de los datos de prueba, como la necesidad de datos de prueba anonimizados procedentes de producción, o la creación de datos de prueba específicos que pueden ser difíciles de proporcionar y necesitan ser validados, como los datos para las pruebas de IA. Por ejemplo, las pruebas basadas en modelos pueden apoyar la creación de datos de prueba y la gestión de datos de prueba.

El jefe de prueba debe determinar qué combinación de técnicas de prueba, niveles de prueba y tipos de prueba debe utilizarse como el mejor enfoque para satisfacer la estrategia de prueba de la organización, el contexto del proyecto y los factores o restricciones adicionales relacionados con la prueba.

Definición de los Objetivos de Prueba

Debe definirse un plan de prueba para cada proyecto de prueba que contenga, entre otros aspectos, el alcance de la prueba, los objetivos de la prueba y los criterios de salida. El plan de prueba puede establecerse a nivel de entrega, como plan de prueba de proyecto (también conocido como plan de prueba maestro) y, si es necesario, como plan de prueba de nivel para los distintos niveles de prueba. Además, pueden definirse planes de prueba para las distintas características de calidad, como un plan de prueba de seguridad o un plan de prueba de rendimiento. En los proyectos de desarrollo ágil de software y de desarrollo híbrido de software, se puede acordar un plan de pruebas de iteración. Para cada entrega e iteración, el alcance de las prestaciones funcionales y sus características no funcionales que deben entregarse se define en el plan de prueba y se acuerda con los implicados.

Asociados a las prestaciones entregadas para su prueba en un proyecto, deben definirse los objetivos de prueba del proyecto y los criterios de salida. Para ello se puede utilizar la metodología de objetivos S.M.A.R.T.:

Sigla	Término original	Traducción	Descripción aplicada al objetivo de prueba
S	specific	específico	El objetivo de prueba y el criterio de salida de un proyecto deben ser claros e inequívocos.
M	measurable	medible	Debe ser cuantificable y tener criterios específicos para medir el avance y determinar si se ha alcanzado.
A	achievable	alcanzable	Debe ser feasible teniendo en cuenta los recursos disponibles, el calendario y las capacidades.
R	relevant	relevante	Debe estar en consonancia con los objetivos generales del proyecto.
T	timely	oportuno	Debe tener un marco temporal específico y un plazo definido para su compleción.

Los objetivos de prueba del proyecto deben abordar todos los aspectos de calidad y cantidad, siempre que sean medibles o evaluables. Algunos ejemplos de objetivos de prueba del proyecto son:

Alcanzar los criterios de salida especificados dentro del plazo definido.
Cumplir los objetivos de calidad de la organización (por ejemplo, medido como un indicador clave de rendimiento para el número de reclamaciones de los clientes por un producto).
Cumplir las normas y reglamentos de la industria específica.
Asegurar la disponibilidad de los datos sólo para los usuarios autorizados (por ejemplo, mediante derechos de acceso).
Comprobar la completitud funcional, el rendimiento, la eficiencia, la portabilidad y la seguridad de la migración de datos.
Mejorar el nivel de automatización de la prueba o de rendimiento en un porcentaje definido.
Refactorizar el código con éxito y demostrar que no ha introducido nuevos defectos (por ejemplo, para eliminar el código fuente mal estructurado o la deuda técnica manteniendo la funcionalidad existente, probado mediante una prueba de regresión).
Demostrar la seguridad de las interfaces (por ejemplo, validando los mensajes XML (Extensible Markup Language) con su definición de esquema XML para asegurar el rechazo de datos maliciosos).

Además del recuento y la medición de los objetivos de prueba del proyecto, debe tenerse en cuenta la evaluación del nivel de calidad por parte de los expertos del dominio y los implicados.

Dependiendo del contexto del proyecto y de los objetivos de prueba, a veces pueden ser necesarios varios entornos de prueba con los recursos y/o herramientas de prueba disponibles. Es posible que no todos los entornos de prueba estén disponibles al mismo tiempo. Esto debe tenerse en cuenta al formular los objetivos de prueba alcanzables y los criterios de salida.

Dependiendo del contexto del proyecto, habrá que tener en cuenta otros factores a la hora de definir los objetivos de prueba y el alcance de las pruebas del proyecto, como se describe en la sección 1.2 de este programa de estudio, El contexto de la Prueba.

1.5 Mejora del Proceso de Prueba

Introducción

La prueba es una parte importante del desarrollo de software y a menudo supone al menos el de los costes totales del proyecto. Junto a los muchos retos (técnicos) a los que se enfrentan los proyectos de software (por ejemplo, el aumento de la complejidad y el tamaño, las nuevas tecnologías, la gran variedad de dispositivos y sistemas operativos y las vulnerabilidades de seguridad), existe la necesidad de optimizar la efectividad y la eficiencia de la prueba, así como la necesidad de mejorar los procesos de prueba en consecuencia. Aprender de las buenas prácticas existentes y de los errores propios permite mejorar el proceso de prueba y hacer que los proyectos tengan más éxito.

Un proceso de mejora a nivel organizativo suele ser más útil que un proceso de mejora a nivel de proyecto o de equipo. Sin embargo, también es posible y beneficioso aplicar la mejora del proceso a nivel de proyecto o de equipo, pero debe adaptarse a las necesidades del proyecto o del equipo. Una mejora de la prueba puede iniciarse, por ejemplo, por insatisfacción con los resultados de la prueba actual, defectos inesperados, circunstancias cambiantes, un resultado de prueba comparativa o falta de comunicación. Existen diferentes técnicas para mejorar las pruebas. A continuación, se describen algunas de estas técnicas. Las técnicas descritas en este programa de estudio pueden aplicarse tanto a modelos de desarrollo secuencial como a modelos de desarrollo ágil de software/modelos de desarrollo incremental. Los programas avanzados orientados a la mejora del proceso de prueba ofrecen una visión más profunda.

El Proceso de Mejora de la Prueba (IDEAL)

Una vez que se ha acordado que los procesos de prueba deben mejorarse, las actividades de implementación de la mejora de la prueba que deben adoptarse para esta actividad pueden definirse como en el modelo IDEAL, que se basa en ideas similares a las del conocido ciclo planificar-hacer-comprobar-actuar (PDCA). IDEAL es un acrónimo de los términos en inglés «Initiating, Diagnosing, Establishing, Acting and Learning» (Iniciar, Diagnosticar, Establecer, Actuar y Aprender).

Aunque IDEAL se definió originalmente para apoyar las actividades de mejora a nivel organizativo, también puede aplicarse a nivel de proyecto o de equipo de desarrollo Ágil de Software. En el contexto de un proyecto, los objetivos de las actividades están por alcanzar. La principal diferencia es probablemente la fase de iniciación, que es mucho menor a nivel de proyecto o de equipo que a nivel organizativo. Diagnosticar a través de una retrospectiva y establecer un plan serán probablemente mucho menores que para un nivel organizativo. La actuación y el aprendizaje también serán relevantes a nivel de proyecto o de equipo.

Iniciar (initiating) el Proceso de Mejora:
Al inicio del proceso de mejora, los implicados acuerdan los objetivos y el alcance de las mejoras del proceso.
Diagnosticar (diagnosing) la Situación Actual:
Se evalúa el proceso de prueba actual para identificar posibles mejoras. La evaluación suele realizarse en función de un marco de trabajo estándar en el caso de la mejora del proceso de pruebas basado en modelos o puede basarse en un análisis de métricas específicas en el caso de la mejora del proceso de pruebas basado en análisis.
Establecer (establishing) un Plan de Mejora del Proceso de Prueba:
Un plan de mejora del proceso de prueba puede ser un documento formal que enumere todas las acciones detalladas que deben realizarse para lograr mejoras. Dependiendo del contexto, el plan puede ser muy informal y muy ligero. La lista de posibles mejoras del proceso debe priorizarse. La priorización puede basarse en el retorno de la inversión (ROI), los riesgos, la alineación con las estrategias del proyecto o del equipo, y/o los beneficios cuantitativos o cualitativos medibles que deben lograrse.
Actuar (acting) para Implementar la Mejora del Proceso de Prueba:
Se implementa el plan de mejora del proceso de prueba para la entrega de las mejoras. Esto suele incluir la formación y la realización de pilotos de los procesos modificados y su despliegue completo en el proyecto o equipo.
Aprender (learning) del Programa de Mejora:
Una vez desplegadas plenamente las mejoras del proceso, es esencial verificar qué beneficios, previstos o imprevistos, se han recibido. Una vez aprendido lo que funcionó y lo que no funcionó, debemos actuar en función de esta información y sólo a partir de entonces podrá iniciarse el siguiente ciclo de mejora.

Mejora del Proceso de Prueba Basada en Modelos

Una premisa tanto para la mejora del proceso de prueba basado en modelos como para la mejora basada en análisis es la suposición de que la calidad de los procesos que se aplican y utilizan influye en gran medida en la calidad del producto. Cuando se aplica la mejora del proceso de prueba basada en modelos, se utiliza un modelo de mejora de la prueba. Los modelos de mejora de la prueba se basan en buenas prácticas y organizan la mejora de la prueba de forma escalonada.

Han surgido varios modelos de proceso recomendados que apoyan la mejora del proceso de prueba. Entre ellos se encuentran Test Maturity Model integration (TMMi®) y TPI NEXT®.

La mejora basada en modelos también puede aplicarse a nivel de proyecto. En tales casos, la evaluación y el proceso de mejora se centran específicamente en los procesos de prueba o en las áreas clave definidas en el modelo que se relacionan con las actividades a nivel de proyecto (por ejemplo, la planificación de la prueba y el diseño de la prueba) y, a menudo, omiten en gran medida las que se encuentran a nivel de organización (por ejemplo, la política de prueba y la organización de la prueba). Alternativamente, también se pueden adaptar adecuadamente al contexto del proyecto las prácticas que abordan el nivel organizativo.

Test Maturity Model integration (TMMi)

El TMMi® se compone de cinco niveles de madurez. Cada nivel de madurez, excepto el nivel 1 del TMMi®, contiene áreas del proceso de prueba y objetivos de mejora. Además, para facilitar y apoyar su implementación, TMMi® contiene prácticas, subprácticas y ejemplos. El TMMi® se desarrolló inicialmente para complementar el Capability Maturity Model Integration (CMMI®), pero hoy en día se utiliza ampliamente con independencia del CMMI®.

Para facilitar y apoyar la actualización del TMMi® en el desarrollo ágil de software, se ha desarrollado una directriz específica que explica cómo se puede utilizar y aplicar el TMMi® de forma beneficiosa en el desarrollo ágil de software.

TPI NEXT

El modelo TPI NEXT® define 16 áreas clave, cada una de las cuales cubre un aspecto específico del proceso de prueba (por ejemplo, estrategia de prueba, métrica de prueba, herramientas de prueba y entorno de prueba). En el modelo se definen cuatro niveles de madurez para cada una de las 16 áreas clave.

Se definen puntos de control específicos para evaluar cada área clave en cada uno de los niveles de madurez. Los resultados de la evaluación se resumen y visualizan mediante una matriz de madurez que abarca todas las áreas clave.

Enfoque de Mejora del Proceso de Prueba Basada en Modelo Analítico

Mediante un enfoque de mejora basado en modelos, como el descrito en el apartado anterior, se introducen mejoras comparando el enfoque de prueba de un proyecto o equipo con las buenas prácticas externas. Los enfoques analíticos identifican los problemas basándose en los datos del propio proyecto o equipo. Del análisis de estos problemas se pueden obtener las mejoras adecuadas. Los enfoques analíticos pueden utilizarse junto con un enfoque basado en modelos para verificar los resultados y aportar diversidad.

Los problemas pueden identificarse utilizando datos cuantitativos y cualitativos. Este enfoque presenta metodologías analíticas que utilizan principalmente datos cuantitativos del proceso de prueba y datos de defectos para evaluar el enfoque actual. Las retrospectivas (sección 1.5.4) presentan la recopilación de datos cualitativos sobre lo que funciona bien y lo que no entre los miembros del equipo de desarrollo y de prueba.

El análisis de datos es importante para la mejora del proceso objetivo de prueba y un valioso apoyo a las evaluaciones puramente cualitativas, que de otro modo podrían dar lugar a recomendaciones imprecisas que no están respaldadas por datos. La aplicación de un enfoque analítico a la mejora suele implicar un análisis cuantitativo del proceso de prueba para identificar áreas problemáticas y establecer objetivos específicos del proyecto. Es necesario definir y medir los parámetros clave para evaluar el proceso de prueba y valorar si las mejoras han tenido éxito.

Algunos ejemplos de enfoques analíticos son:

Análisis de la causa raíz.
Análisis mediante medidas, métricas e indicadores.
El enfoque GQM (Goal-Question-Metric).

El análisis de la causa raíz es el estudio de los problemas para identificar sus causas raíz. Esto permite identificar soluciones que eliminen las causas de los problemas en lugar de limitarse a abordar los síntomas evidentes inmediatos. Un posible procedimiento de análisis consistiría en seleccionar un conjunto adecuado de defectos, identificar agrupamientos en estos datos y utilizar diagramas causa-efecto (también llamados diagramas de Ishikawa o de espina de pescado) para identificar las causas raíz de los agrupamientos de defectos importantes. A continuación, se obtienen mejoras para evitar que se produzcan defectos similares.

Las medidas, métricas e indicadores se utilizan de forma cuantitativa para evaluar lo bien que se realiza el proceso de prueba en el proyecto o equipo. Los atributos clave del proceso de prueba que hay que tener en cuenta son la efectividad, la eficiencia y la previsibilidad. Para cada uno de estos atributos se pueden seleccionar una o varias métricas. Mediante la recopilación y el análisis de los datos correspondientes, se pueden identificar las áreas clave que requieren mejoras.

El enfoque GQM proporciona un marco para definir y analizar métricas adaptadas a las necesidades de información de los implicados relevantes del proyecto. Los objetivos de medición definen un aspecto de calidad de un objeto que necesita ser medido para un propósito, una perspectiva y un contexto concretos. Estos objetivos se refinan en preguntas que definen el aspecto de calidad desde el punto de vista de los implicados. A continuación, se seleccionan las métricas que proporcionan la información necesaria para responder a la pregunta. Los datos recogidos para las métricas responden a las preguntas, para evaluar el objetivo de medición y satisfacer las necesidades de información de los implicados.

Retrospectivas

Las retrospectivas son reuniones en las que un equipo revisa sus métodos y su colaboración, recopila las lecciones aprendidas (buenas y malas) y decide los cambios y las acciones para lograr mejoras (tanto para las cuestiones relacionadas con las pruebas como para las que no lo están). Las retrospectivas abordan temas como el proceso. En este contexto, las retrospectivas tienen como objetivo generar lecciones aprendidas para gestionar mejor los proyectos futuros. En el Desarrollo Ágil de Software las retrospectivas se suelen realizar al final de cada iteración para discutir qué ha tenido éxito y qué necesita mejorarse, y cómo pueden incorporarse esas mejoras en la siguiente iteración. Las retrospectivas son realizadas por todo el equipo, por lo que apoyan el enfoque de equipo completo y fomentan la mejora continua. Tenga en cuenta que a veces se requieren retrospectivas específicas para abordar dificultades de la prueba.

Una retrospectiva típica consta de los siguientes pasos:

Introducción: Se revisan el objetivo y la agenda de la retrospectiva, y se crea una atmósfera de confianza mutua para poder discutir los problemas sin culpar ni juzgar.
Recopilar datos: Se recogen datos sobre lo ocurrido durante la iteración o el proyecto. Es posible recopilar datos cualitativos, como una cronología de los acontecimientos clave en la que se identifiquen las dificultades y se enumere cómo se siente cada miembro del equipo al respecto. Además, se pueden presentar datos cuantitativos procedentes de métricas; por ejemplo, los datos sobre el avance de la prueba, la detección de defectos, la efectividad de la prueba, la eficiencia de la prueba y la previsibilidad pueden proporcionar una visión objetiva de la prueba del proyecto o de la iteración.
Derivar mejoras: Los datos recopilados se analizan para comprender la situación actual y generar ideas de mejora. Por ejemplo, se puede aplicar el análisis de la causa raíz para identificar las causas de los problemas detectados y celebrar una tormenta de ideas para generar ideas sobre cómo resolver las causas raíz.
Decidir las acciones de mejora: Se obtienen y se priorizan las acciones para implementar las ideas de mejora. Se definen un plan de mejora y las responsabilidades. Se pueden definir objetivos y métricas asociadas para evaluar el impacto de las acciones en los problemas identificados. Implementar demasiadas mejoras a la vez es difícil de gestionar con pasos verificables.
Cerrar la retrospectiva: En este último paso, se revisa la propia retrospectiva para identificar los puntos fuertes y las mejoras del proceso retrospectivo. La retrospectiva se realiza con regularidad, especialmente en el desarrollo ágil de software. La mejora continua también se aplica a la propia retrospectiva.

Es importante documentar adecuadamente los resultados de una retrospectiva. En un modelo de desarrollo secuencial, los hallazgos, las conclusiones y las recomendaciones deben distribuirse y comunicarse de forma comprensible a los miembros de la organización. En el Desarrollo Ágil de Software, los problemas y las acciones también deben documentarse para permitir la revisión de las acciones y su posible impacto en los problemas de la siguiente iteración.

Los probadores, al formar parte del equipo (del proyecto), aportan su perspectiva única. Pueden plantear problemas relacionados con la prueba (y otros) y estimular al equipo a pensar en posibles mejoras.

1.6 Herramientas de Prueba

Introducción

Existen tres tipos de herramientas de negocio:

Herramientas comerciales.
Herramientas de código abierto.
Herramientas a medida.

Cuando se selecciona una herramienta de negocio, deben tenerse en cuenta todos los requisitos y normativas de la organización y de los implicados del negocio.

También existen herramientas técnicas como las herramientas de automatización de la prueba, las herramientas de gestión de la prueba y muchas más.

Buenas Prácticas para la Introducción de Herramientas

Esta sección contiene los pasos necesarios para la evaluación e introducción de una herramienta de prueba. Un jefe de prueba puede participar en la introducción de una herramienta o puede fomentar o facilitar el proceso de introducción. Los jefes de prueba suelen ser responsables de una herramienta de prueba dedicada o de cualquier herramienta relacionada con la prueba, como una herramienta de gestión de requisitos, de gestión de defectos o de monitorización.

Existen buenas prácticas y consideraciones genéricas a la hora de evaluar y seleccionar una herramienta de prueba. Estas prácticas y consideraciones incluyen lo siguiente:

Identificar las oportunidades de mejora del proceso, con el apoyo de las herramientas adecuadas.
Comprender las tecnologías utilizadas en una organización y seleccionar una herramienta que sea compatible con dichas tecnologías.
Comprender cómo se integra técnica y organizativamente una herramienta en el ciclo de vida de desarrollo de software (CVDS).
Evaluar la herramienta en función de requisitos claros y criterios objetivos.
Evaluar al proveedor si está teniendo en cuenta el uso de una herramienta comercial.
Evaluar la compatibilidad con herramientas no comerciales (por ejemplo, de código abierto).
Identificar los requisitos internos para entrenar, orientar o formar en el uso de la herramienta.
Tener en cuenta los pros y los contras de los distintos modelos de licencia.
Como paso final, realizar una evaluación de prueba de concepto.

Entre las buenas prácticas genéricas en la adopción y puesta en marcha de una herramienta se incluyen:

Ejecutar un proyecto piloto para validar los criterios de selección y los requisitos y para evaluar cómo encaja la herramienta con los procesos y prácticas existentes.
Adaptar y mejorar los procesos para que encajen con el uso de la herramienta, también adaptar la herramienta a los procesos existentes, si es necesario.
Definir directrices para el uso de la herramienta.
Proporcionar formación, entrenamiento y orientación a los usuarios de la herramienta.
Desplegar la herramienta en la organización en incrementos.
Implantar una forma de recopilar información del uso real de la herramienta para futuras mejoras.
Definir la propiedad de la herramienta.

Aspectos Técnicos y de Negocio para las Decisiones sobre la Herramienta

Existen múltiples factores que influyen en la decisión sobre la implementación y el uso de una herramienta. Para un jefe de prueba es importante conocerlos y abordarlos.

Normativa y seguridad: Las organizaciones que desarrollan software de seguridad crítica o de misión crítica, o que están sujetas al cumplimiento de normativas, pueden preferir las herramientas comerciales, ya que con más frecuencia cumplen los requisitos exigidos y suelen poseer la certificación adecuada.
Aspectos financieros: Las herramientas de código abierto suelen tener un coste inicial más bajo gracias al apoyo y desarrollo de la comunidad. Las herramientas comerciales pueden tener un precio de compra que se paga una sola vez, así como costes de licencia recurrentes. El coste inicial de una herramienta a medida es difícil de determinar porque depende de los requisitos y de la fase de desarrollo de la herramienta. Además de los costes iniciales, hay que calcular y tener en cuenta el coste de formación y mantenimiento a lo largo de la vida útil de una herramienta. Todas las herramientas pueden tener unos costes de mantenimiento elevados.
Requisitos de implicados: Es importante reunir los requisitos de todos los implicados para evaluar e identificar la herramienta más adecuada. Las herramientas comerciales y las de código abierto no necesariamente cumplen todos los requisitos en detalle. Las herramientas a medida pueden ser la mejor opción para satisfacer todos los requisitos individuales y en los casos en los que ninguna otra herramienta proporcione la funcionalidad requerida.
Panorama de software existente y estrategia de herramientas: Debe evaluarse la composición existente de herramientas (panorama del software) y la estrategia de herramientas asociada, ya que puede haber proveedores preferidos o bloqueados, sistemas integrados que tengan dependencias con otros productos o un modelo especial de soporte de servicio completo para todo el panorama del software con normativas específicas.

Consideraciones sobre el Proceso de Selección y Evaluación del Retorno de la Inversión

Las herramientas de prueba pueden ser una inversión a largo plazo, que quizás se extienda a lo largo de muchas iteraciones de un único proyecto, y/o aplicables a muchos proyectos. Por lo tanto, una posible herramienta debe tenerse en cuenta desde distintos puntos de vista.

En lo que respecta a la alta dirección, se requiere un ROI positivo.
En lo que respecta al equipo de soporte y operaciones, se prefiere un número limitado, pero necesario, de herramientas utilizadas en toda la organización. Mantener un número mayor de herramientas, hacer un seguimiento de sus licencias y gestionar la cartera de herramientas no debería suponer ni un gasto ni un consumo de tiempo.
Para los responsables de proyecto, la herramienta debe añadir un valor medible al proyecto o a la organización.
Para las personas que utilizan la herramienta, la usabilidad es muy importante. La usabilidad incluye, por ejemplo, el apoyo a determinadas tareas, la capacidad de ser aprendido y la operabilidad.
Para los miembros del personal operativo, la mantenibilidad es importante.

Las prestaciones deben analizarse para cada tipo de herramienta de negocio y técnica. En ese análisis influyen diferentes perspectivas e intereses: la gestión de la prueba, el análisis (técnico) de la prueba, la automatización de la prueba o el desarrollo. La persona de la organización responsable de la herramienta (el propietario de la herramienta) debe asegurarse de que se realiza el análisis y se tienen en cuenta los puntos mencionados anteriormente.

Todas las herramientas introducidas en el proceso de prueba deben asegurar también un retorno de la inversión positivo para la organización. Es responsabilidad del jefe de prueba ocuparse del cálculo y posterior evaluación del ROI. En el Desarrollo Ágil de Software puede ser responsabilidad de todo el equipo de desarrollo.

Antes de adquirir o construir una herramienta debería realizarse un análisis de coste-beneficio para asegurar que resulta en un beneficio para la organización. Este análisis debería tener en cuenta tanto los costes recurrentes como los no recurrentes.

Entre las actividades y los costes no recurrentes se encuentran los siguientes:

Definir y determinar los requisitos de la herramienta para cumplir los objetivos.
Evaluar y seleccionar la herramienta y el proveedor adecuados, prueba de concepto.
Adquirir, adaptar o desarrollar la herramienta para su uso inicial.
Definir directrices para el uso de la herramienta.
Formación inicial para la herramienta.
Integración de la herramienta en el panorama de herramientas existente.
Adquirir el hardware/software necesario para dar soporte a la herramienta.

Entre las actividades y costes recurrentes se encuentran los siguientes:

Cuotas recurrentes de licencia y soporte.
Costes de mantenimiento.
Costes de formación continua.
Portar la herramienta a diferentes entornos.

También hay que tener en cuenta los costes de oportunidad. Esto significa que el tiempo dedicado a evaluar, administrar, formar y utilizar la herramienta podría haberse empleado en tareas de prueba reales. Por lo tanto, es posible que se necesiten más recursos de prueba antes de poder utilizar la herramienta para las actividades previstas.

En el proceso de selección de herramientas se deberían tener en cuenta los siguientes riesgos en relación con el retorno de la inversión:

La inmadurez de la organización puede conducir a un uso ineficaz de la herramienta.
Los cambios en la política de mantenimiento del proveedor pueden aumentar la carga de trabajo.
Costes más elevados de lo esperado.
Menor beneficio del esperado.

Las siguientes ventajas pueden aplicarse a las herramientas de prueba:

Reducción del trabajo manual repetitivo (por ejemplo, prueba de regresión).
Aceleración del tiempo del ciclo de prueba mediante la automatización.
Ahorro de costes en la ejecución de pruebas gracias a la disminución de las actividades manuales.
Aumento de la cobertura de determinados tipos de prueba admitidos por la herramienta.
Reducción de los errores humanos por la disminución de las actividades manuales.
Acceso más rápido a la información sobre las pruebas.

En la versión 4 del programa de estudio de nivel básico de Probador Certificado y en el programa de estudio de Probador Certificado en Ingeniería de Automatización de Pruebas se pueden encontrar beneficios y riesgos adicionales, especialmente para las herramientas de automatización de la prueba.

En general, una organización de prueba rara vez utiliza una única herramienta. El ROI total de una organización suele ser una combinación del ROI de todas las herramientas que se utilizan para las pruebas. Las herramientas necesitan compartir información y trabajar de forma cooperativa. Es aconsejable una estrategia integral a largo plazo para las herramientas de prueba que incluya riesgos, costes y beneficios.

Ciclo de Vida de las Herramientas

Existen cuatro etapas diferentes en el ciclo de vida de una herramienta. Debe designarse un administrador de la herramienta para asegurar que las actividades de estas etapas se definen, se llevan a cabo y se gestionan.

Adquisición: En primer lugar, se ha tomado la decisión de seleccionar una herramienta. En el segundo paso, es necesario asignar un propietario de la herramienta. Esta persona toma las decisiones sobre el uso de la herramienta (por ejemplo, las convenciones de nomenclatura de los productos de trabajo y dónde se almacenarán estos productos de trabajo). Tomar estas decisiones desde el principio puede suponer una diferencia significativa en la rentabilidad final de la herramienta.
Soporte y mantenimiento: El propietario de la herramienta es responsable de su mantenibilidad. La responsabilidad de las actividades de mantenimiento debe recaer en el administrador de la herramienta o en un grupo dedicado a ella. En el caso de la interoperabilidad, deben tenerse en cuenta el intercambio de datos y los procesos de cooperación y comunicación. Asimismo, se requieren decisiones sobre la copia de seguridad y la recuperación de los artefactos relacionados con la herramienta.
Evolución: A medida que pasa el tiempo, el entorno, las necesidades de negocio o las decisiones de los proveedores pueden requerir cambios en la herramienta. Cuanto más complejo sea el entorno operativo de una herramienta, más fácil será que un cambio altere su uso.
Retiro: Al final de su vida útil, la herramienta debe retirarse. En la mayoría de los casos, la funcionalidad suministrada por la herramienta será reemplazada y los datos deberán conservarse y/o archivarse. Esto puede deberse a una decisión del proveedor o a que se ha llegado a un punto en el que los beneficios y las oportunidades de pasar a una nueva herramienta superan sus costes y riesgos.

Métrica de Herramientas

Las métricas objetivas extraídas de las herramientas se diseñan y recopilan en función de las necesidades del equipo de prueba y de otros implicados. Las herramientas de prueba capturan sobre todo datos que resultan de valor en tiempo real y reducen el esfuerzo requerido para recopilar datos. Estos datos se utilizan para gestionar el esfuerzo global de las pruebas e identificar áreas de optimización.

Las distintas herramientas se concentran en recopilar diferentes tipos de datos. Algunos ejemplos son:

Las herramientas de gestión de la prueba pueden suministrar una variedad de métricas diferentes relacionadas con los elementos de prueba disponibles, las pruebas, las pruebas planificadas, así como el estado de ejecución de la prueba actual y pasada (por ejemplo, aprobada, fallida, omitida, bloqueada o planificada).
Las herramientas de gestión de requisitos proporcionan trazabilidad en relación con la cobertura de los requisitos mediante casos de prueba pasados y fallidos.
Las herramientas de gestión de defectos pueden proporcionar información sobre defectos, como el estado, la severidad, la prioridad y la densidad de defectos de los elementos de prueba. Otros datos valiosos, como el porcentaje de detección de defectos, los niveles de prueba en los que se introducen los defectos y el plazo de ejecución de los defectos detectados ayudan a impulsar la mejora del proceso, pero puede que no todos sean proporcionados únicamente por la herramienta de gestión de defectos.
Las herramientas de análisis estático, entre otras, suministran métricas relacionadas con la complejidad del código.
Las herramientas para prueba de rendimiento pueden proporcionar información valiosa, como los tiempos de respuesta y las tasas de fallos bajo cargas máximas.
Las herramientas de cobertura de código ayudan a comprender qué partes del objeto de prueba han sido practicadas por la prueba.

Aunque las herramientas de prueba pueden utilizarse para recopilar métricas, también deben monitorizarse a sí mismas. En este contexto, puede medirse:

La calidad del proceso de prueba (por ejemplo, el número de defectos encontrados con y sin herramientas y la cobertura de requisitos).
La eficiencia de la prueba (por ejemplo, la duración de la ejecución de la prueba y el número de pruebas ejecutadas).

Fuente: Programa de estudios del ISTQB Advanced Level Test Management v3.0

Please Share This Compartir este contenido

1. Gestión de las Actividades de Prueba

Palabras Clave

Objetivos de Aprendizaje para «Capítulo 1»

1.1 El proceso de Prueba

1.2 El Contexto de la Prueba

1.3 Prueba Basada en el Riesgo

1.4 La Estrategia de Prueba del Proyecto

1.5 Mejora del Proceso de Prueba

1.6 Herramientas de prueba

1.1 El Proceso de Prueba

Introducción

Actividades de Planificación de la Prueba

Actividades de Monitorización y Control de la Prueba

Actividades de Compleción de la Prueba

1.2 El Contexto de la Prueba

Implicados de la Prueba

Importancia del Conocimiento de los Implicados en la Gestión de la Prueba

Gestión de la Prueba en un Modelo Híbrido de Desarrollo de Software

Actividades de Gestión de la Prueba para varios Modelos de Ciclo de Vida del Desarrollo de Software

Actividades de Gestión de la Prueba en Distintos Niveles de Prueba

Actividades de gestión de la prueba para distintos tipos de prueba

Actividades de Gestión de la Prueba para la Planificación, Monitorización y Control

1.3 Prueba Basada en el Riesgo

Introducción

La Prueba como Actividad de Mitigación del Riesgo

Identificación de Riesgos de Calidad

Evaluación del Riesgo de Calidad

Mitigación del riesgo de Calidad Mediante una Prueba Adecuada

Técnicas para la Prueba Basada en el Riesgo

Métricas de Éxito y Dificultades Asociadas a la Prueba Basada en el Riesgo

1.4 La Estrategia de Prueba del Proyecto

Introducción

Elección de un Enfoque de Prueba

Análisis de la Estrategia de Prueba de la Organización, del Contexto del Proyecto y de Otros Aspectos

Definición de los Objetivos de Prueba

1.5 Mejora del Proceso de Prueba

Introducción

El Proceso de Mejora de la Prueba (IDEAL)

Mejora del Proceso de Prueba Basada en Modelos

Test Maturity Model integration (TMMi)

TPI NEXT

Enfoque de Mejora del Proceso de Prueba Basada en Modelo Analítico

Retrospectivas

1.6 Herramientas de Prueba

Introducción

Buenas Prácticas para la Introducción de Herramientas

Aspectos Técnicos y de Negocio para las Decisiones sobre la Herramienta

Consideraciones sobre el Proceso de Selección y Evaluación del Retorno de la Inversión

Ciclo de Vida de las Herramientas

Métrica de Herramientas

Please Share This Compartir este contenido

Gus Terrera

También podría gustarte

ISTQB Foundation Level – Spanish Version – Slideshare

Testing de Caja Blanca – Parte I

ISTQB – Fundamentos de Pruebas de Software

Compartir este contenido

Compartir este contenido