Prueba de aplicaciones empresariales móviles para SAP

Publicado el

(Alexander Ilg) (11 de noviembre , 2020)

Las pruebas son una parte importante de cada proyecto de desarrollo de software: pruebas unitarias, pruebas de integración, pruebas de aceptación de usuarios, etc. En este blog, quiero discutir las pruebas de aplicaciones empresariales móviles, especialmente las que se usan sin conexión.

Ningún software es perfecto. Los cohetes se envían a Marte y se estrellan debido a errores. Algunos aviones se apagan si no se “reinician” al menos cada 248 días (y me preguntas por qué tengo miedo de volar).

¿Miedo a volar? ¡No mire los informes de errores del software de aviones!

La lista sigue y sigue, incluso hay un artículo de Wikipedia que muestra ejemplos de errores en todos areas – https://en.wikipedia.org/wiki/List\_of\_software\_bugs .

Tener y corregir un error en un lugar central como un El sistema SAP ya puede ser un problema (reinicio del sistema, tiempo de inactividad, usuarios insatisfechos, pérdida de datos, etc.). Arreglar un error en una aplicación instalada en muchas computadoras (como, por ejemplo, SAP GUI) es un poco más complicado, pero aún así es manejable si todas las máquinas son internas y están conectadas a la red corporativa.

Se pone mucho Es más difícil enviar una nueva versión de una aplicación empresarial móvil sin conexión que se instala en teléfonos inteligentes y tabletas fuera de la oficina de la empresa. Incluso si tiene una solución de gestión de dispositivos como Idaptive, SAP Mobile Secure, Mobile Iron o Airwatch, todavía es mucho trabajo. Si los usuarios tienen una mala conexión de red, es difícil distribuir nuevas versiones. Peor aún si hay dependencias entre la aplicación móvil y el software del lado del servidor; en ese caso, ambos deben actualizarse al mismo tiempo, lo que puede ser realmente complicado si la base de usuarios está en múltiples zonas horarias y distribuida por todo el mundo. Debido a este hecho, es importante probar con mucho cuidado las aplicaciones empresariales móviles. No importa qué plataforma utilice: Agentry, SMP, SCP Mobile Services, MobiLink u otra cosa. Las pruebas deben realizarse en todas las capas, incluido el cliente, el middleware y el backend. La siguiente es una lista de pruebas que se deben realizar para cada aplicación.

Pruebas funcionales

  • Prueba de todas las funciones en ambas direcciones: cree datos en SAP y sincronícelos con el dispositivo móvil. Cree datos en el dispositivo móvil y envíelos a SAP. Actualice los registros en ambos lados, elimine los datos y verifique que también se eliminen en el sistema opuesto.
  • Pruebe la validación en el dispositivo móvil: si el usuario recibe el mensaje de advertencia / error correcto al ingresar los datos incorrectos ?

Pruebas de rendimiento: sincronización y en el dispositivo

  • Sincronice con el volumen máximo de datos que espera. Además, tenga en cuenta que el volumen de datos podría aumentar con el tiempo.
  • Pruebe con la cantidad máxima de dispositivos simultáneos para ver cómo el sistema puede manejar la carga.
  • Pruebe el dispositivo con la cantidad máxima de datos: ¿cómo es el rendimiento de las listas y los cuadros de diálogo de detalles? ¿Qué tan fluida es la navegación dentro de la aplicación? ¿Qué tan rápido es el tiempo de inicio? Probar en un simulador / emulador nunca es lo suficientemente bueno, ¡debe probarlo en el dispositivo real que el usuario tendrá en sus manos más tarde!

Pruebe las pautas UI / UX de la sistema operativo móvil

  • Si tiene una aplicación nativa, ¿sigue las pautas de UX de Apple, Google y Microsoft?
  • Si tiene una aplicación híbrida / independiente de la plataforma , ¿sigue pautas comunes (por ejemplo, la guía SAP Fiori UX)?

Pruebas de usabilidad

  • Entregue la aplicación a los usuarios y déjeles que la prueben. ¿Es intuitivo? ¿Pueden descubrir cómo usarlo incluso sin o con poca documentación?
  • Pruebe su solución con usuarios experimentados con teléfonos inteligentes / tabletas y con aquellos que no están acostumbrados a la tecnología moderna.
  • Si se implementa internacionalmente, pruebe con usuarios de diferentes países para ver cómo reaccionan al software.
  • Pruebe con diferentes idiomas y configuraciones de ubicación para asegurarse de que todo se muestre correctamente
  • Deje que la traducción sea revisada y probada por un hablante nativo
  • ¡Escuche a sus usuarios de prueba! ¡Este es, con mucho, el mejor comentario que puede obtener!

Pruebe detrás de la cortina, no solo la interfaz de usuario, también el middleware y la integración de backend

  • Cliente de prueba, middleware (si tiene alguno) y backend. Todo debe funcionar bien en conjunto.
  • Asegúrese de que la comunicación entre los tres componentes funcione correctamente.

Pruebe los casos positivos y negativos

  • Pruebe su solución con datos y casos de prueba que espera que funcionen
  • Pruebe su solución con datos que espera fallar.Todos sabemos que los usuarios ingresarán la información más inesperada y debe asegurarse de que la aplicación no se bloquee en tal escenario.
  • Asegúrese de que ambos casos se cubran correctamente
  • Prueba la aplicación cuando el servidor de middleware está inactivo. ¿Se comporta como se esperaba? Pruébelo también cuando SAP no esté disponible.
  • Elimine la aplicación en medio de un proceso de guardado o sincronización. ¿Todavía funciona? ¿Perdiste algún dato?

¿Te suena familiar?

Prueba fuera del laboratorio / con la red real

  • Prueba tu aplicación con la red real que tus usuarios usarán más adelante. ¿El rendimiento sigue siendo lo suficientemente bueno con GPRS o Edge? ¿Es aceptable el rendimiento en ubicaciones remotas?
  • Pruebe el software en el dispositivo real, no solo en un simulador. ¿Se muestra todo como debería ser? ¿El rendimiento es el esperado?
  • Pruebe el software con el dispositivo real en condiciones reales. ¿Puedes leer la pantalla a la luz del sol? ¿El dispositivo funciona al aire libre con calor o frío?
  • Pruebe la solución con todas las demás aplicaciones instaladas. ¿Hay efectos secundarios? Con la filosofía de caja de arena de Android e iOS debería funcionar, pero es mejor que la pruebes.
  • Pruébelo en situaciones de poca memoria: ¿la aplicación sigue funcionando? ¿Cómo es el desempeño en este caso? ¿Qué sucede si la aplicación se elimina de la memoria?
  • Pruebe la aplicación con versiones anteriores del sistema operativo. Además, pruébelo con las versiones beta que se lanzarán en el futuro.
¿Puedes trabajar con una velocidad aceptable en medio de la nada?

Escribe scripts de prueba automatizados

Deja que tus desarrolladores creen casos de prueba automáticos que se puede ejecutar antes de cada compilación. Hacer esto puede reducir el esfuerzo de prueba y detectar los primeros errores antes de que los probadores reales comiencen sus actividades. Sin embargo, las pruebas unitarias automatizadas nunca pueden reemplazar las pruebas «reales», solo complementarlas.

Prueba en diferentes dispositivos

Si tiene una estrategia BYOD (traiga su propio dispositivo), intente probar la aplicación en diferentes dispositivos. ¿La aplicación funciona en todas las resoluciones de pantalla? Si es independiente de la plataforma, ¿funciona en todas las plataformas?

Pruebe la instalación / actualización

Pruebe la instalación y actualización de su aplicación móvil. ¿Se puede descargar el APK, IPA o XAP a través de la conexión telefónica?

Pruebe la seguridad de la aplicación

  • Utilice un rastreador de red para ver si el cifrado que activó está activo.
  • Intente abrir la base de datos del dispositivo para ver si está realmente encriptado.
  • Pruebe el almacenamiento seguro como, por ejemplo, el llavero de iOS: ¿estos datos son solo locales o ¿Enviar a la nube?

Pruebe la parte de administración de la aplicación

  • ¿Puede crear nuevos usuarios, dispositivos, etc. en su entorno móvil?
  • ¿Puede anular el registro o eliminar dispositivos?
  • ¿Están configurados correctamente los registros? ¿Tienen suficiente información para analizar problemas? ¿Está configurado lo suficientemente bajo como para que el registro no disminuya el rendimiento?

No importa cuánto tiempo y cuán bien pruebes, habrá errores que se escabullen por las grietas. Cuanto más compleja sea la aplicación, es más probable que suceda. Por eso, siempre debe tener una solución alternativa: puede ser una hoja de Excel o simplemente una hoja de papel. Idealmente, nunca necesitará usarlo.

Las pruebas son un tema candente: ¿cuántas pruebas son suficientes? ¿Cuánto es demasiado? Se podría argumentar que uno nunca puede probar lo suficiente, sin embargo, alguien debe pagar por ello. Como con todo, necesitas encontrar el equilibrio adecuado.

¡Buena suerte con tus pruebas! Y si tiene alguna pregunta o necesita ayuda con sus pruebas, póngase en contacto conmigo en [email protected] .

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *