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

Представляю какого уровня наняли тестировщика, не справившегося с тестом email. В принципе видимо и разработка была того же уровня.

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

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

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

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

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

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

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

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

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

Работал в банке — там к нашим услугам был анонимизированный дамп прямо с прода. Вот это было удобно, но не совсем безопасно

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

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

А где брать реальные данные для нового проекта непонятно :) отсюда и баги с почтами и прочее. Еще я не понял как эти реальные данные появятся, если они не пройдут валидацию и не запишутся в БД.

Спасибо за статью, в моей практике процентов 80% проблем найденных уже на проде были из-за того, что не смогли предугадать такой вариант в тесте, и нет тестировщики были не начинающие и знали систему хорошо. Просто варианты настроек клиента + использование фичи, да много можно чего вспомнить. И чем крупнее система, тем к сожалению чаще такое встречается, тем и хороши canary релизы, с постепенным увеличением охватываемого объема.
И да — данные с прода очень хороши для проверок, к сожалению в тех системах, с которыми я работала их все равно приходилось обфусцировать и опять же есть вопросы к тому, что получалось в итоге обфускации, но как говорится, нет предела совершенству.

Логи надо писать нормальные. и анализировать их.