¿Cuáles son las dificultades enfrentadas al construir una prueba de aplicación móvil? ¿Cómo puedes explicar esto en términos simples?

Un acrónimo que solíamos usar en HP era ‘FLURPS’. Esto significa:

  • Funcionalidad: ¿hace lo que se supone que debe hacer? Pruébelo con los requisitos / especificaciones / contrato / etc.
  • Capacidad de localización: ¿se puede traducir fácilmente a los idiomas locales?
  • Usabilidad: ¿Es la interfaz natural y obvia? ¿Todos pueden usarlo?
  • Fiabilidad: ¿nunca falla? Si es así, ¿lo hace con gracia?
  • Rendimiento: ¿Va lo suficientemente rápido? ¿Incluso en plataformas más antiguas / más baratas?
  • Capacidad de soporte: ¿es fácil de soportar y mantener? ¿Proporciona información de error que ayuda a capturar errores? ¿Ayuda a las personas de soporte en línea?

Por supuesto, hay mucho más que puedes hacer, pero este es un buen comienzo.

También descubrí que cada tipo diferente de prueba arrojaría diferentes tipos de errores, así que no te quedes atascado con un método. Por ejemplo, cuando se realizaron todas las pruebas planificadas, colocamos la aplicación junto a un plato de donas, para que cualquiera pudiera masticar y probar. También premiamos a las personas que encontraron errores con una botella de vino por error (esto fue genial para transportar en las esquinas).

Aquí es donde debe comenzar a pensar como la persona de negocios frente a un desarrollador. Cuando tenga una aplicación que haya creado, piense que es lo mejor desde el pan rebanado, esa es solo su perspectiva. Eso sí, la aplicación es probablemente una aplicación increíble, pero aún debe asegurarse de que hace lo que está diseñada para hacer.

¿La aplicación resuelve el problema comercial? Si crea varios casos de uso y los ejecuta, ¿es satisfactoria la operación? ¿Alguno de los casos de uso falla?

Esto es lo que debe pensar al crear pruebas para su aplicación. Piensa en lo que sucederá si tu aplicación falla.