ALMELN.ru

Хранилище текстов, отзывов и закладок о тестировании, обеспечении качества и литературе

View the Project on GitHub

Определение приоритета тестов

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

  1. Понятие тестовой стратегии.
  2. Определение приоритета тестов.
  3. Тестовое покрытие (покрытие требований, покрытие кода).
  4. Метрики эффективности процесса тестирования.
  5. Тест смета, тест прогноз.

В “Сертифицированный тестировщик Программа обучения Базового уровня” International Software Testing Qualifications Board указано на необходимость уметь написать график проведения тестирования для данного набора тестовых сценариев, согласно приоритетам, технической и логической зависимости. В «Сертифицированный тестировщик Программа обучения Продвинутого уровня» International Software Testing Qualifications Board указано на необходимость привести примеры выбора различных вариантов тестирования, определения приоритетов тестирования и распределения усилий.

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

«Lessons Learned in Software Testing: A Context-Driven Approach»

Сэм Канер, Джеймс Маркус Бах, Брет Петтичорд, переводчик Максим Захаров. Wiley, 2001 год.148/658 страница:

Различайте понятия критичности и приоритета дефекта

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

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

“Быстрое тестирование”

Роберт Калбертсон, Крис Браун, Гэри Кобб. Издательский дом “Вильямс”, 2002. 59-60, 121, 164/374 страницы:

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

  • Тестируйте в первую очередь требования с наивысшим приоритетом…
  • Сосредоточьте свое внимание на функциях и конфигурациях, с которыми наиболее часто будет иметь дело конечный пользователь…

Определение задач

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

Таблица 5.2. Данные о дефекте, пребывающем в состоянии “Новый”

Степень серьезности дефекта. Описание: Упорядочивание дефектов по степени серьезности послед­ствий. Примеры:

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

Обоснование: серьезность последствий часто опреде­ляет приоритеты усилий разработчиков при устранении дефектов и тестировщиков при проверке результатов этих ис­правлений.

Жизненный цикл дефекта

Иногда для продол­жения тестирования требуется использование правки (patch) исполняемого модуля. В случае возникновения блокировки во время тестирования приоритет исправления ошибки повышается до наивысшего уровня. Тем самым задача немедленного исправ­ления ошибки становится первоочередной…

Тестирование случаев использования

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

«Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах»

Роман Савин, Москва: Дело, 2007. 36, 40, 42, 58, 74, 230-231, 279/316 страницы:

Часть 1. Цель тестирования. Вопросы и задания для самопроверки

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

Часть 1. Искусство создания тест-кейсов. Полезные атрибуты тест-кейса

Приоритет тест-кейса (Test Case Priority)

Это важность тест-кейса. Важность отражается по шкале от 1 до n, где 1 — это высший приоритет, а n — это низший приоритет. Думаю, что рационально делать n = 4.

Допустим, тест-кейс, проверяющий, работает ли кнопка «Купить», будет 1-го приоритета, а тест-кейс, проверяющий цвет шрифта линка «Гостевая книга», будет 4-го приоритета. Концептуально, думаю, понятно.

Зачем это делается? Допустим, у нас есть два тест-кейса: один 1-го приоритета и другой — 3-го приоритета, оба тестируют некую функциональность А, и есть время для исполнения только одного из них. Естественно, что мы выберем тест-кейс 1-го приоритета. Приоритезация тест-кейсов особо полезна при регрессивном тестировании, о котором мы не раз будем говорить.

Вопрос: Как присваиваются приоритеты?

Ответ: Конечно, все зависит от компании, но, как правило, автор тест-кейса просто решает, насколько жизненно важна, определяюща и критична вещь, проверяемая данным тест-кейсом…

Часть 1. Искусство создания тест-кейсов. Тест-комплексты

Priority — приоритет тест-комплекта (например, от 1 до 4), обычно соответствующий приоритету спека…

Часть 1. Цикл разработки программного обеспечения. Разработка дизайна продукта и создание спека

Как правило, приоритет присваивается спекам менеджером продюсеров.

Часть 2. Классификация видов тестирования. По критерию “позитивности” сценариев

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

Часть 3. Исполнение тестирования. Жизнь замечательных багов. Атрибуты бага. Priority

PRIORITY (ПРИОРИТЕТ БАГА)

Форма: ниспадающее меню со значениями от П1 до П4 (П—4) включительно.

Содержание: приоритет бага — это показатель важности бага для бизнеса компании.

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

Серьезность — это категория абсолютная. Приоритет — это категория относительная.

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

Кроме привязки к серьезности бага на приоритет могут воздействовать следующие потенциальные либо реальные вещи:

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

При недостатке времени для исполнения тест-комплектов из группы 3 рекомендую исполнять лишь самые приоритетные тест-кейсы каждого тест-комплекта, выбранного для исполнения при регрессивном тестировании данного релиза.

«Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование»

Рекс Блэк, Москва, Лори, 2006. 69-71/566 страницы:

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

  1. Потеря данных. Ошибки, относящиеся к этому виду ошибок, могут вызвать потерю пользовательских (конечного пользователя, оператора системы и тому подобное) или системных данных.
  2. Потеря функциональности.
  3. Потеря функциональности с наличием обходного пути.
  4. Частичная потеря функциональности.
  5. Косметическая ошибка.

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

  1. Неотложно.
  2. Существенно.
  3. Значимо.
  4. Желательно.
  5. На усмотрение.

Вероятность - возможность возникновения ошибки этого вида и всех ее проявлений, от 1 (наиболее вероятно) до 5 (наименее вероятно). На величину этого рейтинга влияет три фактора. Во-первых, для всех ошибок, включенных в этот вид, устанавливается, велика ли вероятность того, что они могут появиться в системе, с точки зрения факторов технического риска: сложности и предыдущей истории дефекта. Во-вторых, велика ли вероятность того, что ошибки будут пропущены разработчиками (не включая тестировщиков)?…

  1. Очень вероятно
  2. Вероятно
  3. Возможно
  4. Маловероятно
  5. Очень маловероятно

“Тестирование компонентов и комплексов программ”

В.В. Липаев. Москва, Синтег, 2010. 95, 333, 340/392 страницы:

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

Обеспечение баланса требований к качеству комплексов программ

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

  • доминирующие характеристики качества и риски, оказывающие наибольшее влияние на функциональную пригодность при допустимых затратах (обобщенный приоритет > 8);
  • значения характеристик качества и рисков, имеющие достаточное влияние на функциональную пригодность и значительные затраты на реализацию (обобщенный приоритет < 7, но > 4);
  • характеристики качества, значения требований к которым не соответствуют их влиянию на функциональную пригодность и/или затратам на реализацию и могут не учитываться (обобщенный приоритет < 3)…

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

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

  • в структуре тестовых процедур следует учитывать и документировать их приоритеты и риски…

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

Применение графиков для планирования производства компонентов и комплексов программ

… Другой способ обеспечения уложиться в заданные сроки − подробное, критичное изучение требований к программному комплексу и исключение из них не самых актуальных. Иногда, требования оказываются чересчур высокими, так как делаются попытки придать программному продукту дополнительные «украшения», не влияющий на него по существу. Избавление от ненужных требований состоит в «чистке» эталонов – требований. Важнейшим принципом планирования производства комплексов программ является упорядочивание приоритетов в порядке возрастания важности требований для заказчика и/или пользователей. Зачастую можно согласовать с заказчиком и принять решение об исключении определенных требований для того, чтобы уложиться в сроки. Следовательно, необходимо придерживаться принципа последовательного приращения функций и качества, не только на этапе анализа требований, но и во время планирования производства (в том числе календарного), реализации компонентов и комплекса программ…

Новым функциям и характеристикам имеет смысл посвящать повышенное внимание, нежели слегка модифицированным компонентам…

Испытания компонентов и комплексов программ. Организация и процессы испытаний компонентов и комплексов программ

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

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

“Сертифицированный тестировщик Программа обучения Базового уровня”

Версия 2011 (от 13 апреля 2011 года), International Software Testing Qualifications Board, Thomas Müller, Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson и Erik van Veendendaal, Андрей Конушин, Александр Александров, Алексей Александров, Татьяна Смехнова, Елена Абрамова. 16, 19, 52, 71/101 страницы:

Принцип 2 – Исчерпывающее тестирование недостижимо

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

Анализ и проектирование тестов

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

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

Реализация и выполнение тестов

Для реализации и выполнения тестов поставлены следующие основные задачи

  • Завершение, реализация и расстановка приоритетов тестовых сценариев (включая проектирование тестовых данных).
  • Разработка и расстановка приоритетов процедур тестирования, создание тестовых данных и, если потребуется, подготовка тестовых обвязок и написание автоматизированных сценариев тестирования…

Процесс разработки тестов

… Во время реализации теста тестовые сценарии разрабатываются, реализуются, получают приоритеты и формируют спецификацию процедуры тестирования (IEEE STD 829-1998)…

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

Контроль тестирования

Примеры действий по контролю тестирования:

  • … Повторная расстановка приоритетов при возникновении установленного риска (например, задержка выпуска ПО)…

Риски продукта

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

  • … Установления приоритетов для тестирования, что бы найти критичные дефекты как можно раньше…

«Сертифицированный тестировщик Программа обучения Продвинутого уровня»

Версия 2012 от 30 марта 2017 года, International Software Testing Qualifications Board. Рабочая группа Продвинутого уровня Rex Black, Judy McKay, Graham Bath, Debra Friedenberg, Bernard Homès, Kenji Onishi, Mike Smith, Geoff Thompson, Tsuyoshi Yumoto, Маргарита Трофимова, Александр Александров, Андрей Конушин, Елена Костина, Александр Мешков, Александра Титова. 26, 53, 104/127 страницы:

2.2.4. Управление нефункциональным тестированием

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

2.3. Тестирование, основанное на рисках, и другие подходы приоритизации тестов и распределения трудозатрат

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

2.3.1. Тестирование, основанное на рисках

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

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

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

2.3.1.3. Смягчение рисков

… Трудозатраты, связанные с разработкой и выполнением тестирования, пропорциональны уровню риска, что означает, что более тщательные методы тестирования (такие, как парное тестирование) используются для более высоких рисков, в то время как менее тщательные методы тестирования (например, разбиение эквивалентности или ограниченное по времени исследовательское тестирование) используются для более низких рисков. Кроме того, приоритет разработки и выполнения тестирования основан на уровне риска. Некоторые стандарты, связанные с безопасностью (например, Federal Aviation Administration DO-178B, “Software Considerations in Airborne Systems and Equipment Certification” / ED 12B, International Electrotechnical Commission 61508 “Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems”), предписывают методы тестирования и степень покрытия на основе уровня риска…

2.3.2 Методы тестирования, основанного на рисках

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

… При формальном, тяжеловесном завершении определении веса, руководитель тестирования имеет альтернативы:

… Анализ типов отказа и эффекта (FMEA) и его варианты (D.H. Stamatis, “Failure Mode and Effect Analysis,” ASQC Quality Press, 2003, ISBN 0-873-89300), где риски качества, их возможные причины, а также их возможный эффект определены и затем установлены оценки критичности, приоритета и выявления…

… Как правило, наиболее важным фактором успеха тестирования, основанного на рисках, является вовлечение правильной группы заинтересованных лиц в определение и оценку рисков. У всех заинтересованных лиц есть свое собственное понимание того, что представляет собой качество продукта, а также свой собственный набор приоритетов и опасений по поводу качества. Однако, заинтересованные лица, как правило, делятся на две основные категории: бизнес участники и техническая сторона…

… Как описано в “Systematic Software Testing” (Rick Craig, Stefan Jaskiel, Artech House, 2002, ISBN 1-580-53508-9), анализ тестовых условий предполагает внимательное чтение спецификации требований для определения тестовых условий для покрытия. Если этим требованиям присвоен приоритет, это может быть использовано для распределения трудозатрат и приоритизации тестовых случаев. При отсутствии присвоенного приоритета трудно определить соответствующие трудозатраты и порядок тестирования без сочетаний тестирования на основе требований с тестированием, основанном на рисках.

2.3.4. Приоритизация тестов и распределение усилий в процессе тестирования

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

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

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

Как часть представления результатов и оценки критериев выхода, руководитель тестирования может измерить степень завершенности тестирования. Это должно включать трассировку тестовых сценариев и обнаруженных дефектов к соответствующему базису тестирования. Например, при тестировании, основанном на рисках, по мере того как тесты запускаются и обнаруживают дефекты, тестировщики могут рассматривать оставшийся, остаточный уровень риска. Это поддерживает использование тестирования, основанного на рисках, в определении правильного момента для релиза. В отчетности по тестированию следует учитывать покрытые и оставшиеся риски, а также преимущества, достигнутые и еще не достигнутые. Для примера отчетности по результатам тестирования на основе покрытия рисков (см. Rex Black, “Critical Testing Processes,” Addison-Wesley, 2003, ISBN 0-201-74868-1).

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

Создание плана улучшения процессов тестирования

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

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

… Как упоминалось выше, стратегии тестирования описывают общие методологии тестирования, которые, как правило, включают:

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

2.6 Определение и использование метрик тестирования

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

… Когда использование результатов тестирования приводит к влиянию или измерению для достижения контроля проекта, должны приниматься во внимание следующие функции:

  • Пересмотр анализа рисков качества, приоритетов тестирования и/или планов тестирования.

3.3 Управление рецензированием

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

“Стандартный глоссарий терминов, используемых в тестировании программного обеспечения”, версия 2.3 (от 9 июля 2014 года)

International Software Testing Qualifications Board, ред. пер. Александр Александров:

Созидание (модель IDEAL) (establishing (IDEAL)): Фаза модели IDEAL, в которой планируется специфика того, как организация достигнет задуманного. Созидательная фаза состоит из следующий действий: расстановка приоритетов, разработка подхода и планирование действий. См. также модель IDEAL.

Управление рисками (risk management): Систематическое использование процедур и практик с целью идентификации, анализа, определения приоритетов и контроля рисков.

“Тестирование программного обеспечения. Базовый курс”

Святослав Куликов. Версия книги 1.2.1 от 02.08.2017, EPAM Systems. 119, 134/297 страницы:

2.4.5. Атрибуты (поля) тест-кейса

…Приоритет (priority) показывает важность тест-кейса. Он может быть выраыжен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти.

Приоритет тест-кейса может коррелировать с:

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

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

2.4.5. Свойства качественных тест-кейсов

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

23.04.2018. Перейти на Главную страницу