Методологія оцінки macOS-утиліт: від критеріїв до тест-кейсів

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

Усім привіт. Я Юрій Варбанець, CTO в Nektony. Наша команда створює утиліти для macOS вже 15 років, починаючи з 2011-го. Ми бачили, як змінювався підхід до якості софту протягом десятиліття, і сьогодні спостерігаємо новий тектонічний зсув.

Завдяки ШІ ринок буквально вибухає новими рішеннями. На графіку видно цей «ефект доміно»: за кожним стрибком Google Trends (пошукового інтересу) слідує рекордна кількість нових релізів у App Store. Особливо це помітно на зламі 2024–2025 років, коли ШІ-кодинг став мейнстримом, дозволивши створювати утиліти швидше, ніж будь-коли раніше.

Інтерec до Mac-утиліт в порівнянні з кількістю нових утиліт в Mac App Store поквартально

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

Ще задовго до AI-хайпу ми вирішили формалізувати й побудувати власну повноцінну методологію оцінки macOS-утиліт, за якою потім тестували десятки продуктів (і, звісно, свої). У цій статті я хочу показати, що з цього вийшло, підсвітити результати наших порівнянь і, власне, поділитися нашими доробками.

AI-Generated Junkware: нова реальність

Останні два роки ми спостерігаємо, як ШІ дедалі знижує барʼєр входу в розробку програмного забезпечення.

Написати Mac-утиліти за вечір тепер може людина, яка ніколи не читала документацію про APFS і не знає, чим відрізняється контейнер від тома у файловій системі з copy-on-write. Hardlinks, symlinks, resource forks існують не просто так і роблять файлову систему macOS складнішою за простий набір файлів і папок.

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

Ми їх бачимо, бо мусимо вивчати нові застосунки, які зʼявляються в App Store чи на GitHub, адже наші утиліти рано чи пізно зустрінуться з ними на системах наших користувачів. Дивимось: красиві SwiftUI-інтерфейси, плавні анімації, навіть нотаризація від Apple на місці. Але перше тестування на контрольному датасеті — і утиліта сприймає очевидно різні файли як дублікати чи ігнорує корнер-кейси із extended attributes.

Код, написаний за допомогою ШІ, справді може і виглядати правильно і працювати добре. Але він виконає лише поставлену перед ним задачу. Відтак застосунок, написаний за допомогою ШІ, буде працювати настільки ж добре, наскільки його творець знає всі нюанси роботи macOS.

Дев’ять критеріїв оцінки

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

1. Точність і повнота сканування

Головний критерій і водночас найскладніший для об’єктивного вимірювання. Ми створюємо контрольний датасет — набір файлів з відомою структурою: звичайні файли, APFS clones, symlinks, hard links, sparse files, файли з resource forks.

Запускаємо утиліту на цьому датасеті та порівнюємо те, що вона знайшла, з тим, що там реально є. Detection rate, false positive rate, поведінка на edge cases — усе фіксується.

З наших порівнянь: на одному й тому самому наборі різні клінери знаходять від 2,9 до 4,7 ГБ junk files. Різниця може сягати 60%, і це на ідентичній машині з ідентичним набором даних.

2. Безпека даних

Чи використовує утиліта Trash? Чи попереджає перед видаленням системних файлів? Чи є захист від видалення системних директорій?

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

3. Приватність та передача даних

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

4. Швидкість роботи та споживання ресурсів

Ми вимірюємо CPU та RAM під час роботи утиліт на ідентичному залізі.

Цифри з наших порівнянь показові: серед 11 Mac-клінерів споживання пам’яті при скануванні — від 87 МБ до 1,1 ГБ. Різниця в шістнадцять разів. На тому ж Mac, з тим же набором файлів. Серед аналізаторів диску — від 70 МБ у стані спокою до 2,5 ГБ після сканування в одного з продуктів, який, судячи з усього, має витік памʼяті. Час повного сканування системного диска від 14 секунд до 2 хвилин 20 секунд.

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

5. macOS-сумісність

Ми вивчаємо підтримку Apple Silicon, актуальних версій macOS, коректної роботи з System Integrity Protection.

Тут, до речі, є цікаві нюанси. Наприклад, діапазон мінімальних підтримуваних версій macOS серед 11 протестованих клінерів — від macOS 10.2 (двадцятирічна ОС!) до macOS 14.0. Продукт, який підтримує macOS 10.2, швидше за все, тягне legacy-код, який може конфліктувати з сучасними API. Продукт, який вимагає macOS 14.0+ — навпаки, може бути надто агресивним у відмові від зворотної сумісності.

Кожен великий реліз macOS приносить зміну, яку вимагає оновлень від системної утиліти

На нашу думку, підтримку варто реалізовувати, починаючи з версії приблизно macOS 11.0-13.0 — це поки не вимагає забагато зусиль, але при цьому відчутно розширює базу користувачів.

6. UI/UX дизайн

Чи може користувач помилитися? Чи є undo після видалення? Скільки кліків до деструктивної дії? Чи відповідає інтерфейс ментальній моделі macOS-користувача?

