Каждая АС должна иметь документ Правила и методика испытаний.
Разработка части Программа испытаний формализована и достаточна проста. Достаточно идти по пунктам РД50 и просто описывать в формате регламента.
Методики испытаний сложнее и многогранее -)
Метаний с ними много бывает. Согласования также выводят нас на кривую дорожку излишней детализации.
Схему о которой пойдет речь, я придумал не сразу, а пришел к ней постепенно. Аналогичное не встречал, посему решил задокументировать.
Итак...
Главная цель данной методы - сократить трудозатраты, объем описания и уложить ПМ в общую канву ТРП.
Начинаем.
Делим раздел "Методика испытаний" на 2-а блока.
Обеспечение в проекте требований ТЗ
Включает в себя ссылку на Приложение к П2 которое прилагается для раскрытия информации по разделу "Сведения по обеспечению заданных в ТЗ х-ках ..."
Само приложение - это таблица в которой приводится требование ТЗ (по разделу 4 этого ТЗ), графа "Отметка об исполнении" и графа с описанием в формате ссылок на соотв разделы ТРП где документально описано как это реализовано.
То есть - одна таблица ссылок в одном документе.
Выполнение проверок работоспособности функций
Берем список требуемых к реализации функций - согласно П2 "Состав функций"
Для каждой функции
Таким образом сам ПМ превращается в отсылки к другим документам что значительно экономит нам время при правках документов с одной стороны, но позволяет разработать "солидный" документ при другой.
Все. ПМ получается увязанный со всеми документами начиная с ТЗ.
зы. пояснение. здесь не идет разговор о реальном тестировании систем, тест планах автоматизированном тестировании. Речь идет о документе ПМ по которому группа людей ака коммисия будет подтверждать что вы выполнили требования ТЗ.
Разработка части Программа испытаний формализована и достаточна проста. Достаточно идти по пунктам РД50 и просто описывать в формате регламента.
Методики испытаний сложнее и многогранее -)
Метаний с ними много бывает. Согласования также выводят нас на кривую дорожку излишней детализации.
Схему о которой пойдет речь, я придумал не сразу, а пришел к ней постепенно. Аналогичное не встречал, посему решил задокументировать.
Итак...
Главная цель данной методы - сократить трудозатраты, объем описания и уложить ПМ в общую канву ТРП.
Начинаем.
Делим раздел "Методика испытаний" на 2-а блока.
- Первый - Обеспечение в проекте требований ТЗ
- Второй - Выполнение проверок работоспособности функций
Обеспечение в проекте требований ТЗ
Включает в себя ссылку на Приложение к П2 которое прилагается для раскрытия информации по разделу "Сведения по обеспечению заданных в ТЗ х-ках ..."
Само приложение - это таблица в которой приводится требование ТЗ (по разделу 4 этого ТЗ), графа "Отметка об исполнении" и графа с описанием в формате ссылок на соотв разделы ТРП где документально описано как это реализовано.
То есть - одна таблица ссылок в одном документе.
Выполнение проверок работоспособности функций
Берем список требуемых к реализации функций - согласно П2 "Состав функций"
Для каждой функции
- описываем при необходимости входные параметры и получаемые результаты,
- даем ссылку на соотв раздел инструкции пользователя в которой описано как эту функцию делать. Или на список разделов если проверка более сложная
Таким образом сам ПМ превращается в отсылки к другим документам что значительно экономит нам время при правках документов с одной стороны, но позволяет разработать "солидный" документ при другой.
Все. ПМ получается увязанный со всеми документами начиная с ТЗ.
зы. пояснение. здесь не идет разговор о реальном тестировании систем, тест планах автоматизированном тестировании. Речь идет о документе ПМ по которому группа людей ака коммисия будет подтверждать что вы выполнили требования ТЗ.
Комментариев нет:
Отправить комментарий