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

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

Роль Описание

(Test Manager, Test Project Manager)


Производит управленческий контроль (management oversight)

Ответственность:

  • Обеспечивает техническое направление
  • Получает необходимые ресурсы
  • Обеспечивает управленческую отчётность

(Test Designer)

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

Ответственность:

  • Разрабатывает план тестирования
  • Разрабатывает модель тестирования
  • Оценивает эффективность тестирования

(Tester)

Выполняет тесты

Ответственность:

  • Выполняет тесты
  • Фиксирует результаты
  • Восстанавливает тесты и систему после сбоев
  • Документирует запросы на изменение

Администратор тестовой системы, приложений поддерживающих жизненный цикл тестирования

(Test System Administrator)

Обеспечивает управление и поддержку тестовых окружений и данных

Ответственность:

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

(Database Administrator, Database Manager)

Обеспечивает управление и поддержку тестовых данных (баз данных)

Ответственность:

Администрирует тестовые данные (базы данных)

(Designer)

Устанавливает и определяет операции, атрибуты и связи тестовых классов

Ответственность:

  • Устанавливает и определяет тестовые классы
  • Устанавливает и определяет тестовые наборы (пакеты)

Разрабатывает юнит тесты (unit tests), тестовые классы и тестовые наборы (пакеты)

Ответственность:

Создаёт тестовые классы, собирает тестовые пакеты и интегрирует их с тестовую модел

 

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


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

Tags:

View the discussion thread. blog comments powered by DISQUS

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

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

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

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

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

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

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.

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

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

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

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

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


С этим читают