Тестирование

Сервисы, в которых данные собираются и обрабатываются на основе других сервисов, очень чувствительны к интеграциям. Технические решения часто реализованы на брокерах, например, таких как Kafka. В нашем случае была задача с финансовой отчетностью и десятками вариантов состояния документов.

По мере роста продукта регрессионное тестирование быстро становится узким местом: количество сценариев растет, время проверки увеличивается, а цена ошибки перед релизом становится выше. В нашем случае переход к E2E-автотестам стал способом ускорить регресс и основой стабильных, предсказуемых релизов. В статье делимся тем, как мы выстроили покрытие регресса автотестами и встроили его в рабочие процессы команды.

Ошибки в требованиях — один из самых дорогих источников проблем в разработке программного обеспечения. На старте проекта они редко выглядят критичными, но ближе к релизу почти всегда оборачиваются доработками, срывом сроков и сложной коммуникацией между заказчиком и командой.

В своей практике мы используем тестирование требований к ПО (requirements testing / requirements review) как часть подхода shift-left testing. Это позволяет находить дефекты требований еще до начала разработки и снижать стоимость их исправления в 5–10 раз. В этой статье рассказываем, как выстроен процесс тестирования требований у нас и какие измеримые результаты он дает на реальных проектах.

Как архитектурный подход помог нам ускорить тестирование и сократить затраты на поддержку.

Мы отказались от устаревших статичных данных в автотестах и создали систему динамической генерации тестовых данных. Теперь каждое тестирование отражает реальное поведение пользователей, и именно это сделало его надежнее.

Когда автоматизация тестирования превращается в «хаос инструментов», компания теряет не только часы работы инженеров, но и уверенность в качестве продукта. Наш опыт перехода с Postman на Cypress показал: консолидация — это стратегический шаг, который напрямую влияет на скорость релизов и стабильность бизнеса.

Рассказываем, как обеспечить быструю и безопасную миграцию с одной технологии на другую с использованием ИИ.

E2E - тесты - отличный инструмент, чтобы идти в прод и не беспокоится о том, что что-то сломается. Мы в TE активно его используем и готовы делиться опытом. При написании тестов мы использовали TestContainers на реальных проектах и посчитали инструмент очень удобным. После чего нам захотелось рассказать о нем подробнее и показать его возможности.

E2E - тесты - отличный инструмент, чтобы идти в прод и не беспокоится о том, что что-то сломается. Мы в TE активно его используем и готовы делиться опытом. При написании тестов мы использовали TestContainers на реальных проектах и посчитали инструмент очень удобным. После чего нам захотелось рассказать о нем подробнее и показать его возможности.

Рассказываем про плюсы и минусы UI-тестирования мобильных приложений.

Скорость поставки функций пользователям – ключевой показатель эффективной разработки. Чем меньше time-to-market, тем выше конкурентное преимущество. На этот показатель влияет не только скорость разработки, но и скорость тестирования. Рассказываем, как нам удалось оптимизировать этот процесс с помощью всего одной встроенной консоли.

Сегодня подробно расскажем о том, как мы трансформируем процессы тестирования: внедряем стандарты автоматизации и встраиваем автоматические тест-планы в процесс разработки.

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

Сегодня мы поделимся критериями, которые используют наши команды, чтобы удостовериться в качестве продукта при поставке на продакшн.

Quality Gates – это автоматические проверки качества, которые устанавливают пороговые значения для продвижения продукта по конвейеру разработки. Рассказываем, как работает эта технология, и поделимся дорожной картой, которую мы составили, чтобы внедрить Quality Gates во всех наших командах.