Las pruebas de regresión son una parte muy importante de trabajar en la calidad del producto. Y cuantos más productos y más rápido se desarrollen, más esfuerzo requiere.

Yandex aprendió a escalar las tareas de pruebas manuales para la mayoría de los productos que utilizan evaluadores: empleados remotos que trabajan a tiempo parcial por partes, y ahora cientos de asesores participan en las pruebas de productos Yandex, además de los evaluadores regulares.

Esta publicación dice:

• ¿Cómo se las arregló para hacer las tareas de prueba manual tan formalizadas como sea posible y capacitar a cientos de empleados remotos con ellas?
• ¿Cómo se las arregló para poner el proceso en rieles industriales, proporcionar pruebas en diversos entornos, soportar SLA en velocidad y calidad;
• Qué dificultades encontraron y cómo se resolvieron (y algunas aún no se han decidido);
• ¿Qué contribución hicieron las pruebas de los asesores en el desarrollo de productos Yandex? ¿Cómo afectó la frecuencia de los lanzamientos y la cantidad de errores pasados?

El texto se basa en la transcripción del informe de Olga Megorskaya de nuestra conferencia Piter de mayo de Heisenbug 2018:



Desde el día del informe, algunos números lograron cambiar, en tales casos indicamos los datos reales entre paréntesis. La siguiente es una perspectiva en primera persona:

Hoy hablaremos sobre el uso de técnicas de crowdsourcing para ampliar las tareas de pruebas manuales.

Tengo un título de trabajo bastante extraño: jefe del departamento de evaluaciones de expertos. Trataré de decir con ejemplos lo que hago. En Yandex, tengo dos vectores principales de responsabilidad:



Por un lado, todo esto está relacionado con el crowdsourcing. Soy responsable de nuestra plataforma de crowdsourcing Yandex.Tolok.

Y por otro lado, los equipos que, si intenta dar una definición universal, pueden atribuirse a "vacantes masivas no productivas". Incluye muchas cosas diferentes, incluido uno de nuestros proyectos recientes: pruebas manuales con la ayuda de multitudes, a las que llamamos "pruebas de asesores".

Mi actividad principal en Yandex es reunir las columnas izquierda y derecha de la imagen e intentar optimizar las tareas y los procesos en la producción en masa utilizando crowdsourcing. Y hoy hablaremos de ello utilizando el ejemplo de las tareas de prueba.

¿Qué es el crowdsourcing?

Comencemos con lo que es el crowdsourcing. Podemos decir que esto es un reemplazo de la experiencia de un especialista en particular con la llamada "sabiduría de la multitud" en aquellos casos en los que la experiencia de un especialista es muy costosa o difícil de escalar.

El crowdsourcing se ha utilizado activamente en varios campos durante muchos años. Por ejemplo, a la NASA le gustan mucho los proyectos de crowdsourcing. Allí, con la ayuda de la "multitud", exploran y descubren nuevos objetos en la galaxia. Esto parece una tarea muy difícil, pero con la ayuda del crowdsourcing se reduce a una tarea bastante simple. Hay un sitio especial en el que se publican cientos de miles de fotos tomadas con telescopios espaciales, y le preguntan a cualquiera que quiera buscar ciertos objetos allí. Y cuando muchas personas encuentran sospechosamente similar al objeto que necesitan, los especialistas de nivel superior ya están conectados y comienzan a explorarlo.

En términos generales, el crowdsourcing es un método de este tipo, cuando tomamos una tarea grande de alto nivel y la dividimos en muchas subtareas simples y homogéneas, en las que se reúnen muchos artistas independientes. Cada uno de los artistas puede resolver una o varias de estas pequeñas tareas y, en conjunto, trabajan en última instancia por una gran causa común y obtienen excelentes resultados para una tarea de alto nivel.

Yandex crowdsourcing

Ya hemos comenzado varios años para desarrollar nuestro sistema de crowdsourcing. Inicialmente, se usaba para tareas relacionadas con el aprendizaje automático: para recopilar datos de entrenamiento, para configurar redes neuronales, algoritmos de búsqueda, etc.



¿Cómo funciona nuestro ecosistema de crowdsourcing? En primer lugar, tenemos Yandex.Toloka . Esta es una plataforma abierta de crowdsourcing en la que cualquiera puede registrarse como cliente (publicar sus tareas, establecer un precio para ellos y recopilar datos) o como un ejecutor (encontrar tareas interesantes, completarlas y recibir una pequeña recompensa). Lanzamos el techo hace unos años. Ahora tenemos más de un millón de artistas registrados (los llamamos tokers), y cada día en el sistema alrededor de 17,000 personas completan tareas.

Desde que creamos inicialmente el Toloka con la vista puesta en las tareas relacionadas con el aprendizaje automático, tradicionalmente se ha acostumbrado que la mayoría de las tareas que realizan los tolokers son tareas que son muy simples y triviales para una persona, pero aún bastante difíciles para el algoritmo. Por ejemplo, mire una foto y diga si tiene contenido para adultos o no, o escuche una grabación de audio y descifre lo que escuchó.

Toloka es una herramienta muy poderosa en términos de rendimiento y la cantidad de datos que ayuda a recopilar, pero no es trivial de usar. Las personas en la imagen llevan pasamontañas amarillo porque todos los artistas en Tolok son anónimos y desconocidos para los clientes. Y administrar estos miles de anonimato, asegurarse de que hagan exactamente lo que necesita no es una tarea fácil. Por lo tanto, no todas las tareas que tenemos, hasta ahora somos capaces de resolver con la ayuda de esta multitud absolutamente "salvaje". Aunque nos esforzamos por esto, diré más sobre esto más adelante.

