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

в 14:16, , рубрики: автоматизированное тестирование, Блог компании JUG.ru Group, гейзенбаг, конференция, нагрузочное тестирование, ручное тестирование, тестирование, Тестирование IT-систем, Тестирование веб-сервисов, Тестирование игр, Тестирование мобильных приложений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: JUG.ru Group

Источник

Поделиться

* - обязательные к заполнению поля