×Закрыть

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

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

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

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

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

  1. Спочатку повторити, що таке DevOps.
  2. З’ясувати, що в Інтернеті пишуть про TestOps і сформулювати наше бачення.
  3. Спробувати спрогнозувати навички й технології, що повинні опанувати тестувальники для продуктивної роботи в наступні 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’ам

Одна з головних умов дотримання методології TestOps — бути на вістрі сучасних технологій. Тому треба регулярно:

  1. Оновлювати свої знання (коли ви останнього разу ISTQB відкривали?).
  2. Читати про нові підходи в розробці й тестування ПЗ. Те, про що сьогодні лише говорять, завтра ви вже можете тестувати.
  3. Відвідувати мітапи й конференції — місця концентрації ідей, що можуть суттєво збагатити ваші уявлення про тестування й суміжні дисципліни.
  4. Ділитися своїми знаннями з колегами на конференціях, у статтях — найважчий пункт, бо кожен думає, що не робить нічого особливого, про що б не знали інші — це не так! Кожен досвід унікальний, і кожна проблема завжди має низку розв’язків, і, можливо, саме ваш оптимальний ;)

Післямова

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

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

Корисні посилання

LinkedIn

51 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

"

коли ви останнього разу ISTQB відкривали?

" — цікаво чи автори ISTQB хоча б коли небудь лізли до питань інфраструктури і тд ))) Я , наприклад, спалив ту книжку після того, як прочитав)))

автори ISTQB хоча б коли небудь лізли до питань інфраструктури

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

Доречі, чимось подібним на TestOps і займався на попередньому місці роботи. Робив частину роботи за девопсів, потім засилав їм на перевірку, і їм добре, бо лише перевірити, і мені, бо я собі сам інфраструктуру зробив, і не чекаю поки у них «вікно» для мене з"явиться, і старі адмінські знання освіжаю.

Вы никогда не думали о том, что Dev в термине DevOps подразумивает разработку п.о.
которая включает в себя:
1. анализ,
2. формирование требований
3. постановка задач
4. реализация
5. тестирование реализации на соответсвие поставленным требованиям
6. развертывание (иногда)
а Ops подразумевает эксплуатацию, которая включает
1. развертывание (иногда)
2. поддержка
3. мониторинг
4. сбор отзывов
и вот когда на DevOps смотришь с такой стороны, то создается впечталение, что люди которые пытаются внедрить всякие там термины, типа DevSecOps, не понимают о чем говорят.

В стародавні часи термін розробка включав в себе аналіз, дизайн, розробку, тестування, розгортання та підтримку (а ще може принтер заправити і ноут куму вибрати). Нащо в такому випадку взагалі слова тестер, девопс, адмін коли є #тижпрограміст? :)

Світ стає складніший, підходи до роботи теж. Чому б не давати назву новому?

Це хороше питання «чи прийшов час ввести новий термін» і «що дасть його введення». Про нього можна поговорити окремо. Але, Олексій, я б тут не відповідав питанням на питання. Це не дослідницький шлях. Ти підімаєш тему про новий термін. Так уже давай, відповідай на критику в деталях:)

DevOPS — це дійсно методологія, навіть «культура». Цей термін з’явився не просто так. А щоб принести щось нове в старе. Він НЕ з’явився щоб дати назву адмінам які почали налаштовувати частину інфраструктури для девів.

Він з’явився тому що раніше стадія продакт лайф сайклу — підтримка/мейнтененс/оперейшенс — жила окремою тусою. По своїм законам.

А потім деякі компанії почали практикувати певні практики — до речі QA практики — практики що не завжди напряму відносяться до тестування (що є QС — контролем якості). Такі практики як gradual roll out, feature toggle та інші які стали дуже важливі для Continuous Delivery i Deployment. Виявилось що для того щоб можна було в будь-який момент тицьнути на кнопку і запустити версію продукту в прод і передати відповідальність команді оперейшенс — потрібно почати слідувати певним практикам на боці розробки, підлаштувати білд систему і пайплайн. По факту поміняти процес розробки — для легшої роботи оперейшенс. А оперейшенсам підлаштувати свій бік, щоб зрозуміти як жити з цим усім новим, як швидко по гарячому робити в проді ролбеки, як вимикати по гарячому фічі, в яких виявились баги. Як моніторити. Виявилось що взаємодія між командою розробки та командою оперейшенс стала ще більш важливою, назбирались шаблони й кращі практики в цьому контексті. Так і виникла саме методологія нова і дали їй назву DevOps.

