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

Файл «Программа и методика предварительных испытаний» внутри архива находится в следующих папках: Разработка рекомендаций по проведению испытаний системы защиты информационной системы, Приложения. Документ из архива «Разработка рекомендаций по проведению испытаний системы защиты информационной системы», который расположен в категории » «. Всё это находится в предмете «дипломы и вкр» из 8 семестр, которые можно найти в файловом архиве ДВГУПС. Не смотря на прямую связь этого архива с ДВГУПС, его также можно найти и в других разделах. .

Онлайн просмотр документа «Программа и методика предварительных испытаний»

Текст из документа «Программа и методика предварительных испытаний»

СОГЛАСОВАНО (должность руководителя организации) _________________ (И.О.Фамилия) м.п. «___»_____________ 2017 г. УТВЕРЖДАЮ (Заместитель руководителя
органа по аттестации) ______________ (И.О.Фамилия) м.п. «___»_____________ 2017 г.

Приемочная документация. Какую документацию готовит тестировщик? Программа и методика испытаний.

ПРОГРАММА И МЕТОДИКА ПРЕДВАРИТЕЛЬНЫХ ИСПЫТАНИЙ
СИСТЕМЫ ЗАЩИТЫ ИНФОРМАЦИИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

1 Общие положения

• проверка работоспособности подсистем средств защиты информации от НСД, целостности применяемых средств защиты информации от НСД;
• проверка программной совместимости и корректности функционирования всего комплекса используемых СВТ с продукцией, используемой в целях защиты информации;
• испытания системы защиты информации от НСД путем попыток осуществить НСД к тестовой защищаемой информации в обход используемой системы защиты информации.

Проверка и испытания комплекса функций защиты информации от НСД проводятся для программно-технической среды ИС в целом.

2 Программа предварительных испытаний

Предварительные испытания СЗ проводятся в соответствии с программой, включающей испытание подсистем средств защиты информации от НСД, таких как:

• подсистема управления доступом;
• подсистема регистрации и учета;
• подсистема обеспечения целостности.

Результаты проведения испытаний СЗ и заключение о возможности (невозможности) приемки СЗ в опытную эксплуатацию отражаются в протоколе предварительных испытаний, включающем:

• перечень необходимых доработок и рекомендуемые сроки их выполнения;
• заключение о возможности (невозможности) приемки СЗ в опытную эксплуатацию.

3 Методика предварительных испытаний

Методики проведения испытаний средств защиты информации от НСД приведены в таблице 1.

Таблица 1 – Методики проведения испытаний

Методика проведения испытания

1. Подсистема управления доступом

1.1. Подсистема идентификации и аутентификации субъектов доступа

1.1.1. Проверка наличия и работоспособности подсистемы идентификации

Проверяют правильность идентификации субъектов доступа путем обращения субъектов доступа ИС к объектам доступа при помощи штатных средств.

«Разработка ТЗ по ГОСТ 34» – Кристина Стец | SoftTeco PM/BA Talks

При обращении должна проводиться проверка принадлежности предъявленного субъектом идентификатора множеству всех зарегистрированных в ИС идентификаторов.

Если субъект доступа предъявляет идентификатор, не известный подсистеме идентификации, то средства управления должны прекращать процесс предоставления доступа.

1.1.2. Проверка наличия и надежности подсистемы аутентификации

Проверяют правильность аутентификации субъекта доступа.

Если субъект доступа предъявляет пароль, не соответствующий идентификатору субъекта, то средства управления должны прекращать процесс предоставления доступа.

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

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

Продолжение таблицы 1

Методика проведения испытания

1.1.3. Проверка средств загрузки операционной системы ИС в обход подсистемы идентификации и аутентификации

Для проведения испытаний необходим загрузочный CD или USB-накопитель.

Осуществляются попытки загрузки операционной системы с загрузочного CD и USB-накопителя.

Настройки СЗИ от НСД ИС должна обеспечить блокировку загрузки операционной системы с устройств, не предусмотренных технологией инициализации ИС.

1.1.4. Проверка времени действия пароля

На ЭВМ производят перевод системного времени вперед, при этом не превышая установленного политикой безопасности времени действия пароля. Затем осуществляют попытку входа пользователя в систему.

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

На ЭВМ производят перевод системного времени вперед на интервал, больший установленного политикой безопасности времени действия пароля. Затем осуществляют попытку входа пользователя в систему.

Подсистема идентификации и аутентификации должна блокировать вход пользователя в систему.

После проведения испытаний на ЭВМ устанавливают текущее время.

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

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

Проверка считается успешной, если подсистема контроля доступа отказала субъекту в замене пароля.

Право установки минимальной размерности пароля должно предоставляться администратору ИС.

1.2. Проверка подсистемы идентификации объектов доступа

Продолжение таблицы 1

Методика проведения испытания

1.2.1. Проверка идентификации аппаратурных объектов доступа

Идентификация внешних устройств ЭВМ должна осуществляться по одному из ниже перечисленных типов идентификаторов:

• по логическим адресам (номерам);
• по логическим именам;
• по логическим именам и (или) адресам;
• по физическим адресам (номерам);
• по уникальным встроенным устройствам.

Основными средствами проверки являются средства операционной системы и средства контроля защищенности ИС от НСД (наименование средства). С их помощью производится определение периферийных устройств ЭВМ (принтеров, НЖМД, приводов CD-ROM), доступных для пользователя.

Проверка считается успешной, если во время работы со средствами операционной системы и со средствами контроля защищенности ИС от НСД (наименование средства) не выявлены неизвестные (неидентифицированные) объекты доступа.

1.2.2. Проверка идентификации информационных объектов доступа

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

Основными средствами проверки являются средства контроля защищенности ИС от НСД (наименование средства).

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

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

1.3. Проверка подсистемы управления потоками информации

1.3.1. Проверяется настройка СЗИ от НСД в части назначения объектам меток, соответствующих степеням секретности ресурсов

С использованием штатных средств операционной системы производятся попытки переноса информации на носитель с другим грифом секретности (уровнем конфиденциальности).

Проверка считается успешной, если СЗИ от НСД запретила операцию копирования.

Продолжение таблицы 1

Методика проведения испытания

2. Подсистема регистрации и учета

Для проведения испытаний необходимы:

• программа фиксации и контроля исходного состояния (наименование программы);
• программа поиска информации на дисках (наименование программы).

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

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

2.1. Проверка регистрации начала и окончания работ

Проверка осуществляется штатными средствами ИС.

Проводится загрузка операционной системы и запуск программных комплексов ИС, предусмотренных технологией инициализации ИС.

Осуществляются попытки входа в систему по неверному идентификатору доступа, по верному идентификатору доступа и неверному паролю, по идентификатору и паролю легитимного субъекта доступа.

Производится программный останов ИС.

Производится загрузка операционной системы, запуск программных комплексов ИС, предусмотренных технологией инициализации ИС, вход в систему с правами администратора защиты и исследование журнала регистрации доступа.

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

• дату и время входа (выхода) субъекта доступа в систему (из системы) или загрузки (останова) системы;
• результат попытки входа: успешная или неуспешная – несанкционированная;
• идентификатор субъекта, предъявленный при попытке доступа.

Продолжение таблицы 1

Методика проведения испытания

2.2. Проверка регистрации выдачи документов на «твердую» копию

В соответствии с принятой в ИС технологией проводится выдача произвольного документа на «твердую» копию.

В соответствии с принятой в ИС технологией проводится выдача документа иной степени секретности (уровня конфиденциальности) на «твердую» копию . Во время операции вывода документа на «твердую» копию проводится принудительное отключение электропитания устройства выдачи и выполняются действия, предусмотренные документацией ИС для внештатных ситуаций.

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

Выдача документов сопровождается автоматической маркировкой каждого листа (страницы) документа его последовательным номером и учетными реквизитами ИС с указанием на последнем листе документа общего количества листов (страниц).

Продолжение таблицы 1

Методика проведения испытания

2.3. Проверка регистрации использования программных средств

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

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

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

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

• дату и время запуска;
• имя (идентификатор) программы (процесса, задания);
• идентификатор субъекта доступа, запросившего программу (процесс);

результат запуска (успешный, неуспешный – несанкционированный).

Продолжение таблицы 1

Методика проведения испытания

2.4. Проверка регистрации доступа программных средств к защищаемым файлам

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

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

• задают неверные параметры обработки;
• задают в качестве объекта обработки несуществующий файл;
• задают в качестве объекта обработки файл, доступ к которому закрыт подсистемой разграничения доступа.

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

• дату и время попытки доступа к защищаемому файлу с указанием ее результата: успешная, неуспешная – несанкционированная;
• идентификатор субъекта доступа;

спецификацию защищаемого файла.

Продолжение таблицы 1

Методика проведения испытания

2.5. Проверка регистрации доступа программных средств к дополнительным защищаемым объектам доступа

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

• внешние устройства ЭВМ;
• программы;
• тома, каталоги, файлы;
• записи, поля записей.

В соответствии с принятой в ИС технологией производится запуск программ, алгоритм работы которых предусматривает обращение к объектам, входящим в список объектов испытания.

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

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

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

• дату и время попытки доступа к защищаемому объекту с указанием ее результата: успешная, неуспешная – несанкционированная;
• идентификатор субъекта доступа;

спецификацию защищаемого объекта [логическое имя (номер)].

Продолжение таблицы 1

Методика проведения испытания

2.6. Проверка автоматического учета создания новых объектов доступа

Субъект доступа, имеющий полномочия администратора защиты, создает новые объекты доступа, предусмотренные политикой безопасности ИС. В качестве новых объектов доступа рассматриваются файлы защищаемой информации.

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

Проверка считается успешной:

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

2.7. Проверка очистки освобождаемых областей памяти. Проверка очистки внешней памяти при ее освобождении (перераспределении)

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

Проверка считается успешной:

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

Окончание таблицы 1

Методика проведения испытания

3. Подсистема обеспечения целостности

3.1. Проверка средств контроля целостности программных компонентов СЗИ от НСД

Перед проведением проверки штатными средствами ИС осуществляется резервное копирование программных компонентов СЗИ от НСД.

Производится моделирование несанкционированных действий по нарушению целостности программных компонентов СЗИ от НСД. Производится удаление, либо переименование определенных программных модулей СЗИ от НСД.

Производится перезагрузка системы. По завершении инициализации СЗИ от НСД анализируется реакция средств подсистемы обеспечения целостности.

Проверка считается успешной, если СЗИ от НСД зафиксировали изменения в составе программных компонентов.

Источник: studizba.com

Корпоративный троллинг — 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 году жизни с такой багой.

Источник: habr.com

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

Целью проведения испытаний является выявление несоответствий возможностей интернет-магазина требованиям технического задания, проверка работоспособности интернет-магазина.

Требования к программе

Предусмотрена возможность ввода данных

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

Клиент может просматривать информацию о товарах, производителях на страницах сайта

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

Средства и порядок испытаний

Приёмочные испытания проводятся на программно-аппаратном комплексе Заказчика в следующей минимальной конфигурации:

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

ПК: AMD Sempron 2800 mhz, 1024 RAM, AMD HD Graphics 128.

операционная система: MS Windows 7 SP 1;

программы: Google Chrome 24, Mozilla Firefox 19, Opera 12.0, Internet Explorer 9.

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

Создание пользователя — модератора

Таблица 1 — Последовательность действий при создании пользователя

Войти в администраторскую часть сайта по адресу: http://fungas54.ru/administrator/

На экране отобразится иерархический список разделов и действий.

Перейти в раздел управления пользователями, (site > пользователи)

На экране появится список пользователей и их личная информация. Справа сверху — меню функций

Выбрать функцию «Добавить пользователя». (Новый)

На экране появится форма для добавления нового пользователя:

роль (выбор из списка)

кнопка «добавить пользователя»

Заполнить поля, нажать кнопку «Добавить пользователя».

В правой части экрана появится сообщение о результате операции, в левой части экрана обновится форма с информацией о пользователе.

Открыть новое окно браузера и перейти в администраторскую часть.

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

Ввести логин и пароль. Нажать кнопку «ОК».

На e-mail пользователя будет автоматически отправлено письмо о регистрации на портале

Рис 1 — Список пользователей

Создание пользователя — клиента

Таблица 2 — Последовательность действий при создании пользователя

Войти на главную страницу сайта по адресу: http://fungas54.ru/

На экране отобразится главная страница

Нажать кнопку регистрации под формой входа

На экране появится форма для добавления нового пользователя:

Заполнить поля. Нажать кнопку регистрация

На экране появится главная страница и надпись «Теперь вы можете войти».

На E-mail пользователя будет автоматически отправлено письмо о регистрации на портале.

Рис 2 -Регистрация пользователя

Создание и удаление нового материала

Таблица 3 — Последовательность действий при создании/удалении нового материала

Войти в администраторскую часть сайта по адресу: http://fungas54.ru/administrator/

На экране отобразится список действий и список разделов в иерархическом порядке

Материал > Менеджер материалов

На экране отобразится список материалов. Справа сверху отобразится функционал раздела

Нажать кнопку меню «Новый»

На экране отобразится форма с полем для ввода информации материала.

Выбрать в списке раздел, в котором необходимо создать новый материал. Выбрать раздел «Статьи».

Ввести название материала, информацию в форму.

Нажать кнопку «Сохранить»

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

Открыть новое окно браузера и перейти на открытую часть сайта.

Отобразится главная страница сайта.

В левом меню щёлкнуть курсором мыши на раздел «Статьи».

Осуществится переход, и отобразиться страница, относящаяся к разделу «Статьи». В списке материалов мы можем увидеть созданный нами материал.

