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



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

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

Або зіграти в #робохоккей на #heisenbugconf pic.twitter.com/3pfcxDXJO3  Heisenbug (@HeisenbugConf) December 10, 2016


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



Закликавши «не намагатися автоматизувати взагалі все», Іларі супроводив це наочним експериментом, протестувавши тестувальників. Він запропонував спільно скласти список критеріїв для тестування «2+2» на калькуляторі. Із залу назвали багато того, на що варто звернути увагу — наприклад, проміжки між натисканнями. Коли варіанти вичерпалися, Іларі продовжив: «Добре, ви подумали про умови, при яких пристрій може не виконати потрібну дію. Але що, якщо вона виконає не тільки його? Що, якщо крім четвірки, воно виведе на екран ще щось? Якщо ми подивимося на екран, то зауважимо недобре відразу ж. А от скласти повні критерії для автоматизованого визначення всього подібного важко, багато unknown unknowns».

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



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



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



Тим часом Володимир vladimirsitnikov Ситніков (Netcracker) розбирав тонкощі навантажувального тестування на прикладі відмінного відомого йому інструменту JMeter. Наприклад, якщо «запити разів на хвилину» виявляються строго на початку хвилини, нічого хорошого в цьому немає, картина виходить непоказательной. З іншого боку, якщо просто взяти і випадково час, то незрозуміло, як потім коректно порівнювати виміри один з одним — їх умови свідомо відрізняються. До того ж, якщо встановлена частота 100 запитів на годину» і тест проводиться півгодини, хочеться, щоб це означало «50 за півгодини», а рандом такого не обіцяє. Що робити з усією цією складною ситуацією? На думку Володимира, створювати свій правильний велосипед — і він вчинив саме так, написавши таймер для JMeter. Цей таймер видає пуассоновское розподіл, відштовхуючись від random seed (так що можна повторити ті ж самі випадкові затримки), і при цьому має параметром test duration, що дозволяє отримати «рівні півгодини».



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

Кінцівка доповіді вийшла запам'ятовується і в цьому випадку — там був список «навіщо випадково? 5 „В“ і п'яте „В“ відразу врізалося в пам'ять:
  • Покращує покриття
  • Зменшує кількість необхідних тестів
  • Спрощує код (підготовка непотрібних даних)
  • Спрощує розробку загалом (утилітарні завдання)
  • Убучает інструментів, інфраструктурі (юнікод)




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



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

Загалом, корисно влаштовувати конференції з тестування: заодно спікери тобі все самі оттестируют.

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



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

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

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

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

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



Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.