Дякую. Сьогодні я хочу поділитися з вами нашим досвідом, як можна розробляти продукт успішно без виділеного QA на прикладі нашого стартапу. Мене звати Гаранджа Дмитро, я працюю Head of Engineering в стартапі Howly від венчур білдера Scalar. У мене більше 10 років досвіду в розробці. Основна експертиза у мене в бекенді. Якщо брати по ролям, то займав різні позиції, крім розробника. Це і техлід, тімлід, архітектор. Також цікавлюся і впроваджую DevOps методології та тулзи в Howly, в стартапі інфраструктури самостійно. Яка у нас сьогодні адженда? Зробимо коротеньке інтро про наш проект і, в принципі, наш досвід роботи з QA. І далі ми розглянемо принципи і підходи, завдяки яким ми гарантуємо якість на нашому проекті.

Отже, почнемо з інтро. Howly входить в портфель компанії-венчур білдера Scalar. Scalar – це компанія, яка будує бізнеси за венчурним принципом. Вже побудували десяток успішних бізнесів в різних сферах. У компанії працює більше 500 співробітників, і Scalar закриває всі інфраструктурні питання під ключ. Тобто, стартапам не болить голова за те, як закривати якісь юридичні питання, як покривати рекрутинг, фінанси чи HR. Трошки контексту про Howly. Howly – це стартап в сфері онлайн-консультації. Тобто, ми з одного боку поєднуємо користувачів з якимось питанням, а з іншого бока – консультантів, які можуть їм допомогти, тобто, це такий маркетплейс. Нам два з половиною роки. Проект представляє собою веб-сайт, тобто, це мобільна дискордна версія. Мобільних застосунків у нас ще немає. Як виглядає інженерна команда? У нас три крос-функціональні Scrum-команди. Загалом це 11 інженерів. Крім backend, frontend інженерів і продактованерів, також в командах залучені дизайн і контент-едітор.

Якщо ми говоримо про бізнесну архітектуру, кожна команда відповідає за свій набір сервісів. І ключова, мабуть, навіть річ на цьому слайді – це основна метрика, яку від нас вимагає бізнес. Це постійно понижувати time-to-market, тобто, деплоїтись якомога частіше і швидше. Який же наш був шлях з QA? MVP ми випустили в листопаді 2021 року. На той час у нас було три розробники, наскільки я пам'ятаю. QA на той час не було, і необхідності такої не було. Потім бізнес почав масштабуватися, зросла вже кількість продуктового функціоналу, зросла кількість користувачів, ми стали наливати більше трафіку, і ми почали більше задумуватись безпосередньо вже про якість. І відкрили позицію QA. Шукали ми таку людину досить довго. Я на наступному слайді поясню. Чому? Потім все-таки знайшли QA. І за 3-4 місяці все-таки зрозуміли, що це трошки не той шлях, куди ми хочемо прийти. Чому? Ключових тут я б виділив дві речі. Перша річ — це те, що задачі почали доводитися до продакшену пізніше, в середньому десь на день-півтора. Тобто ми почали реалізовувати задачі пачками, якщо до цього реалізували. Ми по готовності, умовно, змерджували майстер. Ми розуміємо, що майстер у нас — робочий код. І ми ліємо його на продакшн. Тут ми чекаємо QA. QA часто це все переводить в пачки, тестує. Потім ми чекаємо фікс і так далі. І друге ключове, що теж трапилось — це менша залученість девелоперів. Менший ownership. Як приклад можна привести навіть кейси, коли у нас QA віддавалися задачі, де сексес сценарій взагалі не працював. Це точно не так, як воно має бути.

Тому ми все-таки прийняли свідоме рішення відмовитися від QA і трішки працювати з якістю по-іншому. Далі розповім саме як. Щодо людини, яку ми шукали. Це був такий супермен чи супервумен, який, крім класичного QA, який, умовно, готує тест-кейси, пише N2N-тести, ми ще шукали людину, яка буде в цілому відповідати за якість на нашому проєкті. Що це значить? Ми хотіли, щоб ця людина розуміла архітектуру, могла зрозуміти, що ось цей тест-кейс, умовно, вже покритий автотестами на фронтенді чи на бекенді, на нього там немає сенсу писати N2N-тест і дублювати ці речі в тесті, який там проходить втричі довше. І аналогічно, знаючи вже цю архітектуру, вміти локалізувати певний баг прямо до рівня сервісу. На жаль, таку людину ми, не знайшли, хоча, чесно кажучи, такі люди на ринку є, але це одиничні кейси. Давайте далі розглянемо трішки культурні принципи і підходи, яких ми притримуємося. Тут буде багато перетинів з попередньої доповіді, тому що у нас схожі принципи з WIXсом, але давайте освіжимо пам'яті.

Отже, перший принцип — це принцип олдершипу. Тут дуже рекомендую, хто ще не читав, є чудова стаття на Netflix. В них такі розробники називаються Full Cycle Developers. Що це значить на практиці? Це значить те, що розробник відповідає не тільки за свою частину умовної. Я написав код, перейшов, у кращому випадку, код-ревію, і я забув взагалі, що це. Що далі відбувається з цією задачею? Ні, у нас це не так. Тобто, розробник — це людина, яка відповідальна за те, щоб задача працювала в продакшені, тобто це людина, яка деплоїть. У неї в нас всі права задеплоїти свою задачу чи навіть інші задачі, якщо вони деплоїться. І також розробник відповідає саме за моніторинг, тобто зацікавлений в тому, щоб його задача працювала. Ця зацікавленість, в свою чергу, на практиці виливається в теж, розробник краще придумує тест-кейси, краще покриває свій код тестами, ну і, звісно, там краще включається на рефайментах.

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

Наступний принцип – це fail-fasten-chip. Що це значить на практиці? Це значить, що ми розуміємо, що ми не можемо щось зробити відразу ідеально, так, з першого разу. Наша задача – це зменшити розмір помилки і пофіксити її максимально швидко. Тобто ми працюємо невеличкими ітераціями, деплоємося невеличкими або пачами, і далі навіть по одній задачі, умовно, змерджили і відразу її вилили. Виливаємо фронтенд канеріючими релізами на невелику частину користувачів, подивилися, зібрали метрики, якщо все окей – вилили далі, якщо ні – відразу заролбечились. Ну і, звісно, тут сюди включається моніторинг, тут буде трішки більш детально на наступній секції.

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

Далі давайте розглянемо безпосередньо роботу з процесами. Тут не буду проговорювати речі, які, я думаю, в 99% компаній співпадають. З чого починається з ідеї? Далі у нас є такий мітинг, як High-Level Refinement, і тут відбувається такий перший сінк всіх Product Owner. Тех лідів, де ми готуємо такий High-Level Review взагалі реалізації цих епіків. Після цього у нас є фаза, де Product Owner детальніше вже декомпозують тікети, описують вимоги. Далі до рефінментів ще розробники також більш деталізовано готуються, тобто це певні чек-лісти. І далі, в принципі, все вже по класичних стандартних сценаріях, і закінчується вже безпосередньо деплоєм на продакшн і моніторингом, що все працює коректно. Найважливіший принцип, який я хотів би тут донести, якого ми притримуємося в процесах, це підхід вбудованої якості в процеси. Цікаво просто, хто взагалі чув колись за Едвардса Деммінга. Підніміть, будь ласка, руку. Не багато. Окей, добре, що є такі люди.

Едвардс Деммінг – це людина, яка після воєнні роки, після Другої світової війни, це американець, який вивів автомобілебудування в Японії прямо на дуже якісний рівень, і принципи цієї людини лягли потім в Лін Рух, який далі теж заклав такий фундамент для багатьох практик, яких ми притримуємося наразі. В чому суть цієї цитати? Суть в тому, що нам потрібно перевіряти якість не просто в кінці року, що, умовно, наша фіча працює чи не працює, і це такий факт, чим часто займаються QA. Нам потрібно гарантувати якість на кожному етапі цього процесу, тобто в кожному етапі є якісь певні інпути, певні аутпути, і наша задача – сфокусуватись на тому, щоб кожен з цих етапів працював максимально ефективно. Чому взагалі це все важливо? Це важливо тому, що це просто економить час і, відповідно, економить купу грошей. Бо інколи, чим пізніше ви знайдете якусь помилку, тим дорожче буде її фіксити.

Як це на практиці відбувається безпосередньо у нас? У нас є, як я вже показував, певний флоу роботи над задачами. Я б рекомендував, якщо у вас якихось компаній цього немає, це займає пів години просто хоча б такі речі візуалізувати. Це вже перший крок до успіху. А ось далі. По кожному з цих етапів у нас є невеличкі чек-лісти. Ми не кажемо про те, що потрібно писати портянки документацій. Зробіть хоча б невеличкі чек-лісти, що на кожному етапі відбувається. В нашому випадку, наприклад, на High-Level Refinement ми розуміємо, що нам потрібно декомпозувати задачі, визначити залежності між командами. Потрібно підготувати якийсь архітектурний солюшн, якщо він вимагається від тех лідів. І, наприклад, маємо підтримуватись дизайн системи. Тобто, у нас дизайн має бути стандартизований для того, щоб фронтен-розробникам було легше і швидше рухатись. Аналогічні чек-лісти у нас є на рефайментах. Тобто, розробники деталізовано готуються до цього. Тобто, це не просто мітинг, на який люди прийшли без підготовки, вперше почули про задачу. Навряд чи з таким підходом ми зможемо зрозуміти всі edge-кейси.

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

