Вхід і реєстрація
Різне · 16 листопада, 8:20 2837
Pavlo Trepytion, Technical Community Manager в DOU.ua

Хто насправді винен у багах?

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Натрапив на історію одного тестувальника, який уже 12 років працює в QA, і він каже, що йому остаточно набридло бути «крайнім». Коли баг вилітає в прод, CTO перш за все дивиться на нього. Під час root cause analysis питання звучить одне й те ж: «чому QA це не спіймали?»

І щоразу після цього — вимога більше тестувати, посилити контроль, переглянути покриття. Але ніхто не запитує: «Чому розробник допустив баг?» або «Чому BA не зібрав повні вимоги?»

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

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

Теми: QA, баг, обговорення
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
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
Serhiy Brytskyy Працює в Oracle 24.11.2025 17:31

В нормальній компанії не шукають винного, а шукають причину (Root Cause Analysis), і думають, як такого уникнити в майбутньому (Corrective Actions Preventive Actions).
Винний переважно відповідальний за оці всі бюрократичні процеси, все задокументувати і тд :)
Звісно, якщо хтось буде робити ці самі помилки знову і знову, такого по голові не погладять.

Відповісти
Підтримати
Vitalii D Frontend Engineer в Tide.co 24.11.2025 15:30

у нас в тімі немає мануал QA, але є автоматизатори.
за баги в проді прилітає дев-ам, а ми кажемо найміть манул QA і тоді багів буде менше(звісно ж це не гарантовано)

Відповісти
Підтримати
Kostiantyn Reu Principal Data Engineer в Hims & Hers 19.11.2025 06:39

В конечном счете баги это неотъемлемый аттрибут кода/приложения.

Кто владелец кода, тот наследует и его аттрибуты.

Не ?

Відповісти
Підтримати
Grichka Bogdanoff 19.11.2025 05:11

Ніхто не винен, так влаштована природа. QA — один з факторів який заміксований в цих природніх процесах, а не той, хто завжди крайній.

Відповісти
Підтримати
Oleg Korol POWER Ops, again 18.11.2025 23:34
Хто насправді винен у багах?

комахи ж

res.cloudinary.com/...​/yuqrua2hrcigb6tslt9g.jpg

Відповісти
Підтримати
BodjaSyper QA Lead 18.11.2025 20:37

QA is a journey, not a destination! :)

А якщо серйозно, то про якість повинні дбати всі, робота QA наставити багато блокпостів які будуть відсіювати 99% багів, і верифікувати 100% основних бізнес тест кейсів

Якість починається ще на етапі рекваєрментів, дизайну архітектури та юай, де мусять бути враховані бест практіси, далі повинні бути:

— статичний аналіз всіх пул реквестів якоюсь тулою
— код ревю від колег, з обовязковим рекваєрментом по апрувах, а для особливо важливих чи складних ПРів тестування ще на фіча бранчі
— хороше покриття юніт тестами в CI/CD
— хороший тест енв, який максимально наближений до кастомерського
— хороше покриття мануальними тестами
— суттєвий відсоток покриття автомейшин тестами, які раняться періодично, з репортами хелс стейту
— час (!) на якісне мануальне тестування, думки outside of the box
— далі всі види функціонального та нон-фашнкшинал тестування нових фіч
— регрешин тестування
— апгрейди, даунгрейди, бекап/рестори
— планування реліз ролбеку, дізастер рекавері, узгодити реліз з усіма стейкхолдерами
— В ім’я Отця, і Сина, і Святого Духа
— Реліз!

Відповісти
Підтримати
Maria Manual QA 18.11.2025 13:06

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

Відповісти
Підтримати
Дмитро Дем'яненко BA/UX 17.11.2025 20:00

багмени — міфологічні істоти що живуть в клавіатурі та псують код.

Відповісти
Підтримати
Mykhailo Tsymbaliuk Front-end developer в ABM Cloud 17.11.2025 13:11

Це вічне питання! Відповідальність завжди спільна, але роль QA — бути не «крайнім».

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

