Про роботу · 27 січня, 15:30 2040

Pavlo Trepytion, Technical Community Manager в DOU.ua

Чи можна та потрібно оцінювати ефективність QA через кількісні метрики?

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

У QA часто можна почути про метрики ефективності тестувальників. Наприклад кількість знайдених багів, їх severity, швидкість проходження тестів... Здавалося б, простий спосіб заміряти продуктивність, але не тут то було.

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

«Кількість знайдених і задокументованих багів не показує ефективність. Будь‑який менеджер, який використовує це як метрику, повинен соромитися».

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

А ви стикалися з подібними метриками у своїх командах? Які альтернативні способи оцінки тестерів ви вважаєте справді корисними і справедливими? Як це працює у вас в команді?

Теми: QA, метрики, обговорення, робота

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному1

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Oleksandr Panchenko Automation QA Engineer, SDET в nav4it 01.02.2026 09:28

Не вихнаходьте велосипеди. Всі метрики до якості прописані в державному (і міжнародному) стандарті ISO 9001:2015. Якщо клікнете тут — то почитаєте повний та офіційний текст стандарту.

Відповісти

Підтримати

Viktor Zhurbenko Dev 01.02.2026 10:04

Iso9001 скоріше стандарт з правильного ведення документації і прозорості процесу для аудиту. Якість то iso 27000, де норм розписані характеристики або Ieee 829 де розписаний тест план
Але жоден не відповідає як оцінити саме тестовий процес, всі зосереджені на якості продукту

Відповісти

Підтримати

Oleksandr Panchenko

Vic Programmer 01.02.2026 10:33

Воно в ISO/IEC 15504 , який по суті є CMM. Станадарт оновлений до ISO/IEC 33001:2015 standards.iteh.ai/...34f553/iso-iec-33001-2015
Серія стандартів ISO:9000 оцінює якість організації в цілому, тоді як серія 330xx в сутності спроможність організації до створення програмного забезпечення. Модель CMM, яка в онові стандарту розроблено на замовлення Пентагону, для оцінки спроможності підрядниками виконати замовлення.
Станом на 1999, по їх дослідам 80% організацій які створювали ПО взагалі, знаходились на рівні 1 — тобто хаос чи «ляп ляп і в продакшн».
І тільки 5% організацій реально здатні виробляти програмне забезпечення із відтворюваним результатом і забезпеченням потрібного рівня якості.
Зараз оцінку постійно роблять Gartner та Forrester, через те що більшість компаній індійські результати аналогічні. В КНР — там партія і уряд прийняли міри.
Стандарт оцінює ланцюжок, Traceability де розробка йде в процесі: Вимога -> Дизайн -> Код -> Тест-кейс -> Результат тесту. Якщо цей ланцюжок розірваний, компанія автоматично не отримує навіть рівень 1.

Відповісти

Підтримати

Viktor Zhurbenko

Viktor Zhurbenko Dev 01.02.2026 01:35

З моєї точки зору є дві об’єктивні метрики — defect leakage, release time.
Якщо багато багів на проді — фігня, якщо реліз триває дні і тижні ще більша фігня.

Тобто від моменту
PR merge до моменту deploy to prod має бути максимум 1 день
При цьому кількість дефектів не має рости по мірі розвитку продукту, все інше то суб’єктивне і залежить від проекту і продукту

Маю на увазі user facing issue. Кількість внутрішніх взагалі не важлива

Відповісти

Підтримати

Andrii Sevastianov Senior Developer в TeamDev 01.02.2026 01:49

PR merge до моменту deploy to prod має бути максимум 1 день

Тільки, наприклад, отримати підпис драйверу від Microsoft це справа не одного дня, наприклад. Ідея зрозуміла, але я не був би таким категоричним зі строками.

Відповісти

Підтримати

Viktor Zhurbenko

Viktor Zhurbenko Dev 01.02.2026 01:52

App release в store теж два тижні займає, але сам артефакт готовий і чекає зовнішніх дій а не роботи команди

Відповісти

Підтримати

Andrii Sevastianov

Andrii Sevastianov Senior Developer в TeamDev 01.02.2026 01:58

Готовий то готовий, але чи ризикнеш ти поставити що останній PR нічого не зламав?

Відповісти

Підтримати

Viktor Zhurbenko

Viktor Zhurbenko Dev 01.02.2026 02:02

Ну так власне з норм процесом — так. Саме задача якісного QA процесу зробити так щоб CI приводив до релізу а не до чергового раунду ручного тестування

Відповісти

Підтримати

Andrii Sevastianov

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 02.02.2026 12:29

Тобто від моменту
PR merge до моменту deploy to prod має бути максимум 1 день

Абсолютно не реально не деяких продуктах. У вас що, спрінт триває 3 дні?

Відповісти

Підтримати

Viktor Zhurbenko

Vic Programmer 02.02.2026 12:38

Деякі системи побудовані на ідеї, що реліз може бути виконано якнайшвидше. Буквально після будь якого багфіксу, усе автоматизовано так — що цикл регресійного тестування із end to end і т.д. займає лічені години. Тобто система контролю змін в продукт, надає дуже велику верогідність, більше 0.9, що внесені зміни нічого не зламали із документованої поведінки.
Досягти цього не практиці — тобто DevOps SDLC, зовсім не просто. І не дешево, треба підготовлений персонал і відповідне обладгання.

Відповісти

Підтримати

Dmytro Yakymenko

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 02.02.2026 13:03

Тільки деякі продукти так побудовані.
Деякі розроблюються і тестуються місяцями до релізу. Деякі — роками.

Відповісти

Підтримати

Vic

Ігор Колосов Project manager в ScoreApp 31.01.2026 16:07

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

Відповісти

Підтримати

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 02.02.2026 12:35

кількість фіч які були релізнуті без багів

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

Відповісти

Підтримати

Ігор Колосов

Олекса Мащиць засновник в QA Україна 31.01.2026 13:43

Чи можна оцінювати ефективність будь-чого через кількісні метрики? Ось питання, на яке треба відповісти. Чи існує якась категорія, де таке вимірювання не варто робити? Або — ефективність у якому контексті? У соціології ми виміряємо все для певної мети, яка інколи лишається виключно в межах соціології.

Тобто, саме вимірювання це «сферичний кінь у вакуумі». Помістіть його в контекст, щоб зрозуміти користь.

Чи можна міряти швидкість у км/год? А у милях/год? У вузлах? Чому у місті обмеження у 50 км/год? На всі ці питання є конкретна відповідь.

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

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

Отже, саме по собі метрика бездушна. Ані погана, ані гарна. Це ми та процес надаємо їй якостей.

Відповісти

Підтримати

Vic Programmer 31.01.2026 14:08

На це є ціла теорія пастки числел. Когнетивне упередження зветься — gambler’s fallancy ru.wikipedia.org/wiki/Ошибка_игрока
Питання по відрядній оплаті (fixed price) ставлять не ІТ менеджери в ІТ постійно. Бо так працювало на класичних конвеїрах. Ціль сама по собі вірна, мінімізувати ризики і максимізувати прибуток. Та це вимагає числьних методик вимірювання ефективності праці. От так і з’явились системи які вимірювали ефективність роботи программістів по кількості створених операторів, і предприїмчові індуси в нульові писали навмисно незмістовні оператори які не робили нічого корисного лише використовували процессор та пам’ять. Тобто ефект був прямо протилежний, вироблявся лайно продукт і ще і росла собівартість.
Вимірювати ефективність роботи QA не по якості продукту, тобто мінімуму багів пвд час експлуатації продукту, а по кількосиі відкритих jurassic тікетів ровнг аналогічний бред.
Ну а бухгалтер який ненавидить сіс адміна який «нічого не робить» і отрмує зарплату, це вже мем. Та суть в тому, що як він постійно щось робить — то постійно щось зламано.
ІТ як і низка інших індустрій, скажімо створення одежі модельльєри і т.д. мають свою специфіку. І вимірбвання кубометрами викопаного груниу, чи кількістю покладених цеглин ефективність на загал не змістовно. Хоча міряти звісно треба, але для інших цілей.

Відповісти

Підтримати

Олекса Мащиць

Олекса Мащиць засновник в QA Україна 31.01.2026 14:35

Міркуючи про хибний висновок Монте-Карло, завжди кажу, що метрика без динамічного показника є безглуздою для тестувальника. Тобто, важливо не стільки те, що ми знаходимо щотижня 100 багів, скільки те, що ми (опускаємо зараз, чому) вирішили, що маємо досягти лише 70 багів, і тоді міряємо кількість, яка є основою для інших метрик: чи кількість багів зменшується, чи збільшується та яка швидкість цього руху.

При fixed price для менеджменту важливо оберігати команду від зайвої інформації та нюансів контакту. Метрики для замовника не завжди є нашими робочими метриками. Це лише в ідеальному світі замовник знається на процесі (як і свій же менеджмент) і у нас повна прозорість з усіма показниками. Тому хтось має захищати команду. Менеджер — від замовника. Тімлід — від менеджера тощо.

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

Відповісти

Підтримати

Vic

Andrii Sevastianov Senior Developer в TeamDev 30.01.2026 13:41

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

Відповісти

Підтримати

Vic Programmer 30.01.2026 14:11