Por lo tanto, para tareas de nivel superior, tenemos el siguiente nivel de artistas. Estas son las personas que llamamos asesores. La misma palabra "asesores" puede ser un poco extraña. Proviene de la palabra "evaluación", es decir, "evaluación", porque inicialmente los evaluadores se utilizaron con nosotros para recopilar evaluaciones subjetivas de la calidad de los resultados de búsqueda. Estos datos se utilizaron como objetivo para el aprendizaje automático de la función de clasificación de búsqueda. Desde entonces, ha pasado mucho tiempo, los asesores comenzaron a realizar muchas otras tareas diferentes, por lo que ahora esta es una palabra común: las tareas han cambiado, pero la palabra permanece.

De hecho, nuestros asesores son empleados a tiempo completo de Yandex, pero trabajan a tiempo parcial y de forma totalmente remota. Estos son tipos que trabajan en su propio equipo. Solo interactuamos con ellos de forma remota: los seleccionamos de forma remota, los entrenamos de forma remota, trabajamos de forma remota con ellos y, si es necesario, los disparamos de forma remota. Con la mayoría de ellos, nunca nos cruzamos en persona en la vida. Trabajan de acuerdo con cualquier horario conveniente para ellos, de día o de noche: tienen estándares mínimos equivalentes a aproximadamente 10-15 horas a la semana, y pueden hacer ejercicio esta vez de la manera que más les convenga. Los evaluadores resuelven una variedad de problemas: están conectados con la búsqueda, y con el soporte técnico, y con algunas traducciones de bajo nivel y con las pruebas, de las que hablaremos más adelante.

Como regla general, no importa qué tarea tomemos, las personas más talentosas siempre se destacan del grupo de asesores que lo realizan mejor, para quienes esta tarea es más interesante. Los destacamos, les otorgamos el fuerte título de superparlantes, y estos muchachos ya están desempeñando funciones de curadores de alto nivel: verifican la calidad del trabajo de otras personas, los consultan, los apoyan, etc.

Y solo en la parte superior de nuestra pirámide tenemos el primer empleado de tiempo completo que se sienta en la oficina y administra estos procesos. Tenemos muchas menos personas que ya están en un nivel mucho más alto y tienen fuertes habilidades técnicas y de gestión, literalmente pocas. Tal sistema nos permite llegar a la conclusión de que estas unidades de personas de "alto nivel" construyen tuberías y gestionan cadenas de producción, en las que decenas, cientos e incluso miles de personas están más involucradas.

Por sí solo, este esquema no es nuevo, pero Genghis Khan lo aplicó con éxito. Ella tiene varias propiedades interesantes que estamos tratando de usar. La primera propiedad es bastante comprensible: este esquema es muy fácil de escalar. Si una tarea necesita comenzar repentinamente a hacer más, entonces no necesitamos buscar espacio adicional en la oficina para plantar a una persona en algún lugar. En general, podemos pensar muy poco acerca de qué: solo invierta más dinero, contrate más artistas por este dinero, y los tipos más talentosos con límites académicos probablemente crecerán de estos artistas, y todo este sistema continuará escalando.
La segunda propiedad (y fue sorprendente para mí) es que una pirámide de este tipo está muy bien replicada, independientemente del área temática en la que se aplique. Esto también se aplica al área de la que vamos a hablar hoy: tareas de prueba manual.

Prueba de multitudes

Cuando comenzamos el proceso de prueba con la ayuda de multitudes, el mayor problema fue la falta de una referencia positiva. No había experiencia a la que pudiéramos referirnos y decir: "Bueno, estos muchachos hicieron esto, ya están probando con la ayuda de multitudes en un circuito muy similar a nosotros, y todo está bien allí, lo que significa que todo estará bien con nosotros". Por lo tanto, teníamos que confiar solo en nuestra experiencia personal, que estaba separada del área temática de las pruebas y más relacionada con la configuración de procesos de producción similares, pero en otras áreas.

Por lo tanto, tuvimos que hacer lo que podamos. Que podemos hacer En esencia, descomponer una tarea en tareas de diferentes niveles de dificultad y dispersarlas por los pisos de nuestra pirámide. Veamos que tenemos.

Primero, observamos las tareas con las que nuestros evaluadores en Yandex están ocupados y les pedimos que dispersen condicionalmente estas tareas en diferentes niveles de dificultad. Este es un "promedio hospitalario":



Estimaron que solo el 57% de su tiempo se gasta en tareas complejas de alto nivel, y en algún lugar alrededor del 20% se gasta en una rutina de muy bajo nivel del que todos quieren deshacerse, y en tareas un poco más complicadas, que también parecen delegarse. Animados por estas cifras, que muestran que casi la mitad del trabajo puede transferirse a algún lugar, procedimos a realizar pruebas con multitudes.

¿Cuáles son nuestros objetivos?

• Haga que las pruebas dejen de ser el cuello de botella que aparece periódicamente en los procesos de producción cuando el lanzamiento está listo, pero espera a que pasen las pruebas.
• Alivie a nuestros geniales, muy inteligentes, especialistas de alto nivel (probadores de tiempo completo) de la rutina, ocupándolos con tareas realmente interesantes y de alto nivel.
• Mejore la variedad de entornos en los que probamos los productos.
• Aprendiendo a manejar cargas máximas porque nuestros evaluadores dijeron que a menudo tienen cargas desiguales. Incluso si, en promedio, un equipo hace frente a las tareas, cuando se produce un pico, entonces lleva mucho tiempo rastrillarlo.
• Dado que en Yandex todavía gastamos bastante dinero en pruebas de outsourcing en algunos proyectos, pensamos que nos gustaría obtener un poco más de resultados y optimizar nuestros gastos de outsourcing para el dinero que gastamos.