До речі, сучасні AI-асистенти чудово допомагають мінімізувати такі ризики, виступаючи як «другий пілот» (Co-pilot), який може підсвітити ризиковані зони або edge-кейси, які людина могла пропустити. Якраз досліджую цю тему в каналі QA Co-pilot.

Але так, в кінці дня відповідальність несе вся команда.

Відповісти
Підтримати
Oleg Marchuk R&D Manager в Playtech 17.11.2025 12:10

«Перед публікацією — перечитуйте, що ви публікуєте» — це щоб повністю позбавитися помилок ))

Відповісти
Підтримати
Emma Orlova SDE 17.11.2025 11:20

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

Для зменшення дефектів потрібно налаштовувати процеси (ревю, репорти, аналітика, автоматичне тестування)

Відповісти
Підтримати
Andrey Rogovsky 17.11.2025 09:17

Во всем виноваты люди — человеки. Баги богов. Боги багов.

Відповісти
Підтримати
Vic Programmer 24.11.2025 10:04

Так оригинальное сленговое название дефекта — bug (жучек), это когда имеено мотылек замкнул одну из схем ENIAC и вся команда искала почему компьютер выдает не прмвтльный результат на тестовой задаче.

Відповісти
Підтримати
Andrey Rogovsky
Oleksii 17.11.2025 08:15

У нормальних командах з гарною інженерною культурою quality assurance — відповідальність всієї команди. І неважливо, чи є у такій команді dedicated QA, чи його немає

Відповісти
Підтримати
Просто Анон 17.11.2025 01:11

Все правильно, нащо тоді QA якщо за баги будуть відповідати інші?

Відповісти
Підтримати
Roman Gorodishcher Principal Engineer в Twilio 16.11.2025 23:36

Ну якщо в процесі задіяні QA, то вони і винні: нехай проводять «post mortem», 5-whys, і зʼясовують що треба було робити інакше.

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

(disclaimer: останні 10 років я працював в командах де не було ролі QA, включаючи Amazon і Twilio, і трохи де номінально QA були але організаційно вони були підпорядковані іншим менеджерам і користі з них було не багато).

Відповісти
Підтримати
Юра 16.11.2025 18:55

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

res.cloudinary.com/...​/lsulr9uz5utooy5nthgm.jpg
res.cloudinary.com/...​/nuejg5neqd9wifeyxdkt.jpg
res.cloudinary.com/...​/myemk4ctkhu7vy5k8k04.jpg

Відповісти
Підтримати
джаваскрипт энджоер 16.11.2025 18:12

чья ответственность за то чтобы дефекты не проходили в релизы? вопрос действительно сложный

эх, вот бы был такой человек(или люди), кто мог бы за этим следить и как-то гарантировать что это не случится. можно было бы тогда это назвать контроль качества, например, или гарантия качества. или лучше по-модному на английском: quality control или quality assurance

oh wait...

Відповісти
Підтримати
Ярослав Характерник Golang Developer в DocHQ 16.11.2025 18:11

Винен CTO.

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

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

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

Відповісти
Підтримати
Просто Анон 17.11.2025 01:17
Задача CTO та менеджменту — організувати процес так, щоб зменшити кількість помилок

Так він це і робить

Коли баг вилітає в прод, CTO перш за все дивиться на нього. Під час root cause analysis питання звучить одне й те ж: «чому QA це не спіймали?»
Відповісти
Підтримати
Ярослав Характерник
Ярослав Характерник Golang Developer в DocHQ 17.11.2025 02:57

Задача RCA — визначити першоджерело проблеми.

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

CTO кожного разу робить висновок «посилити тестування». Кожного разу там або відсутній RCA, або ж замало тестувальників, бо тестувальник виконує ще й інші ролі згідно з оригінальним постом.

Відповісти
Підтримати
Просто Анон
Просто Анон 17.11.2025 07:38
CTO кожного разу робить висновок «посилити тестування».
тестувальник виконує ще й інші ролі

А в них не просто тестувальник,

який уже 12 років працює в QA

За 12 років людина вже могла б освоїти як вводити процеси що покращують якість а не тупо баги шукати

Відповісти
Підтримати
Ярослав Характерник
Volodymyr Dvernytskyi Senior Developer в beeDynamics 16.11.2025 17:46

Оце головна фундаментальна трагедія сприйняття проблем людством, айті не унікальне тут.

Хто винен?

Постійно пошук винних.
Постійно пошук як перекинути відповідальність.

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

Виник баг? Одразу питання:

Як його вирішити з мінімальним впливом на користувачів і з максимальною швидкістю?

Які інструменти в майбутньому допоможуть уникнути таких багів?

Де недоліки методології, що пропустила таке?

Де недоліки в процесах, що проблема виникла та не була відловлена?

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

А пошук винних це не конструктив.

Питання просте, люди в цьому місці є кваліфікованими чи ні? Якщо ні, очевидна проблема в тому як вони тут опинились. Необхідно фіксити саме це.

Це доречі нескінченний та неперервний процес. Цим просто постійно необхідно займатися щоб отримувати високу якість.

Відповісти
Підтримати
Beaver Green 16.11.2025 18:17
Питання просте, люди в цьому місці є кваліфікованими чи ні? Якщо ні, очевидна проблема в тому як вони тут опинились. Необхідно фіксити саме це.

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

А пошук винних це не конструктив.

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

Відповісти
Підтримати
Volodymyr Dvernytskyi
Volodymyr Dvernytskyi Senior Developer в beeDynamics 16.11.2025 18:42

Індивідуальна відповідальність має бути, без неї нікуди.

Я пишу не про колективну відповідальність.

А про фокус на результаті, процесах та інструментах, а не на винних.

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

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

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

А роботу робить кожен в межах своєї відповідальності, тестувальник тестує — розробник розробляє, і так далі.

Відповісти
Підтримати
Beaver Green
Beaver Green 16.11.2025 19:09
А про фокус на результаті, процесах та інструментах, а не на винних.

Individuals and interactions over processes and tools

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

Правда в тому, що аби бути лікарем тільки в одному органі (наприклад — окулістом), людина вчиться 6 років. При тому що око людини влаштовано майже однаково в усіх людей і це не змінюється з часом.
Коли девелопер приходить на проєкт, який до нього розробляли 10 років на різних технологіях і у який постійно додаються фічі — він починає вносити зміни через 2 місяці онбордінгу!
У жодній інший професії такого не має! Ніхто не вигадує новий токарний станок кожні 2-3 роки. А креслення за якими виготовляють деталі на заводі допускають похибку у міліметри чи менше.
ІТ це досі не інженерія — а «кустарне виробництво», де люди, які самі навчалися чомусь, щось збирають, як вміють, з того мотлоху, який у них є.

Відповісти
Підтримати
Volodymyr Dvernytskyi
Просто Анон 17.11.2025 20:06
Які інструменти в майбутньому допоможуть уникнути таких багів?

Де недоліки методології, що пропустила таке?

Де недоліки в процесах, що проблема виникла та не була відловлена?

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

Так це і є обов’язки QA.
Манкі клікінг це тестери.

Відповісти
Підтримати
Volodymyr Dvernytskyi
Beaver Green 16.11.2025 17:42

З мого досвіду роботи у топ-ІТ компаніях з командою тестувальників з Індії.
Віддаємо фічу на тестування. Її асайнять на індійського QA. Той першим чином дзвонить девелоперу який її робив і питає:
QA: А де мені потестувати? У нас нема енвайромента, чи на ньому не ті данні — допоможіть, я заблочений.
DEV: Добре — я засетапив нову віртуальну машину, усе налаштував — беріть тестуйте.
QA: А що саме треба перевірити — можете показати що ви додали?
DEV: Ось я пошарив екран і показую вам як працює фіча, яку ми додали.
QA: Дуже дякую!
Після цього QA переводить фічу у статус «тестування пройшла».
Якщо девелопер не відповідає — то тестування буде висіти «заблоковане».

