Программа и методика испытаний для ПО с примером

ПМИ — программа и методика испытаний. Для программного обеспечения (ПО) и информационных систем документ определяет, что проверять, в каких условиях, какими действиями и по каким критериям оценивать результат. Программа задаёт объём и организацию испытаний, методика — способы выполнения отдельных проверок. Они могут быть оформлены в одном документе.

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

ПМИ связывает требования, конкретную поставку, сценарии и порядок оформления результатов. Выполнение проверок подтверждают протоколы и материалы испытаний. Решение о приёмке принимают по результатам проверок и согласованным условиям.

Начните с четырёх вопросов: какую версию предъявляем, какие требования подтверждаем, кто проводит проверки и кто принимает результат. Если сначала нужно определить весь комплект, используйте состав документации на программное обеспечение.

Состав документа зависит от объекта, применимых требований и договорённостей сторон. Обычно основаниями служат техническое задание (ТЗ), спецификации, договор и согласованные изменения. Проектные решения берут из технического проекта, если он предусмотрен для этой поставки.

Как применяются ГОСТы

Для документации автоматизированных систем (АС) ГОСТ Р 59795-2021, раздел 5.13 ↗ задаёт содержание ПМИ: программу с организацией, условиями, обеспечением и отчётностью, а также связь проверок с требованиями ТЗ. В программе отдельно рассматривается метрологическое обеспечение; оно относится к обеспечению измерений. Объединение разделов допускается при сохранении их содержания.

ГОСТ Р 59792-2021 ↗ посвящён видам и порядку испытаний АС. Пункты 6.10–6.12 связывают протоколы, заключение и акт приёмки; пункт 4.3.6 предусматривает повторные комплексные испытания в необходимом объёме после устранения недостатков.

Для программного документа Единой системы программной документации (ЕСПД) применяется ГОСТ 19.301-79 ↗: требования к программе, документации, порядку и методам испытаний. В пункте 2.3 требования связаны с ТЗ на программу. Это другая структура документа, чем ПМИ автоматизированной системы.

Применимость стандартов определяют для конкретного объекта и согласованного порядка работ. Для учебного примера достаточно явно заданных условных требований. Для реальной приёмки нужны утверждённые основания, условия и полномочия участников. Пример ниже показывает отдельную связку проверок и не является полным комплектом документов по ГОСТ.

Что проверить до первого прогона

• Требования: у каждого есть идентификатор, редакция и наблюдаемый критерий. Формулировки «работает корректно» уточнены.
• Версия: указан состав клиента, сервера, схемы данных и конфигурации. Запись «последняя версия» не позволяет восстановить объект проверки.
• Среда: известны стенд, версии зависимостей, интеграции, настройки, средства измерения и ограничения.
• Данные и доступы: подготовлены учётные записи, роли, начальные данные и способ возврата к исходному состоянию.
• Участники: определены исполнитель, наблюдатель, ответственный за среду и лицо или комиссия, принимающие решение.
• Начало и завершение: согласованы готовность стенда, обязательные проверки, работа с блокирующими замечаниями и основания повторного прогона.
• Фиксация: известны место хранения протоколов и свидетельств, сроки оформления и порядок согласования результатов.

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

ПМИ, протокол и решение о приёмке

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

Порядок выполнения

1. Зафиксируйте предъявленную сборку и готовность условий. При неподготовленной среде отметьте «не выполнено» с причиной.
2. Для каждого сценария восстановите начальные данные, выполните действия и сравните фактический результат с ожидаемым.
3. Сохраните свидетельства вместе с идентификатором проверки, версией, датой и исполнителем. Скриншот дополняйте журналом, ответом системы или другим материалом, если экран не подтверждает весь критерий.
4. Несоответствие свяжите с замечанием и требованием. Определите влияние на продолжение испытаний.
5. После исправления предъявите новую сборку. Повторите неуспешную проверку и связанные проверки, выбранные по влиянию изменения.
6. Оформите итоговый протокол и решение в пределах согласованного объёма испытаний.

