Март 27

Знайомтесь, TestOps!

Стаття написана в співавторстві з Михайлом Чубом.

Останні три роки я працюю тест-лідом/тест-автоматизатором. За останній рік майже щодня пишу код, але не написав жодного автотесту. Як так вийшло? Я спробував проаналізувати свої активності й дійшов висновку, що чимало з того, що роблю, виходить за межі моїх ролей і не має назви. Я налаштовую інфраструктуру, займаюся моніторингом, тестую мікросервіси, запускаючи їх локально в докері, — типові завдання DevOps’а, окрім власне розробки. Я дуже захотів дати означення тому, що саме роблю, і відразу ж подумав — гей, це ж DevOps, тільки з тестуванням замість розробки — TestOps! І відразу ж виникла ціла низка запитань:

А чи є такий термін?
Чи є в цього терміна означення?
Це роль чи підхід до роботи?

Ми з колегою вирішили підійти до запитань системно:

Спочатку повторити, що таке DevOps.
З’ясувати, що в Інтернеті пишуть про TestOps і сформулювати наше бачення.
Спробувати спрогнозувати навички й технології, що повинні опанувати тестувальники для продуктивної роботи в наступні 5 років.

Що таке DevOps

Термін DevOps (Development Operations) з’явився як методологія розробки програмного забезпечення, що рекомендує тісну взаємодію розробників з IT-спеціалістами (наприклад, системними й мережевими адміністраторами) для зменшення часу розробки та поліпшення якості (що нам видається трохи курйозним, адже це мета не тільки DevOps, а й усіх, хто причетний до розробки ПЗ незалежно від ролі). Наприклад, розробник може не тільки код писати, а ще й надати зрозумілу інструкцію: як програму на сервері запускати, де логи дивитися й конфіги налаштовувати. А Operations-інженер може не лише сервер налаштувати, а ще й можливі помилки продебажити.

Ну й звісно, як нам нагадує agile manifest: люди і взаємодія важливіші за процеси та інструменти — не розумієш, як зробити — піди й спитай у колеги, адже мета в усіх одна.

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

Чому Dev-Test-Ops

Може виникнути логічне запитання: чи не зробить розробку складною одна/кілька універсальних ролей? Розподіл праці — доведено ефективний спосіб роботи. Тут варто проаналізувати сучасні тенденції розробки й експлуатації ПЗ. Дуже рекомендуємо прочитати статтю Future of DevOps, а поки що ключові тези.

Навіть за останні 10 років інфраструктурні рішення пройшли довгий шлях.

Від фізичних серверів, на які все, від ОС до застосунків потрібно було ставити власноруч і підтримувати до поступового делегування інфраструктурних речей провайдерові. Навіщо купувати сервер, якщо можна орендувати? Навіщо встановлювати ОС і сервіси типу пошти, якщо можна купити готові рішення? Навіщо взагалі писати повноцінний застосунок, якщо можна написати лише бізнес-логіку у формі лямбда-функцій, — а про все інше подбають за вас? Така стрімка еволюція породила чимало термінів й абревіатур, як-от: IaaS, PaaS, SaaS, Caas тощо, які без пошуковика й не розбереш.

Очевидно, що тенденції ведуть до спрощення процесу розробки й зменшення часу виходу в продакшен. До того ж інфраструктура стає дедалі складнішою, гнучкості досягають великою кількістю конфігураційних файлів й іноді стає дуже важко з’ясовувати причини багів, що зрештою знаходять користувачі. І саме тепер цьому місту потрібен герой, який знає не лише принципи тестування й опанував популярний на ринку стек технологій (БД, вебсервіси, мова програмування), а ще й розуміє, як усе влаштовано.

Що таке TestOps

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

Розширення ролі тестера-автоматизатора, що дає нові обов’язки з налаштування й підтримки середовища запуску автотестів (якщо вам потрібні автотести, самі запакуйте їх у Doker, запустіть ПЗ, що тестується, виконайте тести, зберіть результати та надайте звіт).
Розширення типів тестування ПЗ через обов’язкове тестування навантаження й надійності, розширення ролі тестувальника, що дає змогу займатися моніторингом усіх систем у тестових оточеннях і в продакшені.
Методологія, що рекомендує проводити тестування тільки в продакшені, щоб заощаджувати ресурси (менше середовищ) і час на створення тестових даних та приділяти більше часу аналізу метрик з моніторингу та внесення змін не для всіх користувачів одразу, а для невеликих тестових груп.
Останнє звучить майже дико для мене, але я знаю успішні продукти, в яких процес тестування налаштовано саме так!

Ураховуючи написане вище, ми спробуємо сформулювати своє означення:

TestOps — це методологія, що рекомендує тісну взаємодію QA, Dev, Ops для зменшення видатків на розробку й забезпечення якості, ураховує сучасні тенденції розробки, підтримки ПЗ і вказує головні активності, як-от:

підготовка тестових даних;
функціональне E2E-тестування, зокрема:
- інтеграційне;
- транзакційне;
- автоматизація;
тестування навантаження мікросервісів і всієї системи;
тестування надійності:
- у разі відмови сервісів;
- за асинхронних сценаріїв роботи;
безпека;
налаштування CI/CD.