Відповісти
Підтримати
Beaver Green 16.11.2025 17:33
Хоча помилка може статися на будь-якому етапі: від невірно сформульованого юзерсторі до некоректної імплементації. Та попри це, відповідати найчастіше доводиться саме QA.

Саме тому QA мають відрізнятися від манкі-тостерів!
Робота QA починається ще на етапі формулювання вимог та юзерсторі. Це відповідальність QA перевірити чи вимоги повні та не протирічиві. Чи юзерсторі покривають усі важливі кейси а не тільки «хеппі-пас». Це QA має завести баги і перевести їх на BA аби той закрив усі сумніви.
Далі QA працює паралельно з девелоперами. Поки вони імплементують, QA підготовляє тест-кейси і може навіть починає писати авто-тести.
Коли девелопери віддають фічу у тестування — у QA вже є план як її тестувати, а може вже навіть є готові авто-тести для перевірки. Якщо тести впали — відразу заводиться бага на девелоперів.
У такому випадку:

ніхто не запитує: «Чому розробник допустив баг?» або «Чому BA не зібрав повні вимоги?»

І QA можуть хіба що похвалити що він знайшов проблему вчасно.
А от коли баг випливає вже на проді — то тут виникають питання у першу чергу до QA, точніше до його тест-кейсів. Якщо QA не описав і не протестував сценарій, на якому падає помилка — чому? Може це якась маловірогідна ситуація? Може це взагалі якась тимчасова помилка інфраструктури (таймаут)? А може навіть якась ддос атака чи хитра спроба зламати систему?
QA не винен автоматично в усіх проблемах. Але він — це людина, яка відповідає за якість системи. І вимоги до цієї якості також мають бути описані QA!
Не існує 100% надійних програм без багів. Але 99% надійність та 99.99% — це вже велика різниця. Скажімо на мільйон веб-сторінок у день 1% помилок — це 10 000, а 0.01% — це 1000.
Відповідно і вимоги до тестування мають бути набагато більші — і це буде коштувати грошей та часу.
Хто має відповісти на питання скільки тестування достатньо? Тільки QA (або краще QA Lead). Отже якщо кількість проблем на продакшені більша за очікувану — хто винен у першу чергу?

Відповісти
Підтримати
Vic Programmer 16.11.2025 17:38
Робота QA починається ще на етапі формулювання вимог та юзерсторі. Це відповідальність QA перевірити чи вимоги повні та не протирічиві.

А чому виключно QA? Типу розробник має братись за задачу не розуміючи її ? Це зона повноважень усієї команди насправді, при чому першочергова. Не забуваємо що головна причина провалу проєктів за незалежними дослідами Carnegie Mellon University так і PMІ — 30% це помилки із вимогами, різноманітні включно із не вірним розумінням вимог розробниками. Нормальний QA коли йому скинуть якісь дев домисли вже зовсім, це відфутболить. Інша справа, що часто ситуація — коли просто немає можливості в певний час зібрати вимоги і є потреба в експериментальному програмуванні — R&D.
Пентагон Department of Defense навіть ввів методику оцінки фреймворку, в рамках загального аудити підрядника і команд Adaptive Acquisition Framework

Відповісти
Підтримати
Beaver Green
Beaver Green 16.11.2025 17:57
А чому виключно QA. Типу розробник має братись за задачу не розуміючи її ?

Звичайно розробник також має братися за задачу тільки коли всі вимоги зрозуміли.
Але! Вимоги як має правильно працювати нова фіча (так званий «хепі-пас») можуть бути зрозумілі. А от як ця фіча буде працювати разом з усіма попередніми — це вже інше питання!
Девелопер імплементує новий сценарій — а скільки там було попередніх сценаріїв і які конфлікти можуть виникнути — він може не уявляти.
Саме тому і має виділятися час QA на тестування вимог, аналіз існуючих юзер-сторі та тест-кейсів і пошук можливих конфліктів. Також це робота QA знайти можливі «корнер-кейси» і перевірити їх коли девелопер скаже що «усе готове».
А ще QA має висвітлювати потенційні ризики: наприклад відсутність повної документації як система працює зараз, або розуміння що область де будуть робитися зміни зараз не покрита тест-кейсами. Отже ПМ може або щось зробити з цими ризиками — або потім не мати претензій до QA якщо ці ризики вилізли на проді.

