Тестирование формы счёта: поля, ветки и матрица случаев

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

Что попадает в форму счёта

Набор полей зависит от страны и от того, кто выставляет счёт, но базовый перечень устойчив.

Название организации и её правовая форма. Регистрационный номер. Номер VAT или налоговый номер — в зависимости от системы страны. Юридический адрес. Банковские реквизиты. Контактные данные для вопросов по документу. Дата, номер счёта и срок оплаты.

Отдельно стоит позиция плательщика: наименование, адрес и его собственные реквизиты. Именно от них зависит, какие поля обязательны, а какие можно не показывать вовсе.

И ещё одна группа — сведения о самой сделке: состав позиций, ставки, итог. Она не относится к реквизитам, но тестируется вместе с ними, потому что расчёт и реквизиты попадают в один и тот же документ.

Отдельная тонкость — адрес. В счёте он выполняет две разные роли: юридический адрес организации и адрес для корреспонденции могут не совпадать, и требование «одного адреса» ломает корректный случай. Полезно решить заранее, какой из них обязателен, а какой показывается только при наличии.

Почему обязательные поля зависят от страны?

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

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

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

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

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

Четыре ветки, которые чаще всего не проверяют

Основные поля проверяют почти всегда. А вот сочетания, на которых форма ломается, обычно остаются без внимания.

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

Как построить матрицу случаев

Начните с осей. Первая ось — тип плательщика: организация или частное лицо. Вторая — наличие налогового номера. Третья — страна и её требования. Четвёртая — направление сделки: внутренняя или трансграничная.

Не пытайтесь покрыть все пересечения сразу. Разумный порядок такой: сначала зафиксируйте одну страну и пройдите по ней все сочетания типов и наличия номера. Затем смените страну и повторите, обращая внимание на то, что изменилось в наборе полей.

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

И зафиксируйте ожидаемый результат до запуска. Если тест не знает, что должен увидеть, он подтвердит любое поведение — и пропустит именно ту ошибку, ради которой написан.

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

Что ломается при повторной отправке

Повторная отправка — отдельный класс дефектов, который проявляется только на живом потоке.

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

Номер счёта при этом должен оставаться уникальным. Если система не различает повторную отправку и новое выставление, она либо создаст дубль, либо, наоборот, откажет в законном новом счёте.

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

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

Какие данные брать для проверки?

Вымышленные и явно помеченные. Название вида «Пример Торговая Компания», адрес из примерного диапазона и контакт на зарезервированном домене сразу читаются как образец.

Требования к набору простые. Данные должны быть согласованными: адрес, страна и налоговый номер относятся к одной стране. Они должны быть воспроизводимыми: один и тот же вход даёт один и тот же результат, иначе тест нестабилен. И они должны быть отделены от рабочих: попадание тестового счёта в настоящую отчётность — это уже инцидент.

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

Для разработчиков: порядок проверки и следы

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

Сообщение об ошибке должно указывать на конкретное поле и на причину. Общее «проверьте данные» заставляет пользователя перебирать всё заново, а поддержку — угадывать.

Обеспечьте идемпотентность создания документа. Повторная отправка одного и того же запроса не должна порождать второй счёт; для этого нужен признак, по которому система узнаёт повтор.

Храните след: кто, когда и с какими реквизитами создал документ, какие проверки прошли, а какие нет. Для счетов это не роскошь, а необходимость — расхождения разбирают спустя месяцы.

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

Что делать дальше

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

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

Материал предназначен для тестирования программных форм; приведённые примеры вымышлены и не описывают порядок выставления реальных счетов.