Наступне це те, як ми працюємо з інцидентами. Тут, в принципі, початок досить класичний. Відбувається інцидент, далі ми його або швидко фіксуємо, або бачимо реліз. І ключове, що тут є. Впевнений, що в першому разі, якийсь інцидент, який ми бачимо, і половині компаній цього дотримуються. Якщо ні, то варто теж зробити. Це описати post mortem. Тобто, зробити висновки з цієї ситуації. Тут є чіткі відповідальні люди. В нашому випадку це бекенд або фронтенд тих людей. Тут я привів такі ключові речі, як на мене, які там обов'язково мають бути. Тобто, потрібно порахувати кастомерів, хоча приблизно скільки ми заефектили. Що тут також важливо, це знайти ключову причину дійсно докопатися до суті. Яка привела до цього інциденту. Тут класична техніка, задати 5 разів питання чому це трапилось. І тоді ви дійсно зрозумієте, що можливо ключова причина цього, це те, що ви вже пів року не берете технічні задачі, чи не вирішуєте свій техборт. Тому що інколи можуть бути досить неочевидні речі, якщо там умовно якась задачка з тих беклогу цьому інциденту б запобігла. Рекомендую також описувати таймлайни, для чого це потрібно. Ви зрозумієте, де у вас bottleneck в швидкості фіксу інциденту. Тому що часто, наприклад, приходять до формату, так, нам потрібні чергування, щоб розробники швидше фіксували задачі. Ну, інколи все не так очевидно, інколи виявляється, що ми фіксуємо задачі і проблеми і в неробочий час, а, наприклад, виявляємо їх по 12 годин. Ну, мабуть, варто не чергування вводити, а все-таки покращити свою систему моніторингу. Ну, і, звісно, теж action item. Тут все по класиці, мають бути конкретні, один відповідальний і з чіткими дедлайнами.

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

З точки зору кількості витрат часу, підтримки і рівня впевненості в тому, що твій функціонал працює. Ось, ми притримуємося такої схеми, де кількість юніт-тестів відносно невелика, і більшість займає такі компонентні тести. Як безпосередньо це в нас імплементовано на практиці? Тобто юніт-тестів у нас є. У нас близько п'яти відсотків. По юніт-тестам тут все по класиці, вони виконуються в ізоляції. По компонентним тестам ми їх, знову ж таки, в випадку з фронтендом, це framework, next.js, виконуємо в ізоляції без взаємодії з бекендом. Бекенд трішки детальніше далі буде, може взаємодіяти з базою даних, наприклад. Інтеграційні тести вже стали стандартною практикою, де ми перевіряємо робочі процеси користувача, емулюючи їхню взаємодію. Наш звичайний браузер взаємодіє з фронтендом, обмінюючись інформацією з бекендом та API системами. У нас вже налаштована інфраструктура для енд-тестів, які ми пишемо за допомогою Cypress.

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

Ми також використовуємо скріншот-тести, які емулюють поведінку користувача, зокрема, взаємодію з бекендом. Наш бекенд реалізований на Golang і використовує Gyrkin Syntaxes для стандартизації тестових сценаріїв. Повноцінний запуск тестів включає емуляцію різних подій, використання реальної бази даних та мокапи іншими мікросервісами. Це дозволяє перевіряти всі компоненти в інтеграції та надає високий рівень впевненості у функціональності задачі.Щодо контентних тестів, ми використовуємо Cypress для написання як енд-тестів, так і компонентних тестів. Також ми мокуємо бекенд та сервісну комунікацію для ізольованого тестування окремих віджетів чи сторінок. Щодо юніт-тестів, ми їх пишемо в основному для складних частин логіки або калькуляцій на фронтенді. Запуск Snapshot-тестів допомагає перевіряти, чи коректно відрендерено HTML. Також ми активно використовуємо можливості observability для швидкого виявлення та вирішення проблем. Логи, інформація та помилки системи логуються в ELCastTec та Sentry, а мікросервісна архітектура дозволяє ефективно використовувати трейсинг. І використовуємо для метрик і алертів Prometheus і Grafana, також є зовнішній Uptime Checker. Щодо CI-CD, у нас є два середовища: стейджинг і продакшн. Ми використовуємо Trunk-Based Development. Чому Trunk-Based Development? Тому що з мого досвіду роботи, наприклад, з більш складними схемами, такими, як класичний GitFlow, це призводить до того, що задачу ви починаєте реалізувати пачками.

Тобто у вас є Dev Environment, Staging Environment, якийсь Pre-Production Environment, Production Environment, і тут неважливо, чи є у вас QA чи немає. Ви починаєте накопичувати ці задачі пачками і переганяти їх між цими середовищами. Це точно не найкращим чином впливає на Time-to-Market і не сильно підвищує рівень якості. З мого досвіду, ми вибрали просту схему, де є майстер-гілка. Якщо ми в неї щось мерджимо, ми маємо чітку домовленість: якщо ти мержиш свою задачу в майстер, це має працювати. Ми реалізуємо кожну фічу незалежно. Тобто, знову ж таки, оскільки немає необхідності нічого накопичувати, тестувати або готувати релізи, після мержу задачі вона виливається. На фронтенді виникає питання, як протестувати зміни, якщо немає тестових середовищ. Коли ми готуємо мердж-реквест, ми можемо вилити свою задачу на девгілку, тобто на окремий сабдомен, і розробник може перевірити, що все коректно. Людина, яка робить код-рев'ю, також перевіряє. Якщо все в порядку, ми мержимо задачу, і вона виливається в продакшн.

Щодо бекенду, у нас вже з самого початку були написані всі тести. Тому при мержі задачі вона одразу виливається і на стейджинг, і на продакшн. Чому так? Тому що у нас висока впевненість, що якщо тести пройшли, це дорівнює тому, що воно з 99% вірогідністю буде працювати коректно на продакшн. На фронтенді ми покищо пізніше проводили тестування, тому тегуємо релізи на продакшн руками. Але нічого не заважає тегувати кожну задачу.

Щодо фронтенду, ми також використовуємо канарійські релізи. Як ми до цього прийшли? Надамо трошки контексту. Основний канал трафіку для нас - PPC. Користувач бачить рекламу в Google чи Bing, клікає і переходить на наш сайт. Вартість залучення користувача сильно коливається протягом дня. У одному кварталі в мене було п'ять мітингів із темою "ROI drop". Це означає, що вартість закупівлі зростає. Ми збираємо дані, де вирішуємо, що змінювалося в продукті. Стратегія релізів кожної задачі вносить зміни.

Ми приймаємо рішення про відкат контенту, хоча ніхто не має чіткої впевненості, що проблема саме на стороні продукту, а не у волатильності маркетингу. Тому ми встановили канарійські релізи. Перше, вони дозволяють фіксувати та відділяти волатильність від конкретних продуктових змін. Ми можемо чітко проаналізувати метрики. Друге, ми виконуємо всі зміни через A/B-тести, якщо це відноситься до воронки. Але деякі зміни складно протестувати A/B-тестами, наприклад, якщо ви вносите великі рефакторинги чи зміни в архітектурі. Ми аналізуємо саме бізнесові метрики, а не тільки технічні. Це дозволяє нам здійснювати автоматичний роллбек чи автоматичний накат на 100%, якщо щось піде не так. Зазначимо основні плюси NoQA. Основний - зниження показника Time-to-Market. Це важливо для нашого стартапу, де час є критичним. Інший плюс - більша залученість розробників. Це також спрощує project management, усуваючи зайву ролі та комунікацію. Відсутність зайвих слотів і командні мітинги не затягуються. Щодо мінусів - розробники повинні виділяти додатковий час на роботу, яку може виконати NoQA.

Так, це дійсно вірно, але частково, тобто, щодо бекенду, через 3 місяці після того, як ми наняли QA, я запитав бекенд розробників, чи допомагала їм якось безпосередньо QA в їх роботі. Відповідь була чесна: у 95% випадків - ні. Це були просто точкові задачі, де ця людина допомагала. На фронтенді там трошки все дійсно складніше, там розробники витрачають більше часу на тестування того, що все працює коректно, співпадає з дизайном. У нас немає піксельного досконалості, тому дійсно витрачається більше часу. Проте, з плюсів, за рахунок зменшення комунікації, потреби передавати задачі і пояснювати, плюсів від цієї схеми в нашому випадку більше.

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

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

По висновках, ключова ідея, яку я б хотів, щоб ви винесли з цієї презентації, це те, що якість - це досить широке поняття, яке включає в себе не тільки класичне QA чи QC, чим QA займаються, але й інші аспекти. На більшості проєктів це річ, на яку потрібно дивитися більш системно. Що тут можна порекомендувати? Ну, перше, потрібно знайти людину, яка дійсно буде в цьому зацікавлена. Тут є два варіанти. По-перше, можна сказати, що це ми беремо нашого лідера QA, тепер нехай він пушить цей процес. В принципі, мабуть, такий сетап ефективний, але мені здається, що цим має питанням задаватися людина на рівні CTO або керівника. Чому? Тому що ця людина може мати вплив безпосередньо на всі процеси, на всі взаємодії і на організаційні структури.

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

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