Зачем QA‑инженеру читать законы?
Картина маслом: выкатываем долгожданный релиз. Архитектура вылизана, покрытие автотестами близко к 100 %, бэкенд держит нагрузку как спартанцы, фронт сверкает. Продакт‑менеджер открывает шампанское, CTO довольно выдыхает.
А через месяц в компанию прилетает «письмо счастья» от РКН или ФАС – штраф на полмиллиона рублей. За что?
Например:
- чекбокс согласия на обработку персональных данных на форме регистрации был прожат по умолчанию (нарушение ч. 4 ст. 9 Федерального закона от 27.07.2006 № 152‑ФЗ «О персональных данных»);
- в рекламном баннере на главной странице забыли зашить токен маркировки (нарушение требований ч. 17 ст. 18.1, последние изменения в которую внесены 26.12.2024, Федерального закона № 38‑ФЗ «О рекламе»).
Кто виноват?
Юристы, которые не проверили прод?
Продакт, который забыл поставить задачу?
Разработчик, который скопипастил старый компонент?
Чаще всего мы слышим от CTO и лидов, когда приходим на аудит процессов к клиентам, одно и то же: «Ну, это же юридические вопросы, при чём тут тестирование?»При том, что юристы не умеют открывать DevTools, не тестируют позитивные и негативные сценарии в формах и редко заходят на тестовые стенды. А баги комплаенса стоят бизнесу намного дороже, чем поехавшая вёрстка.
При том, что юристы не умеют открывать DevTools, не тестируют позитивные и негативные сценарии в формах и редко заходят на тестовые стенды. А баги комплаенса стоят бизнесу намного дороже, чем поехавшая вёрстка.
Иллюзия «технического» QA
Исторически сложилось, что от тестировщиков ждут проверки функций. Кнопка нажимается? Данные в базу уходят? 500‑ю ошибку не выдаёт? Отлично, в прод!
Когда клиенты приходят к нам за аутсорсом тестирования, они обычно приносят пачку ТЗ и ожидают, что мы просто разгрузим их внутреннюю команду: заберём на себя регресс, напишем тест‑кейсы, настроим автоматизацию. И когда на этапе планирования мы предлагаем включить в стратегию проверок комплаенс‑тестирование, многие искренне удивляются.
Но для нас QA – это не только поиск технических дефектов, но и управление рисками продукта. Риск блокировки домена или крупного штрафа – серьёзный блокер, рядом с которым меркнет большинство багов в логике.
Что мы проверяем, пока вы думаете, что мы просто кликаем по кнопкам
Мы давно внедрили в наши процессы слой проверок, о которых большинство продуктовых команд даже не задумывается (пока не клюнет жареный петух). Разумеется, всё это мы заранее согласовываем с клиентом, адаптируя под специфику его ниши. Вот лишь несколько примеров того, что наши инженеры ищут на проектах, помимо стандартных функциональных багов.
Ловушки 152‑ФЗ (персданные)
Мы проверяем не только наличие текста про политику конфиденциальности. Мы проверяем поведение системы. Блокируется ли отправка формы, если чекбокс не прожат? Не собирает ли форма лишние данные (принцип минимизации)? Корректно ли работает отзыв согласия из личного кабинета, или кнопка «Удалить аккаунт» – это просто заглушка, которая ставит флаг is_deleted в БД, оставляя данные лежать мёртвым грузом?
Маркировка рекламы (38‑ФЗ)
Боль. Сплошная боль современного рунета. Наши автоматизаторы и ручники проверяют наличие erid токенов в ссылках или на баннерах. Если на проекте есть своя крутилка баннеров, тестировщик убедится, что данные об ИНН рекламодателя не отваливаются при ресайзе окна.
Тёмные паттерны и защита прав потребителей
Знаете, как Роспотребнадзор любит штрафовать за заранее проставленные галочки на платные страховки или SMS‑информирование в корзине? Мы вычищаем эти «тёмные паттерны» на этапе тестирования флоу покупки. Мы проверяем прозрачность рекуррентных платежей, чтобы клиент чётко видел условия до того, как привяжет карту.
Почему это работает именно в аутсорсе?
Справедливый вопрос: «Почему я не могу поручить это своим тестировщикам?»
Можете. И должны! Но давайте будем реалистами. Инхаус‑команды часто перегружены и не всегда имеют релевантную квалификацию. Они бегут в спринтах, горят в дедлайнах и тонут в техдолге. У них просто замыливается глаз. Когда нужно срочно протестировать новый сложный алгоритм рекомендаций, про проверку возрастного шлюза вспоминают в последнюю очередь.
Внешняя команда приносит не только свежий взгляд, но и готовые решения: отполированные фреймворки, чек‑листы и методики (например, «Лаборатория Качества» на рынке 17 лет; естественно, мы работаем с базой, отполированной годами).
Например, мы уже на старте говорим: «Ребята, вы делаете финтех‑продукт. У вас здесь дыра в процессах авторизации (по новому закону нельзя регистрировать граждан через зарубежные SSO), а вот здесь оферта не соответствует флоу оплаты». Таким образом, без промедления превращаем юридические абстракции в конкретные шаги для воспроизведения.
Да простят нас ваши, и без того перегруженные тестировщики, мы поделимся своим базовым чек-листом, благодаря которому можно проверить хотя бы базовые комплаенс-риски. Качайте бесплатно здесь.
Любой QA – это партнёрство, а не просто сервис
Рынок изменился. Законы стали жёстче, штрафы – больше, а внимание контролирующих органов – пристальнее.
Если ваши тестировщики до сих пор проверяют только то, что написано в ТЗ, вы оставляете свои бизнес‑фланги открытыми. Крутой QA‑инженер сегодня – это немного юрист, немного безопасник и во многом – мотивированный адвокат бизнеса.
Поэтому, отдавая тестирование на аутсорс, ищите не просто «руки», которые будут кликать по кнопкам. Ищите партнёров, которые понимают, в какой реальности работает ваш продукт, и готовы защищать его со всех сторон.
Международный контекст
Кстати, а что делать, если ваш продукт выходит на внешние рынки, где существуют свои жёсткие регуляции и даже оборотные штрафы? Тут всё просто: меняются законы, но не инженерные подходы, потому мы также учитываем практики наших иностранных коллег, базирующихся на GDPR (ЕС), HIPAA (США), PIPEDA (Канада) и других.
Раньше мы не делились такими практиками в блоге, но сейчас тема комплаенса и юридических рисков через призму инженерных подходов становится всё актуальнее.
Как считаете, стоит ли шире освещать подобные вопросы? Оставьте комментарий под статьёй или свяжитесь с нами любым другим способом, указанным на сайте.
Будем благодарны за ваши мысли и предложения!
