Управление качеством проекта ● Планирование управление качеством ● Определение и характеристики дефекта; ● Задачи управления дефектами; ● Классификация важности дефектов; ● Виды тестирования; ● Правильное описание дефекта; ● Жизненный цикл дефекта; ● Работа с базами дефектов; ● Метрики на основе дефектов. ● Составление тест плана

1. Управление проектами. Модуль .

2. Лекция 37-38
Управление качеством проекта
● Планирование управление качеством
● Определение и характеристики дефекта;
● Задачи управления дефектами;
● Классификация важности дефектов;
● Виды тестирования;
● Правильное описание дефекта;
● Жизненный цикл дефекта;
● Работа с базами дефектов;
● Метрики на основе дефектов.
● Составление тест плана

3. Что такое тестирование ПО?
Тестирование программного обеспечения — проверка соответствия
между реальным и ожидаемым поведением программы,
осуществляемая на конечном наборе тестов, выбранном
определенным образом. В более широком смысле, тестирование —
это одна из техник контроля качества, включающая в себя активности
по планированию работ (Test Management), проектированию тестов
(Test Design), выполнению тестирования (Test Execution) и анализу
полученных результатов (Test Analysis).
Цели тестирования
Повысить вероятность того, что приложение, предназначенное для
тестирования, будет работать правильно при любых обстоятельствах.
Повысить вероятность того, что приложение, предназначенное для
тестирования, будет соответствовать всем описанным требованиям.
Предоставление актуальной информации о состоянии продукта на
данный момент.

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

5. Принципы тестирования
Скопление дефектов
Разные модули системы могут содержать разное количество дефектов
– то есть, плотность скопления дефектов в разных элементах
программы может отличаться. Усилия по тестированию должны
распределяться пропорционально фактической плотности дефектов. В
основном, большую часть критических дефектов находят в
ограниченном количестве модулей. Это проявление принципа
Парето: 80% проблем содержатся в 20% модулей.
Парадокс пестицида
Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что
они находят все меньше новых ошибок. Поскольку система
эволюционирует, многие из ранее найденных дефектов исправляют и
старые тест-кейсы больше не срабатывают. Чтобы преодолеть этот
парадокс, необходимо периодически вносить изменения в
используемые наборы тестов, рецензировать и корректировать их с
тем, чтобы они отвечали новому состоянию системы и позволяли
находить как можно большее количество дефектов.

6. Принципы тестирования
Тестирование зависит от контекста
Выбор методологии, техники и типа тестирования будет напрямую зависеть от
природы самой программы. Например, программное обеспечение для
медицинских нужд требует гораздо более строгой и тщательной проверки, чем,
скажем, компьютерная игра. Из тех же соображений, сайт с большой
посещаемостью должен пройти через серьезное тестирование
производительности, чтобы показать возможность работы в условиях высокой
нагрузки.
Заблуждение об отсутствии ошибок.
Тот факт, что тестирование не обнаружило дефектов, еще не значит, что
программа готова к релизу. Нахождение и исправление дефектов будут не
важны, если система окажется неудобной в использовании, и не будет
удовлетворять ожиданиям и потребностям пользователя.
И еще несколько важных принципов:
● тестирование должно производиться независимыми специалистами;
● привлекайте лучших профессионалов;
● тестируйте как позитивные, так и негативные сценарии;
● не допускайте изменений в программе в процессе тестирования;
● указывайте ожидаемый результат выполнения тестов.

7. Принципы тестирования
Тестирование зависит от контекста
Выбор методологии, техники и типа тестирования будет напрямую зависеть от
природы самой программы. Например, программное обеспечение для
медицинских нужд требует гораздо более строгой и тщательной проверки, чем,
скажем, компьютерная игра. Из тех же соображений, сайт с большой
посещаемостью должен пройти через серьезное тестирование
производительности, чтобы показать возможность работы в условиях высокой
нагрузки.
Заблуждение об отсутствии ошибок.
Тот факт, что тестирование не обнаружило дефектов, еще не значит, что
программа готова к релизу. Нахождение и исправление дефектов будут не
важны, если система окажется неудобной в использовании, и не будет
удовлетворять ожиданиям и потребностям пользователя.
И еще несколько важных принципов:
● тестирование должно производиться независимыми специалистами;
● привлекайте лучших профессионалов;
● тестируйте как позитивные, так и негативные сценарии;
● не допускайте изменений в программе в процессе тестирования;
● указывайте ожидаемый результат выполнения тестов.

