Техники тест-дизайна и предметная область: что еще должен знать тестировщик

Представьте: вы работаете тестировщиком в продукте для бухгалтерии. Недавно в форме появилась новая ставка НДС. Вы убедились, что она есть в списке, выбирается, сохраняется и не ломает верстку. Формально проверки пройдены, задача закрыта. А потом выясняется, что сумма из этого документа неверно попала в отчет.

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

Меня зовут Юлия Семкина, я специалист по тестированию в команде учета Контура. До перехода в тестирование я работала в технической поддержке и помогала пользователям разбираться в логике бухгалтерского сервиса. В этой статье расскажу, почему в сложном продукте одних техник недостаточно и как знание предметной области помогает строить проверки.

Почему тест-дизайн отвечает на вопрос «как проверять», но не на вопрос «что»

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

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

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

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

• Что будет с авансом, полученным до изменения ставки?
• Какая ставка останется в корректировке старой отгрузки?
• Как операция отразится в книге покупок или продаж, в декларации и печатной форме?
• Что произойдет при возврате?

С этих вопросов проверка отдельного поля превращается в проверку бизнес-логики. Техники остаются теми же — меняется содержимое, которое вы в них закладываете.

Где брать знание продукта: мой путь через поддержку

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

По-настоящему глубоко погрузиться в предметную область помогла техническая поддержка. Пользователь редко спрашивает: «Где у вас эта кнопка?» Гораздо чаще звучит другое: «Почему сервис посчитал именно так?» или «Почему сумма попала в этот отчет?»

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

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

Читайте также: Hard и soft skills: какие навыки востребованы в 2026 году

Одно изменение в законодательстве — десятки связанных проверок

Бухгалтерские сервисы меняются вместе с законодательством, и масштаб правки почти никогда не совпадает с тем, как она выглядит для пользователя. Показательный пример — переход на основную ставку НДС 22% с 1 января 2026 года. В интерфейсе это новое значение в документе. Для команды разработки и тестирования — цепочка функций:

• Создание и редактирование счетов, актов, накладных и других документов.
• Расчет суммы налога и итоговой стоимости.
• Операции на границе налоговых периодов.
• Интеграции с другими сервисами по приему документов.
• Авансы, возвраты, исправления и корректировки.
• Печатные формы, книги покупок и продаж.
• Налоговые декларации и другие отчеты, которые получают данные из документов.

Если проверять каждую форму изолированно, легко убедиться, что ставка отображается верно, и пропустить ошибку в следующем звене. Документ сохранится с правильным значением, а в отчет попадет не туда. Поэтому я стараюсь всегда идти дальше первого результата и смотреть, где данные будут использованы после сохранения.

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

Новый документ в продукте: проверить форму недостаточно

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

Я начинаю с вопроса: что именно этот документ меняет относительно исходной операции? Затем раскладываю сценарий на части. Нужно проверить проводки и сторнирующие записи, отражение операции в доходах и расходах при упрощенной системе налогообложения (УСН), возвраты, связанные отчеты и поведение исходного документа. Отдельный вопрос — что произойдет, если пользователь изменит или удалит уже проведенную корректировку.

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

Как разобраться в незнакомой предметной области: мой алгоритм

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

1. Читаю справочную для пользователей. Она объясняет сценарий простым языком и показывает результат глазами клиента.
2. Смотрю материалы для консультантов во внутреннем сервисе Контура. Там обычно есть подробные разборы редких ситуаций.
3. Изучаю аналитику задачи. Что меняется, для кого, какие ограничения и связанные процессы уже учтены.
4. Сверяюсь с законодательством. Этот шаг обязателен, если изменение касается налогов или отчетности.
5. Воспроизвожу ситуацию в тестовой учетной записи и считаю ожидаемый результат самостоятельно.
6. Иду к коллегам, если логика не складывается. Вопрос экономит время: лучше уточнить один раз, чем построить десяток проверок на неверном предположении.

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

Предметная область не заменяет техники тест-дизайна

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

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

С чего начать погружение в сложный продукт

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

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

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