А от навіщо вводити TestOps поки не зовсім ясно...

Ще раз, у слові DevOps — dev — це команда розробки, а не програмісти. Вже давно у світі еджайлу — тестери є частиною команди розробки. Скрізь де по серйозному впроваджують девопс — дуже близько говорять про автоматизацію, про тестування, про роботу з вимогами. Це комплексний підхід. В DevOPS вже і доволі давно входить набір практик і шаблонів, які вже включають і тестерів, і бізнес-аналітиків/продакт-овнерів, і девів. Нічого не змінилось, це все передбачено, і описано.

Навіщо ж тоді вводити новий термін TestOps?

Хоча стоп... мабуть, таки треба... Заради консистентності...
Ну чо... Як у нас завжди буває...

Прийшов Agile, почав говорити про відповідальність за якість всією командою, про QA практики ... Ніхто цього не зрозумів, нічого не змінилось. Але наших тестерів які й далі продовжували займатись суто QC — почали тепер називати QA Engineer.

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

То може так само давайте і новий термін введемо для тестеро-автоматизаторів-адмінів? А може ще давайте девелоперів які, обоги, поки ніхто не чує — «пишуть авто тести» — почнему називати TestDev-ами? хм... чи може краще DevTest-ами? як краще звучить? :)

Те що науково технічний прогрес росте, і інструменти стали потужніші, але й складніші, і тепер оперейшенсам чи адмінам — треба трохи більш впахувати — хіба заслуговує на нову назву? Може давайте роботу робити, а не вигадувати 100500 термінів, яку більшість все одно не розуміє і перекручує як з тим же DevOps. Як з QA:)

А то у нас люблять на себе погонів навішати. Ні, не тестер який задумується над більш ефективним виконанням своєї роботи через автоматизацію своїх рутинних дій. А — QA Automation, йоу. Написав фреймворк (в той час коли можна додати задачу в беклог, добре подумати над вимогами, дизайном — і потім деви це втричі швидше зроблять) — о, тепер я SDET. І так пішло поїхало.

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

Треба «контролювати якість? — тобто по факту коли щось зроблене, перевірити чи воно відповідає поставленим наперед вимогам (верифікація) чи адекватним потребам його користувачів (валідація)» — і не важливо де це робиться, на якій стадії. Для цього вже давно є термін — QC, Testing. У всіх класичних підручниках написано, що тестування застосовується до всіх стадій починаючи з формування вимог.

От в тому ж еджайлі є така хороша QA-практика (практика що в профілактичному стилі забезпечує якість наперед, а не контролює те що вже нафакапили) — 3 Amigos Meeting — це коли на грумінгу чи пре-пленінгу — збираються і деви і тестери і продакт овнер чи БА — і все разом обговорюють вимоги, прояснюють їй. В деяких командах — коли багато такої роботи, ПО — працює на більш високому рівні в плані формування бізнес-вимог, а деви разом з тестерами вже розбивають їх на аксептенс критерії. Не виділяють же після цього нову роль BaTestDev :)

Хто зна, може і є сенс в нових ролях... Нових термінах. От лиш мені здається, що нам би розібратись з тими термінами що вже є:) Навчитись всім гуртом відповідати за якість. Думати перед тим як починати щось робити, а не після. Зробивши — поглянути на результат, перед тим як передавати іншим в роботу далі — о так, не тільки тестери в команді мають «перевірками займатись». Взявши впроваджувати певну методологію типу DevOps — розібратись в деталях що воно таке в повному обсязі, комплексно. Там ще дуже багато цікавого чого. Якщо робити все як задумано адаптуючись до контексту звісно, то і навряд будуть з’являтись нові «качконоси». Хех, та ні, звісно будуть. Але вони й так завжди з’являються тому що не існує чогось один в один схожого на те що описується в книжках. Я більше про те — що в кожній команді будуть якісь свої версії універсальних солдатів і спец-ролей. Але навряд всіх вийде під одну планку підрівняти.

