Istqb lesson 5

Курс: Профессиональный тестировщик.
Занятие 5. Управление тестированием.
Бульба Евгений, ISTQB Certified Test Manager.
Июль 10, 2019.

Содержание
Занятие 5. Управление тестированием.
1. Организация тестирования.
2. Планирование и оценка тестирования.
3. Контроль и мониторинг тестирования.
4. Управление конфигурацией.
5. Риски и тестирование.
6. Управление дефектами.
2
Профессиональный тестировщик, Июнь
2019 г.

Организация
тестирования
2019 г.
3

1. Организация тестирования (1 из 9)
2019 г.
4
Задачи тестирования могут выполняться как
людьми в конкретной роли, связанной с
тестированием, так и людьми в иной роли (например,
заказчиками). Конкретный уровень независимости
часто делает тестировщика более эффективным в
поиске дефектов из-за психологических различий
разработчика и тестировщика. Независимость не
является, однако, альтернативой осведомленности, и
разработчики могут находить много дефектов в своем
собственном коде.
Стандарт IEEE 1012-2016 - IEEE Standard for
System, Software, and Hardware Verification and
Validation определяет уровни независимости команды
тестирования.

2019 г.
5
Стандарт IEEE 1012 определяет три критерия независимости
команды верификации и валидации.
1. Техническая независимость.
2. Управленческая независимость.
3. Финансовая независимость.
Форма независимости Техническая Управленческая Финансовая
Классическая полноценная полноценная полноценная
Модифицированная полноценная условная полноценная
Интегрированная условная полноценная полноценная
Внутренняя условная условная условная
Встроенная минимальная минимальная минимальная

2019 г.
6
Уровни независимости тестирования включают следующие :
1. Нет независимых тестировщиков; разработчики тестируют
собственный код, других форм тестирования нет;
2. Независимые разработчики или тестировщики в команде
разработки или в команде проекта; это могут быть разработчики,
тестирующие продукты своих коллег;
3. Независимая команда или группа тестирования внутри
организации, отчитывающаяся перед руководством проекта;
4. Независимые тестировщики из организации заказчика. Могут
специализироваться на отдельных типах тестирования;
5. Независимые тестировщики, внешние по отношению к
организации, работающие либо на территории компании
(инсорсинг), либо вне ее (аутсорсинг).

2019 г.
7
Преимущества и недостатки независимого тестирования.
Преимущества Недостатки
Эффективное распознавание различных видов
отказов по сравнению с разработчиками из-за
разницы подходов, технических перспектив и
предубеждений.
Изоляция от команды разработчиков, что
приводит к отсутствию сотрудничества,
задержкам с предоставлением обратной связи
команде разработчиков или соперничеству с
командой разработчиков.
Возможность независимого тестировщика
проверять, оспаривать или опровергать
допущения, сделанные заинтересованными
сторонами во время проектирования и внедрения
системы.
Потеря разработчиками чувства
ответственности за качество.
Восприятие независимых тестировщиков как
«узкого места» и обвинения в задержках релиза.
Недостаточность у независимых тестировщиков
какой-либо важной информации (например, об
объекте тестирования).

2019 г.
8
Тестирование
Руководитель
Тест-аналитик
Технический
тест-аналитик
Тестировщик

2019 г.
9
Руководитель тестирования (Test Manager) – человек,
ответственный за управление ресурсами и работами по тестированию,
а также за экспертизу тестового объекта. Направляет, контролирует,
администрирует, планирует и регулирует экспертизу тестового
объекта.
Тест-аналитик (Test Analyst) – человек, ответственный за
определение правильных тестов и тестовых случаев, их разработку и
выполнение.
Технический тест-аналитики (Technical Test Analyst) – человек,
который работает в рамках тестирования основанного на рисках,
созданного руководителем тестирования.
Тестировщик (Tester) – опытный специалист, принимающий
участие в тестировании компонента или системы.

