Хабрахабр

Протестировать всё: как прошёл Heisenbug 2018 Piter

Спикеры из гигантских компаний и из юных стартапов, темы от тестирования мобильных игр до тестирования блокчейна, доклады с кучей кода и совершенно без кода; наконец, были вообще не доклады, а сессии «birds of a feather». Если попытаться описать прошедший Heisenbug одним словом, это будет «разнообразие».

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

Fuzzing-тестирование и компиляторы

Мы про свою тоже так думали, пока не послушали доклад Максима Казанцева (Azul Systems) и не осознали, каково живётся при тестировании компиляторов. Вы думаете, что у вас очень сложная и ответственная работа?

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

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

В общем, непонятно, за какое время миллион обезьян смог бы написать «Войну и мир», но протестировать компилятор они при должном надзоре могут в разумные сроки.

Zeptolab и автотестирование игр

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

И при создании суперхита Cut the Rope компании Zeptolab не помогла идея логировать действия ручных тестеров: да, можно записать, в какой момент с какими координатами произошёл тап или свайп, но этот лог не переиспользовать на устройстве с другим разрешением экрана или менее мощным процессором. Неудивительно, что геймдев со стороны может казаться непригодным для автоматического тестирования.

А теперь Дмитрий Алексеев и Евгений Шумаков рассказали об этом. Однако на этом в Zeptolab не похоронили идею автоматизации, при работе над игрой King of Thieves к ней вернулись — и там абстрагировались как от точных координат “в какой пиксель ткнули”, так и от точных временных промежутков, научившись вместо этого определять суть тапа. И ещё интересно, что компании пригодился проект Appium: его создатель Дэн Куйаяр на Heisenbug тоже уже выступал. Любопытно, что на одном из прошлых Heisenbug Филипп Кекс выступал с темой «Как научить роботов играть в игры», но там речь шла про игру с очень прямолинейным геймплеем (дрег-рейсинг) — а у King of Thieves специфика другая.

Тестирование конфигурации и разработчики

К счастью, на Heisenbug о них было кому напомнить. За амбициозными задачами вроде «автоматизируем неавтоматизируемое» легко забыть о менее эффектных, но не менее нужных.

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

Руслана давно знают посетители наших Java-конференций (JUG-встречу с ним мы организовали ещё в 2012-м), и тут он давал именно взгляд «со стороны разработчика», а его доклад предполагал, что слово «Java» зрители слышат не впервые. Доклад, по сути, развивал тему Андрея Сатарина с предыдущего Heisenbug (перейдя от общего к более частному), а также хорошо иллюстрировал слоган Heisenbug «о тестировании не только для тестировщиков».

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

Сразу две крупных компании на Heisenbug поделились тем, как они для тестирования используют не только обычных штатных сотрудников, но и более широкие круги: Ольга Мегорская рассказала о работе с помощью «асессоров» проекта Яндекс.Толока, а Анастасия Семенюк — о программе VK Testers.

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

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

Виталий Фридман и UX

Его доклады тоже встречают на ура, но обычно на совсем других конференциях. Виталия Фридмана широко знают, но не в тестировочных кругах: основанный им сайт Smashing Magazine для веб-дизайнеров и веб-разработчиков очень ценят в соответствующей индустрии. Однако такие важные для Виталия темы, как UI/UX, тоже требуют тестирования, и он выступил перед нетипичной для себя публикой.

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

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

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

BoF и эксперименты с форматом

А был на «Гейзенбаге» и другой формат, ранее на этой конференции не проводившийся. Среди докладов было много интересного — однако про формат докладов всё в целом понятно. Где? Вечером первого дня, помимо вечеринки и спортивного «Что? Когда?», прошли BoF-сессии (название формата появилось из-за английской пословицы «birds of a feather flock together», примерно соответствующей «два сапога пара»).

Стулья располагаются кругом, часть мест занимают спикеры, часть зрители — и начинается обсуждение заранее заданной темы. Что они собой представляли? Часто ли можно увидеть, как в одном разговоре участвуют сразу и Майкл Болтон, и Саймон Стюарт?

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

Майкл Болтон (и точка)

Однако бывают случаи, когда при заслуженной репутации человек оказывается не самым ярким спикером. В принципе, тут можно было бы ограничиться именем, которое в тестировочном сообществе говорит само за себя. Рады сообщить, что с Болтоном всё иначе: его закрывающий кейноут «Testers are their worse enemies» собрал очень воодушевлённые отзывы. Мы как организаторы ориентируемся на зрительский фидбэк — и когда после самого первого Heisenbug отзывы на выступление Рекса Блэка оказались не особо восторженными, намотали это на ус.

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

«Люди путают тестирование с простыми проверками сборки. Но «неформальную» не означает «непрофессиональную»: в своей речи он вдумчиво проходился по тому, что считает серьёзными проблемами. Это всё равно что давать слову “дом” определение “собранные определённым образом стройматериалы”. Есть определение программы как “набора инструкций для компьютера”, и я вижу в нём проблему. А программу — как то, что используют люди. Дом разумно определять как место, где живут люди. Мы зациклены на инструментах тестирования, и я не против инструментов самих по себе, но мы используем их как способ избежать контакта с людьми».

Было ещё много интересного — от рассказа Артёма Ерошенко о следующей версии Allure Framework до доклада Алексея Родионова о том, как в тестировании могут помочь сети Петри. Но продолжать можно было бы так долго, что лучше остановимся на этом моменте. Если забыли упомянуть что-то совсем важное или написали что-то некорректно — принимаем баг-репорты в личку. И начинаем ждать следующего Heisenbug, который пройдёт в Москве в декабре!

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

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

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

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

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