На мою думку, зараз же з’являється «нова планка» більше через те що народ масово не розуміє ні що таке QA ні що таке Agile ні що таке DevOps. А ще не має досвіду як це все впроваджувати. І виникають тренди масового однакового непорозуміння) На таке меми треба нові вводити, а не терміни/ролі.

Ох, дякую за розгорнутий коментар, намагатимусь дати короткі відповіді!

DevOPS — це дійсно методологія, навіть «культура». Цей термін з’явився не просто так. А щоб принести щось нове в старе. Він НЕ з’явився щоб дати назву адмінам які почали налаштовувати частину інфраструктури для девів.

так і ми пишемо не про те, що якщо тестера вкусить радіоактивний девопс, той стане тестопсом — а про розширення фокусу: кращу взаємодію людей для досягнення результату, надання більшої уваги нефункціональним тестам — бути дійсно QA а не QC

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

Можливо дивлюсь суб’єктивно, бо цікавлюсь цим напрямком — зараз кожна 3 тема доповіді на конференціях і статті на технічних сайтах — як проводити тестування мікросервісів — власне ті самі кращі практики ;) Багато хто вже робить тестопс, просто його ЩЕ так не називає

Ще раз, у слові DevOps — dev — це команда розробки, а не програмісти. Вже давно у світі еджайлу — тестери є частиною команди розробки. Скрізь де по серйозному впроваджують девопс — дуже близько говорять про автоматизацію, про тестування, про роботу з вимогами. Це комплексний підхід. В DevOPS вже і доволі давно входить набір практик і шаблонів, які вже включають і тестерів, і бізнес-аналітиків/продакт-овнерів, і девів. Нічого не змінилось, це все передбачено, і описано.

В коментарях вище вже писали, що DEV включає в себе все, від аналізу до SEO, з чим я не згоден — команда може бути супер гнучкою, але аналітики краще аналізують, тестери — тестують, розробники — розроблюють, менеджери — менеджать.
І девопс, за визначенням, все ж таки в першу чергу саме про розробку і експлуатацію, все інше є плюсом, але за кадром.

Прийшов Agile, почав говорити про відповідальність за якість всією командою, про QA практики ... Ніхто цього не зрозумів, нічого не змінилось. Але наших тестерів які й далі продовжували займатись суто QC — почали тепер називати QA Engineer.
Далі прийшов DevOps. Те ж саме... Взяли адмінів, яких вже були припахали дженкінси-пере-дженкінси налаштовувати й перейменували їх в DevOps. Без розуміння що воно таке. Без розуміння того, що це взагалі було про підходи, про колаборацію, а не про нову роль.

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

То може так само давайте і новий термін введемо для тестеро-автоматизаторів-адмінів? А може ще давайте девелоперів які, обоги, поки ніхто не чує — «пишуть авто тести» — почнему називати TestDev-ами? хм... чи може краще DevTest-ами? як краще звучить? :)

SDET. Все вже придумали до нас

Те що науково технічний прогрес росте, і інструменти стали потужніші, але й складніші, і тепер оперейшенсам чи адмінам — треба трохи більш впахувати — хіба заслуговує на нову назву? Може давайте роботу робити, а не вигадувати 100500 термінів, яку більшість все одно не розуміє і перекручує як з тим же DevOps. Як з QA:)

Ми в статті говорили про тест опс не як про роль — а як про підхід.
Але навіть назва ролі має переваги — коли ви читаєте резюме, і бачиш там розробник, спитаєш, на чому пишеш, які технології знаєш? Бачиш ДевОпс — і розуміш, що людина вміє умовний дженкінс налаштувати і код написати. Тобто для кожної ролі в нас вже є сформований стереотипний список очікувань.

А то у нас люблять на себе погонів навішати

Дійсно так. Теж не люблю, коли підпис в пошті в 4 рази більший за повідомлення. Але багато хто робить і любить — головне, щоб всі були задоволені

Треба «контролювати якість? — тобто по факту коли щось зроблене, перевірити чи воно відповідає поставленим наперед вимогам (верифікація) чи адекватним потребам його користувачів (валідація)» — і не важливо де це робиться, на якій стадії. Для цього вже давно є термін — QC, Testing. У всіх класичних підручниках написано, що тестування застосовується до всіх стадій починаючи з формування вимог.

дякую, кеп! підручники я теж читав. Не зрозумів, до чого саме ця критика. Тому прошу додаткового роз’яснення

Хто зна, може і є сенс в нових ролях... Нових термінах. От лиш мені здається, що нам би розібратись з тими термінами що вже є:) Навчитись всім гуртом відповідати за якість. Думати перед тим як починати щось робити, а не після.

Так ми ж з цього почали! Я написав, що є, а ти мені опонував! Будь послідовнішим! Я бачу, що IT розвивається швидко, поки будеш розбиратись з термінами, що є, вони застаріють (десь у віддалені чую, як плачуть спеціалісти з блокчейну)
Гуртом відповідати про якість — так і я про це. і DevOps, і TestOps, і Agile і навіть здоровий глузд

Взявши впроваджувати певну методологію типу DevOps — розібратись в деталях що воно таке в повному обсязі, комплексно.

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

На мою думку, зараз же з’являється «нова планка» більше через те що народ масово не розуміє ні що таке QA ні що таке Agile ні що таке DevOps. А ще не має досвіду як це все впроваджувати. І виникають тренди масового однакового непорозуміння) На таке меми треба нові вводити, а не терміни/ролі.

повторюсь — від того, що частина IT-спільноти (впевнений, менша) не розуміє, навіщо потрібні методології, не означає, що не варто про них говорити. Бо дійсно виходить мем — не жили добре, не варто я починати.

і ще про впровадження термінів — отримав листа про QA Fest 2020 — один з актуальних напрямків -Test Automation & TestOps. Ми з колегами саме на це й розраховували — щоб про тест опс почали говорити і всією спільнотою ділитись кращими практиками

Спецом доречі писав пост так щоб не сильно до чогось опонувати. А просто висловити думку. І зупинитись на цьому. Ти назбирав своїх аргументів на те що потрібен новий термін. Я описав більше коментом «статтю відповідь» що мені здається що ні. Весь мій посил якщо коротко зводиться до того, що все що тобою описано входить в роль тестувальника та його компаньйонів по команді, все це вже давно описано в практиках DevOps і Agile. Про це написані й книжки, це входить в програму як просто навчальних тренінгів так і практичних програм по впровадженню цього на проектах. Це коли приходить досвідчений консультант і допомагає команді побудувати DevOps/Agile не по книжкам, а з точки зору свого досвіду. На проектах з якими я зустрічався і де команди займалась всім описаним у статті вище — проблем з розподіленням ролей, і потреби в новому терміні не було. Все вже описувалась в контексті DevOps/Agile. Але світ динамічний і не однаковий, все в контексті. Судячи з усього у твоєму досвіді певна потреба вирішення якихось проблем через введення нового терміну є :) Ну чи не «проблема» а щось інше, що ти новим терміном хочеш «вирішити». Ну вперед:)

Уточню лиш пару моментів, де судячи з усього сталось непорозуміння.

дякую, кеп! підручники я теж читав. Не зрозумів, до чого саме ця критика. Тому прошу додаткового роз’яснення

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

SDET. Все вже придумали до нас

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

Так що згадувати SDET — тут недоречно.
Ну раз вже про нього згадали. SDET — це термін для девелоперів виділених під задачі технологічної організації автоматизації. Цей термін був введений наскільки я знаю гуглом. По суті це інженери які «пишуть фреймворки», технічно забезпечують команди інструментами для автоматизації. Так ця ідея і дійшла до нас в Європу. І в СНГ. Тут все ще так його і юзають. От тільки в гуглі це не взлетіло, і SDET перетворились на «окремі команди інженерів що пишуть автотести (а не фреймворки) замість девелоперів». Тому зараз дехто вважає цей термін скомпрометованим... Ну це так) Для справки.