В верхней правой части экрана появится список доступных действий.

В списке доступных действий щёлкнуть курсором мыши на иконке «Удалить».

В правой части экрана появится сообщение о результате операции, в левой части экрана обновится иерархический список объектов. Заведённый ранее раздел не будет отображён в списке разделов.

Перейти в браузер с открытой частью сайта. Открыть главную страницу сайта.

Откроется главная страница сайта.

В левой части экрана в меню щелкнуть на разделе «Статьи».

Откроется раздел «Статьи». В списке статей не будет только что удаленного материала.

Рис.3 — Создание материала

Создание, удаление, редактирование товарной позиции

Таблица 4. Последовательность действий при создании, редактировании, публикации и удалении и добавления в новой товарной позиции

Войти в администраторскую часть сайта по адресу: http://fungas54.ru/administrator/

В левой части экрана отобразиться список разделов в иерархическом порядке и список действий.

Выбрать в окне навигатора «Компоненты»> «Virtuemart»>

Отобразится интерфейс администратора интернет магазина

Выбрать пункт меню «Товары»

Отобразится список товаров

Нажать кнопку «Новый»

Отобразится форма ввода информации о товаре: Артикул, название, категория, цена, габариты и вес, изображение товара

Заполнить обязательные поля информации о товаре и нажать кнопку «Сохранить»

На экране отобразится статус обработки функции. Если информация введена верно, то мы увидим карточку товара и извещение о создании.

Выбрать в окне навигатора «Компоненты»> «Virtuemart»>

Отобразится интерфейс администратора интернет магазина

Выбрать пункт меню «Товары»

Отобразится список товаров

Нажать на товар, который мы хотим отредактировать

Отобразится форма ввода информации о товаре: Артикул, название, категория, цена, габариты и вес, изображение товара.

Изменяем нужные поля информации о товаре и нажимаем кнопку «Сохранить»

На экране отобразится статус обработки функции. Если информация введена верно, то мы увидим карточку товара и извещение об изменении.

Выбрать в окне навигатора «Компоненты»> «Virtuemart»>

Отобразится интерфейс администратора интернет магазина

Выбрать пункт меню «Товары»

Отобразится список товаров

Нажимаем на чекбокс товара, который мы хотим удалить

Нажимаем кнопку удалить справ сверху

На экране отобразится предупреждение об удалении

Нажимаем кнопку «ОК»

Отобразиться информация, что товар с данным ID был удален

Рис.4 — Создание товарной позиции

Добавление и удаление изображения

Таблица 5 — Последовательность действий добавлении и удалении изображения

Войти в администраторскую часть сайта по адресу http://fungas54.ru/administrator/

На экране отразится список действий и список разделов в иерархическом порядке

На экране отобразится список материалов. Справа сверху отобразится функционал раздела

Нажать на материал, в который мы хотим добавить изображение

На экране отобразится форма с полем для ввода информации материала.

На панели сверху нажимаем кнопку «вставить изменить изображение»

Всплывает форма с полями для ввода URL, описания и заголовка изображения

Вставляем URL изображения, заполняем поля информации, нажимаем кнопку «ВСТАВИТЬ»

Форма с информацией об изображении пропадает, открывая перед нами форму материала с картинкой.

Нажимаем кнопку «Сохранить» в верхнем правом углу.

На экране вновь отображается список материалов и оповещение «Successfully saved article»

Войти в администраторскую часть сайта по адресу http://fungas54.ru/administrator/

На экране отобразится список действий и список разделов в иерархическом порядке

Материал > Менеджер материалов

На экране отобразится список материалов. Справа сверху отобразится функционал раздела

Нажать на материал, в котором мы хотим удалить изображение

На экране отобразится форма с полем для ввода информации материала.

Выделяем изображение и нажимаем кнопку delete

Войти в администраторскую часть сайта по адресу http://fungas54.ru/administrator/

На экране отобразится список действий и список разделов в иерархическом порядке

Материал > Менеджер материалов

На экране отобразится список материалов. Справа сверху отобразится функционал раздела

Нажать на материал, в котором мы хотим редактировать изображение

На экране отобразится форма с полем для ввода информации материала.

Выделяем изображение и на панели сверху нажимаем кнопку «вставитьизменить изображение»

Всплывает форма с полями для ввода URL, описания и заголовка изображения

Редактируем нужные поля, разрешение изображения, стиль обтекания, нажимаем кнопку «Обновить»

Форма с информацией об изображении пропадает, открывая перед нами форму материала с измененной картинкой.

Нажимаем кнопку «Сохранить» в верхнем правом углу.

На экране отображается список материалов и оповещение «Successfully saved article»

Источник: studbooks.net