# QA — для пограничных случаев

Канонический адрес: https://producthub.live/shape-up/qa-dlya-pogranichnykh-sluchaev
Автор публикации: Product Hub (https://producthub.ru). Опубликовано: 2026-10-13. Обновлено: 2026-10-13.
Книга: Ryan Singer (Райан Сингер), «Shape Up: Stop Running in Circles and Ship Work that Matters», Basecamp, 2019. Оригинал: https://basecamp.com/shapeup

Перевод на русский, часть 3 «Завершить вовремя и двигаться дальше», глава 8 «Определить достаточный результат». Оглавление: https://producthub.live/shape-up

При нынешнем масштабе Basecamp — миллионы пользователей и около дюжины человек в продуктовой команде — у нас один специалист по обеспечению качества, QA. Он подключается ближе к концу цикла и ищет пограничные случаи за пределами основной функциональности.

QA может сосредоточиться на пограничных случаях, потому что дизайнеры и программисты отвечают за базовое качество своей работы. Программисты сами пишут тесты, а команда вместе проверяет, что проект делает то, что должен, согласно проработанному замыслу. Это следует из того, что команда получает ответственность за весь проект, а не отдельные задания.

Много лет у нас вообще не было роли QA. Но когда аудитория выросла до определённого размера, мы увидели, что небольшие пограничные случаи в абсолютных числах затрагивают сотни и тысячи пользователей. Дополнительная проверка QA помогла улучшить их опыт и снизить несоразмерную нагрузку на поддержку, которую эти случаи создавали бы.

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

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

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

Далее: [Когда продлевать проект](https://producthub.live/shape-up/kogda-prodlevat-proekt)