ООО "Лаборатория Качества"

Молодой FinTech-стартап привлек аутсорс-команду для разработки мобильного банковского/инвестиционного приложения. Проблема заключалась в том, что бизнес-требования были описаны на высоком уровне, что приводило к постоянному недопониманию между заказчиком и разработчиками. Команда разработки часто интерпретировала задачи по-своему. Это порождало бесконечный цикл: "сделали -> показали -> это не то, что мы хотели -> переделываем". Каждый такой цикл — это потеря времени и денег. Скорость вывода продукта на рынок критически снижалась, а бюджет на разработку неконтролируемо рос. Мы внедрили в процесс методологию BDD (Behavior-Driven Development). Наш тест-аналитик стал связующим звеном между бизнесом и разработкой. Он прописывал каждую функциональность в виде пользовательских сценариев на простом языке Gherkin (Given/When/Then). Эти сценарии стали «единым источником правды»: заказчик утверждал их как требования, а разработчики использовали как ТЗ. На основе этих же сценариев мы моментально создавали автотесты. Внедрение BDD позволило сократить количество дефектов, связанных с неверной трактовкой требований, на 90%. Это сэкономило клиенту около 25% бюджета на разработку, что составило более 4 млн рублей, за счет исключения дорогостоящих переделок трех крупных функциональных блоков. Скорость приемки новых фич выросла в 3 раза.

Страховая компания из ТОП-20 заказала у внешнего подрядчика разработку нового модуля для расчета стоимости полисов КАСКО и ОСАГО. Модуль должен был учитывать сотни различных факторов: регион, мощность автомобиля, возраст и стаж водителей, история страховых случаев и т.д. Предварительное внутреннее тестирование показало, что расчеты нового модуля часто расходились с действующими тарифами компании. Отклонения достигали 30% как в большую, так и в меньшую сторону. Запуск такого модуля привел бы либо к прямым убыткам из-за заниженной стоимости полисов, либо к потере клиентов из-за завышенных цен. Мы разработали сложный тестовый фреймворк, который на основе комбинаторики генерировал тысячи уникальных профилей водителей и автомобилей. Система автоматически подавала эти данные в новый модуль, получала расчет и сравнивала его с эталонной матрицей тарифов. Все отклонения, превышающие 0.1%, фиксировались в отчете. Такой подход позволил за несколько дней покрыть тестами больше комбинаций, чем команда ручного тестирования смогла бы обработать за полгода. Мы обнаружили 19 критических и 58 значительных ошибок в логике расчетов. Исправление этих дефектов до запуска модуля предотвратило потенциальные годовые убытки компании и риски штрафов от регулятора. Стоимость наших услуг многократно окупилась еще до ввода системы в эксплуатацию.

Крупный российский промышленный холдинг принял решение о покупке готовой ERP-системы у китайского разработчика. Система позиционировалась как полностью готовое «коробочное решение», требующее лишь минимальной настройки. Сумма сделки была значительной, и оплата должна была пройти после демонстрации работоспособности. Заказчик не обладал достаточной экспертизой для оценки реального качества и готовности сложной ERP-системы. Существовал огромный риск заплатить за «сырой» продукт, доработка которого собственными силами заняла бы многие месяцы и потребовала бы дополнительных инвестиций, сопоставимых со стоимостью самой системы. Мы выступили в роли центра независимой приемки. В течение 3 месяцев наша команда проводила всестороннее тестирование системы: функциональное, интеграционное, частично нагрузочное, а также поверхностный аудит безопасности и качества локализации (корректность перевода, соответствие российским бизнес-процессам и законодательству, например, расчет НДС). Мы составили подробный, приоритизированный отчет о дефектах на двух языках (русский и английский). Мы обнаружили более 150 дефектов, из которых 45 были классифицированы как критические (включая уязвимости, ведущие к несохранности данных). Наш отчет стал для заказчика мощным инструментом в переговорах. Он выдвинул вендору условие: финальная оплата только после исправления всех критических и блокирующих дефектов. По оценке клиента, самостоятельное исправление этих проблем обошлось бы ему в более 9 млн рублей и заняло бы не менее 4 месяцев. Эта сумма была полностью сэкономлена благодаря нашей работе.

