Хабрахабр

Краудсорсинг в тестировании

А чем больше продуктов и чем быстрее они развиваются, тем больше усилий оно требует. Регрессионное тестирование — очень важная часть работы над качеством продукта.

В Яндексе научились масштабировать задачи ручного тестирования для большинства продуктов с помощью асессоров — удаленных сотрудников, работающих по совместительству на сдельной основе, и теперь в тестировании продуктов Яндекса, помимо штатных тестировщиков, принимают участие сотни асессоров.

В этом посте рассказано:

  • Как удалось сделать задачи ручного тестирования максимально формализованными и обучить им сотни удаленных сотрудников;
  • Как удалось поставить процесс на промышленные рельсы, обеспечить тестирование в различных окружениях, выдерживать SLA по скорости и качеству;
  • С какими трудностями столкнулись и как их решали (а некоторые еще не решили);
  • Какой вклад внесло тестирование асессорами в развитие продуктов Яндекса, как оно сказалось на частоте релизов и количестве пропускаемых багов.

В основе текста — расшифровка докладаОльги Мегорской с нашей майской конференции Heisenbug 2018 Piter:

Далее речь идёт от первого лица: Со дня доклада некоторые числа успели измениться, в таких случаях мы указали актуальные данные в скобках.

Сегодня мы поговорим про использование методик краудсорсинга для масштабирования задач ручного тестирования.

Попробую рассказать на примерах, чем я занимаюсь. У меня довольно странное название должности: руководитель управления экспертных оценок. В Яндексе у меня есть два основных вектора ответственности:

Я отвечаю за нашу краудсорсинговую платформу Яндекс.Толока. С одной стороны, это всё, что связано с краудсорсингом.

Туда входит много разного, и в том числе один из наших недавних проектов: ручное тестирование с помощью крауда, которое у нас называется «тестирование асессорами». А с другой — команды, которые, если пытаться дать универсальное определение, можно отнести к «массовым неразработческим вакансиям».

И сегодня мы поговорим как раз про это на примере задач тестирования. Моя основная деятельность в Яндексе заключается в том, что я свожу между собой левый и правый столбики с картинки и пытаюсь оптимизировать задачи и процессы в массовом производстве с помощью краудсорсинга.

Что такое краудсорсинг?

Начнём с того, что такое краудсорсинг. Можно сказать, что это замена экспертизы одного конкретного специалиста на так называемую «мудрость толпы» в тех случаях, когда экспертиза специалиста или очень дорога, или сложно масштабируется.

Например, в NASA очень любят краудсорсинговые проекты. Краудсорсинг активно используется в самых разных областях далеко не первый год. Кажется, что это очень сложная задача, но с помощью краудсорсинга она сводится к достаточно простой. Там с помощью «толпы» исследуют и открывают новые объекты в галактике. И когда много людей нашло подозрительно похожий на нужный им объект, дальше уже подключаются высокоуровневые специалисты и начинают это исследовать. Есть специальный сайт, на который выкладывают сотни тысяч фотографий, сделанных космическими телескопами, и просят любых желающих поискать там определенные объекты.

Каждый из исполнителей может решить одну или несколько этих маленьких задачек, а все вместе они в итоге работают на одно большое общее дело и собирают большой результат для высокоуровневой задачи. Если говорить в общем, то краудсорсинг — это такой метод, когда мы берём какую-то большую высокоуровневую задачу и делим её на много простых и однородных подзадач, на которые собираются множество независимых друг от друга исполнителей.

Краудсорсинг в Яндексе

Мы уже несколько лет как начали развивать нашу систему краудсорсинга. Изначально использовали её для задач, связанных с машинным обучением: для сбора обучающих данных, для настройки нейронных сетей, алгоритмов поиска и так далее.

Во-первых, у нас есть Яндекс.Толока. Как устроена наша экосистема краудсорсинга? Толоку мы запустили несколько лет назад. Это открытая краудсорсинговая платформа, на которой любой желающий может зарегистрироваться или как заказчик (разместить свои задания, выставить за них цену и собирать данные), или как исполнитель (находить интересные задания, выполнять их и получать небольшое вознаграждение). Сейчас у нас больше миллиона зарегистрированных исполнителей (мы называем их толокерами), и каждый день в системе около 17 000 человек выполняют задания.

Например, посмотреть на фотографию и сказать, есть на ней взрослый контент или нет, или прослушать аудиозапись и расшифровать то, что вы услышали. Так как мы изначально создавали Толоку с прицелом на задачи, связанные с машинным обучением, то традиционно повелось, что большинство задач, которые выполняют толокеры, — это такие задачки, которые очень просто и тривиально сделать человеку, но пока ещё довольно сложно алгоритму.

Люди на картинке одеты в жёлтые балаклавы, потому что все исполнители в Толоке анонимны и неизвестны для заказчиков. Толока — это очень мощный инструмент в плане производительности и количества данных, которые он помогает собирать, но довольно нетривиальный в использовании. Поэтому не все задачи, которые у нас есть, мы пока что умеем решать с помощью вот такого абсолютно «дикого» крауда. И управлять этими тысячами анонимусов, делать так, чтобы они делали именно то, что вам нужно — совершенно не простая задача. Хотя к этому и стремимся, позже об этом ещё скажу.

Это люди, которых мы называем асессорами. Поэтому для более высокоуровневых задач у нас есть следующий уровень исполнителей. Оно пошло от слова «assessment», то есть «оценка», потому что изначально асессоры использовались у нас для сбора субъективных оценок качества поисковой выдачи. Само слово «асессоры», может быть, немножко странное. С тех пор прошло много времени, асессоры стали выполнять много самых разных других задач, поэтому теперь это уже нарицательное слово: задачи изменились, но слово осталось. Эти данные потом использовались как target для машинного обучения функции ранжирования поиска.

Это ребята, которые работают на собственном оборудовании. По сути, наши асессоры — это штатные сотрудники Яндекса, но работающие part-time и полностью удалённо. С большинством из них мы никогда в жизни очно не пересекаемся. Мы с ними взаимодействуем только удалённо: мы их удалённо отбираем, удалённо обучаем, удалённо с ними работаем и, при необходимости, удалённо увольняем. Асессоры решают самые разные задачи: они связаны и с поиском, и с техподдержкой, и с какими-то низкоуровневыми переводами, и с тестированием, о котором мы будем дальше говорить. Они работают по любому удобному для себя графику, днём или ночью: у них есть минимальные нормы, эквивалентные примерно 10-15 часам в неделю, и они могут отрабатывать это время так, как им удобно.

Мы их выделяем, наделяем громким званием суперасессоров, и эти ребята выполняют уже более высокоуровневые функции кураторов: проверяют качество работы других людей, консультируют их, поддерживают и так далее. Как правило, какое бы задание мы ни взяли, из группы выполняющих его асессоров всегда выделяются наиболее талантливые люди, у которых это получается лучше, которым именно эта задача более интересна.

Таких людей, которые уже куда более высокого уровня и имеют сильные технические и менеджерские скиллы, у нас гораздо меньше, буквально единицы. И только на самом верху нашей пирамиды у нас появляется первый full-time-сотрудник, который сидит в офисе и управляет этими процессами. Такая система позволяет нам приходить к тому, что эти единицы «высокоуровневых» людей выстраивают пайплайны и управляют производственными цепочками, в которых дальше задействованы десятки, сотни и даже тысячи человек.

У неё есть несколько интересных свойств, которые мы стараемся использовать. Сама по себе эта схема не нова, ещё Чингисхан её успешно применял. Если какую-то задачу нужно вдруг начать делать больше, то нам не нужно искать дополнительные площади в офисе, чтобы куда-то посадить человека. Первое свойство довольно понятное — такая схема очень легко масштабируется. Это относится и к той области, о которой мы сегодня будем говорить, — задачам ручного тестирования. Нам вообще можно очень мало о чём думать: просто залить побольше денег, на эти деньги нанять побольше исполнителей, и из этих исполнителей наверняка вырастут более талантливые ребята в академических шапочках, и вся эта система будет масштабироваться и дальше.
Второе свойство (и это было удивительно для меня) — такая пирамида очень хорошо тиражируется вне зависимости от предметной области, в которой её применять.

Тестирование краудом

Когда мы запускали процесс тестирования с помощью крауда, самой большой проблемой было отсутствие позитивного референса. Не было никакого опыта, на который мы могли сослаться и сказать: «Ну вот эти ребята так сделали, они уже тестируют с помощью крауда в очень похожей на нас схеме, и там всё хорошо, значит, и у нас всё будет хорошо». Поэтому нам приходилось опираться только на свой личный опыт, который был отделён от предметной области тестирования и больше связан с настраиванием аналогичных производственных процессов, но в других областях.

Что мы умеем? Поэтому нам пришлось делать то, что мы умеем. Посмотрим, что у нас получилось. По сути — декомпозировать одну задачу на задачи разных уровней сложности и раскидывать их по этажам нашей пирамиды.

Это такое «среднее по больнице»: Во-первых, мы посмотрели на задачи, которыми заняты наши тестировщики в Яндексе, и попросили их условно раскидать эти задачи по разным уровням сложности.

Ободрённые этими цифрами, показывающими, что можно почти половину работы куда-то передать, мы приступили к построению тестирования с помощью крауда. Они оценили, что только 57% своего времени тратят на сложные высокоуровневые задачи, а где-то по 20% уходит на совсем низкоуровневую рутину, от которой все мечтают избавиться, и на задачи чуть посложнее, которые тоже вроде бы можно делегировать.

Какие цели мы перед собой ставили?

  • Сделать так, чтобы тестирование перестало быть узким местом, которым оно периодически являлось в производственных процессах, когда релиз готов, но он ждёт, пока пройдёт тестирование.
  • Разгрузить наших классных, очень умных, высокоуровневых специалистов — штатных тестировщиков — от рутины, заняв их действительно интересными и более высокоуровневыми задачами.
  • Повысить разнообразие окружений, в которых мы тестируем продукты.
  • Научиться обрабатывать пиковые нагрузки, потому что наши тестировщики говорили, что у них часто бывает неравномерная нагрузка. Даже если в среднем команда справляется с задачами, при возникновении какого-то пика его потом приходится очень долго разгребать.
  • Так как мы в Яндексе всё равно в некоторых проектах тратили довольно заметные деньги на аутсорс-тестирование, мы подумали, что хотелось бы за те деньги, которые мы тратим, получать чуть больше результатов, оптимизировать наши траты на аутсорс.

Хочу подчеркнуть, что среди этих целей нет задачи заменить тестировщиков краудом, как-то их ущемить и так далее. Всё, что мы хотели сделать — помочь командам тестирования, избавив их от низкоуровневой рутинной нагрузки.

Я сразу скажу, что основные задачи по тестированию сейчас выполняются не самым нижним уровнем «пирамидки», толокерами, а асессорами, нашими штатными сотрудниками. Давайте посмотрим, что у нас в итоге получилось. Дальше речь пойдёт в основном про них, кроме самого конца.

На полноценной задаче регресса у нас сейчас квалифицировано около 300 человек (прим.: с момента доклада стало 500). Сейчас асессоры выполняют у нас задачи регрессионного тестирования и проходят всякие опросы вроде «посмотрите на это приложение и оставьте свой фидбэк». Сейчас наши производственные нужды покрываются примерно таким количеством людей. Но эта цифра условная, потому что система, которая у нас построена, работает на произвольное количество людей: столько, сколько нам нужно. Но всего пул исполнителей примерно такой. Это не значит, что в каждый момент времени все они сидят наготове и готовы выполнять задание: поскольку асессоры работают в гибком графике, в каждый момент времени готовы подключиться где-то 100-150 человек. А простые задания, вроде опросов, когда нужно просто собрать неформализованный фидбэк от пользователей, у нас проходит через гораздо большее количество людей: в таких опросах участвуют сотни и тысячи асессоров.

Это, по дефолту, десктоп и какое-то мобильное устройство. Так как это люди, которые работают на собственном оборудовании, у каждого асессора есть свои личные девайсы. Но понятно, что у них есть не все возможные устройства, поэтому если нам нужно тестирование в каком-то редком окружении, мы используем удалённый доступ через ферму устройств. Соответственно, мы тестируем наши продукты на личных устройствах асессоров.

Это любопытно. Сейчас тестирование краудом используют уже как стандартный продакшн-процесс около 40 (прим.: теперь уже 60) сервисов и команд Яндекса: это и Почта, и Диск, и Браузер (мобильный и десктопный), и Карты, и Поиск, и много-много кто. И мы очень сильно уговаривали всех, говорили: «Да вы не бойтесь, давайте, попробуйте!» Но спустя буквально несколько месяцев у нас оказались десятки команд. Когда мы осенью 2017-го ставили себе планы на конец третьего квартала, у нас была амбициозная цель: привлечь хоть как-нибудь, «хоть обманом, хоть подкупом», хотя бы пять команд, которые бы использовали наши процессы тестирования с помощью крауда.

Так что можно считать, что сейчас это уже стандартная практика в Яндексе, которая летит очень хорошо. И теперь мы решаем другую задачу: как успевать подключать всё новые и новые команды, которые хотят присоединиться к этим процессам.

Сейчас мы делаем в день около 3 000 кейсов регрессионного тестирования (прим.: на октябрь 2018-го уже 7000 кейсов). Что у нас получилось с точки зрения производственных показателей? Большая часть проходит за несколько часов, в пределах суток. Тестовые запуски в зависимости от величины проходят от нескольких часов до (в пике) 2 суток. Это позволило командам релизиться намного чаще, в среднем где-то в несколько раз, потому что релизы стали проходить с той скоростью, которая доступна разработке, а не той, которая доступна тестированию, когда оно иногда становилось узким местом. Внедрение такой системы позволило нам снизить стоимость примерно на 30% по сравнению с тем периодом, когда мы использовали аутсорс.

Теперь я постараюсь рассказать, как мы вообще выстроили производственный процесс, который позволил нам прийти к этой схеме.

Инфраструктура

Начнём с технической инфраструктуры. Те из вас, кто видел Толоку как платформу, представляют себе, как выглядит её интерфейс: можно прийти в систему, выбирать задания, которые вам интересны, и выполнять их. Для внутренних сотрудников у нас есть внутренний инстанс Толоки, в котором мы в том числе раздаём задания разного типа для наших aсессоров.

Тут можно видеть задания, доступные асессору: здесь есть несколько задач по тестированию и несколько задач другого типа, которые асессор из этого примера тоже умеет выполнять. На картинке показано, как выглядит этот интерфейс. И вот человек приходит, видит доступные ему в данный момент задания, нажимает «Приступить», получает тест-кейсы на разбор и начинает их выполнять.

Не все устройства есть на руках, поэтому задание — это, по сути, пара: тест-кейс и окружение, в котором его нужно проверить. Важная часть нашей инфраструктуры — это фермы. Если есть, то человек просто берёт задание и тестирует его на личном девайсе. Когда человек нажимает на кнопку «Приступить», система проверяет, есть ли у него окружение, в котором нужно провести тест. Если нет, то мы отправляем его через удалённый доступ к ферме.

Так человек удалённо подключается к мобильному телефону, который лежит у нас в офисе на ферме. На картинке показано, как это выглядит, на примере мобильной фермы. Для iOS хороших решений нет — до такой степени, что мы уже сделали свое собственное (но об этом расскажем подробно как-нибудь в следующий раз), потому что не смогли найти ни опенсорс, ни то, что имело бы смысл покупать. Для Android мы используем опенсорсные решения OpenSTF. И ещё важный её плюс в том, что у фермы очень высокий коэффициент утилизации: когда бы и какой бы человек ни пришел, мы в любой момент можем направить его на ферму. Понятно, что ферма полезна в тех случаях, когда у нас нет людей, которые имеют нужные устройства. Это лучше, чем раздавать устройства лично, потому что устройства, выданные на руки человеку, доступны для работы только тогда, когда этот человек готов работать.

Немного поговорили о том, как это реализовано для наших асессоров с технической точки зрения, а теперь самая интересная для меня часть: принципы того, как мы вообще организовывали это производство.

Для меня в этом проекте было интересно, что вроде бы предметная область очень специфичная, но все принципы организации производства достаточно универсальны: те же самые, которые используются при организации массового производства в других предметных областях.

1. Формализация

Первый принцип (не самый важный, но один из самых важных, один из наших «китов, слонов и черепах») — это формализация задач. Я думаю, что все вы знаете это по себе. Почти любую задачу проще всего сделать самому. Чуть сложнее объяснить вашему коллеге, который сидит рядом с вами в комнате, чтобы он сделал именно то, что нужно. А задача сделать так, чтобы сотни исполнителей, которых вы никогда не видели, которые работают удалённо, в любое произвольное время, сделали именно то, что вы от них ожидаете, — это задача на несколько порядков более сложная и подразумевает довольно высокий порог вхождения в то, чтобы вообще начать этим заниматься. В контексте задач тестирования задание у нас, понятно, — это тест-кейс, который нужно пройти и обработать.

И каким же должны быть тест-кейсы для того, чтобы можно было их использовать в такой задаче, как тестирование краудом?

Бывали такие случаи, когда к нам приходили команды, которые хотели подключиться к тестированию асессорами, мы говорили: «Отлично, приносите ваши тест-кейсы, мы будем их проходить!» В этот момент заказчик грустнел, уходил, даже не всегда возвращался. Во-первых — и оказалось, что это совсем не само собой разумеющийся факт — тест-кейсы вообще должны быть. Потому что если тестировщик из команды какого-то сервиса сам регулярно тестирует свои сервисы, ему не особо нужны полные, хорошо описанные тест-кейсы. После нескольких таких обращений мы поняли, что, наверное, в этом месте нужна помощь. А если мы хотим эту задачу делегировать большому количеству исполнителей, то без этого просто не обойтись.

А всем остальным людям, которые вне контекста, было очень тяжело понять, что здесь происходит и что нужно делать. Но даже в тех случаях, когда тест-кейсы вообще были, почти всегда они были понятны только тем людям, которые очень глубоко погружены в сервис. Поэтому важно было переработать тест-кейсы так, чтобы они были понятны не погруженному в контекст человеку.

И последнее: если мы сводим задачу тестирования к строго формальному прохождению конкретных кейсов, очень важно следить за тем, чтобы эти кейсы постоянно актуализировались, обновлялись и пополнялись.

Приведу несколько примеров.

Здесь всё разбито по шагам. На картинке выше, например, показан хороший кейс из нашего родного сервиса Толока, в котором нужно проверить корректность работы профиля исполнителя. Есть ожидание, что должно произойти на каждом шаге. Есть каждый шаг, который нужно сделать. Такой кейс будет понятен кому угодно.

Вообще непонятно, что происходит. А вот пример не такого успешного кейса. Такого рода кейсы — это сразу нет, очень плохо проходят. Описание вроде есть, но на самом деле — что это, что вы от меня хотите?

Как же мы построили процесс формализации тест-кейсов, чтобы, во-первых, они вообще у нас были, постоянно появлялись и пополнялись, и, во-вторых, чтобы они были достаточно понятными для асессоров?

Путём проб и ошибок мы пришли к такой схеме:

Наш заказчик, то есть какой-то сервис или команда, приходит и в сколь угодно произвольной форме, удобной для него, описывает те тест-кейсы, которые ему нужны.

Почему важно, что это асессор? После этого приходит наш умничка-асессор, который смотрит на этот свободно сформулированный текст и переводит его уже в хорошо формализованные и расписанные на мелкие детали тест-кейсы. Потому что он сам был в шкуре тех людей, которые проходят тест-кейсы из совершенно разных областей, и понимает, насколько детализированным должен быть тест-кейс, чтобы коллеги его поняли.

Процесс организован так, что если человек не понял, что от него требуется в тест-кейсе, он его пропускает. После этого мы обкатываем кейс: выдаём асессорам задания и собираем фидбэк. Всё равно, как бы хорошо мы на предыдущей стадии ни формализовали тест-кейсы, никогда невозможно угадать, что окажется непонятным людям. Как правило, после первого раза есть достаточно большой процент пропусков. После того как мы собрали фидбэк, получили комментарии от асессоров, узнали, что им было понятно, а что нет, мы ещё раз переписываем, дописываем тест-кейсы. Поэтому первый прогон — это почти всегда тестовый вариант, самые важные его функции — это собрать фидбэк. И через несколько итераций получаем классные, очень чётко сформулированные тест-кейсы, которые понятны всем.

Во-первых, оказалось, что для очень многих команд это вообще killer feature. У такого наведения порядка есть интересный side effect. Второй эффект, неожиданный для меня — порядок в тест-кейсах имеет и другие отложенные эффекты. Все к нам приходят и говорят: «А что, вы правда можете написать за меня тест-кейсы?» Это самое главное, чем мы привлекаем наших заказчиков. Раньше им приходилось отвлекать сервис, чтобы выяснить, что нужно описать, а теперь можно использовать наши понятные и классные тест-кейсы. Например, у нас есть технические писатели, которые пишут пользовательскую документацию, и писать на основе таких хорошо разобранных и понятных тест-кейсов им гораздо легче.

Приведу пример.

Вот так выглядел тест-кейс до того, как он прошёл через нашу мясорубку: очень куцый, не заполнено поле description, сказано «ну вот смотрите на скриншот в приложении» и всё.

Так уже намного лучше. Вот как он стал выглядеть после того, как его переписали — добавили шаги и ожидания на каждом из шагов. С таким тест-кейсом гораздо приятнее работать.

2. Масштабируемое обучение

Следующая задача — моя любимая, самая, мне кажется, креативная в этом всём. Это задача масштабируемого обучения. Для того чтобы мы могли оперировать такими числами — «тут у нас 200 асессоров, тут 1 000, а тут вообще 17 000 толокеров каждый день работает» — важно уметь быстро и масштабируемо обучать людей.

Это, например, то, с чем мы сталкивались, когда работали с аутсорсом.
Очень важно прийти к такой системе, когда на обучение произвольного количества людей вы тратите не больше времени, чем на обучение одного конкретного специалиста. И это такая очень не масштабируемая схема. Специалисты очень классные, но для того чтобы погрузить их в контекст работы, у сервиса уходило довольно много времени, а на выходе у нас всё равно получается один человек, который полгода погружается в контекст. И нужно было это узкое место расширить. Получается, что каждого следующего человека нужно ещё по полгода погружать в контекст задачи.

Для тестирования мы делаем так. На любые массовые вакансии, не только в тестировании, мы набираем людей по нескольким каналам. Но таких людей всё равно на рынке ограниченное количество, а нам нужно, чтобы у нас не было никаких ограничений в найме людей, чтобы мы никогда не упирались в количество исполнителей. Во-первых, привлекаем людей, которые в принципе интересуются задачами тестирования, ребят где-то уровня junior-тестировщиков, для них это хороший старт, погружение в предметную область.

Мы пропагандируем примерно такой подход: каких бы людей вы ни взяли, если их много, то можно выстроить процесс так, чтобы из них отобрать наиболее способных и направить их на решение той задачи, которую вы преследуете. Поэтому, помимо поиска тестировщиков специально на эти задачи, мы проводим набор из людей, которые просто откликнулись на общую позицию асессора. Благодаря такому подходу мы никогда не упираемся в недостаток исполнителей и количество людей, которые у нас работают на этих задачах, всё сводится только к вопросу количества денег, которые мы готовы на это тратить. В контексте тестирования мы строим обучение так, чтобы можно было произвольных людей, которые даже ничего не знали о тестировании, обучить хотя бы минимальным азам, чтобы они начинали что-то понимать.

Мы показываем ребёнку 10 карточек с изображением мячика, и на 11-й раз он поймёт и скажет: «О! Я не знаю, насколько часто вы соприкасаетесь с этой темой, но во всяких научно-популярных статьях, особенно про машинное обучение и нейронные сети, часто пишут, что обучение машины очень похоже на обучение человека. Это мячик!» Так же, по сути, работает и компьютерное зрение, и любые другие технологии машинного обучения.

Что нам для этого нужно? Я хочу поговорить об обратной ситуации: обучение людей можно построить по такой же формальной схеме, как обучение машин. Нужен контрольный набор, на котором мы сможем проверить, хорошо он обучился или нет. Нам нужен training set — набор заранее размеченных примеров, на которых человек будет обучаться. И нужна формальная метрика, которая будет измерять качество выполняемой работы. Как в машинном обучении, нужно проверочное множество, на котором мы понимаем, как наша функция вообще работает. Именно на таких принципах мы построили обучение задачам простейшего регрессионного тестирования.

Оно состоит из нескольких частей. На картинке показано, как это обучение у нас выглядит. Во-первых, есть теория, потом практика и потом идёт экзамен, на котором мы проверяем, понял человек суть задачи или не понял.

Понятно, что для любой задачи, которую выполняет асессор, у нас есть большая развесистая полноценная инструкция с большим количеством примеров, где всё очень подробно разобрано. Начнём с теории. Но её никто не читает.

Это такой тест, в который мы заранее загружаем важные для нас вопросы и правильные ответы. Поэтому, чтобы проконтролировать, что теоретические знания реально осели у человека в голове, мы всегда даём доступ к инструкции, но после этого используем то, что мы условно называем «теоретическим тестом». Я думаю, что для вас это будут комичные примеры, но для людей, которые первый раз в жизни столкнулись с задачами тестирования, это всё совсем не очевидные вещи. Вопросы могут быть самые дурацкие. Например: «Если я встретил несколько багов, мне нужно заводить несколько тикетов — по одному на каждый баг — или сваливать всё в одну кучу?» Или: «Что делать, если я хочу сделать скриншот, но скриншотилка у меня не работает?»

Поэтому теоретический тест состоит из вопросов такого типа: «Я нашёл несколько багов, мне завести один тикет или несколько?» Если человек выбирает неправильный ответ, ему вываливается красная плашка, которая говорит: «Нет, подожди, правильный ответ здесь другой, обрати на это внимание». Это могут быть самые разные, сколь угодно низкоуровневые вопросы, и нам важно, чтобы человек проработал их самостоятельно на стадии изучения теории. Даже если человек не прочитал инструкцию, мимо этого теста он пройти не может.

Как сделать так, чтобы люди, которые вообще ничего не знали о тестировании и не откликались конкретно на вакансию тестировщика, поняли, что вообще дальше нужно делать? Следующий момент — это практика. Я думаю, что вы сразу найдёте большое количество багов, которые есть на этой картинке. Здесь мы приходим к тому самому обучающему набору. Что здесь не так? Так выглядит обучающее задание для асессора: вот перед тобой скриншот, найди на нём все баги. Что ещё? Калькулятор торчит. Вёрстка поехала.

Открыт почтовый ящик основного получателя, я — тот, кому отправлено это письмо. Или вот более сложный пример, «со звёздочкой». В чём здесь баг? Вот я вижу перед собой такую картину. Самая большая проблема здесь в том, что показывается скрытая копия, и я как получатель письма вижу, кому оно стояло в скрытой копии.

Практическая часть — это набор примеров, баги в которых нам уже известны; мы просим человека их найти и в конце показываем ему: «Смотри, баг был здесь», — чтобы он соотносил свои догадки с нашими правильными ответами. Пройдя пару десятков таких примеров, даже человек, бесконечно далёкий от тестирования, уже начинает понимать, что это такое и что от него требуется дальше при прохождении тест-кейсов.

У нас есть специальная тестовая сборка, баги которой нам уже известны, и мы просим человека её пройти. И последняя часть — это то, что мы называем экзаменом. Здесь мы уже не показываем ему правильные и неправильные варианты ответа, а просто смотрим, что он смог найти.

Мы запускаем сколько угодно людей: все желающие читают инструкцию, все желающие проходят теоретический тест, все желающие проходят практику — всё это происходит автоматически по нажатию ими кнопки, а нас вообще никак не касается. Прелесть этой системы и её масштабируемость заключаются в том, что все эти процессы происходят абсолютно автономно, без участия менеджера.

Поскольку это тестовая сборка и мы заранее знаем все её баги, мы можем автоматически определить, какой процент багов был найден человеком. Последнюю часть — экзамен — тоже проходят все, кто хочет, и тут, наконец, мы начинаем смотреть на них внимательно. Если же мы видим, что найдены почти все баги, то в этот момент уже подключается человек, который смотрит, насколько корректно оформлены тикеты, насколько всё сделано правильно по процедуре, с точки зрения наших инструкций. Если он совсем низкий, то мы дальше не смотрим, пишем автоматическую отбивку: «Спасибо большое за ваши старания!» — и не даём этому человеку доступ к боевым заданиям.

Эта схема хороша тем, что она не зависит от того, сколько людей мы через неё пропускаем. Если мы видим, что человек самостоятельно освоил и теорию, и практику и хорошо сдал экзамен, то таких людей мы на выходе пускаем в наши продакшн-процессы. Если нам нужно больше людей, мы просто зальём больше людей на вход и больше получим на выходе.

Даже у ребят, которые успешно прошли наше обучение, возникает много вопросов, с которыми им нужно оперативно помогать. Это классная система, но, естественно, было бы наивно полагать, что после этого можно уже иметь готового тестировщика. И тут мы столкнулись с большим количеством неожиданных для нас проблем.

Причём эти вопросы могут быть настолько странными, что вы никогда в жизни бы не подумали, что ответы на эти вопросы нужно добавить в инструкцию, описать в тесте или что-то подобное. Люди задают очень много вопросов. Каждый из нас с вами, когда попадает в неизвестную для себя область, с небольшой вероятностью, но задаст какой-нибудь вопрос, который специалисту покажется глупым. Если подумать, это нормальная ситуация.

Боже! Здесь ситуация усугубляется тем, что у нас этих людей несколько сотен, и если даже у каждого задать конкретного вероятность задать глупый вопрос низкая, в сумме получается: «А-а-а! Нас заваливает!» Что происходит?

Например, человек пишет: «Я не понимаю, что значит „тапнуть в Undo“». Иногда вопросы кажутся странными. Это то же самое, что нажать кнопку „Отмена“». Ему говорят: «Друг! Спасибо! Он: «О! Теперь я всё понял».

Но через минуту сам понимает, куда он попал — в задачу тестирования; наверное, битая фоточка — это не очень нормально. Или другой человек говорит: «Вроде всё нормально, но что-то фоточка битая, я не могу понять, это ошибка или нет». Здесь он сам понял, и окей.

Человек приходит и говорит: Или вот интересный пример, который реально надолго погрузил нас в пучину исследований.

Все не понимают, что происходит, откуда у него такое — мы же так старались, описывали тест-кейсы — пока не выясняем, что у него стоит какое-то специальное расширение браузера, которое переводит с русского на английский, а потом с английского на русский, и в итоге получается какая-то ересь.

И в какой-то момент наши заказчики — сервисы команды Яндекс, которые использовали тестирование асессорами — начали рвать на себе волосы и говорить: «Слушайте, мы бы потратили гораздо меньше времени, если бы тестировали всё это сами, чем сидеть в этих чатиках и отвечать на эти странные вопросы». На самом деле таких вопросов много, исследование каждого из них занимает какое-то ненулевое время.

Есть условная флудилка, где наши асессоры общаются со своими кураторами, этими «ребятами в шапочках» — здесь решается 90% вопросов. Поэтому мы пришли к системе двухуровневых чатов. Это очень облегчило жизнь всех команд, все вздохнули спокойно. И только самые важные и сложные вопросы эскалируются в выделенный чат, в котором сидит команда сервиса.

Хорошая новость заключается в том, что все эти процессы очень быстро сходятся. Эти ужасы, о которых я рассказываю, — они не так страшны. На картинке выше видны 6 последовательных запусков одного и того же регресса. Любой первый запуск всегда очень плох.

Они находили мало багов, они заводили много тикетов вообще ни о чём. Посмотрите, сколько времени тратили штатные сотрудники на то, чтобы отвечать на вопросы, в первый раз, когда асессоры вообще не понимали, о чём речь и чего от них хотят. И дальше идёт классный отработанный процесс: и асессоры привыкают к новой задаче, и мы после каждого запуска собираем фидбэк, дополняем тест-кейсы, что-то разбираем. Поэтому первый раз — это ужас-ужас-ужас, второй раз — это ужас-ужас, а к третьему разу процентов 80 всех процессов сходятся. И получается классная фабрика, которая работает по нажатию кнопки и не требует никакого участия штатного специалиста.

3. Контроль качества

Очень важный пункт, без которого всё это работать не будет, — это контроль качества.

Точно так же работает и Толока, и вообще любой крауд. Асессоры у нас работают по сдельной оплате труда: все их задачи очень чётко регламентированы и квантифицированы, каждая единица работы имеет свой стандартный тариф, и они получают оплату за количество выполненных единиц. В системе со сдельной оплатой труда любой исполнитель будет стараться оптимизировать свой труд — как можно меньше времени и усилий тратить на задачу, чтобы получить гораздо больше денег в единицу времени. Эта система имеет много плюсов, она очень гибкая, но имеет и свои минусы. Если вы никак не будете контролировать качество, то оно упадёт так низко, как только может упасть. Поэтому любая такая система, построенная на краудсорсинге, гарантированно будет работать с минимальным качеством, которое вы ей позволите.

Если мы умеем количественно оценить качество работы, то дальше задача сводится к довольно простой. Хорошая новость заключается в том, что с этим можно бороться, этим можно управлять. На практике она совсем не такая простая, особенно в задачах тестирования. Это в теории. Очень сложно понять, как часто человек реально находит баги, если багов в принципе очень мало. Потому что тестирование, в отличие от многих других массовых задач, которые мы решали с помощью асессоров, имеет дело с редкими событиями, и там довольно плохо работают всякие статистики. Поэтому нам приходится извращаться и использовать сразу несколько методов контроля качества, которые совокупно будут давать нам определённую картину того, с каким качеством работает исполнитель.

«Перекрытие» означает, что каждое задание мы выдаём нескольким людям. Первое — это проверка в перекрытии. Таким образом, получается, что один и тот же тест-кейс проверили в окружениях A, B и C. У нас это получается естественным образом, потому что каждый тест-кейс нужно проверить в нескольких окружениях. Дальше мы смотрим, разошлись ли результаты. У нас есть три результата от троих людей — прохождение одного и того же тест-кейса.

Может быть, действительно так и есть, а может быть, чья-то ошибка: либо один человек нашёл лишний баг, либо те двое схалтурили и чего-то не нашли. Иногда бывает так, что в одном окружении баг нашёлся, в двух других — не нашёлся. Если мы с таким сталкиваемся, то отправляем на дополнительную перепроверку для того, чтобы убедиться и проверить, кто же был прав, а кто виноват. В любом случае это подозрительный кейс. Заодно мы смотрим, насколько корректно был заведен тикет, всё ли по процедуре: добавлены ли скриншоты, если нужно, добавлено ли понятное описание и так далее. Такая схема позволяет нам отлавливать людей, которые, например, заводили лишние тикеты там, где они были не нужны, или пропускали там, где были нужны.

Поэтому мы автоматически проверяем, есть ли к тикету приложение, добавлены ли скриншоты, есть ли в тикете комментарии или он был просто закрыт не глядя, сколько времени было потрачено на него, для того чтобы выявлять подозрительные кейсы. Кроме этого — и особенно это касается как раз правильности оформления тикетов — приятно и удобно автоматически контролировать какие-то вещи, которые, с одной стороны, кажутся мелочами, но, с другой стороны, довольно сильно влияют на рабочий процесс. Процесс практически бесконечный. Здесь можно придумывать много разных эвристик и применять их.

Иногда хочется сделать честную выборочную проверку. Проверка в перекрытии — хорошая вещь, но она даёт несколько смещённую оценку, потому что мы проверяем только спорные кейсы. На этапе обучения у нас были специально собранные тестовые сборки, в которых мы заранее знаем, где есть баги, а где нет. Для этого мы используем контрольные запуски. Это классный способ, он даёт максимально полную картину мира. Аналогичные запуски мы используем для контроля качества и проверяем, сколько багов человек нашёл, а сколько пропустил. Но он довольно дорогой в использовании: пока мы ещё соберём новую тестовую сборку… Мы используем этот подход довольно редко, раз в несколько месяцев.

Мы проверяем, можно ли было найти этот баг по шагам тест-кейса. Последний важный момент: даже если мы всё уже сделали, обязательно нужно проанализировать, почему баги были пропущены. А если этого кейса не было, то нужно как-то дополнять, актуализировать тест-кейсы. Если можно было, а человек пропустил, то, значит, человек — лопух, и нужно на него оказать какое-то воздействие.

Чем выше рейтинг у человека, тем больше он получает более сложных заданий и претендует на премии. Все метрики качества мы в итоге сводим в единый рейтинг асессоров, который влияет на их карьеру и судьбу в нашей системе. Когда человек стабильно работает с низким рейтингом, мы в итоге расстаёмся с ним. Чем ниже рейтинг асессора, тем больше вероятность быть уволенным.

4. Делегирование

Самый последний из столпов нашей пирамидальной масштабируемой схемы, о котором хочется поговорить, — это задачи делегирования.

У нас есть «высокоуровневые» люди — это штатные тестировщики, представители команды сервиса, которые составляют программы обучения под нужный им для тестирования сервис, формируют стратегию, что нужно тестировать, пишут первичные тест-кейсы в свободной форме. Я напомню ещё раз, как у нас выглядит пирамидка для задач ручного тестирования.

Дальше у нас есть самые талантливые асессоры, которые переводят тест-кейсы из свободной формы в формализованные, помогают другим асессорам, поддерживают их в чатиках и осуществляют перепроверку и выборочный контроль качества.
Дальше есть облако наших многочисленных исполнителей, которые выполняют регресс по шагам.

Сейчас мы на стадии экспериментов: мы понимаем, что простейшие кейсы можно отдавать в тестирование в обезличенный крауд в Толоку. Дальше у нас есть Толока, про которую мы не забыли. Но пока мы в процессе выстраивания этой системы. Это будет намного дешевле и быстрее, потому что там исполнителей ещё больше. Сейчас отдаём только самое-самое простое, но я надеюсь, что через несколько месяцев придём к тому, что будем делегировать туда больше.

Во-первых (такие вопросы мне часто задают, поэтому я хочу ответить на них превентивно), краудсорсинг — это не отказ от труда высокоуровневых специалистов в пользу крауда, а инструмент масштабирования. Очень важно следить за правильным развитием этой пирамиды. Мы не можем отказаться от верха этой пирамиды, от нашей «головы», мы только можем с помощью краудсорсинга добавлять больше рабочих рук в эту систему, таким образом реально очень легко, практически бесплатно масштабируя её.

Грубо говоря, если одно и то же можно делать на нескольких уровнях пирамиды, это обязательно нужно делать на самом нижнем её уровне. Во-вторых — это не rocket science, но про это нужно постоянно помнить: вся эта история функционирует хорошо и правильно, если на каждом её уровне решаются максимально сложные для этого уровня задачи. Мы начинаем с того, что какие-то задачи могут делать только «высокоуровневые» люди, постепенно отрабатываем процесс и спускаем эти задачи ниже, масштабируя и удешевляя весь процесс. Это не статичная история, а динамичная.

Но краудсорсинг — это не замена автоматизации, это параллельная вещь. И я довольно часто слышу такое замечание: «Зачем вообще городить этот огород, лучше просто всё автоматизировать и тратить силы на это». Такая система как раз позволяет нам освободить рабочие руки, которые могли бы заниматься автоматизацией, с одной стороны, и, с другой стороны, достаточно хорошо формализовать процесс, который потом будет гораздо легче автоматизировать. Мы это делаем не вместо автоматизации, а в дополнение к ней.

Мы начинаем с того, что получаем тест-кейсы в свободной форме.
Напоследок я ещё раз напомню, как выглядит вся наша история. После этого получаем классные, уже вылизанные тест-кейсы. Прогоняем их несколько раз через асессоров, собираем фидбэк, уточняем их. Получаем обученный крауд. Параллельно с этим мы набираем много-много людей, проводим их через систему автоматического обучения и на выходе получаем только тех, кто самостоятельно смог справиться со всеми этапами и понял, что мы от него хотели. Он у нас работает по формализованным тест-кейсам, а мы контролируем его качество: постоянно перепроверяем, анализируем кейсы с пропущенными багами для того, чтобы улучшать наши процессы.

Я не знаю, будет ли мой рассказ прямо сейчас полезен кому-то с практической точки зрения, но надеюсь, что он позволит немножко шире мыслить и допускать, что какие-то задачи можно решать и таким образом. И вот такая система у нас работает, летит. У меня такие сложные задачи, что это вообще не про меня». Потому что — и мы с этим сталкиваемся очень часто — кто-то из вас уже мог поймать себя на мысли: «Ну, может быть, это где-то и работает, но точно не у меня. Но наш опыт говорит о том, что практически любые задачи из практически любых предметных областей, если их грамотно декомпозировать, формализовать и выстроить в четкий процесс, можно хотя бы частично масштабировать с помощью крауда.

Если этот доклад с Heisenbug 2018 Piter вам понравился, обратите внимание: 6-7 декабря пройдёт московский Heisenbug, там тоже будет много интересного, и на сайте конференции уже можно увидеть описания многих докладов.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть