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

Чем методика испытаний отличается от программы испытаний. Не касается программных средств по ГОСТ 19.101-77.

Когда речь идет об испытаниях, на первый взгляд может показаться, что методика испытаний и программа испытаний – это одно и то же. Однако, на самом деле это не так. Давайте разберемся в чем разница между методикой и программой испытаний.

Методика испытаний

Методика испытаний – это документ, который содержит описание методов и приемов проведения испытаний на определенное изделие с целью установления его характеристик и соответствия требованиям технических условий.

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

• Цель и задачи испытаний
• Объект испытаний
• Методы и средства измерений
• Критерии оценки результатов испытаний
• Порядок проведения испытаний и контроля за их проведением
• Методы обработки результатов испытаний
• Требования к оформлению результатов испытаний
• Сроки и место проведения испытаний

Программа испытаний

Программа испытаний – это документ, который содержит план проведения испытаний на определенное изделие в рамках методики испытаний. Она разрабатывается на основе методики испытаний и включает в себя следующие разделы:

• Объем и условия проведения испытаний
• График проведения испытаний
• Общие требования к материалам, оборудованию и персоналу, задействованным в проведении испытаний
• Общие требования к организации и проведению испытаний
• Обеспечение безопасности при проведении испытаний
• Требования к оформлению результатов испытаний
• Сроки и место проведения испытаний

В чем разница

Основная разница между методикой испытаний и программой испытаний заключается в том, что методика – это документ, который описывает методы и приемы проведения испытаний и содержит описание требований к изделию, а программа – это документ, который содержит план проведения испытаний на основе методики и содержит различные организационные и технические требования.

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

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

Разница между методикой и программой

Во многих контекстах термины «методика» и «программа» очень близки по смыслу. Но в большинстве случаев между ними наблюдается существенная разница. В чем она заключается?

Что представляет собой методика?

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

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

Что представляет собой программа?

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

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

Структура образовательных программ, к примеру, может отражать:

1. основные нюансы применения знаний с учетом достижений науки, техники (если речь идет, допустим, о естественно-научных предметах), социального и культурного развития государства (если речь идет о гуманитарных дисциплинах);
2. цели преподавания определенных видов знаний учащимся;
3. преемственность между разными типами преподаваемых материалов, последовательность передачи знаний учащимся;
4. в тех случаях, когда это необходимо, — связь преподаваемого предмета с другими дисциплинами.

Сравнение

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

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

Однако у методик и программ бывает и много общего. Так, в алгоритме программы может быть предусмотрено применение в определенной последовательности именно тех инструментов, что закреплены в той или иной методике. Кроме того, успешная реализация методики (например, связанной с преподаванием какой-либо темы в образовательном учреждении) может потребовать задействования определенной программы.

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

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

Разработка ПМИ регламентируется в РФ в первую очередь ГОСТ 19.301-79 данный документ содержит основные требования к методики написания ПМИ и ее оформлению.

ПМИ состоит из следующих разделов:

• Техническое описание объекта, продукции, установки. (Объект испытаний) В разделе «Объект испытаний» указывают наименование, область применения и обозначение испытуемой программы.
• Основная задача испытаний. (Цель испытаний) В разделе «Цель испытаний” должна быть указана цель проведения испытаний.
• Предъявляемые технические требования к оборудованию. (Требования к программе) В разделе ’Требования к программе» должны быть указаны требования, подлежащие проверке во время испытаний и заданные в техническом задании на программу.
• Требования к пакету документов на изделие. (Требования к программной документации) В разделе «Требования к программной документации» должны быть указаны состав программной документации, предъявляемой на испытания, а также специальные требования, если они заданы в техническом задании на программу.
• Материально техническая база для испытаний и порядок их проведения. (Средства и порядок испытаний) В разделе «Средства и порядок испытаний” должны быть указаны технические и программные средства, используемые во время испытаний, а также порядок проведения испытаний.
• Описание примеров испытаний. (Методы испытаний) В разделе «Методы испытаний” должны быть приведены описания используемых методов испытаний. Методы испытаний рекомендуется по отдельным показателям располагать в последователь­ности, в которой эти показатели расположены в разделах ’’Требования к программе” и «Требования к программной документации”. В методах испытаний должны быть приведены описания проверок с указанием результатов проведения испытаний (перечней тестовых примеров, контрольных распечаток тестовых примеров и т. п.).

После написания ПМИ и ее утверждения заказчиком для применения ее в приемо сдаточных испытаниях с привлечением специалистов Ростехнадзора необходимо заверить ее в Федеральном Агентстве (Ростехнадзоре).

Корпоративный троллинг — 3, или сдача работ без лишних забот

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

Сдача результатов работы является одним из самых драматических этапов проекта. Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены зря. Если сдача работ поручена вам, то ваша роль в команде весьма значительна, а доверие руководства велико, даже если начальники вам этого никогда не говорили. Облажаться на сдаче работ иногда означает конец вашей блистательной карьеры. Так что лучше этого не делать.

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

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

Направления троллинга в ходе испытаний

1. Формальная приемка. Тролль тыкает в ТЗ, где написано что-то вроде этого: «система должна иметь архитектуру клиент-сервер». Вам требуется показать, как пункт закрывается. А вы забыли включить в пояснительную записку к техпроекту строчку «Система имеет архитектуру клиент-сервер» или с перепугу не смогли ее найти. Потратьте время, прочешите все разделы ТЗ и найдите нужные строчки.
2. Ошибки в тестах. При формулировании тестов избегайте возможности намеренного неверного истолкования. Например, вы пишете, «Из списка пользователей Оператор выбирает любого пользователя». Тролль выберет из списка системного юзера или админа, под которыми тесты работать не будут. Или вы пишете «Отобразились свойства всех объектов». Тролль ткнет в тот объект, свойства которого не отобразились. А вы имели в виду «всех требуемых объектов», но поезд ушел, и вы получаете страшное замечание «Свойства всех объектов не отображаются».
3. «Крайне важные замечания». Когда пушки основного боя отгремели, начинается разбор замечаний на критические и не критические. Критические будут у вас костью в горле, они мешают подписанию акта. Поэтому тролль будет пытаться сделать каждое замечание критическим. Включается весь имеющийся пафос, привлекаются авторитетные товарищи, кивающие головами, и прочий цирк с конями.

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

Документ ПМИ, или программа и методика испытаний, на мой взгляд, более важен, чем даже ТЗ. От качества этого документа зависит половина, если не две третьих успеха испытаний.

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

Протокол испытаний

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

Протокол испытаний состоит из общей части, таблицы тестов и списка замечаний.

1. Сквозной номер (в удобном вам формате). Например, Номер_теста.Номер_шага.
2. Действия оператора. Что делает оператор, для того, чтобы получить результат. Убедитесь, что формулировки исключают злонамеренное неверное толкование.
3. Ожидаемый результат. Простыми словами описанный результат действий оператора, который можно проверить (пощупать, увидеть, унюхать). Например: «Зажглась зеленая лампочка на верхней панели», «В списке пользователей появился новый пользователь», «На экране отобразилось предупреждение системы о неверно введенном пароле», «В системном журнале X появилась запись Y». Убедитесь, что формулировки максимально конкретные и исключают злонамеренное неверное толкование. Помните также про слова, являющиеся кормовой базой для троллей: «любой», «каждый», «все», «никакие» и т.п.
4. Пункт документации (например, Руководства пользователя), в котором дано подробное описание выполняемых действий или закрывается нефункциональное требование ТЗ. Наличие этого пункта позволит убить сразу двух зайцев. Во-первых, вы задокументируете то, что все, что надо отражено в проектной документации. Во-вторых, вам не придется подробно расписывать действия оператора, так как (внимание!) к тестам допускаются сотрудники, соответствующие требованиям технического проекта, в которых вы написали, что они должны пройти такие-то курсы и быть знакомы с эксплуатационными документами.
5. Пункт или пункты ТЗ, закрываемые на данном шаге. Сумма по колонке должна дать все (именно все, а не только функциональные!) требования ТЗ. Именно поэтому в протоколе будут «тупые тесты» на проверку комплектности документации, на то, что программа написана на java и база данных Oracle DBMS является реляционной (тыкаем пальцем в соответствующий раздел документации).
6. Решение комиссии. Нужно настаивать на следующих решениях: «Пройдено», «Пройдено с замечаниями», «Не пройдено», «Не тестировалось». Других записей тут быть не должно. Запись «Не тестировалось» делается для тестов, проводить которые комиссия не захотела или провести их физически невозможно на момент проведения испытаний. Например, они решили не выдергивать узел кластера из розетки. Лучше, чтобы таких записей в протоколе не было, чтобы не появилась лишняя возможность для троллинга.
7. Комментарии. Если тест пройден с замечаниями, тут должен стоять номер замечания. Все замечания заносятся в приложение к протоколу в свободной форме. Можно указывать номер теста, в ходе выполнения которого возникли замечания. На большее вам банально не хватит времени. Если решение комиссии «Пройдено», постарайтесь ничего не писать в колонке «Комментарии»

