Як забезпечити якість продукту в стартапі без виділеного QA

Привіт, мене звати Дмитро Гаранжа. Я Head of Engineering у стартапі Howly від венчур-білдера SKELAR. Ми створюємо маркетплейс онлайн-консультанцій, що поєднує кастомерів з певним питанням та експертів, які можуть із цим допомогти. Щодня ми вирішуємо більше тисячі запитань кастомерів.

У статті розгляну основні принципи та підходи, завдяки яким ми підтримуємо високу якість продукту в стартапі без виділеного QA.

Як і в більшості стартапів, для нас основною метрикою інженерної команди є швидкість доставки фіч на production. Ми пройшли шлях від найму та свідомої відмови від QA через погіршення показника Time to market (TTM). Водночас вдалося зберегти такий самий рівень якості продукту.

Трішки контексту

Howly 2,5 роки, консультації надаються в форматі чату на нашому сайті. Мобільних застосунків ми поки що не маємо.

У нас дві кросфункціональні скрам-команди сумарно в 10 інженерів. Основні ролі в команді: Product Owner, Team lead, FE/BE Tech lead, FE/BE Engineer, Designer, Content editor. Проєкт побудований на мікросервісній архітектурі, кожна команда відповідає за свій набір функціоналу.

Наш шлях до no-QA

Розробку MVP ми почали без виділеного QA. Через півроку після ускладнення продукту та збільшення кількості кастомерів відкрили позицію.

Ми шукали такого собі «супермена», який буде повністю відповідати за якість на проєкті:

  • базово розумітися в архітектурі, щоб локалізовувати баг до рівня сервісу;
  • ухвалювати рішення, на якому рівні автоматизовувати тест-кейс (Unit / Component / E2E);
  • верифікувати Unit&Component-тести, які пишуть розробники;
  • за потреби дописувати Component-тести самостійно;
  • писати E2E-тести на успішні критичні флоу.

Таких людей за півроку пошуків на ринку виявилося дуже мало, тому вирішили взяти Manual QA і донавчити її. На жаль, нам не пощастило: людина виявилася не настільки проактивною, як ми очікували, і навчання рухалося дуже повільно.

Додатково після найму ми стикнулися з двома основними проблемами:

  • зростанням TTM в середньому на плюс один день;
  • меншою залученістю розробників в забезпеченні якості.

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

Згідно з статистикою, наш середній cycle time складає приблизно чотири — п’ять днів, тому навіть один додатковий день затримки уповільнював нас. Як приклад, можна привести A/B-тести, яких ми запускаємо досить багато. У випадку зі стартом спринта в понеділок без QA ми маємо змогу запустити A/B-тест раніше, і за вихідні вже зібрати більше даних.

Тому ми ухвалили рішення далі забезпечувати якість без додаткового степу в процесі в вигляді окремої ролі.

Далі розглянемо за рахунок чого нам вдалося цього досягти.

Культура та цінності

Почнемо з того, яку культуру та цінності ми формуємо всередині інженерної команди.

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

Перша важлива цінність — це ownership. Якщо сформувати її одним реченням — це відповідальність за результат. В Netflix є чудова стаття на цю тему, де вони називають таких розробників Full cycle developers.

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

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

Крім зниження TTM і більш оперативного фіксу інцидентів на практиці такий підхід підвищує якість — він змушує розробників відповідальніше ставитися до покриття коду тестами та краще продумувати Edge-кейси та архітектуру.

T-shaped skills

Для реалізації ownership необхідні хоча б базові спеціалізовані знання з інших сфер.

У нашому випадку, наприклад, Back-end інженер має базове розуміння роботи та взаємодії з фронтендом, розробники самостійно вносять зміни в CI чи інфраструктуру.

Такий підхід значно пришвидшує комунікацію між спеціалістами в різних стеках.

Fail fast & cheap

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

Як приклад тут можна привести Canary releases — цей підхід дозволяє в проді вилити зміни на невелику кількість кастомерів, зібрати метрики і, якщо все добре, вилити зміни на 100%. Також тут сильно допомагають системи моніторингу, які ми розглянемо далі.

Learning from failure

The fastest way to succeed is to double your failure rate. Thomas Watson

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

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

Процеси

Перейдімо безпосередньо до процесу роботи над задачами.

Ключові речі, які б я в ньому виділив:

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

Наприклад, безпосередньо перед рефайментом у нас є зустріч, на якій синхронізуються всі Product Owners & техліди. На ній ми верхньорівнево проговорюємо тікети чи епіки, синхронізуємося в баченні, пріоритетах, архітектурі та попереднім естімейтам.

До рефайменту розробники досить добре готуються: попередньо залишаються коменти з питаннями, готують API взаємодії фронтенду з бекендом, описують структуру сутностей в БД і т. д. Так розробники набагато краще синхронізуються в баченні з Product Owner, і, відповідно, це дозволяє реалізувати вимоги коректно з першого разу без фіксів в майбутньому.

Built-in quality

Quality comes not from inspection, but from improvement of the production process. W. Edwards Deming

Найважливіший принцип, якого ми притримуємося в процесах, це підхід вбудованої якості в процеси. Він був сформований Едвардсом Демінгом і ліг в основу Lean-руху, який зародився в Японії на заводах Toyota.

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

Чому варто приділити цьому час? Усе дуже просто: так ви сильно пришвидшуєтесь.

Реалізується підхід вбудованої якості досить простими речами: ми почали з візуалізації нашого процесу розробки та невеликих чеклістів на 4-10 пунктів, про які важливо не забути на кожному етапі.

У нашому випадку є чіткі вимоги необхідних речей на кожному етапі. Наприклад, до рефайменту в тікеті, крім безпосередньо вимог, має бути прикріплений дизайн та теобхідний контент, описаний API та створені сабтаски. Під час розробки ми дотримуємося code conventions, які описані в Notion для кожного стеку. Так не витрачаємо час на code review і на суперечки про форматування коду.

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

94% of problems in business are systems driven and only 6% are people driven. W. Edwards Deming

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

Incident management

Важливо також структурувати роботу над помилками. Для кожного інциденту (тобто критичної проблеми на проді) після фіксу технічний лід заповнює шаблон post-mortem в Notion з аналізом причин та планом того, як уникнути цієї ситуації в майбутньому.

Рекомендую додавати в post-mortem:

  • timeline, починаючи з часу деплою зломаної версії, повідомлення про інцидент, деплой фіксу і т. д. Це в майбутньому дозволяє знайти вузькі місця в вашому процесі. Наприклад, після нашого аналізу ми зрозуміли, що вузьким місцем в нас є не час фіксу проблеми розробником, а довгий час її виявлення — тобто варто прикласти зусилля в сторону моніторингу і алертингу;
  • лінкувати issue з issue-трекера;
  • кількість кастомерів, яких ми заафектили;
  • root-cause. Тут добре допомагають такі техніки, як-от 5 why’s;
  • action items.

Оцінка ефективності змін у процесах

Для того, щоб оцінити ефективність змін у ваших процесах (додавання додатково етапу, відмові від QA etc), краще орієнтуватися на об’єктивні показники.

Для оцінки ефективності роботи інженерної команди і змін в процесах ми використовуємо DORA metrics. Це чотири метрики, дві з яких показують швидкість вашої роботи, дві інші — якість.

Для збору та візуалізації ми використовуємо Codacy Solutions.

Це корисно для порівняння ефективності вашої роботи в певні періоди роботи та розуміння загального тренду. Це не інструмент для щоденного використання менеджером — я б рекомендував один — три рази на квартал переглядати статистику. Звісно, це не скасовує інших інженерних метрик, наприклад velocity, cycle time etc.

Тестова стратегія

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

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

Для початку визначімося з термінологією:

  1. Unit-тест — тест першого методу класу в ізоляції. Усі залежності класу мокаються.
  2. Компонентний тест — тест взаємодії всіх компонентів одного сервісу. Зовнішні залежності мокаються, проте БД (Postgres, Redis etc) часто підіймаються в ізольованому контейнері. Для запуску компонентного тесту нам не потрібен повноцінний environment — достатньо декілька ізольованих контейнерів на CI. Можуть запускатися паралельно.
  3. API-тест — схожий на компонентний, проте зовнішні сервіси не мокаються. Нам потрібен тестовий environment.
  4. E2E-тест — тестують весь флоу, починаючи з фронтенду і закінчуючи third-party сервісами. Потрібен тестовий environment, виконуються довго.

З мого досвіду роботи над вебзастосунками інженерні команди часто приходять до такого підходу:

  1. Розробники покривають код в основному тільки Unit-тестами.
  2. Automation QA пишуть значну кількість E2E- & API-тестів.

Загалом цей підхід добре працює перші півтора — два роки, поки кількість E2E- & API-тестів не починає налічувати тисячі, вони виконуються годинами і стабільно приблизно 5% з них починає падати з рандомних причин.

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

З Unit-тестами є інша складність: зазвичай писати їх довше, ніж компонентні, і вони дають трохи менший рівень впевненості, що всі компоненти в інтеграції працюють коректно.

Проте в типовому вебзастосунку з мікросервісною та Layered-архітектурою більшість Unit-тестів часто перевантажена моками і тестує тільки факт виклику залежності чи layer нижче.

Кожен проєкт унікальний, проте розгляньмо альтернативу тестовій піраміді в вигляді Test Automation Diamond, яка, можливо, теж краще підійде вашому проєкту.

У цій стратегії основна кількість тестів припадає саме на компонентні. Підтримуючись невеликою частиною Unit- та E2E-тестів. На E2E-тести в цьому випадку припадають тільки критичні (ті, що приносять бізнесу гроші) успішні флоу. Unit-тестами покриваються методи зі складною калькуляцією, алгоритмами і т. д. Усі інші кейси покриваються компонентними тестами.

Observability

Наявність observability-інструментів дозволяють оперативно відстежувати неочікувану поведінку системи та швидко локалізовувати проблему.

У Howly ми використовуємо для цього такий набір:

  1. Info-логування — ELK-стек. Рекомендую використовувати структурне логування та створити необхідні дашборди в Kibana — це дуже пришвидшить роботу розробників.
  2. Error-логування — Sentry. Цей інструмент вирішує декілька задач: групує помилки та нотифікує про них та додає контекст до помилки — stacktrace, дані про девайс користувача.
  3. Tracing — ELK. Для мікросервісної взаємодії це практично must-have інструмент, завдяки якому ви зможете швидко локалізовувати затримки в відповіді та помилки на рівні сервісу.
  4. Метрики та алерти: Prometheus & Alert manager.
  5. Зовнішній uptime checker — UptimeRobot.

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

CI/CD

У ролі моделі роботи з Git ми використовуємо trunk-based development. Це дозволяє нам використовувати мінімальну кількість environments: staging & production.

Зазвичай більш складні моделі бранчування, наприклад, gitflow, потребують більшої кількості середовищ. На перший погляд вони створюють ілюзію підвищення якості: ви спочатку тестуєте фічі на Dev-середовищі, потім QA перевіряють їх на QA-environments і релізи додатково перевіряються на staging.

З практичного досвіду, крім негативного вприву на TTM (ви релізитеся в кращому випадку раз на один — два тижні замість релізів окремих фіч за готовністю), такий підхід не сильно підвищує якість продукту. Тому в випадку з no-QA стратегією краще підходить більш проста модель бранчування.

Для релізів фронтенду ми використовуємо canary releases — це дозволяє швидко отримати фідбек від кастомерів і зрозуміти, чи не погіршують ваші зміни бізнесові чи технічні метрики. Звісно що для критичного функціоналу ми використовуємо A/B-тестування — кожна зміна на воронці виливається на невелику кількість користувачів і аналізується вплив на conversion rate.

Проте великі зміни (наприклад, оновлення версії фреймворку, перехід на SSR, значний рефакторинг) важко запустити A/B-тестом, тому тут canary releases стають у пригоді. Для оцінки перформансу ми порівнюємо бізнесові метрики.