2019 г.
10
Роль руководителя тестирования может выполняться
профессиональным руководителем тестирования, руководителем
проекта, руководителем разработки, или руководителем по
обеспечению качества. Типичные задачи руководителя тестирования
могут включать:
• Разработку или рецензирование тестовой политики и стратегии
тестирования для организации;
• Планирование тестирования, с учетом контекста и понимания
целей и рисков тестирования. Это может включать выбор тестовых
подходов, оценку времени тестирования, трудозатрат и стоимости,
привлечение ресурсов, определение уровней тестирования и
циклов тестирования и планирование управления дефектами
• Составление и обновление планов тестирования;

2019 г.
11
• Согласование планов тестирования с руководителями проектов,
владельцами продуктов и другими участниками;
• Координацию активностей тестирования с другими проектами,
такими как планирование интеграции;
• Инициирование анализа, разработки, реализации и выполнения
тестов, отслеживание прогресса и результатов тестирования,
контроль выполнения выходных критериев;
• Подготовку и предоставление отчетов о статусе тестирования и
сводных отчетов о тестировании на основе собранной информации;
• Адаптацию планов в зависимости от прогресса и результатов
тестирования;
• Поддержку настройки системы управления дефектами и
конфигурацией тестового обеспечения;

2019 г.
12
• Выбор подходящих метрик для измерения результатов
тестирования и оценки качества процесса тестирования и продукта;
• Выбор и внедрение инструментов поддержки процесса
тестирования, включая рекомендации по выбору инструментария,
выделение времени и трудозатрат для пилотных проектов,
обеспечение постоянной поддержки в использовании инструмента /
инструментов;
• Решения о создании тестовой среды / сред;
• Демонстрацию ценности тестировщиков, группы тестирования и
профессии тестировщика в организации;
• Развитие навыков и карьеры тестировщиков (например,
посредством планов обучения, оценки эффективности, коучинга и
т.д.).

Планирование и
оценка тестирования
2019 г.
13

2. Планирование и оценка тестирования (1 из 16)
2019 г.
14
План тестирования (Test plan) – документ, описывающий цели,
подходы, ресурсы и график запланированных тестовых активностей.
Он определяет объекты тестирования, свойства для тестирования,
задания, ответственных за задания, степень независимости каждого
тестировщика, тестовое окружение, метод проектирования тестов,
определяет используемые критерии входа и критерии выхода и
причины их выбора, а также любые риски, требующие планирования
на случай чрезвычайных обстоятельств. [IEEE 829]
Планирование зависит от политики тестирования и стратегии
тестирования организации, используемых методов и жизненных
циклов разработки, объема тестирования, целей, рисков, ограничений,
критичности, тестируемости и доступности ресурсов.
Планирование тестирования - непрерывная деятельность, которая
выполняется в течение всего жизненного цикла продукта!

2019 г.
15
Содержание планов тестирования
различается. Примеры планов
тестирования можно найти в стандартах:
IEEE 829-2008 - IEEE Standard for
Software Test Documentation.
IEEE 29119-3-2013 - ISO/IEC/IEEE
International Standard - Software and
systems engineering – Software testing –
Part 3: Test documentation.

2019 г.
16
Мероприятия по планированию тестирования могут включать:
• Определение объема, целей и рисков тестирования;
• Определение общего подхода к тестированию;
• Координацию работ по тестированию и их совмещение с другими
работами в рамках жизненного цикла программного обеспечения;
• Принятие решений о том, что тестировать, кто будет выполнять
тестирование и как должны выполняться работы по тестированию;
• Планирование анализа, проектирования, реализации и выполнения
тестов, оценки результатов тестирования с указанием сроков;
• Выбор метрик для мониторинга и контроля тестирования;
• Формирование бюджета тестирования;
• Определение структуры и уровня детализации тестовой
документации.

17
Стратегия тестирования (Test strategy) – высокоуровневое
описание уровней тестирования, которые должны быть выполнены, и
тестирования, входящего в эти уровни, для организации или
программы из одного или более проектов.
Стратегия
Аналитический подход
На основе моделей
Методический подход
На основе процесса
Направленный подход
Минимизация регресса
Реактивный подход
2019 г.

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

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

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