Сложный fashion-маркетплейс с аудиторией более 2 млн активных пользователей в месяц. Продукт с веб-версией, мобильными приложениями (iOS/Android), личным кабинетом поставщика и внутренней CRM-системой. Полное отсутствие автоматизации тестирования. Весь регресс проводился вручную командой из 5 QA-инженеров, что было долго и неэффективно. Тестовое покрытие было неизвестно, тестовая документация отсутствовала, а стратегия тестирования не была формализована. Клиент терял долю рынка из-за медленного вывода фич, негативных отзывов, связанных с ошибками при оформлении заказа. Рейтинг в App Store и Google Play упал с 4.7 до 4.1 Провели полный аудит процессов, кода и команды. Разработали QA-стратегию, определили ключевые бизнес-сценарии для автоматизации и выбрали стек технологий. Команда из 3 QA-инженеров взяла на себя ручное тестирование (при этом создала тестовую документацию с нуля), а команда из 2 SDET приступила к автоматизации. С помощью k6 провели симуляцию «Черной пятницы» с нагрузкой в 12 000 одновременных пользователей. Это позволило выявить и устранить узкие места в базе данных PostgreSQL и API-шлюзе. Time-to-Market (TTM) сократился с 4–6 недель до 1-2 недель для мажорных релизов. Цикл регрессионного тестирования ускорился с 7 дней до 4 часов (автоматизированный запуск в CI/CD). Количество критических багов в продакшене снизилось на 95% (менее 1 в релиз). Покрытие кода автотестами достигло 85% для ключевого API и 75% для E2E-сценариев. Заказчик отметил экономию за счёт высвобождения 1,5 full-time QA-инженеров от постоянного исправления регрессионных багов. Общее снижение затрат на обеспечение качества составило 30% за первый год (по оценке клиента). Конверсия в покупку выросла на 8%. Рейтинг приложения в App Store и Google Play вырос с 4.1 до 4.6 за 7 месяцев.

Крупная веб-студия разрабатывала сложный B2B-портал для своего клиента из сферы недвижимости. Портал включал в себя интерактивные карты, систему бронирования, личные кабинеты для агентов и клиентов, а также интеграцию с несколькими сторонними (внешними) API. Студия столкнулась с «размыванием» сроков (просрочка 3-5 недель) и бюджета (35% средств тратили на исправления). Постоянные баги, обнаруживаемые клиентом на каждом этапе приёмки (40-50+ штук), приводили к бесконечным циклам доработок и падению репутации. Клиент угрожал разрывом контракта. Технические проблемы: полное отсутствие выделенной QA-команды. Тестирование проводилось разработчиками и менеджером проекта «по наитию». Отсутствовала система баг-трекинга (баги присылались в Slack), не было регрессионных тестов. На старте мы внедрили Jira для баг-трекинга и управления задачами. Разработали простой, но эффективный QA-процесс (Definition of Done для задач, регрессионное тестирование перед демо). Один QA-инженер был интегрирован в команду студии. Он взял на себя тестирование нового функционала, кросс-браузерное тестирование (Chrome, Safari, Firefox) и документирование тест-кейсов в Qase. Особое внимание уделялось тестированию вёрстки на разных разрешениях экранов. Был создан минимальный, но критически важный набор E2E-тестов на Cypress, покрывающий основной пользовательский путь (поиск объекта, просмотр, отправка заявки на бронирование). Тесты запускались локально перед каждой демонстрацией клиенту. Просрочка по этапам проекта сократилась до 0-3 дней. Проект был сдан в новый согласованный срок. Количество багов, возвращаемых клиентом после UAT уменьшилось до 2-5, а затраты на исправления снизились на 70%. Клиент не только принял проект, но и подписал с веб-студией контракт на техническую поддержку и развитие портала. Бизнес-показатели: веб-студия смогла использовать этот проект как успешный кейс, что помогло им выиграть номинацию в отраслевом рейтинге.

DeFi-платформа на блокчейне Ethereum, предоставляющая услуги кредитования и стейкинга под залог криптоактивов. Общая заблокированная стоимость (TVL) на момент обращения составляла ~$50M. Команда жила в постоянном страхе перед взломом. Любая уязвимость в смарт-контракте могла привести к мгновенной потере всех средств пользователей. Ручное тестирование через MetaMask было медленным, ненадежным и не покрывало всех векторов атак. Отсутствовал формальный аудит смарт-контрактов. Тестирование проводилось только разработчиками в локальной сети Hardhat. Не было E2E-тестов, имитирующих реальное взаимодействие пользователя с платформой через браузерный кошелек. Покрытие кода смарт-контрактов тестами было всего 60% (только позитивные unit-тесты). Аудит безопасности не проводился. Время регресса E2E составляло 2 дня ручного «прокликивания». Уверенность в безопасности релиза была низкой. Специалисты нашей команды с опытом в блокчейне провели полный аудит Solidity-кода. Мы использовали статические анализаторы (Slither, Mythril) и ручной анализ кода для выявления распространенных уязвимостей (reentrancy, integer overflow, access control). Мы расширили существующие тесты на Hardhat/Foundry, доведя покрытие до 98% и добавив тесты на негативные сценарии и проверку всех require. С помощью Playwright + TypeScript мы создали E2E-тесты, которые автоматизировали браузер, устанавливали MetaMask, импортировали тестовые аккаунты и выполняли полный цикл операций (подключение кошелька, депозит, заём, погашение, вывод) на тестовой сети (Sepolia). В ходе аудита было найдено 2 критические и 5 средних уязвимостей, эксплуатация которых могла привести к потере до 20% TVL. Все они были устранены. Время регресса E2E сократилось с 2 дней до 20 минут (запуск в CI/CD). Клиент успешно прошел два независимых внешних аудита, опубликовав отчеты. Это повысило доверие в сообществе и способствовало росту TVL (общей стоимости активов) с $50M до $150M в течение 3 месяцев после нашего вмешательства.

Финтех-стартап запустил мобильное приложение для микро-инвестиций. Приложение позволяет пользователям покупать доли акций и криптовалют. Безопасность, точность расчетов и стабильность транзакций — высший приоритет. Пользователи жаловались на «зависшие» транзакции и неверное отображение баланса. Регулятор вынес предупреждение из-за отсутствия формализованных процессов тестирования. Каждый сбой стоил компании реальных денег и репутации. Тестирование проводилось вручную на нескольких эмуляторах. Не было тестирования бэкенда, отвечающего за финансовые расчеты. Отсутствовало тестирование на реальных устройствах, что приводило к UI-багам на специфических моделях смартфонов. Процент успешных транзакций составлял всего 97%. 3-4 критических бага, связанных с расчётами, попадали в прод стабильно каждый месяц. Время регрессионного тестирования составляло 4 дня силами 3 QA. Рейтинг в App Store / Google Play упал до 3.9. Первым делом мы сфокусировались на API и бэкенде. Была создана матрица тестов для всех финансовых операций (покупка, продажа, пополнение, вывод), включая граничные значения и нецелочисленные расчеты. На Java + RestAssured был создан фреймворк для тотального тестирования всех эндпоинтов, связанных с деньгами. С помощью Appium + Python мы автоматизировали ключевые пользовательские сценарии на iOS и Android. Тесты запускались на ферме реальных устройств BrowserStack, что обеспечило покрытие популярных моделей. Провели тестирование на проникновение (penetration testing), проверив уязвимости, связанные с хранением данных на устройстве и передачей данных по сети (используя Charles Proxy). Процент успешных транзакций достиг 99.99%. Критические баги в продакшене не появлялись за последние 6 месяцев. Время регрессионного тестирования мобильного приложения сократилось до 6 часов (параллельный запуск на ферме устройств). Рейтинг в App Store / Google Play поднялся до 4.7. Компания успешно прошла проверку регулятора. Доверие пользователей выросло, что привело к увеличению среднего чека инвестиций на 25%.

