Еволюція тестового оточення: Інтерв'ю з Ігорем Хролом (Toptal) та Антоном Семенченко (COMAQA.BY і CoreHard)



Ми не любимо чекати в черзі, хочемо зробити замовлення онлайн, ми не готові купувати квиток у касі, нехай все буде в додатку, в електронному вигляді. І ось тут є важливе «Але»! Ми всі хочемо тут і зараз, але щоб це працювало без збоїв, як годинник. Доставку піци здійснили вчасно, місце в кінотеатрі співпало з отриманими в підтвердженні. Що у всьому цьому різноманітті додатків і сервісів відіграє одну з ключових ролей?

Звичайно — це тестове оточення, без чого неможливий швидкий випуск якісного продукту! Сучасні інструменти тестування увірвалися в наше життя як ураган і буквально за кілька років змінили наші можливості. Ми семимильними кроками освоїли віртуалізацію і контейнеризацію, спробували лінійку Selenium-а, сперечалися про переваги і недоліки Docker-а.

Навіщо все це було потрібно і до чого ми прийшли?
Яке майбутнє нас чекає?

Поговоримо «за тестування» гуру професії. Пройдемося від А до Я інструментарію. Допоможуть нам у цьому Ігор Хрол і Антон Семенченко.

Запасаємося кавою, чаєм, іншими напоями і починаємо. Розмова буде довгою.

Отже, Ігор Хрол — спеціаліст з автоматизації тестування в Toptal. Ігор має великий досвід роботи з більшістю популярних інструментів (Selenium, HP QTP, TestComplete, JMeter).

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

Добрий. Я дозволю собі не погодитися з самою постановкою питання. Класичні відділи тестування, які беруть певну збірку продукту на тестування і видають список дефектів, вже не відповідають сучасним швидкості ведення бізнесу і розробки ПО. Ми стаємо більш Agile (слово це вже досить заїжджено), коли всередині проектної команди є фахівець з тестування, готовий швидко допомогти розробці. Звичайно, інженери з тестування спілкуються між собою, але як такого відділу зі своєю управлінською структурою немає. У такому форматі працює багато передових компаній (як приклад тут дуже добре написано про Spotify). Тестування все щільніше інтегрується в процес розробки.

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

Про економію. Я б не сказав, що вона присутня, особливо в контексті оточення. Вартість заліза за останні роки впала, причому значно. А суми, які компанія може втратити через багів, непропорційно більше. Тому варіант перевірки тільки у себе на комп'ютері, може, і зустрічається в певних випадках, але безумовно не тренд. Я не знаю компаній, які могли б на догоду економії не купити сервер або не виділити гроші на створення хорошого тестового оточення.

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

Перші xUnit-системи з'явилися досить давно (Wikipedia говорить про 1989-й рік) і поки не було такої великої кількості користувальницьких інтерфейсів, напевно, цього вистачало. Потім, в кінці дев'яностих-на початку двотисячних, коли з'явилося більше користувальницьких інтерфейсів, почали з'являтися перші інструменти для UI. Одними з перших у моїй практиці був WinRunner (з'явився в 1995) і Watir (версії від 2005-го року).

Тоді і зараз
Тестування було завжди, адже якщо ти щось написав чи зробив, потрібно обов'язково перевірити. В честь цього і день тестувальника, що бере свій початок у 1945-му році.

Якщо говорити стосовно до теми тестового оточення, то я б не сказав, що є спеціальні інструменти для підготовки тестового оточення. Те, що ми робимо — це застосовуємо підходи для розгортання production оточень: Docker, Puppet, Ansible та інші суміжні рішення. Вони створювалися для того, щоб був відтворений результат. Як ефект ми можемо клонувати нашу production середовище і тестувати безпечно, максимально наближеному до реальності варіанті.

Раніше це були інструкції на сто листів, а нові оточення для тестування розгорталися місяцями, зараз же підходи значно краще. Все стало автоматизованим, всі в коді: запустив скрипт — оточення налаштоване. Тому я б не став називати ці штуки інструментами для тестування, це скоріше тема DevOps, адміністрування.

— Ігоре, розкажіть, будь ласка, про ваше перше «знайомство» з рішеннями в цій області. Коли ви, приміром, познайомилися з платформою VMware? Зараз ви пользуете дані програмні продукти?

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

Покористувався пару годин/днів/тижнів і приглушив це справа. Для continuous integration у нас в Toptal це все теж максимально автоматизовано. Пушнул код в github, а воно там десь само підняло в Google Cloud потрібну кількість серверів, прогнало тести і мені відписало в pull request, немає регресійних проблем. Локально іноді доводиться піднімати віртуальні машини для тестування якісь специфічних речей: наприклад, зрозуміти, як xlsx-звіт буде виглядати в Microsoft Office для Windows.

— Багато розробники люблять розділяти тестове оточення на чисте (з передвстановленою ОС і мінімальним) і брудна (максимально наближене до prod варіанту). Як ви вважаєте, таке розмежування доречно? Вам не здається, що таких варіантів може бути безліч, і їх краще не розглядати тільки в цьому ключі?

Дивлячись для яких завдань. Якщо запускаєте юніт-тести, то необхідний мінімальний набір ПО: що-то, щоб запустити ваш код (JVM, інтерпретатор...) і все. Якщо тестуєте окремий микросервис або компонента системи, то, можливо, вам багато чого не треба запускати, а мати працює тільки те, що цікавить. Практика показує, що мати якийсь staging або preproduction (хто як називає), максимально наближений до бойового оточення, дуже корисно для фінальних перевірок, приймальних тестів. Максимальна наближеність полягатиме у всьому: такому ж залозі, в мінорних версіях і латках на повноцінний наборі даних і т д.

— Процес підготовки тестового середовища раніше і зараз сильно відрізняється? Які інструменти доречні і в яких випадках? Тобто потрібно вибирати рішення в залежності від розміру компанії, або інструменти зараз легко масштабуються?

Коли я починав працювати, тестове оточення складалося з яких-небудь інструкцій. Або взагалі невідомим чином якимись адмінами. По мірі дорослішання тестувальники вже почали перевіряти ці інструкції, тестувати процес розгортання. Поступово все йшло до більшої автоматизації і, як наслідок, відтворюваності результату, зменшення людського фактору. Зараз налаштування оточення рідко виробляється руками — швидше за все, це буде ansible, puppet ну або щось аналогічне. У підсумку тестове оточення максимально наближене до production, і ми не тестуємо те, чого не буде на prod'e.

— Ви використовували / використовуєте контейнерні технології у повсякденній роботі? Ви дивилися рішення rancherOS або Atomic від Red Hat?

Тема docker/контейнерів та надбудов над ними зараз бурхливо розвивається. Чи впливає це на тестове оточення? Звичайно, впливає. Отримати працюючу систему для тестів вже можна в кілька кліків, що радує. У нас в Toptal контейнери використовуються в основному для тестування:

  • максимально підготовлений контейнер скорочує час на підготовку до запуску
  • якщо потрібно кілька компонентів для інтеграційного тестування, то їх легко отримати, запустивши декілька пов'язаних між собою контейнерів


— Після всіх дій зі створенням ідентичних конфіги і додатків постає питання про перенесення даних. В якому випадку доцільною є підтримка тестового середовища у вигляді дзеркальній версії prod-а? Важливий момент — це знеособлення бази даних. Як ви ставитеся до цієї практики при передачі в тестування?

Повноцінний набір даних потрібен найчастіше для приймальних тестів, коли вам треба глянути фінальний результат. Частину проблем можна не знайти, якщо у вас мало даних або вони не схожі на справжні. Тести продуктивності в багатьох випадках теж проводяться на реальних даних.

Знеособлення — це хороша, потрібна практика. Не дуже хотілося б, щоб з тестового середовища у зовнішній світ потрапили хеші паролів або навіть списки ваших клієнтів.

Selenium
— Зараз відбувається активне впровадження та використання Selenium-а (лінійки продуктів) в тест-середовищі. Ви бачили, як видозмінюється даний проект, обростаючи новим функціоналом? Що ви скажете про Selenium WebDriver в його нинішньому стані?

За розвитком Selenium'a я активно стежу і використовую його, починаючи з версій 0.8. Переповідати всю історію тут не бачу сенсу, так як на сайті selenium2.ru дуже добре написано про це.

Говорячи про поточний стан проекту, найбільш знаковим можна назвати те, що проект став w3c-стандартом для браузерів, і основні виробники браузерів самі реалізують драйвери.

Екосистема навколо WebDriver'a теж не стоїть на місці. Можливо, вона розвивається навіть швидше, ніж WebDriver API. Якщо раніше будь-який проект з автоматизації тестування починався з написання власного фреймворку, то зараз використання самописних рішень вважається поганим тоном. Практично в будь-якій мові вже є готові бібліотеки, що дозволяють не писати черговий раз те, як правильно перевіряти наявність елементів на сторінці або працювати з AJAX. На Java: HtmlElements, Selenide. В Ruby-світі: Capybara і page-object. Webium в Python.

З хороших ресурсів, присвячених Selenium'у, можу порадити запису конференції SeleniumCamp. Я там регулярно беру участь і мені подобається те, як тематика розвивається щороку.

— Як ви вважаєте, які саме інструменти для створення тестових середовищ вдалося зробити відмінно, на п'ятірку, за останні кілька років? Які сервіси однозначно варто спробувати вже зараз? Може, існують проекти, що розвиваються, на які варто звернути увагу вже зараз?

Тема створення тестових середовищ тісно перегукується з DevOps, і як таких окремих інструментів для тестувальників якось не приходить в голову. Я вважаю чудовим досягненням те, що зараз рідше зустрічається фраза «А у мене працює», так як оточення стають все більш і більш однаковими. Ключові слова у цьому відношенні — це ansible, puppet, docker, vagrant. Скрипти для розгортання стали невід'ємною частиною проектів і постачання.

Не можна не згадати cloud-рішення (AWS, Google Cloud, DigitalOcean). Раніше купували собі сервера і піднімалася купа обурення при спробі щось віддати третім особам. Зараз деякі компанії можуть собі дозволити власні датацентри, та й нема чого.

З перспективних напрямів можу відзначити cloud-рішення, де у вас взагалі немає серверів як таких, які потрібно перевантажувати, встановлювати оновлення і всіляко витрачати час, замість корисної діяльності. Push'нулі код – цей код у тестовій середовищі або на prod'e. Це Heroku, Google App Engine.

— Дякую за відповіді. Будемо чекати ваших наступних виступів.




Антон Семенченко — активіст спільноти автоматизаторів www.COMAQA.BY і «суворої» розробки C++ і www.CoreHard.by. Основна спеціалізація: автоматизоване тестування, низькорівнева розробка на C++ і нижче.

— Антон, добрий вечір. Тема нашої розмови – «Еволюція тестового оточення». Пропоную трохи торкнутися історію вашого становлення як фахівця, а в розвитку поговоримо про тестування.

Добрий! ОК.

— Як ви опинилися у всій цій історії? Процес переходу до тестування йшов паралельно з процесами розвитку цього сегмента в компанії, де ви працювали, чи це виключно ваш вибір?

Все вийшло випадково, але це, безумовно, мій вибір. Я, як і будь-який інший IT-фахівець широкого профілю, був побічно пов'язаний з тестуванням. Забезпечення якості кінцевого продукту – складний комплексний процес, тому і стандарти кодування, і код-review, і unit-тести, і парне програмування, формальні обговорення ключових ділянок коду, і робота з ERD, PRD – це все одно елементи Quality Assurance (далі QA), в яких беруть участь розробники. Тому мені був зрозумілий загальний цикл QA, я, безумовно, брав участь в забезпеченні якості.

Були проекти, цілком і повністю пов'язані з QA, наприклад, Unit-тестуванням, так, від Symantec був запит на покриття Unit-тестами ядра своїх флагманських продуктів, розроблених на чистому C на початку 80-х років. З одного боку – це складна технічна задача по розробці, з іншого боку – стовідсотковий QA. Ми займалися виключно Unit-тестами того, що в принципі не було призначене для тестування. Часом траплялися функції цикломатической складністю в 250 і більше. Все, приїхали, місяць можна розбиратися лише з однією функцією, щоб зрозуміти, як саме покрити її тестами. Так що я, звичайно, був пов'язаний з QA, але специфічно, побічно.

Автоматизоване тестування
На минулому місці роботи в компанії ISsoft з'явилася ідея відкрити незалежний відділ з автоматизованого тестування. В компанії були автоматизаторы, але, по-перше, ми пропонували автоматизацію не як сервіс, а як ресурс. Є фахівці, ви самі сформулюйте їм цілі, завдання, процеси, а вони працюють у стилі «можу копати, можу не копати». З'явилося бажання, швидше, бізнес-потреба, вийти на новий рівень якості сервісу, так і технічної складової рішень. По-друге, у компанії в силу завдань, які стояли перед колегами роками, не було хлопців, готових зайнятися вирішенням цих «викликів», при всій повазі до їх професіоналізму.

Мені надійшла пропозиція організувати подібний відділ з нуля. Ця роль вимагала різних навичок і в розробці, і в умінні працювати з людьми, адже потрібно було зібрати чудову команду, інакше «не зрушити гори». Вибір припав на мене не тільки і не стільки в силу винятково технічною складовою, а за сукупністю факторів. «Призначення» здалося мені цікавим, як я тоді думав і, мабуть, не помилився – автоматизація тестування це безумовний тренд.

Я почав працювати в цьому напрямку приблизно чотири роки тому. Мені дуже пощастило, я відразу знайшов хлопців, які чудово вписалися в команду, доповнили один одного, фактично був зібраний костяк: Андрій Стахіевіч, Вадим Зубович і багато інші, відомі з численних конференцій, публікацій, тренінгів та інших заходів, професіонали. Без команди я б з цими завданнями фізично не впорався.

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

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

Було зрозуміло, що область настільки динамічно розвивається, настільки широка і багатогранна, що силами однієї компанії її гарантовано неможливо охопити, для цього потрібна робота дуже різних фахівців, з різних компаній, краще з різних країн. Зараз ми активно рухаємося по СНД, намагаємося співпрацювати, тільки восени я буду брати участь у 25 події з усіх куточків Росії та Білорусі. Приблизно так я прийшов у цю цікаву сферу. Не можу сказати, що це був винятковою мій вибір. Якби мені надійшла така пропозиція, якщо б не вдалося зібрати чудову команду, цього б не сталося. Багато в чому це заслуга хлопців, що я зараз в автоматизації.

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

Мені здається, це дуже складний, неоднозначний питання, його слід розбити на кілька, на цілу групу питань. Я зараз висловлю свою суб'єктивну думку, можливо, багато фахівців з ним не погодяться, тим цікавіше побачити гарячу полеміку. На мій погляд, нічого концептуально нового в підходах до організації якогось процесу привнести практично неможливо, неважливо, чи говоримо ми про управління феодальним замком або про процесі розробки ПЗ. У широкому сенсі слова, Сократ у формулюванні Платона був першим об'єктно-орієнтованим програмістом. У нього були архетипи, категорії (ієрархії), неідеальні реалізації архетипів у нашому світі і т. п. Якщо цю ідею розвинути і застосувати до IT, то ось вам ООП з класами, мета-класами, об'єктами і іншої технічної атрибутикою.

Насправді, вже в п'ятдесяті роки були спеціалісти, які відповідають за встановлення та організацію стендів, формального тестового оточення, серйозні тест-плани та інша документація, причому в значно більш жорсткому, стандартизованому вигляді, ніж сьогодні. Це було продиктовано тим, що «залізо» коштувало дуже дорого, так що «машинне час» витрачали вкрай економно, до комп'ютера допускалися справжні гуру, які гранично ретельно, коректно конфигурировали оточення.

У це важко повірити, але розробка hardware та software, описана Фредеріком Бруксом в його «канонічної» книзі «Міфічний людино-місяць», є другим за вартістю науковим проектом в історії людства, перший – американська космічна програма. Це сьогодні ми можемо невірно організувати env і пропустити дефект, в минулому фахівці, крім стандартних «мінусів», на додачу отримували ситуацію, коли тут і зараз були даремно витрачені десятки або сотні тисяч доларів, адже «машинне час» коштувало «космічно» дорого.

З іншого боку, сьогодні дуже і дуже багато чого змінилося принципово. Кількість програмних продуктів зростає по експоненті, складність середнього програмного продукту падає по експоненті. Якщо у шістдесяті роки розроблялася виключно величезна, надскладне для фундаментальної науки, банківських систем, воєнки, то сьогодні це може бути веб-сторінка домашнього вихованця, завдання неймовірно простіше. Але є і третя «сторона медалі», завдяки тому, що росте, розвивається різне оточення, відбувається перехід кількості в нову якість за Гегелем.

Сам же «стрибок» на новий виток Гегелівської кривий продиктований необхідністю в силу закону «Ієрархічних компенсацій» Сєдова. Розвиваючи «прикладну» думка, безліч різних операційних систем і їх версій браузерів та іншої «обв'язки», орієнтованої на користувача, а також тих. складова, начебто версії JVM або .Net Framework-а, «засобів» в широкому сенсі слова, фізична і віртуальне оточення, дуже різне залізо – ось реалії сьогодення.

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

З одного боку, я не можу говорити про «принципові» зміни, з іншого – не можу заперечувати «якісного» росту, оскільки кількість різних environment-ов зростає по експоненті і завжди існувала проблема схрещування, інтеграції. Одна справа, коли у нас є n варіантів оточення, і зовсім інша — e у степені n, і ми починаємо їх «з'єднувати». Дана проблема комбінаторики та динамічного оточення в цілому варто зараз оооочеень гостро.

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

Віртуалізація
Взяти ту ж віртуалізацію, на якій зараз побудовано більшість хмарних сервісів, взяти контейнеризацію як етап розвитку віртуалізації. Прототипи віртуалізації з'явилися в п'ятдесяті роки, перша промислова серійна віртуалізація, якщо мені не зраджує пам'ять, вийшла в шістдесят четвертому році.

Не можна сказати, що віртуалізація – це щось нове (новизна, «застаріла» на п'ятдесят років), з іншого боку, у сьогоднішньому вигляді, коли існує безліч різних virtualization engine і всіх їх потрібно «з'єднати» один з одним, «виклик» принципово іншою. З'явився навіть окремий клас додатків, єдине завдання яких – одноманітно ефективним чином «здружити» різні virtualization engine, побудувати єдиний API з управління, неважливо, це low level CLI або загальний UI, далі може йти якась надбудова.

Наведу кілька непрямих особистих прикладів. Я багато років працював над розробкою data protection рішень – нескінченні варіації резервного копіювання і відновлення даних. Одна з дуже затребуваних завдань в недавньому минулому, сьогодні і, впевнений, завтра — «хитрий» bare metal restore[2].

Абстрактна ситуація «з голови»: фізична машина на 32 bit-ном Intel-вському залозі з ОС Windows 2000; шляхом back-up і bare metal restore переноситься в десятки хвилин, в ідеалі, по одному кліку, на 64 bit-ве AMD-шное залізо з Windows Server 2008… а якщо в цю «наваристу кашу» додати щіпку різних virtualization engine… а якщо спробувати вирішити завдання «по-гарячому», без виключення машини з точки зору споживача «сервісу»? Подібні нетривіальні трансформації дуже затребувані.

3 роки тому існував справжній IT-клондайк, багато великі компанії намагалися «втиснутися» у цей золотоносний ринок, підмножини bare metal restore рішень, у тому числі («юнацький максималізм» видно неозброєним оком) мій стартап DPI.Solutions. Як тільки офіційно Windows XP перестали підтримувати, банки судорожно почали шукати безпечний, швидкий і здійсненний спосіб масового переходу на нову ОС, так як за своїм внутрішнім policy не мали права залишатися на «операційки» без актуальних security pack-ів.

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

Спеціалізований bare metal restore вирішував подібну задачу в зазначені «страшні» обмеження. Зробив backup машини з Windows XP і розгорнув повністю готову до роботи, з усією «історичної» інформацією та налаштуваннями, вже на новому або старому залізі зі свіжою віндою, де виходять security pack оновлення. Багато компаній спеціалізувалися саме в цій області. Це нехай непряма, але яскрава ситуація, що ілюструє сьогоднішні складнощі «середовищ».

Юнацькі проблеми
Мені здається, формальна підготовка тестового оточення прийшла до нас лише сьогодні, багато в чому тому, що IT в СНД — «юна» професійна область, на пам'яті наших викладачів / вчителів стався розрив поколінь.

Спершу, Радянське IT, дуже потужне, яскраве, зі своїми плюсами і мінусами, мені, м'яко кажучи, важко судити про це часу, це історії «з чужого плеча». Потім IT у нас не було зовсім, ну або майже не було. Бурхливий розвиток пішло в двотисячних: повсюдно створювалися перші компанії, але вони не були великими, IT не був мейнстрімом, зарплати, а значить і потік талановитих кадрів, були відносно невисокими, порівнянними з іншими інженерними областями.

Тільки з 2005 року пішов активне зростання, галузь розвивається років десять, ну нехай п'ятнадцять; будемо відверті, ми ще підлітки, з класичними «підлітковими проблемами незнання і переоценивания, відкриття наново того, що було давно відомо нашим батькам. Чого далеко ходити, давайте подивимося на наших колег, візьмемо країни з фізично меншим об'ємом IT. Наприклад, поняття «бізнес-аналітик» в Молдові з'явилося лічені роки тому. Зрозуміло, що ця функція була завжди, але саме поняття про ролі з'явилося лише кілька років тому — яскрава ілюстрація «молодості професії», адже ми в СНД в «одному соку варимося».

Взяти інший приклад, поділилися «наболілим» колеги з Узбекистану. У них весь ринок ІТ фахівців — від тисячі до двох тисяч осіб, немає критичної маси, необхідної для якісного стрибка. Тренінгових центрів лічені одиниці, можна перерахувати по пальцях однієї руки на всю столицю; майже всі IT-шники – фахівці широкого профілю, знають і вміють все, але по верхах.

Ми страждаємо хворобами, незрелостями, світове IT розвивається дуже швидко, наш IT-ринок дуже активно зростає, а значить, складності, в тому числі складності «невстигання», зводяться в ступінь.

Якщо говорити про DevOps-фахівцях, як давно з'явився цей термін у Росії? У Білорусі активно використовується лише останні три роки, не більше. Ми своїми очима бачимо «дорослішання» і одночасно розвиток IT-галузі на прикладі Мінська. Так, чотири роки тому проходила одна велика спеціалізована IT-конференція на квартал, не більше, частина напрямків не були охоплені в принципі.

Зараз кожен день є, як мінімум, невелика зустріч, meet-up, присвячений одній з IT-спеціалізацій, можна щодня займатися очним IT-освітою самого широкого профілю, було б бажання.

Кількість і якість подій зростає принципово. Взяти, приміром, QA. Три роки тому у Білорусі не було жодного активного спільноти, присвяченого автоматизації тестування, і лише одне, присвячене Quality Assurance в цілому, організує 1-2 невеликих технічних події на рік, з 3-4 відмінними доповідями на базі SQA Days і 20-40 слухачами. Хлопці регулярно зустрічалися в неформальній обстановці, створювали умови для особистого спілкування, грали у Мафію та інші ігри. Вони робили дуже важлива і корисна справа, але це починання, при всій моїй глибокій повазі до учасників, не можна назвати професійним співтовариством, а «затишні посиденьки» — конференціями або навіть meet-up-ами.

Хлопці були першопрохідцями, за що їм величезне спасибі. Сьогодні тільки співтовариство COMAQA.by проводить 4 повномасштабні безкоштовні або умовно платні конференції в рік, присвячені QA Automation, а є ще регулярні читання в Університетах і школах, співпрацю з безліччю провайдерів IT-курсів, meet-up-и і вебінари. Найближчим подія пройде 5-6 листопада: 2 дня, 2 потоку, 8 майстер-класів, 16 доповідей, понад 500 очних слухачів, онлайн-трансляція по СНД. Один з майстер-класів буде присвячений Docker-у. Всю необхідну інформацію для участі в ролі слухача або доповідача можна знайти на сайті спільноти. Будемо дуже раді поділитися своїми знаннями і напрацюваннями.

Інший яскравий приклад. Близько року тому мною спільно з колегами було створено співтовариство CoreHard, зібрала фахівців з «суворою» розробки, перш за все на С++ і нижче. Сьогодні ми проводимо по 4 конференції в рік. Найближчим подія 22 жовтня: 11 доповідачів з СНД і США, понад 350 очних слухачів, онлайн-трансляція по СНД. Подія CoreHard збере чудових speak-єрів: це і Антон Полухін – активний розробник Boost, автор книги «Boost C++ Application Development Cookbook», представник в міжнародному комітеті з стандартизації С++ від Росії; і Єгор Кишилов — більше 8 років працює в Microsoft, все це час займаючись розробкою пошукової системи Bing; і Святослав Размыслов — керівник відділу, що займається розробкою ядра аналізатора PVS-Studio для аналізу C і C++ коду; і Євген Мисливців – незалежний розробник з більш ніж 20-річним стажем, займається OpenSource-інструментарієм для спрощення розробки багатопотокових додатків на мові C++; і багато-багато інших чудові фахівці. Величезне спасибі колегам, готовим поділитися своїми знаннями.

І це лише невеликий приклад, найбільш близький мені приватний випадок. У Мінську функціонують десятки активних спільнот, кожен день є певна подія. Ми протягом кількох років бачимо якісне, принципову зміну в галузі.

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

— Якісний тестове оточення зараз — це не тільки зв'язка програмних і апаратних засобів, у тому числі систем контейнеризації і хмарних сервісів, але і продумана ідеологія? Як розробити коректних план тестування?

Буду коротким. Мені здається, тест-план безумовно потрібен, а тестове оточення – обов'язкова частина, незалежно від розміру та обраної методології, неформальній документації або суворого слідування стандартам.

Оточення як невід'ємна частина тест плану обов'язково має бути враховано, причому «індивідуально» на кожному з етапів розробки ПО. Проблеми з усвідомленням необхідності формального підходу до організації тестового оточення якщо і можуть виникнути, то виключно в силу «юності» галузі в СНД, в силу недостатньої інформованості фахівців. На мій суб'єктивний погляд, в цілях систематизації знань дуже корисна сертифікація ISTQB.

Можна погоджуватися з зазначеною термінологією або ж гаряче дискутувати (я, швидше, «не угодовець»), але єдина несуперечлива база дуже важлива. Головне, ISTQB приділяється пильна увага і тест-плану і його складових частинах, у тому числі тестового оточенню, тому підручник для проходження сертифікації варто використовувати для придбання актуальних знань.

Про Мінськ можу сказати наступне, сьогодні немає відкритих курсів, тренінгів з менеджменту в тестуванні. Від спільноти COMAQA.by ми хочемо запустити восьмигодинний майстер-клас з метрик тестування як складової частини менеджменту, присвячений, перш за все, практиці і в меншій мірі теорії їх використання. На правах реклами повідомлю, що закінчую роботу над «авторським» за курсом «Менеджмент у тестуванні», який в абсолютно різних варіаціях буде запущений віддалено в Software-Testing.ru і очно в Мінську, спільно з тренінг-центром «Іскра».

Деякі частини курсу були прочитані в рамках корпоративних тренінгів англійською мовою, вперше російською я озвучу частина курсу у вигляді 6-годинного майстер-класу на конференції SECR в Москві. Сподіваюся, інформування дозволить остаточно переконати наших чудових QA-фахівців у необхідності «свідомої» планової роботи над тестовим оточенням.

— На які етапи ви можете розділити створення тестового оточення? Що ви однозначно закладаєте при виборі способів і інструментів для тестування? Скільки часу займає процес налаштування зараз і скільки займав в недавньому минулому?

Чудові питання. Так і хочеться відповісти за КВН-овски: «Все як завжди залежить від усього!» :) Щоб розкрити ці теми, потрібно, як мінімум, кілька доповідей, а краще — майстер клас. Не хочу давати простий некоректний відповідь на складне і важливе питання. Давайте детально проговоримо їх в рамках окремого поста, частина відповідей можна знайти в рамках моїх виступів.

Сьогодні скажу лише таке: ROI, завжди і у всьому потрібно керуватися ROI, розробляти свій мікро Calculator під специфіку конкретного проекту / завдання і використовувати його спільно з stakeholder-му. Якщо навіть в області права і моральних компенсацій, людство не змогло виробити кращого універсального мірила, ніж гроші, нам точно не варто намагатися вигадати щось своє. Будь-яке рішення має бути виваженим, матеріально прорахованим, в тому числі вибір підходу до організації тестового оточення, вибір способів та інструментів тестування.

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

— Підготовка конфіги і тестових даних — основа, або кожен окремий випадок — це «чистий аркуш», який доводиться переписувати з нуля?

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

Безумовно, повинен бути набір готових, специфічних для компанії або бізнес-домену в рамках компанії еталонних віртуальних машин, «шаблонів» тестових даних, якихось спеціалізованих рішень, архітектур для автоматизації тестування з серії, якщо у нас Java stack, Web, Angular, додаток середнього розміру і з великою варіабельністю даних, то починати варто, виходячи з рішення 25.

У цьому сенсі дуже показова конференція ExTENT 2015. Саме такий підхід я разом з колегами намагався реалізувати на минулому місці роботи, організував сьогодні в DPI.Solutions і беру посильну участь у систематизації в рамках EPAM. Великі компанії, на мій суб'єктивний погляд, переросли ситуацію нестачі напрацювань і готових рішень, скоріше, ми бачимо інверсію, проблема не недоліку, а надлишку «експертизи з полиці», коли потрібно поліпшити мета-опис і систему ранжирування, інакше в море готових можливостей можна потонути.

— За ці кілька років активно розвивався пласт готових з коробки рішень для побудови ізольованих середовищ тестування. Наскільки вони гарні? Чи можна серед них виділити найбільш цікаві, зручні рішення? Як раніше справлялися без цього?

На жаль, я не зможу детально відповісти на це питання, особисто не займався порівняльним аналізом подібних інструментів. Як робили раніше?.. Це класичний еволюційний питання. А як наші батьки справлялися без пральних машин, мікрохвильових печей? Я не кажу про мобільних телефонах, комп'ютерах, в інтернеті. Справлялися! Але до хорошого звикаєш дуууже швидко.

— Ви використовуєте технологію Docker? У порівнянні, наприклад, з OpenVZ — був зроблений крок у бік спрощення використання? Розкажіть про ваш досвід. До «Докера» були зручні рішення подібного рівня або вони є і зараз? З якими обмеженнями Докера ви стикаєтеся і як їх вирішуєте?

Так, звичайно, Docker — чудовий інструмент. Невисокий поріг входження, дуже зручний у використанні, з величезною кількістю готових конфігурацій, усе це вигідно відрізняє його від OpenVZ та подібних інструментів. Docker зробив великий крок у бік спрощення.

Зручний UI, дуже простий лаконічний набір команд для вирішення більшості завдань, мета-опис «машини» в одному файлі, ієрархічність, оптимізація трафіку при скачуванні і дискового простору при зберіганні. Море плюсів. Мінуси, звичайно, теж є, не буває ліків без побічних ефектів. Не все так райдужно при спробах серйозного масштабування, проблеми зворотної сумісності API, внаслідок швидкого зростання, а також безліч низькорівневих специфічних проблемок, для рішення кожної з яких є деякі рекомендації, але я недостатньо компетентний, щоб формулювати великий список best practices.

— Існує серйозна проблема — це відмінності в залозі на тестових та прод-середовищах. Виникає безліч питань, як організаційних, так і технічних. Які ви бачите шляхи вирішення при різношерстих програмно-апаратних засобах у тестовій і прод-середовищі? Як ви ставитеся до повної симуляції запуску програм в середовищі? Повинне тестування включати обов'язкову емуляцію апаратної та мережевої інфраструктури? Які рішення є в даній галузі, або зараз дійсно настав час, коли апаратна архітектура жодним чином не впливає на виконання?

На мій погляд, апаратна архітектура і проблеми відмінності тестового і реального оточення поступово відходять на другий план. Сьогодні як промислового, так і test-овий env все частіше перебуває в хмарах, а отже, завдяки додатковим прошаркам віртуалізації і сервісів проблема нівелюється.

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

Сьогодні в контракті прописується оточення в хмарах, для отримання фінальних результатів тестування продуктивності ми надаємо результати на певному оточенні і інструмент візуалізації тренда, проблем з прийомом робіт не виникає. Замовник при необхідності запускає тести на новому хмарному оточенні і працює з трендом. Процес підписання контракту і приймання виконаних робіт істотно спростився. На мій погляд, нехай приватна, але дуже наочна ілюстрація.

— Підводячи невеликий підсумок нашої розмови, підкажіть, будь ласка, які технології / продукти за останні десять років ви б назвали проривними в галузі тестування та створення тестового оточення? Можна однозначно сказати, що відбулася еволюція інструментарію?

Дозволю собі відповісти питанням на питання: Еволюція чи революція? Еволюцію не зупинити, прогрес можна затримати або навіть змусити відступити за деякими «фронтах», але зупинити в цілому – ніколи! Це фізично неможливо! Якщо серйозно, без ліричних відступів або наступів, ми бачимо черговий виток діалектичної спіралі.

Ідеї 60-х в абсолютно новій якості реалізуються тут і зараз. Навіть не знаю, як охарактеризувати цей процес, скажімо, «Еволюційна революція». Віртуалізація, контейнеризація, вихід в «хмари», поява одночасно мінімалістичний і універсальних засобів автоматизації, начебто Selenium-а й, завдяки початковій гнучкості архітектурних рішень, поширення на «суміжні» області, такі як мобільний автоматизація та автоматизація Desktop-них програм.

– Спасибі за ваші відповіді.




Придбати квитки на конференцію можна вже зараз, реєстрація відкрита.

Крім доповідей Ігоря («Такі ж, але краще») і Антона («Хорошие» і «погані» варіанти паралельного запуску Selenium WebDriver тестів) радимо вам звернути увагу і на ці:

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

0 коментарів

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