21
Реактивный подход – тестирование в данном
случае не является спланированным заранее, но
зависит от тестируемого компонента, системы или
событий, происходящих при выполнении тестов.
Новые тесты проектируются, разрабатываются и
выполняются, исходя из знаний, ранее полученных при
тестировании. Исследовательское тестирование
является распространенной методикой, применяемой
в реактивных стратегиях.
Подходящая стратегия тестирования может быть создана путем
объединения нескольких стратегий тестирования. Например,
аналитическая стратегия может сочетаться с реактивной стратегией.
2019 г.

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

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

24
График тестирования (test schedule) – список задач, действий
или событий в процессе тестирования, определяющий даты и/или
время их начала и завершения, и их взаимозависимости.
Расписание выполнения тестов (test execution schedule) –
схема выполнения тестовых процедур.
Расписание должно учитывать такие факторы как: приоритет,
зависимости между тестами и / или тестируемыми функциями,
необходимость выполнения подтверждающих тестов и регрессионных
тестов и наиболее эффективную последовательность выполнения
тестов.
В идеальном случае тестовые сценарии упорядочиваются на
основе их приоритетов, при этом сначала выполняются тестовые
сценарии с наивысшим приоритетом.
2019 г.

25
Оценка затрат на тестирование подразумевает прогнозирование
объема связанной с тестированием работы, которая необходима для
достижения целей тестирования проекта, релиза или итерации.
Факторы влияющие
на затраты
Результаты тестирования
Характеристики продукта
Характеристики процесса разработки
Характеристики людей
2019 г.

26
Характеристики продукта включают:
• Риски, связанные с продуктом;
• Качество базиса тестирования;
• Размер продукта;
• Сложность предметной области продукта;
• Требования к характеристикам качества (например, безопасности,
надежности);
• Требуемый уровень детализации тестовой документации;
• Требования к юридическому и нормативному соответствию.
Характеристики продукта
2019 г.

27
Характеристики процесса разработки включают:
• Стабильность и зрелость организации;
• Используемую модель разработки;
• Подход к тестированию;
• Используемые инструменты;
• Процесс тестирования;
• Сжатость сроков.
Характеристики процесса разработки
2019 г.

28
Характеристики людей включают:
• Навыки и опыт, особенно в аналогичных проектах и продуктах
(например, знание предметной области);
• Командная сплоченность и лидерство.
Характеристики людей
Результаты тестирования
Результаты тестирования включают:
• Количество и критичность выявленных дефектов;
• Объем требуемых доработок.
2019 г.

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

Контроль и мониторинг
2019 г.
30

3. Контроль и мониторинг тестирования (1 из 10)
2019 г.
31
Мониторинг тестирования (test monitoring) – задача управления
тестированием, связанная с периодической проверкой статуса
тестирования проекта. Составляемые отчеты содержат сравнение
реального и запланированного состояний.
Контроль тестирования (test control) – задача управления
тестированием, связанная с разработкой и применением комплекса
корректирующих мер для возвращения тестирования проекта в график
при выявлении отклонений от плана.
Примеры действий по контролю тестирования:
• Повторная приоритезация тестов при реализации рисков;
• Изменение графика тестирования из-за недоступности тестовой
среды или других ресурсов;
• Повторная проверка выполнения критериев входа или выхода.

2019 г.
32
Метрика (metric) – шкала измерений и метод, используемый для
измерений [ISO 14598].
Метрики могут собираться во время и по завершении
тестирования, чтобы оценить:
• Прогресс относительно запланированного графика и бюджета;
• Текущее качество объекта тестирования;
• Адекватность подхода к тестированию;
• Эффективность активностей тестирования по достижению целей
«Вы не можете контролировать то, что не можете
измерить»
Том ДеМарко

2019 г.
33
Типичные метрики тестирования включают:
• Процент выполненных работ по подготовке тестовых сценариев
(или процент разработанных тестовых сценариев);
• Процент выполненных работ по подготовке тестовой среды;
• Метрики выполнения тестов: количество выполненных /
невыполненных тестовых сценариев, количество тестовых условий
или сценариев, выполненных успешно / неуспешно;
• Информацию о дефектах: плотность дефектов, количество
обнаруженных и исправленных дефектов, частоту отказов и
результаты подтверждающих тестов;
• Покрытие тестами требований, пользовательских историй,
критериев приемки, рисков или кода;

2019 г.
34
• Информацию о выполнении задач, распределении и использовании
ресурсов, трудозатратах;
• Стоимость тестирования, включая сравнение стоимости с выгодой
от нахождения следующего дефекта или от выполнения
следующего теста.
Важно помнить, что метрика может содержать только
утверждения, относящиеся к одному аспекту, который
рассматривается, и рассчитанные значения измерений интересны
только в сравнении с числами из других программ или частей
программы, которые проверяются.
Метрики не существуют в изоляции!
Для сбора метрик используются специальные инструменты!

2019 г.
35
Примеры метрик в тестировании:
• Плотность дефектов (Число дефектов / Размер кода);
• Доля отклоненных дефектов (Число отклоненных дефектов / Число
дефектов);
• Эффективность тестирования (Число дефектов / Трудозатраты
тестирования);
• Доля покрытия требований (Число требований, покрытых тестами /
Число требований);
• Плотность покрытия требований (Число тестов / Число
требований);
• Доля повторно открытых дефектов (Число повторно открытых
дефектов / Число дефектов);
• и т.д.

2019 г.
36

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

2019 г.
38
Отчет о тестировании – документ, подводящий итог задачам и
результатам тестирования, также содержащий оценку
соответствующих объектов тестирования относительно критериев
выхода. [IEEE 829]
Во время мониторинга и контроля тестирования руководитель
тестирования регулярно публикует для заинтересованных сторон
отчеты о ходе тестирования. Помимо разделов, общих для отчета о
ходе тестирования отчет может включать:
• Статус активностей тестирования и прогресс по сравнению с
планом тестирования;
• Факторы, препятствующие прогрессу;
• Тестирование, запланированное на следующий отчетный период;
• Качество объекта тестирования.

2019 г.
39
Когда критерии выхода выполнены, руководитель тестирования
готовит итоговый отчет о тестировании. Обычно итоговые отчеты и
отчеты о ходе тестирования включают:
• Резюме проведенного тестирования;
• Информацию о том, что произошло во время тестирования;
• Информацию об отклонениях от плана, включая отклонения в
расписании, длительности выполнения или затратах;
• Информацию о качестве тестирования и качестве продукта с точки
зрения критериев выхода или критериев завершения;
• Информацию о факторах, которые блокировали или продолжают
блокировать тестирование;
• Метрики дефектов, тестовых сценариев, покрытия, прогресса
тестирования и использования ресурсов;

2019 г.
40
• Информацию об остаточных рисках;
• Перечень тестовых артефактов, которые можно повторно
использовать.
Содержимое отчета о тестировании зависит от проекта,
корпоративных требований и жизненного цикла разработки
программного обеспечения.
Стандарт (ISO/IEC/IEEE 29119-3) описывает два типа отчетов о
тестировании: отчет о ходе тестирования и отчет о завершении
тестирования (называемый в этом документе итоговым отчетом) и
содержит структуру и примеры оформления отчетов каждого типа.

Управление
конфигурацией
2019 г.
41

4. Управление конфигурацией (1 из 2)
2019 г.
42
Конфигурация – структура компонента или системы,
определяемая числом, типом и взаимосвязанностью составляющих
частей.
Управление конфигурацией – наука, применяющая техническое
и административное руководство и контроль для: идентификации и
документирования функциональных и физических характеристик
элемента конфигурации, контроля изменений этих характеристик,
записи и отчетности о состоянии процесса внедрения изменений, а
также проверки совместимости с заданными требованиями. [IEEE 610]
Идентификация конфигурации – элемент управления
конфигурацией, состоящий из выбора элементов конфигурации для
системы и фиксирования их функциональных и физических
характеристик в технической документации. [IEEE 610]

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

