Почему мы подключаем QA с первого дня проекта
Одна из ключевых проблем, с которыми сталкиваются компании, заказывающие разработку, — это разрыв между ожиданиями и реальностью. Причины бывают разные: неполное или неструктурированное ТЗ, размытые пользовательские сценарии, неучтённые роли или ветвления логики, которые всплывают на стадии разработки и тестирования.
Мы приняли решение: QA подключаются к проекту на этапе первого ознакомления с ТЗ от заказчика, ещё до оценки, дизайна и начала разработки. Этот подход сильно влияет на качество итогового продукта и помогает заказчику получить то, что действительно нужно — без множества итераций «переделать» и «добавить, потому что забыли».
Ниже расскажем, как у нас выстроен процесс, какие задачи берут на себя QA, и почему мы считаем, что раннее подключение тестирования — это не просто хорошая практика, а основа устойчивой разработки.
Чем мы занимаемся и почему нам важна точность на старте
Мы — IT‑компания, специализирующаяся на заказной разработке цифровых продуктов. Работаем в следующих направлениях:
- outsource;
- outstaff;
- обучение LLM;
- внедрение LLM;
- компьютерное зрение;
- Telegram mini apps;
- HR Tech;
- дизайн мероприятий.
Многие из этих решений разрабатываются с нуля и под конкретный бизнес. Это значит, что не существует универсального шаблона — каждый проект требует вдумчивой проработки логики, ролей, ограничений и сценариев. Именно поэтому точность на старте критична: чем лучше проработано ТЗ до начала разработки, тем меньше доработок и недопонимания впоследствии.
Рассылка: как вести бизнес в России
Пять полезных писем пришлем сразу после подписки. В них — бизнес‑идеи, готовые промпты для нейросетей, советы, как выбрать налоговый режим и получать пассивный доход
Роль QA в нашей команде: не только тестирование
Наши QA участвуют в проекте с первых дней. Это не формальность — они не просто читают документацию, а помогают её формировать. В частности, QA:
- структурируют поступившее от заказчика ТЗ;
- выделяют функциональные блоки;
- формируют уточняющие вопросы;
- работают над схемами и диаграммами логики;
- а самое главное — проверяют, насколько требования реализуемы и согласованы между собой.
Мы используем такие инструменты, как UML‑диаграммы, ER‑диаграммы, BPMN, Use Case‑сценарии. Всё это оформляется в Miro, где удобно работать над схемами в команде и комментировать блоки.
Наша задача на этом этапе — перевести бизнес‑язык заказчика на язык разработки и одновременно — выловить противоречия и пустые места в логике до того, как они станут багами.
Наши QA не ведут коммуникацию с заказчиком напрямую. Но они плотно взаимодействуют с селлерами и лидами разработки и на основе текущей информации помогают формализовать требования. Это снижает нагрузку на менеджеров и ускоряет проработку проекта.
Как это работает на практике
Заказчик приходит с ТЗ. Оно может быть подробным, а может состоять из тезисов, что хотелось бы реализовать в продукте.
Далее происходит следующее:
- QA разбивают информацию на структурные блоки — экраны, роли, сценарии, ограничения, точки перехода.
- На основе анализа составляются вопросы, которые передаются в команду, ответственную за коммуникацию с заказчиком.
- Параллельно разработчики начинают верхнеуровневую оценку трудозатрат. В процессе заполнения таблицы с оценками они тоже оставляют вопросы, если логика не до конца ясна.
- Все вопросы объединяются, уточняются, и через менеджеров идут в диалог с заказчиком.
Такой процесс позволяет уточнить максимум информации до старта разработки и значительно уменьшает риск изменения требований на лету.
Когда это спасло проект
Один из проектов, с которым мы работали, сопровождался очень подробным бизнес‑ТЗ — документ содержал более 70 страниц описания сервиса. Всё выглядело детально и проработано.
Однако при формировании схемы ролей и доступов наши QA обнаружили логические противоречия: несколько ролей получали доступ к функциям, к которым не должны были иметь отношения. Это было связано с тем, что в тексте документа не было визуального представления логики переходов, и ошибки остались незамеченными.
На этом этапе проблема была решена за один день — без этой работы её бы пришлось исправлять на этапе тестирования, переделывая часть кода и логику авторизации.
Когда QA подключились слишком поздно
Был и обратный пример. В одном проекте QA привлекли только после завершения основной разработки. На этом этапе в процессе ручного тестирования были найдены баги, затрагивающие критически важный функционал — в частности, неверно работали переходы между статусами в заказах и была перепутана логика ролей.
Переделка потребовала нескольких недель и повлекла перенос сроков. Всё это можно было предотвратить, если бы проработка логики с QA началась с самого начала.
Внутренние процессы: как это устроено
Мы работаем по Agile: QA входят в спринты наравне с разработкой. Внутри спринта QA выполняют не только тестирование, но и работу, близкую к системной аналитике: анализ, структурирование, детализация, согласование требований, построение логики.
Тест‑кейсы и баг‑репорты ведём в YouTrack и Qase, используем CI/CD, чтобы как можно раньше получать обратную связь по стабильности продукта.
CI/CD (Continuous Integration / Continuous Delivery) — это подход к разработке, при котором изменения в коде регулярно проходят автоматические проверки, сборку и доставку в тестовую или продуктивную среду. Такой процесс помогает быстрее находить ошибки, сокращать цикл поставки и минимизировать человеческий фактор.
Зачем это заказчику
Когда QA работают с самого начала, заказчик получает не просто «протестированный» продукт. Он получает:
- прозрачную архитектуру с понятной логикой;
- согласованные требования, переведённые в схемы;
- минимум доработок в процессе разработки;
- экономию времени — на исправление неочевидных ошибок;
- повышенное доверие команды к требованиям — все понимают, что делают и зачем.
Мы не ставим знак равенства между QA и тестированием. Для нас QA — это про качество проекта целиком, а не про поиск багов. И именно поэтому мы включаем их в процесс с первого дня.
Если вы находитесь в поиске команды, которая помогает не просто писать код, а проектирует продукт вместе с вами, задаёт неудобные вопросы до начала разработки и экономит вам месяцы правок — значит, вам нужен именно такой подход.
