Три тижні тому я створив віджет для запису клієнтів для подруги, яка керує йога-студією — чат, план, який я схвалив швидко, бо був зайнятий іншими справами, запуск, а тоді картка версії із зеленою галочкою, на яку я лише глянув і пішов далі. У вівторок вона написала мені, чи можна направити на цю саму збірку сайт другої студії. Перш ніж погодитися, я повернувся подивитися, що насправді означало «перевірено» три тижні тому, і саме тоді я вперше по-справжньому прочитав такий запис, а не просто довірився галочці.
Він розташований прямо на картці версії, поруч із попереднім переглядом і діями з кодом — там само, куди ви пішли б, щоб повторно розгорнути чи відкотити версію. Перше, що я помітив: він стосується лише цієї конкретної версії, а не всієї розмови. Я ітерував над цією збіркою п'ять разів, гоняючись за зламаним вибором дати, і напівочікував, що запис розповість мені історію всього цього процесу туди-сюди. Але ні. Запис версії 4 описує лише версію 4. Він не пам'ятає, що версія 2 вийшла з формою входу, яка мовчки не спрацьовувала, і не скаже мені, що версія 5 тихо виправила те, що зламала версія 3. Кожен запис — це знімок, а не diff і не список змін — якщо мені потрібна історія того, що змінювалося від релізу до релізу, це вже зовсім інший вигляд. Цей же відповідає лише на питання «чи все гаразд із цією версією».
Прокручуючи далі, запис розбивається на шість рядків:
| Рівень | Проходження означає |
|---|---|
| Функціональний / у браузері | Збірка запускалася у справжньому браузері; взаємодії перевірялися (в ігри дійсно грали) |
| Огляд коду | Рецензент, що працює лише на читання, не знайшов дефектів, які можна підтвердити файлом і поведінкою |
| Безпека | Не виявлено поверхонь для ін'єкцій, витоків секретів чи небезпечних патернів |
| Посилання та SEO | Немає зламаних посилань; метадані, robots і sitemap у порядку |
| Доступність | Автоматизована перевірка axe не виявила порушень |
| Відповідність | Збірка містить те, що обіцяв затверджений план |
Усі шість пунктів були зеленими, і моя перша реакція була такою ж хибною, як, гадаю, і в більшості людей: безпека пройшла — отже, безпечно; доступність пройшла — отже, доступно. Жодне з цих тлумачень не витримує зіткнення з тим, що насправді роблять ці перевірки. Прохід перевірки безпеки означає, що поверхневі проблеми — конкатенація рядків у запиті, ключ API, що світиться у клієнтському бандлі, eval над тим, що ввів користувач — не виявилися. Це не день роботи з пентестером. Студія моєї подруги не приймає платежів через цей віджет, лише імена й часові слоти, тож для неї цього рівня було достатньо. Якби це був потік оформлення оплати, я б хотів більшого, ніж просто нижню планку.
Доступність — це саме те, через що я зупинився й пішов шукати додаткову інформацію, бо "пройшов перевірку axe" звучить вичерпно, хоча насправді це не так. Axe — автоматизований движок, що працює під капотом, — стабільно виявляє приблизно третину-половину критеріїв успіху WCAG: відсутній alt-текст, поганий контраст, непідписані поля форм, очевидні помилки ARIA. Але він не скаже вам, чи зручно користуватися кастомним випадаючим календарем, який я замовляв, за допомогою скрінрідера, чи потрапляє фокус у логічне місце при переході по табах через багатоетапний процес бронювання, чи стане проблемою статус "підтверджено" проти "очікується", позначений зеленим і жовтим кольором, для людини з червоно-зеленою дальтонією. Це потребує людини, яка проходить весь застосунок за допомогою інструментів, якими реально користуються люди з обмеженими можливостями. Axe дає реальний сигнал, це не марно — це рівень перевірки орфографії в доступності, а не редактор.
Відповідність — це рядок, який я мало не пропустив, бо звучить бюрократично — «містить те, що обіцяв план» — поки я не згадав, що план, який я схвалив, писався, коли я був відволікся, і я справді не міг пригадати, чи просив підтвердження на email, чи лише SMS. Це шар, який перевіряє білд відповідно до плану, а не мого реального наміру, і він пройшов, а це означало, що білд відповідає тому, на що я сказав «так», але не обов'язково тому, що я мав на увазі. Я чув про білди, які були функціонально надійними та безпечними, але все одно не проходили цей шар, бо якась функція тихо зникла під тиском дедлайну. Це шар, який утримує білд чесним щодо розмови, яка його породила, навіть якщо сама розмова була трохи недбалою.
Під шістьма рядками був довший список, розділений на два блоки, і саме на ньому я витратив найбільше часу. Пункти «обов'язково виправити» — це не те, що зараз не так у білді, — це квитанції. Один рядок повідомляв, що шар перевірки виявив випадок, коли рядок дати вставлявся прямо в запит, і це вже було виправлено до того, як цю версію позначили завершеною. Я дивився не на відкриту рану, а на шрам. Ця різниця важлива, бо якщо читати пункт «обов'язково виправити» як живе попередження, ви витратите час, хвилюючись про те, що вже закрито.
Список рекомендацій був довшим, і здебільшого це були речі, які я сам сказав би, переглядаючи код колеги, не бажаючи блокувати мердж: «варто винести повторюваний блок рендерингу слотів у спільний компонент», «цей ендпоінт не має обмеження частоти запитів, що прийнятно для внутрішнього інструменту бронювання студії, але варто переглянути, якщо він стане публічним». Жоден пункт у цьому списку не був дефектом. Це були судження, які верифікатор зробив, маючи лише план і код, і для внутрішнього планувальника йога-студії кожне з цих суджень виявилося обґрунтованим. Якби студія мого друга була франшизою з віджетом, вбудованим на п'ятдесяти сторінках локацій, я б наполягав на перегляді пункту про обмеження частоти запитів — класифікація залежить від контексту, який верифікатор може лише вгадувати, і коли здогадка виглядає для вас хибною, правильний крок — сказати про це в чаті, а не вважати мітку остаточною.
Що мене вразило, коли я дивився на досить довгий список рекомендацій поряд із чистою колонкою «обов'язково виправити», так це те, що я мало не сприйняв його довжину як погану новину. Це не так. Білд без жодної рекомендаційної нотатки або пройшов вузьку перевірку, або йому просто пощастило; білд зі стосом пунктів «варто розглянути» і без жодного відкритого пункту в «обов'язково виправити» — це той, який дійсно ретельно перевірили. Колонка рекомендацій — це те, що має залишитися, коли реальні проблеми вже усунуто.
Інше, що я змусив себе зробити, оскільки цей запис уже застарів на три тижні, — перевірити, які шари фактично запускалися, перш ніж довіряти вердиктам взагалі. Тут були присутні всі шість, але відтоді я бачив білд, де перевірка доступності просто була відсутня у списку, а не позначена як «пройдено» чи «не пройдено» — це не те саме, що бути пропущеною як неважлива, це ознака того, що перевірка не запускалася для конкретного типу сайту чи конфігурації прапорців, і сприйняття відсутності як тихого «пройдено» — саме та помилка, до якої підштовхує цей формат, якщо переглядати побіжно.
Ніщо з цього не сказало мені, чи справді потік бронювання йога-студії конвертує, чи покидають люди процес на кроці вибору часового слота, чи взагалі ідея власного віджета замість простого посилання на Calendly була правильним рішенням. Верифікація доводить, що білд працює так, як обіцяно, а не що обіцянка була правильною — це різні питання, і я бачив, як білди чисто проходили кожен шар і все одно провалювалися з реальними користувачами, бо «працює коректно» і «вирішує правильну проблему» перетинаються не так сильно, як хотілося б. Та половина, яка відповідає на друге питання, — це цикл вимірювання, і ці два аспекти призначені для читання разом. Чистий запис верифікації для функції, яку ніхто не бронює, — це все одно функція, яку ніхто не бронює.
