258.57
Rating
JUG Ru Group
Конференции для программистов и сочувствующих. 18+

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

JUG Ru Group corporate blogIT systems testingWeb services testingMobile applications testingGame testing


Если попытаться описать прошедший 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, который пройдёт в Москве в декабре!

Tags:HeisenbugтестированиеконференцияMichael Bolton
Hubs: JUG Ru Group corporate blog IT systems testing Web services testing Mobile applications testing Game testing
+20
3.8k 11
Comments 1

Popular right now

Top of the last 24 hours

Information

Founded
Location
Россия
Website
jugru.org
Employees
51–100 employees
Registered

Habr blog