Calidad y pruebas de las métricas publicitarias en dispositivos móviles

Por Maya Reddy | Ingeniera en software, Ad Formats (Formatos de anuncios)

En Pinterest, todos los días ayudamos a nuestros socios de publicidad a llegar a los usuarios a través de diferentes formatos de anuncios y les ofrecemos métricas y análisis sobre el rendimiento de sus anuncios. Mantener la confianza de nuestros socios y ofrecerles valor es fundamental, por lo que las métricas que mostramos, que en última instancia se basan en registros que contienen eventos de cliente, deben ser correctas.

A principios de 2017, hacíamos lanzamientos móviles cada dos semanas y realizábamos un control de calidad manual para verificar el comportamiento de registro antes de cada lanzamiento. Al poco tiempo, los equipos de cliente comenzaron a invertir en marcos de pruebas; en este contexto, las pruebas de integración son pruebas automatizadas que pasan por el flujo de la interfaz de usuario, que van desde iniciar sesión en la aplicación hasta realizar comportamientos como tocar Pines, guardar Pines, etc. Al final de las acciones automatizadas, las pruebas verifican que los registros coincidan con las acciones de la interfaz de usuario.

Por qué creamos el conjunto de pruebas de integración de registro de anuncios

Detectar y corregir errores antes en el ciclo de lanzamiento. Anteriormente, como dependíamos del control de calidad manual, el equipo quizá no detectaba errores hasta las últimas etapas del ciclo de lanzamiento, y a menudo debíamos solucionar errores P1 poco antes de la fecha límite de envío.

Enviar el código con confianza. Las pruebas automatizadas nos permiten ejecutar más casos de prueba y tener aún más confianza en que el nuevo código no introdujo errores ni problemas.

Redistribuir las pruebas manuales. Al cambiar las tareas repetidas de control de calidad por pruebas de integración, el control de calidad manual puede hacer más pruebas exploratorias y pruebas de nuevas funciones.

Desafíos

Cómo asegurarnos de que hacemos pruebas del formato correcto

Necesitamos una forma de garantizar que un anuncio determinado aparecerá en el feed de un usuario para poder ejecutar pruebas con el formato de anuncio deseado. En el siguiente ejemplo, necesitamos que se muestre un anuncio de instalaciones de aplicación.

Caso de prueba de ejemplo:

1. Desplazarse por el feed y ver un Pin de instalaciones de aplicación en su totalidad.

2. Confirmar que se activa una impresión. Verificar que se proporciona el ID y que parece un ID compuesto válido.

Usamos una herramienta útil que inserta Pines promocionados en el nivel de la API en función de datos de JSON. Tenemos muchas cuentas de prueba diferentes, cada una con un Pin específico insertado en esa cuenta. De esta manera, nuestras pruebas automatizadas pueden iniciar sesión en la cuenta que se necesite para la prueba de ese formato específico.

Cómo estructuramos las pruebas

Nuestros anuncios aparecen en muchos lugares de la aplicación de Pinterest. Pueden aparecer en el feed de inicio, cuando un usuario hace una búsqueda, etc. A veces, un error puede afectar solo una superficie, por lo que necesitamos hacer pruebas en todas las superficies. Esto aumenta la cantidad de pruebas, pero facilita la división lógica. Disponemos de un método base que realiza todas las acciones de la interfaz de usuario y verificaciones de registro, y tenemos un método de prueba para cada superficie que navega a la superficie antes de acudir al método base.

A continuación, se muestra una prueba que se está ejecutando en el feed de inicio, la búsqueda y el feed de Pines relacionados. La prueba consiste en verificar que las impresiones terminan correctamente cuando aparece el menú contextual.

Replicación de pruebas

A medida que los anuncios se lanzan en nuevas superficies, debemos certificar que el registro y el comportamiento de los anuncios funcionan como se esperaba. Por ejemplo, en el tablero de un usuario, hay una sección llamada “Más ideas” donde ahora pueden aparecer anuncios, y queremos poder replicar fácilmente las pruebas existentes para ejecutarlas en esta nueva superficie. Lo ideal es que los equipos que cuentan con superficies también tengan un subconjunto de pruebas, desde la creación hasta el mantenimiento de las pruebas. Como la mayoría de las pruebas tienen una estructura consistente, creamos un script de Python que genera pruebas para nuevas superficies copiando y modificando las pruebas existentes.

Integración continua

A medida que fuimos agregando más formatos y su cobertura de pruebas asociada, el conjunto de pruebas se hizo cada vez más grande. Nuestra capacidad disponible en las instalaciones restringía la frecuencia con la que podíamos ejecutar el conjunto de pruebas completo. Después de algunas iteraciones, nuestro proceso actual consiste en ejecutar el conjunto de pruebas todas las noches cuando hay más capacidad disponible. Sin embargo, también seleccionamos un pequeño subconjunto de pruebas para ejecutarlas por confirmación a fin de detectar los errores de manera temprana. Siempre nos aseguramos de pasar el conjunto de pruebas completo en la versión candidata para lanzamiento antes de enviar la compilación a App Store/Play Store. Usamos la siguiente configuración para nuestro entorno de integración:

● Buildkite: configuramos canalizaciones en Buildkite para que las pruebas de integración se ejecuten en máquinas remotas.

● Las pruebas terminan más rápido, ya que se ejecutan en paralelo.

● Los desarrolladores pueden trabajar con otras funciones mientras se ejecutan las pruebas.

● Podemos programar las compilaciones para que las pruebas se ejecuten todas las noches o configurar integraciones para que las pruebas se ejecuten por confirmación.

● Metro: herramienta interna que se usa para analizar los resultados y las tendencias de las pruebas. Podemos ver la tasa de éxito a lo largo del tiempo para una canalización específica, así como para pruebas individuales.

Cómo mantenemos las pruebas

Una vez que se escribe el código de una prueba, este se agrega a la canalización provisional de Buildkite. La prueba nueva se ejecuta durante unos días, y solucionamos los problemas que surjan. Una vez que es estable, la agregamos a la canalización de producción de Buildkite. Además del costo inicial de escribir el código de las pruebas, se requiere trabajo para mantenerlas.

● A veces, al modificar una función, se rompen las pruebas de integración. Por ejemplo un botón Atrás podría convertirse en un botón Cerrar. Como dependemos de las etiquetas de accesibilidad, nuestras pruebas se romperían. En este caso, le enviaríamos un informe de error al equipo correspondiente para que solucione el problema.

● Otras veces, hay problemas con la forma en que escribimos las pruebas que se hacen evidentes con el tiempo. En esos casos, actualizamos el marco o la configuración de la prueba.

Conclusión

Las pruebas de integración automatizadas nos permiten confiar en las métricas que informamos a nuestros anunciantes. Desarrollamos continuamente el proceso para que nuestras pruebas sean más fáciles de ejecutar y mantener.

Agradecimientos: Quiero agradecer a Wendy Lu, Matt Mo, Joseph Smalls-Mantey, Jordan Maler, Tony Lu, Jerry Marino, Freddy Montano, al equipo de Ad Formats iOS (Formatos de anuncios para iOS), al equipo de Metrics Quality & Test Tools (Calidad de las métricas y herramientas de pruebas), al equipo de iOS Core Platform (Plataforma principal de iOS) y a todos aquellos que ayudaron en esta iniciativa.

Estamos construyendo el primer motor de descubrimiento visual del mundo. Más de 475 millones de personas de todo el mundo usan Pinterest para soñar, planear y preparar lo que quieren hacer en la vida. ¡Únete a nuestro equipo!


Calidad y pruebas de las métricas publicitarias en dispositivos móviles was originally published in Pinterest Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source: Pinterest

Leave a Reply

Your email address will not be published.


*