Тестовые данные компании — это набор сведений о вымышленном юридическом лице, который подставляют в формы, счета и демонстрационные сценарии вместо настоящей организации. Такой набор выглядит правдоподобно, но не принадлежит никому: его нет в официальном реестре, по нему нельзя выставить реальный счёт, и он ничего не говорит о настоящем бизнесе. Ниже разберём, зачем он нужен, из чего состоит и что важно учесть разработчику.
Зачем выдумывать организацию вместо настоящей
Причин три, и все они практические.
Первая — форме нужны данные, которых у вас пока нет. Пока продукт не подключён к настоящему заказчику, поля с названием, регистрационным номером и номером VAT остаются пустыми, и проверить обязательность, длину и порядок сообщений об ошибках не на чем.
Вторая — демонстрация. Скриншот, прототип или презентация с пустыми полями выглядят неубедительно, а подставлять туда действующего клиента нельзя: его реквизиты попадут в файл, который потом уедет наружу.
Третья — воспроизводимость. Настоящие реквизиты не дают повторяемого результата: вы не управляете их появлением, и один и тот же прогон дважды не соберётся. Вымышленная запись, наоборот, полностью определяется входными данными, поэтому её можно закрепить в автотесте и сравнивать с эталоном.
Почему реальные реквизиты для тестов не подходят?
Соблазн взять данные действующей компании понятен: они «точно правильные». Но именно эта правильность здесь и мешает.
Регистрационный номер и номер VAT существуют, чтобы однозначно указывать на конкретное юридическое лицо в официальном реестре. Если такой номер появится в тестовой заявке, счёте или письме, он всё равно будет указывать на реальную организацию — независимо от ваших намерений. Возникает видимость деловых отношений, которых нет.
Дальше — утечка. Тестовые базы, выгрузки, журналы и скриншоты почти никогда не защищены так же строго, как настоящая клиентская база. Реквизиты реального партнёра в таком окружении — это уже вопрос о персональных и коммерческих данных, а не о качестве проверки.
И третье: настоящие реквизиты плохо подходят для теста ещё и потому, что меняются. Компания переезжает, меняет форму или налоговый статус, а фикстура остаётся прежней — и тест падает по причине, которая к вашему продукту отношения не имеет.
Из чего состоит рабочая запись
Состав полей зависит от задачи, но базовый набор у большинства сценариев один и тот же.
| Поле | Что содержит | Зачем нужно в тесте |
|---|---|---|
| Название компании | Вымышленное наименование с пометкой образца | Длина, регистр, переносы в вёрстке |
| Правовая форма | Тип организации по правилам страны | Условные поля формы и шаблон счёта |
| Отрасль и размер | Сфера деятельности и число сотрудников | Демонстрационные данные и фильтры |
| Юридический адрес | Адрес из потока адресных данных | Обязательность, формат индекса, страна |
| Регистрационный номер | Номер, присвоенный регистрирующим органом | Основная проверка реквизитов |
| Номер VAT | Номер налоговой регистрации | Сценарии с НДС и зарубежные счета |
| Контакт | Телефон или служебный адрес образца | Проверка контактных полей |
| Ключ личности | Строка, задающая все случайные значения | Воспроизводимость между запусками |
Стоит помнить, что весь набор привязан к стране. Налоговый номер, формат адреса и допустимые правовые формы определяются юрисдикцией, и переносить запись из одной страны в другую без пересборки нельзя: получится смесь, которая не пройдёт ни одну реальную проверку.
Последняя строка важнее, чем кажется. Если у каждой страницы сайта свои случайные значения, демонстрационные записи расходятся: адрес из одного раздела не совпадает с адресом в счёте, а имя сотрудника — с названием его работодателя. Общий входной ключ убирает целый класс таких расхождений, и именно поэтому он полезен в связке «человек — адрес — компания».
Как убедиться, что запись не столкнётся с настоящей?
Полностью исключить совпадение случайной строки с реальными данными нельзя, но вероятность сводят почти к нулю тремя приёмами.
Первый — использовать зарезервированные под документацию значения. В справочной литературе и стандартах принято держать отдельные примерные домены и примерные диапазоны адресов: они специально не принадлежат никому, и их появление в тексте никого не вводит в заблуждение.
Второй — называть вещи своими именами. Наименование вида «Пример Торговая Компания» сразу читается как образец, и его нельзя спутать с действующим юридическим лицом.
Третий — держать тестовые записи только в тестовых окружениях. Даже идеально вымышленная запись, попавшая в рабочую базу, создаёт путаницу в отчётности и поддержке.
Для разработчиков: как устроить такую запись
Начните с ширины полей. Название компании в разных странах содержит диакритику, дефисы, амперсанды и лигатуры, а иногда записывается без пробелов. Если поле рассчитано на короткие латинские строки, половина мира в него не поместится — и вы узнаете об этом не на тесте, а на первом настоящем заказчике.
Держите юридическое название и отображаемое имя двумя полями. Официальное написание в документах и то, как компания хочет выглядеть в интерфейсе, — разные вещи, и попытка вывести одно из другого заканчивается обрезанными или удвоенными формами.
Отделяйте правовую форму от самого названия. Хранить их вместе удобно ровно до первой задачи, где нужна сортировка, группировка или смена формы: тогда строку приходится разбирать заново.
Не забывайте про уникальность и воспроизводимость одновременно. Ключ должен давать ту же запись при повторном вызове, а разные ключи — разные записи. Это два разных требования, и проверять их стоит отдельными случаями.
И последнее: тестовые данные не должны доезжать до рабочего окружения. Пометка среды, отдельный набор ключей и запрет на выгрузку в рабочую базу стоят дешевле, чем разбор инцидента.
Как связать компанию с человеком и адресом
Отдельная сложность — согласованность между разделами. В реальной жизни у компании есть юридический адрес, сотрудники и банковские реквизиты, и всё это связано между собой. Если тестовые страницы генерируют значения независимо, связи рвутся: сотрудник числится в организации, которой нет в списке, а адрес в счёте не совпадает с юридическим.
Решение — общий источник. Одна запись о человеке порождает и его работодателя, и адрес организации, и контактные данные. Тогда любая страница, которая обращается к этой записи, получает согласованный набор: название, отрасль и размер компании совпадают с тем, что показано в профиле сотрудника.
Проверять эту согласованность стоит отдельным тестом. Достаточно взять один ключ, получить данные с двух страниц и сравнить поля, которые обязаны совпадать. Такой тест дешёвый и ловит ошибку, которую иначе замечают только на демонстрации перед заказчиком.
Где заканчивается допустимое
Вымышленная компания годится для проверки форм, демонстраций, наполнения и обучения. Она не годится для заявок на реальные услуги, выставления настоящих счетов, регистрации по чужому имени и попыток обойти процедуру проверки контрагента. Подробнее об этой границе — в материале о том, где заканчиваются допустимые границы вымышленных данных, а о самой процедуре проверки — в чек-листе по проверке компании.
Если тестовая запись нужна для счёта, заранее посмотрите, какие поля вообще попадают в документ: об этом отдельная статья про тестирование формы счёта.
Что делать дальше
Начните с малого: возьмите одну страну, соберите для неё образец организации и прогоните через формы, которые уже есть в продукте. Если расхождения между разделами всплывут сразу — это нормальный результат, он показывает, где именно не хватает согласованности. Сгенерировать согласованный набор, в котором название, адрес и номера относятся к одной записи, можно в разделе генератора тестовых данных компании.
Эта статья описывает вымышленные реквизиты для проверки программ: они не предназначены для открытия настоящих счетов, подачи заявок или выдачи себя за существующую организацию.