Я не буду описывать здесь, что такое матрица трассировки, какие они бывают, как строить зависимости и прочую теорию. Это вы можете самостоятельно погуглить, если интересно. Я не люблю переписывать учебники.
Мы с вами разберем на примере, как аналитику проверить доработку с помощью матрицы трассировки.
Вы сняли требования, написали ТЗ, отдали разработчику. Он сделал. Теперь нужно проверить результат.
Вариант «просто потыкать в кнопки» это самая частая ошибка. Потыкали, вроде работает, отдали заказчику. А через день звонок: «А почему вот здесь не считается?» Потому что нужно проверить не только позитивный сценарий.
Начнем.
Пример: Расходная накладная со складами в табличной части
Документ: Реализация товаров (расходная накладная)
Конфигурация: 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. Час работы, и сплю спокойно.
И самое важное: очень быстро вы научитесь думать на шаг вперёд.
Удачных вам внедрений!
А вы проверяете доработки системно или «на глаз»?