Риски и тестирование
2019 г.
44

5. Риски и тестирование (1 из 11)
2019 г.
45
Риск – сочетание вероятности события причинения вреда и
тяжести этого вреда [МЭК 61508-4].
Управление рисками – систематическое использование процедур
и практик с целью идентификации, анализа, определения приоритетов
и контроля рисков.
Риск подразумевает наступление некоторого негативного события
в будущем. Уровень риска можно определить через вероятность
события и серьезность последствий.
Риски
Проекта Продукта

2019 г.
46
Риск продукта – риск, непосредственно связанный с объектом
Риск продукта – это возможное несоответствие некоторого
артефакта (спецификации, компонента, системы или теста и т.д.)
потребностям пользователей и заинтересованных сторон.
Когда риски продукта связаны с конкретными характеристиками
качества (функциональной пригодностью, надежностью,
производительностью, практичностью, безопасностью,
совместимостью, сопровождаемостью и переносимостью), их также
называют рисками качества.

2019 г.
47
Примеры рисков продукта:
• Программное обеспечение не выполняет функции, указанные в
спецификации;
• Программное обеспечение не выполняет функции, ожидаемые
пользователями, клиентами и/или заинтересованными сторонами;
• Системная архитектура не поддерживает нефункциональные
требования;
• Вычисления выполняются неверно в каких-то ситуациях;
• Неверная реализация в коде структуры управления циклом;
• Неадекватное время отклика высоконагруженной системы;
• Отзывы пользователей о продукте показывают, что их ожидания не
оправдались.

2019 г.
48
Риск проекта – риск, относящийся к управлению и контролю
проектом или тестированием в проекте. Например: нехватка
персонала, жесткие сроки окончания, изменения требований, и т.д.
Риски проекта связаны с событиями, препятствующими
достижению целей проекта.
Риски проекта
Проектные
проблемы
Технические
проблемы
Организационные
проблемы
Политические
проблемы
Проблемы
поставщика

2019 г.
49
• Задержки поставки, выполнения задач, выполнения критериев
выхода или критериев готовности;
• Неточные оценки, перераспределение средств на проекты с более
высоким приоритетом или общие сокращения затрат по всей
организации могут привести к неадекватному финансированию;
• Поздние изменения могут привести к существенным доработкам.
Проектные
проблемы

2019 г.
50
• Недостаток навыков, обучения или численности персонала;
• Проблемы с персоналом могут вызвать конфликты и серьезные
трудности;
• Пользователи, бизнес-пользователи или эксперты предметной
области могут быть заняты другими работами.
Организационные
проблемы

2019 г.
51
• Тестировщики не могут адекватно сообщать о своих потребностях
и/или результатах тестирования;
• Разработчики и/или тестировщики не могут отслеживать
информацию, полученную при тестировании и рецензировании (не
стремясь улучшить методы разработки и тестирования);
• Может быть неправильное отношение или ожидания от
тестирования (недооценивается важность обнаружения дефектов
во время тестирования и т.д.).
Политические
проблемы

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

2019 г.
53
• Третья сторона может не предоставить необходимый продукт или
услугу, или обанкротиться;
• Контрактные проблемы могут вызвать серьезные трудности для
проекта.
Проектные риски могут влиять как на разработку, так и на
тестирование. В некоторых случаях руководители проектов несут
ответственность за управление всеми проектными рисками;
руководители тестирования обычно отвечают за управление рисками,
связанными с тестированием проекта.
Проблемы
поставщика

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

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

Управление дефектами
2019 г.
56

6. Управление дефектами (1 из 9)
2019 г.
57
Управление дефектами – процесс распознавания, исследования,
принятия действий и устранения дефектов. Он включает в себя
фиксирование дефектов, их классификацию и выявления
последствий. [IEEE 1044]
Способ регистрации дефектов может варьироваться в
зависимости от контекста, тестируемого компонента или системы,
уровня тестирования и модели жизненного цикла. Любые выявленные
дефекты должны быть изучены и отслеживаться от момента
обнаружения и классификации до принятия решения по ним.
Чтобы управлять дефектами до принятия решения по ним, в
организации должен существовать процесс управления дефектами,
который включает в себя жизненный цикл и правила классификации
дефектов.

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

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

2019 г.
60
Отчет о дефекте – документ, содержащий отчет о любом
недостатке в компоненте или системе, который может привести
компонент или систему к невозможности выполнить требуемую
функцию. [IEEE 829]
Типичные отчеты о дефектах имеют следующие цели:
• Предоставлять разработчикам и другим сторонам информацию о
произошедших негативных событиях, чтобы они могли определить
побочные эффекты, изолировать проблему с минимальными
затратами на воспроизведение и исправить потенциальные
дефекты по мере необходимости, или решать проблемы другими
способами;

2019 г.
61
• Обеспечить руководителей тестирования инструментами
отслеживания качества продукта и влияния на тестирование
(например, если сообщается о большом количестве дефектов, то
тестировщики будут вынуждены тратить много времени на
отчетность по найденным дефектам вместо того, чтобы запускать
тесты; следовательно, нужно больше подтверждающего
тестирования);
• Предоставить идеи для совершенствования процессов
тестирования и разработки.
Отчет по инциденту – документ, описывающий событие, которое
произошло, например, во время тестирования, и которое необходимо
исследовать. [ IEEE 829]

2019 г.
62
Сообщение о дефекте обычно включает:
• Идентификатор дефекта;
• Заголовок и краткое описание найденного дефекта;
• Дату сообщения о дефекте, информацию об авторе сообщения;
• Идентификацию элемента тестирования (проверяемого элемента
конфигурации) и среды;
• Фазу жизненного цикла разработки, в которой обнаружен дефект;
• Описание дефекта, достаточное для его воспроизведения и
принятия решения, включая системные журналы, скриншоты,
дампы базы данных или записи (если они созданы во время
выполнения теста);
• Ожидаемые и фактические результаты;

2019 г.
63
• Область или степень влияния дефекта на интересы
заинтересованной стороны (критичность);
• Срочность / приоритет для исправления;
• Статус дефекта (например, открыт, отложен, дубликат, ожидает
исправления, ожидает проверки, повторно открыт, закрыт);
• Выводы, рекомендации и согласования;
• Глобальные проблемы, например, области, которые будут
затронуты исправлением дефекта;
• История изменений, например, последовательность действий
членов команды проекта, чтобы изолировать дефект, исправить и
подтвердить исправление дефекта;
• Ссылки, включая ссылку на тестовый сценарий, который обнаружил
дефект.

2019 г.
64
Идентификатор №
Короткое описание
Короткое описание проблемы, явно указывающее на причину и тип ошибочной
ситуации.
Проект Название тестируемого проекта.
Компонент приложения Название части или функции тестируемого продукта.
Номер версии Версия на которой была найдена ошибка.
Серьезность
Наиболее распространена пятиуровневая система градации серьезности дефекта:
Блокирующий, Критический, Значительный, Незначительный, Тривиальный.
Приоритет Приоритет дефекта: Высокий, Средний, Низкий.
Статус Статус дефекта.
Автор Создатель отчета о дефекте.
Назначен на Имя сотрудника, назначенного на решение проблемы.
Окружение
ОС / Сервис Пак и т.д. /
Браузера + версия / ...
Информация об окружении, на котором был найден дефект: операционная система,
сервис пак, для WEB тестирования - имя и версия браузера и т.д.
...
Описание
Шаги воспроизведения Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат Результат, полученный после прохождения шагов к воспроизведению.
Ожидаемый результат Ожидаемый правильный результат.
Дополнения
Прикрепленный файл.
Файл с логами, скриншот или любой другой документ, который может помочь прояснить
причину ошибки или указать на способ решения проблемы.

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

Спасибо за внимание!
Вопросы?

Istqb lesson 5

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Istqb lesson 5

Similar to Istqb lesson 5 (20)

Istqb lesson 5