P.S.
Олексій, давай на цьому зупинятись. Дискусії тут не потрібно, вже виклали наші карти на стіл. Думаю достаньо)

> Все що описано в статті, як на мою думку вже включено і в наявні на ринку ролі і в практики і шаблони.

Як я вже згадав, це просто моя думка. Ймовірно суб’єктивна. В цілому про те що наявних на ринку термінів/ролей/методологій за адекватного їх розуміння — достатньо для успішного SD. Там де я бачив «не достатньо» — там просто люди не розуміли що таке DevOps і Agile, чи не знали як його правильно впровадити... З іншого боку... Можливо таке «масове непорозуміння» якраз і говорить про те що «наявні на ринку терміни/методології» — недосконалі. І варто вводити/формувати нові методології/терміни. Судячи з мого досвіду — це не так. Проблеми не в наявних методологіях/термінах, а в іншому. Можливо в чомусь ще більш базовому... І можливо в чомусь, де таки і нові терміни знадобляться (більш базові, на мою думку не в дусі TestOps). Але це вже окрема історія. Окреме дослідження. Я б його виходить повів в інший бік. Ти його повів в бік TestOps. Пробуючи замінити те що на мою думку вже описане і так в DevOps/Agile. Ну успіхів) В тому числі і з конференціями які згадуєш в наступному коменті;) Там якраз люблять новімодні терміни і хайпові теми.

То есть вы просто переименовали senior qa automation в testops? 😅 шииик

Якщо узагальнити, то в цілому жодні назви не потрібні — треба просто добре робити свою роботу ;)

... а senior dev в devops ;)
люди ті ж самі, робота та ж сама — нові підходи, нові технології

+ML, я вже й таке чув :)

TestOps очень затребован в финтеке, только там он сталкивается с реальными задачами. Например — тестирование работы с банковским гейтом при слабой документации. В отечественных (да и не только) банках, это типичная проблема:
Документация устарела, а новой нет и не будет, потому что требования должно быть уровня НБУ с конскими штрафами
Апдейт API идет в любое время и часто без предупреждений
Тут мы еще вам фискальный аппарат принесли с секретным протоколом, который не работает через файрвол но открыть полностью не дают ИБ: Будь добр потестируй и найди, что ему нужно открыть

Тут мы еще вам фискальный аппарат принесли с секретным протоколом, который не работает через файрвол но открыть полностью не дают ИБ: Будь добр потестируй и найди, что ему нужно открыть

Все правильно делают. Периметр должен быть защищен.

Ага. Разработчики фискального аппарата требуют полностью открытый трафик, а ИБ — полностью закрытый. Вот TestOps меж двух огней...

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

А ІБ відповідає — це не секюрно, шукайте інший спосіб. Як би все було так просто...

Для начала еще определи те порты, там же секретный протокол — нуль информации

Я просто в тестування прийшов з IT безпеки, а в безпеку з адміна мереж і компів, тому такі питання давно не стоять.

Безопасность бывает разных уровней, до этого видно ты не доходил

та не сказав б ... ніхто нікуда доступу не хоче в цілях сесуріті давати на таких проектах QA інженерам...)

стаття кльова, додав би, що варто також людям з тестінгу, більше залучатись у тестування яке є нижче ніж E2E : unit, integration, etc

— швидший фідбек
— швидші та стабільніші тести
— розуміти та покращувати якість на проект

А если отойти от теории в реальный мир?
В смысле кто видел в наших реалиях именно integration тесты? Чем они отличаются от e2e?
Чем что даст тестировщикам чтение unit?
Что значит более быстрые и стабильные? Как тестировщики повлияют на это в unit/integration?
Тот же вопрос про улучшение проекта.

именно integration тесты?

так, бачив

Чем они отличаются от e2e?

бувають різного рівня інтеграції. десь це декілька класів + БД, десь це окремий мікросервіс з залежностями, десь це декілька сервісів.

Как тестировщики повлияют на это в unit/integration?

