Миграция IT-инфраструктуры таит скрытые риски, способные парализовать бизнес и привести к серьёзным потерям. В статье – практический подход к тестированию: от приёмки и сверки данных до нагрузочных и аварийных испытаний, с примерами реальных кейсов и мини-планом, чтобы заранее выявить уязвимости и снизить риски до переключения.
Третья часть цикла о тестировании без требований. Говорим о метриках, российской специфике и плане наведения порядка в QA-процессах за 90 дней. Полезно тестировщикам, техлидам и продакт-менеджерам, которые работают на проектах без чётких требований и ТЗ.
Это уже вторая часть цикла про тестирование без требований. Рассмотрим практические инструменты. Тестировать на проектах без ТЗ вполне реально: нужно только выстроить системный подход. В статье мы делимся практиками, которые помогают справляться с самыми острыми проблемами. Рассказываем, как оперативно фиксировать требования и отслеживать прогресс без громоздкой документации.
Статья о методологии приёмки для проектов без ТЗ, где требования меняются быстрее, чем вы успеваете дописать тест-кейс. Разбираемся, почему отсутствие ТЗ – это не одна проблема, а целых пять, и почему для решения каждой нужен свой подход. Также вы узнаете об оракулах и карте продукта и рисках.
Пока разработчики заняты кодом, маркетолог рискует столкнуться с оттоком пользователей и обвалом рейтинга приложения. Узнайте из статьи, почему тестировщики — верные союзники маркетологов в удержании позиций на рынке мобильных приложений.
Статья для маркетологов о подготовке сайтов и приложений к приёму трафика перед рекламными компаниями, акциями и распродажами. Маркетолог «Лаборатории качества» делится личным опытом о необходимости нагрузочного тестирования. Внутри разбор ключевых понятий, терминов и пошаговый чек‑лист.
В статье рассказываем, какие метрики мы внедрили вместо подсчёта количества багов, как собрать риск‑матрицу за пару часов, сколько это стоит и что будет, если забить и игнорировать новые подходы в тестировании. Читайте о проверенных на практике решениях, которые действительно работают — без претензии на истину в последней инстанции.
Продукт прошёл функциональное тестирование, но не прошёл главный тест – встречу с реальным человеком. Классический QA не лечит кривой UX. Он вообще не про это. Можно покрыть продукт автотестами на 100%, прогнать регрессию, получить зелёненький отчёт и всё равно слить релиз – потому что пользователь не понял, куда жать.
Выкатываете релиз – всё работает, тесты пройдены, команда довольна. А через месяц приходит штраф на полмиллиона рублей. Причина? Пропущенный токен в рекламе или чекбокс согласия, прожатый по умолчанию. Разбираемся, как комплаенс‑тестирование помогает избежать таких ситуаций и защитить бизнес от претензий регуляторов.
Сегодня всё больше команд задаются вопросом: если разработчики пишут юнит-тесты и прогоняют код через CI, нужен ли отдельный QA вообще? В статье разбираем, когда тестирование силами разработчиков на самом деле работает, а когда превращается в рискованную авантюру для бизнеса.
