Пока мы после конференции Heisenbug собирали и анализировали зрительский фидбэк, на Хабре появился подробный пост IvanPonomarev с его впечатлениями зрителя. И чтобы не повторять его, а дополнить, мы решили построить свой текст о конференции иначе.

Не описывать все два дня с вечеринкой и не говорить о тех докладах, которые уже описал Иван, а посмотреть по зрительским оценкам, какие из остальных больше всего понравились аудитории (у всех таких оценки оказались выше 4.2), и рассказать немного о них. В итоге получился список «шесть вещей, которые привлекли зрителей Heisenbug» — по нему можно оценить и конкретные темы, и их разброс.

Танки

Летом на петербургском Heisenbug был доклад о нагрузочном тестировании от Алексея Лавренюка, и там упоминался Яндекс.Танк, к которому Алексей имеет прямое отношение. В этот раз на конференции тоже не обошлось без танков, но совсем других: Александр Шуков из Wargaming рассказывал о том, каково заниматься автотестами в случае с World of Tanks. Пока где-то вовсю бушуют микросервисы, игры остаются «монолитными» — так что игра таких масштабов тоже своего рода «танк», с которым надо ещё суметь управиться, и для этого в Wargaming сделали свой фреймворк.

Для кого был доклад — для тех, кто работает непосредственно в геймдеве («перенимайте опыт»), или, наоборот, для всех остальных («пока вы плюшками балуетесь, у нас вот что творится»)? Пожалуй, и для тех, и для других. Заранее знать игровую специфику не требовалось — наоборот, доклад как раз помогал понять основные положения. Например, со стороны легко не задуматься, что на тестировании игр очень сказывается разница между «коробочными» и MMO: одно дело тестировать большой проект, который «два года готовят, громко релизят и выдыхают», и совсем другое — непрерывно развивающийся. И пользу для себя могли извлечь не только люди из геймдева. В конце концов, монолиты не только в играх остались.

Можно ли было в кулуарах конференции выпытать у Александра способ читерить в World of Tanks? Наоборот, можно было получить от него объяснение, почему эта игра защищена от жульничества лучше многих других: почти всё обрабатывается на сервере, а не на клиенте, так что как ни пытайся нахимичить с установленным приложением, мало что сможешь сделать.

Смартфоны: пара парных докладов

iOS и Android поделили мобильный мир на две части. Забавно, что то же число всплывало на Heisenbug в связи с мобильной темой: в зрительский топ-5 докладов попало именно два с тегом #mobile, и каждый из них был представлен именно двумя спикерами.



Первый — «Тестирование геолокации в Badoo: шишки, камни, костыли и селфи-палка» от Александра Хози и Николая Козлова. Для дейтинга с функцией «пользователи поблизости» геолокация очевидно важна, и тщательность подхода спикеров к теме иллюстрировало уже то, что вместо «GPS» они говорили «GNSS» («global navigation satellite system»): GPS — самая популярная, но не единственная спутниковая навигационная система.

Хитрости с тестированием геолокации начинаются уже с того, что она подразумевает перемещения в пространстве. Если другие функции приложения можно напрямую вызывать на своём рабочем месте, то как проверять перемещение, не покидая офиса? Как выяснялось, разделение на Android и iOS тут как раз сказывается. У обеих систем в официальных эмуляторах можно «подкрутить» своё положение, но если у Android можно лишь просто задать конкретные координаты (по умолчанию стоит исландская деревня Дальвик, подарившая название виртуальной машине Android), то у iOS есть ещё и режимы, имитирующие перемещение. Но если стандартных инструментов не хватает, на помощь приходят сторонние, о которых тоже зашла речь. А позже затронули и энергопотребление — кто оказывался в незнакомом месте с разряженным телефоном, потому что часто смотрел на карту, тот понимает, насколько это больное место для геолокации.



Как раз об энергопотреблении был второй полюбившийся «мобильный» доклад от Алексея Лавренюка и Тимура Торубарова из Яндекса. Более того, они даже начали со слов о том, что слушали выступление Александра и Николая. Но затем ушли почти что в формат «Очумелые ручки». Как измерять энергопотребление приложения, не тратя время на разрядку смартфона в ноль? Теоретически есть софтовые способы это посмотреть, но они по ряду причин не устроили — например, из-за недостаточной частоты замеров (кроме того, там разница между Android и iOS тоже давала о себе знать). Среди сторонних hardware-проектов вроде Batt0r сейчас тоже не нашлось подходящего.

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

А/B-тесты

Что может быть проще проведения А/B-теста? Запустил два разных варианта на разную аудиторию, сравнил, оставил в продакшне показавший себя лучше.

Но не тут-то было. Роман Поборчий в названии доклада громко заявил «Ваши A/B-тесты сломаны», и это провокационное утверждение было подкреплено аргументами. Вот, например, один из первых. Обычно при сравнении результаты считают различающимися при вероятности этого в 95%, и такое число выглядит солидно. Но если вместо одного теста проводить целую серию («сейчас мы выберем лучший из десятков вариантов»), то вероятность, что хотя бы в одном из них результат был случайной флуктуацией, резко возрастает — а значит, очень вероятно, что вы примете за «самый понравившийся пользователям» вариант тот, который на самом деле выстрелил случайно.

Любопытно, что в зрительских отзывах Романа хвалили и «за статистику с математикой», и «за то, что было мало статистики с математикой». У такого парадокса есть объяснение: доклад говорил о важности статистического подхода в A/B-тестах, но при этом был тщательно выстроен так, чтобы неподготовленный слушатель не оказался погребён под грудой формул и не перестал что-либо понимать.

Белый ящик

Никита Макаров (Одноклассники) участвует в программном комитете Heisenbug, начиная с самой первой конференции. Неудивительно, что он понимает, каких докладов ждут зрители, и его собственный оказался высоко оценен.

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

Добавим куда менее предсказуемое: любопытный исторический факт из его доклада. Сейчас хорошо известен инструмент Chaos Monkey, который случайным образом отключает различные элементы большой системы, позволяя узнать, как система отреагирует на такой сбой. И Netflix, создавшие Chaos Monkey, сейчас считаются главными апологетами такого подхода. Но куда менее известно, что подобную идею впервые реализовывали ещё в 70-х, причём не на софтовом уровне, а на «железном». При развитии схемотехники, когда схемы стали сложными и последствия сбоя какого-либо элемента — неочевидными, для проверки их стали исключать из схемы физическим образом, породив тем самым fault injection.

Сообщения об ошибках

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

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

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

Атомные электростанции

Наконец, был и совсем неожиданный доклад. Вячеслав Аленьков представлял группу компаний «ASE», относящуюся к «Росатому», а атомная энергетика — не первое, что приходит в голову при словах «конференция по тестированию». И со стороны можно было бы предположить, что строительство АЭС — это консервативная область, где все главные принципы были заложены много лет назад, инновации приходят неторопливо, и непоколебимо царит водопадная модель. Нужны ли тотальная оцифровка всего и аджайл, когда речь не о модном мобильном фотосервисе, а о громадном, сложном и очень ответственном физическом объекте?

Оказалось, что нужны. Без гибкости сегодня просто никуда — с «водопадом» окажешься попросту неконкурентоспособным на мировом рынке («ASE» работает в целом ряде стран). А переход к цифровым проектам произошёл как раз по причинам, связанным с тестированием. Ошибка обходится гораздо дороже, когда она уже воплощена физически в виде неправильно проложенной трубы — и чем больше их удастся отловить до воплощения (например, в 3D-модели), тем лучше. В общем, всё ближе к жизни типичных участников Heisenbug, чем можно было подумать.

Баги

А напоследок, уже после докладов, поделимся парой забавных «багов» прошедшего Heisenbug.



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

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

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