Una prueba móvil es tan útil como su entorno. 

Tu equipo tiene una prueba móvil para el proceso de compra. Funciona correctamente en el teléfono donde se creó. Antes del próximo lanzamiento, alguien pregunta si ese mismo proceso funciona en los dispositivos y sistemas operativos que usan tus clientes. Es entonces cuando la conversación pasa de la prueba en sí al entorno que la rodea. 

También puede ocurrir lo contrario. Un equipo puede tener muchos dispositivos, pero ningún método repetible para convertir sus experiencias de usuario más importantes en pruebas. Ninguna de las dos situaciones requiere una solución universal. Requiere considerar la creación de pruebas y el acceso a los dispositivos como decisiones interrelacionadas al planificar las pruebas móviles. 

¿Puede tu equipo crear pruebas que quiera mantener? 

Una prueba móvil debe capturar un recorrido del usuario que merezca la pena revisar: iniciar sesión, realizar un pedido, pagar una factura o recuperarse de una sesión interrumpida. Crear la primera versión es útil. Mantenerla útil a medida que cambian las pantallas, las etiquetas y el comportamiento de la aplicación es una tarea más larga. 

Consideremos quién se encargará de crear las pruebas. ¿Podrán contribuir quienes comprenden la experiencia del usuario? ¿Puede otro miembro del equipo leer el flujo de trabajo y ver qué se verifica? Si una prueba falla tras una actualización de la aplicación, ¿puede el equipo determinar si la aplicación cambió o si la prueba necesita revisión? Estas preguntas definen el valor de un enfoque de creación de pruebas más que la rapidez de una primera demostración. 

Una organización puede que ya cuente con una plataforma de automatización utilizada en otras áreas del negocio. Extender ese enfoque familiar al ámbito móvil puede ser una buena opción, siempre que pueda gestionar las aplicaciones y los dispositivos que el equipo necesita validar. Otra organización podría estar definiendo su estrategia de desarrollo móvil desde cero. Ambas deben evaluar cómo se mantendrán las pruebas una vez finalizado el proyecto inicial. 

¿Se pueden ejecutar esas pruebas donde se necesitan? 

La siguiente decisión se refiere al entorno. ¿Qué modelos de dispositivos y versiones de sistemas operativos son relevantes para sus usuarios? ¿Qué flujos de trabajo requieren hardware físico en lugar de un dispositivo virtual? ¿Quién necesita acceso y cuándo estarán disponibles los dispositivos para su lanzamiento? 

La solución puede ser un laboratorio interno existente, dispositivos alojados por un proveedor o una combinación de ambos. Cada opción implica trabajo operativo. Los dispositivos deben aprovisionarse, actualizarse, configurarse para la aplicación y ponerse a disposición de los equipos adecuados. Un clúster de dispositivos puede satisfacer esta necesidad, pero su valor depende de si se ajusta a la cobertura de pruebas y al calendario de lanzamientos que la organización tiene previsto. 

No hay razón para suponer que un equipo deba reemplazar un laboratorio que funciona correctamente. La pregunta clave es si su entorno actual puede soportar la cobertura, el acceso y el control que espera a medida que aumentan las pruebas móviles. En particular, una prueba que espera un dispositivo o se ejecuta con una configuración diferente a la prevista genera menos confianza en el resultado. 

La conexión es tan importante como cualquiera de las dos opciones. 

Una herramienta de autoría y un entorno de dispositivo solo se convierten en un flujo de trabajo de pruebas cuando pueden funcionar conjuntamente. Una prueba debe poder acceder al dispositivo previsto, ejecutarse con la versión correcta de la aplicación y proporcionar al equipo la información suficiente para comprender lo sucedido. Esta conexión merece atención desde el principio, antes de que un conjunto de herramientas cada vez más amplio genere costes adicionales. 

Por eso, la elección no debe plantearse simplemente como "¿Qué herramienta escribe nuestras pruebas?". Hay que preguntarse cómo es el proceso desde que el autor de la prueba llega al dispositivo para el equipo que lo operará. Averigüe qué se debe configurar, quién es el responsable y cómo investigará el equipo un fallo. 

Planifica toda la ruta desde la prueba hasta el resultado. 

Empiece con un pequeño conjunto de recorridos móviles importantes. Decida cómo el equipo creará y mantendrá esas pruebas, y luego asigne cada una a los dispositivos y condiciones que debe cubrir. Verifique que el método de creación de pruebas se pueda conectar al entorno elegido y que el equipo pueda repetir la ejecución cuando una versión dependa de ella. 

Esa es la prueba práctica de una estrategia de pruebas móviles: ¿Puede su equipo crear las pruebas necesarias, ejecutarlas en los dispositivos que necesita y comprender los resultados lo suficientemente bien como para actuar?  

Tercera parte de nuestra serie de blogs sobre UiPath examina una forma de conectar esas piezas con UiPath y Digital.ai Pruebas.