Производственная компания (5000+ сотрудников) заменила устаревшую систему SAP на собственное ERP-решение для управления логистикой, складом и закупками. После релиза нового ERP сотрудники массово саботировали его использование, предпочитая старые процессы в Excel. Это приводило к рассинхронизации данных, задержкам в поставках и неэффективному управлению складом. Уровень принятия (user adoption) был критически низким. Продукт был разработан без участия QA. Основной фокус был на бизнес-логике, но UI/UX был сложным и перегруженным. Отсутствовало тестирование интеграций между модулями, что приводило к потере данных. Уровень принятия пользователями (User Adoption) достиг 15%. 120 обращений в день в среднем получала техподдержка. Время выполнения ключевой операции составляло 15 минут. При этом 25% заказов содержали ошибки из-за проблем с интеграцией. Мы провели серию интервью с пользователями (кладовщиками, логистами) и организовали сессии юзабилити-тестирования. Все проблемы были задокументированы и приоритизированы по степени влияния на бизнес-процесс. Команда из 2 QA-инженеров провела полное регрессионное тестирование всех модулей и их связей. Основной фокус был на тестировании API между сервисами и проверке целостности данных в базе Oracle. Был развернут фреймворк на Selenium + Java, автоматизирующий сквозные бизнес-сценарии (от создания закупки до оприходования на склад). Это позволило гарантировать, что исправления не ломают связанный функционал. Уровень принятия пользователями (User Adoption) вырос до 75% в течение 4 месяцев. Количество обращений в техподдержку снизилось до 10-15 в день. Среднее время выполнения ключевой операции сократилось до 4 минут.

B2B SaaS-платформа, предоставляющая услуги по агрегации, анализу и визуализации больших данных для enterprise-клиентов. Продукт работает с чувствительной информацией и требует высокой степени надежности и безопасности.Высокий отток клиентов (churn rate - 5% ежемесячно) из-за нестабильной работы платформы и периодической недоступности API. С компанией не заключали контракты крупные клиенты, так как она не могла гарантировать выполнение SLA (Service Level Agreement). «Монолитная» архитектура с множеством скрытых зависимостей. Отсутствие нагрузочного и security-тестирования. Автотесты покрывали только «счастливые пути» (~30%), а ошибки в API часто обнаруживались уже клиентами, к тому же, среднее время ответа API под нагрузкой составляло более 2000 мс! Uptime, время которое система работала без остановки составляло ~99.5%, что является нарушением SLA для enterprise. Мы провели аудит архитектуры и API. Разработали стратегию, сфокусированную на трех китах: надежность (API-тесты), производительность (нагрузочные тесты) и безопасность (security-тесты). Разработали на Python + Pytest комплексный фреймворк для тестирования API, покрывающий не только позитивные, но и негативные сценарии, проверку схем ответов и прав доступа. С помощью Gatling мы создали профили нагрузки, имитирующие работу разных типов клиентов. Тесты выявили проблемы с пулом соединений к базе данных и неоптимальные запросы. Провели базовое сканирование на уязвимости (OWASP Top 10) с помощью OWASP ZAP и внедрили статический анализ кода безопасности в CI/CD. Довели показатель Uptime до стабильных >99.9%. Ежемесячный отток пользователей снизился до 3%. Покрытие API тестами увеличилось до 90%. Среднее время ответа API под нагрузкой снизилось до менее 300 мс. А самое важное, что компания успешно прошла технический аудит трех крупных enterprise-клиентов и подписала с ними долгосрочные контракты, увеличив MRR на $200,000.