Риск-ориентированное тестирование в 1С: как распределить 40 часов проверки пропорционально цене ошибки

Для тех, кому некогда: если делить 40 часов проверки поровну между восемью бизнес-процессами, на печатную форму перемещения между складами и на закрытие месяца уйдёт по 5 часов. Таблица признаков и скрипт на 81 строку дают другую раскладку: 9,7 часа закрытию месяца и 1,1 часа печатной форме. Данные в таблице учебные, я "синтезировала" их для примера. Поэтому статья рассказывает про метод и его границы, о чьей-то базе в ней речи нет.

🪧 Вместо вступления

Честно скажу сразу: проекта сопровождения, где я лично сорвала закрытие месяца, у меня нет, и "пронзительной" истории про семидневную рабочую неделю здесь не будет. Есть метод из стандартов тестирования, скрипт и прогон на условных данных. Скрипт и текст я готовила вместе с языковой моделью; запуск, числа и ссылки проверила сама 07.10.2026.

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

🧭 Что говорит стандарт

В глоссарии ISTQB риск-ориентированное тестирование определено как проверка, в которой управление, выбор, приоритезация и использование ресурсов опираются на виды и уровни рисков. Уровень риска там задаётся вероятностью и последствиями и может выражаться словами (высокий, средний, низкий) или числом. Стандарт ISO/IEC/IEEE 29119-2 описывает процессы тестирования с тем же риск-ориентированным подходом.

Оговорка о проверке: страницу глоссария ISTQB я напрямую не открыла (она отдала пустой ответ), определение сверила по стороннему пересказу. Дословных цитат в тексте нет, формулировку пересказала своими словами. Версию стандарта 2013 года его издатель пометил как заменённую редакцией 2021 года.

Дальше вся арифметика сводится к одной формуле: риск равен вероятности дефекта, умноженной на цену последствий. Обе величины я оцениваю по шкале от 1 до 3.

📋 Признаки вместо ощущения

Чтобы оценка не зависела от настроения, каждую величину я собираю из признаков со значениями 0 или 1. Вероятность оценивает разработчик по истории изменений, цену последствий - владелец процесса.

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

🧮 Как скрипт считает

Баллы из признаков скрипт переводит в шкалу 1-3, перемножает и назначает уровень проверки. Ядро из risk_plan.py:

1
2
3
4
5
6
7
8
9
10
11
12
13

def bucket_p(points):
    return 1 if points <= 1 else 2 if points <= 3 else 3


def bucket_i(points):
    return 1 if points <= 1 else 2 if points == 2 else 3


def tier(risk, law):
    t = "A" if risk >= TIER_A else "B" if risk >= TIER_B else "C"
    if law and t == "C":
        t = "B"
    return t

Произведение двух величин от 1 до 3 принимает значения 1, 2, 3, 4, 6 и 9. Границы уровней - константы TIER_A = 6 и TIER_B = 3, то есть моя политика, к стандарту она отношения не имеет. Уровень A получает полную проверку: позитивные и негативные сценарии, граничные значения, сверку с эталоном. Уровень B - основной сценарий и два-три типовых отклонения. Уровень C - выборочный осмотр изменённого.

Часы бюджета скрипт делит пропорционально риску. Правило пола в функции tier я добавила после первого прогона, о нём ниже.

🚦 Что вышло на учебных данных

Запуск 07.10.2026, Windows 11, Python 3.12.10, python risk_plan.py risks-example.csv --hours 40:

Процесс                                    P  I  Риск  Ур.   Часы  Поровну
Закрытие месяца                            3  3     9    A    9.7      5.0
Обмен с банком                             2  3     6    A    6.5      5.0
Расчёт зарплаты                            2  3     6    A    6.5      5.0
Реализация товаров                         3  2     6    A    6.5      5.0
Розничные продажи (смена кассы)            2  3     6    A    6.5      5.0
Регламентированная отчётность              2  1     2    B    2.2      5.0
Групповая обработка справочника            1  1     1    C    1.1      5.0
Печатная форма внутреннего перемещения     1  1     1    C    1.1      5.0

Процессов: 8; бюджет 40 ч; сумма рисков 37
Совпадений значения риска между процессами (шкала грубая): 4

Смотреть стоит на отношения. Пять процессов уровня A получают вместе 35,7 часа против 25 часов при дележе поровну. Остальные три процесса получают около 4,3 часа вместо 15. Освободившиеся десять с небольшим часов уходят туда, где ошибка дороже.