Quiero enfatizar que entre estos objetivos no hay tarea de reemplazar a los evaluadores con multitudes, de alguna manera infringirlos, y así sucesivamente. Todo lo que queríamos hacer era ayudar a los equipos de prueba, eliminando la rutina de bajo nivel.

Veamos con qué terminamos. Diré enseguida que las tareas principales de las pruebas ahora se realizan no por el nivel más bajo de la "pirámide", por los títeres, sino por los asesores, nuestros empleados a tiempo completo. Además, discutiremos principalmente sobre ellos, excepto por el final.

Los evaluadores ahora están realizando las tareas de prueba de regresión para nosotros y están haciendo todo tipo de encuestas como "mira esta aplicación y deja tu opinión". Alrededor de 300 personas ahora están calificadas para la tarea de recurso completo ( nota: desde que el informe se convirtió en 500 ). Pero esta cifra es condicional, porque el sistema que hemos construido funciona para un número arbitrario de personas: todo lo que necesitamos. Ahora nuestras necesidades de producción están cubiertas por aproximadamente tantas personas. Esto no significa que en todo momento estén todos listos y listos para llevar a cabo la tarea: dado que los asesores trabajan en un horario flexible, en cualquier momento, 100-150 personas están listas para conectarse. Pero el grupo de artistas es casi el mismo. Y tareas simples, como encuestas, cuando solo necesita recopilar comentarios informales de los usuarios, pasamos por muchas más personas: cientos y miles de asesores participan en tales encuestas.

Como se trata de personas que trabajan en su propio equipo, cada asesor tiene sus propios dispositivos personales. Esto, por defecto, es una computadora de escritorio y algún tipo de dispositivo móvil. En consecuencia, probamos nuestros productos en dispositivos personales de asesores. Pero está claro que no tienen todos los dispositivos posibles, por lo que si necesitamos pruebas en un entorno poco común, usamos acceso remoto a través de la granja de dispositivos.

Ahora las pruebas de multitudes ya se utilizan como un proceso de producción estándar para aproximadamente 40 ( aproximadamente: ahora 60 ) servicios y equipos de Yandex: estos son Mail, Disk y Browser (móvil y de escritorio), y Maps, y Search, y muchos, muchos quien Esto es curioso Cuando nos planteamos planes para el final del tercer trimestre en el otoño de 2017, teníamos un objetivo ambicioso: atraer al menos de alguna manera, "incluso por fraude, incluso sobornando", al menos cinco equipos que utilizarían nuestros procesos de prueba con la ayuda de multitudes. Y convencimos mucho a todos, dijimos: "¡No tengas miedo, vamos, pruébalo!" Pero después de unos pocos meses, tuvimos docenas de equipos.

Y ahora estamos resolviendo otro problema: cómo lograr conectar cada vez más equipos nuevos que quieran unirse a estos procesos. Por lo tanto, podemos suponer que ahora esto ya es una práctica estándar en Yandex, que vuela muy bien.

¿Qué hicimos en términos de indicadores de producción? Ahora estamos haciendo unos 3,000 casos de pruebas de regresión por día ( nota: a partir de octubre de 2018, ya hay 7,000 casos ). Las pruebas, dependiendo del tamaño, toman de varias horas a (en el pico) 2 días. La mayoría pasa en unas pocas horas, en un día. La introducción de dicho sistema nos permitió reducir el costo en aproximadamente un 30% en comparación con el período en que utilizamos la subcontratación. Esto permitió a los equipos lanzar mucho más a menudo, en promedio, varias veces, porque los lanzamientos comenzaron a pasar a la velocidad que estaba disponible para el desarrollo, en lugar de la que estaba disponible para las pruebas, cuando a veces se convirtió en un cuello de botella.

Ahora trataré de decir cómo construimos generalmente el proceso de producción, lo que nos permitió llegar a este esquema.

La infraestructura

Comencemos con la infraestructura técnica. Aquellos de ustedes que han visto a Toloka como una plataforma, imaginen cómo es su interfaz: pueden iniciar sesión en el sistema, seleccionar tareas que les interesen y completarlas. Para los empleados internos, tenemos una instancia interna de Toloka, en la cual, entre otras cosas, distribuimos tareas de varios tipos para nuestros asesores.



La imagen muestra cómo se ve esta interfaz. Aquí puede ver las tareas disponibles para el evaluador: aquí hay varias tareas para probar y varias tareas de un tipo diferente, que el evaluador de este ejemplo también sabe cómo realizar. Y entonces la persona llega, ve las tareas disponibles para él en este momento, hace clic en "Continuar", recibe casos de prueba para su análisis y comienza a llevarlos a cabo.

Una parte importante de nuestra infraestructura son las granjas. No todos los dispositivos están disponibles, por lo que la tarea es, de hecho, un par: un caso de prueba y el entorno en el que debe verificarlo. Cuando una persona hace clic en el botón Continuar, el sistema verifica si tiene un entorno en el que realizar la prueba. Si lo hay, entonces la persona simplemente toma la tarea y la prueba en un dispositivo personal. Si no, lo enviamos a través de acceso remoto a la granja.



La imagen muestra cómo se ve, usando el ejemplo de una granja móvil. Entonces, una persona se conecta remotamente a un teléfono móvil que se encuentra en nuestra oficina en la granja. Para Android, utilizamos soluciones de código abierto OpenSTF. No hay buenas soluciones para iOS, en la medida en que ya hemos creado las nuestras (pero hablaremos de esto en detalle la próxima vez), porque no pudimos encontrar código abierto o algo que tuviera sentido comprar. Está claro que la granja es útil en los casos en que no tenemos personas que tengan los dispositivos correctos.Y otra ventaja importante de esto es que la granja tiene una tasa de utilización muy alta: siempre y sin importar qué persona ingrese, podemos enviarla a la granja en cualquier momento. Esto es mejor que repartir dispositivos en persona, porque los dispositivos que se entregan a una persona están disponibles para trabajar solo cuando esa persona está lista para trabajar.

Hablamos un poco sobre cómo se implementó para nuestros asesores desde un punto de vista técnico, y ahora la parte más interesante para mí: los principios de cómo organizamos esta producción.

Los principios de organización de la producción en multitud.

Para mí en este proyecto fue interesante que el área temática parece ser muy específica, pero todos los principios de organización de la producción son bastante universales: los mismos que se usan para organizar la producción en masa en otras áreas temáticas.

1. Formalización

El primer principio (no el más importante, pero uno de los más importantes, una de nuestras "ballenas, elefantes y tortugas") es la formalización de las tareas. Creo que todos ustedes saben esto por su cuenta. Casi cualquier tarea es más fácil de hacer usted mismo. Es un poco más difícil explicarle a tu colega quién está sentado a tu lado en la habitación para que haga exactamente lo que necesitas. Y la tarea es asegurarse de que cientos de artistas que nunca haya visto, que trabajan de forma remota, en cualquier momento arbitrario, hagan exactamente lo que espera de ellos: esta tarea es varios órdenes de magnitud más complicada e implica un umbral bastante alto para ingresar para comenzar a hacer esto en absoluto. En el contexto de las tareas de prueba, la tarea con nosotros, por supuesto, es un caso de prueba que debe pasarse y procesarse.

¿Y qué casos de prueba deberían ser para poder usarlos en una tarea como la prueba de multitudes?

En primer lugar, y resultó que esto no es una cuestión de hecho, los casos de prueba generalmente deberían serlo. Hubo momentos en que los equipos vinieron a nosotros que querían conectarse a las pruebas de los evaluadores y les dijimos: "¡Genial, traigan sus casos de prueba, los revisaremos!" En este momento, el cliente estaba triste, se fue, no siempre regresó. Después de varias apelaciones, nos dimos cuenta de que probablemente necesito ayuda en este lugar. Porque si un probador de un equipo de algún servicio prueba sus servicios regularmente, realmente no necesita casos de prueba completos y bien descritos. Y si queremos delegar esta tarea a un gran número de artistas, simplemente no podemos prescindir de ella.

Pero incluso en aquellos casos en los que hubo casos de prueba, casi siempre eran entendibles solo para aquellas personas que están muy inmersas en el servicio. Y para todas las demás personas que están fuera de contexto, fue muy difícil entender lo que está sucediendo aquí y lo que hay que hacer. Por lo tanto, era importante revisar los casos de prueba para que fueran comprensibles para una persona no inmersa en el contexto.

Y lo último: si reducimos la tarea de prueba a casos específicos estrictamente formales, es muy importante asegurarse de que estos casos se actualicen, actualicen y actualicen constantemente.

Daré algunos ejemplos.



La imagen de arriba, por ejemplo, muestra un buen caso de nuestro servicio nativo de Tolok, en el que debe verificar la corrección del perfil del artista. Todo se descompone en pasos. Hay cada paso a tomar. Hay una expectativa de lo que debería suceder en cada paso. Tal caso será claro para cualquiera.



Y aquí hay un ejemplo de un caso no tan exitoso. En general, no está claro lo que está sucediendo. La descripción parece estar allí, pero en realidad: ¿qué es, qué quieres de mí? Casos de este tipo: no es inmediato, pasan muy mal.

¿Cómo construimos el proceso de formalización de casos de prueba para que, en primer lugar, los tuviéramos a todos, aparecieran constantemente y se reabastecieran, y, en segundo lugar, que fueran lo suficientemente comprensibles para los evaluadores?

A través de prueba y error, llegamos a este esquema:



Nuestro cliente, es decir, algún tipo de servicio o equipo, viene y en una forma arbitrariamente arbitraria conveniente para él, describe los casos de prueba que necesita.

Después de eso viene nuestro asesor inteligente que mira este texto formulado libremente y lo traduce en casos de prueba bien formalizados que están bien formalizados y pintados con pequeños detalles. ¿Por qué es importante que este asesor? Porque él mismo estaba en el lugar de aquellas personas que toman casos de prueba de áreas completamente diferentes, y entiende cuán detallado debe ser el caso de prueba para que los colegas lo entiendan.

Después de eso, corremos en un caso: asignamos tareas a los evaluadores y recopilamos comentarios. El proceso está organizado de modo que si una persona no comprende lo que se requiere de él en un caso de prueba, lo omite. Como regla general, después de la primera vez hay un porcentaje bastante grande de pases. De todos modos, no importa cuán bien formalicemos los casos de prueba en la etapa anterior, nunca es imposible adivinar qué será incomprensible para las personas. Por lo tanto, la primera ejecución es casi siempre una versión de prueba, sus funciones más importantes son recopilar comentarios. Después de que recopilamos los comentarios, recibimos comentarios de los evaluadores, aprendimos lo que entendieron y lo que no, reescribimos, agregamos casos de prueba una vez más. Y después de algunas iteraciones, obtenemos casos de prueba geniales y muy claramente formulados que son entendibles para todos.

Esta limpieza tiene un efecto secundario interesante. En primer lugar, resultó que para tantos equipos esto generalmente es una característica asesina. Todos vienen a nosotros y nos dicen: "¿Realmente puedes escribir casos de prueba para mí?" Esto es lo más importante que atraemos a nuestros clientes. El segundo efecto, inesperado para mí: el orden en los casos de prueba tiene otros efectos pendientes. Por ejemplo, tenemos escritores técnicos que escriben documentación del usuario, y escribir sobre la base de casos de prueba tan bien diseñados y comprensibles es mucho más fácil para ellos. Anteriormente, tenían que distraer el servicio para averiguar qué necesita ser descrito, pero ahora podemos usar nuestros casos de prueba claros y geniales.

Daré un ejemplo.



Así es como se veía el caso de prueba antes de pasar por nuestra picadora de carne: es muy escaso, el campo de descripción no se completa, dice "bueno, mira la captura de pantalla en la aplicación" y eso es todo.



Así es como comenzó a cuidar después de que fue reescrito: pasos y expectativas adicionales en cada paso. Mucho mejor ya. Es mucho más agradable trabajar con un caso de prueba de este tipo.

2. Aprendizaje escalable

La siguiente tarea es mi favorita, la mayoría, me parece, creativa en todo esto. Esta es una tarea de aprendizaje escalable. Para que podamos operar con tales números: "aquí tenemos 200 asesores, aquí hay 1,000 y aquí en general 17,000 tokers trabajan todos los días", es importante poder capacitar a las personas de manera rápida y escalable.


Es muy importante llegar a tal sistema cuando no pasa más tiempo entrenando a un número arbitrario de personas que entrenando a un especialista específico. Esto, por ejemplo, es lo que encontramos al trabajar con outsourcing. Los especialistas son muy geniales, pero para sumergirlos en el contexto del trabajo, el servicio tomó mucho tiempo, y en la salida todavía tenemos una persona que está inmersa en el contexto durante seis meses. Y este es un esquema muy escalable. Resulta que cada persona siguiente necesita estar inmersa en el contexto de la tarea durante otros seis meses. Y fue necesario ampliar este cuello de botella.

Para cualquier vacante masiva, no solo en las pruebas, reclutamos personas a través de varios canales. Para las pruebas, lo hacemos. En primer lugar, atraemos a personas que, en principio, están interesadas en las tareas de evaluación, chicos en algún lugar al nivel de evaluadores junior, para ellos este es un buen comienzo, inmersión en el área temática. Pero todavía hay un número limitado de tales personas en el mercado, y necesitamos que no tengamos restricciones para contratar personas, de modo que nunca descansemos en el número de artistas.

Por lo tanto, además de encontrar probadores específicamente para estas tareas, llevamos a cabo un conjunto de personas que simplemente respondieron a la posición general del asesor. Defendemos este enfoque: no importa qué personas tome, si hay muchas, puede crear un proceso para seleccionar a los más capaces y dirigirlos a resolver el problema que persigue. En el contexto de las pruebas, desarrollamos capacitación para que sea posible que las personas arbitrarias que ni siquiera sabían nada sobre las pruebas enseñen al menos los conceptos básicos mínimos para que puedan comenzar a comprender algo. Gracias a este enfoque, nunca nos encontramos con la falta de artistas y la cantidad de personas que trabajan para nosotros en estas tareas, todo se reduce a la cuestión de cuánto dinero estamos dispuestos a gastar en ello.

No sé con qué frecuencia te encuentras con este tema, pero en todo tipo de artículos de divulgación científica, especialmente sobre aprendizaje automático y redes neuronales, a menudo se escribe que el aprendizaje automático es muy similar al entrenamiento humano. Le mostramos al niño 10 cartas con la imagen de la pelota, y por undécima vez lo entenderá y dirá: “¡Oh! ¡Esto es una pelota! De hecho, la visión por computadora y cualquier otra tecnología de aprendizaje automático también funcionan en esencia.

Quiero hablar sobre la situación opuesta: la formación de personas se puede construir de la misma manera formal que las máquinas de formación. ¿Qué necesitamos para esto? Necesitamos un conjunto de capacitación: un conjunto de ejemplos premarcados en los que se capacitará a una persona. Necesitamos un conjunto de control, en el que podamos verificar si estudió bien o no. Al igual que en el aprendizaje automático, necesita un conjunto de pruebas en el que comprendamos cómo funciona nuestra función en general. Y necesitamos una métrica formal que mida la calidad del trabajo realizado. Es sobre estos principios que hemos construido la capacitación en las tareas de las pruebas de regresión más simples.


La imagen muestra cómo se ve este entrenamiento con nosotros. Se compone de varias partes. Primero, hay una teoría, luego práctica, y luego se realiza un examen, en el cual verificamos si una persona entendió la esencia del problema o no.



Comencemos con la teoría. Está claro que para cualquier tarea que realice el asesor, tenemos una instrucción amplia, importante y completa con una gran cantidad de ejemplos, donde todo se describe con gran detalle. Pero nadie lo lee.

Por lo tanto, para verificar que el conocimiento teórico realmente se establezca en la cabeza de una persona, siempre damos acceso a las instrucciones, pero después de eso usamos lo que condicionalmente llamamos una "prueba teórica". Esta es una prueba de este tipo, en la que precargamos preguntas importantes para nosotros y las respuestas correctas. Las preguntas pueden ser las más estúpidas. Creo que para usted estos serán ejemplos cómicos, pero para las personas que se enfrentan a tareas de prueba por primera vez en sus vidas, estas no son cosas obvias. Por ejemplo: "Si me encontré con varios errores, ¿necesito iniciar varios tickets, uno para cada error, o volcar todo en una pila?" O: "¿Qué sucede si quiero tomar una captura de pantalla, pero la captura de pantalla no me funciona?"

Estas pueden ser preguntas muy diferentes, arbitrariamente de bajo nivel, y es importante para nosotros que una persona las trabaje independientemente en la etapa de estudio de la teoría. Por lo tanto, la prueba teórica consiste en preguntas de este tipo: "Encontré varios errores, ¿debería tener un boleto o varios?" Si una persona elige la respuesta incorrecta, se cae un dado rojo que dice: "No, espera, la respuesta correcta es diferente, presta atención". Incluso si una persona no ha leído las instrucciones, no puede pasar esta prueba.



El siguiente punto es la práctica. ¿Cómo asegurarse de que las personas que no sabían nada acerca de las pruebas y no respondieron específicamente a la vacante del probador, entendieron lo que se debe hacer a continuación? Aquí llegamos a ese conjunto de entrenamiento. Creo que inmediatamente encontrarás una gran cantidad de errores en esta imagen. Así es como se ve la tarea de capacitación para el asesor: aquí hay una captura de pantalla frente a usted, encuentre todos los errores en ella. ¿Qué está mal aquí? La calculadora sobresale. Que mas El diseño fue.



O aquí hay un ejemplo más complejo, con un asterisco. El buzón del destinatario principal está abierto, yo soy el destinatario de esta carta. Entonces veo una foto así delante de mí. ¿Cuál es el error aquí? El mayor problema aquí es que se muestra una copia oculta y, como destinatario de la carta, veo quién era en la copia oculta.

Después de pasar un par de docenas de estos ejemplos, incluso una persona que está infinitamente lejos de las pruebas, ya comienza a comprender qué es y qué se requiere de él cuando pasa los casos de prueba. La parte práctica es un conjunto de ejemplos en los que ya conocemos errores; le pedimos a la persona que los encuentre y al final le mostramos: "Mira, el error estaba aquí", para que correlacione sus conjeturas con nuestras respuestas correctas.



Y la última parte es lo que llamamos un examen. Tenemos un ensamblaje de prueba especial, cuyos errores ya conocemos, y le pedimos a la persona que lo revise. Aquí ya no le mostramos las respuestas correctas e incorrectas, solo mira lo que pudo encontrar.

La belleza de este sistema y su escalabilidad radica en el hecho de que todos estos procesos ocurren de manera absolutamente autónoma, sin la participación de un gerente. Dirigimos a tantas personas como desee: todos los que quieran leer las instrucciones, todos los que quieran tomar el examen teórico, todos los que quieran tomar la práctica: todo esto sucede automáticamente con solo tocar un botón, y no tenemos ninguna preocupación en absoluto.

La última parte, el examen, también es aprobada por todos los que quieran, y luego, finalmente, comenzamos a mirarlos cuidadosamente. Como se trata de un ensamblaje de prueba y conocemos todos sus errores de antemano, podemos determinar automáticamente qué porcentaje de errores encontró una persona. Si es muy bajo, entonces no buscamos más, escribimos un ritmo automático: "¡Muchas gracias por sus esfuerzos!" - y no le dé a esta persona acceso a misiones de combate. Si vemos que se han encontrado casi todos los errores, en ese momento una persona ya se está conectando y está mirando cómo se emiten los boletos correctamente, cuánto se hace correctamente de acuerdo con el procedimiento, desde el punto de vista de nuestras instrucciones.

Si vemos que una persona domina de manera independiente la teoría y la práctica y aprueba bien el examen, entonces permitimos que esas personas entren en nuestros procesos de producción. Este esquema es bueno porque no depende de cuántas personas pasamos por él. Si necesitamos más personas, simplemente inundamos a más personas en la entrada y obtenemos más en la salida.

Este es un sistema genial, pero, por supuesto, sería ingenuo creer que después de eso ya puede tener un probador listo para usar. Incluso los muchachos que han completado con éxito nuestra capacitación tienen muchas preguntas que necesitan para ayudar rápidamente. Y aquí nos enfrentamos a muchos problemas inesperados.

La gente hace muchas preguntas. Además, estas preguntas pueden ser tan extrañas que nunca hubieras pensado en tu vida que las respuestas a estas preguntas deberían agregarse a las instrucciones, descritas en una prueba o algo así. Si lo piensas, esta es una situación normal. Cada uno de nosotros, cuando nos encontramos en un área desconocida para nosotros, es poco probable que hagamos una pregunta que parezca tonta para un especialista.

Aquí la situación se ve agravada por el hecho de que tenemos varios cientos de estas personas, e incluso si cada uno de nosotros pregunta a una persona específica, la probabilidad de hacer una pregunta estúpida es baja, en total resulta: “¡Ahhh! Oh dios Que esta pasando ¡Nos abruma!

A veces las preguntas parecen extrañas. Por ejemplo, una persona escribe: "No entiendo lo que significa" aprovechar Deshacer ". Le dicen: "¡Amigo! Esto es lo mismo que hacer clic en el botón "Cancelar". Él: "¡Oh! Gracias Ahora entiendo todo ".

O otra persona dice: "Todo parece estar bien, pero algo está un poco roto, no puedo entender si esto es un error o no". Pero después de un minuto, él mismo comprende dónde se metió en la tarea de prueba; Probablemente una foto rota no sea muy normal. Aquí lo entendió, y está bien.

O aquí hay un ejemplo interesante que realmente nos sumergió en el abismo de la investigación durante mucho tiempo. Un hombre viene y dice:



Todo el mundo no entiende lo que está sucediendo, de dónde viene, lo intentamos mucho, describimos casos de prueba, hasta que descubrimos que tiene algún tipo de extensión de navegador especial que se traduce del ruso al inglés y luego del inglés al ruso. , y al final tenemos algo de herejía.

De hecho, hay muchas preguntas de este tipo, el estudio de cada una de ellas lleva un tiempo distinto de cero. Y en algún momento, nuestros clientes, los servicios del equipo de Yandex que usaban las pruebas de los asesores, comenzaron a arrancarse el pelo y decir: "Escucha, pasaríamos mucho menos tiempo si probáramos todo esto nosotros mismos que para sentarnos en estas salas de chat y responder a estas extrañas preguntas ".

Por lo tanto, llegamos a un sistema de chat de dos niveles. Hay una inundación condicional, donde nuestros asesores se comunican con sus curadores, estos "muchachos con sombrero": el 90% de los problemas se resuelven aquí. Y solo los problemas más importantes y complejos se escalan en un chat dedicado en el que se sienta el equipo de servicio. Esto facilitó enormemente la vida de todos los equipos, todos suspiraron con calma.



Estos horrores de los que hablo no son tan terribles. La buena noticia es que todos estos procesos convergen muy rápidamente. Cualquier primer lanzamiento siempre es muy malo. En la imagen de arriba, son visibles 6 inicios consecutivos de la misma regresión.

Mire cuánto tiempo dedicaron los miembros del personal a responder preguntas, por primera vez cuando los asesores no entendían de qué estaban hablando y qué querían de ellos. Encontraron pocos errores, comenzaron muchas entradas sobre nada en absoluto. Por lo tanto, la primera vez es horror-horror-horror, la segunda vez es horror-horror, y por tercera vez, el 80 por ciento de todos los procesos convergen. Y luego viene el proceso genial elaborado: los evaluadores se acostumbran a la nueva tarea, y después de cada lanzamiento recopilamos comentarios, complementamos los casos de prueba y resolvemos algo. Y resulta ser una fábrica genial que funciona con solo hacer clic en un botón y no requiere la participación de un especialista a tiempo completo.

3. Control de calidad.

Un punto muy importante, sin el cual todo esto no funcionará, es el control de calidad.

Nuestros asesores trabajan en salarios a destajo: todas sus tareas están muy claramente reguladas y cuantificadas, cada unidad de trabajo tiene su propia tarifa estándar y reciben el pago por el número de unidades completadas. Toloka funciona exactamente de la misma manera, y en general cualquier multitud. Este sistema tiene muchas ventajas, es muy flexible, pero también tiene sus inconvenientes. En un sistema con pago a destajo, cualquier contratista intentará optimizar su trabajo: dedicará el menor tiempo y esfuerzo posibles a la tarea para obtener mucho más dinero por unidad de tiempo. Por lo tanto, se garantiza que cualquier sistema de este tipo basado en crowdsourcing funcionará con la calidad mínima que usted permita. Si no tiene control sobre la calidad, entonces caerá lo más bajo posible.

La buena noticia es que puedes combatirlo, se puede controlar. Si podemos cuantificar la calidad del trabajo, entonces la tarea se reduce a una bastante simple. Esto es en teoría. En la práctica, no es tan simple en absoluto, especialmente en las tareas de prueba. Porque las pruebas, a diferencia de muchas otras tareas masivas que resolvimos con la ayuda de evaluadores, tratan eventos raros y todo tipo de estadísticas funciona bastante mal allí. Es muy difícil entender con qué frecuencia una persona realmente encuentra errores, si en principio hay muy pocos errores. Por lo tanto, tenemos que pervertir y usar varios métodos de control de calidad a la vez, que juntos nos darán una cierta imagen de con qué calidad trabaja el artista.

El primero es un control en la superposición. "Superposición" significa que asignamos cada tarea a varias personas. Hacemos esto naturalmente, porque cada caso de prueba necesita ser probado en varios entornos. Por lo tanto, resulta que el mismo caso de prueba se verificó en los entornos A, B y C. Tenemos tres resultados de tres personas, pasando el mismo caso de prueba. Luego observamos si los resultados divergieron.

A veces sucede que se encontró un error en un entorno, pero no en otros dos. Tal vez realmente lo sea, o tal vez el error de alguien: o una persona encontró un error adicional, o esos dos hicieron trampa y no encontraron algo. En cualquier caso, este es un caso sospechoso. Si nos encontramos con esto, entonces enviamos una nueva verificación para asegurarnos y verificar quién tenía razón y quién tenía la culpa. Tal esquema nos permite atrapar a personas que, por ejemplo, comenzaron boletos adicionales donde no se necesitaban, o se perdieron donde se necesitaban. Al mismo tiempo, observamos qué tan correctamente se abrió el ticket, si todo está de acuerdo con el procedimiento: se agregaron capturas de pantalla, si es necesario, se agregó una descripción clara, y así sucesivamente.

Además de esto, y especialmente esto se refiere solo a la exactitud de la emisión de boletos, es bueno y conveniente controlar automáticamente algunas cosas que, por un lado, parecen ser insignificantes, pero, por otro lado, afectan bastante el flujo de trabajo. Por lo tanto, verificamos automáticamente si hay una aplicación para el ticket, si se agregan capturas de pantalla, si hay comentarios en el ticket o si simplemente se cerró sin observar cuánto tiempo se dedicó a él para identificar casos sospechosos. Aquí puede encontrar muchas heurísticas diferentes y aplicarlas. El proceso es casi interminable.

