Testing: pruebas a un teléfono
Por Antonio Montañez, Jefe de proyectos – Sénior
En los últimos meses hemos estado trabajando en uno de los proyectos más diferentes y peculiares que han pasado por mis manos desde que me dedico la traducción. Uno de esos trabajos que suponen un reto porque no se parecen a nada de lo que has hecho hasta el momento y que, por lo tanto, nunca tienes muy claro cómo afrontar.
¿EN QUÉ CONSISTÍA EL PROYECTO?
A través de uno de nuestros clientes recibimos una petición para encargarnos del testing de la función de escucha activa de uno de los últimos modelos de móvil que una conocida compañía, a la que no citaremos para mantener el anonimato, ha comercializado en España.
Esta función se aprovecha de un chip dedicado con el que cuenta el teléfono para que siempre permanezca a la escucha, aunque esté bloqueado o en standby, de forma que si decimos una frase de activación (o trigger) y, a continuación, los comandos de voz adecuados podremos llamar, hacer búsquedas en Google y recibir una respuesta hablada o simplemente pedirle que nos diga si tenemos notificaciones y nos las lea. Todo esto aunque el teléfono se encuentre en reposo en otra parte de la habitación.
Esta función además cuenta con el añadido de que, una vez configurado, únicamente responde ante la voz del usuario.
El testing que debíamos realizar se componía de tres fases bien diferenciadas, de las cuales la tercera era la más complicada y también la que abarcaba el 90 % de la tarea en sí.
Fase 1: Grabación de sonidos ambientales
Primero, cuatro personas (dos hombres y dos mujeres) debían llevar encima el dispositivo durante unas 52 horas con una aplicación de grabación funcionando de forma ininterrumpida para recoger los sonidos ambientales de distintos entornos a los que normalmente estaría expuesto el teléfono en nuestra vida cotidiana (excepto en las horas de sueño): clases, trabajo, supermercado, parque, etc. Todos aquellos entornos en los que no estuviera prohibido grabar, claro. Una vez recopilados estos sonidos se enviarían al equipo de desarrolladores.
Fase 2: Grabación de comandos
A continuación, otras cuatro personas (también dos hombres y dos mujeres) debían leer y grabar aproximadamente 300 comandos de voz cada uno y enviarlos para su análisis.
Fase 3: Testing en distintos entornos del funcionamiento de los comandos
Por fin llegamos a la fase 3, en ella 20 personas (10 hombres y 10 mujeres) debían probar el reconocimiento de voz del teléfono en distintos entornos:
● un entorno silencioso (como un despacho de oficina),
● un salón de estar (con TV o radio de fondo),
● una cafetería (con ruido ambiente),
● y un coche (tanto en ralentí como en marcha y con el teléfono en varias ubicaciones: en el soporte para móviles, en el portabebidas, etc.).
Este ciclo de pruebas se repetiría varias veces a lo largo de los meses.
Como hemos dicho antes, para hacer uso de esta función, cada persona debía enseñar al teléfono a que reconociera su voz, repitiendo unas frases tres veces en un entorno muy silencioso. Esto, que un usuario normal solo debería hacerlo una vez en la vida, era necesario hacerlo con cada participante en el testing. Una vez configurado, con el teléfono en standby, había que decir la frase de activación y después el comando, del tipo:
ok Google (frase de activación) + ¿qué novedades tenemos? (comando)
ok Google + ¿cuánto mide la Torre Eiffel?
ok Google + llamar a Pablo Martín
En un principio se probaron 4 comandos (en ciclos sucesivos serían 6). Cada persona debía repetirlos por lo menos 10 veces seguidas en cada uno de los entornos y registrar en unos documentos de Excel dos tipos de datos para cada uno de ellos:
● si el teléfono había reaccionado correctamente a la frase de activación en cada una de las ocasiones
● y si respondía adecuadamente al comando en sí (o bien entendía otra cosa y no reaccionaba como se esperaba de él).
Cada vez que un participante terminaba la prueba en un entorno, se enviaba un informe a través de una aplicación que recopilaba información como el sonido grabado y otros parámetros relevantes para los desarrolladores.
¿POR QUÉ SUPUSO UN DESAFÍO?
Organizar una prueba de estas características, en la que participan al menos 20 personas, se cuenta con un plazo ajustado de tres o cuatro días y cualquier fallo técnico o error sobre la marcha supone pérdida de datos o de un tiempo (ese tiempo que nunca te sobra) no es tarea sencilla.
Preparación del material y de los entornos
Tras preparar el material, es decir, instalar en los teléfonos la última versión de software y de la aplicación, aprender el uso del sonómetro para medir los decibelios y otras cuestiones técnicas, llega la hora de pensar en los entornos y en cómo se iban a recrear.
Para el entorno silencioso podría utilizarse la sala de reuniones de la empresa pero… ¿y el salón de estar? La misma sala con una televisión, una mesita y un sofá sería suficiente. En cuanto a la cafetería era importante buscar una que se encontrara cerca y que estuviera lo suficientemente transitada para ahorrar tiempo y gasolina en los desplazamientos y también para que el nivel de ruido fuera el idóneo. ¡Ah! Y a ser posible con Wi-Fi para ahorrar en consumo de datos, ya que el uso que se iba a hacer de ellos era intensivo. Casi todos los comandos requerían búsquedas o consultas en Internet.
Búsqueda y planificación de recursos
Si tenemos en cuenta que nuestra oficina se encuentra en un remanso de tranquilidad apartado del mundanal ruido, no es fácil encontrar a voluntarios que estén dispuestos a desplazarse hasta allí por un módico precio. Por otra parte, en el caso de los miembros del equipo interno que iban a participar en el testing, tampoco fue fácil alejarlos de la pantalla del ordenador durante la hora y pico que duraba la prueba.
Una vez confeccionada la lista de participantes en función de la disponibilidad de cada uno, elaboramos un calendario a lo largo de la semana y se fijaron citas con 5 personas cada día.
Solución de problemas inesperados
Una vez listo el material, acordadas las citas, planificada la ruta en coche y elegida la cafetería, pusimos la maquinaria en marcha y echamos a rodar el testing. Pero ya se sabe que las cosas nunca son tan fáciles como parecen y no es que todo lo que pueda salir mal, saldrá mal, por citar a Murphy, pero sí que nos encontramos con más de un problema imprevisto sobre la marcha.
● Eco: al acondicionar la sala de juntas a modo de sala de estar, tuvimos ciertos problemas porque el teléfono no reconocía los comandos de voz con el televisor encendido. Este tipo de errores de reconocimiento eran de esperar en este entorno pero la tasa de fallos era cercana al 100 %. La raíz del problema era que no había cortinas, ni alfombras ni otro tipo de objetos normalmente presentes en un salón de casa que amortiguaran el sonido. Como el eco era mayor de lo esperado tuvimos que reacondicionar la sala.
● Cuelgues de la aplicación: en algunas de las compilaciones que probamos la aplicación devolvía un error desconocido y dejaba de responder, o bien de repente no reconocía la tarjeta SIM. Esto nos obligaba a tener que reiniciar el teléfono y volver a empezar la prueba en marcha.
● Consumo de datos: en ocasiones la aplicación no podía acceder a Google en ese momento, aún cuando el teléfono estaba al máximo de cobertura. Nos llevó un tiempo darnos cuenta de que el problema era que se había agotado la tarifa de datos porque los informes que se enviaban después de cada prueba ocupaban entre 30 y 60 Mb, y al tener que enviar 4 por persona los datos se consumieron rápidamente. ¿La solución? Guardar cada informe como borrador y enviarlo vía Wi-Fi.
● Nivel de ruido y entrenamiento del teléfono: por exigencias del guión, a veces era necesario entrenar al teléfono en la cafetería. El nivel de ruido ambiente para esta configuración inicial debía ser muy bajo y a veces ni siquiera en los servicios el nivel de ruido se reducía lo suficiente como para que el teléfono captara el tono de voz propio de cada persona. Por suerte, el aislamiento dentro de un coche es considerablemente mejor y proporcionaban ese ambiente silencioso necesario
IMPRESIONES FINALES
Como comentaba al principio, afrontar un proyecto de estas características puede suponer un quebradero de cabeza al principio pero es sin duda una experiencia satisfactoria. Siempre lo es trabajar en algo radicalmente nuevo. Y conocer de primera mano cómo se testean este tipo de aplicaciones es sin duda interesante si te gustan las nuevas tecnologías como a mí. Además de que te permite alejarte de esa pantalla de ordenador delante de la que pasamos tantas horas trabajando. Incluso esos problemas inesperados son como pequeños desafíos que hacen que te sientas mejor una vez superados.
La alegría es aún mayor cuando el cliente te felicita porque ha quedado muy contento con los resultados del testing.
Por cierto, se va acercando una nueva ronda de testing… ¡Se buscan voluntarios!
1 respuesta a "Testing: pruebas a un teléfono"
camilo veas dice:
31 agosto 2014
Hola me gustaria prticipar como voluntario y me encantaría trabajar en esto saludos