Економіка тестування/вартість якості (Cost of quality)
PreviousТехніки оцінки тестів/оцінка трудовитрат на тестування (Test Estimation)NextПідхід до тестування (Test Approach)
Last updated
Last updated
Вартість якості (cost of quality): Загальна вартість витрат на завдання забезпечення та проблеми якості, що часто поділяється на вартість запобігання, вартість оцінки, вартість внутрішніх відмов та вартість зовнішніх відмов. (ISTQB)
Вартість якості розробки програмного забезпечення – це метрика, яка може допомогти перетворити програмне забезпечення на прибутковий інструмент для компаній. Підприємства дивляться на ROI, т. е. прибуток організації від інвестицій у розробку програмного забезпечення.
Якість досягається за рахунок ціни, і ця вартість називається COQ або Cost of Quality.
Щоб зрозуміти, як справи з тестуванням на проекті, потрібно проаналізувати його ефективність з погляду якості створюваного продукту та процесів. Тут можна розраховувати щільність дефектів, розриви, витоку, ефективність тест-кейсів, RC, FDP, DDP, PTC, MTTD, TDE та десятки інших метрик тестування. Але щоб визначити рентабельність такого тестування, необхідно рахувати гроші. Гроші та їх потік, що зростає, - основна мета замовника в більшості випадків розробки ПЗ.
Щоб правильно приймати управлінські рішення, тест-менеджеру необхідно повною мірою орієнтуватися у собівартості активностей із тестування, бачити зони розвитку та шляхи оптимізації процесів. Замовнику також важливо розуміти, за що він платить і чому, де він втрачає, а де заробляє. Один у полі не воїн, і завдання так званого архітектора – змусити бджіл реально усвідомити, скільки грошей вони приносять замовнику, скільки допомогли заощадити. Заощаджені гроші не обов'язково, але можуть формувати фонд для потенційного збільшення оплати праці тих самих бджіл.
Ціна та цінність
Будь-яка якість має власну ціну. Формально вартість якості становлять так:
COQ = Cost of control + Cost of failure of control або
COQ = Cost of Good Software Quality + Cost of Poor Software Quality;
Вартість хорошої якості (COGQ) = Витрати на запобігання + Витрати виявлення;
Вартість низької якості (COPQ) = Внутрішні витрати на відмову + Зовнішні витрати на відмову.
Якщо ж розглядати вартість якості в глобальному сенсі, то вона складається і з більш практичних аспектів:
Контекст проекту:
Розмір, обсяг та навантаження. Тут до ворожки не ходи, чим масштабніший продукт, чим більше у нього користувальницька аудиторія і складніше начинка, тим більше часу/ресурсів необхідно на його розробку, а значить і на тестування та підтримку.
Сфера/область. Розробка та тестування простого веб-сайту та медичного IT-продукту потребують різної кількості часу та ресурсів. Останній продукт має більш складний функціонал, тому для нього, як правило, потрібно кілька видів тестування, більше часу і хороший рівень фахівців.
Якість розробки. Якість коду, його валідність, масштабованість - все це впливає на стабільність функціональності, а значить і на те, скільки ресурсів знадобиться на забезпечення якості та підтримку.
Наявність тестової документації. Тестова документація – це такий плацдарм для тестування. Якщо вона вже є, то це скоротить терміни на занурення та роботу. Якщо ні – це збільшить терміни та бюджет, бо доведеться витратити на неї час.
Цифри та вступні проекти:
Скільки людей користуються сервісом;
Скільки людей скаржаться на обслуговування;
Скільки проблем у нас виникає після релізу;
Чи відбувається зростання/падіння бізнесу/грошей після релізу;
Які терміни і чи ми встигаємо з термінами релізу;
Наскільки задоволені ТОПи бізнесу у роботі IT-відділу (щоправда, це не виміряти цифрою, але показник також важливий).
Динаміка:
Наскільки динамічний продукт – частота оновлень та релізів.
Загальна вартість тестування досить велика, але варто лише оцінити вартість поганого тестування, як вона здається цілком прийнятною. Уоррен Баффет якось сказав, що ціна – це те, що ви платите, а цінність – те, що отримуєте. І не завжди вони збігаються. Якість ще означає цінність. Спробуйте сьогодні продати дуже якісну друкарську машинку або переконати замовника, що для нього цінніше зарелізувати фічу не післязавтра, а через рік, адже за цей час ви ще краще все протестуєте і якість буде вищою. Не вийде. Дорога ложка до обіду, і time to market ніхто не скасовував.
Завдання полягає в тому, щоб досягти оптимального співвідношення ціна/якість для замовника. Чому оптимального? Тому що в міру збільшення витрат на пошук дефектів та їх усунення вартість поломки буде знижуватися доти, доки не буде досягнуто оптимальної точки, після якої подальше збільшення активностей із тестування стане економічно недоцільним.
Як відбувається оцінка проекту
Робота вважається в годинах, які розраховуються за критеріями, виходячи з контексту та вступного проекту:
кількість браузерів/пристроїв для перевірки;
складність фіч/верстки;
документація;
терміни;
кількість осіб, які братимуть участь у проекті тощо.
Назвемо такий підхід, в основі якого лежить аналіз цінності та економічної доцільності тестування, value based, або value driven testing, і розглянемо його на прикладі.
QA team складається із трьох Manual QA. Це не Fixed Price проект, і ціноутворення тут а-ля Time&Materials. У нас 826 мануальних тестів, брак часу та цілий вагон проблем з якістю. І стоїть завдання покращити та оптимізувати тестовий процес.
Почнемо з масштабної ревізії кісток. Не вдаючись ні до ПСБУ, ні до МСФЗ, витрати можна поділити на: капітальні, або CAPEX (купівля серверів, ліцензій для софту, віртуалки тощо), операційні (витрати на прогін навантажувальних та автотестів, роботу серверів, репортинг та настроювання оточення) , Прямі (зарплата, витрати на навчання) та непрямі (дебаггінг, повторне тестування, оновлення та виправлення тест-кейсів). Для себе також фіксуємо постійні та змінні витрати. Не обов'язково слідувати боемівській COCOMO, все набагато прозаїчніше.
Перше, з чого варто почати, - визначити, скільки часу йде на ту чи іншу тестову активність у годиннику, а потім проаналізувати, як можна скоротити цей час. Тут і зниження трудомісткості, відносна економія праці та боротьба з неявним абсентеїзмом QA-команди.
W = I * T, де
W – трудовитрати, I – постійна інтенсивність праці або наш перформанс, а T – час роботи QA.
Короткий стиль оформлення, чітка пріоритезація, зменшення повторень у кроках та інша оптимізація тест-кейсів допомогла скоротити їх кількість з 826 до 611, що, своєю чергою, знизило витрати часу на їхнє проходження втричі. Ця активність та вироблені правила гри для всієї команди заощаджували час на проектування та виконання тестів на майбутнє. Приклад оптимізації тесту:
Аналогічні заходи торкнулися і активностей щодо написання документації (наповнення Wiki-проекту), репортингу та внутрішніх комунікацій. Але незважаючи на те, що витрати праці (часу) знижувалися, вони досягли своєї межі (див. графік). Скоуп регресії збільшувався, і хоча годинник, що звільнився, давали якийсь запас міцності, потрібно було щось ще.
Економія від масштабу
Left shit testing – основа теорії тестування. На мою думку, це чимось схоже на концепцію вартості грошей у часі. Один долар сьогодні дорожчий, ніж коштуватиме завтра, тому що його можна інвестувати вже сьогодні. А знайдений баг сьогодні також цінніший, ніж завтра, оскільки його можна раніше виправити.
Перевага досягається за рахунок швидкості та зниження простоїв – чим швидше ми отримуємо гроші та знаходимо дефекти, тим краще. Збільшення кількості перевірок при одночасному зниженні собівартості однієї перевірки неминуче призводить до економії масштабу. Хай живе її величність автоматизація! Розглянемо цей процес через призму економіки:
c = (TFC/Q) + AVC, де
з - собівартість виконання одного тесту, TFC - загальна величина постійних витрат, Q - кількість тестів, що запускаються, AVC - середні змінні витрати.
Отже, збільшення кількості перевірок за одиницю часу та зниження середніх змінних витрат на тестування – це два ключі у ваших руках до зниження собівартості знаходження одного дефекту.
Додавання QA Auto до команди збільшило постійні витрати QA Team, однак у перспективі обіцяло компенсувати це зростанням продуктивності.
Крапка беззбитковості автоматизації була досягнута не відразу, а лише коли значна частина тестів вже поранилася автоматично. Розрахунок критичного обсягу тестів для автоматизації можна обчислити, знову застосувавши економічний аналіз:
Критичний обсяг = Постійні витрати загалом на автоматизацію / (собівартість виконання одного мануального тесту - змінні витрати виконання одного автотесту).
Ефект операційного левериджу почав знижуватися, як і середні змінні витрати на тестування, а QA Manual побільшало часу на experience-based тестування. Це дозволило підвищити оборотність регресійних ран і значно збільшити скоуп спринтів.
Такий позитивний тренд говорив про те, що доцільно збільшити темпи приросту автоматизації, але додавання ще однієї одиниці QA Auto не витягувало ROI через збільшення постійних прямих витрат (оплати праці). Рішення було простим і швидким – взяти QA Auto Trainee з випробувальним терміном три місяці. За відсутності додаткових прямих витрат (оплати другого QA Auto) витрати на онбординг трохи знизили продуктивність першого QA Auto, але змінили загальну тенденцію до зростання.
Стадо бізонів
Стадо бізонів біжить зі швидкістю найповільнішого бізона, і якщо ваші автоматизатори працюють швидко, але змушені чекати мануальних тестів від QA Manual, то вся їхня швидкість втрачає сенс. Це bottleneck проекту і його потрібно терміново виправляти.
Якщо збільшити контроль за написанням мануальних тестів та привести формат їх написання до єдиного стандарту, значно зменшиться час QA Auto на їх розбір та конвертацію. Звичайно, не потрібно кидати всі сили на термінову підготовку безглуздих мануальних тестів для автоматизаторів для галочки. Тести повинні бути надійними мережами для лову багів, а їхній потік повинен лише з невеликим запасом покривати продуктивність Automation Team.
В іншому випадку зайве нагромадження тестів буде безглуздим, а втрати часу на їхній «простій» економічно необґрунтованій. Це стосується всього процесу тестування від планування до складання summary-репорту. Жодних ботлнеків.
Вибудовувати конвеєр непросто, але добре налагоджена виробнича лінія набагато цінніша за сотню окремих верстатів. Якщо добре покопатися і проаналізувати, можна забрати безліч зайвих активностей. І дуже важливо це зробити до автоматизації процесів. Інакше впровадження автоматизації лише збільшить продуктивність такого сизіфової праці.
Недостатньо робити все, що від тебе залежить. Як казав Демінг, спочатку треба знати, що робити, а тоді вже робити все, що від тебе залежить, покращуючи процеси. А з усіх моделей по покращенню мені найбільше подобається TMMi, п'ятий рівень якої, як кажуть, має багато спільного з ідеальним чоловіком: усі чули, але мало хто бачив.
Але прагне цього потрібно, і якщо ми маємо намір нести цінність замовнику, то саме час визначитися, де ми зараз і куди йдемо. Адже зазвичай, як співав гурт «Кіно», «Усі говорять, що ми в місці, всі говорять, але мало хто знає, в якому». Впровадження моделі для покращення тестування - теж бажана частина вашого value driven testing.
Ризик чи холодний розрахунок
Буває, що, незважаючи на знайдені баги, вирішується релізувати версію. Такі новини часто демотивують випробувачів. Починаються міркування на кшталт "ну, самі винні, що хочуть, нехай і роблять", "як можна з цим релізувати", "сенс було перевіряти" і так далі. Є й протилежна ситуація, коли тестували-тестилі, а багів не знайшли особливо. Всі знають, що ПЗ, як і людина, не буває абсолютно здоровим, а буває недообстеженим, тому й питання виникають «чому мало багів», «як саме перевіряли». Але якщо подивитися на ці ситуації з погляду цінності, то все стане на місця.
Розглянемо приклад. Ви збираєтеся релізувати фічу, яка принесе умовно $75K. З ймовірністю в 40% у цій версії може бути критичний баг, і якщо цей дефект просочиться до користувачів, то пов'язані з цим витрати становитимуть $150K. Можна не ризикувати – нічого не релізити, але й профіту тоді не буде.
Якщо релізим одразу, то з урахуванням ймовірності появи критичного бага очікувана чиста вигода становитиме: $75K - ($150K * 40%) = $15K
Рішення
Ні бага
Є баг
Релізим
75
-75
Чи не релізим
0
0
Можна витратити гроші на тестування, нехай теж $15K. Тестування може знайти баг, а може і не знайти, нехай 50/50, або 40% ділимо на 2. У такому разі ймовірність того, що баг потрапить до релізу, знизиться з 40% до 20%. Тепер давайте рахувати гроші:
Рішення
Ні бага
Є баг
Не знайдено нами
Знайдено нами
Релізим без тестування
75k
-75k
-75k
Чи не релізим
0
0
0
Тестуємо та релізимо, якщо тільки дефект виправлено
-15k
-15k
60k
Тестуємо та релізимо у будь-якому випадку
60k
-90k
60k
Перемноживши ймовірності настання подій та вартості їх наслідків, визначимо, яке рішення буде вигіднішим.
Чи не релізим взагалі: $0K
Релізимо відразу без тестування: $15K (це ми вже визначили вище)
Тестуємо та релізимо, якщо тільки дефект виправлений: −15K * 60% + (-15K * 20%) + 60K * 20% = $0K
Тестуємо та релізимо у будь-якому випадку: 60K * 60% + (-90K * 20%) + 60K * 20% = 30K
Примітно, що витрати на фікс не бралися до уваги, інакше третя стратегія була б менш привабливою. Це в жодному разі не означає, що не потрібно фіксувати баги, проте факт: найвигіднішою стратегією виявилася четверта – тестувати продукт та релізувати у будь-якому випадку. У це важко повірити, але для конкретного прикладу це так. Навіть якщо тести не знайшли багів (за умови, що вони здатні були), то вони дійсно приносять реальну економічну цінність, знижуючи ймовірність витоку помилок.
Як наслідок, набагато важливіша величина тестового покриття (ймовірності виявлення дефектів), ніж фактична кількість виявлених багів. Це як морський бій. Виграє той, хто досягне більшого покриття поля суперника першим, це важливіше, ніж просто підбиті кораблі.
Тестові активності матимуть ще більшу цінність, якщо застосовувати будь-яку з моделей Risk-Based Testing, це FMEA, PRA, PRISMA. Тестування, засноване на ризиках, грамотно пріоритезує ваші тести, навчить всю команду та замовника правильно їх шукати та оцінювати, а як результат убезпечить майбутні релізи. Схильність до ризику можна знайти, перемноживши ймовірність використання функціоналу на ймовірність фейлу і, власне, ціну його наслідків. Імплементація такого підходу вимагатиме витрат, проте якість продукту і спокійний сон того варті.
Тепер, коли ризики відомі, оцінені та знайшли вираз у відповідних пріоритетах тестів, найбільш ризикові фічі будуть перевірені детальніше та насамперед.
Леверідж ризиків
Використовувати результати фінансового аналізу при прийнятті управлінських рішень я рекомендую у різних ситуаціях.
Розглянемо приклад. На вашому проекті існує можливість втрати даних на тестовому сервері 20%. Якщо це станеться, вартість такої втрати (строки + вартість відновлення даних) становитиме $20K.
Оцінимо ризик: 20% * $20K = $4K
Ризиків можна уникати, їх можна приймати, знижувати та передавати. Але що з цього вибрати? Є варіант впровадити механізм бекапу та зменшити ризик до 5%. Вплив буде незмінним, тому що у разі збою на сервері ми також втратимо, а вартість робіт з бекапу складе $2K. Отже:
Імовірність - 5% (після вжитих заходів)
Втрати - $20K (такі ж)
Оцінка ризику після 5% * $20K = $1K
Витрати зменшення ризику - $2K
Risk Reduction Leverage = (Risk Estimation (до) - Risk Estimation (після)) / Risk Reduction Cost
Розрахуємо леверидж зменшення ризику: ($4K - $1K) / $2K = 1.5
Отримана величина (>1) свідчить, такі заходи доцільні.
Можна розглянути варіант передачі ризику, використовуючи послуги аутсорсу. Якщо вигода другого варіанта виявиться більшою, але команда зупиниться на самостійному впровадженні механізму бекапу, то вона нестиме альтернативні витрати або витрати втрачених можливостей.
Схожі порівняння необхідно проводити і з ROI, вибираючи найкращий варіант.
ROI = ((Savings - Costs)/Costs) * 100%
При розрахунку ROI є маса нюансів залежно від проекту та виду тестування. Основна складність - правильно розрахувати отримувану вигоду. Без аналізу витрат та собівартості тестових активностей зробити це коректно буде проблематично. Зниження витрат з автоматизації відбувається в основному за рахунок паралельного запуску тестів, перевикористання коду, зниження витрат на аналіз результатів, автоматизації створення звітів про тестування та налаштування тестового оточення.
Проблема вибору
Допустимо, у вас два проекти або дві окремі команди тестувальників A та Z.
Кому спрямувати кошти на розвиток та як не помилитися у розрахунках? Ставка дисконтування проекту A 10%, а проекту Z 12% (через триваліший термін його реалізації).
Показники
Проекти із тестування
A
Z
Обсяг планованих вкладень
70K
68K
Кількість періодів експлуатації
2
4
Сума запланованого чистого грошового потоку
100k
110k
в тому числі:
1-й період
60k
20k
2-й період
40k
30k
3-й період
-
30k
4-й період
-
30k
За інших рівних умов наче вигідніше надати бюджет розвитку проекту Z, оскільки він вимагає менших вкладень і краще окупається.
Але долар сьогодні дорожчий, ніж коштуватиме завтра, тому слід визначити чистий наведений дохід за кожним проектом:
Тут Fn - обсяг грошового потоку у період n, а r - ставка дисконтування.
Розрахувавши підсумкову реальну вартість чистих грошових потоків за мінусом запланованих вкладень, отримаємо:
NPV (A) = 54545 + 33057 - 70000 = 17603
NPV (Z) = 17860 + 23910 + 21360 + 19080 - 68000 = 14210
Ще до розрахунку внутрішньої норми прибутковості (IRR) очевидно, що вигідніше надати бюджет розвитку тестувальникам проекту A.
Всі ці приклади не так про фінанси, як про світогляд у тестуванні, про розуміння сенсу своєї роботи. Яку б тестову активність команда не починала, непогано думати про те, яку цінність вона має для замовника і кінцевих користувачів. Такий підхід однаково корисний усім як директору з тестування, так і новоспеченому джуну. Іноді стереотипи про те, що творцем є лише розробник, заважають тестувальнику також любити і піклується про продукт як своє дітище. Це як образа злої феї, яку не запросили на хрестини принцеси. Замість турботи вона зловтішно чекає, коли маля вколеться веретеном, а потім скаже: «Я ж казала, тут баг на базі». Але ми не руйнуємо, а творимо. Бути лише добрим виконавцем, регулярно освоювати бюджет і робити рівно стільки, скільки сказали, можна, але й цінність цього відповідна.
Джерела:
Дод. матеріал: