Материал: ISTQB_CTFL_Syllabus_2011_RU
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 71 из 101
13 апреля 2011
© International Software Testing Qualifications Board
Метрики, которые необходимо собрать во время и в конце уровня тестирования:
•
Соответствие целей тестирования уровню тестирования;
•
Адекватность выбора подхода к тестированию;
•
Эффективность тестирования в отношении установленных целей.
5.3.3 Контроль тестирования (K2)
Контроль тестирования описывает любые направляющие или корректирующие
действия, принятые как результат по полученной и собранной информации и
значениям метрик. Контроль тестирования может затрагивать любые действия по
тестированию, а так же воздействовать на другие действия и задачи жизненного
цикла ПО.
Примеры действий по контролю тестирования:
•
Принятие решений на основании данных мониторинга тестирования;
•
Повторная расстановка приоритетов при возникновении установленного
риска (например, задержка выпуска ПО);
•
Изменение графика тестирования согласно доступности тестового
окружения;
Установка критерия входа, требующего повторного (подтверждающего)
тестирования исправлений, сделанных разработчиком, перед принятием их в
сборку.
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 72 из 101
13 апреля 2011
© International Software Testing Qualifications Board
5.4 Управление конфигурацией (K2)
10 минут
Терминология
Управление конфигурацией, управление версиями
Введение
Целью управления конфигурацией является установка и поддержка
интегрируемости продуктов (компонентов, данных и документации) ПО или
системы на протяжении жизненного цикла проекта или продукта.
Для тестирования управление конфигурацией может гарантировать:
•
Все пункты того, что нужно протестировать, определены, контролируются
по версиям, все изменения учитываются, связаны с разрабатываемыми
элементами (объекты тестирования) и друг с другом так, что бы обеспечить
трассировку на протяжении всего процесса тестирования;
•
Вся установленная документация и элементы ПО однозначно определены в
документации по тестированию.
Для тестировщика, управление конфигурацией помогает однозначно определить
(и воспроизвести) элемент тестирования, документацию тестирования, тесты и
средства тестирования.
Процедура управления конфигурацией и инфраструктура (средства) выбираются,
документируются и внедряются на стадии планирования тестирования.
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 73 из 101
13 апреля 2011
© International Software Testing Qualifications Board
5.5 Риски и тестирование (K2)
30 минут
Терминология
Риски продукта, Риски проекта, риск, ориентированное на риски тестирование
Введение
Риск может быть определен как вероятность возникновения события, опасности,
угрозы или ситуации, которая выражается в нежелательных последствиях или
потенциальной проблеме. Уровень риска определяется вероятностью
возникновения неблагоприятного события и его влияния (ущерб, проявляющийся
в результате этого события).
5.5.1 Риски проекта (K2)
Риски проекта – это риски, которые влияют на способность проекта достигнуть его
целей, и включают:
Организационные факторы:
o
Недостаток квалификации, подготовки и сотрудников;
o
Личные проблемы сотрудников;
o
Политические проблемы, такие как:
Тестировщики в недостаточной степени сообщают о своих
проблемах и результатах тестирования;
Неспособность следовать информации, полученной во время
тестирования или рецензирования (например, не улучшать
практики разработки или тестирования);
o
Неверное отношения к тестированию или ложные ожидания
(например, не принимать во внимание значение найденных во время
тестирования дефектов);
Технические проблемы:
o
Проблемы в определении верных требований;
o
Объем, при котором требования не могут соответствовать заданным
ограничениям;
o
Вовремя не готово тестовое окружение;
o
Позднее преобразование данных, планирование миграции и
разработки тестовых данных и средств преобразования\миграции
тестовых данных;
o
Низкое качество проектирования, кода, конфигурационных и
тестовых данных и тестов;
Проблема поставщика:
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 74 из 101
13 апреля 2011
© International Software Testing Qualifications Board
o
Отказ третьей стороны;
o
Проблемы контракта.
При анализе, управлении и уменьшении этих рисков менеджер тестирования
должен следовать хорошо обоснованным принципам управления проектом.
«Стандарт по тестовой Документации для Программного Обеспечения» (IEEE Std
829-1998) содержит шаблон плана тестирования, требующий определения рисков
и непредвиденных обстоятельств.
5.5.2 Риски продукта (K2)
Риски продукта – это потенциальные области сбоя (неблагоприятные будущие
события или опасность) в ПО или системе, т.к. они подвергают риску качество
продукта, например:
Поставка потенциально ненадежного ПО;
Возможность того, что программное\аппаратное обеспечение может
нанести вред человеку или компании;
Плохие характеристики ПО (например, функциональность, надежность,
удобство использования или производительность);
Неполнота и низкое качество данных (например, проблемы миграции,
преобразования и перемещения данных, отклонение от стандарта данных);
ПО, которое не выполняет предполагаемых функций.
Риски используются для определения того, где начинать тестирование и каким
аспектам уделить большее внимание, тестирование используется для
уменьшения риска возникновения неблагоприятных эффектов или их
последствий.
Риски продукта – это особенный тип рисков, который влияет на успех продукта.
Тестирование как действие, контролирующее риски, позволяет определить
остаточные риски путем измерения эффективности исправления критичных
дефектов и плана на случай непредвиденных обстоятельств.
Подход к тестированию, основанный на рисках, предоставляет превентивные
возможности уменьшения рисков продукта, начиная с ранних стадий проекта. Он
включает в себя идентификацию рисков продукта и их использование в
планировании и контроле тестирования, требованиях, подготовке и выполнении
тестов. В подходе, основанном на рисках, их можно использовать для:
Определения методики тестирования для использования;
Определения объема тестирования, которое должно быть выполнено;
Установления приоритетов для тестирования, что бы найти критичные
дефекты как можно раньше;
Определения, нужны ли дополнительные, не связанные с тестированием
действия по уменьшению рисков (например, проведение тренинга для
неопытных проектировщиков).
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 75 из 101
13 апреля 2011
© International Software Testing Qualifications Board
Тестирование, основанное на рисках, использует коллективное знание и
понимание участников проекта для определения рисков и уровней тестирования,
необходимых для работы с этими рисками.
Для того, что бы удостовериться, что сбой в продукте минимизирован, действия
по управлению рисками обеспечивают строгий порядок подхода к:
Оценке (и переоценке на регулярной основе) того, что может пойти неверно
(риски);
Определению, какие риски наиболее важны для решения;
Выполнение действий по работе с этими рисками.
В дополнение, тестирование может поддерживать нахождение новых рисков,
помогает определить какие риски должны быть уменьшены, а также может
снижать неопределенность в отношении рисков.