Приемочные испытания ИТ-систем: сценарии и протоколы сдачи

Зачем нужны приемочные испытания и что они закрывают

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

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

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

Для заказчика «система введена» обычно означает четыре вещи: она работает по ключевым сценариям, производительность в норме, безопасность и доступы настроены, а сопровождение реально возможно (инструкции, схемы, регламенты, контакты поддержки).

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

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

Когда эти правила зафиксированы заранее, приемка становится быстрым измерением, а не торгом на финише проекта.

Что подготовить до начала испытаний

Перед приемкой соберите «папку проекта», чтобы тесты шли по фактам, а не по памяти участников. Это экономит дни на уточнениях и снимает споры из серии «мы так не договаривались».

В первую очередь нужны документы, которые фиксируют ожидаемый результат и устройство системы: ТЗ и спецификация, краткое описание архитектуры, схемы сети и интеграций, инструкции для админов и пользователей, перечень настроек (например, политики доступа, резервное копирование, параметры мониторинга). Если часть договоренностей осталась в письмах или чатах, оформите их приложением.

Ключевой инструмент - матрица требований. Она связывает «что обещали» и «что проверяем» и становится основой программы приемочных испытаний. В матрице на каждое требование должны быть: проверка (сценарий/тест), критерий (число или условие), фактический результат с датой и исполнителем, статус (пройдено/не пройдено/с оговорками).

Дальше определите границы приемки. Зафиксируйте, что входит (например, офисная сеть, серверы, резервное копирование, ключевые пользовательские сценарии) и что не входит (пилотные функции, обучение «на будущее», модернизация рабочих мест вне проекта). Это должно совпадать с тем, как будет заполняться протокол приемки ИТ-проекта.

Стенд и доступы подготовьте заранее: учетные записи для комиссии, права администратора, доступ к журналам и мониторингу, тестовые данные и тестовые пользователи, шаблоны заявок в сервис-деск (если он есть). Простой пример: если проверяется восстановление из бэкапа, заранее согласуйте «контрольные файлы» или базу, по которым сразу видно, что восстановление прошло корректно.

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

Критерии приемки: как сделать их измеримыми

Хороший критерий приемки отвечает на три вопроса: что проверяем, как проверяем и какое значение считаем успехом. Формулировка должна быть измеримой, с допуском и понятным методом проверки. Плохо: «сеть работает стабильно». Хорошо: «потери пакетов между узлами A и B не более 0,5% при нагрузке X, измерение по ping/iperf в течение 30 минут, 3 прогона».

Пороговые значения задавайте заранее и привязывайте к реальным сценариям. Для сети обычно фиксируют задержку и потери, для серверов - время восстановления и доступность, для приложений - время отклика и долю ошибок. Для инфраструктуры полезно сразу договориться про RTO/RPO: например, RTO 60 минут (сколько времени можно восстанавливаться) и RPO 15 минут (сколько данных допустимо потерять).

Пропишите два режима: нормальный и отказ. В нормальном режиме критерии про производительность и стабильность. В режиме отказа - что считается успешным переключением и какие деградации допустимы. Пример: «при отказе одного коммутатора связь между критичными сегментами восстанавливается за 30 секунд, потеря одного TCP-сеанса допускается не более чем у 1% активных пользователей».

Отклонения фиксируйте по правилам: кто регистрирует, где хранится, какой срок реакции и исправления. Удобно заранее описать уровни критичности (критично/средне/низко) и привязать к ним сроки. Тогда спор идет не о «важно или нет», а о том, в какую категорию попадает проблема.

Условная приемка допустима, когда система безопасна и пригодна к работе, а недочеты не блокируют ключевые процессы. В протоколе нужен список доработок с конкретикой: описание, критерий готовности, владелец, срок, и что будет считаться доказательством исправления (повторный тест, лог, скриншот, отчет).

Шаблон протокола приемочных испытаний (структура)

Протокол нужен, чтобы результаты были проверяемыми: что тестировали, чем измеряли, что получилось, что считать «сдано», а что - нет. Один и тот же документ должен быть понятен заказчику, подрядчику и службе эксплуатации.

Практичная структура:

• Паспорт документа: объект (система/контур), версия, площадка, даты, участники, основание (договор, ТЗ, заявка на изменения).
• Реестр сценариев: список тестов с пошаговыми действиями, входными данными, ожидаемым результатом и фактом.
• Метрики и способы измерения: какие показатели проверяем и какими инструментами фиксируем значения.
• Журнал несоответствий: что не прошло, насколько критично, кто исправляет и до какого срока.
• Итог: выводы, допущения и ограничения, перечень приложений, подписи сторон.

Реестр сценариев: как оформить, чтобы не спорить