Генеральная репетиция

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

Не бойтесь переписать ПМИ с нуля. Один раз мы пожалели время и перекомпоновали тесты вместо того, чтобы переписать их. В итоге мы просто успокоили сами себя, не изменив общей плачевной картины. За что и огребли.

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

Эффективный дуэт

Оптимальной командой для сдачи является пара из внедренца (или программиста) и бизнес-аналитика (консультанта).

• работает с системой, демонстрируя виртуозное владение интерфейсом
• отвечает на технические вопросы

• говорит о системе с заказчиком, ведет беседу
• отвечает на общие вопросы
• ведет протокол
• пинает под столом внедренца (программиста)

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

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

Не зря же западные «айтишные евангелисты» любят работать парами.

Процесс пошел!

Когда вы приступили к испытаниям, не смейте лезть в систему сразу! Постарайтесь пройти сначала всю формальную часть. Сверьте коды документации, носителей информации, откройте ТЗ, положите на стол Руководство пользователя. Пройдитесь по нефункциональным требованиям. ОС Windows — галочка. Поддерживаемые версии браузеров — раз, два, три, галочка. Язык разработки, архитектура, база данных, да мало ли что там в ТЗ понаписано! Все нужно показать в документации. Хотя бы там всего лишь одно предложение, оно обязано там быть! Не пренебрегайте этой бюрократией, тролли только этого и ждут. Вам хочется получить в протоколе, что «Исполнитель не продемонстрировал, что язык java является кроссплатформенным языком высокого уровня. Требования ТЗ 1.2.3 и 3.2.1 не выполнены»? А ведь это не придуманный маразм, это сама жизнь.

Когда вы закончили с формальной стороной дела, тоже не спешите лезть в систему! Следующая группа тестов заключается во включении монитора и демонстрации рабочего стола, иконок и запуска программы (если запуск нужно тестировать). Вход в систему с неправильным паролем, галочка, вход с правильным — опять галочка, галочка, галочка. Меню — эка невидаль! Главная форма, список чего-нибудь. Галочка.

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

Замечания

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

Когда заказчик делает замечание, вы фиксируете его формулировку в протоколе. Обязательно проговорите записанные слова, убедитесь, что вы друг друга поняли. Будет лучше, если в ходе испытаний будет работать диктофон. Постарайтесь сделать так, чтобы формулировка замечания была конструктивной, то есть, было понятно, что нужно сделать, чтобы замечание было снято. Слов «все», «ничего», «каждый», «любой», а также неизмеряемых качественных оценок «плохо», «медленно», «слишком быстро» и т.п. в замечании быть не должно! Если «система работает медленно», то должно быть написано «запрошенная форма должна отображаться в течении 5 сек». Если «символы на схеме плохо различимы», то должно быть написано «увеличить символы на схеме до 18 пунктов». И так далее.

Конкретизация позволит минимизировать возможность необоснованного перетаскивания того или иного замечания в ранг критического. Заказчик может утверждать, что отработка запроса за 6 секунд для него неприемлема, а за 5 секунд — в самый раз. Пусть это появится в протоколе! Но что-то мне подсказывает, что не появится. Или замечание будет признано некритическим.

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

Что делать, если все пропало

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

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

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

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

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

Заключение

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

UPD от 23.06.2011. Пользователь igendo добавляет в комментариях, что неплохо бы уже на этапе заключения договора утвердить формы официальных документов проекта.

Добавлю, что очень помогает в работе, когда формы актов, протоколов и прочих формальных документов зафиксированы в контракте. Дабы не было необходимости их предварительно согласовывать, пересогласовывать и переделывать\переподписывать в середине проекта.

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

Пользователь ЖЖ ryzhij_papa Добавляет, что существует практика ранжирования замечаний по степени их влияния на бизнес, методика ранжирования также заносится в ПМИ.

Нужно формально описать что является замечаниями крического, высокого, среднего и низкого приоритета. Описание делается в терминах бизнеса. Если утрировать, то так: критический приоритет при потере 1000$, высокий если 100$, средний когда сотрудники в мыле, но убытков у нас нет, низкий — возможны случаи легкого умопомрачения на 5-6 году жизни с такой багой.