Колега, прибрати науково доказовий метод геть з процессу розробки ПЗ, і перейти до математично доказових і повністю формальних методів вимірювання, ще по пропозиції Едсгера Дейкстра, це завітна мрія усього ІТ бізнесу з 60-х років минулого сторічча. Ну дуже хочеться повторити прогнозованність принципів массовго виробництва Веніціанського Арсеналу впровадженного Генрі Фордом, який був секретом успіху бізнесів в США загалом усе двацяте сторічча. Коли можна стати із секундомером і заміряти скільки буде загвичуватись гайка в середньому на конвеїрі по зборці Ford T, чи готуватиметься гамбургер в ресторані McDonald’s значно простіше прогнозувати прибутки компанії і приймати рішення для розміщення капіталів.
Ще в IBM та інших компаніях типу Bell Labs/AT&T, Пентагону і т.д. усі спроби зазнали фіаско (див статистику від Фредерік Брукс Міфічна Людиногодина), навідміну від випуску аппаратного забеспечення. По індустрії зараз розповсюджені підходи різноманітні SDLC, та улюблений метод хаосу який у 80% випадків має місце.
Чому постійно постають питання дивних форм формалізації і пастка чисел? В ситемі освіти в усьму світі дірка із ІТ специфічним менеджментом. Більшість менеджерів навчають в різних місцях массовому виробництву Форд/Рокфеллер по різниз программах MBA і вони це переносять і на ІТ (у Cтіва Джобса було інше бачення www.youtube.com/watch?v=bVKcxK_tVBM), хоча специфіка давно усім відома. Маленькі команди до 7 людей, короткі цикли планувань в 2 тижні з конкретними цілями, дослідна експлуатація, описання вимог на мінімально необхідному рівні тощо. Більшість же інженерів яких підвищили в менеджери — не знаються на будь якому менеджменті взагалі, бо цьому не вчились, тому і хаотичний процесс.

Відповісти

Підтримати

Andrii Sevastianov

Andrii Sevastianov Senior Developer в TeamDev 30.01.2026 17:11

Ваші аргументи навіть читати смішно... Це як у 50-х роках запевняти, що польоти у космос неможливі, бо сам Ціолковський про це мріяв! Навіщо згадувати книги Брукса, коли він писав їх у 70-х, а Calculus of Constructions, необхідна теоретична база, з’явилася лише у середині 80-х? Тому чесно, читати про усі спроби до 90-х це марно витрачати час, бо люди з камʼяними топорами не могли збудувати літаки апріорі.

Так, люди в 70-х роках намагалися написати верифіковану операційну систему. Автоматичної перевірки доказів не було, їх писали на папері... Швидко з’ясувалося, що люди на папері помиляються так само, як і в коді. Що це доводить? Тільки те, що не було відповідних інструментів. А от у 2009-му написали seL4, бо вже був і Haskell, і Isabelle.

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

Відповісти

Підтримати

Vic

зайшов почитати що тут пише 30.01.2026 17:27

Нічого не зрозуміло, але дуже цікаво

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

Це як? «науково доказовий метод» він не математичний?
Чи навпаки «математично доказових» вони не наукові?

Відповісти

Підтримати

Vic

Vic Programmer 30.01.2026 17:40

Доведення через матиматичну індукцію (індукція це метод формальної логіки разом із дедукцією, аналізом та синтезом), а не екперементальними перевірками (тестуванням).
Як прикдад він матиматично довівів власний Алгоритм пошуку найкоротшого шляху на графі.
Дивіться книгу Роберта Мартіна Clean Architecture, відомого консультанта із не фунціональних вимог та структурної якості ПЗ та методиста — там це буде перша глава.
В якості альтернативи дядько Боб пропонує систему яку розробив разом із : Кентом Беком, Вордом Каннінгемом, Мартіном Фаулером і низкою іших методистів та експертів, XP з використанням декількох шарів тестування і автоматизації тестування, від модульних тестів до End to End.https://uk.wikipedia.org/wiki/%D0%95%D0%BA%D1%81%D1%82%D1%80%D0%B5%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F
Станом на сьогодні це напевно найросповсюдженіша методолгія із розробки ПЗ, разом із процессами Agile та DevOps SDLC.
Навіть як у вас підхід ляп-ляп і прод, дуже часто ви матимете якісь частки процессу бо «так усі роблять». Оце усі по перше було далеко не завжди (я ще пам’ятаю цього не було і навіть модудьні тести по конторах не писали, а QA ще по суті починалось в нашому ІТ) , по друге винайшли професійні методисти і консультанти.

Відповісти

Підтримати

зайшов почитати що тут пише

зайшов почитати що тут пише 30.01.2026 21:11

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

повертаючись до початкової фрази (звідки й почалася розмова)

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

це нісенітниця

Відповісти

Підтримати

Vic

Vic Programmer 30.01.2026 21:21

Ну як нісенітниця, теоретичну основу під це закладали ще на самих початкових етапах розвитку кібнетики та інформатики, у цього вічного двигуна з трійками Хоара і т.д. досі є адепти.
Як відомо відладка та тестування, це процесси які займають найбільше робочого часу ІТ команд. Відповідно якщо дати математичну срібну кулю — то собівартість виготовлення ПЗ має впасти різко в рази. Та ставка зараз йде швидше на методи штучного інтелекту, аж до рівня самосознання і само програмування.
Математика теж наука, а науково доказовий метод (Evidence Based Software Enginering) — це така назва тестування. Звідци і терміни «документована поведінка», «не документована поведінка» (undefined bechavior).
Там самі ідеї індуктивних доказів йдуть в мови типу Haskel і т.д. з сенсом, сворення мов програмування в яких не буває undefined bechavior. Те що при цьому код усеодно може породжувати не бажану для вимог программу то вже інша справа. Ну а С та ассемблер — повністю зворотня філософія «не плати за те що не використовуєш». Тобто перформанс має значання, хоча програмувати складно. Інструмент гострий як бритва яким можна як створити шедевр, так і кроваве місиво.
Скажімо відсутність перевірки границь массиву, це мінус декілька інструкцій в бінарному коді. На загал може так статись що в нормальних умовах експлуатації, программа на С чи ассемблері як то ядро операційної системи, працює в десяткі а то і сотні разів швидше, за аналогічну написану скажімо на Haskel. Але щось йде не так і стається що завгодно, залежить від конретної программно аппаратної середи. Десь загальний захист пам’яті в одній середі, і нічого в іншій, а десь типу MS DOS втрата напруги.

Відповісти

Підтримати

зайшов почитати що тут пише

yvs2014 30.01.2026 21:51

якщо дати математичну срібну кулю

рожеві мрії програмування ...)

для тривіальних випадків «срібні кулі» не дуже цікаві, а для інших — пошуковцям тих «єдинорогів» колись-таки прийдеться ознайомитися з Gödel’s theorems

Відповісти

Підтримати

Vic

Andrii Sevastianov Senior Developer в TeamDev 31.01.2026 18:18

Теорема Гьоделя тут не працює. Вони, як і проблема зупинки, стосуються створення універсального алгоритму, який перевірить будь-яку довільну програму... А нам це і не треба. Нам треба перевірити конкретну програму. Якщо код написаний так, що його неможливо верифікувати... ми просто переписуємо його так, щоб верифікатор його з’їв.

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

Відповісти

Підтримати

yvs2014 31.01.2026 18:28

просто переписуємо його так, щоб верифікатор його з’їв

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

Відповісти

Підтримати

Andrii Sevastianov

зайшов почитати що тут пише 30.01.2026 22:02

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

нє, нє, нє, ще раз повертаємося до оригінальної цитати.
Цитата:

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

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

Відповісти

Підтримати

Vic

Andrii Sevastianov Senior Developer в TeamDev 31.01.2026 19:09

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

Просто нарешті з’явилися обчислювальні потужності. Як Rust не міг виникнути в 70-х через те, що компіляція та перевірка правил власності займала би місяці, так і верифікація за Хоаром стала практичною лише зараз, коли залізо дозволяє SMT-солверам доводити складні інваріанти за прийнятний час.

Звідци і терміни «документована поведінка», «не документована поведінка» (undefined bechavior).

Визначена, неуточнена, залежна, невизначена.

Там самі ідеї індуктивних доказів йдуть в мови типу Haskel і т.д. з сенсом, сворення мов програмування в яких не буває undefined bechavior.

Це просто набір розумних слів, звалений у купу... Можна мати мову без UB (як Python), де ніякої індукції для розробника немає... І навпаки, можна використовувати індуктивні докази для верифікації коду на C, де UB повно, щоб довести, що конкретно у вашій програмі жодне UB ніколи не вистрілить...

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

Інструмент гострий як бритва яким можна як створити шедевр, так і кроваве місиво.

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

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

Про «в сотні разів»... це смішно. Реальна різниця 1.5-2 рази, виключно за рахунок GC. А в деяких конкурентних тестах можна побачити паритет або навіть виграш Haskell, якщо мова йде про STM, багато алокацій, тощо.

Відповісти

Підтримати

Vic

Vic Programmer 30.01.2026 13:24

Через те що ми використовуєм науково доказовий метод в розробці ПО (див Роберт Мартін ака дядько Боб Сlean Architecture) вважається що в будь якій программі є недокументована поведінка, навіть як це Hello world. Але недокументована поведінка яка може виникати в певних сценаріях, може не впливати на практичну цінність і роботу програмно аппаратного комплексу. Задача інженера із оцінки якості — Quality Assurance предоставити команді розробки інформацію, щодо якості виробляємого програмного продукту. Якість є здатність якогось виробу виконувати свою головну функцію і не виходити зі строю під час виконання цієї функції.
Зокрема це досягається процессом верифікація — при виробленні ПО підвердження того що ПО виконує саме те що вимагалось, та валідації — тобто що описані функції программи виконують заплановані результати (проходять тести). Також QA проводять дослідну експлуатацію, задля доповнення вимог з розряду «в це поле можна вводити тільки цифри, чи дати — але не букви» хоча такі вимоги початково не закладались, тим не менше впливають на користувацький досвід.
Відповідно OKR та KPI як для програмістів так і QA є стабільно працюючий программно аппаратний комплекс, випущений в заплановані строки та бюджет і запланованим рівнем якості — усе. Міряти кількість тікетів, операторів, жопочасів, сторіпойнтів і т.д. в тупу не змістовно. Хоча такі показники таки є і мають первний сенс, якщо виявлено, що вони впливають на головні показники KPI та OKR. Скажімо завалено спрінт (не виконані закледені і запланована ціліь в означений період) коли було знайдено занадто багато багів і т.д. Тоді треба знаходити root cause і прибирати його, наприклад не описані вимоги чи занадто слабо описані і т.д. і т.п.

Відповісти

Підтримати

зайшов почитати що тут пише 30.01.2026 14:01

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

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

всі тести можуть проходити зелененьким, тільки такий продукт в такому вигляді, все ж бути замовникові юзлесс/непотрібним (не валідним)

Відповісти

Підтримати

Vic

