Протокол испытаний программного обеспечения фиксирует конкретный программный продукт, его версию, тестовую среду, сценарии и фактические результаты проверок. Универсального обязательного бланка для любого ПО нет. По запросу «Протокол испытаний программного обеспечения образец и ГОСТ» основным ориентиром служит ГОСТ Р 56922-2016, но структуру документа адаптируют к проекту и цели испытаний.
Документ должен позволять установить, что именно проверяли, при каких условиях и по каким критериям вынесен итоговый вывод. Формальной записи «программа протестирована, замечаний нет» для этого недостаточно.
Коротко о главном
- Протокол составляют во время испытаний или по их итогам, когда уже получены фактические результаты.
- Объект испытаний идентифицируют по версии, номеру сборки, релизу или другому признаку конфигурации.
- Результаты связывают с требованиями, тестовыми сценариями и критериями приемки.
- В документе фиксируют параметры тестовой среды, которые влияют на воспроизводимость проверки.
- Программа и методика испытаний определяют порядок проверки, а протокол показывает, что получилось.
- Отчёт о тестировании, протокол и акт приёмки решают разные задачи, хотя проект может объединить часть их содержания.
- Форма документа зависит от договора, технического задания, внутренних регламентов и назначения испытаний.
Что такое протокол испытаний программного обеспечения
Протокол испытаний программного обеспечения представляет собой итоговый или поэтапный документ с доказательствами выполненных проверок. В нём указывают объект испытаний, основание для работы, применённые методы, условия тестовой среды, ожидаемые и фактические результаты, выявленные отклонения и вывод по установленным критериям.
Объектом может выступать настольная программа, мобильное приложение, веб-сервис, отдельный модуль, API, интеграция, информационная система или программный комплекс. Названия продукта недостаточно. Один программный продукт существует в разных релизах, сборках и конфигурациях, а результаты старой версии нельзя без проверки переносить на новую.
Идентификация конфигурации особенно важна при частых обновлениях. Протокол должен содержать версию программного обеспечения, номер сборки, дату релиза либо другой используемый в проекте идентификатор. Если проверяли только определённый модуль, это ограничение тоже фиксируют, чтобы вывод не воспринимался как подтверждение характеристик всей системы.
Что подтверждает такой документ? Он показывает факт выполнения тестовых сценариев и результаты испытаний в описанных условиях. Протокол не доказывает, что программа лишена любых дефектов, и не подтверждает характеристики, которые не входили в объём проверки.
Когда нужен протокол испытаний ПО
Единого перечня ситуаций, в которых каждая ИТ-компания обязана оформлять протокол, нет. Потребность возникает из условий договора, технического задания, процедуры приёмки, внутренних правил качества, конкурсной документации либо выбранной процедуры добровольного подтверждения характеристик.
Передача результата разработки заказчику
При передаче ПО протокол связывает обязательства исполнителя с проверяемым результатом. Для каждого существенного требования указывают тестовый сценарий, ожидаемое поведение системы, фактический результат и статус проверки. Такая структура помогает сторонам отделить подтверждённые функции от замечаний, ограничений и работ, которые ещё не завершены.
Если техническое задание содержит измеримые критерии, их переносят в программу испытаний и тест-кейсы. Общие формулировки вроде «удобный интерфейс» или «высокая производительность» сначала уточняют: без показателя, метода измерения и допустимого результата объективная проверка невозможна.
Приёмочные испытания информационной системы
Приёмочные испытания проводят по правилам, установленным договором и проектной документацией. Стороны заранее определяют состав комиссии или участников, последовательность проверок, условия допуска системы, порядок регистрации замечаний и документы, которыми оформляют решение о приёмке.
Для автоматизированных систем может применяться ГОСТ Р 59792-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Его нельзя механически распространять на любую программу. Применимость стандарта определяют с учётом объекта, проектной документации, условий договора и отраслевых требований.
Протокол в такой процедуре хранит доказательную часть, а акт приёмки фиксирует решение сторон. Успешно выполненные тесты сами по себе не заменяют акт, если договор предусматривает отдельное оформление приёмки.
Выпуск новой версии или обновления
После изменения кода проверяют исправленные функции и связанные с ними участки системы. Регрессионное тестирование показывает, не нарушил ли новый релиз ранее работавшие возможности. В протокол включают идентификатор новой сборки, перечень изменений в пределах испытаний, выполненные тест-кейсы и обнаруженные дефекты программного обеспечения.
Старый протокол нельзя просто переименовать под новую версию. Даже небольшое обновление способно изменить зависимости, интеграции, права доступа или обработку данных, поэтому состав повторных проверок определяют после анализа изменений и рисков.
Внутренний контроль качества
Внутренний протокол часто короче документа для заказчика. Команда вправе использовать собственную форму, связанную с системой управления задачами, журналом тестирования и результатами автотестов. Минимальный состав всё равно должен отвечать на вопросы о версии, окружении, выполненных сценариях и полученном результате.
Если тестирование программного обеспечения ведётся постоянно, доказательства удобнее сохранять вместе с каждой сборкой. Попытка восстановить сведения после выпуска продукта часто заканчивается потерей логов, точных параметров окружения и данных о последовательности проверок.
Добровольное подтверждение характеристик ПО
Добровольный сертификат соответствия не равен протоколу испытаний. Сначала определяют объект подтверждения, нормативный документ или заявленные требования, перечень оцениваемых характеристик и допустимые доказательства. Только после этого становится понятно, какие испытания потребуются и кто вправе их выполнить в выбранной процедуре.
Для внутреннего QA-отчёта аккредитация испытательной лаборатории не служит универсальным условием. Если заказчик требует документ от аккредитованного лица, проверяют область аккредитации лаборатории и соответствие заявленного метода её компетенции. Национальную систему аккредитации регулирует Федеральный закон № 412-ФЗ, а сведения об аккредитованных лицах ведёт Росаккредитация.
Есть ли единый образец протокола испытаний программного обеспечения по ГОСТ
Единого государственного бланка, который обязательно подходит каждому программному продукту, нет. ГОСТ Р 56922-2016 описывает документацию тестирования на уровне организации, проекта и отдельных процессов тестирования, но содержание конкретного протокола зависит от объекта и целей проверки.
Образец протокола испытаний ПО нужно адаптировать. Для мобильного приложения существенны модель устройства, версия операционной системы и разрешения. Для веб-сервиса важны браузер, серверная часть, база данных, API и внешние интеграции. При нагрузочном тестировании потребуются схема нагрузки, исходные данные, конфигурация стенда и измеряемые показатели.
Собственную форму утверждает лицо, которое наделено такими полномочиями внутренними правилами организации. В договорном проекте стороны могут согласовать форму в техническом задании, программе и методике испытаний, приложении к договору или отдельном регламенте. Государственное согласование обычного внутреннего протокола тестирования ПО универсально не требуется.
Если заказчик уже закрепил форму в контракте или конкурсной документации, исполнитель использует её. Недостающие сведения лучше добавить приложением или согласованным разделом, чем исключить данные о версии, тестовой среде и фактических результатах ради формального совпадения с кратким шаблоном.
Какие стандарты здесь работают на самом деле: номера приказов и даты
Единого обязательного бланка действительно нет. Но документы, из которых собирают состав протокола, вполне конкретные, и у каждого есть номер приказа, дата введения и статус. Проверка занимает минуту и снимает половину споров с заказчиком — особенно когда в техническом задании стоит ссылка на стандарт, который уже не действует.
| Документ | Чем утверждён | Дата введения | Статус на 26 августа 2026 года |
|---|---|---|---|
| ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению | постановление Госстандарта СССР от 11.12.1979 № 4753 | 1 января 1980 года | действует, с изменениями № 1 и 2 (ИУС 5-82 и 9-83), издание 2010 года |
| ГОСТ Р 56920-2016 / ISO/IEC/IEEE 29119-1:2013. Тестирование программного обеспечения. Часть 1. Понятия и определения | приказ Росстандарта от 18.05.2016 № 331-ст | 1 июня 2017 года | не действует |
| ГОСТ Р 56920-2024. Системная и программная инженерия. Тестирование программного обеспечения. Общие положения | приказ Росстандарта от 10.06.2024 № 752-ст | 30 сентября 2024 года | действует |
| ГОСТ ISO/IEC 17025-2019. Общие требования к компетентности испытательных и калибровочных лабораторий | приказ Росстандарта от 15.07.2019 № 385-ст | 1 сентября 2019 года | действует |
Обратите внимание на вторую и третью строки: серию 29119 в России в 2024 году пересобрали, и первая часть 2016 года уже вне действия. Прежде чем ссылаться на любой номер из этой серии, сверьтесь с реестром Росстандарта на дату подписания протокола, а не с сохранённой у себя копией.
Шесть разделов, которые ГОСТ 19.301-79 требует буквально
Это единственный из перечисленных документов, где состав документа задан списком, а не принципами. Пункт 1.2 называет шесть разделов «Программы и методики испытаний»: объект испытаний; цель испытаний; требования к программе; требования к программной документации; средства и порядок испытаний; методы испытаний. Дополнительные разделы вводить разрешено. Структуру и оформление берут по ГОСТ 19.105-78, информационная часть (аннотация и содержание) необязательна.
Шестнадцать сведений, без которых протокол лаборатории неполон
Если протокол выпускает аккредитованная испытательная лаборатория, минимальный состав задан п. 7.8.2.1 ГОСТ ISO/IEC 17025-2019 — шестнадцать позиций от a) до p). Отступить от них лаборатория может, только если у неё есть обоснованные причины.
| Пункт | Что должно быть в протоколе |
|---|---|
| a) | Название документа — например, «Отчёт об испытаниях» |
| b) | Наименование и адрес лаборатории |
| c) | Место, где выполнялась работа, включая площадку заказчика, удалённый участок, временный или мобильный объект |
| d) | Уникальная идентификация документа и чёткая отметка его конца |
| e) | Наименование и контактные данные заказчика |
| f) | Идентификация применённого метода |
| g) | Описание, однозначная идентификация и при необходимости состояние образца |
| h) | Дата получения образца и дата отбора, когда это влияет на достоверность результатов |
| i) | Даты выполнения лабораторной деятельности |
| j) | Дата выдачи документа |
| k) | Ссылка на план и метод отбора образцов, если это важно для результатов |
| l) | Заявление, что результаты относятся только к тому, что испытывали |
| m) | Результаты с единицами измерения |
| n) | Дополнения, отклонения и исключения из метода |
| o) | Идентификация лиц, утвердивших документ |
| p) | Однозначная идентификация результатов, полученных от внешних поставщиков |
Пункт 7.8.3.1 добавляет к этому для отчётов об испытаниях ещё пять позиций, если они нужны для понимания результата: особые условия испытаний, заявление о соответствии требованиям или спецификациям, неопределённость измерений, мнения и интерпретации, а также сведения, которых требуют конкретный метод, орган власти или заказчик. Примечание 1 к п. 7.8.1.2 прямо оговаривает: отчёты об испытаниях иногда называют протоколами испытаний — это один и тот же документ.
Для программного обеспечения часть позиций читается непривычно: роль «образца» играет конкретная сборка, а «состояние образца» — это версия, номер сборки или идентификатор коммита. Но структура остаётся рабочей: пункты c), g), h) и n) как раз закрывают то, из-за чего протоколы чаще всего возвращают на доработку — где испытывали, что именно испытывали и в чём отступили от заявленного метода.
Чем протокол отличается от программы и методики испытаний, отчёта и акта
| Документ | Для чего нужен | Когда готовят | Что в нём главное |
|---|---|---|---|
| Программа и методика испытаний | Определяет организацию, объём и порядок проверок | До начала испытаний | Объект, методы, сценарии, условия и критерии приемки |
| Протокол испытаний | Фиксирует выполнение проверок и полученные результаты | В процессе или по итогам испытаний | Версия, среда, фактические результаты, отклонения и доказательства |
| Отчёт о тестировании | Обобщает результаты тестового этапа | После этапа или релиза | Покрытие, дефекты, ограничения, риски и выводы QA-команды |
| Журнал тестирования | Хранит последовательные записи о ходе работы | Во время тестирования | События, исполнители, время выполнения, сбои и промежуточные статусы |
| Акт приёмки | Оформляет решение сторон о принятии результата | После выполнения предусмотренной процедуры | Решение заказчика и исполнителя, замечания и условия приёмки |
В одном проекте протокол и отчёт о тестировании можно объединить, если договор и внутренние правила допускают такую форму. Объединённый документ должен сохранять доказательную часть: сведения об объекте, версии, среде, тестовых сценариях, фактических результатах и выявленных отклонениях.
Программа испытаний отвечает на вопрос «что и в каком порядке будем проверять?». Методика объясняет, как выполнить проверку и оценить результат. Протокол отвечает на другой вопрос: «что фактически сделали и что получили?» Акт фиксирует решение о приёмке, которое принимают уполномоченные участники процедуры.
Ниже приведён образец структуры без фиктивных реквизитов и результатов. Его можно использовать как основу внутренней формы, а затем дополнить требованиями договора, технического задания и принятой документации тестирования.
- Наименование и идентификатор документа. Указывают название «Протокол испытаний программного обеспечения», номер документа и обозначение проекта, если организация использует систему регистрации.
- Сведения об объекте испытаний. Фиксируют наименование программного продукта, назначение, проверяемый модуль, версию, номер сборки, релиз и другой идентификатор конфигурации, который позволяет однозначно определить объект.
- Основание для испытаний. Перечисляют техническое задание, договор, программу и методику испытаний, план тестирования, спецификацию требований, заявку на изменение или внутренний регламент.
- Цель и объём проверки. Описывают характеристики и функции, которые нужно подтвердить. Здесь же перечисляют исключения, если часть системы не входила в испытания.
- Вид испытаний. Указывают функциональное, интеграционное, регрессионное, нагрузочное тестирование, проверку безопасности, приёмочные или иные испытания, предусмотренные проектом.
- Участники. Вносят сведения об исполнителях тестирования, представителях заказчика и иных участниках, если их участие установлено процедурой. Полномочия на утверждение или подписание определяют договор и внутренние правила.
- Тестовая среда. Описывают операционную систему, браузер, устройство, серверную конфигурацию, базу данных, версию API, сетевые условия, внешние сервисы и другие параметры, влияющие на результат.
- Исходные и тестовые данные. Указывают наборы данных, входные параметры, права доступа, учётные записи, предварительные условия и ограничения. Конфиденциальные сведения можно идентифицировать без раскрытия их содержимого в основной части документа.
- Перечень проверок. Для каждого требования приводят идентификатор тест-кейса, краткое описание сценария, действия и ожидаемый результат. Подробные шаги допустимо вынести в приложение.
- Фактические результаты. Записывают наблюдаемое поведение программы, полученные значения, статус теста и ссылку на доказательства тестирования. Статус должен быть понятен без устных пояснений исполнителя.
- Дефекты и замечания. Указывают идентификатор дефекта, описание, условия воспроизведения, критичность по принятой в проекте шкале, статус исправления и влияние на критерии приемки.
- Итоговый вывод. Формулируют результат только в пределах проведённых проверок. Если остались дефекты или ограничения, их перечисляют вместе с влиянием на итоговое решение.
- Приложения. Прикладывают таблицы тест-кейсов, логи, скриншоты, выгрузки автотестов, файлы конфигурации, матрицу трассируемости и перечень дефектов.
- Подписание или утверждение. Документ подписывают лица, предусмотренные договором, программой испытаний или внутренним регламентом. Состав подписантов не устанавливается одним универсальным правилом для любого ПО.
Основную таблицу результатов удобно строить по цепочке «требование, тест-кейс, ожидаемый результат, фактический результат, статус, доказательство, дефект». Такая документация тестирования позволяет проверить покрытие требований и быстро найти основание для каждого вывода.
Как заполнить ключевые разделы протокола без формальных ошибок
Не указана версия или сборка ПО
Причина: составитель ограничился коммерческим названием продукта. Последствие: невозможно установить, какая конфигурация прошла испытания и относятся ли результаты к передаваемому релизу. Корректное действие: внести версию программного обеспечения, номер сборки, обозначение релиза или идентификатор коммита, если его используют в проекте.
Нет описания тестовой среды
Причина: параметры окружения посчитали техническими деталями. Последствие: команда или заказчик не могут повторить проверку, а дефект проявляется только на отдельных устройствах, браузерах или конфигурациях. Корректное действие: фиксировать характеристики среды, которые влияют на работу проверяемой функции.
Требования не связаны с результатами
Причина: в протокол внесли только общий перечень функций и итоговый статус. Последствие: неясно, какие требования к программному обеспечению действительно проверены. Корректное действие: использовать идентификаторы требований и тест-кейсов, а для крупного проекта подготовить матрицу трассируемости.
Фактический результат повторяет ожидаемый
Причина: исполнитель скопировал формулировку из тестового сценария. Последствие: запись не показывает, что происходило во время проверки. Корректное действие: описать наблюдаемое поведение, полученные значения или созданные объекты и указать, где сохранены логи, скриншоты либо результаты автотеста.
В документе скрыты отклонения
Причина: протокол пытаются представить как подтверждение безусловной готовности продукта. Последствие: нерешённые вопросы переходят на этап эксплуатации и становятся предметом спора. Корректное действие: фиксировать дефекты, ограничения, обходные решения и условия проявления, а итоговый вывод соотносить с критериями приемки.
Статус теста не определён
Причина: команда использует сокращения без расшифровки или смешивает «не пройден» и «не выполнен». Последствие: читатель не понимает, обнаружен ли дефект или проверку вообще не проводили. Корректное действие: закрепить набор статусов в программе испытаний или правилах проекта и применять его последовательно.
Что подготовить до начала испытаний
- описание программного продукта, его назначения и границ проверяемой системы;
- техническое задание, спецификацию требований или иной документ с критериями оценки;
- сведения о версии, сборке и составе поставки;
- программу и методику испытаний либо согласованный план тестирования;
- перечень тестовых сценариев и тест-кейсов;
- доступ к тестовому стенду, приложению, API или отдельному модулю;
- тестовые учётные записи с установленными правами доступа;
- исходные данные и правила их подготовки;
- описание интеграций и зависимостей от внешних сервисов;
- логи, скриншоты, выгрузки автотестов и другие доказательства;
- реестр выявленных дефектов, если команда ведёт его отдельно.
Для внутреннего функционального тестирования небольшой программы комплект можно сократить. Приёмка информационной системы с несколькими подсистемами, ролями пользователей и интеграциями потребует более подробной программы, матрицы требований, описания стенда и приложений к протоколу.
До начала работы полезно пройти последовательность подготовки:
- Определить цель. Зафиксировать, нужен ли внутренний контроль, договорная приёмка, подтверждение отдельных характеристик или документ для иной процедуры.
- Идентифицировать объект. Установить продукт, модуль, версию, сборку и состав проверяемой конфигурации.
- Собрать требования. Убрать неоднозначные формулировки и определить измеримые критерии приемки.
- Подготовить методику. Описать тестовые сценарии, данные, условия, ожидаемые результаты и правила присвоения статусов.
- Настроить сохранение доказательств. Определить, где будут храниться логи, скриншоты, отчёты автотестов и записи о дефектах.
- Провести проверки. Выполнить сценарии в идентифицированной среде и записать фактические результаты без исправления истории задним числом.
- Сформировать вывод. Сопоставить результаты с критериями и перечислить ограничения, не пройденные проверки и открытые замечания.
Пример из практики: почему сначала определяют цель документа и применимый ГОСТ
Запрос о сертификации программного обеспечения
В «Реестр Гарант» обратилась организация, которой требовалось подтвердить характеристики программы для анализа объектов на изображениях и видео. Первоначальный запрос звучал как «сертифицировать программное обеспечение по ГОСТ», но такой формулировки недостаточно для выбора процедуры и состава документов.
Сначала специалисты уточнили назначение продукта, перечень подтверждаемых характеристик и предполагаемого получателя документа. Отдельно выясняли, нужен ли добровольный сертификат соответствия, протокол для заказчика или внутренний отчёт о тестировании. Эти документы нельзя заменять друг другом только потому, что каждый из них связан с оценкой ПО.
Для определения порядка работы требовалось установить:
- какие функции и показатели программы нужно проверить;
- какой нормативный документ, технические условия или требования заказчика задают критерии;
- нужен ли самостоятельный протокол испытаний;
- какая версия программного продукта будет объектом проверки;
- какие доступы, тестовые данные и документы потребуются исполнителю;
- требуется ли участие лаборатории с определённым статусом в конкретной процедуре.
Практический вывод простой: выбор шаблона начинается не с поиска файла, а с определения задачи. Для одного продукта внутренняя проверка качества, приёмка заказчиком и добровольное подтверждение соответствия ПО потребуют разного состава доказательств и разных итоговых документов.
Запрос на испытания по нескольким показателям
Другой клиент обращался по поводу испытаний материального изделия, эластичной ленты. Этот пример не относится к программному обеспечению напрямую, однако показывает правильную последовательность квалификации запроса: специалист уточнил назначение изделия, показатели, нормативную базу и требования к статусу лаборатории.
Для материальной продукции понадобились реальные образцы, а возможность испытаний зависела от компетенции лаборатории и её области аккредитации. Содержание таких протоколов регулируют методы испытаний конкретной продукции. Например, отдельные требования к физическим образцам раскрыты в материале про протокол испытаний бетонных смесей, а правила электрических проверок рассмотрены в руководстве про испытания диэлектрических перчаток.
Переносить такую логику на ПО без поправки нельзя. Вместо физического образца нужен доступ к конкретной сборке, тестовому стенду, API, данным и документации. Лабораторное оборудование заменяется программно-аппаратной средой только в бытовом смысле: методы, компетенции и основания процедуры всё равно определяют отдельно.
Нужен ли образец программного обеспечения для испытаний
Физический образец, характерный для испытаний материальной продукции, для ПО обычно не нужен. Но испытать программу без самого объекта проверки невозможно. Исполнитель должен получить доступ к конкретной версии приложения, сборке, модулю, API или тестовому контуру.
В зависимости от архитектуры потребуются установочный пакет, тестовая учётная запись, документация по API, набор исходных данных, описание интеграций и ограничения окружения. Для мобильного приложения нужны поддерживаемые устройства или эмуляторы, а для серверной системы может потребоваться выделенный стенд с воспроизводимой конфигурацией.
Облачный сервис не передают как физический экземпляр. В протоколе идентифицируют доступный контур, версию развёртывания и существенные параметры среды. Если система обновляется автоматически, команда должна сохранить сведения о конфигурации, которая действовала в момент проверки.
А что делать, если доступ к производственной среде запрещён? Испытания проводят на тестовом контуре и прямо фиксируют это ограничение. Вывод относится к описанной среде, а эквивалентность тестовой и производственной конфигураций подтверждают только в той части, для которой есть достоверные данные.
Как фиксировать результаты и доказательства тестирования
Каждая запись должна связывать исходное требование с тестовым действием и наблюдаемым результатом. Для простого проекта достаточно таблицы. В крупной информационной системе используют идентификаторы требований, тест-кейсов и дефектов, чтобы построить трассируемость между техническим заданием и результатами испытаний.
Ожидаемый результат формулируют до выполнения проверки. Фактический результат записывают после неё и не подгоняют под ожидание. Если программа вернула ошибку, зависла или выполнила действие частично, это отражают в протоколе вместе с условиями воспроизведения.
Доказательствами могут служить логи, снимки экрана, видео прохождения сложного сценария, выгрузки из системы автотестов, ответы API, результаты измерений и записи журнала тестирования. Формат зависит от характера требования. Скриншот подтверждает отображение интерфейса, но плохо подходит для оценки производительности или устойчивости под нагрузкой.
При тестировании безопасности состав приложений ограничивают с учётом конфиденциальности. Открытый протокол не должен раскрывать пароли, ключи доступа, персональные данные и сведения, которые создают дополнительные риски. Доказательства можно хранить отдельно, обозначив их идентификаторы и порядок доступа.
Особенности разных видов испытаний
Функциональное тестирование
Проверки строят по функциям и пользовательским сценариям. В протоколе указывают входные условия, действия, ожидаемый и фактический результат. Положительных сценариев недостаточно, если требования предусматривают обработку ошибок, ограничения прав и проверку некорректных данных.
Интеграционное тестирование
Документ должен идентифицировать взаимодействующие системы, версии интерфейсов и тестовые точки. При сбое фиксируют, на каком этапе нарушился обмен, какой ответ вернул внешний сервис и могла ли недоступность интеграции повлиять на другие сценарии.
Нагрузочное тестирование
Результат зависит от конфигурации стенда, профиля нагрузки, объёма данных и продолжительности сценария. Без этих сведений показатели нельзя воспроизвести или корректно сравнить с другим запуском. Критерии производительности задают до испытаний, а не выбирают после получения удобных значений.
Тестирование безопасности
Объём проверки определяют модель угроз, требования проекта и разрешённые методы. Итоговый документ отделяет проверенные свойства от предположений. Если проводился только анализ настроек или автоматизированное сканирование, вывод не распространяют на все аспекты защищённости продукта.
Регрессионное тестирование
Набор тестов формируют с учётом изменений и связанных рисков. Протокол указывает, какие сценарии повторили после исправлений, какие области не вошли в прогон и к какой сборке относятся результаты. Закрытый дефект не считается проверенным, пока команда не выполнила предусмотренную повторную проверку.
Частые сложности при оформлении протокола и как их решить
Заказчик не предоставил форму. Исполнитель готовит проект структуры на основании технического задания и согласует состав сведений до начала испытаний. За основу можно взять логику ГОСТ Р 56922-2016, сохранив разделы об объекте, среде, сценариях, результатах и ограничениях.
Непонятно, какой ГОСТ подходит. Поиск начинают с классификации объекта и цели процедуры. Отдельная программа, автоматизированная система и ПО в составе оборудования могут подпадать под разные проектные и отраслевые требования. Название стандарта нельзя выбирать только по наличию слова «испытания».
Требования изложены общими словами. До подготовки тест-кейсов их переводят в проверяемые критерии. Заказчик и исполнитель определяют, какое поведение считается ожидаемым, каким способом его проверяют и какие отклонения допустимы.
Нет доступа к производственной среде. Используют тестовый стенд, описывают отличия и ограничивают вывод условиями этого стенда. Скрывать различия нельзя, поскольку серверная конфигурация, данные и внешние сервисы влияют на результаты.
Проверки прошли, но доказательства не сохранились. Достоверные сведения восстанавливают из журналов, систем сборки и истории задач, если они сохранились. При отсутствии подтверждений критичные сценарии выполняют повторно. Составлять результат по памяти нельзя.
Протокол готовят после релиза. Команда идентифицирует фактически выпущенную сборку, собирает доступные записи и отделяет подтверждённые проверки от предположений. Если старую среду восстановить невозможно, ограничение включают в документ, а нужные испытания проводят на доступной конфигурации.
Протокол смешивают с испытаниями материальной продукции. У разных объектов отличаются образцы, методы и доказательства. Например, протокол испытаний заземления основан на измерениях физической системы, тогда как для ПО центральное значение имеют версия, конфигурация, сценарии и данные.
Проверка готового протокола перед подписанием
Перед передачей документа заказчику проверьте не оформление ради оформления, а доказательную связность. Читатель, который не участвовал в тестировании, должен понять границы проверки и найти подтверждение итогового вывода.
- Объект и версия программного обеспечения определены однозначно.
- Основание для испытаний и критерии приемки указаны.
- Тестовая среда описана в объёме, достаточном для воспроизведения.
- Каждый результат связан с требованием или тестовым сценарием.
- Фактические результаты отличаются от заранее заданных ожиданий и содержат наблюдаемые данные.
- Дефекты, пропущенные тесты и ограничения не скрыты.
- Приложения перечислены и доступны уполномоченным участникам.
- Итоговый вывод не выходит за границы проведённых проверок.
- Документ подписывают или утверждают лица, определённые процедурой проекта.
FAQ
Мне нужен протокол испытаний по 5 показателям.
Сначала определяют сами показатели, требования к ним и методы проверки. По каждому показателю в протоколе фиксируют связанное требование, тестовый сценарий, ожидаемый результат, фактический результат, статус и доказательства выполнения.
Нужен ли образец?
Для программного обеспечения обычно нужен не физический образец, а доступ к конкретной версии программы или тестовому стенду. Также могут потребоваться учётные записи, тестовые данные, документация по API и сведения об интеграциях.
Как можно сертифицировать программу обеспечения?
Сначала определяют цель подтверждения, объект оценки и нормативную основу. Добровольный сертификат соответствия, протокол испытаний и внутренний отчёт о тестировании решают разные задачи и не заменяют друг друга автоматически.
Какой сертификат это может быть?
Вопрос решают после анализа назначения программы и требований получателя документа. Если обязательные требования к выбранной процедуре не установлены, может рассматриваться добровольное подтверждение соответствия, но его основание и показатели нужно определить заранее.
Если образца нет, что делать?
Подготовьте доступ к объекту испытаний: сборке, приложению, API или тестовому контуру. Если фактический доступ отсутствует, достоверно подтвердить выполнение тестовых сценариев и оформить доказательный протокол нельзя.
Сколько времени занимает оформление?
Продолжительность зависит от количества требований, готовности тестовой среды, состава сценариев и необходимости повторных проверок после исправления дефектов. Срок определяют после анализа программы, документации и требуемого объёма испытаний.
Вывод: каким должен быть рабочий протокол испытаний ПО
Рабочий протокол относится к конкретной версии программного продукта, связывает результаты испытаний с требованиями и описывает условия, в которых выполнялись проверки. ГОСТ Р 56922-2016 даёт основу для построения документации тестирования, но форму документа нужно адаптировать к цели, архитектуре продукта и правилам проекта.
- Идентифицируйте версию, сборку и границы объекта испытаний.
- Свяжите требования, тестовые сценарии, фактические результаты и дефекты.
- Зафиксируйте тестовую среду, ограничения и состав доказательств.
- Согласуйте критерии приемки до начала проверок, а не после получения результатов.
«Реестр Гарант» с 2015 года сопровождает оценку соответствия продукции и услуг по России и помогает разграничить испытательный протокол, добровольный сертификат и внутреннюю тестовую документацию. До начала процедуры стоит подготовить описание продукта, требования, сведения о версии и доступ к тестовой среде.