8. Bug, Error, Failure?
● Дефект, Баг (Defect, Bug) – недостаток компонента или системы,
который может привести к отказу определенной функциональности.
Дефект, обнаруженный во время исполнения программы, может
вызвать отказ отдельного компонента или всей системы.
● Ошибка (error) – это действие человека, которое порождает
неправильный результат.
● Сбой (failure) – несоответствие фактического результата (actualresult)
работы компонента или системы ожидаемому результату
(expectedresult)
Всего существует несколько источников дефектов и, соответственно, сбоев:
● ошибки в спецификации, дизайне или реализации программной
системы;
● ошибки использования системы;
● неблагоприятные условия окружающей среды;
● умышленное причинение вреда;
● потенциальные последствия предыдущих ошибок, условий или
умышленных действий.

10. Фундаментальный процесс тестирования
● Планирование и управление
Планирование тестирования включает действия, направленные на определение основных целей
тестирования и задач, выполнение которых необходимо для достижения этих целей.
В процессе планирования мы убеждаемся в том, что мы правильно поняли цели и пожелания
заказчика и объективно оценили уровень риска для проекта, после чего ставим цели и задачи для,
собственно, тестирования.
Для более ясного описания целей и задач тестирования составляются такие документы как тест-
политика, тест-стратегия и тест-план.
Тест-политика – высокоуровневый документ, описывающий принципы, подходы и основные
цели компании в сфере тестирования.
Тест-стратегия– высокоуровневый документ, содержащий описание уровней тестирования и
подходов к тестированию в пределах этих уровней. Действует на уровне компании или программы
(одного или больше проектов).
Тест-план – документ, описывающий средства, подходы, график работ и ресурсы, необходимые
для проведения тестирования. Помимо прочего, определяет инструменты тестирования,
функциональность, которую требуется протестировать, распределение ролей в команде, тестовое
окружение, используемые техники тест-дизайна, критерии начала и окончания тестирования и
риски. То есть, это подробное описание всего процесса тестирования.
В любой деятельности, управление не заканчивается планированием. Нам нужно контролировать и
измерять прогресс. Именно поэтому управление тестированием – непрерывный процесс.
Управление тестированием – сопоставление текущей ситуации в процессе тестирования с
планом и составление отчетности.

11. Фундаментальный процесс тестирования
● Анализ и проектирование
Анализ и проектирование тестов – это процесс написания тестовых сценариев и
условий на основе общих целей тестирования.
В процессе анализа и проектирования мы разрабатываем тестовые сценарии на
основании общих целей тестирования, определенных во время планирования.
Тестовый сценарий – документ, определяющий установленную
последовательность действий при выполнении тестирования.
● Внедрение и реализация
Во время выполнения тестирования происходит написание тест-кейсов, на
основе написанных ранее тестовых сценариев, собирается необходимая для
проведения тестов информация, подготавливается тестовое окружение и
запускаются тесты.
Тест-кейс – документ, содержащий набор входных значений, пред- и
постусловий, а также ожидаемый результат проведения теста, разработанный
для проверки соответствия определенной функциональности системы заданным
для этой функциональности требованиям.
Тестовое окружение – аппаратное и программное обеспечение и другие
средства, необходимые для выполнения тестов.

12. Фундаментальный процесс тестирования
● Оценка критериев выхода и написание отчетов
Критерии выхода определяют, когда можно завершать тестирование. Они необходимы для каждого
уровня тестирования, поскольку нам необходимо знать, достаточно ли было проведено тестов.
При оценке критериев выхода необходимо:
● проверить, было ли проведено достаточное количество тестов, достигнута ли нужная степень
обеспечения качества системы.
● убедится в том, что нет необходимости проводить дополнительные тесты. Если все же такая
необходимость есть, возможно, потребуется изменить установленный критерий выхода.
После окончания тестирования происходит написание отчета, который будет доступен всем
заинтересованным сторонам. Ведь не только тестировщики должны знать результаты выполнения
тестов, – эта информация может быть необходима многим участникам процесса создания ПО.
● Действия по завершению тестирования
При завершении тестирования мы собираем, систематизируем и анализируем информацию о его
результатах. Она может пригодиться позже – при выпуске готового продукта. Могут быть и другие
причины для сворачивания тестирования, например, досрочное закрытие проекта или завершение
определенного этапа разработки.
Основные цели этого этапа:
● убедиться, что вся запланированная функциональность действительно была реализована;
● проверить, что все отчеты об ошибках, поданные ранее, были, так или иначе, закрыты;
● завершение работы тестового обеспечения, тестового окружения и инфраструктуры;
● оценить общие результаты тестирования и проанализировать опыт, полученный в его процессе.

13. Верификация vs валидация?
Верификация (Verification) — это статическая практика проверки документов, дизайна,
архитектуры, кода, т.д.
● Верификация — это процесс включающий в себя проверку Plans, Requirement Specifications,
Design Specifications, Code, Test Cases, Chek-Lists, etc.
● Верификация всегда проходит без запуска кода.
● Верификация использует методы — reviews, walkthroughs, inspections, etc.
● Верификация отвечает на вопрос “Делаем ли мы продукт правильно?”
● Верификация поможет определить, является ли программное обеспечение высокого
качества, но оно не гарантирует, что система полезна. Проверка связана с тем, что система
хорошо спроектирована и безошибочна.
● Верификация происходит до Validation.
Валидация (validation) – это процесс оценки конечного продукта, соответствует ли программное
обеспечение ожиданиям и требованиям клиента. Это динамический механизм проверки и
тестирования фактического продукта.
● Валидация всегда включает в себя запуск кода программы.
● Валидация использует методы, такие как тестирование Black Box, тестирование White Box и
нефункциональное тестирование.
● Валидация отвечает на вопрос “Делаем ли мы правильный продукт?”
● Валидация проверяет, соответствует ли программное обеспечение требованиям и
ожиданиям клиента.
● Валидация может найти ошибки, которые процесс Verification не может поймать.
● Валидация происходит после Verification.