Крім цього canary releases дозволяють відділити волатильність маркетингу (особливо актуально для PPC) від змін на продукті. Так ми швидко локалізуємо проблеми між відділами.

Висновки

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

Це поняття містить культуру, ефективність процесів, відповідну тестову стратегію, наявність observability-інструментів та ефективний CI/CD flow. Крім цього значний влив відіграє слабко зв’язана архітектура застосунку.

Лідити цей процес, на мою думку, має CTO/Head of engineering. Оскільки QA Team lead зазвичай має обмежений вплив на рішення з культурних принципів, організаційної структури та змін у процесах.

Більшість підходів принесуть користь і за наявності виділеного QA в команді. Проте no-QA стратегія дозволить вам релізитися і підтримувати продукт значно швидше. Це відбувається за рахунок зменшення необхідних етапів в вашому SDLC і більшої залученості розробників на всіх етапах.

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Не зрозуміла назву статтю — до чого тут QA? Треба іншу назву — як змусити дева повірити в

ownership

і максимально загрузити грубою роботою за ті ж самі гроші.
З вашої точки зору, втовкмачити йому що він повинен виконувати обов’язки QA, бізнес-аналітика, девопса, сидіти на саппорті та робити все інше. Дев максимально зайнятий, голови ніколи підняти, повільно вигорає — профіт! Власник робить максимально швидкі релізи і економить на розробці — супер!
В мене тільки одне питання — навіщо такому золотому

Full cycle developer

взагалі ваша компанія?) І що буде, якщо така людина-оркест звільнитьсячи зламає ногу?) Хто буде розробляти, тестувати, підтримувати кліентів? Доведеться в режимі алярму наймати кілька окремих людей.
Ну і коли стартап стане трошки більшим і успішнішим, ніж три каліки, то все одно постане необхідність в QA. Все одно з’явиться потреба в тестовій документації, стратегії і так далі.

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

ну прям мега стисло)))

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

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

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

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

Це відбувається через те, що QA покривають не тільки основні позитивні кейси чи складні інтеграції, а й усі неуспішні флоу чи edge-кейси (які можна було б покрити більш швидкими і стабільними Unit- чи компонентними тестами).

Однак часто проблемні edge-кейси це якісь тривалі ’закручені’ сценарії, які влючають/залежать від кількох сервісів/компонентів. Зважаючи на ’трохи менший рівень впевненості, що всі компоненти в інтеграції працюють коректно’ робити такі заміни тестами нижчих рівнів досить ризиковано, бо якщо проблема дійсно лежить в інтеграціх, то це може пофіксити хіба що стан репортів до ’зелених’ 100%, але ж проблема то залишиться

У цій стратегії основна кількість тестів припадає саме на компонентні. Підтримуючись невеликою частиною Unit- та E2E-тестів. На E2E-тести в цьому випадку припадають тільки критичні (ті, що приносять бізнесу гроші) успішні флоу. Unit-тестами покриваються методи зі складною калькуляцією, алгоритмами і т. д. Усі інші кейси покриваються компонентними тестами.

Так в оригіналі інтеграційні, а не компонентні?

Сеньйор дев коштує 4-5к. QA коштує 2-3. Якщо в вас нема QA — то розробник за 5к займається роботою яка коштує 2к, причому робить це гірше. Проста математика, та дуже тупа «економія»

Це те ж саме, що на виробництві оператору складного станка сказати «в кінці зміни помий підлогу в цеху, це не складно, навіщо нам окрема прибиральниця»

Сеньйор AQA коштує приблизно стільки ж, скільки сеньйор дев

Щоб тестувати формочки — не завжди треба QA сеньйор. Вже не кажучи про мануальні тести

Це ж стартап, де потрібно і статичне тестування робити, і код писати, і пайплайни розгортати, і т.д. Автор пише, що ідея найняти QA і довчити не дала бажаного результату, бо, на мій погляд, очевидно, що тут потрібен сеньйор автоматизатор

Можливо, вона не дала результату тому, що найняли мануал QA на відповідну релевантну зарплату, і людина думала, що вона йде робити відповідну своєму тайтлу роботу, а потім як почали обвішувати овнершіпами і задачами робити крім мануального тестування ще й друге, третє, п’яте-десяте — де ж тут тій проактивності взятися?Та і для чого — щоб потім накинули ще більше роботи, ще більше задач?

Деякі люди нормально свою фічу протестувати не можуть... ви хочете сказати, що без QA ті самі люди починають класно тестувати?

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

Для того, щоб людина навчилася нормально тестувати, вона має тому десь навчитися? І якщо це не книга і не курси, вони вчаться (і роблять помилки) прямо на проекті?

Чи таким чином ви просто закриваєте очі на ненайдені баги?

P.S. у нас теж проект без QA але мені це не дуже подобається. Я дуже багато займаюся тим, чим міг би зайнятися QA.

Дев може і дизайн зробити і на сапорті посидіти) питання в якості та цілесообразності)

Отож. Я вже не знаю, чим я на проекті НЕ займаюся :D
От девопс з мене поки ще не дуже хороший (такий.. на три з плюсом, але це справа часу — я все розумію але практики малувато, VPN з всякими різними підмережами та закритими очима однією лівою рукою я ще не налаштую, з CloudFormation ще малувато практики щоб весь стек описати та розвернути).

А є вже методика no-devops? Ну бо якщо на проект брати виділених девопсів — то програмісти слабо залучаються в девопс операції. А якщо брати в компанію бухгалтерів — то програмісти якось слабо залучаються в бухгалтерію. А якщо брати в компанію сейлзів — то програмісти якось слабо залучаються в сейлз процеси. А якщо брати в компанію маркетологів — то програмісти якось слабо залучаються в маркетологію. І так далі....

А є вже методика no-devops?

Дуже влучний аргумент, мені аж сподобалося! )

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

Так, я знаю, що ми раніше самі все робили (навіть самі по ssh руками заливали релізи на серваки, без CI), я навіть слова такого девопс не чула до 2015 року. Але і технологій сучасних не було (клаудформейшенов та кубернетісов), і проекти були попростіше (максимум фронт та бек, шо там його заливати)

Саме так. Таке на мою думку може сказати тільки людина, яка краєм вуха шось чула, але сама не жила в тих реаліях. Дохіба інструментів, тре знати як воно все працює і як їх одне з одним подружити. Коли люди на перфокартах код дірочками робили, то теж девопси не дуже потрібні були )

А є вже методика no-devops?

Не те, щоб буквально no-devops, але чув про компанії, де розробники роблять суттєву частину devops роботи — принаймні, в плані опису потрібної інфраструктури в terraform / CloudFormation

UPD: не те щоб я проти такого підходу, але було б краще, якби перед тим, як оголошувати «А тепер ми працюєм без QA!» компаніі проводили для програмістів «Базовий курс по якісному тестуванню» чи хоча б вебінар на цю тему, бо реально не всі люди знають як тестувати (знаходити edge cases) і тестують просто happy path. А як тестувати систему на предмет security то взагалі мабуть знають одиниці?

по тайтлу думал «какие тестировщики плохие» — а тут годная статья.
Спасибо, было интересно.

якщо наймати кваліфікованих розробників, то без QA працювати легко. Гарний розробник сам відповідає за результати своєї роботи та робить все, щоб не було багів на проді. Від якості коду та наявності всебічних тестів, до процесів деплою та rollout stratagy.

Ви абсолютно праві в тому випадку, якщо кінцевого споживача влаштує рівень якості продукту який буде отримано в результаті самотестування розробниками. Але зазвичай подібний підхід починає валитися десь на межі інтеграційних/системних тестів і речей a la «в мене на комп’ютері все працює»

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

Таке буває лиш в компаніях з досвідченими керівниками, які можуть нести хоч якусь персональну відповідальність за персонал, та його майбутнє, й не зводять робочі відносини суто до Об’єктних промазаних відповідним Магічним Мисленням, задля зменьшення вірогідності винекненення відповідних психічних розладів... або йдуть в наркоманію (вже було так).

Якщо ви працюєте за SCRUM обійтися без QA дуже легко. Бо в SCRUM ніякого QA немає.

В SCRUM нема також і BA, UI/UX дизайнерів і т.д.)

В scrum нікого немає ))) скрам мастер і падавани. Як в садіку у моєї дитини — банда оболтусів різного віку і вихователька яка просто дивиться щоб вони лби не порозбивали

Ми проходили схожий шлях 2 рази у двох компаніях. Ми мали QA, але всі QA допомагали писати авто-тести (юніт, апі, інтеграційні, contract, UI, e2e) і НЕ тестували руками. В результаті, ми дійшли до того, що могли робити релізи майже кожен день.
——-
Ну не зовсім як у вас, але багато ідей були схожі.

Але...

На мою думку, QA краще направить команду зробити гарний тестовий фреймворк. Допоможе з покриттям.
Тому я за те, що QA треба 🙏
Але НЕ тестувати руками (лише зовсім крайні випадки — коли наприклад, треба WI-Fi перемкнути на Ethernet, чи перезагрузити комп, чи touch жести протестувати, чи коли треба подзвонити, чи щось таке дуже специфічне. Але зазвичай це не більше 5% всіх тест-кейсів (дуже залежить ще від продукту)

Круто) Дякую що поділилися досвідом!

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

юзери мабуть з продуктом теж руками не працюють у цьому випадку

Стаття написана так гарно, що я навіть почав вірити, що це можливо 🙂

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

Безумовно вам бажаю успіху.

Є досвід автоматизації кодгенерації з записаних тестів хром рекордером... нічього надзвичайного там нема. Можна ще стандартизувати E2E тести як табличні — тобто json spec хром рекордера засунуть кудись там гуглодок... й виходить зовсім цікаво.

Можливо релізну з того OpenSource рішення й свої розширення під k6/xk6-browser.

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

It depends...

1. Треба повводити й провалідувати метрик (CSAT/NPS/CES/PE), щоб розуміти як шо й де впливає на безпосередньо монетизацію (APRU/CAC/MRR/CLTV).
2. Без візуальної регрессії ніхто ті тести не ганяє...
3. Є тули що відповідно при приклацуванні маркують DOM дерево й створюють візуальне покриття (обмальовують квадратиками), потім воно співставляється з наявними Heatmap’ами й визначається найбільш впливовий функціонал, який інколи й варто прокласувать «Нормальному QA/QC».
4. На найбільш критичний функціонал (Critical Path), навішується Observability, де відповідно логується стан додатку перед винекненням помилки, щоб її можна було повторити будь кому локально (redux чи component state через кастомний hook 3 шт перед exception’ом достатньо), опціонально відбілюється від персональних даних, щоб по GDPR’у.
5.Відповідно QA/QC має мати достатньо досвіду щоб вирішувати задачі QE, а не бути «проклацуючою мавпою», там наприклад мати змогу прикрутити мутаційне тестування до E2E тестів за потреби, та покращувати роботу BuildOps/TestOps.

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

Тут питання не в тому чи потрібні QA/QC, а в тому що їх робота має бути чітко спрямована на критичний для бізнесу функціонал, де можна одразу ж побачити вплив їх діяльності (чи бездіяльності) на Дохід Проекту.

Тут справа в костах такого підходу vs стандартного дня нас підходу з QA
власне, не часто вам самому приходилось такі проекти бачити?

Тут справа в костах такого підходу vs стандартного дня нас підходу з QA

Ви приходите з солюшеном в продуктову, розгортуюте інфру, показуйте предіктнутий кост.
Готовий подібний сетап вартує 200К$ ±150К за тренінги в місяць й інтеграцію, в середньому.

Вартість володіння в середньому +1-6К$ в місяць, в залежності від використаного СDN’у й edge стеку. QA’шники загалом роблять меньше, користуються там HotJar’ом й подібним... й треба їх максимум 2-3 чоловіка з хорошим досвідом й навичками QE. Тобто ±3K$ за одного — 6-9К$.

Маєм приблизно 7-15К$

спроба обгрунтувати маячню.
З досвіду:
1. Коли крітікал попадає на прод швидкість реакції що з QA що без, у нормальних командах, однакова )))
2. з qa девелопер робить 3 таски за спринт але тільки 2 попадає у прод, чи без QA 2 таски робить і всі аони попадають на прод, роботу по забезпеченню якості все одно треба виконувати. як на мене швидкість делівері однакова, якість QA процесів у виконання девелоперів гірша.
3. якщо забити на QC то звісно швидше, походу у автора так і сталося під капотом )).

Є ще веселіші випадки, коли люде там накатують мутаційне тестування поверх E2E тестів ... там на Stryker поверх JSDOM cнапшотів, шоб браузери не ялозить.

Але загалом — повністю згоден... забагато маячні.

Практичний кейс про те, як ми відмовились від QA, для того щоб покращувати метрику «швидкості реакції команди» на критичний баг на проді. При цьому кількість owner’ів якості начебто збільшилась в рази. Висновки і практики, до яких ви прийшли в результаті реалізації підходу, вам зміг би сказати будь-який більш-менш досвідчений QA lead, а може навіть і senior QA з відповідним досвідом, також вони описані у багатьох підручниках з тестування.
Як на мене був сильний missfit по першому QA, якого ви найняли, і цю проблему ви спробували вирішити створенням власного велосипеду, який начебто поки що їде.
Навіть у висновках не обгрунтували чи вдалося вам

забезпечити якість продукту в стартапі без виділеного QA

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

Другий рівень організаційної зрілості (по SEI), коли менеджемент ще не працює, бо відповідні кращі практики не відпрацьовані, не формалізовані й головне — не підтверджені існуючим ринком. Досвід в команді ще не накопичений й розподілений дуже нерівномірно.

1. ELK стек мертвий, разом з Sentry
2. Grafana LGTM разом з Pyroscope має значно нижчу вартість володіння.. але навряд че в них там куби
3. А чим там вони в СD Сannary Deployment’и та A/B тести дійсно зробили — маєм самі здогадаться...

Швидше за все, ніхто нічьо до путя там не доробив, й це просто Wanna Be стаття «як треба» але досвіду робити «як треба» — нема.

Якщо робити «нормально», то «нормальне СD» без кубів зараз лиш — AWS CodeDeploy.
«Нормальні» A/B тести — CloudFlare Workers, або Akamai Workers. Lambda@edge — доволі дорога.

Й то відповідно створює обмеження по вибору фронтенд фреймворку, бо його пререндер має бути сумісний з відповідним рантаймом — там Remix, чи щось схоже...

Ansible — Сobol сучасного DevOps’у... причин віртуальні машини руками налаштовувать зараз немає, т.к. усе переважно cloud-init з Stateless Atomic Infrastructure на docker linux’ах типу CoreOS та Flatcar чи Elemental Toolkit у Rancher’а.

Причин «писати E2E тести руками» — зараз, теж немає.
Нічього не заважає використати розширення для Сhrome Recorder’a для кодогенерації під конкретний фреймворк, або ж написати свою кодогенерацію.... там під k6, наприклад.

Причин «писати E2E тести руками» — зараз, теж немає.
Нічього не заважає використати розширення для Сhrome Recorder’a для кодогенерації під конкретний фреймворк

успіхів ) Були вже тут такі схожі. Посипалися питання, полетіли помідори і автор зник. Хоча там навіть не рекордер був, а лоу код.

... а в чому власне проблема ?

Якби це дійсно зараз було щось «нереалізоване» — це не було б рекомендацією та хорошою практикою, й відповідні рекордери cypress-chrome-recorder nightwatch-chrome-recorder chrome-recorder не висіли б в офф документації й не згадувались в replay, й не підтримувались розповсюдженими сервісами типу TestCafe й SauseLabs.

Відповідно сама схема рекордера в Replay наявна — нічього не заважає обійти її й згенерувати будь який інший тест. Поки генерую під xk6-browser та відповідно ще захоплюю API виклики для k6 в ServiceWorker’і.

На практиці, там треба ще ручками в самому рекордері інколи трохи підправляти селектори.

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

Головний доказ — цього ніде нема. Чому так ніхто не робить? Я маю на увазі більш менш серйозні проєкти складніші за лендінг. Проблеми дуже схожі на проблеми лоу код автоматизації, які вже були описані у вище згаданій статті, то ж не буду повторюватися. Якщо ви придумали магічну паличку, яка міняє правила гри в світі, то давайте робити з цього комерційний продукт.
Ця штука працює в трьох випадках: дуже маленький об’єм, коротка тривалість або погратися з ціллю навчання.
Знову ж таки, якщо у вас є успішний кейс — напишіть статтю. Ком’юніті велике, оцінять )
В бувшій конторі СЕО десь почув шо лоу код з рекордером то класна штука яка вирішує проблеми і вперто вирішив жити по новому. Втратили класних людей, купу грошей і через пів року відмовилися від цієї цсторії, бо воно не працює.

якщо у вас є успішний кейс — напишіть статтю

Є кейс приймального тестування різних CNCF додатків в дистрибутиві кубів... бо SLO/SLA не враховується при Liveness Probe’ах, й то відома вада дизайну.

Чому так ніхто не робить?

Знаю чотири продуктові, які так вже тести й ганяють з 2019ого.
Не роблять — бо люде ригідні, й більшість компаній не готові вирішувати супутні інженерні проблеми.

то давайте робити з цього комерційний продукт

... в процесі, там насправді нічього надзвичайного

Ком’юніті велике, оцінять )

Кількість пасивно агресивних та невротизованих зашкалює... з урахуванням відповідних форм соціальної контамінації й Неможливості Усвідомлення обмеженності професійного й особистого зростання в Наявних Ринкових Умовах, на конструктивний зворотній зв’язок розраховувати не доводиться — максимум напишу 5-10 «+/- розумних» коментарів, люди обуряться, обісруть, покіплять ... й все. Загалом компенсаторні процеси й потреби занадто примітивні...

Мені нема сенсу витрачати свій час на місцеву флору й фауну, якщо й так по коментах видно якість й наміри тої спільноти.

десь почув шо лоу код з рекордером

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

Підіб’ю підсумки. Ви бігаєте по коментам взад вперед і всім доводите, що все хєрня, треба так робити. Як як «так» казати не хочете, бо нахєр вам ті людішки здалися на них час витрачати. Накидати побільше розумних слів. Шоб шо в ітозі? ) Якщо вам пофіг на тих людішек, то нашо кажете те, що невзмозі/не хочете доводити і обгрунтовувати?
А лоу код то навіть наступний крок після рекордера. Де можна зробити запис і потім на юайці підредагувати за допомогою дропдаунів з екшинами і так далі. І та хєрня не їде. Так шо я не приплітаю, а навіть доплітаю за вами )
Насінг пьорсонал як то кажуть. У нас з вами мабуть занадто різний досвід )

Як як «так» казати не хочете,

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

Якщо вам пофіг на тих людішек, то нашо кажете те, що невзмозі/не хочете доводити і обгрунтовувати?

Так жеж обгрунтував: для людей власна обмеженість та відсутність кваліфікації частіш не є проблемою.

Якщо ви не знаєте що таке Соціальна Контамінація чи Проективні Процеси, та як це спотворює сприйняття... можна було б спитати, де про те прочитати.

Так шо я не приплітаю, а навіть доплітаю за вами )

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

І та хєрня не їде.

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

Насінг пьорсонал як то кажуть.

Насінг бат пьорсонал...

Накидати побільше розумних слів. Шоб шо в ітозі? )

Щоб люди похизувались своєю обмеженністю, безвідповідальністю, недалекістю, посивною агрессією й було очевидно що вони об’єктивно Хворі.

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

Метрики та алерти: Prometheus & Alert manager.

А чи не дивилися у бік VictoriaMetrics та VictoriaLogs?

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

Ну й треба ще в куби вміти... на те треба окремий бюджет, десь від 300К$ на рік.

Тобто? Софт що я вказав працює як бінарник в системі, так і в докерах, так і кубах. Є cloud.victoriametrics.com для метрик типу managed prometheus в aws, але я так і не зрозумів ваших розрахунків 🤔

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

От шоб їх перевчить, звільнить, знайти нових, знову звільнить... й хоча б щоб за рік всі були з СKAD’ом — треба десь 300К$ на середню команду в 40 чоловік. Ну й туди ще входить допилка розробка відповідної платформи поверх кубів, contribute в відповідні проекти й рішення певних наявних інженерних проблем.

Брать готовий там москальський DeckHouse, чи той же OpenShift — множить ту суму десь на 2.

Можна використати managed... але зараз з тим є певні юридичні проблеми (security conformance й FIPS’и в основному)

В докерах оператора нема.

hub.docker.com/...​c019302e2?context=explore а це тоді що? чи про який оператор йдеться?

Брать готовий там москальський DeckHouse, чи той же OpenShift — множить ту суму десь на 2.
й хоча б щоб за рік всі були з СKAD’ом — треба десь 300К$

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

Шановний, якщо у вас проблема із навичками персоналу, то не треба вважати, що й інщі компанії такі проблемні. k8s дефакто стандарт для компаній, але звичайно без монолітів нікуди(uklon, kasta.ua, etc), котрі працюють і без докеру чи k8s, але таких мало та вони самі свої велосипеди створюють.Той же Jenkins ніяк не помре, чи nomad — прекрасно живуть, але знову ж кажу що це вийнятки котрі історично так працюють.

hub.docker.com/...​c019302e2?context=explore а це тоді що? чи про який оператор йдеться?

Це Kubernetes Controller ... відповідно реалізує паттерн Оператор.
Та похостяний він в Dockerhub’і — це не означає що в Docker Swarm є нормальна можливість реалізувати Reconciliation Cycle та виконувати контроллери як розширення... й тим паче керувати життєвим циклом відповідних додатків.

Поняття оператора — воно одне, є в кубах... й до Nomad / Docker Swarm поки не застосовується.

Максимум шо люди можуть, так це накостилити якийсь Workflow через Apache Airflow... й то буде повільно й ненадійно... порівняно з повноцінними операторами.

сертифікат це більше для продати себе як спеціаліста дорожче на аутсорс чи аутстаф.

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

Якщо говорити про AWS Architect / DevOps / Cloud Practitioner (AWS DOP-C02, CLF-C02) — там дійсно мало користі й майже нуль практичних навичок порівняно з SysOps / SA (SAA-C03, SOA-C02). Є багато «паперових сертифікатів» й в Azure, й зараз GCP вмикає агресивний маркетинг для студентів... Відповідно «Паперових CNCF Сертифікатів» не існує — кожен з них має конкретні вимоги до практичних навичок й можливостей, хоч й здають їх в Linux Foundation десь між ніяк й жахливо.

Якщо говорити конкретно про CKAD — це необхідний мінімум роботи з кубами, який принаймні гарантує що людина буде знати різницю між Deployment’ом й StatefulSet’ом, що таке й нащо треба Headless Servic’и ... тобто основні ресурси. Звичайно що для реальних задач того мало й треба ще вміти Helm рендерити / патчити через Kustomize — заміняти стокові деплойменти там на щось нормально маштабоване, Knative Serving сервіси чи Argo Rollouts / Flagger під Keda.

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

У людей відповідальності зазвичай лиш вистачає на «helm install / helm upgrade»... а шо том по rollout’ам й операторам — дізнаються після CrashLoopBackOff.

Я розумію що Jenkins недалекі є, й будуть... як москалі... й аргументація в них така ж — «не все однозначна». Коли ринок побудований на підміні понять, брехні й лицемірстві — на «однозначність» сподіватись не доводиться.

що й інщі компанії такі проблемні

То який в них реальний рівень організаційної зрілості ?

