Основы: как читать протокол верификации сборки

Три недели назад я собрал виджет бронирования для подруги, у которой студия йоги, — чат, план, который я одобрил быстро, потому что был занят другим делом, запуск, а затем карточка версии с зелёной галочкой, на которую я взглянул и пошёл дальше. Во вторник она написала, спрашивая, можно ли направить сайт второй студии на ту же сборку. Прежде чем сказать «да», я вернулся посмотреть, что на самом деле означало «проверено» три недели назад, и именно тогда я впервые по-настоящему прочитал одну из этих записей, а не просто доверился галочке.

Она находится прямо на карточке версии, рядом с превью и действиями с кодом — там же, куда вы пошли бы, чтобы повторно развернуть сборку или откатиться. Первое, что я заметил: она привязана именно к этой версии, а не ко всему разговору. Я итерировал эту сборку пять раз, пытаясь исправить сломанный выбор даты, и наполовину ожидал, что запись расскажет мне историю всей переписки. Но нет. Запись версии 4 описывает только версию 4. Она не помнит, что версия 2 вышла с формой входа, которая тихо ломалась, и не скажет мне, что версия 5 незаметно исправила то, что сломала версия 3. Каждая запись — это снимок, а не диф и не журнал изменений — если мне нужна история изменений от релиза к релизу, для этого есть совершенно другой раздел. Этот отвечает только на вопрос «всё ли в порядке с этой версией».

Прокручивая вниз, запись разбивается на шесть строк:

Все шесть пунктов были зелёными, и моей первой реакцией стала та же неверная реакция, что, наверное, была бы у большинства: безопасность пройдена — значит безопасно; доступность пройдена — значит доступно. Ни одно из этих прочтений не выдерживает столкновения с тем, что проверки делают на самом деле. Проверка безопасности означает, что поверхностные проблемы — конкатенация строк в запрос, ключ API, торчащий открытым в клиентском бандле, eval над тем, что ввёл пользователь, — не обнаружились. Это не день с пентестером. Студия моей подруги не принимает через этот виджет платежи, только имена и время слотов, так что этого минимума было достаточно. Если бы это был поток оформления заказа, я бы хотел большего, чем минимум.

Доступность — это единственный пункт, который заставил меня действительно остановиться и что-то посмотреть, потому что «прошёл axe» звучит исчерпывающе, но это не так. Axe — автоматизированный движок, работающий под капотом, — надёжно ловит примерно треть-половину критериев успешности WCAG: отсутствующий alt-текст, плохой контраст, неподписанные поля форм, явные ошибки в ARIA. Он не может сказать вам, удобен ли кастомный выпадающий выбор даты, который я запросил, для чтения с экрана, приземляется ли фокус в разумном месте при табуляции через многошаговый процесс бронирования, или является ли проблемой для человека с красно-зелёной цветовой слепотой то, что статусы «подтверждено» и «в ожидании» я раскрасил зелёным и жёлтым. Для этого нужен человек, который проходит сборку с инструментами, отключёнными так же, как их отключают реальные пользователи с ограниченными возможностями. Axe — это реальный сигнал, не пустышка, — это уровень проверки орфографии в доступности, а не редактор.

Соответствие — это строка, которую я чуть не пропустил, потому что звучит бюрократически — «содержит то, что обещал план» — пока я не вспомнил, что план, который я одобрил, был написан, пока я был отвлечён, и я искренне не мог вспомнить, просил ли я подтверждения по email или только по SMS. Это уровень, который сверяет сборку с планом, а не с моим реальным намерением, и он прошёл, а значит сборка соответствовала тому, на что я сказал «да», но не обязательно тому, что я имел в виду. Я слышал о сборках, которые были функционально надёжными и безопасными, но всё равно не прошли этот уровень, потому что функция незаметно выпала из-за нехватки времени. Это уровень, который держит сборку честной по отношению к разговору, из которого она возникла, даже если сам разговор был немного небрежным.

Под шестью строками был более длинный список, разделённый на две группы, и именно на нём я провёл больше всего времени. Пункты «обязательно исправить» — это не то, что сейчас не так со сборкой, а квитанции. В одной строке говорилось, что уровень ревью обнаружил случай, когда строка с датой подставлялась прямо в запрос, и это уже было исправлено до того, как эта версия была помечена завершённой. Я смотрел не на открытую рану, а на шрам. Это различие важно, потому что если читать пункт «обязательно исправить» как живое предупреждение, вы потратите время, беспокоясь о том, что уже закрыто.

Список рекомендаций был длиннее, и в основном это были вещи, которые я сам бы сказал, если бы ревьюил код коллеги, не желая блокировать слияние: «стоит вынести повторяющийся блок рендеринга слотов в общий компонент», «у этого эндпоинта нет ограничения частоты запросов, что нормально для внутреннего инструмента бронирования, но стоит пересмотреть, если он станет публичным». Ничего в этом списке не было дефектом. Это были суждения, которые верификатор сделал, имея на руках только план и код, и для внутреннего расписания студии йоги каждое из этих суждений оказалось разумным. Если бы студия моей подруги была франшизой с виджетом, встроенным на пятьдесят страниц филиалов, я бы хотел оспорить пункт про ограничение частоты запросов — классификация зависит от контекста, о котором верификатор может только догадываться, и когда догадка кажется вам неверной, правильный ход — сказать об этом в чате, а не считать метку окончательной.

Что меня поразило при взгляде на довольно длинный список рекомендаций рядом с чистой колонкой обязательных исправлений — я чуть было не прочитал его длину как плохую новость. Это не так. Сборка без единой заметки в рекомендациях либо прошла узкую проверку, либо ей просто повезло; сборка со стопкой пунктов «стоит рассмотреть» и без единого открытого пункта в обязательных исправлениях — это та, которую действительно тщательно изучили. Колонка рекомендаций — это то, что должно остаться, когда реальные проблемы уже устранены.

Ещё одно, что я заставил себя сделать, поскольку эта запись была трёхнедельной давности, — проверить, какие уровни вообще запускались, прежде чем доверять вердиктам. Здесь присутствовали все шесть, но с тех пор я видел сборку, где доступность просто отсутствовала в списке, а не была помечена как пройдена или провалена — это не то же самое, что быть пропущенной как неважная, это признак того, что проверка не запускалась для данного типа сайта или конфигурации флагов, и читать отсутствие как тихое прохождение — именно та ошибка, к которой подталкивает этот формат, если бегло его просматривать.

Ничто из этого не сказало мне, действительно ли поток бронирования студии йоги конвертирует, бросают ли люди процесс на шаге выбора времени, или была ли вообще правильным решением идея кастомного виджета вместо простой ссылки на Calendly. Верификация доказывает, что сборка работает так, как обещано, а не что само обещание было правильным — это разные вопросы, и я видел, как сборки чисто проходили каждый уровень и всё равно проваливались с реальными пользователями, потому что «работает корректно» и «решает правильную задачу» пересекаются не так сильно, как хотелось бы. Та половина, которая отвечает на второй вопрос, — это цикл измерения, и их задумано читать вместе. Чистая запись верификации на функции, через которую никто не бронирует, — это всё равно функция, через которую никто не бронирует.