Что подписывает заказчик, когда принимает ERP-систему

ERP-систему обычно принимают подписью под списком функций. Каждую функцию показали, и каждая сработала. Через несколько месяцев те же операции выполняются заметно дольше, а в подписанном документе ничего не сказано о том, как быстро они должны выполняться.

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

Что подписывает заказчик

Важны два документа.

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

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

Что стоит автоматизировать

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

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

Редкие проверки остаются ручными. Автоматические тесты нужно поддерживать, и это может стоить дороже ручного тестирования, поэтому автоматизируют не все.

Почему принятая система замедляется

Неэффективный код трудно заметить на небольшой выборке данных, в 1С:ERP так же, как в любой ERP-системе. Несколько месяцев опытной эксплуатации его тоже не покажут: данных за это время накапливается слишком мало. Проблема проявляется позже, когда проект уже закрыт. Чтобы этого избежать, тестируют две вещи.

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

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

Скорость как число

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

APDEX, открытый индекс времени отклика, сводит замеры к одному числу. Результат меньше целевого времени считается за единицу, меньше четырех целевых - за половину, все, что дольше, - за ноль, а индекс равен среднему. По общепринятой шкале значение от 0,85 считается хорошим, а от 0,94 - отличным.

Шесть вопросов до подписи

• Есть ли план тестирования с входными данными и ожидаемыми результатами, утвержденный как часть спецификации?
• Кто со стороны заказчика подтверждает каждую строку чек-листа?
• Какие тесты повторяются перед каждым выпуском и какие из них автоматизированы?
• Есть ли список ключевых операций с целевым временем для каждой?
• Сколько данных было в тестовой базе и сколько пользователей одновременно работало в нагрузочном тесте?
• Виден ли заказчику реестр дефектов и разделено ли в нем то, что нашла команда подрядчика, и то, о чем сообщили пользователи?

Открытый вопрос дешевле закрыть до подписи, чем после нее.