Гейзенбаг: Версия 1.0

Может ли самый первый релиз продукта быть достаточно хорошо оттестированным, или кучу шишек неизбежно набьёшь уже в продакшене? Конференция по тестированию «Гейзенбаг», которую мы недавно провели в Москве, состоялась в самый первый раз, так что можно было на её наглядном примере и посмотреть. Как она прошла? Возникли ли проблемы? И как вообще должна выглядеть конференция по тестированию, если внутри него существуют подвиды с совершенно разной спецификой, а дело с ним имеют специалисты разного профиля?

Утром 10 декабря в холле «Radisson-Славянской» можно было увидеть не только тестировщиков, но и разработчиков, которые не хотят просто «перекидывать код через стену», а ощущают значимость тестирования. В том же холле, помимо прочего, можно было поиграть в робохоккей — и поскольку в этой игре надо управлять жуками, она смотрелась на «Гейзенбаге» довольно символично.

С открывающим кейноутом выступал Илари Хенрик Эгертер — обладатель такой бороды, что при её виде люди твитят ^[5] «живьём она впечатляет втрое сильнее». Предупредив «я консультант и менеджер, так что сомневайтесь во всём сказанном мной», он начал высказывать мысли, которые действительно способны вызывать возражения. Например, что деление на ручное и автоматизированное тестирование надуманное, потому что «в обоих случаях важны не руки, а мозг». И что TDD вообще не может считаться полноценным тестированием, «потому что закон необходимого разнообразия ^[6] требует от контролирующей системы большего разнообразия, чем от контролируемой».

Призвав «не пытаться автоматизировать вообще всё», Илари сопроводил это наглядным экспериментом, протестировав тестировщиков. Он предложил совместно составить список критериев для тестирования «2+2» на калькуляторе. Из зала назвали много того, на что стоит обратить внимание — например, промежутки между нажатиями. Когда варианты иссякли, Илари продолжил: «Хорошо, вы подумали об условиях, при которых устройство может не выполнить нужное действие. Но что, если оно выполнит не только его? Что, если помимо четвёрки, оно выведет на экран ещё что-то? Если мы посмотрим на экран, то заметим неладное сразу же. А вот составить полные критерии для автоматизированного определения всего подобного затруднительно, много unknown unknowns ^[7]».

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

Дэн Куайяр, разрабатывающий Appium, недавно рассказывал нам в интервью ^[8] о своём детище и о мобильном тестировании в целом. Доклад был о том же, но куда детальнее: «На iOS тестированию может мешать вылезающее предупреждение о “фишинговом сайте”, а смысла платить за сертификат только для тестирования нет. В таких случаях это предупреждение можно обойти с помощью safariIgnoreFraudWarning». Окончание доклада у него тоже получилось громким: «Верьте в себя. Я уверен, что можно сделать лучше, чем Appium. Если в SpaceX сажают ракету на баржу, это ещё не значит, что они что-то понимают!»

Доклад Игоря khroliz ^[9] Хрола (Toptal) об автоматических тестах был, пожалуй, самым наглядным: на громадном экране в реальном времени он демонстрировал написанный на Ruby код одних тестов за другими, прогонял их и фиксировал в отдельной таблице производительность. Каждый следующий тест оказывался производительнее предыдущего, делая графу «сколько таких тестов можно прогнать за пять минут» всё более впечатляющей.

Тем временем Владимир vladimirsitnikov ^[10] Ситников (Netcracker) разбирал тонкости нагрузочного тестирования на примере отличного известного ему инструмента JMeter. Например, если «запросы раз в минуту» оказываются строго в начале минуты, ничего хорошего в этом нет, картина получается непоказательной. С другой стороны, если просто взять и рандомизировать время, то непонятно, как потом корректно сравнивать замеры друг с другом — их условия заведомо отличаются. К тому же, если установлена частота «100 запросов в час» и тест проводится полчаса, хочется, чтобы это означало «50 за полчаса», а рандом такого не обещает. Что делать со всей этой сложной ситуацией? По мнению Владимира, создавать свой правильный велосипед — и он поступил именно так, написав таймер ^[11] для JMeter. Этот таймер выдаёт пуассоновское распределение, отталкиваясь от random seed (так что можно повторить те же самые случайные задержки), и при этом обладает параметром test duration, позволяющем получить «ровные полчаса».

