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.
Nota
Las pruebas deben ser un esfuerzo continuo desde el primer componente que se cree hasta la puesta en marcha; no puede ser un gran ejercicio único.
Probar es algo más que el 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: el objetivo es que todos los sistemas integrados funcionen en armonía. Las pruebas de integración comprueban que todo funcione de forma conjunta, incluidos los servicios y datos integrados de otras fuentes.
Pruebas de rendimiento: estas pruebas se verifican con la carga máxima esperada y el volumen máximo de transacciones y, por lo general, se automatizan y se ejecutan antes de la puesta en marcha.
Pruebas de migración: practican la migración de datos para garantizar la calidad de los datos. Estas pruebas se realizan en estrecha colaboración con expertos en la materia que conocen 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: un plan de recuperación ante desastres es inútil si no funciona.
Pruebas de puesta en marcha: simulacros del proceso de puesta en marcha y la solución completa. Por lo general, estas pruebas se realizan antes de la puesta en marcha.
No se requerirán todos los tipos de pruebas; vienen determinadas por el 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 comienzan a acumularse cuando su solución se vuelve más grande y compleja, particularmente con el desarrollo del lado del servidor, donde podría ver beneficios significativos en la depuración local mediante el uso de 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 enfoque de prueba, que es necesario definirse. 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 del usuario
Las pruebas de aceptación del usuario (UAT) las realizan los usuarios finales para dar una aprobación formal y probar la facilidad de uso del sistema. Las pruebas de aceptación suelen realizarse como una comprobación final antes de implementar la funcionalidad. El objetivo de esta prueba es asegurar que lo que han desarrollado los creadores se ajustará a los requisitos solicitados inicialmente por el usuario.
Consejos para obtener buenos resultados con las UAT:
- Pruebe con usuarios reales.
- Seleccione usuarios con niveles de capacidades de TI diversas. Como consecuencia, puede recibir comentarios diversos.
- No dé instrucciones al usuario, compruebe si puede comprender 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.