Tipos de pruebas

En /e/OS tenemos tres tipos de pruebas:

  • pruebas de sprint
  • pruebas de actualización
  • pruebas de portado o de aplicaciones

Pruebas de sprint: son las pruebas regulares de nuestras compilaciones, para todos los dispositivos de la lista de compatibles. Seguimos el modelo de desarrollo ágil, con sprints regulares: 2 semanas de desarrollo y 1 semana de pruebas (más información).

Pruebas de actualización: cuando hay que actualizar el sistema operativo de un dispositivo (por ejemplo, de la versión Nougat a la Oreo o Pie de /e/OS), hacemos pruebas de actualización. Anunciamos qué dispositivos se van a actualizar en esta categoría de nuestro foro. Durante las pruebas creamos un equipo de pruebas formado por usuarios voluntarios, que se disuelve cuando las compilaciones se publican.

Pruebas de portado o de aplicaciones: de vez en cuando portamos /e/OS a dispositivos que otras ROM personalizadas no soportan, sean smartphones o tabletas. Por ejemplo, portamos /e/OS al FP3. El easy-installer fue una aplicación que creamos y que requirió pruebas detalladas durante su desarrollo.

Durante las pruebas creamos un equipo de usuarios voluntarios que se disuelve cuando las compilaciones se publican.

Qué se espera de un probador

Como probador, tendrás que:

  • flashear la compilación de prueba en tu dispositivo;
  • la primera vez será un flasheo manual; las siguientes compilaciones deberían llegar por OTA;
  • ten en cuenta que flashear el dispositivo borrará los datos existentes: haz una copia de seguridad antes de continuar;
  • solo deben unirse quienes tengan experiencia flasheando ROM;
  • las pruebas solo se hacen con dispositivos de la lista de compatibles.

Si tu dispositivo no está en la lista de compatibles, puedes solicitar que se añada. En ese caso, no deberías unirte al equipo de pruebas.

¿Puedo dejar el equipo de pruebas?

Sí. La participación como probador es voluntaria: puedes dejar el equipo cuando quieras.

  • Ten en cuenta que, para volver a las compilaciones oficiales normales, tendrás que flashearlas manualmente en tu dispositivo, porque las compilaciones de prueba y las oficiales o de desarrollo se firman con claves distintas.

¿Cómo me uno a la comunidad de pruebas?

Cómo activar el canal de pruebas OTA

  • Activa el modo de desarrollador: Ajustes > Acerca del teléfono > toca 7 veces Número de compilación.
  • Activa el canal de pruebas de /e/OS: Ajustes > Sistema > Opciones de desarrollador > activa Connect to /e/OS test channel. El interruptor se pondrá verde.
  • Busca actualizaciones: Ajustes > Actualizaciones > actualiza con la flecha de la esquina superior derecha si hace falta.
  • Descarga e instala la última actualización.

Cómo desactivar el canal de pruebas OTA

  • Accede a las opciones de desarrollador: Ajustes > Sistema > Opciones de desarrollador (activadas antes).
  • Desactiva el canal de pruebas de /e/OS: en Opciones de desarrollador, desplázate hasta Connect to / test channel y desactívalo.
  • El interruptor activado es verde; desactivado, gris.

Sesiones de pruebas con Kiwi

Desde la e Foundation ofrecemos un sistema operativo para una enorme cantidad de dispositivos, y lamentablemente no podemos comprobar y evaluar cada versión de /e/OS en todos los dispositivos compatibles con el proyecto. En primer lugar, el equipo se centra en los dispositivos oficiales; después, el equipo y la comunidad de pruebas también pueden probar sus propios dispositivos con la última versión. Para centralizar las sesiones de pruebas y sus informes usamos una herramienta llamada «Kiwi».

Kiwi es una herramienta de código abierto con interfaz web para gestionar tus pruebas: la mejor amiga de los equipos de QA, porque incorpora buenas prácticas por diseño. Te lleva a crear un plan de pruebas para tus productos con un conjunto de casos de prueba. En cada nueva versión puedes asignar fácilmente ejecuciones de pruebas a los miembros del equipo y a la comunidad.

Añadimos a cada caso de prueba metadatos como la aplicación y la información de hardware (Ajustes, Notas, GPS, Wifi…). Eso ayuda a hacerse una idea de lo que hará la prueba, y pensamos usar esas etiquetas en el futuro para generar un informe completo por dispositivo. Compartir esta información con la comunidad será muy útil antes de proceder a la instalación: el usuario podrá ver qué funciona y qué no en un dispositivo concreto.

Kiwi además es extensible: podemos conectar nuestro rastreador de errores para abrir directamente una incidencia en el backlog cuando se detecta un error. Personalizamos la descripción de las incidencias para facilitar su resolución, con el sistema de plugins de Kiwi.

FAQ del proceso de pruebas

  • ¿Qué pasa si una compilación falla o se detectan errores durante mis pruebas?

Si una compilación falla en el proceso de pruebas, retenemos su publicación y vuelve a los desarrolladores. Igualmente, si se informa de un error, revertimos la corrección a la versión anterior que funcionaba y el error vuelve al desarrollador para que lo resuelva.

  • ¿Cómo gestionáis esas reversiones en un desarrollo ágil?

Como recordarás, tenemos ciclos de desarrollo de 2 semanas por sprint. Los errores detectados en las pruebas pasan al siguiente ciclo de sprint, y solo las correcciones que funcionan entran en la compilación.

  • ¿Solo se corrigen errores en estos sprints? ¿Y las mejoras?

Buena pregunta: combinamos mejoras y correcciones de errores en los sprints. Si el código de una mejora no se termina en el plazo dado, pasa al siguiente ciclo.

  • No tengo experiencia flasheando ROM y mi dispositivo no está en la lista de compatibles, ¿puedo unirme al equipo de pruebas?

Agradecemos tu entusiasmo, pero por favor no te unas al equipo en ese caso. Como dijimos, el equipo trabaja con un calendario estricto: no es posible acompañar a un usuario para enseñarle a flashear una ROM. Para ese nivel de ayuda, ve a nuestro foro.