🟢Терабайты синтетических тестовых данных не означают, что у вас есть на чём тестировать

Продолжаем цикл статей о синтетических тестовых данных. Поймите, сгенерированные массивы будут бесполезны, если в данных не сохранены связи между сущностями, не учтены бизнес-правила и редкие сценарии. В первой статье мы разобрали, зачем компаниям нужна синтетика, где её использовать и как это связано с законами РФ.

Теперь переходим от теории к практике ✅

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

‼️По сути, задача не в том, чтобы сгенерировать много данных. Важно сконцентрироваться на качестве, чтобы нормально тестировать продукт, масштабировать проверки и при этом не тащить в тестовый контур реальные ПД.

🔗 Разбираем 7 шагов построения такого конвейера по ссылке.

А в пятницу вас будет ждать обзор инструментов и распространённых ошибок с тремя кейсами, а ещё расчёт экономики для защиты бюджета + план на 90 дней по неделям.

#тестирование #QA #тестовыеданные #синтетическиеданные #нагрузочноетестирование #автоматизациятестирования #152ФЗ #разработкаПО

🟢Стенд был зелёным, но прод лёг через 40 минут после релиза. Нагрузочный контур был огромным – 1,2 млрд транзакций. Тесты показывали p99 в 180 мс. Всё выглядело хорошо. А потом на проде p99 вырос до 4,2 секунды.

Проблема оказалась не в объёме данных, а в том что данные оказались слишком чистыми и ровными. В проде 0,4% мерчантов давали 61% трафика, а на тестовом стенде значения были распределены равномерно. В результате тесты проверяли систему на совсем другом профиле нагрузки. Это один из примеров, который показывает почему синтетические данные – не про генерацию большого количества строк, а про вдумчивый подход.

🔗 Предлагаем прочесть три поучительных кейса в заключительной статье нашего цикла о синтетических тестовых данных.

✅В ней вы также найдёте типичные ошибки работы с синтетикой с учётом российской специфики. Узнаете об экономике внедрения и получите пошаговый план на 90 дней: что делать по неделям, чтобы получить первый рабочий домен, а не просто красивый генератор.

#тестирование #синтетическиеданные #QA #тестовыеданные #нагрузочноетестирование #автоматизациятестирования #тестовыйконтур #разработка

🟢Требований нет, а тестировать надо и срочно. Знакомо? Читайте дальше!

Наверняка, каждый сталкивался с работой на проекте, где продукт живёт своей жизнью, требования меняются на ходу, документация отстаёт, а тестировщику всё равно нужно понимать, что проверять и где искать проблемы. Можно бесконечно ждать внятного ТЗ, что-то просить и жаловаться, но лучше взять и научиться тестировать в условиях неопределённости 😳

Мы посвятили теме тестирования без требований новый цикл из трёх статей и презентуем вам первую. Читайте, чтобы узнать, чем заменить ТЗ, как использовать оракулы, зачем составлять карту продукта. Также расскажем, как выявлять зоны риска и что проверять в первую очередь. Даём подходы, которые помогают не потеряться, когда у проекта нет чётких границ.

Вы сможете взять управление качеством в свои руки без страха и сомнений.

🔗Читайте статью по ссылке.

#тестированиеПО #QA #тестировщики #QALead #продуктоваяразработка #тестированиебезТЗ #рискориентированноетестирование

🟢Конкретики нет. Сроки горят. Тестировать всё равно нужно. Что делать?

Когда требования меняются на ходу, документация устарела, а заказчик сам не до конца понимает, каким должен быть продукт, то тестирование может легко превратиться в бесполезный изматывающий труд 🐒

Как в таких условиях понять, что проверять в первую очередь? Как не пропустить критичные проблемы и не потратить всё время на второстепенные проверки?

Продолжаем цикл статей о тестировании в условиях неопределённости. Вторая статья о QA-практиках, которые помогают эффективно работать в самых туманных проектах.

Разбираем:
🔘как выстроить тестирование, когда требования постоянно меняются;
🔘на какие 4 практики опираться, если документации недостаточно;
🔘как сделать тестирование более системным, даже если проект развивается хаотично.

Статья пригодится тестировщикам, QA-лидам и продакт-менеджерам, которым приходится отвечать за качество в условиях неопределённости.

👉 Читайте по ссылке.

📢 И это ещё не всё: впереди заключительная статья цикла. Уже на следующей неделе. Следите за новостями.

#ТестированиеПО #QA #QALead #Тестировщики #ПродактМенеджмент #ТестированиеБезТЗ #QAПрактики #ЛабораторияКачества

🟢ТЗ нет, требования меняются, возможно ли в таких условиях построить устойчивую систему качества?

Тестировщики вынуждены проверять то, что сами не понимают до конца. Разработчики переделывают один и тот же функционал, продакт спорит с командой, основываясь на ощущениях.

🍒 И вишенка на торте: тест-кейсов становится больше, автотесты запускаются, а предсказуемости так и нет.

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

В статье рассказываем:
🔘какие 5 метрик помогают оценивать качество и принимать решения на основе данных;
🔘какой стек использовать в российских реалиях;
🔘как за 90 дней выстроить QA-процессы – от карты продукта до предсказуемой приёмки;
🔘каких ошибок стоит избегать, чтобы не тратить время на бесполезные тест-кейсы и преждевременную автоматизацию.

🔗 Читайте статью по ссылке.

Статья пригодится тестировщикам, QA-лидам и продакт-менеджерам, которым приходится отвечать за качество продукта в условиях неопределённости.

#ТестированиеПО #QA #QALead #Тестировщики #ПродактМенеджмент #ТестированиеБезТЗ #АвтоматизацияТестирования #ЛабораторияКачества

🟢Готовитесь к миграции IT-инфраструктуры? Тогда обязательно прочитайте это 👇

Мы вошли в эру все более нестабильного интернета. Прежняя уверенность в неуязвимости облачных систем рассыпалась, оставив трезвое осознание, что так как раньше, больше не будет. Недавняя критическая ситуация с дата-центрами в России показала бизнесу, как важно иметь план Б. Практически все игроки IT-рынка получили повод серьезно задуматься о диверсификации данных по разным ЦОД. 

Одни компании уже начали частичный или полный переезд на альтернативные мощности, другие заложили перенос инфраструктуры в план на ближайшие недели. Мы, в свою очередь, как QA-команда, хотим рассказать как сделать все правильно и снизить риски потерь при миграции с помощью тестирования.

Как убедиться, что после миграции продолжит работать не только инфраструктура, но и сам бизнес? В практическом руководстве для CTO, CIO и владельцев продуктов разбираем, как проверить готовность к переезду до того, как риски превратятся в финансовые потери.

Внутри статьи:
🔘какие проблемы могут остаться незамеченными после технически успешного переноса;
🔘как проверить целостность данных, платежи, интеграции и критичные бизнес-сценарии;
🔘какие выводы можно сделать из известных инцидентов TSB Bank и Knight Capital;
🔘мини-план: какие именно проверки запускать перед переключением.

🔗 Читайте руководство по ссылке.

Кстати, если готовите переезд инфраструктуры, запишитесь на бесплатную консультацию к QA-экспертам «Лаборатории качества». Они помогут прояснить важные вопросы. 30 минут в удобном видеоформате.

#ITМиграция #ТестированиеПО #QA #ИТИнфраструктура #НагрузочноеТестирование #Отказоустойчивость #МиграцияДанных #ЛабораторияКачества