Частая причина конфликтов - «мы проверили, и вроде работает». Поэтому в сценарии пишите не общие слова, а наблюдаемый результат. Например, не «VPN поднимается», а «туннель установлен, пинг до адреса X проходит, потерь нет, средняя задержка не выше Y мс в течение 10 минут».

Сценарии удобно вести таблицей прямо в протоколе. Минимальные колонки:

Метрики и инструменты простыми словами

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

Для несоответствий заведите короткую карточку, чтобы закрывать их по одному:

• Где проявляется (сценарий, шаг, окружение) и что именно происходит.
• Влияние на работу (что не сможет сделать пользователь или служба).
• Приоритет и критерий закрытия.
• Владелец и срок исправления.
• Повторная проверка (дата, результат, приложенные доказательства).

В финале добавьте общий статус (принято/принято с ограничениями/не принято), список ограничений (например, «в филиале N канал связи будет расширен до даты ...») и подписи. Это особенно полезно, когда оборудование, интеграцию и поддержку делают разные команды.

Пошаговый план приемки: как провести тесты без хаоса

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

Начните со «снимка системы»: версии ПО и прошивок, конфигурации, схемы сети, перечень узлов, учетные записи для тестов и границы ответственности (кто меняет настройки, кто подтверждает результат). В протоколе укажите дату, место, состав стенда и что считается эталоном.

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

Удобный маршрут:

• Зафиксировать исходное состояние (версии, конфиги, схемы, компоненты).
• Выполнить короткий «smoke»-прогон базовых функций.
• Пройти согласованные сценарии по подсистемам с метриками.
• Проверить отказоустойчивость и восстановление (если это было в проекте).
• Оформить результаты, согласовать замечания и повторить тесты после исправлений.

Тесты отказоустойчивости заранее согласуйте: что именно «ломаем», сколько времени можно держать сервис в деградации, кто дает разрешение на переключения. Примеры: отключение одного коммутатора в паре, имитация отказа диска, перезапуск службы приложения. Фиксируйте факты (время восстановления, потери пакетов, число ошибок, время отклика), а не ощущения.

Финишный этап - дисциплина протокола. Для каждого теста запишите шаги, фактический результат, доказательство (лог, скрин, замер), статус и ответственного за исправление. Повторный прогон выполняйте по тем же шагам и на том же «снимке системы». Если поставщик еще и интегратор (как GSE.kz в проектах под ключ), заранее назначьте единое окно для правок и повторных проверок, чтобы не расползались версии и настройки.

Шаблоны тестов для сети: сценарии и метрики

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

Мини-набор сценариев (что тестировать)

Начните с маршрутов и доступности: пройдите по ключевым сегментам из сетевой схемы (пользовательский, серверный, Wi-Fi, DMZ, управление) и проверьте, что трафик идет так, как задумано.

Дальше держите короткий, но показательный набор:

• Доступность сегментов: ping и traceroute между контрольными точками (ПК, сервер, шлюз, контроллер Wi-Fi) с фиксацией результатов.
• Базовые сервисы: DHCP (выдача адреса и опций), DNS (разрешение внутренних имен), NTP (синхронизация времени), плюс проверка резервного сервера или второго источника.
• Производительность: задержка, потери, пропускная способность на типовых направлениях (пользователь - сервер, филиал - ЦОД, Wi-Fi - LAN).
• Резервирование: отказ линка или маршрута, переключение на резерв и измерение времени восстановления.
• Базовая безопасность: сегментация и ACL (что разрешено и что запрещено), гостевой доступ (если предусмотрен) без доступа к внутренним ресурсам.

Чтобы метрики были сравнимыми, заранее договоритесь о методе измерения и окне времени. Например, для задержки и потерь используйте серию из 100-300 ICMP-пакетов в рабочее время; для пропускной способности - тест между двумя согласованными точками, по одному и нескольким параллельным потокам.

Примеры критериев, которые удобно включать в протокол: задержка между офисом и серверным сегментом не более X мс, потери не более Y%, пропускная способность не ниже Z Мбит/с, время переключения при отказе линка не более T секунд.

Фиксация результатов (что приложить к протоколу)

Нужно не только «прошло», но и доказательства, чтобы потом не спорить:

• Выгрузки конфигураций с ключевых устройств (маршрутизатор, коммутатор ядра, фаервол) на момент теста.
• Логи DHCP/DNS/NTP и скриншоты статусов (пулы, зоны, синхронизация времени).
• Отчеты утилит измерения (ping/traceroute, замеры пропускной способности) с датой, временем, точками A/B.
• Подтверждение резервирования: событие падения, событие восстановления, рассчитанное время простоя.
• Снимки правил сегментации/ACL и результаты контрольных попыток доступа (разрешенные и запрещенные).

Такая структура хорошо работает и для объектов с филиалами: вы повторяете один и тот же набор сценариев по каждой площадке и получаете сопоставимую картину качества сети.

Шаблоны тестов для серверов и хранения данных