Verificar la superposición es algo bueno, pero brinda una evaluación un tanto sesgada, porque solo verificamos casos controvertidos. A veces quieres hacer una verificación honesta. Para hacer esto, usamos pruebas de funcionamiento. En la etapa de capacitación, tuvimos ensambles de prueba especialmente ensamblados en los que sabemos de antemano dónde hay errores y dónde no. Utilizamos lanzamientos similares para el control de calidad y verificamos cuántos errores encontró una persona y cuántos se perdieron. Esta es una forma genial, da la imagen más completa del mundo. Pero es bastante costoso de usar: aunque todavía recolectamos un nuevo conjunto de prueba ... Usamos este enfoque muy raramente, cada pocos meses.

El último punto importante: incluso si ya hemos hecho todo, definitivamente debemos analizar por qué se omitieron los errores. Verificamos si fue posible encontrar este error siguiendo los pasos del caso de prueba. Si fue posible, pero la persona se perdió, entonces, la persona es una taza, y usted necesita tener algún efecto sobre él. Y si este caso no estaba allí, entonces necesita complementar de alguna manera, actualizar los casos de prueba.

Como resultado, reducimos todas las métricas de calidad en una sola calificación de evaluadores, lo que afecta su carrera y destino en nuestro sistema. Cuanto más alta sea la calificación de una persona, más recibirá tareas más difíciles y reclamará premios. Cuanto más baja sea la calificación del asesor, más probable es que sea despedido. Cuando una persona trabaja de manera estable con una calificación baja, finalmente nos separamos de ella.

4. Delegación

El último de los pilares de nuestro esquema piramidal escalable del que quiero hablar es sobre las tareas de delegación.



Recordaré una vez más cómo se ve nuestra pirámide para las tareas de prueba manual. Tenemos personas de "alto nivel": estos son evaluadores de tiempo completo, representantes del equipo de servicio que componen programas de capacitación para el servicio que necesitan probar, forman una estrategia para lo que necesita ser probado, escriben casos de prueba primarios en forma gratuita.

Además, contamos con los evaluadores más talentosos que transfieren los casos de prueba de forma libre a los formales, ayudan a otros evaluadores, los apoyan en las salas de chat y realizan verificaciones cruzadas y control de calidad selectivo.
Además, hay una nube de nuestros muchos artistas que realizan la regresión paso a paso.

A continuación tenemos Toloka, del cual no hemos olvidado.Ahora estamos en la etapa de experimentos: entendemos que los casos más simples se pueden dar para probar a una multitud impersonal en Toloka. Será mucho más barato y más rápido, porque hay aún más artistas allí. Pero mientras estamos en el proceso de construir este sistema. Ahora damos solo lo más simple, pero espero que en unos meses lleguemos al hecho de que delegaremos allí más.



Es muy importante monitorear el desarrollo adecuado de esta pirámide. En primer lugar (a menudo me hacen estas preguntas, por lo que quiero responderlas de manera proactiva), el crowdsourcing no es un rechazo al trabajo de especialistas de alto nivel a favor de las multitudes, sino una herramienta de escala. No podemos rechazar la parte superior de esta pirámide, nuestra "cabeza", solo podemos usar crowdsourcing para agregar más manos a este sistema, por lo que es realmente muy fácil escalarlo de forma gratuita.

En segundo lugar, esto no es ciencia espacial, pero debes recordarlo constantemente: toda la historia funciona bien y correctamente si las tareas que son más difíciles para este nivel se resuelven en cada nivel. En términos generales, si se puede hacer lo mismo en varios niveles de la pirámide, esto debe hacerse en su nivel más bajo. Esta no es una historia estática, sino dinámica. Comenzamos con el hecho de que solo las personas de "alto nivel" pueden realizar algunas tareas, refinar gradualmente el proceso y reducir estas tareas a continuación, ampliando y abaratando todo el proceso.

Y a menudo escucho ese comentario: "¿Por qué molestarse con este jardín? Es mejor simplemente automatizar todo y gastar energía en él". Pero el crowdsourcing no es un sustituto de la automatización, es una cosa paralela. Hacemos esto no en lugar de la automatización, sino además de eso. Tal sistema simplemente nos permite liberar a los trabajadores que podrían participar en la automatización, por un lado, y, por otro lado, formalizar el proceso bastante bien, lo que será mucho más fácil de automatizar.


Al final, recordaré una vez más cómo se ve toda nuestra historia. Comenzamos obteniendo casos de prueba en forma gratuita. Los ejecutamos varias veces a través de asesores, recopilamos comentarios, los especificamos. Después de eso nos ponemos geniales, ya lamimos casos de prueba. Paralelamente a esto, reclutamos a muchas, muchas personas, las sometemos al sistema de entrenamiento automático y en la salida solo obtenemos a aquellos que pudieron hacer frente a todos los pasos por su cuenta y se dieron cuenta de lo que queríamos de él. Tenemos una multitud entrenada. Él trabaja con casos de prueba formalizados para nosotros, y controlamos su calidad: constantemente lo verificamos, analizamos casos con errores perdidos para mejorar nuestros procesos.

Y ese sistema funciona para nosotros, vuela. No sé si mi historia será útil en este momento para alguien desde un punto de vista práctico, pero espero que nos permita pensar un poco más ampliamente y asumir que algunas tareas pueden resolverse de esta manera. Porque, y a menudo nos encontramos con esto, uno de ustedes ya podría sorprenderse pensando: “Bueno, tal vez esto funcione en algún lugar, pero definitivamente no es para mí. Tengo tareas tan difíciles que no se trata de mí en absoluto ". Pero nuestra experiencia sugiere que prácticamente cualquier tarea de casi cualquier área temática, si se descompone correctamente, se formaliza y se integra en un proceso claro, se puede escalar al menos parcialmente con la ayuda de multitudes.

Heisenbug 2018 Piter , : 6-7 Heisenbug , , .