Beaver Green 29.01.2026 15:00

Думка що работу в ІТ не можна оцінювати кількісними метриками (KPI) — це ще один міф. Походить він від того, що менеджери дуже часто не розуміють процесу розробки і тому беруть метрики, які тільки шкодять. Як то кількість рядків коду чи кількість знайдених багів. І потім, коли це насправді шкодить — команда каже що краще без метрик.
Але метрики можуть бути дуже корисними, якщо змінити мету: замість вимірювати «хто краще працює», метрики мають показувати де втрачається час, ефективність, гроші. Для цього треба добре розуміти процес розробки.
Наприклад: хтось залив у main неробочий код. Назавтра сотні девелоперів прийшли, стягнули останню версію — і не можуть працювати через незрозумілі помилки. Кожен з низ почне витрачати час, аби з’ясувати що сталося, писати в чати. Через 1-2 години нарешті усі дізнаються що сталося, хто винний, чи є якийсь трюк аби обійти проблему, чи треба відкатуватись на вчорашню версію, коли зайде фікс. Один такий інцидент коштуватиме сотні людино — годин! Так само проблеми з інфраструктурою, CI/CD, віртуальними машинами. Більд сервер помер — а запасного нема? Робота сотен людей стоїть поки девопси у милі лагодять. І втрати будуть коштувати як два нових сервера.
Стосовно QA також усе просто: QA створив багу і кинув скріншот на якому можна побачити тільки тест помилки або навіть просто що буля акась джаваскріпт помилка. Ні повного тексту помилки, ні колстека, ні кроків що робити, ні енвайромента, ні тестових даних. Що буде робити девелопер? Він витратить декілька годин намагаючись відтворити баг — потім піде до QA. Той напевне вже тестує щось інше і відразу показати помилку не зможе. У кращому разі вони разом зможуть зарепродюсити. Девелопер піде намагатися повторити у себе. У гіршому випадку (якщо з комунікацією погано) девелопер поставить баг у Can’t Reproduce і поверне QA. І так від може ходити туди — сюди кілька раз.
В ідеальному світі QA побачив би баг — натиснув кнопку у тулі яка збере усі деталі, може ще й запише відео і створить баг. Далі QA зробить скнепшот віртуалки чи контейнерів — і девелопер зможе за пів-години усе підняти, повторити і підключити дебаг. Або може і дебаг не буде треба якщо є детальна телеметрія. Так само коли баг буде пофікшено: QA підніме ту саму конфігурацію, проапдейтиться до нової версії (відразу і апдейт перевірить) — і впевниться що помилка зникла.
Кожен девелопер (думаю QA також) знає що на великих проєктах як мінімум 40% часу витрачається не на роботу — а на «супутні проблеми»: щось підняти, налаштувати, почекати поки щось зробиться, почекати поки хтось відповість і т.і. Цей час ніхто за закладає в естімейти, його ніхто окремо не репортить — тому він як «темна матерія» впливає на роботу команди, але залишається прихованим.
Чи є тут можливості для оптимізації, підвищення ефективності, заощадження коштів? Звичайно — і величезні! Бо якщо час витрачає кожна людини — а людей багато. Зробили аби білд проходив за 15 хвилин замість 30? Заощадили десятки годин щодня — сотні годин щомісяця! Те саме якщо відмінили непотрібний мітинг, автоматизували заповнення звітів, купили QA тулу, яка автоматизує створення дефектів. А тим більше зараз — коли AI дозволяє автоматизувати навіть те, на що раніше не могли написати скрипти. Зараз якщо людина витрачає кожен день час на однакові дії — це вже неефективно. Керівник не має усе робити сам — він має налаштувати роботу підлеглих. Фактично зараз кожен ІТшник — це керівник AI помічників — і має використовувати їх аби ефективно заощаджувати власний час.
І ті самі метрики, про які тема, як раз і може збирати AI! Як думаєте: реально налаштувати AI аби він відшукав і порахував «прихований час», який витрачається неефективно? І бажано зробив це без встановлення анальних трекерів чи відео-спостереження за кожним девелопером.

Відповісти

Підтримати

Vic Programmer 30.01.2026 14:38

Як думаєте: реально налаштувати AI аби він відшукав і порахував «прихований час», який витрачається неефективно? І бажано зробив це без встановлення анальних трекерів чи відео-спостереження за кожним девелопером.

Реально і працює, щоправда як і справжній менеджер в офісі спостерігає зі сторони, так LLM аналізує скажімо мітинги чи процесси і видає рекомендації. Скажімо нема онбордінгу, або передачі іформації процессу Knowledge transfer, Ефект Силосних Веж про існування якого я дізнався від AI ( усі стикались, але не в курсі що з цього були наукові досліди www.yakaboo.ua/...aVm7FBS0hDmWC_vNQgz1UIy7S)
це коли різні відділки або команди замість того щоби співробіничати конкурують між собою, в цей час виграє зовнішній до компанії конкурент, не фективні комунікації, відсутності агенд та чітких цілей нарад, відсутність планування, відсутність чітких кол повноважень та обов’язків, miss communication, відсутність керування ризиками і т.д. і т.п.
Що цікаво коли люди таке кажуть їх позбуваються, а коли автоматика яку створили люди на базі наукових підходів і відомих рекомендацій взятих із накових праць — задаються питанням.