Чтобы приемка не превращалась в спор, фиксируйте для каждого теста: входные условия (конфигурация и нагрузка), шаги, ожидаемый результат, фактический результат, артефакт (скрин, лог, отчет), критерий прохождения. Эти шаблоны подходят и для «железа» в стойке, и для виртуальной среды.

1) Базовая готовность и здоровье оборудования

Начните с проверки того, что поставлено именно то, что в спецификации. В протоколе отдельно отметьте модель, серийные номера, состав дисков, объем RAM, версии прошивок и контроллеров. Для серверов, которые ставят в гос или крупные организации (в том числе локально произведенные стойковые серверы), этот шаг часто самый важный.

Короткий набор тестов, который удобно повторять на каждом узле:

• Инвентаризация и соответствие спецификации: серийные номера, конфигурация, лицензии, гарантийные отметки.
• Состояние RAID и дисков: уровень RAID, состояние, прогноз отказа, корректность замены диска.
• Память, температура, питание: нет перегрева, вентиляторы и блоки питания видны, нет критических событий.
• Журналы событий: нет повторяющихся ошибок (диск, контроллер, сеть, питание) за последние N часов.
• Базовый сетевой доступ: управление, доступ к хранилищу (если есть), корректные скорости линков.

2) Производительность, виртуализация, бэкап и отказоустойчивость

Производительность оценивайте «в пределах разумного»: важнее соответствие ожиданиям проекта без троттлинга и перегрева, чем рекорды. В критериях заранее зафиксируйте длительность прогона, профиль (чтение/запись), целевые IOPS или пропускную способность и допустимые пики температуры.

Для виртуализации добавьте проверки, которые показывают готовность к работе:

• CPU/RAM/диск: тест под нагрузкой 15-30 минут с фиксацией метрик и отсутствием ошибок контроллера.
• Виртуализация: создать тестовую ВМ, установить ОС, сделать снапшот и откат; если есть кластер - выполнить миграцию.
• Резервное копирование: сделать бэкап тестовой ВМ и восстановить (1) один файл, (2) всю ВМ в изолированную сеть.
• Отказ диска: имитировать сбой (вывод диска), проверить деградацию RAID, время начала реконструкции и отсутствие потери данных.
• Отказ блока питания или сети: отключить один БП или один линк, зафиксировать доступность сервисов и корректную запись событий.

Так результаты становятся однозначными: «пройдено/не пройдено» видно по метрикам, логам и контрольным действиям восстановления.

Шаблоны тестов для прикладных систем

Чтобы приемка не превращалась в спор «работает или нет», фиксируйте для каждого теста предусловия (данные, права, окружение), шаги, ожидаемый результат, метрику (секунды, количество, статус) и правило приемки.

1) Функциональные сценарии (пользователь и администратор)

Выберите 5-10 самых частых операций, которые реально будут делать каждый день: вход, поиск, создание сущности, изменение, согласование, выгрузка. Для администратора добавьте управление пользователями и ролями, настройку справочников, резервное копирование настроек.

Пример кейса: «Создать заявку -> отправить на согласование -> получить статус “Одобрено” -> запись появилась в журнале -> уведомление отправлено». Критерий приемки: статус меняется корректно, данные не теряются, время выполнения операции не превышает X секунд.

2) Права доступа, интеграции и устойчивость

Права лучше проверять на реальных ролях (оператор, руководитель, аудитор, админ), а не на «тестовом суперпользователе». Проверьте, что роли видят и делают ровно то, что должны, а запрещенные действия дают понятную ошибку, а не «молчаливый отказ». Обязательно убедитесь, что аудит работает: в журнале фиксируются кто, что и когда изменил, и старое/новое значение.

Интеграции принимайте как отдельные тесты: «входящее сообщение -> обработка -> запись в системе -> ответ/квитанция». Сразу задайте измеримые критерии: процент успешных сообщений, допустимая задержка, поведение при дубликатах и при недоступности смежной системы.

Для устойчивости добавьте сценарии перезапуска сервиса, временной потери связи с БД и восстановления очереди. Отчеты проверяйте по контрольным цифрам (3-5 значений) и времени формирования при типичном объеме данных.

Нагрузочные прогоны делайте на типовых операциях (поиск, сохранение, отчет). Фиксируйте медиану, 95-й процентиль времени отклика и поведение на пике (ошибка, очередь, деградация).

Пример сценария: приемка системы в организации с филиалами

Исходные данные: сеть из 3 филиалов (например, поликлиника или школа) и головной площадки. Всего 100-300 пользователей, часть работает посменно. Есть общие принтеры, Wi-Fi для сотрудников, серверы и хранилище в серверной, плюс прикладная система (учет пациентов или электронный журнал). На день приемки заранее готовят тестовые учетные записи: регистратор, врач/учитель, бухгалтерия, администратор.

Одним пакетом принимают: Wi-Fi (покрытие и доступ), серверы и резервное копирование, доменные учетные записи и права, работу приложения, печать (в том числе из филиалов), доступность сервиса с основных рабочих мест.

Сценарии на день приемки

Лучше прогонять не разрозненные тесты, а реальные цепочки работы:

• Утро: сотрудник в филиале включает ПК, подключается к Wi-Fi, входит в учетную запись, открывает приложение.
• Работа: создает документ/карточку, вносит изменения, сохраняет, формирует отчет.
• Печать: отправляет на общий принтер, проверяет время выхода и корректность шаблона.
• Сбой: имитируют отключение интернета в одном филиале (если по проекту есть офлайн-режим или резервный канал) и фиксируют поведение.
• Вечер: запускается резервное копирование, затем выполняется контрольное восстановление одного объекта (файла или записи) на тестовую площадку.

Типовые измеримые критерии

Критерии лучше записывать числами и условиями замера, а не словами «быстро» и «стабильно»:

• Время входа пользователя: не более 60 секунд от ввода пароля до готовности рабочего стола.
• Открытие карточки/документа в приложении: не более 3 секунд в 95% попыток.
• Доступность сервиса в рабочее время: 99,5% за период наблюдения (или по окну приемки).
• Печать типового документа: не более 30 секунд до выхода листа.

Если возникает спорный момент, не решайте его «на ощущениях». Согласуйте единый способ измерения (какой таймер, от какого действия до какого), повторите тест 3-5 раз, зафиксируйте условия (филиал, рабочее место, время, нагрузка) и приложите скриншоты/логи. Если критерий не выполнен, оформляйте это как несоответствие с дедлайном и правилом повторной проверки. Так приемка остается измеримой и без споров, независимо от того, кто интегратор и на чьем оборудовании собрана система (в Казахстане такие проекты нередко ведет GSE.kz).

Частые ошибки, из-за которых приемка затягивается

Первая причина затяжной приемки - туманные договоренности. Когда в критериях написано «работает нормально» или «быстро открывается», каждая сторона понимает это по-своему. Заранее фиксируйте числа: время отклика, допустимый простой, процент потерь пакетов, RPO/RTO, количество одновременных пользователей, срок устранения дефектов.

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

Часто приемку смешивают с донастройкой. Тесты превращаются во внедрение: что-то не прошло - тут же «подкрутили», снова прогнали, потом еще раз. Это растягивает сроки и ломает логику: приемка подтверждает готовность, а не заменяет доведение до требований. Правильнее так: дефекты фиксируются, затем выполняется исправление, после чего проводится повторный прогон конкретного сценария.

Отдельный стоп-фактор - отсутствие плана отката и резервных копий перед испытаниями. Любой нагрузочный тест, изменение политики или проверка отказоустойчивости могут привести к сбою. Если заранее не определено, как быстро вернуться к стабильной версии и кто это делает, команда начинает «беречь» систему и сокращает проверки, а потом спорит о качестве.

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

• восстановление из резервной копии и время возврата сервиса
• перезапуск ключевых сервисов и поведение при падении компонента
• деградацию при потере канала/узла и корректность переключения
• целостность данных после сбоя

Если проект включает серверы и интеграцию, заранее согласуйте зоны ответственности: «железо», ОС, приложения, и кто подписывает итоговый протокол. Это особенно важно в поставках под гос и крупные организации, где требования к повторяемости и документам высокие.

Короткий чеклист и следующие шаги после подписания

Приемка заканчивается не на последнем тесте, а на четкой фиксации результатов и понятном плане, что будет дальше.

За 1-2 дня до старта пройдите короткий чеклист готовности:

• Утверждены программа и методика испытаний, критерии приемки, состав стенда и границы ответственности.
• Готовы доступы: учетные записи, роли, доступ к мониторингу, доступ к журналам и резервному хранилищу логов.
• Согласованы окна работ и коммуникации: кто на связи, куда эскалировать, как фиксировать инциденты.
• Назначены ответственные со стороны заказчика, подрядчика, ИБ и эксплуатации (с контактами).
• Подготовлены исходные данные: тестовые учетные записи, тестовые наборы данных, эталонные конфигурации.

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

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

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

Если в систему вносятся изменения (патчи, замена оборудования, новые интеграции), ведите версионирование протоколов: номер версии, дата, причина правки, что именно изменилось, кто согласовал. Так проще доказать, что тестировали актуальную конфигурацию.

Когда требуется продолжение работ после приемки (расширение, поддержка, обновление парка ПК/серверов), заранее назначьте владельца эксплуатационного плана. В таких случаях системная интеграция, поставка и поддержка оборудования (например, серверов и рабочих станций, как у GSE.kz) логично становятся частью следующего этапа - с теми же измеримыми критериями, что и на приемке.