Темы, затронутые Ситниковым, в следующем слоте оказались развиты в двух разных залах сразу: пока Алексей Рагозин (Deutsche Bank) говорил о нагрузочном тестировании, Станислав Башкирцев (EPAM) тоже обратился к рандомизации, но в другом контексте. Он предлагает использовать Random Ext ^[12] (для JavaScript) или написанную им библиотеку Datagen ^[13] (для Java), чтобы получать рандомизированные данные для тестирования. Почему это имеет значение? Станислав в качестве примера показал жалобу ^[14] пользователя JIRA на ошибку при попытке вставить в поле текста эмодзи: без рандомизации такой сценарий может вообще не прийти в голову, а пользователям, как выясняется, он бывает нужен.

Концовка доклада получилась запоминающейся и в этом случае — там был список «зачем рандомизировать? 5 ”У”», и пятое «У» сразу врезалось в память:

• Улучшает покрытие
• Уменьшает количество необходимых тестов
• Упрощает код (подготовка ненужных данных)
• Упрощает разработку в общем (утилитарные задачи)
• Убучает инструментам, инфраструктуре (юникод)

Резко отличался от других доклад Филиппа Кекса: он заговорил о такой экстремальной теме, как автоматизация тестирования игр (о которой ранее писал блог-пост ^[15]), и призвал не бояться создавать для этого собственные инструменты. В процессе Кекс наглядно показал с помощью лайвкодинга, как в Creative Mobile тестируют свой мобильный дрег-рейсинг NitroNation ^[16] (больше 10 миллионов установок в Google Play). А заодно продемонстрировал фотографию сервера Cthulhu, запускающего сборки на целом ряде подключенных мобильных устройств — своё название сервер получил из-за того, как всё это вместе выглядит. Всё это настолько впечатлило аудиторию, что чуть ли не первым вопросом из зала после доклада оказался «Есть ли у вас вакансии».

Jan Jaap Cannegieter начал выступление со слов «вам сложно правильно произнести моё имя, но ничего страшного, мне ваши тоже сложно» (поэтому мы на всякий случай оставим его латиницей). В отличие от Илари, он не предлагал упразднить деление на ручное и автоматизированное тестирование, но при этом соглашался с тем, что главным используемым инструментом оказывается мозг ^[17]. И для демонстрации этого принялся на сцене тестировать сайт самого «Гейзенбага»: «Возьмём Website Crawler Tool ^[18] и проанализируем им сайт. Он сообщает о ряде ошибок — но теперь нужен человек, чтобы разобраться, где ошибки на самом деле. Перейдём по этой ссылке ^[19] — с ней вроде бы всё в порядке, хоть я и не понимаю, что это. А вот тут ^[20] настоящая 404-я. Ура, я нашёл ошибку!»

В общем, полезно устраивать конференции по тестированию: заодно спикеры тебе всё сами оттестируют.

И, наконец, закрывающий кейноут был у Рекса Блэка — настолько значимой фигуры в мире тестирования, что на конференции некоторые делали с ним селфи ^[21]. «Я из Техаса — возможно, вы ожидали, что буду в ковбойской шляпе? У нас есть выражение “all hat and no kettle” про тех, кто одевается как ковбой, не будучи им. Я не хочу быть all hat and no kettle, так что шляпу не ношу».

В его кейноуте о том, как избегать ошибок в использовании метрик, был интересный пример с Hawthorne effect ^[22]: порой сам факт измерения чего-то сказывается на измеряемом, мешая получить правильное представление о ситуации. Это любопытно перекликалось с названием конференции: «гейзенбагом» называют баг, исчезающий или меняющий свойства при попытке его обнаружения.

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

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

А топ-5 докладов конференции по оценкам зрителей оказался таким:

1. Филипп Кекс (Creative Mobile) — Как научить роботов играть в игры?
2. Александр Баяндин (Badoo) — ChromeDriver Jailbreak
3. Дэн Куайяр (Appium) — Appium: Automation for Apps
4. Станислав Башкирцев (EPAM) — Рандомизированное тестирование
5. Владимир Ситников (Netcracker) — Подводные камни в нагрузочном тестировании

Автор: JUG.ru Group

Источник ^[24]