Прежде чем делать отчёт, доработку или запускать проект, я всегда задаю себе один вопрос:
Как мы будем проверять результат, чтобы убедиться, что он верный?
Не «как сделать».
А именно — как проверить.
Потому что без критерия проверки любая работа остаётся зоной веры.
А в автоматизации, расчётах и отчётности вера — слабый инструмент.
Переход со старой базы на новую: всё относительно просто
Когда мы переносим данные со старой базы в новую, логика проверки понятна.
Есть базовый принцип:
Итог до перехода = итог после перехода.
Сверяем:
- обороты,
- остатки,
- расчётные показатели,
- ключевые регистры,
- НДФЛ и взносы,
- количество сотрудников,
- суммы начислений.
Если итог совпадает — переход технически корректен.
Если нет — ищем расхождение до уровня конкретной записи.
Это понятная математика.
А если алгоритм новый?
Вот здесь начинается интересное.
Когда мы:
- внедряем новый механизм расчёта,
- пишем нестандартную доработку,
- автоматизируем то, что раньше делалось вручную,
- меняем логику распределения,
у нас нет «старого итога», с которым можно сравнить.
Нельзя просто сказать: «должно совпасть».
Значит, нужно создать эталон.
Пишем сценарии тестирования
В таких случаях я всегда настаиваю на сценариях тестирования.
Что это значит на практике?
1️⃣ Описываем типовые кейсы
2️⃣ Описываем пограничные ситуации
3️⃣ Описываем исключения
4️⃣ Фиксируем ожидаемый результат
Например:
- сотрудник с отпуском в середине месяца;
- сотрудник с больничным;
- сотрудник с премией;
- сотрудник с удержаниями;
- приём и увольнение внутри периода;
- разные налоговые статусы.
Каждый сценарий — это мини-модель реальности.
И по каждому должна быть чёткая формула:
что ожидаем увидеть в итоге.
Почему это критично
Потому что без сценариев тестирования:
- результат оценивается «на глаз»;
- ошибки обнаруживаются постфактум;
- возникает фраза «ну вроде считается правильно».
В зарплатной области «вроде» — опасное слово.
Алгоритмы любят крайние случаи.
Ошибки чаще всего прячутся именно там.
Ещё один уровень проверки — логика
Помимо цифр, я всегда проверяю логику:
- объяснима ли итоговая сумма;
- можно ли её разложить по шагам;
- повторяем ли результат при тех же условиях;
- нет ли зависимости от «ручных» действий пользователя.
Если результат нельзя воспроизвести — он нестабилен.
Управленческий принцип
В проектах есть простой принцип:
Нельзя управлять тем, что нельзя измерить.
Я бы добавила:
Нельзя считать корректным то, что нельзя проверить.
Поэтому проверка результата должна проектироваться одновременно с решением, а не после.
Вопрос к вам
А вы как проверяете свои результаты?
- Сравниваете с предыдущими периодами?
- Делаете контрольные расчёты вручную?
- Пишете тест-кейсы?
- Или ориентируетесь на «если жалоб нет — значит всё хорошо»?
Очень интересно, какие у вас инструменты контроля.