Далі вважаємо за потрібне пояснити вибрані пріоритетні напрями тестування.

Тестові дані

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

Уявімо, що ваша команда розробляє проєкт, який складається з кількох сервісів зі своїми БД й інтегрується ще з кількома сторонніми. Якщо об’єкти першого сервісу мають посилання на id об’єктів другого сервісу й сторонніх систем, то саме такі об’єкти й слід створювати. Ба більше, підготовка даних — це не лише про створення. Якщо протягом тесту повинні бути створені унікальні дані, треба впевнитися, що їх заздалегідь стерто з усіх сервісів, де вони мають бути.

Функціональне тестування

За нашою статистикою, 80% усіх тестів, що їх роблять тестувальники — функціональні. На нашу думку, така цифра досить справедлива й навряд чи зміниться найближчим часом. Однак акцент трохи зміщується з тестування функцій окремих систем/сервісів до тестування всієї системи загалом. І тут тестування повинно будуватися на класичній схемі:

Компонентне — кожна система/сервіс окремо. Сюди ж можна додати тестування контрактів.
Інтеграційне — взаємодія кількох сервісів. Тут нам уже знадобиться підготовлений заздалегідь набір узгоджених даних.
Системне — E2E-тестування, перевірка, що вся система загалом виконує сподівані функції й обробляє сподівані помилки.

На компонентному й інтеграційному рівні дуже ефективною є автоматизація тестування завдяки unit-тестам і тестам вебсервісів.

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

На системному рівні обов’язково мають бути протестовані основні сценарії використання системи, мануально чи за допомоги автоматизованих UI-тестів.

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

Тестування навантаження й надійності

І тут ми наближаємося до потенційної ситуації, коли поведінка системи (виконання нею своїх функцій) змінюється під навантаженням. Оскільки мікросервіси починають використовувати задля масштабованості, логічним кроком буде завжди проводити тестування навантаження незалежно від наявності відповідних вимог. Цілями тестування навантаження можуть бути як окремі мікросервіси, так і вся система загалом для виявлення вузьких місць (bottlenecks). Мета-мінімум — проаналізувати продуктивність системи й надати інформацію команді та замовникові; мета-максимум — спрогнозувати можливості системи залежно від масштабу й запобігти багам, пов’язаним з високим навантаженням.

А тепер перейдімо до надійності, що тісно переплітається з ефективністю системи. Наші цілі:

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

Останній пункт — типова проблема, з якою може стикнутися тестувальник. За великих об’ємів даних і навантаженні асинхронних операцій, наприклад, процес, що запускається раз на годину, може не встигнути виконатися. У такому разі варто впевнитися, що дані не втрачаються або не обробляються повторно.

Окремо варто згадати, що для тестування надійності розподілених і мікросервісних систем є своя власна методологія та набір інструментів — Chaos Engineering.

Безпека

Що складніша система, то більше потенційних уразливих місць. Якщо ми говоримо про docker, то кожен мікросервіс — окрема операційна система зі своїм ПЗ. Мінімум, що можна зробити — перевірити походження images, використані версії ПЗ і фреймворків та навіть користувача, від якого запускають сервіси (експерти стверджують, що запускати все від root — погана ідея). Почитати більше можна за посиланнями: безпека для Docker, проблем безпеки Docker..

Налаштування CI/CD

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

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

Навички TestOps’а

Нарешті можна поговорити про потрібні в наш час знання й навички, щоб відповідати потенційній ролі TestOps:

Бази даних — дані наше все! Уміння працювати з SQL і NoSQL.
Мінімальні знання з сучасних підходів і протоколів обміну даними: REST, SOAP, JMS, WebSocket.
Знання форматів даних: XML, JSON, CSV.
Навички роботи з Unix-системами.
Навички написання скриптів в ОС: bash, PowerShell.
Знання з влаштування ОС: як працюють програми, що таке сервіс тощо.
Навички програмування: Python, JS. Перевагу віддають скриптовим мовам, бо частіше буває важливо написати допоміжний скрипт, ніж створити програму.
Навички тестування навантаження. Мало знати інструменти типу JMeter, Locust, Gatling — треба розуміти, які метрики потрібно збирати, як і за яких умов.
Навички автоматизації. І тут варто зазначити, що цей термін повинен мати ширше значення, ніж просто написання автоматизованих тестів, а будь-яку автоматизацію роботи команди.
Навички налаштування CI/CD (Jenkins, TeamCity).

Післямова

Ця стаття — не що інше, як змога поінформованого осмислення не до кінця сформованої в професійній спільноті концепції, або ж, інакше кажучи, спроба цю концепцію доробити до стану цілісної й зрозумілої принаймні для самих себе :) На щастя, наш робочий і позаробочий простір сформовано дружнім до презентацій та обговорення ідей чином, тож ми вже мали змогу отримати кілька суттєвих коментарів до наведеного в статті означення TestOps і сподіваємося на обговорення надалі з шановною спільнотою!

А ще ми з однодумцями ведемо українськомовний телеграм-канал про тестування й намагаємося регулярно публікувати цікаві матеріали. Підписуйтеся!