Цей принцип заснований на емпіричній закономірності, названій в честь економіста та соціолога Вільфредо Парето, і яка говорить: «20% зусиль дають 80% результату, а інші 80% зусиль – лише 20% результату».
Але не варто сприймати це правило як мотивацію до хаотичного тестування з метою пошуку грааля, який містить ті самі заповітні 80% проблем, дозволить вам здобути славу мега тестувальника і внести ключовий внесок в реалізацію проєкту. Не будемо винаходити велосипед і просто процитуємо Вікіпедію, щодо недоліків закону Парето:
- у якісному формулюванні (тобто без урахування конкретних значень 20/80) закон являє собою тривіальне спостереження, згідно з яким в ситуації, коли результат складається з дій безлічі різних факторів, внесок цих факторів в результат часто буває різним;
- кількісна частина закону математично очевидно некоректна:
- дійсний розподіл вкладу більшої і меншої частини чинників в реальному житті буває яким завгодно, і зовсім не обов'язково дорівнює 20/80;
- легко перевірити, що конкретні значення розподілу змінюються навіть при аналізі одних і тих самих даних, досить змінити правила групування вибіркових значень.
Усе вищесказане лише підтверджує правило, яке свідчить, що всі проєкти різні: десь вплив цього закону вище і дуже помітно за підсумками спринту/ітерації, а десь нижче. Так, на проєкті з безліччю модулів, частина з яких стара, а нові створюються постійно, принцип скупчення багів буде добре помітний. У той же час продукт, що містить мінімум взаємодіючих модулів, матиме не таку виражену кластеризацию багів.
Закономірним питанням буде: «Навіщо ж тоді взагалі знати про цей принцип?». А для того, що час і гроші, як основні ресурси розробки програмного забезпечення, обмежені або лімітовані. Покрити всі модулі тестами – це щось на межі фантастики, а тому потрібно бути ефективними і професійно виявляти проблеми і помилки за відведений на це час.
Уявімо ситуацію, коли часу на написання якісних тест-кейсів немає і команда обмежена досить простим чеклістом. Тут і вступає в силу принцип Парето. Можна сміливо стверджувати, що як тільки знаходиться перший баг, перша проблема, перша невідповідність очікуваного результату – варто продовжувати шукати в цьому напрямку. По суті, це можна порівняти з пошуком схованки, де авантюрист, a.k.a тестувальник, постукує палицею по площині в пошуках порожнин за нею і після продовжує рухатися по знову знайденому шляху. Але це не означає, що потрібно кинути все і концентруватися всією командою на одному лише модулі, в якому знайшли перші баги, бо не варто забувати про недоліки цього правила, що були згадані вище.
З досвіду багатьох практикуючих тестувальників можна сказати, що наявність якісного ТЗ/вимог/товариських розробників, а також розуміння продукту і минулий досвід значно підвищують ефективність застосування даного закону.
Таким чином, він ідеально доповнює основні ідеї Agile команди, дозволяє полегшити задачу, прискорити роботу на проєкті, а також зробити її більш ефективною.
Цікавою особливістю принципу «Скупчення дефектів» також є те, що, проаналізувавши дані за результатами тестів, можна виявити найпроблемніші модулі продукту і переглянути їх. Наприклад, якщо виявиться, що один з модулів на кожному спринті генерує левову частку багів або багів там трохи, але вони повертаються знову і знову, це відмінний привід задуматися над тим, чи варто далі намагатися реалізовувати його поточним чином? Це може бути як наслідком того, що з'являється конфлікт старих і нових модулів, приходу нових розробників, і таким чином невідповідності якості нового коду попередньому. Закон Парето дозволяє нам подивитися на вирішення проблеми з іншого боку: можливо нам варто переглянути ТЗ? Можливо простіше відмовитися від підтримки такого старого модуля і витратити сили на написання нового, який буде ідеально доповнювати поточні?
Але, здавалося б, до чого тут QA? До того, що позбавлення від такого модуля вирішить проблему куди ефективніше і простіше, ніж його тестування, яке з кожною ітерацією вимагає все більших зусиль команди тестувальників. Таким чином, принцип Парето допомагає покращити якість продукту, а QA команді приділити більше часу функціоналу, що залишився.
Виходячи зі статистики, отриманої незалежною міжнародною консультативною фірмою з досліджень в області IT, 45% функціоналу програми користувачі ніколи не використовують, 19% функціоналу використовується рідко, 16% – іноді, і тільки 20% – часто або постійно. На підставі цього можна припустити, що, сконцентрувавши більшу частину уваги на цих самих 20% часто використовуваних користувачами функціях, можна отримати куди більше вигоди, ніж інакше.
Основоположні принципи тестування спочатку можуть здатися занадто монолітними, непридатними. Лише аналізуючи пройдений етап, ми збираємо по крихтах воєдино мозаїку, роздивляючись яку, можна сказати, що принципи тестування ховаються у дрібницях, те, що здається ніяк не пов'язаним на перший погляд – в ретроспективі доповнює картину, яку вони описують. Не варто ними нехтувати, але також і не потрібно сподіватися застосувати їх в перший же робочий день. Чим більше досвід – тим частіше ці принципи застосовуються, навіть без думки про те, щоб використовувати їх, вони стають природними.