Відповісти

Підтримати

Mark Tsyrulnyk CTO в Lumos.codes 03.02.2026 01:19

>Думка що работу в ІТ не можна оцінювати кількісними метриками (KPI) — це ще один міф

А розвінчання міфу буде? Бо щось тексту полотно а набору тих самих метрик немає...

Як писали вище, кількісні метрики реально працюють лише у «конвеєрних» процесах.

Виготовити 50 деталей за зміну згідно хреслення з браком менше 3% відсотків.

А тепер спробуйте сформулювати такі метрики для «творчих» професій і одразу отримає купу розмників які на тачпаді вертіли ваші метрики.

Зробили аби білд проходив за 15 хвилин замість 30?

Це не метрика. А от всі білди проходять не довше ніж 15хв це метрика. А домашка для вас чого ця метрика не працює.

В ІТ метрики не можуть бути вирішальним фактором, тобто ви не зможете побудувати «виробництво» суто на метриках, але при правильному налаштуванні під поточний стан бізнеса, вони будуть давати вам гарні сигнали.

Ну і якщо б хтось міг описати що таке «гарні метрики під поточний стан бізнесу» він би отримав нобелевку чи що там за таке видають. Як то кажуть change my mind

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 27.01.2026 22:42

Коли був джуном-тестувальником, за 9 місяців знайшов 1000 багів.
Сусідка-сіньор знайшла щось із 200.
Результат: мені підвищили зарплатню на 50 баксів, і я звільнився.
Це про неоцінювання ефективності.

Відповісти

Підтримати

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 29.01.2026 12:42

Ефективність неможливо оцінити суто по кількості багів. Один може знайти за день 10 low-severity багів, які так і будуть висіти в беклозі роками.
А інший може за той самий час знайти один critical-severity баг, провести root-cause analysis, зібрати логи і завести його так, щоб деву, якій буде це фіксити, було з першого погляду зрозуміло — де проблема і чому з’явилася (а іноді — і як її пофіксити ;-) ).
То хто з цих двох буде більш ефективним і корисним для проекту?

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 29.01.2026 12:54

realmensch.org/...e-of-the-two-programmers

Відповісти

Підтримати

Dmytro Yakymenko

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 30.01.2026 12:03

Шикарна історія, раніше не бачив, дякую.
Але мій комент трохи про інше — він про користь для проекту. Ваша історія — про те, як ти вмієш цю користь «продати» менеджменту.
Я за 10 років в IT неодноразово бачив ситуацію (і сам в ній був), коли дві людини працюють однаково на однакових ролях, але один(одна) з них просувається і по рейзам, і по личках значно швидше за рахунок софт скілів — вміння «продати» свою роботу менеджменту.

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 30.01.2026 13:03

Ну моя історія за те, що:
* Задача QA — знайти та оформити усе, що бачиш.
* Таки є різниця ефективності в рази.
* І якщо ефективність не впливає на зарплатню — то ці люди йдуть.

Відповісти

Підтримати

Dmytro Yakymenko

Oleksandr Suvorov Corporal under NDA :) в AFU 30.01.2026 14:08

* Задача QA — знайти та оформити усе, що бачиш.

Я не згоден із такою постановою задачі.

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

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 30.01.2026 14:42

QA is Quality Assurance. Це людина, котра гарантує якість, і репортить усі проблеми.

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

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

Відповісти

Підтримати

Oleksandr Suvorov

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 30.01.2026 15:09

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

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 30.01.2026 16:01

Тоді QA є частиною обов’язків PO, бо саме він відповідає за баланс якості та швидкості — і за результати бажних релізів.

Відповісти

Підтримати

Dmytro Yakymenko

Просто Анон 30.01.2026 16:13

QA is Quality Assurance. Це людина, котра гарантує якість, і репортить усі проблеми.

Гарантувати якість != спамити тікетами.

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 30.01.2026 17:04

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

Відповісти

Підтримати

Просто Анон

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 30.01.2026 17:27

усі проблеми мають бути задокументованими

Один з основних принципів тестування — вичерпне тестування неможливо.
Тобто неможливо сказати, що ми знайшли усі проблеми :-)

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 30.01.2026 17:31

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

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

Відповісти

Підтримати

Dmytro Yakymenko

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 30.01.2026 17:35

* Задача QA — знайти та оформити усе, що бачиш.
* Таки є різниця ефективності в рази.

Знов ж таки, ефективність тестувальника != кількість заведених багів

* І якщо ефективність не впливає на зарплатню — то ці люди йдуть.

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

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 30.01.2026 17:43

Знов ж таки, ефективність тестувальника != кількість заведених багів

Ефективність тестувальника — це те, наскільки мало залишається невідомих багів в релізі. Чим більше знайшов — тим менше лишилося.

Відповісти

Підтримати

Dmytro Yakymenko

yvs2014 30.01.2026 21:03

Ефективність тестувальника — наскільки мало залишається невідомих багів в релізі

