Звіт із Selenium Camp 2017, про метрики

Продовжу писати свої нотатки про Selenium Camp 2017. 

Інші частини:
    Про архітектуру тестів
        Про Continuos Deployment
 

Не одна і не дві доповіді були присвячені збору статистики запусків тестів; і звісно рішенням, що приймаються на основі зібраних даних.

Метрика села Северинівка, severyn.org

Що і чим міряють(ся) тестувальники у 2017?

 

# Збір Даних

За 2 дні я встиг побачити 3 презентації, де люди показували, як це в них:
    -  Хлопці з ізраїльського офісу Wix.com показали свою автентичну систему;   
    -  Джон Хейр-Вінтон(@jonhw87) з Guardian Media Group розповів, як у них на проді тести крутяться, і як збираються результати;
    -  а Х’ю МакКамфилл(@hughleo01) дав практичні поради, як це можна повторити вдома за допомогою стеку, що набуває популярності, Elasticsearch+Logstash+Kibana ELK.
Ще була презентація ReportPortal.io про хмарне рішення і може ще хтось. 

Якщо сюди додати кілька реалізацій інтеграції автотестів з TestRail, в яких я брав участь останнім часом, і додати кількість логів, що висерає у 2017 посередня система, стає ясно, що кількість накопичених результатів зараз буде стрімко зростати, і галузь в активному пошуку рішень. На мою думку, треба сюди запихати нейронні мережі, що будуть парсити і грепати ваші логи швидко і надійно (бо шукати в логах слово ERROR - це не будувати вело-маршрути в Києві). Потім вбудувати це все у плагін до Jenkins із окремо підключеним вінтом на кілька терабайт. Оце буде клас! Бажаючі?

 

# Пост-Детермінізм

Що кидається в око у колі автотестерів у 2017 - це їхня розслабленість. 
Впав тест на продакшені? Запусти ще раз.
Знову впав? Ну може ще 5 разів запустиш, і саме́ мине?

Вже не пригадаю кількість слайдів із словом flaky, що позначає непевний, нестабільний тест. Тепер коли тест впав один раз, його не біжать фіксити, а позначають flaky - непевним. У Wix.com тест позначають як failed тільки коли він впаде 4 рази, а у Guardian -- цілих 10. В якому стані знаходиться функціональність у цей час? 
 Можна вважати, що в тестуванні тепер офіційно з’явився статус "невизначеного" результату. І це певною мірою контрастує із кількістю разів, що я почув на конференції слово "deterministic" :-)

Також, у Wix.com згадували про "Too Stable", надто стабільний тест. Якщо тест ніколи не падає, його переводять "на пенсію", і запускають тільки на свята іноді.

Все це легко пояснюється. Тестові фреймворки ростуть, гладшають, починають робити складніші речі, ідуть до школи та вперше закохуються. А із ускладненням системи результат її роботи все важче і важче привести до бінарного Пройшов/Звалився. Все більше випадкових факторів, як то швидкість мережі чи доступна пам’ять в ОС, можуть вплинути на проходження тесту. І щоб прибрати вплив цих чинників, приходиться проганяти тести знову і знову щоб локалізувати проблему, зрозуміти: чи вона у нашій контрольованій системі, чи у дикому світі випадковостей?

# Продуктивність та Безпека

Щоб позбавити себе якомога більшої кількості випадкових факторів Альпер Мермер (@alpermermer) та багато інших наполягають, що до автоматизованих наборів мають бути додані:

• Тести Продуктивності
• Performance Journeys, тобто сценарії, що мусять проходити за певний час. Це такий собі перетин UX та продуктивності. Я вперше про таке почув, і захотілося одразу спробувати!
• Попередження про певний рівень навантажень, чи зайняття ресурсу. Ми не маємо бачити, що за 10 хвилин роботу у нас впала система із "...out of space", але нас можна попередити через одну хвилину, що швидкість і об’єм зайнятої пам’яті перевищують норму на 20%
• Варіативність може бути використана навіть у пеформанс-тестах. Спробуйте робити різні схожі дії одночасно.

Щодо продуктивності також кілька разів згадували між іншим Gatling.io. І чомусь жодного разу не згадали про цікавий хмарний сервіс оцінки продуктивності NewRelic.com (може час стати їхнім сейлзом? :-) )

• Безпекові Тести
• Використовуйте статичні перевірки коду на СІ
• Постійно перевіряйте наявність безпекових пачів для використованих third-paty компонентів
• OWASP ZAP щодня!

 Якщо на все це поглянути загалом, то ми компенсуємо непевність наших тестів спробами точніше контролювати середовище навколо системи-під-тестами.

   

# Метрики

На додачу до того, що ми вже вимірюємо, що нам експерти порадять ще поміряти? 

• Цикломатична складність. Мабуть, малася на увазі складність коду тестів. Чи всієї системи. Це із серії - "добрий код не може бути складним". Дивіться презентацію Альпера, там гарні картинки :)
• Пріоритетні баги на проді, за модулями. Це ясно. Допоможе матриця покриття функціоналу == Traceability Matrix.
• Середній час між падіннями білдів, за модулями. Оце дійсно крута та цікава метрика! Члени команд, звичайно, це інтуїтивно відчувають, але мати якусь борду, де будуть показані модулі/мікросервіси, де часто падають білди - це дійсно допоможе правильно оцінювати ризики!
• Тривалість кроку до середньої тривалості цього кроку. Цю метрику показував вищезгаданий Х’ю. Ось, доречі, його слайди, якщо відео не дивитесь. Цю метрику можливо впровадити тільки якщо у ви використовуєте паттерн Step, тобто кожен тестовий крок інкапсульований, і у сам тест викликає тільки крок, а не сторінку.

По вісі Х просто перелічені усі тестові кроки. По вісі Y - їхня тривалість у цьому білді (синя), і середня тривалість цього кроку за останній місяць(зелена). Усе можна нормалізувати для зображення на одному графіку, поділивши кожне значення на середнє, і отримавши процент від середнього.

 Це вже моя ілюстрація ідеї Х’ю, але виглядає цікаво.  

 На останок приведу фразу Х’ю МакКамфилла, що мені сподобалась:

Test failing is an indicator of change

Падіння тесту - ознака змін

Майже Лао Цзи :-). На цьому все, сподіваюсь, далі буде.