Descripción general del taller Revisión de estrategia de pruebas

15 minutos

El objetivo de Success by Design es asegurar un buen resultado para el cliente mientras se implementa Microsoft Dynamics 365. El propósito de la revisión de la estrategia de prueba es:

Impulsar la comunicación y la comprensión: el taller de revisión de la estrategia de prueba está diseñado para impulsar una conversación sobre la estrategia de prueba que promueva la comprensión general en todo el equipo de implementación con respecto a la planificación y los objetivos, los tipos y la cobertura de las pruebas, así como el enfoque para validar la solución.
Identificar riesgos y problemas: al adoptar una perspectiva amplia y de alto nivel en relación con la estrategia de prueba, puede identificar problemas y riesgos con el enfoque que afectarían negativamente al resultado.
Proporcionar recomendaciones: según los riesgos identificados, este taller proporciona recomendaciones para ayudar a administrar y mitigar mejor los riesgos.

El taller de revisión de la estrategia de prueba se puede llevar a cabo en persona para proyectos complejos, en cuyo caso, generalmente es un taller único que abarca todos los temas requeridos. El taller se lleva a cabo con mayor frecuencia de forma remota.

Las siguientes secciones abarcan los aspectos de nivel superior del taller de revisión de la estrategia de prueba y proporcionan un muestreo de los tipos de preguntas que se tratan en cada sección.

Estrategia de prueba global

La estrategia de prueba cubre el enfoque de alto nivel y el plan para validar que la solución sea adecuada para su uso en producción. Este tema se centra en responder a preguntas como las siguientes:

¿Existe una estrategia de prueba documentada?
¿La estrategia de prueba refleja las necesidades y circunstancias de este proyecto?
¿La estrategia de prueba está expresada en un lenguaje que se relacione con el proyecto y sea comprensible para las partes interesadas del proyecto y del negocio?

Asignación del ámbito del proyecto al ámbito de la prueba

El ámbito de la prueba depende claramente del ámbito del proyecto. Esta sección examina en qué grado el ámbito de la prueba cubre el ámbito del proyecto.

En este tema se considera esta pregunta: ¿cómo y como parte de qué fase de prueba o tipo de prueba se deben probar las áreas de ámbito funcional del proyecto?

Por ejemplo, plantéese las siguientes áreas de ámbito:

Procesos de negocio
Requisitos empresariales
Requisitos de diseño
Datos (para uso funcional, migración, interfaces, informes/BI, etc.)
Geografía
Áreas personalizadas
Cambios del proceso
Seguridad
Requisitos reglamentarios
Objetivos del proyecto

Otra cuestión que se considera en este tema es: ¿cómo y como parte de qué fase de prueba o tipo de prueba se deben probar las áreas de ámbito no funcional del proyecto?

Por ejemplo, plantéese las siguientes áreas de ámbito:

Rendimiento
Facilidad de uso
Operabilidad
Mantenimiento
Recuperación ante desastres
Continuidad del negocio
Otras áreas, según su pertinencia para este proyecto

Plan de prueba general

Las pruebas se llevarán a cabo durante todo el proyecto y el plan de pruebas de alto nivel proporciona la estructura para mostrar cómo los distintos tipos y fases de prueba se complementan entre sí para proporcionar una validación incremental y completa de la solución. Este tema se centra en responder a preguntas como las siguientes:

¿Cómo se integra el plan de prueba de alto nivel dentro del plan del proyecto?
¿La planificación de la prueba refleja la estrategia de la prueba?
¿Todos los tipos y fases de prueba se reflejan con precisión en el plan de prueba?
¿El plan de prueba proporciona suficiente tiempo y esfuerzo para realizar pruebas en proporción al tamaño y la complejidad del proyecto?
¿Muestra el plan de prueba que el tiempo y el esfuerzo que se asignan a las diversas áreas de prueba son proporcionales al riesgo que representa para la empresa?

Fases y tipos de prueba

Las pruebas en una aplicación empresarial como Dynamics 365 son multifacéticas, y las fases y los tipos de prueba representan la validación de diferentes capas y dimensiones de la solución. Esta sección examina la integridad de algunas definiciones de prueba importantes y atributos de gestión de pruebas de las fases y tipos de prueba clave.

Las siguientes tablas muestran una vista de las áreas que debería haber definido cada tipo de prueba.

Pruebas: definiciones clave

Fase de prueba/tipo de prueba	Objetivos clave	Documentos de origen	Cobertura de la prueba	Criterios de entrada	Criterios de salida
Introduzca el título de la fase de prueba (como Pruebas de integración o Pruebas de aceptación de usuario) o los tipos de prueba clave (como Pruebas de rendimiento o Transición simulada).	Introduzca los objetivos clave que se espera lograr en cada fase de prueba.	Indique el tipo de documento/área de requisitos que se usa para definir el contenido de los casos de prueba y los criterios de aceptación; en otras palabras, ¿qué se usa como definición con la que se valida el resultado de la prueba?	Determine qué áreas del ámbito del proyecto se espera que valide esta fase, por ejemplo: - Proceso de negocio integral y configuración relacionada - Funciones específicas - Datos migrados	Defina los criterios de entrada que deben cumplirse para que esta fase de prueba se considere lista para iniciar la implementación formal.	Defina los criterios de salida que deben cumplir los resultados de la prueba para que se considere que esta fase de prueba cumple su objetivo y puede salir formalmente de esta fase.

Administración de pruebas

Fase de prueba/tipo de prueba	Preparación de la prueba	Implementación de la prueba	Informe de prueba	Herramientas de administración de la prueba	Propiedad de la prueba
Introduzca el título de la fase de prueba (como Pruebas de integración o Pruebas de aceptación de usuario) o los tipos de prueba clave (como Pruebas de rendimiento o Transición simulada).	Breve descripción de la preparación de la prueba que se espera que cumpla los criterios de entrada de la prueba (por ejemplo, escritura del guion de la prueba, requisitos de datos o entornos).	Breve descripción de cómo se implementará esta prueba (qué roles realizarán las pruebas o cuál será el ciclo de vida de un defecto).	Defina cómo se informará sobre el progreso de la prueba y cómo se analizarán y notificarán los resultados y la calidad, como, por ejemplo: - Informes para uso interno del proyecto - Informes a las principales partes interesadas del negocio	Determine las herramientas que se utilizarán para almacenar, revisar y administrar el marco de prueba, los casos de prueba y los resultados de las pruebas. Además, considere qué herramientas se utilizarán para asignar los casos de prueba al requisito/ámbito, como Azure DevOps, Kira o Microsoft Excel.	Defina quién es responsable del resultado de esta prueba.

La información de las tablas anteriores se aplica a todos los tipos de pruebas. Las fases y tipos de prueba clave que podrían cubrirse incluyen:

Pruebas unitarias
Pruebas funcionales/de procesos
Pruebas de integración de sistemas
Pruebas de extremo a extremo
Pruebas de aceptación de usuario (UAT)
Pruebas de regresión

Los tipos de prueba no funcional clave que podrían cubrirse son:

Pruebas de rendimiento
Validación de datos
Pruebas de seguridad

Esta lista no es exhaustiva y, según la naturaleza del proyecto, puede haber otros tipos de pruebas adecuadas, como las pruebas de punto de venta (PDV) para tiendas minoristas o las pruebas de dispositivos de escaneo para aplicaciones de almacén.

Otras preguntas que son especialmente pertinentes para un tipo o fase de prueba determinado y que podrían no estar adecuadamente cubiertas por las categorías anteriores son:

¿Se han definido casos de prueba funcional a partir de requisitos o escenarios empresariales?
¿Las pruebas funcionales cubren todos los módulos funcionales?
¿Se validan los scripts de prueba funcional con usuarios empresariales?
¿La estrategia de las pruebas de integración de sistemas explica la creación de un entorno de prueba similar al de producción para realizar las pruebas de integración de sistemas?
¿Se ha definido un método para sincronizar/resincronizar todos los sistemas que participan en las pruebas de integración de sistemas?
¿Se han validado los casos de prueba de un extremo a otro con el propietario de cada módulo funcional?
¿La estrategia de pruebas de un extremo a otro tiene en cuenta las pruebas de facilidad de uso?
¿Se han identificado las partes interesadas clave para UAT?
¿El plan de UAT documenta claramente el rol de cada parte interesada en la fase de UAT?
¿Ha establecido un plan de comunicación claro durante la UAT para todas las partes interesadas necesarias?
¿Se ha descompuesto cada proceso principal para incluir subprocesos?
¿Se han priorizado los escenarios de prueba en UAT?
¿El plan de pruebas de UAT incluye el aprovisionamiento adecuado del entorno de pruebas de UAT?
¿Ha planificado la formación de los usuarios antes de realizar las pruebas UAT para los evaluadores?
¿Se ha establecido una definición adecuada para el conjunto básico de pruebas que constituiría un conjunto de pruebas de regresión?
¿Existe un proceso para identificar los cambios recientes (en un nivel alto) para las pruebas de regresión?
¿El plan de prueba incluye la automatización de las pruebas de regresión?
¿Se ha definido un proceso para las pruebas de validación de datos?
¿Se han identificado las partes interesadas del negocio correctas para realizar pruebas de validación de datos?
¿Existe un plan para realizar pruebas de un extremo a otro con los datos migrados?
¿Las pruebas de validación de datos incluyen informes y planes de conciliación de datos?
¿Se han identificado áreas clave para las pruebas de seguridad?
¿El plan de prueba requiere que se definan y completen todos los roles y privilegios de seguridad necesarios antes de la UAT o la prueba de integración de sistemas?
¿La estrategia de pruebas de seguridad incluye los requisitos de seguridad de su organización?

Herramientas

La planificación, preparación, realización y presentación de informes de las pruebas requiere una gestión significativa. Para los proyectos más sencillos, el proceso puede administrarse a través de hojas de cálculo, pero podría volverse difícil de manejar y de seguir para los más complejos. La mayoría de los proyectos utilizarán algún tipo de software de gestión de tareas. Además, muchas organizaciones utilizan herramientas de automatización para planificar, crear pruebas, ejecutar pruebas e informar sobre los resultados de las pruebas. Este tema se centra en responder a preguntas como las siguientes: