Регрессионное тестирование — очень важная часть работы над качеством продукта. А чем больше продуктов и чем быстрее они развиваются, тем больше усилий оно требует.
В Яндексе научились масштабировать задачи ручного тестирования для большинства продуктов с помощью асессоров — удаленных сотрудников, работающих по совместительству на сдельной основе, и теперь в тестировании продуктов Яндекса, помимо штатных тестировщиков, принимают участие сотни асессоров.
В этом посте рассказано:
- Как удалось сделать задачи ручного тестирования максимально формализованными и обучить им сотни удаленных сотрудников
- Как удалось поставить процесс на промышленные рельсы, обеспечить тестирование в различных окружениях, выдерживать 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сессоров.
На картинке показано, как выглядит этот интерфейс. Тут можно видеть задания, доступные асессору: здесь есть несколько задач по тестированию и несколько задач другого типа, которые асессор из этого примера тоже умеет выполнять. И вот человек приходит, видит доступные ему в данный момент задания, нажимает «Приступить», получает тест-кейсы на разбор и начинает их выполнять.
Важная часть нашей инфраструктуры — это фермы. Не все устройства есть на руках, поэтому задание — это, по сути, пара: тест-кейс и окружение, в котором его нужно проверить. Когда человек нажимает на кнопку «Приступить», система проверяет, есть ли у него окружение, в котором нужно провести тест. Если есть, то человек просто берёт задание и тестирует его на личном девайсе. Если нет, то мы отправляем его через удалённый доступ к ферме.
На картинке показано, как это выглядит, на примере мобильной фермы. Так человек удалённо подключается к мобильному телефону, который лежит у нас в офисе на ферме. Для Android мы используем опенсорсные решения OpenSTF. Для iOS хороших решений нет — до такой степени, что мы уже сделали свое собственное (но об этом расскажем подробно как-нибудь в следующий раз), потому что не смогли найти ни опенсорс, ни то, что имело бы смысл покупать. Понятно, что ферма полезна в тех случаях, когда у нас нет людей, которые имеют нужные устройства. И ещё важный её плюс в том, что у фермы очень высокий коэффициент утилизации: когда бы и какой бы человек ни пришел, мы в любой момент можем направить его на ферму. Это лучше, чем раздавать устройства лично, потому что устройства, выданные на руки человеку, доступны для работы только тогда, когда этот человек готов работать.
Немного поговорили о том, как это реализовано для наших асессоров с технической точки зрения, а теперь самая интересная для меня часть: принципы того, как мы вообще организовывали это производство.
Принципы организации производства в крауде
Для меня в этом проекте было интересно, что вроде бы предметная область очень специфичная, но все принципы организации производства достаточно универсальны: те же самые, которые используются при организации массового производства в других предметных областях.
1. Формализация
Первый принцип (не самый важный, но один из самых важных, один из наших «китов, слонов и черепах») — это формализация задач. Я думаю, что все вы знаете это по себе. Почти любую задачу проще всего сделать самому. Чуть сложнее объяснить вашему коллеге, который сидит рядом с вами в комнате, чтобы он сделал именно то, что нужно. А задача сделать так, чтобы сотни исполнителей, которых вы никогда не видели, которые работают удалённо, в любое произвольное время, сделали именно то, что вы от них ожидаете, — это задача на несколько порядков более сложная и подразумевает довольно высокий порог вхождения в то, чтобы вообще начать этим заниматься. В контексте задач тестирования задание у нас, понятно, — это тест-кейс, который нужно пройти и обработать.
И каким же должны быть тест-кейсы для того, чтобы можно было их использовать в такой задаче, как тестирование краудом?
Во-первых — и оказалось, что это совсем не само собой разумеющийся факт — тест-кейсы вообще должны быть. Бывали такие случаи, когда к нам приходили команды, которые хотели подключиться к тестированию асессорами, мы говорили: «Отлично, приносите ваши тест-кейсы, мы будем их проходить!» В этот момент заказчик грустнел, уходил, даже не всегда возвращался. После нескольких таких обращений мы поняли, что, наверное, в этом месте нужна помощь. Потому что если тестировщик из команды какого-то сервиса сам регулярно тестирует свои сервисы, ему не особо нужны полные, хорошо описанные тест-кейсы. А если мы хотим эту задачу делегировать большому количеству исполнителей, то без этого просто не обойтись.
Но даже в тех случаях, когда тест-кейсы вообще были, почти всегда они были понятны только тем людям, которые очень глубоко погружены в сервис. А всем остальным людям, которые вне контекста, было очень тяжело понять, что здесь происходит и что нужно делать. Поэтому важно было переработать тест-кейсы так, чтобы они были понятны не погруженному в контекст человеку.
И последнее: если мы сводим задачу тестирования к строго формальному прохождению конкретных кейсов, очень важно следить за тем, чтобы эти кейсы постоянно актуализировались, обновлялись и пополнялись.
Приведу несколько примеров.
На картинке выше, например, показан хороший кейс из нашего родного сервиса Толока, в котором нужно проверить корректность работы профиля исполнителя. Здесь всё разбито по шагам. Есть каждый шаг, который нужно сделать. Есть ожидание, что должно произойти на каждом шаге. Такой кейс будет понятен кому угодно.
А вот пример не такого успешного кейса. Вообще непонятно, что происходит. Описание вроде есть, но на самом деле — что это, что вы от меня хотите? Такого рода кейсы — это сразу нет, очень плохо проходят.
Как же мы построили процесс формализации тест-кейсов, чтобы, во-первых, они вообще у нас были, постоянно появлялись и пополнялись, и, во-вторых, чтобы они были достаточно понятными для асессоров?
Путём проб и ошибок мы пришли к такой схеме:
Наш заказчик, то есть какой-то сервис или команда, приходит и в сколь угодно произвольной форме, удобной для него, описывает те тест-кейсы, которые ему нужны.
После этого приходит наш умничка-асессор, который смотрит на этот свободно сформулированный текст и переводит его уже в хорошо формализованные и расписанные на мелкие детали тест-кейсы. Почему важно, что это асессор? Потому что он сам был в шкуре тех людей, которые проходят тест-кейсы из совершенно разных областей, и понимает, насколько детализированным должен быть тест-кейс, чтобы коллеги его поняли.
После этого мы обкатываем кейс: выдаём асессорам задания и собираем фидбэк. Процесс организован так, что если человек не понял, что от него требуется в тест-кейсе, он его пропускает. Как правило, после первого раза есть достаточно большой процент пропусков. Всё равно, как бы хорошо мы на предыдущей стадии ни формализовали тест-кейсы, никогда невозможно угадать, что окажется непонятным людям. Поэтому первый прогон — это почти всегда тестовый вариант, самые важные его функции — это собрать фидбэк. После того как мы собрали фидбэк, получили комментарии от асессоров, узнали, что им было понятно, а что нет, мы ещё раз переписываем, дописываем тест-кейсы. И через несколько итераций получаем классные, очень чётко сформулированные тест-кейсы, которые понятны всем.
У такого наведения порядка есть интересный side effect. Во-первых, оказалось, что для очень многих команд это вообще killer feature. Все к нам приходят и говорят: «А что, вы правда можете написать за меня тест-кейсы?» Это самое главное, чем мы привлекаем наших заказчиков. Второй эффект, неожиданный для меня — порядок в тест-кейсах имеет и другие отложенные эффекты. Например, у нас есть технические писатели, которые пишут пользовательскую документацию, и писать на основе таких хорошо разобранных и понятных тест-кейсов им гораздо легче. Раньше им приходилось отвлекать сервис, чтобы выяснить, что нужно описать, а теперь можно использовать наши понятные и классные тест-кейсы.
Приведу пример.
Вот так выглядел тест-кейс до того, как он прошёл через нашу мясорубку: очень куцый, не заполнено поле 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, там тоже будет много интересного, и на сайте конференции уже можно увидеть описания многих докладов.
Автор: phillennium
