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