Introducción

El trabajo de un arquitecto de soluciones continúa después de haber diseñado el sistema. La siguiente tarea es asegurarse de que el sistema se implemente y lo utilicen usuarios reales.

Rol del arquitecto de soluciones en las pruebas y la puesta en marcha

Normalmente, el arquitecto de soluciones es una de las personas que mejor conoce cómo funciona la solución y puede orientar al equipo de pruebas sobre cómo probarla.

El arquitecto de soluciones desempeña un rol clave en las pruebas y debe:

• Mantenerse implicado hasta el final del periodo de pruebas para garantizar el éxito.
• Ayudar a educar al equipo de pruebas sobre la arquitectura de la solución para garantizar que prueben adecuadamente todos los componentes e integraciones.
• Clasificar los problemas complejos que surjan durante las pruebas, los ensayos y después de la puesta en marcha.
• Participar con el equipo de puesta en marcha durante la planificación e implementación de la estrategia de puesta en marcha.

Información general sobre las pruebas

Las pruebas adecuadas son importantes para ayudar a garantizar el éxito del proyecto.

Las pruebas no se limitan al proceso de asignar requisitos a la funcionalidad. Si bien es importante crear e implementar estos tipos de pruebas, deben probarse muchos más aspectos de la solución. Independientemente de la métrica específica que se esté probando, el proceso es similar.

El proceso de prueba incluye los siguientes pasos:

• Planificación: revise la estrategia de prueba general, desarrolle el plan de prueba y realice el análisis necesario para las métricas de referencia. Identifique los escenarios empresariales clave que están dentro y fuera del alcance. Documente los requisitos, si ese paso aún no se ha completado.

• Preparación: configure los entornos necesarios para las pruebas de rendimiento, las pruebas de aceptación del usuario, etc. Revise los datos recibidos para la migración, tanto antes como después de la prueba de migración. Valide los requisitos del sistema de alto nivel y luego desarrolle los scripts necesarios.

• Ejecución: ejecute scripts de prueba, analice resultados, identifique posibles cuellos de botella y luego revise errores y comportamientos.

• Elaboración de informes: prepare una evaluación detallada del plan de presentación de informes, los resultados y el plan de acción.

Tipos de pruebas

El arquitecto de soluciones debe participar en el debate sobre la cantidad y el tipo de pruebas que se requieren para un proyecto.

Entre los tipos de pruebas comunes en Microsoft Power Platform se incluyen:

• Pruebas unitarias: realizadas por el creador la aplicación, el analista de negocios, el consultor funcional o el desarrollador.

• Pruebas funcionales: verifican que la implementación cumpla con los requisitos.

• Pruebas de aceptación: las realizan los usuarios para dar su aprobación formal.

• Pruebas de regresión: evalúan funciones no cambiadas para la regresión, y suelen realizarse cada vez que ha ocurrido una actualización del sistema.

• Pruebas de integración: comprueban que todo funcione bien en conjunto, lo que incluye los servicios y los datos integrados de otros orígenes. El objetivo es que todos los sistemas integrados funcionen en armonía.

• Pruebas de rendimiento: comprueban si la aplicación funciona con la carga máxima esperada y el volumen máximo de transacciones; por lo general, se automatizan y se ejecutan antes de la puesta en marcha.

• Pruebas de migración: cargan los procesos de migración de datos para garantizar la calidad de estos. Estas pruebas se realizan en estrecha colaboración con expertos en la materia que conozcan los datos del cliente. Estos expertos deben comprender la transición y transformación de los datos, y pueden confirmar que los datos migrados son válidos con el contexto adecuado.

• Pruebas de recuperación ante desastres: comprueban si los planes de recuperación ante desastres funcionan, ya que, de lo contrario, no sirven para nada.

• Pruebas de puesta en marcha: simulaciones del proceso de puesta en marcha y del funcionamiento de toda la solución. Por lo general, estas pruebas se realizan antes de la puesta en marcha.

No siempre es necesario hacer todas las pruebas, esto dependerá del tamaño y el alcance del proyecto.

Pruebas unitarias

Puede utilizar una prueba unitaria para comprobar si una función o característica específica de su aplicación está funcionando correctamente. Normalmente, los creadores y desarrolladores de aplicaciones realizan pruebas unitarias. Cada miembro del equipo debe verificar su propio trabajo antes de la transferencia.

Las pruebas unitarias son recomendables, pero no obligatorias. Al comenzar, o si la cantidad de código en su solución es relativamente pequeña, puede percibir que dedica más tiempo a escribir pruebas que a crear la funcionalidad incluida en su solución. Las ventajas de las pruebas unitarias se van acumulando a medida que la solución se vuelve más grande y compleja, particularmente con el desarrollo del lado del servidor, donde es normal que haya importantes beneficios en la depuración local usando datos simulados o falsos en un marco de prueba.

Las pruebas manuales se pueden realizar con todas las aplicaciones, reglas comerciales y complementos. Algunas pruebas se pueden automatizar utilizando Estudio de Microsoft Power Apps y Visual Studio. Un marco popular para las pruebas unitarias de desarrollo en el lado del servidor es Fake Xrm Easy.

El arquitecto de soluciones debe decidir las herramientas que se utilizarán para las pruebas unitarias y el nivel de automatización que se ha de emplear.

Pruebas de integración

