Пример плана тестирования

Предисловие.

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

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

Пробуйте. Возможно вам этот тип документа окажется полезен. А может и нет.

Да еще. Размер и форма должны выбираться в зависимости от размера и типа проекта. Расширенная форма приведенная ниже неплохо подходит для проектов размером “десятки человеколет” - “несколько человековеков”. Для проекта поменьше я использовал форму “две страницы А4 цветными ручками в тетради”. Тоже хорошо работало. Не факт, что приведенный ниже документ использовался в реальном проекте. Но факт, что использовались похожие документы.
Термин “план” используется в значении близком к “стратегия”. Это не календарный график и не перечень тестовых примеров.


План тестирования системы

Версия 1.1

История исправлений

Дата    Версия    Описание    Автор
02.01.20хх    1.0    Создан
07.01.20хх    1.1    Подготовлен черновик

Содержание

1    Введение
1.1    Цель
1.2    Состав документа
1.3    Нотации, аббревиатуры и определения принятые в документе
1.4    Комплексные показатели качества по ГОСТ Р ИСО/МЭК 9126-93
1.5    Ссылки
2    Идентификация объектов тестирования
3    Стратегия тестирования
4    Виды проводимых тестов
4.1    Функциональное тестирование
4.2    Тестирование бизнес цикла
4.3    Конфигурационное тестирование
4.4    Тестирование производительности
4.5    Стресс тестирование
4.6    Юзабилити тестирование
4.7    Тестирование инсталляции
5    Требования к численности и квалификации персонала
5.1    Оценка объема работ
5.2    Распределение по ролям и квалификации
6    Необходимые ресурсы
6.1    Программные средства

1    Введение
1.1    Цель

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

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

1.3    Нотации, аббревиатуры и определения принятые в документе

TBD (To Be Defined) - будет определено в дальнейшем. Указывает, что данный раздел документа еще не разработан.

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

Описание дефекта - формализованное описание, составленное в той или иной системе учета дефектов. Дефект существует вне зависимости от того описали его или нет и от того нашли его или нет.

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

Контроль качества продукта  - более широкое определение, нежели тестирование, включающее в себя, в том числе тестирование. Так например просмотр кода, также называемый code review или статическим тестированием обеспечивает контроль такой метрики как “Сопровождаемость->Изменяемость” (в классификации ГОСТ 9126), но при этом  не используется прогон программы. Кроме, собственно, программы (исполняемого кода) контролю качества подвергаются другие конечные артефакты: руководство пользователя, руководство администратора, …
Также может контроль качества может применяться не к конечным, а рабочим артефактам (ЧТЗ, прототипы интерфейсов, …)

QA (Quality assurance) - работы по улучшению и поддержанию процессов, контролю соответствия процессам. Не имеют отношения к тестированию.

Метрика программного обеспечения (англ. software metric) - это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.

Конечный артефакт - самостоятельная часть продукта, передаваемая заказчику

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

Тестирование методом свободного поиска (exploratory testing) - также называется тестированием на основе сеансов. Не предполагает жестко заданных, формализованных сценариев тестирования. Часто, проводится в парах.

1.4    Комплексные показатели качества по ГОСТ Р ИСО/МЭК 9126-93
А.2.1 Функциональные возможности (Functionality)
А.2.1.1 Пригодность (Suitability)
Атрибут программного обеспечения, относящийся к наличию и соответствию набора функций конкретным задачам.
Примечание - Примерами соответствия является состав функций, ориентированных на задачу, из входящих в него подфункций и объемы таблиц.

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

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

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

А.2.1.5 Защищенность (Security)
Атрибуты программного обеспечения, относящиеся к его способности предотвращать несанкционированный доступ, случайный или преднамеренный, к программам и данным.

А.2.2 Надежность (Reliability)
А.2.2.1 Стабильность (Maturity)
Атрибуты программного обеспечения, относящиеся к частоте отказов при ошибках в программном обеспечении.

А.2.2.2 Устойчивость к ошибке (Fault tolerance)
Атрибуты программного обеспечения, относящиеся к его способности поддерживать определенный уровень качества функционирования в случаях программных ошибок или нарушения определенного интерфейса.
Примечание - Определенный уровень качества функционирования включает возможность отказобезопасности.

А.2.2.3 Восстанавливаемость (Recoverability)
Атрибуты программного обеспечения, относящиеся к его возможности восстанавливать уровень качества функционирования и восстанавливать данные, непосредственно поврежденные в случае отказа, а также к времени и усилиям, необходимым для этого.

А.2.3 Практичность (Usability)

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

А.2.3.2 Обучаемость (Learnability)
Атрибуты программного обеспечения, относящиеся к усилиям пользователя по обучению его применению (например оперативному управлению, вводу, выводу).

А.2.3.3 Простота использования (Operability)
Атрибуты программного обеспечения, относящиеся к усилиям пользователя но эксплуатации и оперативному управлению.

А.2.4 Эффективность (Efficiency)

А.2.4.1 Характер изменения во времени (Time behavior)
Атрибуты программного обеспечения, относящиеся к временам отклика и обработки и к скоростям выполнения его функций.

А.2.4.2 Характер изменения ресурсов (Resource behavior)
Атрибуты программного обеспечения, относящиеся к объему используемых ресурсов и продолжительности такого использования при выполнении функции.

А.2.5 Сопровождаемость (Maintainability)

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

А.2.5.2 Изменяемость (Changeability)
Атрибуты программного обеспечения, относящиеся к усилиям, необходимым для модификации, устранению отказа или для изменения условий эксплуатации.

А.2.5.3 Устойчивость (Stability)
Атрибуты программного обеспечения, относящиеся к риску от непредвиденных эффектов модификации.

А.2.5.4 Тестируемость (Testability)
Атрибуты программного обеспечения, относящиеся к усилиям, необходимым для проверки модифицированного программного обеспечения.
Примечание - Значения этой подхарактеристики могут быть изменены рассматриваемыми модификациями.

А.2.6 Мобильность (Portability)

А.2.6.1 Адаптируемость (Adaptability)
Атрибуты программного обеспечения, относящиеся к удобству его адаптации к различным конкретным условиям эксплуатации, без применения других действий или способов, кроме тех, что предназначены для этого в рассматриваемом программное обеспечении.

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

А.2.6.3 Соответствие (Conformance)
Атрибуты программного обеспечения, которые заставляют программу подчиняться стандартам или соглашениям, относящимся к мобильности.

А.2.6.4 Взаимозаменяемость (Replaceabilily)
Атрибуты программного обеспечения, относящиеся к простоте и трудоемкости его применения вместо другого конкретного программного средства в среде этого средства.
Примечания

  1. Взаимозаменяемость используется вместо совместимости для того, чтобы избежать возможной путаницы со способностью к взаимодействию (см. А.2.1.3).
  2. Взаимозаменяемость с конкретным программным средством не предполагает, что данное средство заменимо рассматриваемым программным средством.
  3. Взаимозаменяемость может включать атрибуты простоты внедрения и адаптируемости. Понятие было введено в качестве отдельной подхарактеристики из-за его важности.

1.5    Ссылки
[1]    Рекомендации по конфигурационному управлению в части инстансов (стендов)
[2]    Описание стендов (аппаратная и программная части, сетевые адреса, протоколы, адреса, логины и пароли).
[3]    ГОСТ 9126

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

Так в частности, должно быть проведено тестирование:

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

3    Стратегия тестирования

Текущий подход к контролю качества подразумевает следующие вехи проекта:
Подсистема готова к демонстрации заказчику
Подсистема готова к промышленной эксплуатации

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

tre1.PNG

Для проверки готовности прототипа служат приемо-сдаточные испытания. Критерий готовности - акт сдачи прототипа подписанный приемо-сдаточной комиссией. Приемо-сдаточные испытания описываются в отдельном документе. Либо как раздел шесть частного технического задания, согласно ГОСТ 34.602-89, либо в отдельном документе содержащем программу и методику испытаний.

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

4    Виды проводимых тестов
4.1    Функциональное тестирование
Используется для контроля качества “Функциональных возможностей” в части “Пригодности”, “Правильности” и “Способности к взаимодействию”.
Функциональное тестирование является основным видом тестирования. Проводится вручную через интерфейс пользователя. Использование средств автоматизации в 20хх году не предполагается.
При подготовке прототипа рекомендуется использовать тестирование методом свободного поиска (exploratory testing).
При подготовке системы (подсистемы) к промышленной эксплуатации рекомендуется использовать стандартное промышленное тестирование, с оценкой полноты тестового покрытия.

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

4.3    Конфигурационное тестирование
Используется для контроля качества “Мобильности” в части “Адаптируемости”
Должна быть проверена работоспособность приложения для:

Различных видов ОС:

  • WinXP - обязательно
  • Vista - обязательно
  • Win7 - обязательно

Различных БД:

  • MSSQL 2000
  • MSSQL 2005

Различных разрешениях монитора рабочего места

  • 1280х1024 - обязательно
  • 1600х900 - обязательно
  • 1024х768 - желательно
  • 1680х1050 - желательно

Может проводиться как выделенный вид тестирования методом визуального контроля при выполнении юзкейсов классов read и list.
Рекомендованный метод - объединение с функциональным тестированием. В этом случае на каждом рабочем месте тестировщика рекомендуется установка своей конфигурации.

4.4    Тестирование производительности
Используется для контроля качества “Эффективности”.
Для первичного анализа производительности серверной части используется ручное тестирование. Для оценки пригодности системы к промышленной эксплуатации на реальных объемах данных с заданным числом пользователей используется автоматизированное тестирование.
Для  анализа поведения пользовательского интерфейса на реальных объемах данных используется ручное тестирование.

4.5    Стресс тестирование
Используется для контроля качества “Надежности” в части “Стабильности” и “Устойчивости к ошибке”.

4.6    Юзабилити тестирование
Используется для контроля качества “Практичности” в части “Понятности”, “Обучаемости”, “Простоты использования”.

4.7    Тестирование инсталляции
Используется для контроля качества “Мобильности” в части “Простоты внедрения”.
Проводится вручную.
5    Требования к численности и квалификации персонала
5.1    Оценка объема работ
Существует несколько способов оценок трудозатрат на тестирование. Проведем оценку по числу программистов
Для системы такого класса нормальным считается что 20-25% от трудоемкости проекта приходится на тестирование. Расчеты показывают, что трудоемкость проекта порядка   300 человеколет. Следовательно трудоемкость тестирования 60-75 человеколет. Учитывая неравномерность поглощаемой трудоемкости тестирования в зависимости от фазы проекта и целевой показатель создания системы в три года, в пике на проекте должно быть ___ тестировщиков.

5.2    Распределение по ролям и квалификации
tre.PNG

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

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

6    Необходимые ресурсы
Рекомендации к тестовому и прочим стендам описаны в [1]. В разное время, в зависимости от потребностей, могут существовать одновременно несколько тестовых стендов.
Так для тестирования:

  • переносимости и инсталляции - рекомендуется использовать стенд с изоляцией на уровне сети,
  • производительности  - стенд, с характеристиками, максимально близкими к промышленной среде
  • проблем заказчика - должен быть стенд класса “Образ заказчика”.

Описание стендов и прав доступа можно найти в [2]
6.1    Программные средства

Управление тестированием   TrackStudio
Трекинг дефектов    TrackStudio
Управление проектом    TBD
Работа с BD    TBD
Профилирование работы сети    TBD
Профилирование работы сервера приложений    TBD

Один комментарий

  1. Выпуск 10: Стратегия тестирования - Radio QA написал:

    […] Пример плана тестирования […]

Оставьте комментарий

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