Поки ні, оскільки поточний стек влаштовує і закриває потреби на нашому об’ємі даних. Але чув позитивні відгуки про VictoriaMetrics, порівняємо, дякую.

Спершу варто злізти на Grafana LGTM... бо ELK віджив своє давно.
AWS Managed Prometheus має нормальний кост й з СloudWatch’a можна туди експортувати метрики. Managed Grafana білиться по seat’aм в 9$ й 5$ ... то треба в Сontrol Tower’і відповідний Guarderail завезти. З агрегаторів — можна взяти Vector.dev чи Grafana Agent... з протоколів краще сидіти на GRPC OTLP. Фронтенд зараз також нормально існтрументується через OpenTelemetry (там трохи сирий Exporter, але Grafana його вже монетизує в Grafana Faro), й можна, наприклад, логувать останні 2-3 стани компонентів перед exception’ом, тощо.

«На потицять» раджу не лізти в terraform, хоч в нас дуже хороша спільнота й купа готових модулів, варто спробувати спершу розібратись з AWS CDK під TypeScript — там є можливість створити StackSet й прив’язати до організації в AWS Organizations, потім покрити AWS Control Tower, зробити ферму акаунтів й шарить між ними сервіси через AWS RAM (той самий managed prometheus).

Потім вже те саме пробувать повторити на terraform модулях... можна через CDKTF й теж на Typescript’і, щоб люди в HCL не влазили й могли multi-stage deployment’и через remote state provider.

Як забезпечити якість продукту в стартапі без виділеного QA

взяти і зайнятися роботою яку зазвичай робить QA)

0. Назва не відповідає змісту, ви описуєте шлях побудови інженерної культури в середині команд, а не відмову від тестувальників (по факту, у вас була лише одна спроба найму тестувальника)

1. «Наш шлях до no-QA» — qa це не людина, а процес який може забезпечуватись всім членами команди (про що ви далі і пишите), тож правильно було б написати «Наш шлях до quality ownership без виділенного тестувальника»

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

3. Також цікаво скільки у вас був бюджет на цього «супермена», якщо змогли найняти тіки Manual QA

4. «кількість E2E- & API-тестів не починає налічувати тисячі, вони виконуються годинами і стаільно приблизно 5% з них починає падати з рандомних причин» — все так, а скільки ви змогли покрити тестами маючи команду з 10 розробників, скільки автоматизованих тестів у вас по ітогу знаходять дефекти?

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

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

Дякую за статтю.
Підхід до відповідальності за свій код з боку розробників доволі поширений, про це писав Джеймс Уіттакер в своїй книзі про тестування в Google.
"

Ми шукали такого собі «супермена», який буде повністю відповідати за якість на проєкті:

"
Ви скоріше шукали SDET/SET ніж QA. Хоча в наших реаліях ці поняття дуже розмиті.

Дякую за відгук! Щодо SDET — шукали людину і з таким тайтлом, проте нам в більшості випадків траплялись кандидати, котрі розробляли тестову інфраструктуру і бібліотеки для інших QA. Що не зовсім той портрет, в який ми цілилися оскільки це більше про технічну складову ніж про побудову процесу.

Мабуть у кандидатів не було розуміння своєї позиції)
Коротка змістовна стаття на цю тему www.linkedin.com/...​st-alex-markevich-ukvne

кандидати, котрі розробляли тестову інфраструктуру і бібліотеки для інших QA.

так це власне типові SDETи і є, за нормального розподілу ролей між всіма членами загальної тестової команди, це їх найперша задача, за ідеальних умов — чи не єдина задача взагалі

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

Автор пише що стартапу вже 2,5 роки. Цілком ймовірно, фазу product-market fit вони вже пройшли, і далі пішов якийсь sustainable розвиток, де якість вже дійсно може бути важливою.

На етапі первинних MVP та pivoting таке ретельне тестування може бути дійсно не потрібним, але! Якщо не впроваджувати хоч якийсь ownership за те, що роблять розробники, то без QA в продакшен зазвичай попадає щось настільки багливе та нестабільне, що може вбити продукт ще на етапі MVP

4 рівня тестування для стартапу, Ви знущаєтесь

з нашого досвіду написання автотестів при:

  • готовій тестовій інфраструктурі
  • навченій команді
  • тестовій стратегії, яка дозволяє писати тести швидко

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

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

в продакшин вийшли через 2 міс після початку розробки. При цьому виходили вже з компонентними тестами на бекенді та декількома E2E тестами.
Оскільки в FE&BE тех лідів був досвід написання тестів до цього, підготовка тестової інфраструктури зайняла близько 2 днів.

Нам вже 2.5 роки, наразі вже вийшли в net profit)

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

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

дякую за толковий матеріал, таке питання:

До рефайменту розробники досить добре готуються: попередньо залишаються коменти з питаннями, готують API взаємодії фронтенду з бекендом, описують структуру сутностей в БД і т. д. Так розробники набагато краще синхронізуються в баченні з Product Owner, і, відповідно, це дозволяє реалізувати вимоги коректно з першого разу без фіксів в майбутньому.

як можна готувати API взаємодії фронтенду з бекендом та описувати структуру сутностей в БД, якщо рефайнмент ще не відбувся, і розробники ще не обговорили деталі вимог, які зазвичай на рефайнменті обговорюються?

Дякую за фідбек і питання!

Основна ціль підготовки API/опису структури сутностей в БД — стимулювати розробників краще продумати реалізацію і таким чином виявити більшість підводних каменів та задати необхідні питання PO.
Тобто в нас немає самоцілі зробити на 100% точний API до рефайменту.

Якщо резюмувати, тут є 3 можливі сценарії:
1) задача типова і зрозуміла (50%): API можна підготувати відразу, на/після рефайменту вносяться незначні правки
2) задача в цілому зрозуміла, але є декілька точкових питань (30%): розробник залишає коментар в тасці, якщо PO відповідає до рефайменту, то готуємо API
3) задача нетипова і є багато запитань(20%): API готуємо після рефайменту або після виконання SPIKE

Наприклад, можна використати RPC яка не потребує рефайнменту — це може бути tRPC або GRPC зі шлюзами в rest чи graphql.

Відповідно якщо то pg_rest / pg_graphql в Supabase, чи prisma/hasura — потреба в розробці API може відпасти сама по собі.

Тобто зараз й «API’шки люди руками не пишуть»...

якщо то pg_rest / pg_graphql в Supabase, чи prisma/hasura — потреба в розробці API може відпасти сама по собі.

Це хіба що API являє собой тупий CRUD; але зазвичай поверх доступу до даних буває якась бізнес-логіка (іноді доволі нетривіальна)

1. Є момент з денормалізацією — відповідно варто спершу просто постворювати вьюшок в базі... часто практикував створення однієї вьюшки на агрегат (по DDD в рамках Сontext Boundary), щоб не роздувати самі Endpoint’и. Так то нормально живу з tRPC, й вже понаписував шлюзів в GraphQL й GRPC (під envoy й linkerd2).

2. Якщо це Stateful FSM API з будь яким Workflow яке відповідно там має певні стани — його варто реалізовувати на відповідних Workflow рушіях чи сервісах. Там по мінімуму зараз краще в Argo Workflows, та якщо це щось батчане з чергами — Volcano Scheduler. Apache Airflow на пістоні занадто повільний й майже ніяк не оптимізований... хоч й єдине що без кубів хоч якось працює, то варто в куби лізти хоча б із-за можливості там в якийсь Argo Workflows + Argo Events чи там Triggermesh. Так то можна обійтись AWS StepFunction’ами, Azure LogicApps, GCP Workflows, але треба вміти налаштовувати організації з фермами акаунтів й відповідними політиками квот... можна похостить Gitpod/OpenVSCode чи там Jetbrains Gateway з Jetbrains Server’ами, щоб й IDE’шки в хмарах автомаштабувати, й була можливість працювати з калькулятора... але нажаль частіш всім всеодно, бо відповідальності й навичок не вистачає, як й з фермами акаунтів (AWS Organization / Control Tower + AFT, а усюди далі «IAM користувача чи ролі» діло не йде).

Зазвичай такі Stateful FSM API використовують десь існуючі з supabase / prisma / hasura ендпоінти та наслідують відповідні політики авторизації... часто практикував написання FDW до Argo Workflows, щоб API’шку підтягнуло як Foreign Table.

3. Є ще момент з агрегатами (для аналітики, а не DDD), бази частіш не вміють в Incremental View Maintanence, й нема інкрементального поновлення мат вьюшок, бо у оракла на те патентів купа, разом з автоматичним створенням мат вьюшок — не здивуюсь якщо кому вже погрожували судами (вже були суди в PostgreSQL з HР по патентованим алгоритмам кешування). Є там pg_ivm, але він недопрацьований місцями й часто варто після нього його ж створені тригери переписувати... й потім те дуже тяжко підтримувати. Частіш усю аналітику вивантажую в окремий ETL пайплайн через СDC. Там на прикладі AWS то може бути AWS RDS -> DMS -> Kinesis Firehose -> Kinesis Analytics SQL -> OpenSearch / Athena / S3 etc. Все шо було про Stream’и давно вміє в SQL — kafka -> ksqldb, flink -> flink sql, spark -> spark sql, beam -> beam sql, arrow -> datafusion. Відповідно по вартості володіння не варто лізти в усілякий PowerBI/DataBricks/Tableu, й воно не є чимось більшим за конструктор запитів до тих діалектів Stream SQL’я.

  1. Далеко не кожний проект робиться по DDD / EventSourcing методології
  2. Застосування зовнішніх workflow рушіїв теж далеко не завжди виправдано. До того ж, це додаткова вимога до навичок команди розробки, яка може ускладнити найм та збільшити direct costs

В цілому, то про що ви кажете, може бути доречним для великих ентерпрайзів, але для проектів меншого масштабу зазвичай набагато простіше та дешевше використати ORM та написати зверху неї кастомну бізнес-логіку, ніж йти шляхом Hasura + зовнішній workflow рушій.

Команди які не можуть в Stateless Streaming я вже й за людей часто не сприймаю...

Втім, після такого тейку я не бачу жодного сенсу спілкуватися з вами далі.

може бути доречним для великих ентерпрайзів

Вже використовується в Українських Продуктових Компаніях, й має значно нижчу вартість володіння. От як раз в ентерпрайсах далі ORM’у не можуть, бо в ентерпрайсі DBA нема... в Observability, Time-series, Storage Partitioning/Segregation не вміють... й той же самий ES поверх ORM’ів в найкращому випадку можуть виконати поверх Debezium’у, з дуже різними наслідками.

Далеко не кожний проект робиться по DDD / EventSourcing методології

Проблема в некваліфікованому персоналі, який не вміє в Бази Данних й Аналітику... Materialized Views не вивозять, а «щось розумніше» відповідальності/навичок застосувати немає. Тобто вже можу порахувати з три десятки проектів які усю аналітику, в буквальному сенсі, в терабайтах пихають в той же Data Bricks й навіть ElasticSearch (там є агрегати) й платять по 40-200К$+ в місяць, просто із-за подобового поновлення того датасету.

Stateless Streaming

Десь 80% проектів «просто з кафкою» мають з тим проблеми, по моїм суб’єктивним, з того що бачив, — це надзвичайно розповсюджена вада дизайну. На яку просто прийнято «закривати очі», поки «клієнт» чи «стейкхолдер» сплачує 100К$+ за хостинг, а в СI/CD/Failover не можна, бо «стейт в черзі», або «ми не можем мігрувати формат повідомлень» бо «не можем».

сенсу спілкуватися з вами далі.

Будь ласка. Індустрія переповнена дилатентами, дилетантів, які не відповідають своїм посадам, не виконують свої обов’язки й не виправляють відомі вади, й не попереджують збільшення вартості володіння... людьми тяжко назвати.

Спробуйте спершу розібратись в тому Що Написано

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