Наприклад, один із продуктів при натисканні Done після видалення файлу повертає користувача не на ту вкладку, де він працював, а на головний екран — це порушення UX, яке призводить до плутанини.

7. Повнота функцій

Чи вирішує утиліта свою задачу повністю, чи лише імітує рішення? Чи робить те, що декларує?

Наприклад, деякі клінери памʼяті показують детальну статистику споживання RAM, але не мають самої функції оптимізації памʼяті. Інші, навпаки, чистять пам’ять, але дають ефект, який зникає за хвилину — бо macOS сам управляє memory pressure і «звільнена» пам’ять миттєво повертається до кешованого стану.

8. Доступність підтримки

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

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

9. Ціноутворення

Прозорість ціноутворення: чи зрозуміло, що входить у підписку, чи можна заплатити раз за володіння ліцензією, чи не з’являються додаткові платні фішки після оплати.

З порівнянь: один із продуктів надсилає 10+ маркетингових сповіщень на день. Інший не дозволяє повноцінно протестувати продукт без прив’язки банківської картки.

Кожен критерій створено як відповідь на конкретну проблему, яку ми бачили в реальних продуктах.

Від критеріїв до калькуляторів

Для кожного критерію ми створили набір конкретних перевірок, специфічних для категорії продукту. Для пошуковиків дублікатів ми сформулювали 53 такі перевірки, для аналізаторів місця на диску — 54, для деінсталяторів — 48. Кількість різна, бо різна специфіка: пошуковик дублікатів має правильно відрізняти дублікати від просто схожих за атрибутами файлів, а деінсталятор — коректно знаходити PKG-receipts та не чіпати shared frameworks.

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

Оскільки методологія — це суха теорія, ми також створили три інтерактивні калькулятори, по одному для кожної категорії. Кожен калькулятор пропонує покрокову інструкцію: ви проходите всі критерії для конкретного продукту, відповідаєте на питання (підтримує/не підтримує/частково підтримує) і на виході отримуєте зважений бал.

Кожен тест-кейс має очікуваний результат. Ми прогоняємо утиліту на датасеті та порівнюємо фактичний результат з очікуваним — стандартний QA-підхід, просто застосований до категорії продуктів, де його чомусь ніхто публічно не робив.

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

Нещодавно ми опублікували наші методології під ліцензією CC BY 4.0. Ви можете використовувати її як основу для власних оцінок, адаптувати під свої потреби, цитувати в оглядах. Ми свідомо обрали цю ліцензію, а не, скажімо, закрили методологію під NDA, бо вважаємо, що індустрії потрібен відкритий стандарт оцінки, навіть якщо цей стандарт хтось використає проти наших власних продуктів.

Водночас ми не претендуємо на те, що наші автоматизовані тести чи методології покривають усі можливі випадки. macOS — жива операційна система, де один апдейт може змінити поведінку Finder, інший — спосіб підрахунку purgeable space, третій — логіку роботи security-scoped bookmarks. Ручне тестування edge cases після кожного мажорного оновлення macOS — обов’язкова частина нашого і, певен, вашого процесу.

Як це можна застосувати на практиці

Усе, що я описав, доступне публічно.

Якщо ви QA-інженер або тестувальник — завантажте наші тестові датасети. Вони містять APFS clones, symlinks, hard links, sparse files, resource forks, вкладені бандли — увесь набір edge cases, на яких ламається наївна логіка. Прогоніть на них продукт, який тестуєте. Порівняйте результати з еталоном.

Якщо ви розробник macOS-утиліти — «пройдіть» калькулятор для своєї категорії. За 10 хвилин ви отримаєте об’єктивну оцінку свого продукту за тими ж критеріями, за якими ми оцінюємо конкурентів і самих себе.

Якщо ви техлід або CTO — використовуйте нашу методологію як основу для внутрішнього QA-процесу. PDF із повним описом доступний під ліцензією CC BY 4.0. Адаптуйте під свої потреби, додайте критерії, специфічні для вашого продукту.

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

Усі інструменти зібрані на сторінці nektony.com/resources.

Замість висновку: запрошення до дискусії

Наша методологія — не істина в останній інстанції. Це наш поточний best effort на основі 15 років роботи з macOS. Ми знаємо, що вона має обмеження: не покриває всі категорії утиліт, не враховує деяких сценаріїв.

Саме тому ми свідомо публікуємо все під відкритою ліцензією і запрошуємо до діалогу. Нам цікаво не підтвердити свою правоту, а зробити оцінку якості macOS-утиліт менш суб’єктивною.

Кілька питань, які мене особисто цікавлять:

• Які критерії для вас є вирішальними при виборі системної утиліти? Може, є щось, чого ми не врахували?
• Як ви у своїх командах підходите до оцінки сторонніх macOS-інструментів (особливо таких, які запитують привілейований доступ)?
• Чи є сенс створити щось на кшталт спільного industry benchmark для macOS-утиліт, чи кожен вендор неминуче буде «тягнути ковдру» під свої продукти?

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

Дякую за увагу.