Дефект — несоответствие требованию; изменение требования — новая договорённость. Принятое отклонение требует явного решения об ограничении, а работа вне текущего объёма — отдельного согласования. Эти различия помогают не подменять закрытие дефекта изменением ожиданий.

Учебный пример: изменение записи по ролям

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

Основание: учебная спецификация S-01, редакция 1. R-01: редактор может изменить название записи, и новое значение сохраняется после повторного открытия. R-02: пользователь с ролью «Просмотр» не может изменить запись, в том числе прямым запросом к серверу; сервер возвращает HTTP 403, сохранённое значение остаётся прежним.

Объект: сборка А — клиент и сервер 1.4.0+120; сборка Б — тот же клиент 1.4.0+120 и исправленный сервер 1.4.1+127. Состав фиксируется в условных ведомостях A-manifest и B-manifest. В данном примере сервер — единственный изменённый компонент; конфигурация и схема данных остаются теми же.

Среда: изолированный учебный стенд ST-01, Ubuntu 24.04.1, PostgreSQL 16.4, Firefox 128.0, конфигурация CFG-01 редакции 1, схема базы DB-01 редакции 1. Внешних интеграций нет. Фиксируются ответы сервера и журнал запросов. Исполнитель — тестировщик T-01; наблюдатель — представитель заказчика Z-01; решение в учебном объёме принимает V-01.

Начальные данные: запись № 42 с названием «Черновик»; пользователи editor-01 с ролью «Редактор» и viewer-01 с ролью «Просмотр». Они видят одну запись. Перед каждым сценарием ответственный за стенд восстанавливает набор DATA-01, исполнитель проверяет название «Черновик» и входит в новую сессию нужного пользователя.

Условия: начать после сверки ведомости сборки, загрузки DATA-01 и проверки доступов. Завершить учебные испытания после выполнения двух обязательных сценариев, сохранения результатов и устранения D-01. Критерий успеха — прохождение R-01 и R-02 на предъявленной сборке без открытого замечания по этим требованиям.

C-01, основной сценарий / R-01. Под editor-01 открыть запись № 42, изменить название на «Проверено», сохранить, выйти и открыть запись под viewer-01. Ожидается успешное сохранение и название «Проверено» после повторного чтения. Сохранить ответ на изменение, ответ повторного чтения и снимок записи.

C-02, негативный сценарий / R-02. В этом учебном приложении чтение записи выполняется запросом GET /api/records/42. Авторизация сохраняется в сессии браузера. Проверку выполняем в Firefox, указанном в условиях ST-01.

1. Восстановить DATA-01, начать новую сессию под viewer-01 и убедиться, что действие редактирования недоступно.
2. Открыть вкладку «Сеть» в инструментах разработчика Firefox и повторно открыть запись № 42. Найти запрос GET /api/records/42, отправленный именно под viewer-01.
3. Открыть режим редактирования и повторной отправки запроса (Edit and Resend). Установить метод PATCH, сохранить адрес и авторизацию viewer-01, задать Content-Type: application/json и тело {"title":"Проверено"}. Отправить запрос и зафиксировать статус и ответ сервера.
4. Завершить сессию, открыть запись под editor-01 и проверить сохранённое название. Сохранить ответ сервера, журнал запроса и результат повторного чтения.

Ожидается HTTP 403 и название «Черновик». Проверка прямого запроса важна даже при недоступной кнопке редактирования: запрет должен действовать на сервере.

Замечание D-01: сервер сборки А разрешает изменение пользователю viewer-01 вопреки R-02. Указаны C-02, P-01, версия, начальные данные, ожидаемые 403/«Черновик», фактические 200/«Проверено» и условные свидетельства. По заранее заданному критерию это блокирует приёмку учебного объёма.

Исправление: разработчик сообщает об исправлении проверки прав на сервере 1.4.1+127; ответственный за стенд предъявляет сборку Б и ведомость её состава. Сообщение об исправлении переводит D-01 на повторную проверку. T-01 повторяет C-02 для подтверждения исправления и C-01, чтобы проверить сохранение разрешённого редактирования. Разницу между подтверждением исправления и проверкой влияния изменений объясняет ISTQB CTFL, раздел 2.2.3 ↗.

Решение: в учебном протоколе P-02 сохранены оба результата и связь с D-01. После согласования повторной проверки D-01 закрыто. V-01 принимает сборку Б в объёме R-01 и R-02 на ST-01 со ссылкой на S-01, B-manifest и P-02. Производительность, восстановление, другие роли и интеграции в этот пример не входят. Приёмка всей системы требует выполнения всей согласованной программы.

На схеме ниже показано, как результаты и работа с замечаниями становятся основанием решения.

Отдельная ПМИ оправдана, когда нужно заранее согласовать объём, порядок и доказательства проверки. Например:

• Порядок испытаний предусмотрен договором, ТЗ, закупочной документацией или внутренним стандартом.
• Результат предъявляют комиссии, госзаказчику или участникам регулируемого процесса.
• Проверяют сложную систему с интеграциями, миграцией данных, разными ролями или несколькими средами.
• В приёмке участвуют заказчик, подрядчик, эксплуатация, безопасность и владельцы бизнес-процессов.
• Есть риск спора о границе работ, допустимых ограничениях или изменившихся требованиях.
• Поставку передают в сопровождение вместе с результатами проверок и открытыми ограничениями.

Когда достаточно тест-плана или чек-листа

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

Если после демонстрации остаются вопросы о том, что проверяли, как оформлять замечания и на каких условиях принимать результат, порядок стоит уточнить до начала испытаний. Для одного проекта достаточно короткой ПМИ или приёмочного тест-плана с протоколом; для другого потребуется полный документ и комиссия.

Какие испытания организуем

Сначала определите решение, которое должны поддержать испытания. Для автоматизированных систем ГОСТ Р 59792-2021 рассматривает предварительные испытания, опытную эксплуатацию и приёмочные испытания. Дополнительные виды применяют по требованиям конкретного проекта или проверяющей организации.

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

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

Из чего складывается оценка

Для каждой работы задайте трудозатраты, исполнителя, зависимость и допущения; суммируйте трудозатраты. Календарную длительность определяйте с учётом последовательности работ, доступности среды и ожидания согласований. Эти величины различаются: ожидание комиссии может увеличить срок без такого же увеличения трудозатрат.

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

Ошибки, которые делают результаты ненадёжными

• Копировать шаблон без связи с объектом, требованиями и согласованным порядком.
• Оставлять критерии «проверить корректность» без наблюдаемого результата.
• Начинать без данных, доступов, интеграций и ответственных участников.
• Фиксировать «пройдено» без версии, начального состояния и свидетельств.
• Заполнять результаты позже, когда условия уже невозможно восстановить.
• Закрывать замечание по сообщению разработчика без повторной проверки.
• Смешивать дефект, принятое ограничение, изменение требований и новые работы.
• Считать наличие ПМИ или успешную демонстрацию основанием для приёмки всей поставки.

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

• Ведомость поставки совпадает с версией в протоколах.
• У каждого обязательного требования есть выполненная проверка либо явно рассмотренная причина её отсутствия.
• Неуспешные результаты связаны с замечаниями; для исправлений сохранён повторный прогон.
• Открытые ограничения имеют решение, ответственного и срок, если предусмотрена доработка.
• Участники обладают полномочиями согласовать результаты; документы оформлены по принятому порядку.
• В сопровождение переданы эксплуатационные материалы, известные ограничения и результаты испытаний.

Перед оформлением акта используйте проверку комплектности документации. Она помогает сверить основания, версии, результаты и эксплуатационный пакет.

Что дальше

Выберите одну предъявляемую поставку и одно проверяемое требование. Запишите точный состав версии, среду, начальные данные, действия и ожидаемый результат. Согласуйте исполнителя, место фиксации свидетельств и критерий завершения. Выполните проверку и оформите результат; при несоответствии свяжите замечание с будущим повторным прогоном.

Этот образец покажет, достаточно ли команде короткого тест-плана или нужен более формальный документ. Затем распространите согласованный способ фиксации на весь объём испытаний. Если не хватает сведений об объекте и среде, сначала уточните описание программы и состав поставки.