El arquitecto de soluciones debe ayudar al equipo a comprender cómo probar los componentes integrados.

Una ventaja de Microsoft Power Platform es su sólida capacidad de integración. La integración es uno de los puntos más importantes de la implementación del proceso de negocio, ya que garantiza que la implementación funcione correctamente, además de tener un gran impacto en la adopción general.

El arquitecto de soluciones y el cliente deben revisar los escenarios de pruebas que implican integraciones con otras aplicaciones de línea de negocio para garantizar que se creen escenarios de pruebas integrales. Es probable que esta revisión requiera que el cliente planifique tener entornos de prueba para sus otras aplicaciones.

Es posible que cada integración tenga su propio método de prueba, y este tendrá que definirse con antelación. El equipo de pruebas debe participar desde el principio para determinar cómo se prueba cada escenario de integración. Los equipos deben garantizar que las integraciones necesarias puedan configurarse para admitir las pruebas.

Un aspecto clave de las pruebas de integración debe centrarse en los datos que entran y salen de la integración. Gran parte del debate de la sección de pruebas de validación de datos también puede aplicarse a los datos involucrados en las integraciones.

Dado que las pruebas de integración pueden involucrar a otros sistemas, debe asegurarse de que se utilicen entornos de prueba para todos los componentes. No desea que las pruebas de integración se comuniquen con un sistema activo y luego se modifiquen los datos de producción por accidente. Ocasionalmente, estos escenarios impulsan las opciones de configuración en la integración de aplicaciones para que pueda someterse a pruebas. Contar con la capacidad de desactivar integraciones puede ayudar a realizar pruebas sin invocar la integración.

El proceso de generación de integraciones ahora es más accesible y, por lo tanto, es más sencillo para un mayor número de miembros de los equipos de proyecto. A menudo, las integraciones pueden ocultarse dentro de las aplicaciones de lienzo de Power Apps o los flujos de Microsoft Power Automate. Estas integraciones ocultas suelen pasar desapercibidas, ya que la aplicación simplemente utiliza un conector de superficie de una fuente externa. El plan debe tener en cuenta estas integraciones como cualquier otra integración y probarlas en consecuencia.

Pruebas de aceptación de usuarios

Las pruebas de aceptación de usuario (UAT) están a cargo del usuario final, y tienen el objetivo de probar la facilidad de uso del sistema y de otorgar una aprobación formal. Las pruebas de aceptación suelen realizarse como una comprobación final antes de implementar la funcionalidad. El objetivo de esta prueba es confirmar que lo que han desarrollado los creadores coincida con los requisitos solicitados inicialmente por el usuario.

Consejos para obtener buenos resultados con las UAT:

• Haga las pruebas con usuarios reales.
• Seleccione a usuarios con distintos niveles de conocimientos informáticos; así recibirá distintos tipos de comentarios.
• No dé instrucciones a los usuarios, así podrá ver si entienden la aplicación de forma intuitiva.
• Observe cómo navegan los usuarios por la aplicación sin ayuda y luego determine dónde puede mejorar el diseño.
• Cuando el usuario se queda atascado en una pantalla, pídale que explique sus expectativas.
• Experimente con diferentes dispositivos para asegurarse de que los casos de prueba se comporten de manera similar.
• Idealmente, pruebe la aplicación en el entorno o la ubicación real del usuario si la aplicación tiene funciones sin conexión.
• Pida a sus usuarios que intenten "estropear" su aplicación, por ejemplo, que introduzcan caracteres inusuales en las columnas de texto.
• En la prueba, los usuarios normalmente seguirán la "ruta feliz" (la ruta que sigue un usuario cuando todo va perfectamente). Pídales que también prueben escenarios como cancelar un informe de gastos en lugar de enviarlo o rechazar un informe de gastos en lugar de aprobarlo.

Es posible que los usuarios no estén familiarizados con el software de prueba. Infórmeles qué tipo de comentarios está buscando. Suele ser útil proporcionar una plantilla de errores para asegurarse de que los evaluadores expliquen exactamente lo que estaban haciendo, lo que sucedió, lo que esperaban que sucediera e información relevante sobre su entorno de prueba (como el tipo de dispositivo y el navegador).

El arquitecto de soluciones tendrá que ayudar a clasificar los problemas que detecten los usuarios durante sus pruebas.

Pruebas de seguridad

Las pruebas de seguridad son importantes para garantizar la seguridad de la aplicación y el cumplimiento de los requisitos normativos. Dichas pruebas deben incluir una evaluación de vulnerabilidad para garantizar que la aplicación sea segura. También deben incluir pruebas del contexto de seguridad de diferentes tipos de usuarios para garantizar que se disponga de un nivel adecuado de datos y características.

Las pruebas de seguridad también deben tener en cuenta el modelo de seguridad dentro de la aplicación para acceder a sus datos y características. Las pruebas deben incluir escenarios con distintos usuarios con diferentes roles y características de acceso para garantizar que el modelo de seguridad se mantenga. Las pruebas del modelo de seguridad deben garantizar que no se compartan los datos en exceso ni en defecto. Una forma de abordar las pruebas del modelo de seguridad es crear una cuenta de usuario de prueba dedicada para cada conjunto de roles principales.

El arquitecto de soluciones debe ayudar a definir el nivel de las pruebas de seguridad que se han de realizar.