![](https://habrastorage.org/files/87b/f2b/be3/87bf2bbe364446c69cd92349c85c093d.jpg)
Может ли самый первый релиз продукта быть достаточно хорошо оттестированным, или кучу шишек неизбежно набьёшь уже в продакшене? Конференция по тестированию «Гейзенбаг», которую мы недавно провели в Москве, состоялась в самый первый раз, так что можно было на её наглядном примере и посмотреть. Как она прошла? Возникли ли проблемы? И как вообще должна выглядеть конференция по тестированию, если внутри него существуют подвиды с совершенно разной спецификой, а дело с ним имеют специалисты разного профиля?
Утром 10 декабря в холле «Radisson-Славянской» можно было увидеть не только тестировщиков, но и разработчиков, которые не хотят просто «перекидывать код через стену», а ощущают значимость тестирования. В том же холле, помимо прочего, можно было поиграть в робохоккей — и поскольку в этой игре надо управлять жуками, она смотрелась на «Гейзенбаге» довольно символично.
С открывающим кейноутом выступал Илари Хенрик Эгертер — обладатель такой бороды, что при её виде люди твитят «живьём она впечатляет втрое сильнее». Предупредив «я консультант и менеджер, так что сомневайтесь во всём сказанном мной», он начал высказывать мысли, которые действительно способны вызывать возражения. Например, что деление на ручное и автоматизированное тестирование надуманное, потому что «в обоих случаях важны не руки, а мозг». И что TDD вообще не может считаться полноценным тестированием, «потому что закон необходимого разнообразия требует от контролирующей системы большего разнообразия, чем от контролируемой».
![](https://habrastorage.org/files/96e/c91/e24/96ec91e24c8442e99643bef5bc7e3eb3.jpg)
Призвав «не пытаться автоматизировать вообще всё», Илари сопроводил это наглядным экспериментом, протестировав тестировщиков. Он предложил совместно составить список критериев для тестирования «2+2» на калькуляторе. Из зала назвали много того, на что стоит обратить внимание — например, промежутки между нажатиями. Когда варианты иссякли, Илари продолжил: «Хорошо, вы подумали об условиях, при которых устройство может не выполнить нужное действие. Но что, если оно выполнит не только его? Что, если помимо четвёрки, оно выведет на экран ещё что-то? Если мы посмотрим на экран, то заметим неладное сразу же. А вот составить полные критерии для автоматизированного определения всего подобного затруднительно, много unknown unknowns».
Закончил речь он не менее решительно: словами «не считайте себя носителями истины, поддерживайте уровень сомнений внутри себя».
![](https://habrastorage.org/files/244/a47/d2f/244a47d2fbe541eb8fbe2f48720ce09a.jpg)
Дэн Куайяр, разрабатывающий Appium, недавно рассказывал нам в интервью о своём детище и о мобильном тестировании в целом. Доклад был о том же, но куда детальнее: «На iOS тестированию может мешать вылезающее предупреждение о “фишинговом сайте”, а смысла платить за сертификат только для тестирования нет. В таких случаях это предупреждение можно обойти с помощью safariIgnoreFraudWarning». Окончание доклада у него тоже получилось громким: «Верьте в себя. Я уверен, что можно сделать лучше, чем Appium. Если в SpaceX сажают ракету на баржу, это ещё не значит, что они что-то понимают!»
![](https://habrastorage.org/files/0b3/25a/9a6/0b325a9a66de48239abfed8225dab95b.jpg)
Доклад Игоря khroliz Хрола (Toptal) об автоматических тестах был, пожалуй, самым наглядным: на громадном экране в реальном времени он демонстрировал написанный на Ruby код одних тестов за другими, прогонял их и фиксировал в отдельной таблице производительность. Каждый следующий тест оказывался производительнее предыдущего, делая графу «сколько таких тестов можно прогнать за пять минут» всё более впечатляющей.
![](https://habrastorage.org/files/0cf/163/36e/0cf16336efdc44c694b862bc2241890d.jpg)
Тем временем Владимир vladimirsitnikov Ситников (Netcracker) разбирал тонкости нагрузочного тестирования на примере отличного известного ему инструмента JMeter. Например, если «запросы раз в минуту» оказываются строго в начале минуты, ничего хорошего в этом нет, картина получается непоказательной. С другой стороны, если просто взять и рандомизировать время, то непонятно, как потом корректно сравнивать замеры друг с другом — их условия заведомо отличаются. К тому же, если установлена частота «100 запросов в час» и тест проводится полчаса, хочется, чтобы это означало «50 за полчаса», а рандом такого не обещает. Что делать со всей этой сложной ситуацией? По мнению Владимира, создавать свой правильный велосипед — и он поступил именно так, написав таймер для JMeter. Этот таймер выдаёт пуассоновское распределение, отталкиваясь от random seed (так что можно повторить те же самые случайные задержки), и при этом обладает параметром test duration, позволяющем получить «ровные полчаса».
![](https://habrastorage.org/files/910/581/ada/910581ada0f640f18c0e3191ef8f795d.jpg)
Темы, затронутые Ситниковым, в следующем слоте оказались развиты в двух разных залах сразу: пока Алексей Рагозин (Deutsche Bank) говорил о нагрузочном тестировании, Станислав Башкирцев (EPAM) тоже обратился к рандомизации, но в другом контексте. Он предлагает использовать Random Ext (для JavaScript) или написанную им библиотеку Datagen (для Java), чтобы получать рандомизированные данные для тестирования. Почему это имеет значение? Станислав в качестве примера показал жалобу пользователя JIRA на ошибку при попытке вставить в поле текста эмодзи: без рандомизации такой сценарий может вообще не прийти в голову, а пользователям, как выясняется, он бывает нужен.
Концовка доклада получилась запоминающейся и в этом случае — там был список «зачем рандомизировать? 5 ”У”», и пятое «У» сразу врезалось в память:
- Улучшает покрытие
- Уменьшает количество необходимых тестов
- Упрощает код (подготовка ненужных данных)
- Упрощает разработку в общем (утилитарные задачи)
- Убучает инструментам, инфраструктуре (юникод)
![](https://habrastorage.org/files/5a3/e37/5fd/5a3e375fd3d947c5977ef4e5b1e5e28c.jpg)
Резко отличался от других доклад Филиппа Кекса: он заговорил о такой экстремальной теме, как автоматизация тестирования игр (о которой ранее писал блог-пост), и призвал не бояться создавать для этого собственные инструменты. В процессе Кекс наглядно показал с помощью лайвкодинга, как в Creative Mobile тестируют свой мобильный дрег-рейсинг NitroNation (больше 10 миллионов установок в Google Play). А заодно продемонстрировал фотографию сервера Cthulhu, запускающего сборки на целом ряде подключенных мобильных устройств — своё название сервер получил из-за того, как всё это вместе выглядит. Всё это настолько впечатлило аудиторию, что чуть ли не первым вопросом из зала после доклада оказался «Есть ли у вас вакансии».
![](https://habrastorage.org/files/df2/1a7/7c0/df21a77c0c5845be9f099da15a6378ad.jpg)
Jan Jaap Cannegieter начал выступление со слов «вам сложно правильно произнести моё имя, но ничего страшного, мне ваши тоже сложно» (поэтому мы на всякий случай оставим его латиницей). В отличие от Илари, он не предлагал упразднить деление на ручное и автоматизированное тестирование, но при этом соглашался с тем, что главным используемым инструментом оказывается мозг. И для демонстрации этого принялся на сцене тестировать сайт самого «Гейзенбага»: «Возьмём Website Crawler Tool и проанализируем им сайт. Он сообщает о ряде ошибок — но теперь нужен человек, чтобы разобраться, где ошибки на самом деле. Перейдём по этой ссылке — с ней вроде бы всё в порядке, хоть я и не понимаю, что это. А вот тут настоящая 404-я. Ура, я нашёл ошибку!»
В общем, полезно устраивать конференции по тестированию: заодно спикеры тебе всё сами оттестируют.
И, наконец, закрывающий кейноут был у Рекса Блэка — настолько значимой фигуры в мире тестирования, что на конференции некоторые делали с ним селфи. «Я из Техаса — возможно, вы ожидали, что буду в ковбойской шляпе? У нас есть выражение “all hat and no cattle” про тех, кто одевается как ковбой, не будучи им. Я не хочу быть all hat and no cattle, так что шляпу не ношу».
![](https://habrastorage.org/files/8e3/af5/558/8e3af555835749498a1d6481c1befd94.jpg)
В его кейноуте о том, как избегать ошибок в использовании метрик, был интересный пример с Hawthorne effect: порой сам факт измерения чего-то сказывается на измеряемом, мешая получить правильное представление о ситуации. Это любопытно перекликалось с названием конференции: «гейзенбагом» называют баг, исчезающий или меняющий свойства при попытке его обнаружения.
В ходе того же закрывающего кейноута некоторое время прерывалась онлайн-трансляция, так что конференция о борьбе с багами не обошлась без небольшого собственного «бага». Однако это стало самой серьёзной проблемой за весь день — помог опыт проведения конференций про другим тематикам. Получается, что есть ситуация, когда с первого раза вполне можно обойтись без масштабных проблем: в том случае, если уже набил руку на похожем.
Вопрос «какой должна быть конференция о таком разностороннем явлении, как тестирование» тоже нашёл свой логичный ответ: она тоже должна быть разносторонней. Доклады о нюансах конкретного продукта и доклады о всей деятельности в целом, доклад о распределённых системах на опыте Яндекса и доклад об играх на опыте популярнейшего приложения, доклады с кодом и доклады с общими рассуждениями — и в итоге, судя по фидбэку, пользу для себя смогли извлечь как тестировщики, так и разработчики.
По итогам конференции у подкаста Radio QA вышел выпуск о Heisenbug с участниками программного комитета. А топ-5 докладов конференции по оценкам зрителей оказался таким:
- Филипп Кекс (Creative Mobile) — Как научить роботов играть в игры?
- Александр Баяндин (Badoo) — ChromeDriver Jailbreak
- Дэн Куайяр (Appium) — Appium: Automation for Apps
- Станислав Башкирцев (EPAM) — Рандомизированное тестирование
- Владимир Ситников (Netcracker) — Подводные камни в нагрузочном тестировании
![](https://habrastorage.org/files/d71/05c/91e/d7105c91eaab42ccaa719fe836756110.jpg)
Комментарии (10)
IvanPonomarev
22.12.2016 01:45+5Присоединяюсь к благодарностям за конференцию! Было полезно!
Смотрели с коллегой по трансляции. Мои пожелания (как разработчика, а не специалиста по тестированию): хочется слышать ещё меньше теоретизирования, ещё больше практики, практики и практики с реальными инструментами.
И по всем вашим конференциям с позиции онлайн-зрителя: 1) ещё надёжнее трансляции — финальный кейноут да, оказался испорчен ))) 2) и ещё — было бы круто, если бы у интернет-аудитории была возможность «передавать записки» спикеру через твиттер какой-нибудь или как-нибудь.
(Впрочем, если в следующем году будет в Москве Гейзенбаг — мы, скорее всего, уже придём «в оффлайне».)23derevo
22.12.2016 17:00+1С кейноутом Рэкса в онлайне была проблема, да. Возникли проблемы с интернетом на площадке. Пока разбираемся, на чьей стороне была проблема — площадки или подрядчика по трансляции. Ясность должна наступить совсем скоро.
Что касается «передавать записки» — со следующего раза ведущий в зале будет просто задавать вопросы, которые возникают у людей в онлайне. Или мы будем их по скайпу выводить. Сейчас решаем.
Ну а в видео он уже неделю как лежит, и заполнившим фидбэк он уже неделю как доступен. Если вы заполняли фидбэк в прошлый четверг или позже — ссылка придет вот-вот.
igor_suhorukov
Жаль про доклад Алексея Рагозина ничего конкретного не сказали… Будет видео или стенограммы докладов с конференции?
phillennium
Про всё подробно не рассказать — текст попросту слишком длинным получится. Видео сначала становится доступно участникам, а в открытый доступ попадает спустя несколько месяцев, но уже сейчас на сайте доступны презентации.
ARG89
Публичное видео будет через несколько месяцев, презентации докладов можно посмотреть на сайте конференции
IvanPonomarev
А скоро ли будет смонтировано непубличное видео, для участников конференции? Пока прислали только ссылки на непорезанные куски…
23derevo
Обещают завтра.