Стачка - Стоимость неправильной подписи: как мы внедрили семантический аудит в пайплайн

Стоимость неправильной подписи: как мы внедрили семантический аудит в пайплайн

3 октября

13.10-13.40

Green 8. Инфраструктура

Руководитель отдела тестирования @ООО «НИЦ «Аэродиск»

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

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

Честный разбор, почему мы это пропустили, а не просто «нашли и молодцы». Наш процесс тестирования годами проверял: кнопка кликается, значение отображается, форма отправляется. Ни у QA, ни у UX, ни у разработки не было зоны ответственности за вопрос «а правда ли текст совпадает с тем, что происходит». Мы не завалили тест — у нас просто не было теста на этот класс проблем.

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

Вторая попытка сработала, потому что мы перестали считать это одной задачей. Три категории с разными владельцами и разным SLA: баг логики идёт разработчику как обычный баг; вводящий в заблуждение лейбл — задаче с владельцем UX и доменным экспертом, не блокирует релиз, но имеет срок; нарушение единообразия терминов — в накопительный список по глоссарию, закрывается пакетами. Как только у каждой категории появился конкретный человек, который отвечает за неё лично, находки перестали бесконечно откладываться.

Цена, которую мы не считали заранее и зря. Переименование поля в интерфейсе enterprise-продукта почти всегда тянет за собой API-ответ, CLI-команду, экспортируемый файл или документацию. У нас был инцидент именно на этом: разработка «просто исправила текст» в интерфейсе, а у клиента отвалился скрипт, парсивший старое название поля через экспорт. После этого правило про контракт появилось в чек-листе не как теория, а как прямое следствие конкретной поломки.

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

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

Второй инсайт на понедельник: перед тем как переименовать любое поле в интерфейсе, спросите явно — меняется только то, что видно на экране, или меняется контракт (API/CLI/экспорт/документация) целиком. Один вопрос, вставленный в определение готовности задачи, стоит дешевле одного инцидента.

Честное ограничение метода, которое не буду прятать от зала: аудит помогает найти расхождения, но решение, является ли конкретное расхождение проблемой, всё равно принимает человек с доменной экспертизой. Это снижает объём ручной работы, но не убирает необходимость эксперта — и если кто-то продаёт вам полностью автоматический процесс здесь, он либо преуменьшает риск, либо преувеличивает возможности.

Что бы я сделал иначе, если бы начинал сейчас: завёл бы три категории сразу, а не после первой провалившейся попытки с одним пунктом в чек-листе. Это стоило нам лишнего месяца и нескольких находок, которые успели дойти до продакшена, пока процесс не заработал.

Итог для зала, без красивых слов: то, что выглядит как опечатка, может быть операционным риском с измеримой ценой. Моя работа как лида — не находить эти дефекты самому, а построить процесс, который систематически находит их до клиента, и признать вслух, когда первая версия этого процесса не сработала.

Скачать доп. контент

Может заинтересовать

#похожие доклады

15.10-15.40

Автотесты-паразиты: как найти и обезвредить пожирателей ресурсов