а відомі можна вважати фічею, більше фіч — більш ефективна командна робота, має деякий сенс)

Чим більше знайшов — тим менше лишилося

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

p.s. це трохи поза ниткою дискусії щодо суті тестування саме по собі

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 30.01.2026 21:13

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

Відповісти

Підтримати

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 02.02.2026 12:37

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

це неможливо виміряти

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 02.02.2026 12:50

І що з того.

Якщо в релізі було Х багів, і тестувальник А знайшов 100 багів, то лишилося Х — 100 багів.

Якщо було ті ж Х багів, але тестувальник Б знайшов 10 багів, то лишилося Х — 10 багів.

Здається, завжди Х — 100 < Х — 10.

Відповісти

Підтримати

Dmytro Yakymenko

BodjaSyper QA Lead 30.01.2026 11:55

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

root-cause analysis,

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

Відповісти

Підтримати

Dmytro Yakymenko

Vic Programmer 30.01.2026 16:13

При якісному багрепорті, пофіксити можна значно швидше ніж лісти писати промпт і взагалі запускати ШІ. Та нажаль баги вони тому і Bug-и, що того метелика який замкнув схему десь траба знайти і виправити першопричину винекнення. А це найважче, бо зазвичай прояви такі — аномальні записи про помилки в логах на сервері продакшена, або почав валитись якийсь авто тест якому 10 років і ніхто нічого не чіпав (а там на древьному сервері почалось погано дискам на RAID контроллері перенесли на віртуальний сервер наршеті і усе запрацювало) і т.д. і т.п. От тут ШІ — невідомо як поможе, може дасть вірну наводку типу «піди перевір що з дисками» може ні. Далеко не усі баги це логічні помилки через порушення контрактів чи вхідні чи віхідні данні поза очікуємих алгоритмом і задачею діапазонами. Як приклад React Native UI виглядає здорово під iPhone, а десь на Samsung чи Huawei — усе поїхало і не можна натиснути на кнопку.

Відповісти

Підтримати

Просто Анон 30.01.2026 16:15

пофіксити можна значно швидше ніж лісти писати промпт і взагалі запускати ШІ.

Спасибі що добровільно уступаєш своє робоче місце девам які юзають ШІ

Відповісти

Підтримати

Vic

Vic Programmer 30.01.2026 16:46

Тут мене весь форум прозвав ШІ ботом :) Баги пару разів намагався, а так у мене після ШІ часто обробка йде ручна верніше головою. ШІ це заміна Stack Overflow або прискорювач пошуку по ресурсам швидще, та так є агенти які можуть зараз прості речі типу CRUD зробити одразу вірно, навіть ассемблер та SIMD робити, ще якийсь час назад — не могли.

Відповісти

Підтримати

Просто Анон

Mark Tsyrulnyk CTO в Lumos.codes 03.02.2026 01:27

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

Відповісти

Підтримати

Denys Poltorak Embedded | C++ (opentowork) 03.02.2026 11:30

Гіперефективному джуну більшу частину бо:
1) для нього це буде більший % підвищення зарплатні, відповідно, більша утримувальна сила
2) він є більш цінним і одночасно більш дешевим співробітником для проекту

Відповісти

Підтримати

Просто Анон 27.01.2026 16:35

Все має вимірюватись.

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

Відповісти

Підтримати

Dmytro Shevchenko 27.01.2026 17:50

«Все» — це погано прописана вимога) Можете розписати?

Відповісти

Підтримати

Просто Анон

Alexandra Kovalyova Senior QA Consultant в Certified Unicorns 27.01.2026 19:58

Тут прикол в фокусі уваги.
Ефективність знаходження дефектів до релізу точно варто міряти і для цього існують спеціальні метрики. Але вони знаходяться НЕ в категорії показників ефективності конкретної людини-тестувальника. Тобто дослівно існують категорії a) people metrics, b) project metrics, c) product metrics, d) process metrics — і одна з розповсюджених проблем це використання метрик з b-d для оцінки людей.

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

Відповісти

Підтримати

Просто Анон

Просто Анон 27.01.2026 20:43

root cause цього потрапляння багів на прод, і о диво може виявитись що тестувальник тут взагалі ні до чого

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

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

Решта це тугодуми які хочуть отримувати ІТ ЗП, шукаючи баги типу «1 піксель вліво», і постійно ниючи що деви їм не пояснюють що вони міняють у фічах.
Вміння розрізнити 404 і 500 помилку і заюзати постман це вже знання рівня сіньор

Відповісти

Підтримати

Alexandra Kovalyova

Roman та й Roman 28.01.2026 14:54

В тебе якась травма чувак, через призму якої ти міряєш весь світ.

Відповісти

Підтримати

Просто Анон

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 29.01.2026 12:38

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

Це був QA, не тестер

Решта це тугодуми які хочуть отримувати ІТ ЗП, шукаючи баги типу «1 піксель вліво», і постійно ниючи що деви їм не пояснюють що вони міняють у фічах.

А ось це тестери, ще й поганенькі, судячі з опису xD

Відповісти

Підтримати

Просто Анон

Vic Programmer 30.01.2026 13:42

Не усі баги можна знайти «не на проді». Звідки і сленгова назва Bug, коли мителик замкнув одну зі схем Mark 2 під час його тестування і команда довго не могла з’ясувати, чому компьютер не працює так як би мав за теорією на тестовій задачі. uk.wikipedia.org/wiki/Баг
А так, скажімо бізнес стратегія Microsoft по TTM як пріорітету та Apple чи Oracle по забеспеченню якості усім відома.

Відповісти

Підтримати

Просто Анон

Andrii Sevastianov Senior Developer в TeamDev 30.01.2026 14:18

Спробуй знайти баги у CompCert. Усі знахідки дослідників за останні 15 років стосувалися або коду парсера, але це було до його верифікації, з версії 3.0 все ок, або неоднозначності паперового стандарту, або дрібних невідповідностей у моделях конкретних процесорів (спека, знову поза кодом). У верифікованому ядрі компілятора, де відбуваються складні оптимізації, багів не знаходили взагалі. А проблема однозначного розуміння вимог це вже окреме питання

Відповісти

Підтримати

Vic

Vic Programmer 30.01.2026 14:22

А це звідки взялось ? sf.snu.ac.kr/...sepcompcert/compcertbugs
Зазаз же інформація доступна миттєво, через AI.

Відповісти

Підтримати

Andrii Sevastianov

Andrii Sevastianov Senior Developer в TeamDev 30.01.2026 14:48

Це приклади помилок в специфікації, про що я писав. Тобто людина помилилася, коли описувала правила гри (стандарт Сі чи залізо), бо нечітко описано. Яке замовлення, такий і результат.

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

А от багів типу алгоритм глюкнув не знаходили ще.

Відповісти

Підтримати

Vic

Vic Programmer 30.01.2026 15:19

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

Відповісти

Підтримати

Andrii Sevastianov

Andrii Sevastianov Senior Developer в TeamDev 30.01.2026 16:00

Слухай, ну от дивись... Якщо взяти традиційні компілятори типу GCC чи Clang, то там ситуація чітка. Є круте дослідження «Finding and Reporting Bugs in C Compilers», і цифри кажуть самі за себе.

Десь 20-30% багів це реально про «не так зрозумів стандарт». А от інші 70-80% це чиста помилка реалізації. Особливо в оптимізаціях.

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

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

Відповісти

Підтримати

Vic

Vic Programmer 30.01.2026 16:33

Вимогу «не зламай логіку програми після оптимізації» неможливо зрозуміти якось не так.

І де тут логічний формалізм, це абсолютно не формалізована не функціональна вимога. Та же формалізація, «Після змін усі тести мають бути зеленими на СІ, а білд в статусі Success» буде куди як більш чіткою вимогою. Ми сперичаємось із того що давно описано індустрією, ще 50 років тому. А також робились досліди Карнегі-Меллон на замовлення Пентагону тощо (Модель СMM uk.wikipedia.org/...Capability_Maturity_Model).
Напевно вони не просто так працювали над різними Algol 68 та Ada, а зараз вимагають робити перестроги в мовах програмування (як виявилось їм куди як більше подобається Java ніж Rust, до якого вони теж мають притензії. У Java більш чітко формалізована — модель пам’яті і т.д.) тощо. Хоча є і інша думка, Деніс Річі — Герб Саттер про норми до дитячих велосипедів, які застосовують до спортивних велоспедів для Тур де Франс. Власне так і був створений С Денісом Річі, не тому що не вміли по іншому — а саме тому що потрібен був саме такий хакерський інструмент із хакерськими характеристиками для розвитку UNIX. Де там істина — ХЗ, десь по середені.

Відповісти

Підтримати

Andrii Sevastianov

Andrii Sevastianov Senior Developer в TeamDev 30.01.2026 17:29

Яка ще «неформальна вимога»? Навіть віслюку зрозуміло, як формалізувати вимогу до компілятора: ∀ I, p : R(p, I) = R(O(p), I) де I вхідні дані, p програма, O оптимізація а R запуск програми на вхідних даних.

50 років тому навіть читати не буду, це як вчити квантову механіку за працями Демокріта. Світ розвивається...

Про зелені 100% покриті тести... так, формальна вимога, але безглузда: будь-який LLM напише тести, щоб уникати багів.

Відповісти

Підтримати

Vic

Maria Manual QA 27.01.2026 16:24

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

Відповісти

Підтримати

Dmytro Yakymenko Senior QA Engineer в GlobalLogic 29.01.2026 12:27

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

Якщо це маленький проект, то можливо і легше, якщо великий проект і на ньому є стратегії тестування і аналітика, то це — bad practice, і так краще не робити.
Як на проекті менеджер можу зрозуміти ефективність тестувальника, якщо він працює вже тиждень-два над фічею, а багів заведено нуль?
До того ж, заведення баги в джиру нормальному QA з нормальною англійською займає 1 хвилину і її немає сенсу не використати, ризикуючи забути про цю багу при регрешн тестуванні перед релізом. Інвестигейшн з пошуком root cause займає значно довше.

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

Повністю погоджуюся!

Відповісти

Підтримати

Maria

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

Ваша пошта

Не підписуватись