Cómo decidir sobre los bugs en el móvil

Daniel Knott Daniel Knott
tiempo de lectura minutos
Applause Blog Logo

Veamos cómo podemos integrar la corrección de errores en una aplicación móvil nativa después de publicarla.

Cualquier producto de software, tanto si se trata de una web como de una aplicación móvil o para escritorio, está a prueba hasta que demuestra que sus características funcionan tal y como se esperaba. Dicho de otro modo: el software nunca está libre de errores. En función del producto, la corrección de errores durante la fase de producción no resulta sencilla y, en la mayoría de los casos, se trata de un proceso caro.

Antes de la publicación de una aplicación

Para reducir al mínimo la publicación de revisiones, antes de que el equipo de desarrollo móvil envíe una aplicación móvil a la plataforma correspondiente, es necesario llevar a cabo una fase de pruebas intensivas. Otra opción es enviar la aplicación a evaluadores de versiones beta externos para obtener comentarios en una fase temprana. Sin embargo, sabemos que la mayor parte de los errores graves se producen en los dispositivos de los clientes y, muy a menudo, en situaciones que solo se producen en el mundo real.

La matriz de errores para dispositivos móviles

¿Cómo podemos decidir qué errores requieren la publicación de una revisión en un entorno móvil? A lo largo de los últimos años, he visto a muchos equipos enfrentándose a esta cuestión. Algunos han intentado corregir todos y cada uno de los errores durante la fase de producción, pero terminaron dedicándose de forma exclusiva a la corrección de errores en la aplicación publicada, dejando de lado el desarrollo de características. En este sentido, es importante que los equipos encuentren el equilibrio adecuado entre elaborar una revisión y esperar a la siguiente versión.

Para facilitar la toma de decisiones en lo relativo a las revisiones, he creado la matriz de errores para dispositivos móviles. Esta cuenta con dos ejes. El eje X indica la gravedad/importancia para el usuario, mientras que el Y muestra la gravedad/importancia para la empresa.

Mobile Bugs Fixes

Hay tres resultados posibles. He incluido un ejemplo deerror en cada escenario:

  1. Revisión: esta área es la que tiene el mayor impacto para la empresa y el usuario. Si se detecta un error en la aplicación definitiva y puede clasificarse en esta categoría, el equipo debe corregirlo lo antes posible.
    Ejemplo de error:
    no se puede iniciar sesión.
  2. Siguiente versión: los errores en esta categoría pueden afectar más a la empresa o al usuario. El error no es lo suficientemente grave para publicar una revisión, aunque el equipo deberá corregirlo en la siguiente versión.
    Ejemplo de error
    : los elementos de la interfaz de usuario de la aplicación se encuentran en una posición incorrecta.
  3. Próximas prioridades: estos problemas deben corregirse, aunque no son urgentes en el ámbito empresarial o del usuario. Este tipo de errores pueden añadirse a la lista de tareas pendientes.
    Ejemplo de error:
    erratas en el texto o fallos de traducción.

Plantea preguntas para resolver dudas

Al hablar con las diferentes personas implicadas en el proceso de desarrollo de la aplicación, es probable que recibas diferentes opiniones sobre la gravedad del error detectado y en qué categoría debe incluirse. Con el fin de evitar debates inacabables, el equipo puede plantear las siguientes preguntas para facilitar el proceso de toma de decisiones.

  1. ¿Cuántos usuarios se ven afectados por el error?
  2. ¿Estamos perdiendo actividad en la aplicación?
  3. ¿La empresa está perdiendo la confianza de los usuarios?
  4. ¿Este error plantea un problema legal?
  5. ¿Estamos perdiendo dinero debido a este error?
  6. ¿El problema puede reproducirse en los dispositivos y versiones de los sistemas operativos compatibles?
  7. ¿Qué secciones se han visto afectadas?
  8. ¿Podemos desactivar la característica desde el backend?

Una vez que el equipo decida que merece la pena publicar una revisión, debe emplearse el enfoque de desarrollo de software existente. Hay que detectar la causa del problema, corregirla y llevar a cabo varias comprobaciones automatizadas. Una vez que haya finalizado el proceso de desarrollo, un probador de software o evaluador de versiones beta debe comprobar que el error se ha corregido. Asimismo, es necesario realizar pruebas de regresión para comprobar que la corrección no ha generado problemas adicionales. Por último, pero no menos importante, es necesario ejecutar el conjunto de pruebas automatizado y que todos los resultados sean correctos.

Cómo encontrar un flujo de trabajo para el equipo

En resumen, la matriz de errores para dispositivos móviles es una estrategia para decidir si es necesario corregir un error de forma inmediata o hacerlo más tarde. Cada equipo debe definir un flujo de trabajo para gestionar los errores graves o leves en el sistema de producción. Asimismo, es importante alcanzar un equilibrio entre una revisión y la publicación de la próxima revisión, ya que corregir un error en un entorno móvil no suele ser un proceso rápido ni barato. Además de los costes asociados al desarrollo y a las pruebas, hay periodos de espera para la revisión y envío de la aplicación en algunas plataformas hasta que esta se encuentra disponible para los clientes, algo que puede resultar bastante inconveniente si la siguiente publicación de la aplicación va a llevarse a cabo en breve.

Applause Circle Logo