Синтетические vs реальные тестовые данные: плюсы, минусы, подводные камни

    Тестирование синтетических данных

    Начнём со сладкого и приведём примеры из практики тестирования.

    Представьте себе готовый к запуску интернет-магазин. Ничего не предвещает беды. Маркетологи разработали стратегию продвижения, были написаны статьи в профильные интернет-ресурсы, оплачена реклама. Руководство ожидало до 300 покупок еженедельно. Проходит первая неделя, менеджеры фиксируют 53 оплаты. Руководство магазина в ярости...

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

    Кейс Лаборатория качества

    Анализ показал, что остальные не смогли оформить покупку из-за адреса электронной почты!
    Тестирование формы заказа отдали начинающему специалисту. Он старался изо всех сил, вводил в поля «ФИО», «Email», «Телефон» все возможные и невозможные варианты, которые давали ему онлайн-генераторы. Спустя неделю все баги были найдены и пофикшены. Релиз состоялся. Но в числе рассмотренных вариантов не было ни одного адреса электронной почты, содержащей менее 8 символов после @.

    Пример ошибки Лаборатория качества

    Так счастливые обладатели почт @ mail.ru, @ ya.ru (и аналогичных) не смогли ввести свою почту и покинули сайт без покупок. Владельцы недополучили порядка 600 тысяч рублей, весь рекламный бюджет был слит в пустоту, а сам интернет-магазин получил кучу негативных отзывов.

    Думаете это единичный случай? Тогда вот ещё одна страшилка для заказчика.

    На волне всеобщего интереса к безналичным расчетам, компания по выдаче займов решила ввести новый способ перечисления денежных средств — на банковскую карту заемщика. Реализовали соответствующую форму в личном кабинете менеджера, протестировали разные варианты ошибок в полях для ввода данных карты, пофиксили, начали работать. Спустя месяц до руководства дошла информация, что 24% потенциальных заемщиков, которые уже получили одобрение, не оформили займ до конца. Почему? Они предоставляли банковскую карту, номер которой содержал 18 цифр, вместо заложенных и протестированных 16. Ни система, ни менеджеры не могли зарегистрировать такие карты, и клиенты уходили ни с чем.

    Финансовые потери без тестирования

    Пилотный проект был внедрен в 3 офисах города. Среднее количество ежемесячных займов по трём офисам равнялось 340. Итог: организация потеряла, как минимум, 612 тыс. руб. выручки.

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

    Однако, чаще всего они видят пользователя не многомерным, как в кинотеатре с 3D-очками, а схематичным, как будто ребёнок нарисовал человечка на альбомном листе.

    Это приводит к тому, что тестировщик не покрывает все возможные тестовые ситуации и не может работать с большим объёмом данных. И, хотя тестирование может быть проведено хорошо, нет никаких гарантий, что система не упадёт, когда самый настоящий пользователь (чаще всего нелогичный и даже непредсказуемый) начнёт взаимодействовать с продуктом.
    Сегодня мы поговорим о том, каким данным отдать предпочтение в процессе тестирования: синтетическим или реальным.

    Разберёмся в терминах


    Каждый раз, когда мы берёмся за тест, мы решаем, какими тестовыми данными мы будем пользоваться. Их источниками могут быть:

    1. Копии БД продакшн-версии на тестовый стенд.
    2. БД сторонних систем клиента, которые могут использоваться в текущей.
    3. Генераторы тестовых данных.
    4. Ручное создание тестовых данных.

    Первые 2 источника предоставляют нам реальные тестовые данные. Они создаются при существующих процессах пользователями или системой.

    Реальные тестовые данные ЛК

    Например, когда мы присоединяемся к проекту по разработке веб-продукта для производственной компании, мы можем для тестирования воспользоваться копией существующей БД 1С, которая на протяжении нескольких лет собирала и обрабатывала все данные об операциях и клиентах. С помощью модуля формирования и отображения отчетов о выполненных заказах мы получаем информацию из 1С в нужном формате и работаем с реальными тестовыми данными.

    Источники из пунктов 3 и 4 мы называем «синтетическими тестовыми данными» (такой термин можно встретить в зарубежном тестировании, но в русскоязычном сегменте он используется редко). Такие данные мы создаём сами для целей разработки и тестирования.

    Синтетические тестовые данные ЛК

    Например, мы получили заказ от новой электронной торговой площадки для проведения закупок государственными и муниципальными организациями по 44 ФЗ. Здесь соблюдаются очень строгие правила защиты информации, поэтому у команды нет доступа к реальным данным. Единственный выход для проведения тестирования: создать весь набор тестовых данных с нуля. Даже физические электронно-цифровые подписи, которые предназначены исключительно для тестирования.

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

    Для проверки ограничений и исключений в той же системе для производственной компании мы дополнительно задействовали синтетические данные. С их помощью мы проверили, как поведет себя отчет, если в одном из заказов будут отсутствовать продукты. На электронной торговой площадке мы комбинировали синтетические данные с реальными справочниками ОКПД2 и ОКВЭД2.

    Возможности синтетических данных


    Плюсы синтетических тестовых данных

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

    1. Упрощение и стандартизация


    Часто реальные данные представляют собой однородные массивы данных: представьте, что в системе регистрируются тысячи физических лиц с одним набором атрибутов, юридические лица, отличающиеся по типу, стандартные операции и множество других типов сущностей. Тогда зачем тратить часы на тестирование одинаковых входных данных, если можно объединить их в группы и для каждой группы назначить «представителя»?

    На одном из прошлогодних проектов заказчик решил усилить команду тестировщиков перед очередным релизом, для чего была привлечена команда из наших специалистов. Продукт содержал доработанную форму регистрации с множеством полей. Мы заложили на тест формы 30 минут и потратили примерно столько же времени. Параллельно же вскрылось, что ранее эту форму уже тестировал другой тестер, потратив на это 7 часов. Почему? Просто он решил прогнать тест по реальным данным 12 сотрудников из штатного расписания и не учёл, что тест по одному сотруднику покрывает все атрибуты, одинаковые для каждого регистрируемого профиля.

    Профит: 6 часов 30 минут и это только на одном тесте.

    2. Комбинаторика и покрытие тестами


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

    Вернёмся к предыдущему примеру. Форма регистрации в новом релизе дорабатывалась не просто так. Команда заказчика, исходя из норм корпоративной культуры, решила сделать область отчества обязательной. Итог, у всех иностранных специалистов в штате резко появился один отец — Иван (кто-то сказал писать Иванович, пока не починят). Случай забавный, но если вы не учитываете какие-то хотелки или параметры своих клиентов в тестах, то не обижайтесь, если эти люди потом не будут учитывать вас в своих затратах/отзывах.

    3. Автоматизация


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

    Тут наглядным будет пример из банковской сферы. Чтобы проверить правильно ли приложение проставляет номера банковских счетов в генерируемых им документах, мы потратили 120 человеко/часов на написание автотестов. Доступа к БД не было, потому номер счёта был указан в самом автотесте. Тесты отлично себя показали и мы уже готовы были рисовать в отчёте 180%+ ROI от автоматизации. Но через неделю произошло обновление БД с изменением номера счёта. Все автотесты, как и наши усилия по автоматизации благополучно попадали. После доработки автотестов, итоговый ROI снизился до значения 106%. С тем же успехом мы могли сразу начать тестировать руками.

    4. Повышение управляемости


    Используя синтетические данные, мы знаем (в худшем случае, предполагаем), какого отклика ждать от системы. Если в функциональность вносятся изменения, мы понимаем, как изменится отклик на те же самые данные. Или мы можем подкорректировать данные, чтобы получить желаемый результат.

    В одном из проектов наша команда приступила к тестированию с использованием реальных данных из БД контрагентов заказчика. БД активно дорабатывалась, но на тот момент она была составлена крайне небрежно. Мы теряли время, пытаясь понять где ошибка, в функционале или в БД. Решение было простым, составить синтетичекскую БД, которая стала короче, но адекватнее и информативнее. Тестирование этого функционала было закончено за 12 человеко/часов.

    Так в чём же недостатки?


    Может показаться, что синтетические данные всесильны. Так оно и есть, пока вы не столкнётесь с человеческим фактором. Синтетические данные преднамеренно создаются людьми и в этом их главный недостаток. Мы физически не можем продумать все возможные варианты развития событий и комбинации входных факторов (да и форс-мажоры никто не отменял). И тут преимущество остаётся за реальными данными.

    Преимущества работы с реальными данными


    Плюсы реальных тестовых данных

    Какие же преимущества мы видим в работе с реальными данными? 4 пруфа из нашего опыта:

    1. Работа с большими объёмами информации


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

    Пруф: мы создали синтетическую мини-БД, которая, как нам казалось, соответствовала всем критериям существующей у заказчика базы. С синтетической базой всё работало великолепно, но стоило запустить тесты с реальной базой, как всё посыпалось. Итог: если не можете учесть все нюансы реальной выборки данных, не тратьте время на генерацию синтетических данных.

    2. Использование разнообразных форматов данных


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

    Пруф: мы тестировали поле загрузки фотографии в профиль пользователя. Попробовали самые распространенные графические форматы из базы, плюс несколько видео- и текстовые файлы. Синтетическая подборка загружалась отлично. При реальной эксплуатации выяснилось, что любая попытка загрузить звуковой файл вызывает ошибку. Вся регистрационная форма крашилась без возможности заменить файл. Не спасало даже обновление страницы.

    3. Непредсказуемость поведения пользователей


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

    Пруф: у нас в компании каждый год сотрудники проходят аттестацию, где, в числе прочего, оценивают свои навыки в специальной анкете. Оценки согласовываются с руководителем, и на основе их рассчитывается грейд (уровень) специалиста. Перед релизом модуль был полностью проверен, всё работало как часы. Но однажды именно в момент сохранения результатов на систему была совершена ddos-атака, в результате которой сохранилась только часть данных, а последующие попытки сохранения только дублировали ошибки. Без реальной ситуации мы бы не отследили такую серьезную ошибку.

    4. Обновления систем


    Очень важно понимать, как поведёт себя система при обновлении, какие возможны риски, что может «не взлететь». В программах типа 1С, где огромное количество справочников и связей, вопрос обновлений стоит особенно остро. И здесь лучшим вариантом будет иметь свежую копию продакшен-версии, тестировать обновление на ней, и только потом релизиться.

    Пруф: случай достаточно распространенный. Проект в сфере факторинговых услуг. Критичность потери и искажения данных зашкаливает, а любое подозрение к актуальности воспроизводимых системой данных может остановить работу всего офиса. И тут наш спец криво выкатывает очередное обновление сразу на прод, не захватив при этом последние 10 версий билдов.

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

    С тех пор мы в обязательном порядке работаем с тремя стендами:

    1. Develop. Сюда выкладываются доработки, творится анархия и беспредел, называемые тестированием исключений. QA-инженеры работают, в основном с синтетическими данными, реальные заливаются нечасто.
    2. Pre-release. Когда все доработки реализованы и протестированы, они собираются в данную ветку. Сюда же предварительно накатывается версия с прода. Таким образом мы тестируем обновление и работу новых функций в условно боевых условиях.
    3. Production. Это уже рабочая, боевая версия системы, с которой работают конечные пользователи.

    Так с какими данными и когда работать?


    Какие тестовые данные выбрать

    Делимся 3 инсайтами нашей работы с реальными и синтетическими данными:


    1. Помните, что выбор типа данных зависит от целей и этапа тестирования. Так, разрабатывая новую систему, мы можем оперировать только синтетическими данными. Для покрытия различных комбинаций входных условий, тоже, чаще всего, обратимся к ним. А вот воспроизводство какого-нибудь хитрого исключения, связанного с поведением пользователя, потребует уже реальных логов. Это же относится к работе с общепринятыми справочниками и реестрами.

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

    3. Не переходите на сторону сплошной синтетики, но и не зацикливайтесь на реальных данных. Используйте комбинированный подход к тестовым данными, чтобы не пропускать ошибки, экономить время и показывать максимальные результаты в своей работе.

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

    Давайте обсудим. Расскажите в комментариях о своих кейсах работы с синтетическими и реальными тестовыми данными. Давайте разберёмся, кого среди нас больше: реалистов или синтетиков? ;)

    Виктория Соковикова.
    Тест-аналитик at «Лаборатория качества»
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 15

      +2
      Представляю какого уровня наняли тестировщика, не справившегося с тестом email. В принципе видимо и разработка была того же уровня.
        0
        Это скорее крайний случай. Хотя зачем далеко ходить.
        Наша последняя статья: habr.com/ru/post/440486 — там последний коммент от reishi, он отлично отражает подход некоторых компаний к тестированию.
        Потому не удивительно, что до сих пор случается после таких «QA инженеров» заходить на проект.
        +3
        Расскажите в комментариях о своих кейсах работы с синтетическими и реальными тестовыми данными. Давайте разберёмся, кого среди нас больше: реалистов или синтетиков?


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

        Вот вам первый «кейс»:
        Как правило, в моих проектах компьютер работает не сам по себе. Он управляет какой-то подключенной к нему технологической установкой (станком, линией).

        И в состав разрабатываемого софта практически всегда входит программа — эмулятор этой самой технологической установки, или станка. Она воспринимает команды устройству и в ответ генерирует набор тех самых синтетических данных.
        Причем обычно сначала разрабатывается именно эмулятор.

        Зачем это нужно:
        1. Можно отлаживать свой код в спокойной обстановке, а не в цеху (там бывает шумно, жарко, холодно). Бывает, подключенный к компьютеру девайс должен находиться вне помещения. (Тут есть желающие отлаживать софт в Якутии зимой при температуре в минус 45?)
        2. С помощью эмулятора можно легко получить такие предельные и запредельные величины, которые в ходе штатной работы системы получиться не должны. Например, датчик температуры воды в магистрали, который обычно выдает величины 10-20 градусов. Как проверить поведение софтины, если внезапно воды в магистрали не окажется? (В принципе, такое имеет право произойти, то есть зимой эта температура запросто может стать отрицательной).
        3. Эмулятор позволяет легко и просто моделировать всякие отказы оборудования, поломки и аварийные ситуации. Например, программа посылает команду на закрытие какого-нибудь клапана, а расходомер жидкости, с этим клапаном связанный, спустя какое-то время продолжает показывать поток порядка несколько литров/сек. Это означает, что у нас или клапан не сработал, или еще что-то случилось, но где-то в цеху прямо сейчас льется кислота, причем куда она льется — непонятно! То есть софтина должна зажечь на операторском щите здоровенную красную лампу, и в дополнение к ней включить ревун (вдруг оператор дежурной смены ночью задремал). Причем в жизни эта логика иногда оказывается весьма хитрой и довольно таки не очевидной. Как все эти ситуации проверять на реальном оборудовании? (Проверка исправности сигнализации обычно предусмотрена, но ведь ломать оборудование никто не даст. А тут достаточно мышкой щелкать и спокойно смотреть, что происходит при возникновении той или иной аварии, в разных комбинациях).

        То есть, без синтетических данных с эмулятора, как видите, не удастся обеспечить приемлемое покрытие тестами.

        Но одним эмулятором тоже обойтись не получается. При отсутствии данных, полученных в ходе «боевой» эксплуатации системы, тоже не получается отловить многие баги и глюки. Причем проверять все надо в комплексе, ибо причина возникновения бага может крыться не только в программном коде.
        Было дело, когда неправильное поведение моего софта были вызваны неудачным расположением оборудования на предприятии (дело было на мукомольном комбинате). Один из датчиков (который был довольно чувствителен к вибрационным помехам) оказался смонтирован совсем рядом с ситовейной машиной. (Ну вот представьте себе обычное сито, только через него просеивается больше 10 тонн муки в час). Когда оно работало, там вокруг все ходуном ходило, и датчик, понятно, выдавал нечто несуразное. Самое интересное, что и перенести этот датчик в другое, более спокойное место, не получалось. Пришлось мне допиливать софт, вводить фильтрацию нежелательных помех (уровень которых на порядок превышал уровень полезного сигнала). На этапе разработки и тестирования, ясен перец, такие вещи не приходили в голову никому. (Почему на других мельницах такой проблемы не возникало? Потому что обычно можно было найти более удобное место для установки этого датчика)

        Другой «кейс» — когда множественные малопонятные сбои компьютера были вызваны его неправильным подключением к электросети. Местные КИПовцы, не подумавши, подключили промышленный компьютер к той же самой питающей линии, на которой находились несколько довольно мощных (около 20 кВт каждая) машин. Помехи, вызываемые электродвигателями, так лихо пролезали через не самый дешевый ИБП и через блок питания компьютера. (до того мне и в голову не приходило, что такое может быть) А я там всю голову сломал в размышлениях «какого ж хрена программа-то виснет, причем вместе со всей системой?». А там программа была не особо простая: асинхронный ввод-вывод, несколько потоков, всякие там мьютексы с критическими секциями, и вот это все. Естественно, я грешил на свою ошибку в синхронизации потоков, которая могла вызвать «перекрестное ожидание». А обнаружился этот «баг» совсем случайно. (Мне стало интересно, а с чего это мой софт виснет только в те моменты, когда в вашем цеху что-то такое эдакое мощное выключается?).
        Поглядел, куда идут кабели… Сказал КИПовцам, чтобы они больше так не делали. Они шустро перебросили питание на другую линию, и случилось чудо — подвисания пропали.

        Вот оно как бывает в жизни.

          0
          Вот это пример, спасибо, очень интересно! Вообще жаль, что в сети не так много информации о тестировании в производстве — все чаще разговор про корпоративные и массовые ИТ продукты (на которые внешняя среда не так сильно влияет). Здесь я бы передала «привет» специалистам, которые тестируют некоторые бытовые датчики пожара, которые воспринимают пыль как дым и во время ремонта срабатывают каждые 15 минут :(
          0
          Работал в банке — там к нашим услугам был анонимизированный дамп прямо с прода. Вот это было удобно, но не совсем безопасно
            0
            не совсем безопасно

            почему? я видел на соревнованиях по машинному обучению используются банковские данные или например сотовых операторов, и надо было предотвратить на основе этих данных отток клиентов например. Или там нереальные а какие то искусственные данные?
              0
              А в чем был риск, если не секрет? Не все анонимизировали? Или в самом механизме обезличивания? Мы сейчас на внутреннем проекте тоже анонимизируем информацию о финансовых потоках и адреса электронной почты, а остальные данные накатываем с прода.
                0
                Там база была таблиц на несколько сотен и механизм анонимизации был, так сказать, не идеален — помню, что где-то в недрах базы можно было наткнуться на необработанные данные клиентов.
              0
              Параллельно же вскрылось, что ранее эту форму уже тестировал другой тестер, потратив на это 7 часов. Почему? Просто он решил прогнать тест по реальным данным 12 сотрудников из штатного расписания и не учёл, что тест по одному сотруднику покрывает все атрибуты, одинаковые для каждого регистрируемого профиля.

              В случае единичного тестирования по одному сотруднику, снижается вероятность обнаружить потенциально проблемный участок: юзер без отчества; юзер, родившийся 29 февраля; юзер с двойной фамилией; юзер с несклоняемой фамилией
                +1
                Полностью поддерживаю. Тут как раз без синтетики и наработок/опыта не обойтись. В реальных данных может быть 100 человек со «стандартными» ФИО и датой рождения, адресом и паспортом, а 101й окажется иностранцем без отчества с двойной несклоняемой фамилией, родившийся 29 февраля — и будет как в анекдоте "… Первый реальный клиент заходит в бар и спрашивает, где туалет. Бар вспыхивает пламенем, все погибают." :)
                0
                А где брать реальные данные для нового проекта непонятно :) отсюда и баги с почтами и прочее. Еще я не понял как эти реальные данные появятся, если они не пройдут валидацию и не запишутся в БД.
                  0
                  Все зависит от проекта, конечно — в некоторых случаях реальным данным взяться неоткуда, спасет только синтетика. Но, бывает, применимы базы, которые есть в открытом доступе (мы на проектах периодически использовали) — государственные реестры (если это применимо к проекту опять же), базы адресов, товаров, видов деятельности, учреждений и компаний. Если говорить про корпоративную или отраслевую ИС, можно взять данные из реальной деятельности. Например, при тестировании системы для полиграфии мы брали в т.ч. реальные данные по заказам продукции у заказчика. Если заказчика нет, то идешь на сайты покупки/продажи услуг, объявлений :)
                    0
                    в сеть же сливают разные взломанные аккаунты, мне кажется вот их и можно использовать для таких тестов.
                    0
                    Спасибо за статью, в моей практике процентов 80% проблем найденных уже на проде были из-за того, что не смогли предугадать такой вариант в тесте, и нет тестировщики были не начинающие и знали систему хорошо. Просто варианты настроек клиента + использование фичи, да много можно чего вспомнить. И чем крупнее система, тем к сожалению чаще такое встречается, тем и хороши canary релизы, с постепенным увеличением охватываемого объема.
                    И да — данные с прода очень хороши для проверок, к сожалению в тех системах, с которыми я работала их все равно приходилось обфусцировать и опять же есть вопросы к тому, что получалось в итоге обфускации, но как говорится, нет предела совершенству.
                      0
                      Логи надо писать нормальные. и анализировать их.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое