Если попытаться описать прошедший Heisenbug одним словом, это будет «разнообразие». Спикеры из гигантских компаний и из юных стартапов, темы от тестирования мобильных игр до тестирования блокчейна, доклады с кучей кода и совершенно без кода; наконец, были вообще не доклады, а сессии «birds of a feather».
Наверное, лучший способ рассказывать о таком событии — не пытаться найти «общий знаменатель», а привести несколько разных примеров того, о чём можно было услышать на прошедшей конференции. Что мы и сделали под катом.
Fuzzing-тестирование и компиляторы
Вы думаете, что у вас очень сложная и ответственная работа? Мы про свою тоже так думали, пока не послушали доклад Максима Казанцева (Azul Systems) и не осознали, каково живётся при тестировании компиляторов.
Во-первых, там пользователи считают «это должно правильно работать всегда»: если ошибку в мобильном приложении люди готовы понять и простить, то ситуация «компилятор внёс ошибку в мою программу» вызывает в лучшем случае недоумение. Во-вторых, от веры пользователей «тут багов не может быть» вероятность их появления не исчезает — даже наоборот, в проекте такого масштаба и сложности бороться с ними ещё труднее обычного. А в-третьих, JIT-компилятор Falcon, над которым трудится Максим, сейчас очень активно развивается — то есть при такой сложности и таких требованиях к качеству надо тестировать очень большие нововведения в очень короткие сроки.
Но при этом доклад был посвящён не тому, через что проходят люди, о чьей работе мы обычно даже не задумываемся. Он был посвящён Fuzzing-тестированию, которое способно помочь как при работе над компиляторами, так и в совершенно других проектах. Суть его в том, чтобы автоматически генерировать миллионы разных тестов с элементом случайности, «вслепую паля во все стороны»: при определённых условиях вероятность попасть окажется выше, чем была бы с медленным прицельным огнём.
В общем, непонятно, за какое время миллион обезьян смог бы написать «Войну и мир», но протестировать компилятор они при должном надзоре могут в разумные сроки.
Zeptolab и автотестирование игр
«Мобильная игра» может звучать не так ответственно, как «JIT-компилятор», но с точки зрения тестирования тоже та ещё задача. Пока в «обычном» мобильном тестировании используют целый набор автоматизированных инструментов, в игровом многие из них оказываются непригодными: у элементов интерфейса нет стандартных view id, на разных устройствах всё может загружаться с совершенно разной скоростью, и вообще много своей сложной специфики.
Неудивительно, что геймдев со стороны может казаться непригодным для автоматического тестирования. И при создании суперхита Cut the Rope компании Zeptolab не помогла идея логировать действия ручных тестеров: да, можно записать, в какой момент с какими координатами произошёл тап или свайп, но этот лог не переиспользовать на устройстве с другим разрешением экрана или менее мощным процессором.
Однако на этом в Zeptolab не похоронили идею автоматизации, при работе над игрой King of Thieves к ней вернулись — и там абстрагировались как от точных координат “в какой пиксель ткнули”, так и от точных временных промежутков, научившись вместо этого определять суть тапа. А теперь Дмитрий Алексеев и Евгений Шумаков рассказали об этом. Любопытно, что на одном из прошлых Heisenbug Филипп Кекс выступал с темой «Как научить роботов играть в игры», но там речь шла про игру с очень прямолинейным геймплеем (дрег-рейсинг) — а у King of Thieves специфика другая. И ещё интересно, что компании пригодился проект Appium: его создатель Дэн Куйаяр на Heisenbug тоже уже выступал.
Тестирование конфигурации и разработчики
За амбициозными задачами вроде «автоматизируем неавтоматизируемое» легко забыть о менее эффектных, но не менее нужных. К счастью, на Heisenbug о них было кому напомнить.
Например, все помнят и думают про «основной» код от разработчиков, осознавая важность тестирования бизнес-логики — а вот то, что относится к конфигурации, может легко ускользать от внимания как «малозначимая вспомогательная сущность». Но Руслан Черёмин напоминал, что вообще-то с этой частью всё в некотором смысле ещё сложнее. Она тоже может приводить к ошибкам, которые стоят бизнесу денег, и при этом она обычно зависит от окружения. А это значит, что вроде бы протестированное «на моей машине» может удивить в продакшне.
Доклад, по сути, развивал тему Андрея Сатарина с предыдущего Heisenbug (перейдя от общего к более частному), а также хорошо иллюстрировал слоган Heisenbug «о тестировании не только для тестировщиков». Руслана давно знают посетители наших Java-конференций (JUG-встречу с ним мы организовали ещё в 2012-м), и тут он давал именно взгляд «со стороны разработчика», а его доклад предполагал, что слово «Java» зрители слышат не впервые.
Яндекс, ВК и краудсорсинг
Сразу две крупных компании на Heisenbug поделились тем, как они для тестирования используют не только обычных штатных сотрудников, но и более широкие круги: Ольга Мегорская рассказала о работе с помощью «асессоров» проекта Яндекс.Толока, а Анастасия Семенюк — о программе VK Testers.
Какие преимущества у такого подхода, какие сложности, и как эти сложности преодолевать? Например, Ольга рассказала, что это позволило расширить «пропускную способность» тестирования и сэкономить на QA-аутсорсе, так что уже многие крупные проекты Яндекса активно используют новый процесс, но без сложностей тоже не обошлось. Использование тысяч «не-тестировщиков» даже для рутинных задач означает, что эти задачи нужно подробно описывать понятным им языком, а разработчики не всегда были готовы это делать. В итоге помогает промежуточная прослойка из «опытных асессоров», получающих тест-кейсы в произвольной форме и переводящей их в понятный подробный алгоритм: им как раз понятно, какие вопросы возникнут у других асессоров.
Как многие участники Heisenbug заметили в отзывах, эти доклады были интересными, но не слишком применимыми для «обычных» компаний: когда у тебя нет ни армии увлечённых лояльных пользователей, как у ВК, ни масштабного краудсорсингового проекта, как у Яндекса, попытки сделать что-то аналогичное могут быть нецелесообразны. Но как раз уникальность этих ситуаций делала и сами доклады уникальными: если про «типичный опыт» можно послушать много от кого, то про подобное — только от этих людей. Как заметила Ольга, при построении своих процессов Яндекс даже не мог учиться на чужом опыте, и приходилось набивать все шишки самостоятельно.
Виталий Фридман и UX
Виталия Фридмана широко знают, но не в тестировочных кругах: основанный им сайт Smashing Magazine для веб-дизайнеров и веб-разработчиков очень ценят в соответствующей индустрии. Его доклады тоже встречают на ура, но обычно на совсем других конференциях. Однако такие важные для Виталия темы, как UI/UX, тоже требуют тестирования, и он выступил перед нетипичной для себя публикой.
Как выглядит элемент «карусель» на турецких сайтах? Почему его лучше не использовать, и если всё-таки использовать, то как? На каком сайте размещено, вероятно, самое длинное в мире сравнение характеристик товаров, и что можно было сделать, чтобы им стало удобно пользоваться? Зачем в таких сравнениях нужна возможность менять колонки местами? Какой рейтинг для товара идеален, если «5.0» ощущается накрученным и лживым? По какому чек-листу «учли ли мы это» стоит пройтись при реализации паттерна «аккордеон»?
Всё это не выглядит вопросами для конференции по тестированию — и доклад действительно получился своеобразным «оффтопиком». Однако зрительские отзывы показали, что включить его в программу было правильным решением: многие высказались в духе «да, не про тестирование, но это было потрясающе».
(А если заинтересовал вопрос про «аккордеон» — у Виталия про этот паттерн есть большая статья, и там в конце приведён упомянутый чек-лист.)
BoF и эксперименты с форматом
Среди докладов было много интересного — однако про формат докладов всё в целом понятно. А был на «Гейзенбаге» и другой формат, ранее на этой конференции не проводившийся. Вечером первого дня, помимо вечеринки и спортивного «Что? Где? Когда?», прошли BoF-сессии (название формата появилось из-за английской пословицы «birds of a feather flock together», примерно соответствующей «два сапога пара»).
Что они собой представляли? Стулья располагаются кругом, часть мест занимают спикеры, часть зрители — и начинается обсуждение заранее заданной темы. Часто ли можно увидеть, как в одном разговоре участвуют сразу и Майкл Болтон, и Саймон Стюарт?
Сессий шло две: на русском языке говорили о тестировании в продакшне, на английском — о вечной дихотомии «использовать готовый инструмент или пилить свой велосипед». Больше зрителей собрал русскоязычный, но довольно живо прошли обе.
Майкл Болтон (и точка)
В принципе, тут можно было бы ограничиться именем, которое в тестировочном сообществе говорит само за себя. Однако бывают случаи, когда при заслуженной репутации человек оказывается не самым ярким спикером. Мы как организаторы ориентируемся на зрительский фидбэк — и когда после самого первого Heisenbug отзывы на выступление Рекса Блэка оказались не особо восторженными, намотали это на ус. Рады сообщить, что с Болтоном всё иначе: его закрывающий кейноут «Testers are their worse enemies» собрал очень воодушевлённые отзывы.
Вероятно, это связано с тем, что Болтон оказался очень «живым»: он абсолютно не забронзовел в своих регалиях, шутит на сцене и вне её, притаскивает на BoF-сессию сразу два стакана пива («меня очень интересует вопрос, сколько стаканов можно эффективно нести одновременно?») и сразу создаёт располагающую неформальную атмосферу.
Но «неформальную» не означает «непрофессиональную»: в своей речи он вдумчиво проходился по тому, что считает серьёзными проблемами. «Люди путают тестирование с простыми проверками сборки. Есть определение программы как “набора инструкций для компьютера”, и я вижу в нём проблему. Это всё равно что давать слову “дом” определение “собранные определённым образом стройматериалы”. Дом разумно определять как место, где живут люди. А программу — как то, что используют люди. Мы зациклены на инструментах тестирования, и я не против инструментов самих по себе, но мы используем их как способ избежать контакта с людьми».
Было ещё много интересного — от рассказа Артёма Ерошенко о следующей версии Allure Framework до доклада Алексея Родионова о том, как в тестировании могут помочь сети Петри. Но продолжать можно было бы так долго, что лучше остановимся на этом моменте. Если забыли упомянуть что-то совсем важное или написали что-то некорректно — принимаем баг-репорты в личку. И начинаем ждать следующего Heisenbug, который пройдёт в Москве в декабре!
debose
А что там про Allure3? Когда будет доступен? Платный/бесплатный?