Я не буду описывать здесь, что такое матрица трассировки, какие они бывают, как строить зависимости и прочую теорию. Это вы можете самостоятельно погуглить, если интересно. Я не люблю переписывать учебники.
Мы с вами разберем на примере, как аналитику проверить доработку с помощью матрицы трассировки.
Вы сняли требования, написали ТЗ, отдали разработчику. Он сделал. Теперь нужно проверить результат.
Вариант «просто потыкать в кнопки» — самая частая ошибка. Потыкали — вроде работает — отдали заказчику. А через день звонок: «А почему вот здесь не считается?» Потому что нужно проверить не только позитивный сценарий.
Начнем.
Пример: Расходная накладная со складами в табличной части
Документ: Реализация товаров (расходная накладная)
Конфигурация: 1С: Управление торговлей
Доработка: В табличную часть документа добавлена колонка «Склад», чтобы можно было отгружать товар с разных складов одним документом.
Коротенько напомню: требования бывают разные и их много, нас интересуют только функциональные требования.
Шаг 1. Выписываем функциональные требования из ТЗ
ID |
Требование |
|---|---|
FR-01 |
В табличную часть документа добавлена колонка «Склад» |
FR-02 |
Пользователь может выбрать склад из справочника «Склады» для каждой строки |
FR-03 |
При проведении товар списывается со склада, указанного в строке |
FR-04 |
Если в какой-либо строке склад не заполнен — документ не проводится |
FR-05 |
Если на складе недостаточно остатка — документ не проводится |
FR-06 |
В печатной форме ТОРГ-12 выводится склад по каждой позиции |
Шаг 2. На каждое требование пишем тест-кейсы (позитивные, негативные, граничные)
Позитивные:
ID |
Тест-кейс |
|---|---|
TC-01 |
Заполнить две строки с разными складами (остатков достаточно). Провести. Проверить движения — остатки уменьшились на нужных складах |
TC-02 |
Сформировать печатную форму ТОРГ-12 после проведения — проверить, что склады выводятся по строкам |
Негативные и граничные:
ID |
Тест-кейс |
|---|---|
TC-03 |
В одной из строк не заполнить склад. Попытаться провести — ожидаем ошибку |
TC-04 |
В одной из строк указать склад, на котором недостаточно остатка. Провести — ожидаем ошибку |
TC-05 |
В первой строке указать склад с остатком ровно под нужное количество, во второй — склад с остатком больше. Провести — должно провестись |
TC-06 |
Указать в нескольких строках один и тот же склад. Провести — остаток должен уменьшиться на общую сумму |
TC-07 |
Попытаться выбрать склад, помеченный на удаление (если в системе есть такая возможность) — проверка, что система не даёт выбрать или предупреждает |
TC-08 |
Провести документ, затем попытаться изменить проведённый документ (если редактирование запрещено настройками) — проверка блокировки |
Шаг 3. Матрица трассировки
Строки — требования, столбцы — тест-кейсы. На пересечении X, если тест проверяет это требование.
Требование |
TC-01 |
TC-02 |
TC-03 |
TC-04 |
TC-05 |
TC-06 |
TC-07 |
TC-08 |
|---|---|---|---|---|---|---|---|---|
FR-01 |
X |
X |
X |
X |
X |
|||
FR-02 |
X |
X |
X |
X |
X |
|||
FR-03 |
X |
X |
X |
X |
||||
FR-04 |
X |
|||||||
FR-05 |
X |
X |
||||||
FR-06 |
X |
Шаг 4. Что даёт такая матрица
FR-04 (проверка заполнения склада) проверяется только TC-03 — если тест пройден, требование работает.
FR-05 (недостаток остатка) проверяется TC-04 и TC-05 — если падает TC-04, значит, при нехватке остатка документ всё равно проводит.
FR-03 (списание) проверяется TC-01, TC-05, TC-06, а также TC-08 — последний проверяет, что после проведения нельзя изменить склад (иначе списание перестанет быть корректным).
FR-06 (печатная форма) — только TC-02.
TC-07 проверяет одновременно FR-01 и FR-02 (выбор склада и наличие колонки).
TC-08 связан с FR-02 и FR-03 — если тест падает, значит, проведённый документ можно редактировать, что ломает логику списания.
TC-05 проверяет граничное условие: если остаток ровно равен нужному количеству, система должна провести документ (типичная ошибка разработчика — поставить условие «больше» вместо «больше или равно»).
Если TC-04 упадёт — разработчик идёт чинить проверку остатков.
Если TC-03 упадёт — чинит обязательность заполнения.
Зачем это аналитику в 1С
В 1С-проектах отдельного тестировщика чаще всего нет. Аналитик сам проверяет доработки. Матрица даёт:
Ничего не забыть. Каждое требование привязано к тесту.
Не пропустить граничные случаи. Негативные сценарии не на коленке, а в таблице.
Понять последствия. Если падает один тест — видно, какие требования под угрозой.
Отчитаться. Заказчику можно показать: все требования проверены.
Коротко
Матрица трассировки — это ваш щит перед заказчиком. Если возникнут вопросы, у вас есть документ, в котором проверили ВСЕ функциональные требования. Вы защищаете и себя, и разработчика. Вы не будете стоять и хлопать глазами перед заказчиком, пытаясь оправдаться: «А… эээ… ну… всё работало… сейчас будем разбирать».
Я делаю её в Google Sheets на каждую доработку. Можете делать где вам удобно, например в Miro. Час работы — и сплю спокойно.
И самое важное: очень быстро вы научитесь думать на шаг вперёд.
Удачных вам внедрений!
А вы проверяете доработки системно или «на глаз»?
Комментарии (7)
USergey
27.02.2026 14:26Я думал работа системного аналитика заключается в знание программы, чтоб не переизобретать и не тестировать переизобретенные костыли, а по максимому использовать что заложено в типовое решение.
Я к тому что в УТ насколько помню, заложена реализация с нескольких складов. Если ошибаюсь прошу меня заранее извенить, выгараю без компьютера на пляжу.
AriaQA Автор
27.02.2026 14:26Хорошего отдыха! ☀️ Вы абсолютно правы: изобретать то, что уже есть в типовом функционале — это зло. Золотое правило 1С-аналитика: максимально использовать заложенное вендором.
В статье я взяла этот кейс именно как короткий и понятный каждому аналитику пример, чтобы не перегружать текст спецификой сложной кастомной логики. Моя цель — показать саму систему: как работает Матрица трассировки.
Этот инструмент универсален. Его можно и нужно применять на любой доработке: от маленькой колонки до огромной подсистемы, которой точно нет в коробке.
USergey
27.02.2026 14:26Вы правильно объясняете на доступных, базовых примерах, так делают многие учителя в уц1.
Единственное отличие что они свою упрощенную конфигурацию называют каркасной. Это заготовка с который ученик работает.
Называя это торговлей, можно в будущем наткнутся на ленивого аналитика получившего похожую задачу и списавшего в интернете требования с условиями приемки.
Это породит дальнейшие ошибки в человеческой многоножке. Мусор на входе - порождает мусор на выходе.
А так замечательная статья. Можно в колонки и строки добавить наименование, а не только номер и в ней орентироваться можно будет без сопровождающего описания. Это убережет мозги от хранения бесполезных переменных fr и tc.
AriaQA Автор
27.02.2026 14:26Насчет "каркасности" примера — это осознанный выбор. На Хабре в 80% случаев встречаются только обзоры инструментов, но почти нет конкретики: а как его применить в реальной жизни? Я взяла УТ как понятную базу, чтобы сфокусироваться на методике.
К сожалению, в среде аналитиков 1С системная проверка через Матрицу трассировки — это большая редкость. Многие привыкли проверять "на глаз", и моя статья — попытка показать, что можно (и нужно) работать по-другому.
Про "человеческую многоножку" — риск есть, но я надеюсь, что статья научит коллег именно думать, а не просто копировать ID. Насчет названий требований прямо в матрице — отличный совет, в крупных проектах это действительно спасает мозги от лишних переменных. Спасибо за конструктив!»
kompilainenn2
Заяем аналитику делать работу тестировщика? Или в мире 1С так принято просто?
AriaQA Автор
Хороший вопрос! В мире классической разработки это действительно выглядит странно, но в 1С своя специфика.
Если мы говорим про внутренний инхаус крупных компаний, там стек обычно полный: есть архитекторы, консультанты и аналитики. Но даже там ручной QA — это исчезающий вид. Чаще всего всё закрывают автотестами (Vanessa Automation), а функциональную приемку "на соответствие бизнесу" всё равно делает аналитик.
А вот в компаниях, которые занимаются внешним внедрением, ситуация жестче. Там команда часто состоит из троих: Менеджер (его задача — продать проект), Разработчик и Аналитик. И вот тут Аналитик реально превращается в "человека-оркестра": он снимает требования, пишет ТЗ, сам же его тестирует и сам сдает заказчику.
Матрица трассировки в таких условиях — это не попытка отобрать хлеб у тестировщика, а единственный способ для аналитика выжить, не пропустить баги и не "хлопать глазами" на сдаче. Это просто инструмент контроля качества там, где больше некому этот контроль обеспечить.
gennayo
Да, в мире 1С очень часто нет выделенной роли тестировщика, поэтому кроме аналитика типа некому :) В идеальном мире сейчас грамотные аналитики 1С пишут сценарии функционального тестирования с использованием специализированного ПО, которые затем прогоняются в автоматическом режиме.