14. Жизненный цикл дефекта
● Новый (New). Тестировщик нашел баг, дефект успешно занесен в «Bug-tracking» систему.
● Открыт (Opened). Баг либо автоматически, либо в ручную назначается на человека который должен её
проанализировать (обычно Project Manager). В зависимости от решения менеджера проекта, баг может быть:
— Отложен (Deferred). Исправление этого бага не несет ценности на данном этапе разработки или по другим,
отсрочивающим его исправление причинам.
— Отклонен (Rejected). По разным причинам дефект может и не считаться дефектом или считаться
неактуальным дефектом, что вынуждает отклонить его.
— Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему, то статус
такой ошибки меняется на «дубликат».
● Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build),
происходит назначение на разработчика который должен исправить ошибку.
Когда наличие дефекта неопровержимо, его путь может привести к следующим статусам:
● Исправлен (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.
В зависимости от того, исправил ли разработчик дефект, дефект может быть:
— Проверен (Verified). Тестировщик проверяет, действительно
ли ответственный разработчик исправил дефект, или все-таки
разработчик безответственный. Если бага больше нет, он
получает данный статус.
— Повторно открыт (Reopened). Если опасения тестировщика
оправданы и баг в новом версии не исправлен – он все так же
потребует исправления, поэтому заново открывается.
● Закрытый (Closed). В результате определенного количества циклов баг все-таки окончательно устранен и
больше не потребует внимания команды – он объявляется закрытым.

15. Классификация важности дефектов
● Серьезность (Severity) — это атрибут,
характеризующий влияние дефекта на
работоспособность приложения.
● Приоритет (Priority) — это атрибут,
указывающий на очередность выполнения
задачи или устранения дефекта.
● Можно сказать, что это инструмент менеджера
по планированию работ. Чем выше приоритет,
тем быстрее нужно исправить дефект.
● Severity выставляется тестировщиком
● Priority — менеджером, тимлидом или
заказчиком

16. Градация Серьезности дефекта (Severity)
● S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате
которого дальнейшая работа с тестируемой системой или ее ключевыми функциями
становится невозможна. Решение проблемы необходимо для дальнейшего
функционирования системы.
● S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе
безопасности, проблема, приведшая к временному падению сервера или приводящая в
нерабочее состояние некоторую часть системы, без возможности решения проблемы,
используя другие входные точки. Решение проблемы необходимо для дальнейшей работы
с ключевыми функциями тестируемой системой.
● S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не
критична или есть возможность для работы с тестируемой функцией, используя другие
входные точки.
● S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения,
очевидная проблема пользовательского интерфейса.
● S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая
проблема, малозаметная посредствам пользовательского интерфейса, проблема
сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на
общее качество продукта.

17. Градация Приоритета дефекта (Priority)
● P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее,
т.к. ее наличие является критической для проекта.
● P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не
является критичной, но требует обязательного
решения.
● P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не
является критичной, и не требует срочного решения.
● С помощью такой классификации организована работа
многих систем отслеживания ошибок, в том числе Jira.

18. Виды тестирования

19. Уровни тестирования
● Модульное тестирование (Unit Testing)
Компонентное (модульное) тестирование проверяет
функциональность и ищет дефекты в частях приложения,
которые доступны и могут быть протестированы по-отдельности
(модули программ, объекты, классы, функции и т.д.).
● Интеграционное тестирование (Integration Testing)
Проверяется взаимодействие между компонентами системы
после проведения компонентного тестирования.
● Системное тестирование (System Testing)
Основной задачей системного тестирования является проверка
как функциональных, так и не функциональных требований в
системе в целом. При этом выявляются дефекты, такие как
неверное использование ресурсов системы,
непредусмотренные комбинации данных пользовательского
уровня, несовместимость с окружением, непредусмотренные
сценарии использования, отсутствующая или неверная
функциональность, неудобство использования и т.д.

20. Уровни тестирования
● Операционное тестирование (Release Testing).
Даже если система удовлетворяет всем требованиям, важно убедиться в том,
что она удовлетворяет нуждам пользователя и выполняет свою роль в среде
своей эксплуатации, как это было определено в бизнес моделе системы.
Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так
важно провести операционное тестирование как финальный шаг валидации.
Кроме этого, тестирование в среде эксплуатации позволяет выявить и
нефункциональные проблемы, такие как: конфликт с другими системами,
смежными в области бизнеса или в программных и электронных
окружениях; недостаточная производительность системы в среде
эксплуатации и др. Очевидно, что нахождение подобных вещей на стадии
внедрения — критичная и дорогостоящая проблема. Поэтому так важно
проведение не только верификации, но и валидации, с самых ранних этапов
разработки ПО.
● Приемочное тестирование (Acceptance Testing)
Формальный процесс тестирования, который проверяет соответствие
системы требованиям и проводится с целью:
• определения удовлетворяет ли система приемочным критериям;
• вынесения решения заказчиком или другим уполномоченным лицом
принимается приложение или нет.

21. Уровни тестирования
● Функциональные виды тестирования
Функциональное тестирование (Functional testing)
Тестирование безопасности (Security and Access Control Testing)
Тестирование взаимодействия (Interoperability Testing)
● Нефункциональные виды тестирования
Все виды тестирования производительности:
● нагрузочное тестирование (Performance and Load Testing)
● стрессовое тестирование (Stress Testing)
● тестирование стабильности или надежности (Stability / Reliability Testing)
● объемное тестирование (Volume Testing)
Тестирование установки (Installation testing)
Тестирование удобства пользования (Usability Testing)
Тестирование на отказ и восстановление (Failover and Recovery Testing)
Конфигурационное тестирование (Configuration Testing)
● Связанные с изменениями виды тестирования
Дымовое тестирование (Smoke Testing)
Регрессионное тестирование (Regression Testing)
Повторное тестирование (Re-testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

22. Подходы к интеграционному тестированию
● Снизу вверх (Bottom Up Integration)
Все низкоуровневые модули, процедуры или функции собираются воедино и
затем тестируются. После чего собирается следующий уровень модулей для
проведения интеграционного тестирования. Данный подход считается
полезным, если все или практически все модули, разрабатываемого уровня,
готовы. Также данный подход помогает определить по результатам
тестирования уровень готовности приложения.
● Сверху вниз (Top Down Integration)
Вначале тестируются все высокоуровневые модули, и постепенно один за
другим добавляются низкоуровневые. Все модули более низкого уровня
симулируются заглушками с аналогичной функциональностью, затем по мере
готовности они заменяются реальными активными компонентами. Таким
образом мы проводим тестирование сверху вниз.
● Большой взрыв («Big Bang» Integration)
Все или практически все разработанные модули собираются вместе в виде
законченной системы или ее основной части, и затем проводится
интеграционное тестирование. Такой подход очень хорош для сохранения
времени. Однако если тест кейсы и их результаты записаны не верно, то сам
процесс интеграции сильно осложнится, что станет преградой для команды
тестирования при достижении основной цели интеграционного тестирования.

23. Тест дизайн и техники
Тест –дизайн - это этап процесса тестирования ПО, на
котором проектируются и создаются тестовые случаи (тест
кейсы), в соответствии с определёнными ранее критериями
качества и целями тестирования.
Роли, ответственные за тест дизайн:
Тест аналитик — определяет «ЧТО тестировать?»
Тест дизайнер — определяет «КАК тестировать?»
Техники тест –дизайна:
● Эквивалентное Разделение (Equivalence Partitioning — EP).
● Анализ Граничных Значений (Boundary Value Analysis —
BVA).
● Причина / Следствие (Cause/Effect — CE).
● Предугадывание ошибки (Error Guessing — EG)
● Исчерпывающее тестирование (Exhaustive Testing — ET)

24. Test case
Test Case – это тестовый артефакт, суть которого заключается в
выполнении некоторого количества действий и/или условий,
необходимых для проверки определенной функциональности
разрабатываемой программной системы.
Структура данного артефакта заключается в «троице»:
Выполняемое действие (Action) – Ожидаемый результат (Expected
result) – Фактический результат (Test result).
Непосредственно сам тестовый случай состоит из 3 частей:
• PreConditions(Предусловия) – либо список шагов, которые приводят
проверяемую систему в состояние, пригодное для тестирования, либо
список проверок условий того, что система уже находиться в
необходимом состоянии.
• Test Case Description(Описание тестового случая) – список действий,
с помощью которых осуществляется основная проверка функционала
(после которой и сверяется фактический результат с ожидаемым).
• PostConditions(Постусловия) –список действий, которые возвращают
систему в исходное состояние.

25. Test plan
Тест-план (Testplan, план тестирования) – это документ, описывающий
весь объем работ по тестированию, начиная с описания тестируемых
объектов, стратегии, расписания, критериев начала и окончания
тестирования, до необходимого в процессе работы оборудования,
специальных знаний, а также оценки рисков с вариантами их
разрешения. Могут входить следующие пункты:
● Перечень областей тестирования с приоритетами.
● Стратегия тестирования.
● Перечень возможных рисков.
● Перечень необходимых ресурсов.
● План выполнения проекта.
● Общая информация о проекте (ссылки на документацию, баг-
трекеры, и т.д.)
● Положения, описывающие процесс тестирования, заведения
дефектов и т.д.
● Критерии готовности продукта к выпуску.

26. Bug report
● Дефект (он же баг) – это несоответствие фактического
результата выполнения программы ожидаемому
результату. Дефекты обнаруживаются на этапе
тестирования программного обеспечения (ПО), когда
тестировщик проводит сравнение полученных результатов
работы программы (компонента или дизайна) с
ожидаемым результатом, описанным в спецификации
требований.
● Баг репорт (bugreport) – это технический документ,
который содержит в себе полное описание бага,
включающее информацию, как о самом баге (короткое
описание, серьезность, приоритет и т.д.), так и о условиях
возникновения данного бага. Баг репорт должен содержать
правильную, единую терминологию, описывающую
элементы пользовательского интерфейса и события
данных элементов, приводящих к возникновению бага.

27. Bug report(структура)• Шапка
• Короткое описание (Summary) Короткоеописание проблемы, явно указывающеена причину и тип
ошибочной ситуации.
• Проект (Project) Названиетестируемого проекта
• Компонент приложения (Component) Названиечасти или функции тестируемого продукта
• Номер версии (Version) Версия на которой была найдена ошибка
• Серьезность(Severity) Наиболее распространена пятиуровневаясистема градации серьезности
дефекта:
• Приоритет (Priority) Приоритет дефекта:
• Статус (Status)Статус бага. Зависит от используемой процедурыи жизненного цикла бага (bug
workflow and life cycle)
• Автор (Author) Создатель баг репорта
• Назначенна (Assigned To) Имя сотрудника,назначенного на решение проблемы
• Окружение
• ОС / Сервис Пак и т.д. / Браузера+ версия /… Информация об окружении,на котором был найден баг:
операционнаясистема, сервис пак, для WEB тестирования — имя и версия браузераи т.д.
• Описание
• Шаги воспроизведения(Steps to Reproduce)Шаги, по которым можно легко воспроизвести ситуацию,
приведшую к ошибке.
• Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению
• Ожидаемый результат (Expected Result) Ожидаемый правильныйрезультат
• Дополнения
• Прикрепленный файл (Attachment)Файл с логами, скриншот или любой другой документ, который
может помочь прояснить причину ошибки или указать на способ решения проблемы.

28. Матрица соотвествия требований
Это двумерная таблица, содержащая соответствие функциональных требований
(functional requirements) продукта и подготовленных тестовых сценариев (test
cases). В заголовках колонок таблицы расположены требования, а в заголовках
строк — тестовые сценарии. На пересечении — отметка, означающая, что
требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица обычно хранится в виде электронной таблицы.
Матрица соответствия требований используется QA-инженерами для валидации
покрытия требований по
продукту тестами. Цель
«Traceability Matrix» состоит
в том, чтобы выяснить:
● какие требования
«покрыты» тестами, а какие нет.
● избыточность тестов
(одно функциональное
требование покрыто
большим количеством тестов).

29. Тестирование vs QC vs QA