Программа и методика испытаний
Программа и методика испытаний – это документ, входящий в комплект конструкторской документации, составляемой на автоматизированную систему или программу на стадии разработки. Программа методики испытаний призвана установить технические данные, которые подлежат проверке во время испытаний всей системы в целом или ее отдельных компонентов. Этим документом устанавливается порядок опытов и способы контроля их результатов.
Какие проверки входят в программу и методику испытаний?
Согласно руководящему документу РД 50-34.698-90, в этом документе перечисляются все проверки, призванные установить эффективность проектных решений, выявить причины отказов или сбоев, определить качество проведенных работ, проверить соответствие АСУ технике безопасности, а также устанавливается продолжительность всех опытов, их режим и прочее.
Программа и методика испытаний содержит перечень необходимых проверок, проводимых во время испытаний. К таким проверкам обычно относится:
Проверка соответствия техзаданию; Проверка комплектности системы; Проверка комплектности и качества документации; Установление достаточности, комплектности и качества программной поддержки и документации на нее; Установление квалификации обслуживающих работников; Проверка соответствия системы требованиям функционального назначения; Установление пригодности системы к контролю; Выявление нарушений техники безопасности, санитарии, эргономики; Проверка взаимодействия системы с другими программными средствами.
Оформление
Согласно государственному стандарту ГОСТ 19.301-79, документ «программа и методика испытаний» оформляется в соответствии с ГОСТ 19.105-78 (общими требованиями к оформлению программных документов) и должен содержать следующие разделы:
Объект испытаний, с указанием наименования, области применения, обозначения АСУ. Цель испытаний, с указанием конкретных данных, которые должны быть получены по результатам опытов. Требования к программе. Содержит перечень требований, которые заданы тех заданием и должны быть проверены опытным путем. Требования к программным документам, с перечислением состава документов и особых требований на испытания системы, установленных ТЗ. Средства и порядок испытаний, с указанием технических и программных средств, использующихся для проведения испытаний, и порядка опытов. Методы испытаний. Описание применяемой методологии, с перечнем данных, которые должны быть получены во время проведения испытаний. Приложения. Программы и методики испытаний могут содержать дополнительные материалы – графики, таблицы, тестовые примеры и их контрольные распечатки.
Согласно ГОСТ 19.301-79, информационную часть – аннотацию, содержание и прочее – на такой документ, как программа и методика испытаний, можно не оформлять.
Наша компания оказывает услуги по разработке любой конструкторской документации на программные продукты и автоматизированные системы управления. С нами процедура составления и согласования этих сложных документов пройдет быстро и просто.
У нас работают профессионалы, которые прекрасно разбираются во всех аспектах создания, проектирования и тестирования АСУ, а также обладают всеми необходимыми навыками для оформления программ и методик испытаний, а также любых других документов, сопутствующих разработке программных продуктов.
Оформите заявку и задавайте все интересующие вас вопросы по телефону +7(499)755-74-33 e-mail Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. или через форму заказа.
Шаблон программы и методик испытаний по ГОСТ 34
Структура и содержание документа
Требования к структуре программы и методик испытаний по ГОСТ 34 устанавливаются РД 50-34.698-90. В общем случае документ должен состоять из следующих разделов:
1 Объект испытаний
1.1 Полное наименование системы, обозначение
1.2 Комплектность испытательной системы
2 Цель испытаний
3 Общие положения
3.1 Перечень руководящих документов, на основании которых проводят испытания
3.2 Место и продолжительность испытаний
3.3 Организации, участвующие в испытаниях
3.4 Перечень ранее проведенных испытаний
3.5 Перечень предъявляемых на испытания документов, откорректированных по результатам ранее проведенных испытаний
4 Объем испытаний
4.1 Перечень этапов испытаний и проверок, а также количественные и качественные характеристики, подлежащие оценке
4.2 Последовательность проведения и режима испытаний
4.3 Требования по испытаниям программных средств
4.4 Перечень работ, проводимых после завершения испытаний, требования к ним, объем и порядок проведения
5 Условия и порядок проведения испытаний
5.1 Условия проведения испытаний
5.2 Условия начала и завершения отдельных этапов испытаний
5.3 Имеющиеся ограничения в условиях проведения испытаний
5.4 Требования к техническому обслуживанию системы
5.5 Меры, обеспечивающие безопасность и безаварийность проведения испытаний
5.6 Порядок взаимодействия организаций, участвующих в испытаниях
5.7 Порядок привлечения экспертов для исследования возможных повреждений в процессе проведения испытаний
5.8 Требования к персоналу, проводящему испытания, и порядок его допуска к испытаниям
6 Материально-техническое обеспечение испытаний
7 Метрологическое обеспечение испытаний
8 Отчетность
Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы.
Содержание документов, разрабатываемых на предпроектных стадиях по ГОСТ 34.601, и организационно-распорядительных определяют разработчики в зависимости от объема информации, необходимой и достаточной для дальнейшего использования документов.
Примечание
Оформление документа
Документ выполняют на формах, установленных соответствующими стандартами Единой системы конструкторской документации (ЕСКД).
Для размещения утверждающих и согласующих подписей к документу рекомендуется составлять титульный лист и (или) лист утверждения.
Текст документа при необходимости разделяют на разделы и подразделы. Разделы, подразделы должны иметь заголовки. Пункты, как правило, заголовков не имеют. Заголовки должны четко и кратко отражать содержание разделов, подразделов.
Текст документа должен быть кратким, четким и не допускать различных толкований.
Как правильно написать методику испытаний
Единая система программной документации
ПРОГРАММА И МЕТОДИКА ИСПЫТАНИЙ
Требования к содержанию и оформлению
Unified system for program documentation. Program and methods of testing. Requirements for contents and form of presentation
Дата введения 1981-01-01
Постановлением Государственного комитета CCCР по стандартам от 11 декабря 1979 г. N 4753 дата введения установлена 01.01.81
ИЗДАНИЕ (январь 2010 г.) с Изменениями N 1, 2, утвержденными в феврале 1982 г., июне 1983 г. (ИУС 5-82, 9-83).
Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа «Программа и методика испытаний», определенного ГОСТ 19.101-77.
Стандарт полностью соответствует СТ СЭВ 3747-82*.
(Измененная редакция, Изм. N 1, 2).
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Структура и оформление документа устанавливаются в соответствии с ГОСТ 19.105-78.
Составление информационной части (аннотации и содержания) является необязательным.
1.2. Документ «Программа и методика испытаний» должен содержать следующие разделы:
требования к программе;
требования к программной документации;
средства и порядок испытаний;
В зависимости от особенностей документа допускается вводить дополнительные разделы.
(Измененная редакция, Изм. N 1, 2).
2. СОДЕРЖАНИЕ РАЗДЕЛОВ
2.1. В разделе «Объект испытаний» указывают наименование, область применения и обозначение испытуемой программы.
2.2. В разделе «Цель испытаний» должна быть указана цель проведения испытаний.
2.3. В разделе «Требования к программе» должны быть указаны требования, подлежащие проверке во время испытаний и заданные в техническом задании на программу.
2.4. В разделе «Требования к программной документации» должны быть указаны состав программной документации, предъявляемой на испытания, а также специальные требования, если они заданы в техническом задании на программу.
2.3, 2.4. (Измененная редакция, Изм. N 2).
2.5, 2.6. (Исключены, Изм. N 2).
2.7. В разделе «Средства и порядок испытаний» должны быть указаны технические и программные средства, используемые во время испытаний, а также порядок проведения испытаний.
2.8. В разделе «Методы испытаний» должны быть приведены описания используемых методов испытаний. Методы испытаний рекомендуется по отдельным показателям располагать в последовательности, в которой эти показатели расположены в разделах «Требования к программе» и «Требования к программной документации».
В методах испытаний должны быть приведены описания проверок с указанием результатов проведения испытаний (перечней тестовых примеров, контрольных распечаток тестовых примеров и т.п.).
2.7, 2.8. (Измененная редакция, Изм. N 2).
2.9. В приложение к документу могут быть включены тестовые примеры, контрольные распечатки тестовых примеров, таблицы, графики и т.п.
Электронный текст документа подготовлен
АО «Кодекс» и сверен по:
Единая система программной документации:
Кто должен разрабатывать программу и методику испытаний
Программа и методика испытаний – разновидность технической документации, составляемой в определенной форме и содержащей установленные разделы информации, предназначенной для дальнейшего использования. Испытания проводятся для различных групп продукции, изделий и конструкций, включая товары, предназначенные для поставки конечным потребителям, технику и оборудование, используемое на предприятиях в различных отраслях. В некоторых случаях данные о методике испытаний дополнительно указывают в технических условиях, которые также представлены отдельным видом документа.
Кто разрабатывает программу и методику испытаний при работе с различными объектами
Программа и методика испытаний разрабатывается и составляется группой лиц в составе комиссии, в которую входят профильные специалисты предприятия, технические руководители (главный инженер), непосредственный руководитель предприятия, привлеченные эксперты, специалисты службы технического контроля. Программа составляется и утверждается в установленном виде, с надлежащим оформлением соответствующих информативных разделов, с последующей поэтапной проверкой документа, с подписями ответственных лиц и печатью.
Программа испытаний в соответствии с законодательно установленными требованиями должна содержать следующие разделы данных:
Привлечение к работе специалистов соответствующего профиля, а также соблюдение правил проведения испытаний позволяет получать необходимые результаты в сжатые сроки и следовать нормам, утвержденным на законодательном уровне.
Корпоративный троллинг — 3, или сдача работ без лишних забот
В предыдущих статьях (первая, вторая) мы бегло и в шутливой форме прошлись по примерам противодействия, которое оказывают нам сотрудники заказчика на различных этапах проекта. Сегодня предметом рассмотрения будет сдача работ, и мы подойдем к этому этапу во всеоружии, чтобы ни один тролль не прорвался. Получилось много букв, но, надеюсь оно того стоит.
Сдача результатов работы является одним из самых драматических этапов проекта. Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены зря. Если сдача работ поручена вам, то ваша роль в команде весьма значительна, а доверие руководства велико, даже если начальники вам этого никогда не говорили. Облажаться на сдаче работ иногда означает конец вашей блистательной карьеры. Так что лучше этого не делать.
Процесс приемо-сдаточных испытаний должен быть строго формализован. Всем понятно, что в конце этого процесса должен появиться протокол и акт, на основании которого выпускается приказ о переводе системы в опытную или промышленную эксплуатацию. Акт также является формальным поводом для выставления счета на оплату очередного этапа проекта.
В этой статье я без лишних шуток (какие уж тут шутки!) и максимально последовательно (ну, для блога, конечно) опишу процесс сдачи проектных работ. Разумеется, многие вещи опытным коллегам покажутся очевидными. Пусть. Зато менее опытные коллеги или желающие примерить ответственную роль сдающего на себя найдут эту публикацию полезной и познавательной.
Направления троллинга в ходе испытаний
Программа и методика испытаний
Документ ПМИ, или программа и методика испытаний, на мой взгляд, более важен, чем даже ТЗ. От качества этого документа зависит половина, если не две третьих успеха испытаний.
Протокол испытаний
На основе тестов ПМИ вы должны подготовить протокол испытаний. Протокол будет являться документом, подтверждающим то, что ваша система выполнена в соответствии с ТЗ, о чем делается соответствующая запись в акте. Не доверяйте подготовку протокола никому другому, если не хотите иметь бледный вид перед комиссией. Обычно протокол является «копипастом» из ПМИ, так что его подготовка много времени у вас не займет.
Протокол испытаний состоит из общей части, таблицы тестов и списка замечаний.
Генеральная репетиция
Без нее нельзя. Только так вы можете отловить все шероховатости в тестах, выявить тесты, крадущие время и тесты, результаты которых сомнительны. Помните, что визуальная составляющая должна быть безупречна. Постарайтесь забить в систему данные, которые выглядят натурально и похожи на то, с чем имеет дело клиент. Проследите, чтобы имена пользователей и другие поля не содержали ненормативную лексику (любимая шутка внедренцев и программеров). Эти «шуточки» иногда действуют на комиссию как красная тряпка на быка.
Не бойтесь переписать ПМИ с нуля. Один раз мы пожалели время и перекомпоновали тесты вместо того, чтобы переписать их. В итоге мы просто успокоили сами себя, не изменив общей плачевной картины. За что и огребли.
Если вы сдаете вдвоем, гоняйте тесты вместе. Приглашайте коллег, пусть они придираются, изображая из себя комиссию. Потраченное на эти игры время в итоге позволит всем вам получить деньги от довольного заказчика.
Эффективный дуэт
Оптимальной командой для сдачи является пара из внедренца (или программиста) и бизнес-аналитика (консультанта).
Точно так же, если консультант скажет глупость, а заказчик нахмурится в ответ, программист может с лицом оскорбленной невинности продемонстрировать очередную фишку системы и тогда заказчик проникнется к нему симпатией, так как поймет, кто тут настоящий профи, а кто клоун в галстуке.
В особенно напряженные моменты можно устроить дружескую перепалку, разрядив тем самым обстановку и отведя внимание аудитории от не совсем корректной работы системы.
Не зря же западные «айтишные евангелисты» любят работать парами.
Процесс пошел!
Когда вы приступили к испытаниям, не смейте лезть в систему сразу! Постарайтесь пройти сначала всю формальную часть. Сверьте коды документации, носителей информации, откройте ТЗ, положите на стол Руководство пользователя. Пройдитесь по нефункциональным требованиям. ОС Windows — галочка. Поддерживаемые версии браузеров — раз, два, три, галочка. Язык разработки, архитектура, база данных, да мало ли что там в ТЗ понаписано! Все нужно показать в документации. Хотя бы там всего лишь одно предложение, оно обязано там быть! Не пренебрегайте этой бюрократией, тролли только этого и ждут. Вам хочется получить в протоколе, что «Исполнитель не продемонстрировал, что язык java является кроссплатформенным языком высокого уровня. Требования ТЗ 1.2.3 и 3.2.1 не выполнены»? А ведь это не придуманный маразм, это сама жизнь.
Когда вы закончили с формальной стороной дела, тоже не спешите лезть в систему! Следующая группа тестов заключается во включении монитора и демонстрации рабочего стола, иконок и запуска программы (если запуск нужно тестировать). Вход в систему с неправильным паролем, галочка, вход с правильным — опять галочка, галочка, галочка. Меню — эка невидаль! Главная форма, список чего-нибудь. Галочка.
Когда дойдет дело до нажатия кнопок в системе, комиссия уже порядком устанет и проголодается. А вы в первый день сможете проскочить, к примеру, основные справочники и базовые функции. А на другой день оставить бекапирование, администрирование и еще какую-нибудь ерунду.
Замечания
Они будут, можете не сомневаться. Нет такой системы, к которой не было бы замечаний. Ваша задача — заставить заказчика поделить все замечания на критические и не критические. Первые должны быть исправлены для успешного перевода в опытную эксплуатацию. Вторые могут быть исправлены в ходе опытной эксплуатации. Соответственно, лучше, чтобы первых вообще не было или были только те, исправить которые не представляет особого труда.
Когда заказчик делает замечание, вы фиксируете его формулировку в протоколе. Обязательно проговорите записанные слова, убедитесь, что вы друг друга поняли. Будет лучше, если в ходе испытаний будет работать диктофон. Постарайтесь сделать так, чтобы формулировка замечания была конструктивной, то есть, было понятно, что нужно сделать, чтобы замечание было снято. Слов «все», «ничего», «каждый», «любой», а также неизмеряемых качественных оценок «плохо», «медленно», «слишком быстро» и т.п. в замечании быть не должно! Если «система работает медленно», то должно быть написано «запрошенная форма должна отображаться в течении 5 сек». Если «символы на схеме плохо различимы», то должно быть написано «увеличить символы на схеме до 18 пунктов». И так далее.
Конкретизация позволит минимизировать возможность необоснованного перетаскивания того или иного замечания в ранг критического. Заказчик может утверждать, что отработка запроса за 6 секунд для него неприемлема, а за 5 секунд — в самый раз. Пусть это появится в протоколе! Но что-то мне подсказывает, что не появится. Или замечание будет признано некритическим.
Все замечания, признанные критическим фиксируются в акте: «Комиссия постановила, что система соответствует ТЗ и рекомендует принять ее в опытную эксплуатацию при условиях отработки следующих замечаний. » При этом список некритических замечаний лучше непосредственно в акт не включать. Их обычно много и они могут напугать ответственного сотрудника, ставящего подпись. Если заказчик беспокоится, что вы не будете отрабатывать некритические замечания, успокойте его при помощи документа «Методика проведения опытной эксплуатации», котрый настоятельно рекомендуется подготовить. Там вы в простой и доступной форме должны описать как будет проходить опытная эксплуатация, как будут отрабатываться найденные баги и как будет заполняться журнал опытной эксплуатации, являющийся гарантом безболезненного окончания ОЭ, ввода системы в промышленную эксплуатацию и салюта с шампанским по причине окончания проекта.
Что делать, если все пропало
Когда вы понимаете, что испытания идут неудовлетворительно, система безобразно глючит, а заказчик уже исчерпал запас ругательств, не нужно сдаваться! Караван должен продолжать идти вперед, будет новый релиз, новые испытания. И даже если проект будет завален, ничего в этом страшного для вас нет. В условиях острого дефицита толковых исполнителей вы быстро найдете работу, тем более, что я бы на вашем месте не стал бы работать в компании, допускающей подобные ситуации.
Чтобы не терять время в бесплотных препирательствах, я бы рекомендовал применить тактику «бей своих, чтобы чужие боялись». Начните вместе с заказчиком ругать «этих криворуких программеров», «жадное руководство», а когда накал страстей уменьшится, предложите заказчику собрать максимум багов «этого глюкалова», чтобы показать этим нехорошим людям какие они нехорошие.
Тогда активные сотрудники заказчика во главе с троллем-киллером начнут собирать баги и радостно наполнять протокол сотнями замечаний. Фактически, за свои собственные деньги они проведут вам высокоуровневое функциональное тестирование, на которое, судя по результатам испытаний, ваши разработчики так и не сподобились.
По хорошему, описанной безобразной ситуации вообще быть не должно. Но проектный бизнес отличается иногда странными флуктуациями, когда первый прототип пытаются сдать как полноценную систему, начальство врет подчиненным и самим себе, все вокруг делают хорошую мину при плохой игре и уверяют друг друга в обязательном и непременном успехе.
Вторым советом в подобной ситуации было бы, как я уже говорил, сразу уволиться из конторы, допускающей подобные «косяки». Потому что по всем меркам настоящему профессионалу не стоит портить свою репутацию подобным образом.
Заключение
Итак, коллеги, на этом я спешу завершить трилогию о корпоративных троллях, которых не нужно бояться, а нужно уважать и даже некоторым образом любить, так как они не дают ленивым обезьянам ИТ бизнеса падать от обжорства с деревьев, держат нас в тонусе и даже привносят некоторый интерес в безумно скучные, но крайне необходимые проектные работы.
UPD от 23.06.2011. Пользователь igendo добавляет в комментариях, что неплохо бы уже на этапе заключения договора утвердить формы официальных документов проекта.
Добавлю, что очень помогает в работе, когда формы актов, протоколов и прочих формальных документов зафиксированы в контракте. Дабы не было необходимости их предварительно согласовывать, пересогласовывать и переделывать\переподписывать в середине проекта.
От себя тоже могу добавить, что в совсем уж тяжелых и масштабных проектах принято составлять устав проекта, некий документ о глубинном смысле которого можно говорить часами. Там, кроме всего прочего, можно обговорить и формы документов проекта, и процедуры контроля хода проекта, и высокоуровневые бизнес-задачи. Но это, опять же, тема для другого поста.
Пользователь ЖЖ ryzhij_papa Добавляет, что существует практика ранжирования замечаний по степени их влияния на бизнес, методика ранжирования также заносится в ПМИ.
Нужно формально описать что является замечаниями крического, высокого, среднего и низкого приоритета. Описание делается в терминах бизнеса. Если утрировать, то так: критический приоритет при потере 1000$, высокий если 100$, средний когда сотрудники в мыле, но убытков у нас нет, низкий — возможны случаи легкого умопомрачения на 5-6 году жизни с такой багой.