Теперь о том, что мне в этой таблице не нравится. Пять процессов из восьми получили одинаковый риск 6. Шкала из трёх делений слишком грубая, чтобы внутри уровня A выбрать, что проверять первым. Скрипт печатает счётчик совпадений (здесь 4: восемь процессов и четыре разных значения риска), чтобы вы видели, когда таблица перестаёт различать процессы. Порядок внутри уровня тогда решается разговором с владельцами, второй знак после запятой тут не поможет.

🔁 Что будет, если поменять входные данные

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

Снятие признака changed у закрытия месяца. Представим, что релиз расчёт себестоимости не трогал. Вероятность падает с 3 до 2, риск - с 9 до 6, часы - с 9,7 до 7,1. Процесс остаётся в уровне A и теперь делит первое место с четырьмя другими. Вывод: «не менялось» снижает приоритет, но не обнуляет его.

Расчёт зарплаты без признаков вероятности. Если у процесса нет изменений, сложной логики, дефектов, интеграций и обновлений, вероятность становится 1, риск падает с 6 до 3, уровень - с A до B, часы - с 6,5 до 3,5. Здесь и видна слабость формулы: цена ошибки в зарплате осталась прежней, проверка при этом сократилась почти вдвое. Если ваша политика такого не допускает, добавьте минимальный уровень для процессов с высокой ценой последствий.

Отчётность и правило пола. У регламентированной отчётности в учебной таблице сработал один признак цены, law. Цена получилась 1, риск 2, и без правила пола процесс попал бы в уровень C, то есть в «выборочно». Штраф за несданный отчёт одним баллом из четырёх не описывается, поэтому в tier и появилось правило: сработал law - уровень не ниже B. Правило работает как заплатка и показывает слабость суммы признаков: один признак здесь весит больше трёх остальных.

🤝 Что узнать у владельца процесса

Признаки цены я не могу заполнить из репозитория, их знает только тот, кто отвечает за процесс. Вопросы лежат в архиве в interview-checklist.md, на каждый процесс уходит минут пятнадцать. Ответ «да» ставит единицу в столбец.

Из дополнительных вопросов в чек-листе самый полезный последний: «Что вы готовы не проверять в этот релиз?» Ответ записывается как принятый риск. Через месяц это разница между «мы решили не проверять печатную форму» и «мы про неё забыли».

🛠 Как встроить в релиз

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

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

🧯 Ограничения

• Скрипт запускали только на учебных данных, на одном компьютере и одной версии Python. Linux, macOS и более ранние версии Python не проверены.
• Данные в risks-example.csv придуманы. Выводы о том, какой процесс критичнее, к вашей базе не переносятся, переносится только способ счёта.
• Веса признаков одинаковы, границы уровней заданы константами. Я не проверяла, совпадает ли такая раскладка с распределением реальных дефектов.
• Статистики по проектам 1С, где подход снизил число дефектов, у меня нет, и обещать эффект я не берусь.
• Первоисточник ISTQB не открылся, определение пересказано по стороннему сайту.

📚 Источники

• Глоссарий ISTQB: термины «risk-based testing» и «level of risk». Страница при проверке 07.10.2026 вернула пустой ответ, формулировки сверены по стороннему пересказу.
• ISO/IEC/IEEE 29119-2: процессы тестирования; страница издателя открыта 07.10.2026, редакция 2013 года помечена как заменённая версией 2021 года.
• Предшественники на Infostart, сверены по снимку ленты от 28.09.2026: ИИ-тестирование в 1С: как проверить код, который написала нейросеть (farafonov_alexey, 24.07.2026); Блеск и нищета юнит-тестирования в 1С (alexandr_yang, 29.06.2026); Моем руки перед обменом, или самые частые ошибки ручного тестирования интеграций между 1С базами (romandredan, 03.04.2026). Здесь рассматривается другой вопрос: как разделить часы между процессами по цене ошибки.

📎 Файл к статье

В архиве risk-oriented-testing-companion.zip: risk_plan.py, учебная таблица risks-example.csv, вопросы владельцу процесса interview-checklist.md, вывод запуска output-2026-10-07.txt и README. Сначала выполните пример из README, затем подставьте свои процессы. Веса признаков и границы уровней в скрипте - политика, которую стоит пересмотреть под ваш проект.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 48 технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S