Что такое приёмо-сдаточные испытания?
Приёмо-сдаточные испытания (ПСИ) — это финальная проверка продукта перед запуском в промышленную эксплуатацию. Это как выпускной экзамен для команды разработки, где они демонстрируют заказчику, что продукт полностью соответствует требованиям.
Ключевые особенности ПСИ:
- Проводятся на этапе опытной эксплуатации
- Участвуют команда разработки и заказчик
- Результат — решение о запуске системы
Как организовать ПСИ: пошаговая инструкция
1. Подготовка документов
Основной документ — Программа и методика испытаний (ПМИ). Это чек-лист проверок, который включает:
✔ Проверку функциональности при разных нагрузках
✔ Тестирование интерфейса и пользовательских сценариев
✔ Проверку восстановления после сбоев
✔ Оценку документации (инструкций, руководств)
Пример структуры ПМИ:
1. Проверка авторизации:
- Стандартная нагрузка (100 пользователей)
- Пиковая нагрузка (500 пользователей)
- Восстановление после сбоя БД
2. Формирование команды
Оптимальный состав участников:
- Бизнес-аналитик (ведущий испытаний)
- Разработчик (объясняет технические решения)
- Тестировщик (помогает с сценариями)
- Дизайнер (проверяет интерфейс)
- Руководитель проекта (координирует процесс)
3. Проведение испытаний
Испытания проводятся в два этапа:
Этап 1 — Проверка отдельных функций:
- Демонстрация каждой ключевой функции
- Проверка соответствия требованиям
- Пример: "Показываем работу формы оплаты"
Этап 2 — Проверка системы в целом:
- Комплексные сценарии использования
- Проверка под нагрузкой
- Пример: "Одновременная работа 1000 пользователей"
4. Фиксация результатов
Все находки фиксируются в протоколе с указанием:
- Типа замечания (критическое/некритическое)
- Описания проблемы
- Ответственного за исправление
- Сроков устранения
Виды замечаний:
Тип - Влияние на запуск - Пример
Критическое (КЗ) - Блокирует запуск - Утечка персональных данных
Условно-критическое (УКЗ) - Не блокирует запуск - Неправильный шрифт в подвале сайта
Роль бизнес-аналитика в ПСИ
Бизнес-аналитик — ключевой участник процесса:
- Подготовительный этап:
Собирает все требования и документацию
Формирует ПМИ
Готовит демонстрационные сценарии - Проведение испытаний:
Демонстрирует функциональность
Отвечает на вопросы заказчика
Аргументирует соответствие требованиям - Завершающий этап:
Фиксирует замечания
Участвует в принятии решения о запуске
Формирует итоговый отчёт
Советы для успешных испытаний
- Начинайте подготовку заранее — идеально за 2-3 недели до ПСИ
- Проведите репетицию — убедитесь, что все сценарии работают
- Готовьте наглядные материалы — скриншоты, схемы, демо-данные
- Фиксируйте всё — ведите подробный протокол встреч
- Будьте готовы к доработкам — редко когда ПСИ проходят идеально
Типичные ошибки
❌ Слишком формальный подход — превращение ПСИ в "галочку"
❌ Недооценка подготовки — попытка провести без репетиций
❌ Игнорирование замечаний — нефиксация мелких недочётов
Пример из практики
Ситуация: Запуск системы онлайн-банкинга
Проблема: При нагрузке в 500 пользователей падала страница переводов
Решение:
- Зафиксировали как критическое замечание
- Разработчики оптимизировали запросы к БД
- Провели повторные испытания через 3 дня
- Успешно запустили систему
Программа и методика испытаний (ПМИ)
Что такое ПМИ и зачем она нужна?
Программа и методика испытаний (ПМИ) — это ключевой документ, который определяет порядок проведения приёмо-сдаточных испытаний (ПСИ). Это своеобразная "инструкция по проверке" продукта перед его сдачей заказчику.
Основные задачи ПМИ:
- Чётко определить что и как будем проверять
- Установить критерии успешности испытаний
- Зафиксировать порядок действий для всех участников
- Обеспечить единое понимание требований
Структура ПМИ: разбираем по разделам
1. Введение
Это "титульная часть" документа, которая содержит:
- Название проекта/продукта ("Мобильное приложение для записи к врачу")
- Автора документа (например, "Бизнес-аналитик: Иванова А.А.")
- Оглавление
- Историю изменений (если документ обновлялся)
- Список сокращений и терминов
Пример:
Сокращения:
ПСИ — приёмо-сдаточные испытания
ОЭ — опытная эксплуатация
ПЭ — промышленная эксплуатация
2. Общие положения
Здесь описываем "правила игры":
- Какие документы регламентируют испытания (ТЗ, требования)
- Место и время проведения
- Участники с обеих сторон
- Используемое оборудование
Пример для мобильного приложения:
Оборудование для тестирования:
1. Samsung Galaxy S22 (Android 13)
2. iPhone 14 (iOS 16)
3. Серверная инфраструктура клиники
3. Объект испытаний
Подробно описываем, что именно будем тестировать:
- Название и версия продукта
- Основные функции
- Целевая аудитория
Пример:
Объект: мобильное приложение для записи к врачу (v2.1.3)
Основные функции:
- Выбор клиники и врача
- Запись на приём
- Уведомления о записи
Целевая аудитория: пациенты клиники
4. Цель испытаний
Формулируем, чего хотим достичь:
- Количественные критерии (например, "поддержка 200 одновременных пользователей")
- Качественные критерии ("отсутствие критических ошибок")
Пример целей:
1. Подтвердить корректность работы всех функций
2. Проверить устойчивость при 500 одновременных запросах
3. Убедиться в безопасности данных
5. Требования к программе
Перечисляем конкретные требования, которые будем проверять, с чёткими критериями:
Функциональные требования:
ФТ1: Приложение должно аутентифицировать пользователя по номеру телефона
ФТ2: Система должна отображать доступные даты приёма
Нефункциональные требования:
НФТ1: Время отклика не более 2 секунд
НФТ2: Поддержка Android 8+ и iOS 12+
6. Объём испытаний (самый важный раздел!)
Здесь детально расписываем все проверки. Для каждой указываем:
- Что проверяем
- Как проверяем
- Критерии успеха
Пример проверки:
Проверка #1: Запись к врачу
Шаги:
1. Открыть приложение
2. Выбрать клинику
3. Выбрать врача
4. Выбрать дату и время
5. Подтвердить запись
Ожидаемый результат:
- Запись успешно создаётся
- Приходит SMS-подтверждение
- Запись отображается в "Моих записях"
Как готовить ПМИ: практические советы
- Начинайте заранее — оптимально за 2-3 недели до ПСИ
- Привлекайте команду — разработчики, тестировщики, аналитики
- Берите за основу ТЗ — все проверки должны соответствовать требованиям
- Делайте проверки измеримыми — вместо "работает быстро" пишите "время отклика < 1с"
- Учитывайте отраслевые стандарты — для медицины, банков и т.д. есть особые требования
Типичные ошибки при составлении ПМИ
❌ Слишком общие формулировки
Плохо: "Проверить работу приложения"
Хорошо: "Проверить создание записи к терапевту в филиале на ул. Ленина"
❌ Не учитываются все сценарии
Не забывайте про:
- "Счастливый путь" (идеальный сценарий)
- Ошибочные сценарии (неправильный ввод данных)
- Граничные условия (минимальные/максимальные значения)
❌ Нет чётких критериев
Для каждой проверки должно быть понятно, что считать успехом, а что — провалом.
Пример ПМИ для мобильного приложения
Проверка #3: Восстановление пароля
Шаги:
1. Нажать "Забыли пароль?"
2. Ввести зарегистрированный номер телефона
3. Нажать "Получить код"
4. Ввести код из SMS
5. Установить новый пароль
Ожидаемый результат:
1. SMS приходит в течение 1 минуты
2. После ввода кода открывается форма смены пароля
3. Новый пароль сохраняется в системе
Критерий успеха: Все шаги выполняются без ошибок
Как работать с замечаниями?
Во время испытаний могут выявиться проблемы. Их фиксируем так:
Критическое замечание (КЗ) — блокирует запуск
Пример: "При оплате списываются двойные средства"
Условно-критическое (УКЗ) — можно исправить позже
Пример: "Неверный шрифт в подвале сайта"
Для каждого замечания указываем:
- Описание
- Шаги воспроизведения
- Ответственного
- Сроки исправления
Вывод
Хорошая ПМИ — это:
✅ Полная — охватывает все ключевые функции
✅ Чёткая — с измеримыми критериями
✅ Понятная — все участники одинаково её трактуют
Потратьте время на качественную подготовку ПМИ — это сэкономит часы на исправлениях и убережёт от неприятных сюрпризов при сдаче проекта!