тестувальникам, як мінімум потрібно орієнтуватись, які тести пишуть девелопери

А чому відходити? Чому б теорію не вносити в реальний світ?
Звісно якщо тобі не дають код розробників бо тестери та автоматчікі сидять в окремій кімнаті, окремого департамнету, окремої компанії, країни, світу, реальності то так. Тому погоджуюсь, що не вийде приносити нормально профіту
Але якщо дійсно привнести в команду «теоретичні» підходи та практики — то щось з цього може вийти
Атвічаю, я спробував і мені зайшло! Назад в іну реальність повертатись не хо!

Звісно якщо тобі не дають код розробників бо тестери та автоматчікі сидять в окремій кімнаті,

У вас в конторе до сих пор на сникернете сидят? ) попробуйте гит )

це що таке? ти шо, гіт то космос, всі на зіпах сидимо і на дискєтах

p.s. запитання не валідне для треда

Unit-тесты — инструмент разработчика, который при правильном применении позволят облегчить рефакторинг и не делать откровенных глупостей, которые обнаружатся при первой же попытке запустить приложение. Никому кроме самого разработчика результаты этих тестов не интересны. Если вам очень нужно сжечь ресурсы впустую, то посадите писать unit-тесты человека не писавшего код, который они тестируют.

повністю згідний. але варто мати уявлення які юніт тести є і який рівень покриття

Я теж хотів шось написати, але краще перепитаю, чи маєте ви на увазі перекласти написання юнітів на тестувальника?

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

я б сказав, від хороший тестер/тест менеджер має знати, для чого потрібні unit-тести та вимагати їх від команди розробки.
Можна навіть закріпити формально в тест плані як entry test criteria — тестуються лише білди, які мають покриття не менше N та успішно пройшли unit тести

Боюсь, коллега, что Вы категорически не правы. Все зависит от проекта и в 90% проектов крутящихся в стране — после того, как вы

потрібні unit-тести та вимагати їх від команди розробки.

и

Можна навіть закріпити формально в тест плані як entry test criteria — тестуються лише білди, які мають покриття не менше N та успішно пройшли unit тести

будите писать farewell letter

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

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

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

Вас же наймають як експерта не для того, щоб ви тримали думки при собі?

Є така думка, що мене наймають для того, щоб усе було за%:*сь на проекті, а не для того, щоб вислуховувати мої думки :)

ахах! так і я про що — щоб все було в проекті добре в ж щось робите? якщо вам скажуть каву носити замість розробки і тестування, ви скажете ок чи поцікавитесь, чому такий цінний ресурс (без іронії) використовують настільки неоптимально?

і повертаючись до попереднього питання — писати юніт тести — хороша практика, а вимагати писати юніт тести — прямий шлях до звільнення і взагалі фу. Чому?

будите писать farewell letter

якщо команда\компанія\проект не підпадають під ваші цінності то завжди є 2 шляхи : або ти впроваджуєш зміни, або ти міняєш компанію\проект\команду

ти впроваджуєш зміни

Я ж про це і писав ;)

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

Об интеграционных тестах я ничего не говорил (но тут, вообще, каждый подразумевает что-то свое). А вот про юнит интересно. То есть у вас юнит тесты пишут люди, которые сам код не писали? Кто обновляет тесты после изменений в коде? Что происходит в случае падения теста где-нибудь на CI, т.е. кто в первую очередь смотрит на его результаты, кто решает как его починить?

А я і не казав, що юніт/інтеграційні тести тільки я пишу, здебільшого я їх рев’юваю та раджу, що ще можна додати по перевірках.
Юніт та інтеграційні пишуть розробники ±98%, результам їх виконання ±98% часу приділяють розробники, я тільки іноді втручаюсь та їх відповідно всі знаю і краще розумію на якому рівні, що я маю та можу покривати

Тогда где вы видите противоречие тому, что я написал изначально?

Хм я не казав, що ви протиріччя кажете і я те саме роблю. Я не до кінця висловився — мав би доповнити, що знати те які є юніт й інтеграційні тести дуже корисно для QA процеса. Перепрошую

Подписаться на комментарии