Відповісти
Підтримати
Vic
Vic Programmer 17.11.2025 01:07

Комрад, ми переписуєм в форум Роберта Мартіна — дядька Боба, Clean Architecture. Я особисто пожалкував, що ця книга мені не попалась значно раніше ніж була треба. Особливо вона була би мені корисною ще на минулій роботі, році десь в 2008-9. Ми робили продукт і в ньому періодично в продакшн потрапляти баги, що скінчувалось нескінченним сапортом.
Потім якось прийшов професійний QA в контору, почав робити співбесіди і наймати і в нас в команді з’явився нормальний QA. До того іноді підсаджували дівчат, яких доводилось вчити елементарно описувати баги, а в одному випадку навіть набирати на клавіатурі і взагалі базовим навичкам користувача ПК. І їх бігом переводили до аутсорсінгово відділку, доки він існував. Продати начальнику необхідність QA як процесу фактично не вдавалось. Бо з варіантів винайняти людину і купити собі нову машину з продажі корпоративної ліцензії — звісно був обраний варіант, нова машина. І прорахувати і показати на числах, що так він купляє японський кросовер — а так би купив собі скажімо німецький чи японський позашляховик, це те що мені треба було би тоді робити. Потім професійні вже QA які таки були найняті розповіли, що існує ціла теорія із тестування і контролю якості. Чому дівчат бігом переводили до аутсорсу — бо там закривалась позиція за яку платив клієнт з США і це давало 300%+ прибутку і більше. Клієнт давав $30 на годину, дівчині платити $2.5.
Чому потрібні QA — а тому що ми використовуємо науково-доказовий метод при розробці програмного забезпечення, в сутності контроль якості — це той самий експеримент чи практичні випробування. Математично-доказовий метод Едгера Дейстери — провалився і є аналогом вічного двигуна в ІТ вже багато десятиліть.

Отже ПМ може або щось зробити з цими ризиками

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

Відповісти
Підтримати
Beaver Green
NarutoUA 16.11.2025 16:38

тестувальників десяток а користувачів десятки тисяч. Тому деякі компанії не тримають QA відділ, а тестують все на продакшені

Відповісти
Підтримати
Євгенія Невська HR-manager 16.11.2025 17:07

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

Відповісти
Підтримати
NarutoUA
NarutoUA 16.11.2025 17:29

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

Відповісти
Підтримати
Євгенія Невська
Vic Programmer 16.11.2025 17:12

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

Відповісти
Підтримати
NarutoUA
yvs2014 16.11.2025 14:06

треба додати що goroh (якщо то він) доволі зручний щоб подивитися відповідну інфо, і з достатньо зручним інтерфейсом

Відповісти
Підтримати
Юра
yvs2014 16.11.2025 13:01

Виглядає як звичайний side-effect галерних оверспеціалізацій, перемасштабування, і пошуку взаємодії у таких крупних структурах. І чомусь нагадало байку (чи не байку) яку десь бачив на yt — коли кодер знайшовши випадково баг виправив його — після чого несподівано отримав по шапці від умовно манагера процесу чи тімліда чи ще когось — бо це не в зоні його відповідальності виправляти баги (тобто виглядало як те що він має тільки генерувати код з̶ ̶б̶а̶г̶а̶м̶и̶), і тому він ламає цим відлагоджений процес розробки.

Відповісти
Підтримати
Vic Programmer 16.11.2025 15:28

Тому власне і системи гнучиких процессів типу SAFe, бо коли задіяно скажімо 200 людей то вже потрібні методи взаємодії. Один з них це робочі групи по 7 людей максимум, щоби спростити комунікації.
Дійсно був випадок півтора року тому назад, коли питання по копіюванню текстового СSV файлу в GCP Claud Storage із on demand сервера проходило коло пошуку в чиїй зоні відповідальності (повноважень) той on demand сервер (розробка велась із допомогою Test Data Management) через замовників і купу начальства. Як з’ясувалось, що це сусідня команда з якою ми виявляється спілкувались через 5 кіл начальства і замовника і менеджер якої, був безпосереднім коучем нашої інженерінг менеджерині (мене бомбануло не слабо тоді, хоча я таке бачів безліч разів).
Ще було 2 години перемовин і як виявилось, дівчини адміна яка керувала тим сервером на цих перемовинах не було. Там була повна форма бюрократії від тест ліда їх команди — категоричний ні, без повного технічного репорту висновку їх тех ліда та узгоджених регламентів по роботах, що де та коли буде робитись.
З іншого боку то була система забезпечення медичного обладнання однієї великої американської медичної корпорації і підхід до стабільності був особливий, як і в хелскере сфері в цілому, або наприклад авіації. TTM — не був вирішальним фактором.

Відповісти
Підтримати
yvs2014
yvs2014 16.11.2025 16:40

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

Відповісти
Підтримати
Vic
Vic Programmer 16.11.2025 17:02

А чому до кого ? Писати треба — що не так. Тобто які результати очікуються, які результати по факту і як цього досягнути, шляхи до відтворення. Таким чином будь який розробник зможе визначити першопричину і виправити помилку.
Інша справа, що бувають часто випадки під час експлуптації — коли немає шляхів до відтворення, але щось йде не так, наприкдад минулий проект — в чеках була невідповідність на один пенні через різні методи математичного округлення при ділінні на 100. Ніби нічого такого, все працює штатно — разом з тим через цю невідповідність в 1 пенні, вже можна подавати в суд, що і зроблять конкуренти через треті структури.
То вже інша справа — то Root Cause Annalise — RCA. Це вже звісно про кваліфікацію і гибокі знання та досвід, як в цілому так і в конкретному проекті та системі та її бізнес процессах.

Відповісти
Підтримати
yvs2014
Kristi Mitsik 16.11.2025 12:02

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

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

Відповісти
Підтримати
Олег Дорожко 16.11.2025 11:56

Баг це знахідка. Його виправлення вдосконалює систему.

Відповісти
Підтримати
Vic Programmer 16.11.2025 11:41

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

Відповісти
Підтримати
Denys Adamov 16.11.2025 12:16
вимагає письмових фіксацій вимог і домовленостей

+++

Відповісти
Підтримати
Vic
Donald Trump 16.11.2025 10:57
Під час root cause analysis питання звучить одне й те ж: «чому QA це не спіймали?»

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

Відповісти
Підтримати
Vic Programmer 16.11.2025 11:32

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

Відповісти
Підтримати
Donald Trump
IRD 16.11.2025 13:09

А раніше був винен індус зі стековерфлоу. Простіше якось було.

Відповісти
Підтримати
Donald Trump
Denys Adamov 16.11.2025 10:51

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

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

Відповідального за реліз — аби поревʼювати цей «баг» і визначити, що з ним робити

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

Тому тестувальнику з 12-ма роками досвіду видно не везе з процесами, і фокус там на вині, а не реальному покращенню. Однак питання — чи він намагався змінити ці процеси?

Відповісти
Підтримати
Vic Programmer 16.11.2025 12:04

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

Відповісти
Підтримати
Denys Adamov
Denys Adamov 16.11.2025 12:14

В певному сенсі синоніми, але так, я це розділяю якраз з точки зору повноважень. Бо навіть якщо тестувальник і знайде першопричину, то над планом усунення та реалізацією плану саме він навряд чи працюватиме. І тут треба саме відповідальний, який буде «овнити» цей процес

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

Відповісти
Підтримати
Vic
Нікіта Рашній 23.11.2025 15:11

Все так. У подібних випадках скільки б там років досвіду не мав тестувальник має бути звільнений. По перше коли звільнити 15-20% штату на такому падаючому ринку інші будуть боятись і працювати набагато більше що перекриє падіння перормансу на ці 15%, по друге, вони будуть заткнувши пельки робити свою роботу а не думати про ходіння по співбесідам чи щось таке. Коли немає часу поїсти чи сходити в туалет — як ти підготуєшся до співбесіди?

Відповісти
Підтримати
Denys Adamov
Вова Москаленко 16.11.2025 10:38
Але ніхто не запитує: «Чому розробник допустив баг?»

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

Відповісти
Підтримати
Vic Programmer 16.11.2025 11:52

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

Відповісти
Підтримати
Вова Москаленко
Вова Москаленко 16.11.2025 17:06
Зазвичай більшість багів за статистикою пов’язані із невірним використанням API та інтерфейсів.

Еее, ну це, якщо чесно, вже якийсь дитячий садок або лютий ковбой кодинг. Щоб таке вилізло, треба провтикати валідацію, тести, тестування самими QA/AQA (куди вони взагалі дивляться, якщо не ганяють такі кейси). І взагалі, якщо у нас шось кудись стирчить, то Господь дав нам контрактне тестування.
Тому тут явно або щось зі статистикою або я недооцінив кількість гівняних проектів.

Відповісти
Підтримати
Vic
Юра 16.11.2025 09:36

що означає слово «винен» ? 🤔

Відповісти
Підтримати
Володимир Обрізан Директор в Design and Test Lab 16.11.2025 09:38

ВИНА ТА ЇЇ ФОРМИ

Стаття 23. Вина

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

Стаття 24. Умисел і його види

1. Умисел поділяється на прямий і непрямий.

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

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

Стаття 25. Необережність та її види

1. Необережність поділяється на кримінальну протиправну самовпевненість та кримінальну протиправну недбалість.

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

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

zakon.rada.gov.ua/laws/show/2341-14#Text

Відповісти
Підтримати
Юра
Юра 16.11.2025 11:58
Виною є психічне ставлення особи до вчинюваної дії чи бездіяльності,

один я не розумію, шо тут написано? 🤔

Відповісти
Підтримати
Володимир Обрізан
Юра 16.11.2025 11:59

а шо, трудові відносини вже регулюються Кримінальним Кодексом? 🤔

Відповісти
Підтримати
Володимир Обрізан
Володимир Обрізан Директор в Design and Test Lab 16.11.2025 20:15

Та скоріше би почали регулюватися. Може тоді програмісти почнуть автотести писати.

Відповісти
Підтримати
Юра
yvs2014 16.11.2025 12:41

ви́нний, ви́нен, ви́нна, ви́нне
goroh.pp.ua/Тлумачення/винний

у цьому контексті пункт 1.2 «Який є причиною чого-небудь»

Відповісти
Підтримати
Юра
Володимир Обрізан Директор в Design and Test Lab 16.11.2025 09:34
Як думаєте, хто реально має нести відповідальність за баг у проді

CTO.

Відповісти
Підтримати
Andrii Sevastianov Senior Developer в TeamDev 16.11.2025 09:28

Тестування програм може показати наявність помилок, але ніколи не може показати їх відсутність! © Дейкстра

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

І щоразу після цього — вимога більше тестувати, посилити контроль, переглянути покриття.

Експоненційне зменшення інтенсивності виявлення дефектів у часі = часто марно витрачений час та кошти

Але ніхто не запитує: «Чому розробник допустив баг?» або «Чому BA не зібрав повні вимоги?»

Errare humanum est

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

Яке тупе запитання. Кількість багів в проді це властивість системи розробки, а не провина окремих людей.

Відповісти
Підтримати
Олег Дорожко 16.11.2025 09:07

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

Відповісти
Підтримати
Undisclosed User 16.11.2025 08:54

Добре що не Петро Порошенко

Відповісти
Підтримати
Andy K

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.