Application Review

Once we receive your application, we’ll verify that you meet the eligibility criteria and that your experience and/or education is valid and consistent with the guidelines stated in the certification handbook.

For each certification, a specified percentage of applications are randomly selected for audit. PMI conducts application audits to confirm the experience and/or education documented on certification applications. The purpose of the audit is to enhance the credibility of the certification program and of the certification holders. Read Frequently Asked Questions about the application audit process.

Program Management Professional (PgMP) and Portfolio Management Professional (PfMP) applications include an additional step of panel review. Once we have completed the initial review, a panel of PMI certification holders will evaluate your experience summaries to confirm your qualification.

Сертификация PRINCE2

Существует еще одна популярная международная система сертификации менеджеров проектов, которая не относится ни к одной из вышеперечисленных школ – PRINCE2. Это метод, который был разработан в конце 1980-х гг. в правительстве Великобритании как способ управления проектами информатизации. Со временем этот метод перешел на новый качественный уровень и стал универсальным, применимым для проектов любого типа. Метод используется на правительственном уровне практически во всех странах Евросоюза для реализации важных масштабных проектов. В качестве примера можно привести недавно реализованный проект реконструкции морского порта в г. Роттердам (Нидерланды). PRINCE2 — это официальный метод реализации всех проектов ООН, очень похожий метод используется в Еврокомиссии.

Руководство Managing successful projects with PRINCE2 — это инструкция к действию, которая описывает три вещи:

• Принципы управления проектами

• Инструменты управления проектами

• Последовательность действий при управлении проектами

На сегодняшний день этот метод является наиболее популярным в сфере управления проектами благодаря своей практичности и возможности адаптации для крупных и небольших проектов. Всего в мире насчитывается 1 500 000 сертифицированных специалистов по PRINCE2. Система сертификации включает три уровня:

• PRINCE2 Foundation. Сертификат этого уровня подтверждает, что специалист знает содержание руководства по PRINCE2 и правильно понимает все профессиональные термины. Экзамен длится 1 час, включает 75 вопросов, для получения сертификата необходимо правильно ответить на 50% вопросов. Стоимость сертификации составляет 12 000 рублей.

• PRINCE2 Practitioner. Сертификат этого уровня подтверждает, что специалист знает содержание руководства и умеет адаптировать метод к своему проекту. Данный экзамен сложнее, поскольку проверяет не знание книги, а умение применить знания в конкретной ситуации. Кандидат получает кейс и отвечает на 80 вопросов по этому кейсу. Чтобы получить сертификат, он должен правильно ответить на 55% вопросов за 2,5 часа. Стоимость сертификации составляет 16 000 рублей.

• PRINCE2 Professional. Самый продвинутый уровень сертификации, пока недоступный в России. Сертификат этого уровня подтверждает, что специалист не только знает и умеет применять метод на практике, но и способен внедрить метод в той или иной организации. Чтобы получить сертификат, кандидат должен пройти трехдневную экзаменационную сессию в асессмент-центре, в том числе личное собеседование с асессорами.

Пример вопроса из сертификации PRINCE2 Practitioner

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

Является ли это надлежащим применением PRINCE2 в этом проекте?

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

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

C

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

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

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

Сертификации в управлении проектами

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

Project Management Professional (PMP)

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

Certified Associate in Project Management (CAPM)

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

Program Management Professional (PgMP)

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

• PMI-SP (PMI Scheduling Professional)
• PMI-RMP (PMI Risk Management Professional), специалист по управлению рисками;
• PMI-ACP (PMI Agile Certified Practitioner), специалист по «гибким» методам управления проектами.

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

Аудит провален, читайте handbook перед тем, как подавать заявку

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

Подтверждение тренингов

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

К стати о тренингах, у меня уже было достаточно контактных часов, полученных за счет обучения, оплаченного работодателем. Позже в процессе подготовки я открыл источник дешевых контактных часов в виде тренингов на Udemy пример. 35 часов за 10 USD вполне неплохо. Главное — внимательно прочитать аннотацию тренинга и убедиться, что он предоставляется провайдером, аккредитованным PMI (Registered Education Provider или REP).

Подтверждение основного образования

Чуть сложнее. здесь нужно приложить копию диплома и вкладыша (transcript) и простой (не нотариальный) перевод диплома и вкладыша.

Подтверждение опыта

Здесь самое важное — внимательно, очень внимательно читать PMP Handbook, документ, описывающий требования к кандидату PMP и правила оформления заявки.
Проект, которым Вы руководили или в котором Вы участвовали может понизить температуру земли на два градуса и остановить таяние ледников, избавить мир от голода и неизлечимых болезней, наконец, просто принести хорошую выручку Вашему работодателю и пользу клиентам.пафос> Эти проблемы не интересуют PMI. PMI интересует, чтобы Ваш опыт работы в каждом проекте был описан в терминах и процессах PMI

К сожалению, я недостаточно хорошо прочитал PMP Handbook и допустил достаточно распространенную ошибку: описал опыт проектной работы с точки зрения ценности, приобретенной компанией и клиентами

Как оказалось, PMI не проводит аудит заявки до тех пор, пока не получит пакет документов. Форма подтверждения аудита по каждому проекту генерируется автоматически в личном кабинете на сайте PMI. Форму нужно скачать, подписать у указанного в заявке контактного лица, которое может подтвердить Ваш опыт (например, директора работодателя или клиента или Вашего непосредственного руководителя). Описание опыта в форме подтверждения копируется из заявки.
В моем случае, из заявки было скопировано некорректное описание опыта. PMI в первый раз проверило информацию о моем опыте только получив пакет документов. Опыт был описан некорректно, и PMI отклонило мою заявку.
Кстати, дешевле всего оказалось отправить документы с помощью службы EMS. Отправка из Москвы стоила около 1700 рублей. Пакет шел до адресата около 10 дней, 2 дня от точки входа в США до PMI обычной американской почтой и 8 дней по России экспресс-почтой EMS.

Т.е. опыт нужно описывать опыт стандартными терминами, указывающими на указывающими на группы процессов PMI.

PMI уведомляет о положительном решении о заявке вот таким

Очень надеюсь, что мой опыт окажется полезен будущим кандидатам PMP. Желаю, чтобы ваши заявки принимались без аудита. И еще раз: внимательно, очень внимательно читайте PMP Handbook перед тем как подавать заявку.

Как сдавал

Центр тестирования. Экзамен принимают в центре тестирования Прометрик (Prometric), в Москве он находится на Ленинском проспекте, дом 2 у метро «Октябрьская». На момент написания статьи сдавать можно было по вторникам и четвергам 2 раза в день — утром и после обеда. Я выбрал утреннее время во вторник, т.к. в начале недели и с утра у меня голова свежее и сил больше.

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

Что нового. По сравнению с экзаменом 2005 года появились новшества:

— Теперь во время просмотра учебника (Tutorial) — а это лишних 15 минут времени — нельзя записывать формулы и что-либо из головы на бумагу. На бумаге разрешают писать только во время экзамена, когда тикает таймер. В 2005 году я выписал формулы и таблицу с процессами, которые боялся забыть под давлением времени. Теперь нельзя это сделать до начала экзамена. — Появилась удобная возможность вычеркивать варианты ответов. Если сразу видишь неверный ответ, вычеркиваешь его, и он больше не отвлекает. — Еще удобно сделали выделение нужного вам текста цветом, как маркером. В вопросах часто много лишней информации. Теперь можно взять и выделить цветом только тот текст, что имеет отношение к сути вопроса. — Русский вариант вопросов и ответов, если заказать экзамен с его поддержкой, будет отображаться в верхней части экрана. Это не очень удобно, особенно для длинных вопросов — появляется 2 независимые полосы прокрутки справа экрана. Качество перевода не очень хорошее, его можно использовать для страховки, но желательно не использовать для основного чтения и ответов на вопросы.

Экзамен длится 4 часа. Мне едва хватило: я ответил на все вопросы за 3,5 часа, а оставшиеся 30 минут просматривал отмеченные вопросы. Я помечал много вопросов, т.к. из общей массы в 200 вопросов я был полностью уверен в ответе лишь где-то на 20. В остальных сомневался — из четырех вариантов ответа два-три часто выглядят верными. Все помеченные вопросы я просмотреть не успел, но при повторном просмотре некоторые ответы изменил.

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

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

Наконец, появляется значок ожидания, идет подсчет результатов экзамена. Через 10-15 секунд, за которые вы успеваете несколько раз изменить мнение о своих способностях, наконец, появляется экран с финальным результатом. За 4 с лишним часа непрерывного сидения у монитора я был уже не в состоянии что-то читать, но увидел заветное слово «Pass» и успокоился.

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

Роли в тестировании (roles)

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

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

Tags:

View the discussion thread.

blog comments powered by DISQUS

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

TestLink

Сайт: testlink.org
Язык разработки: PHPРадует: встроенные требования и отслеживание их через кейсы; разнообразные текстовые отчеты; возможность добавить пользовательские поля; гибкая настройка ролей пользователей; интеграция с багтрекерами (JIRA, YouTrack, GitLab, Bugzilla и др.); тестлид может дополнительно установить срочность (urgency) для каждого кейса в тестране, что повлияет на порядок выполнения кейсов; управление списком тестируемых платформ; инвентарный список хостов (мелочь, но приятно); HTML-редактор с возможностью вставлять картинки, ссылки, таблицы, списки; по-моему, самый популярный Open Source инструмент со множеством инструкций и статей по настройке и использованию; наличие ресурса разработки на языке PHP позволяет изменить продукт под свои потребности (если стандартных функций покажется недостаточно или они окажутся не такими удобными).Не радует: интерфейс, требующий небольшого привыкания; придется повозиться с настройкой некоторых компонентов для полноценной работы (точечная настройка конфигурационных файлов, отправка почты, интеграция с багтрекером); в текстовых окнах HTML-редактора не работает стандартная проверка орфографии браузера; нельзя редактировать системные поля и порядок их отображения на форме кейса; ручная смена порядка шагов (приходится вводить цифры, вместо перетаскивания); назначение кейсов для тестрана (билда) после платных инструментов покажется неудобным.

Когда и кто?

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

Тем не менее, все разработчики сходятся во мнении, что тестирование программного продукта с точки зрения классификации по целям должно делиться на два класса:

• Функциональное тестирование
• Нефункциональное тестирование

Планирование тестов

Первый вопрос, который встает перед нами: «Сколько нужно тестов». Ответ, который часто дается: тестов должно быть столько, чтобы не осталось неоттестированных участков. Можно даже ввести формальное правило:

Код с не оттестированными участками не может быть опубликован

Проблема в том, что хотя неоттестированный код почти наверняка неработоспособен, но полное покрытие не гарантирует работоспособности. Написание тестов исходя только из уже существующего кода только для того, чтобы иметь стопроцентное покрытие кода тестами — порочная практика. Такой подход со всей неизбежностью приведет к существованию оттестированного, но неработоспособного кода. Кроме того, метод белового ящика, как правило, приводит к созданию позитивных тестов. А ошибки, как правило, находятся негативными тестами. В тестировании вопрос «Как я могу сломать?» гораздо эффективней вопроса «Как я могу подтвердить правильность?». Это наглядно демонстрирует статья 61 тест, который потряс программу.

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

Пример такого подхода можно посмотреть в статье Тривиальная задача.

Один из эффективных инструментов, для определения полноты тестового набора — матрица покрытия.

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

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

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

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

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

Последнюю проверку полноты тестового набора следует проводить с помощью формальной метрики «Code Coverage». Она показывает неполноту тестового набора. И дальнейшие тесты можно писать на основании анализа неоттестированных участков.

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

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

Например:
1. Запустить ярлык Database Control на рабочем столе.

2. Ввести с клавиатуры имя пользователя system и пароль пользователя system и нажать кнопку Login.

3. Перейти на закладку Administration.

4. В разделе Storage выбрать Redo Log Groups.

5. Зафиксировать в колонке «Результат испытания» в «Журнале испытаний» количество групп журнальных файлов, определяемое количеством строк в таблице раздела Redo Log Groups.

qTest Manager

Сайт: tricentis.com
Разработчик: Tricentis (приобрела QASymphony в 2018)
Цена: от $99 за юзера / месяц (цена приблизительна и зависит от количества пользователей)Радует: настройка системных и добавление пользовательских полей к различным объектам (с возможностью предпросмотра этого объекта и даже изменения цвета для статуса прогона); информативная история изменения кейса; встроенный HTML-редактор в текстовых полях кейса; комментирование отдельного кейса; можно подписаться на отдельный кейс и получать уведомления на почту об изменениях; интересная реализация авто-версионирования кейса (с мажорной и минорной составляющей); функция быстрого прогона кейса (без выставления статуса каждому шагу); встроенные требования с привязкой кейсов и указанием целевой сборки, также имеется встроенный багтрекинг; переиспользуемые кейсы; настраиваемые конфигурации тестранов; широкие возможности по интеграции как с багтрекерами, так и CI/CD сервисами; API для еще более гибкого взаимодействия; хранимые запросы поиска по кейсам, требованиям и т.д.; разнообразные отчеты; гибкая настройка на стороне администратора (пользователи, уведомления, права, группы и т.д.); встроенный проект со всеми данными для ознакомления с возможностями продукта; планы тестирования.Не радует: нет печатных форм кейсов; экспорт кейсов только в Excel формате (но зато он имеет читаемый вид); немного неудобный просмотр картинок в шагах кейса при прогоне; на сайте нет информации о цене продукта (нужно делать отдельный запрос) и она внушительная.

Приоритеты в тестировании

Почему «позитивное» тестирование считается на порядок более важным, чем «негативное»?

Предположим, что система не слишком устойчива к «плохим» вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить «подводные камни», не будут делать «опасные» или «неразрешённые» действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа «ни в коем случае не оставляйте это поле пустым, а то …».

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

Именно поэтому «позитивное» тестирование гораздо, гораздо важнее «негативного».

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

Нужна ли тестировщику база в ИТ?

Откровенно скажем, желательна.
Большинство наших специалистов в той или иной форме увлекались ИТ с детства или как минимум учились в профильных вузах, т.е. уже имели какую-то базовую подготовку еще до прихода в тестирование. Часть из них начинали как разработчики (учились на разработчика) — отдельные “тестовые” направления еще лет 10 назад отсутствовали. Так что у нас перед глазами просто нет “антипримера” такого пути.
Сейчас в ИТ действительно много тех, кто такую подготовку не проходил. И им немного сложнее двигаться вперед. Чтобы справиться с задачами в тестировании, необходимо как минимум уметь поставить операционку, понимать, как развернуть тестовое приложение и необходимое окружение, как создать репозиторий в Git, погуглить ответы на свои вопросы, покопаться на специализированных ресурсах вроде Stackoverflow. По сути это и обеспечивает общая база по информатике.
Но и эти знания вполне можно освоить по книгам или курсам в интернете. Сегодня недостатка в источниках информации нет. Главное, чтобы была заинтересованность и время, которое можно на это выделить.

Где взять первый опыт?

Настоящий опыт тестирования можно получить только на работе в реальном проекте. Чем больше кода вы напишете собственными руками, тем эффективнее вы будете решать следующие задачи, потому что прочитанная теория без практики быстро забывается.
В реальном проекте обучение пойдет гораздо эффективнее. Будут возникать конкретные проблемы, их решения можно искать в Google или на форумах. Путь, проложенный самостоятельно, в будущем сильно поможет. Естественно, путь этот стоит прокладывать не с нуля — поэтому мы выше и рассказывали о том, где стоит искать начальные знания.
Вместе с общей базой любой проект даст определенную степень специализации. Может быть, это будет тестирование продуктов под разные операционные системы, клиент-серверные приложения или инструменты для серверов. Все это потребует своих сопутствующих умений.
Ценно, когда на этом пути вас сопровождают коллеги

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

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

Пакет документов для разработки Программы и методики

Требования к оформлению и содержанию этих документов регламентируются ГОСТ 13.301-79.

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

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

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

Требование технического задания

Приводятся требования из технического задания (с указанием пункта) подлежащие проверке.

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

Например:
4.2. Система должна протоколировать все события, связанные с изменением своего информационного наполнения.

4.2. Система должна иметь возможность в случае сбоя в работе восстанавливать свое состояние, используя ранее запротоколированные изменения данных.

Деятельность/Задачи тестирования (Testing Activities)

Рассмотрим более подробно существующие активности/задачи связанные с тестированием:

• Планирование тестов (Plan Test)
  • Определение требований к тестам (identify requirements for test)
  • Оценка рисков (assess risk)
  • Разработка стратегии тестирования (develop test strategy)
  • Определение ресурсов (identify test resources)
  • Создание расписания/последовательностей (create schedule)
  • Разработка Плана тестирования (generate Test Plan)
• Дизайн тестов (Design Test)
  • Анализ объёма работ (prepare workload analysis)
  • Определение и описание тестовых случаев (identify and describe test cases)
  • Определение и структурирование тестовых процедур (identify and structure test procedures)
  • Обзор и оценка тестового покрытия (review and assess test coverage)
• Разработка тестов (Implement Test)
  • Запись или программирование тестовых скриптов (record or program test scripts)
  • Определение тесто-критичной функциональности в Дизайне и Модели реализации (identify test-specific functionality in the Design and Implementation Model)
  • Создание/подготовка внешних наборов данных (establish external data sets)
• Выполнение тестов (Execute Test)
  • Выполнение тестовых процедур (execute Test procedures)
  • Оценка выполнения тестов (evaluate execution of Test)
  • Восстановление после сбойных тестов (recover from halted Test)
  • Проверка результатов (verify the results)
  • Исследование неожиданных результатов (investigate unexpected results)
  • Запись ошибок (log defects)
• Оценка тестов (Evaluate Test)
  • Оценка покрытия тестовыми случаями (evaluate Test-case coverage)
  • Оценка покрытия кода (evaluate code coverage)
  • Анализ дефектов (analyze defects)
  • Определение критериев завершения и успешности тестирования (determine if Test Completion Criteria and Success Criteria have been achieved

Процесс тестирования

Этот процесс можно описать следующими шагами:

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

В первом и втором пункте описан процесс, который называется «позитивным» тестированием. «Позитивное» тестирование — это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению тестируемой системы.

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

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

Информационный словарь дает достаточно четкое определение термина «дымовое тестирование»:

• рудиментарная форма тестирования программного продукта после изменения его конфигурации либо после изменения его (программного продукта) самого. В процессе дымового тестирования тестировщик проверяет ПО на наличие «дыма», т.е. ищет какие-либо критические ошибки программы;
• первый запуск программы после её критического изменения или «сборки».

Функциональное тестирование

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

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

Для проведения функционального тестирования персоналом отдела технического контроля разрабатывается документ программа и методика испытаний функционала приложения (ПМИ). Документ ПМИ содержит перечень сценариев тестирования программного продукта (test cases) с подробным описанием шагов. Каждый шаг сценария тестирования характеризуется действиями пользователя (специалиста по тестированию) и ожидаемыми результатами – ответной реакции программы на эти действия. Программа и методика испытаний обязана имитировать эксплуатацию программного продукта в реальном режиме. Это означает, что сценарий тестирования должен быть построен на основе анализа операций, которые будут выполнять будущие пользователи системы, а не быть искусственно составленной последовательностью понятных только разработчику манипуляций.

Обычно, функциональное тестирование проводится на двух уровнях:

• Компонентное (модульное) тестирование. Тестирование отдельных компонентов программного продукта, сфокусированное на их специфике, назначении и функциональных особенностях.
• Интеграционное тестирование. Данный вид тестирования проводится после компонентного тестирования и направлен на выявление дефектов взаимодействия различных подсистем на уровне потоков управления и обмена данными.

Материально-техническое обеспечение испытаний

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

Например:
Для проведения испытаний необходимо провести следующие работы:
— Силами Заказчика обеспечить доступ к Системе с рабочих мест пользователей.
— Силами Исполнителя провести установку необходимого программного обеспечения на рабочие места пользователей и администраторов Системы.
— Силами Исполнителя создать в проектной зоне рабочую папку (\\DWH\) и предоставить к ней полный доступ участникам испытаний.
Испытания проводятся на компьютерах Заказчика. К конфигурации компьютеров предъявляются следующие минимальной требования:
CPU: 1 Intel;
RAM: 512 Mb;
HDD: 80Gb;
Network Card: 1 Mb/s;
ОС: MS Windows 2000/XP;
ПО: MS Internet Explorer ver. 6.0;
MS Office ver. 2003.

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

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

В программе подробно прописываются:

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

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