# Тестирование

:::info
[Презентации + Лабораторные](https://yadi.sk/d/v9_CDxeEAhI2dQ). Википедия в 80% случаев даёт верные ответы
:::

:::spoiler <b>Содержание</b>
[TOC]
:::

## Лекция для подготовки к экзамену

OBS перепутал красный и синий каналы, не обращайте внимания :slightly_smiling_face:
Бонус: теперь вы знаете, как были выбраны цвета интерфейса Microsoft Office

{%youtube 6UGSSvJzCjU%}

## Вопросы

### ✔️ 1. Что является объектом тестирования?

**Объект тестирования** -- некоторое **Программное Обеспечение** или **Программный Продукт**.

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

### ✔️ 2. Чем отличается коробочный продукт от заказного продукта?

**Коробочный программный продукт** — это программное обеспечение, предназначенное для неопределённого круга покупателей и поставляемое на условиях «как есть», со стандартными для всех покупателей функциями.

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

### ✔️ 3. Перечислите основные этапы процесса разработки ПП. Какова основная задача каждого из них?

1. **Планирование** — Project Manager разрабатывает **план проекта** (процесса разработки, включая финансы, риски, ресурсы и прочее). План включает в себя анализ всех последующих этапов.
2. **Сбор и анализ требований** — аналитики формируют **требования**.
3. **Проектирование архитектуры** — системный архитектор готовит **список необходимых технологий**, применяемых на уровне реализации.
4. **Разработка** — разработчики создают **код и сопровождающую документацию**.
5. **Тестирование** — тестировщики создают **тест-кейсы и отчеты о найденных дефектах**.
6. **Документирование** — технический писатель пишет **документацию для конечного пользователя**.
7. **Внедрение и сопровождение** — настройка окружения, разворачивание системы в конечном окружении (внедрение), консультации и ответы на вопросы, исправление дефектов, найденных пользователями (сопровождение). За это отвечают почти все в команде (кроме, разве что, технического писателя, если нет ошибок в документации).
8. **(опционально) Вывод из эскплуатации**

**Последовательность этапов определяет модель жизненного цикла**.

### ✔️ 4. С какими процессами взаимодействует процесс тестирования?

1. **Планирование** — Выделение времени на тестирование. Тест-лид должен предоставить информацию о плане тестирования
2. **Сбор и анализ требований** — Необходимо знать требования, чтобы их проверять
3. *Проектирование архитектуры* — Спорно, потому что знание архитектуры возможно для серого ящика, для чёрного ящика не нужно
4. **Разработка** — Уточнение реализации, доклады разработчикам о дефектах
5. *Документирование* — Тестировщики могут помочь документаторам разобраться с тем, как работает продукт. Также тестировщики могут заниматься верификацией документации.
6. **Внедрение и сопровождение** — Проверка результата разворачивания системы и работа с дефектами во время сопровождения

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

### ✔️ 5. Что такое проект? Перечислите основные роли в проекте?

**Проект** — предприятие с определёнными датами начала и завершения, предпринятое для создания продукта или услуги в соответствии с заданными ресурсами и требованиями к качеству.

Основные роли в проекте:
1. **Product Manager** — задает **стратегию развития** продукта. Работает с пожеланиями потребителей и анализирует рынок.
2. **Project Manager** — руководитель проектной команды, ответственный за **управление проектом, достижение целей проекта** в рамках бюджета, в срок и с заданным уровнем качества. Отличие Product менеджера от Project менеджера в том, что первый придумывает, какие новые функции добавить в продукт, а второй ставит задачи своим подчиненным реализовать новые функции и сообщает продукт менеджеру о сроках, когда эти функции будут готовы.
3. **Архитектор** — принимает решения относительно **внутреннего устройства** программной системы и её технических интерфейсов.
4. **Бизнес аналитик** — напрямую общается с заказчиками продукта и выясняет их **пожелания и требования**.
5. **Системный аналитик** — занимается, в основном, анализом данных и принятием решений о том, **как будет работать система**, какие методы будут использоваться, а также написанием основных технических документов (**техническое задание, спецификации**). Важная часть работы — функциональный анализ, в результате которого выделяется перечень функций, которые должна выполнять система, а также определение требований к системе.
6. **Технический писатель** — специалист, который занимается составлением **документации** для конечного пользователя.
7. **Проектировщик** — занимается построением **макетов создаваемой системы** с учетом удобства ее использования, превращает описанные в ТЗ функции в панели инструментов, кнопки, поля, таблицы и прочее, что видит и с чем взаимодействует пользователь. Результат его работы — макет, как правило черно-белый без графических элементов, который показывает расположение элементов интерфейса и возможные переходы между элементами и страницами (экранами) продукта.
8. **Дизайнер** — прорабатывает все элементы макетов системы, определяя форму, цвета, размер элементов, шрифты, прорисовывают **графические элементы** (картинки, баннеры, логотип), которые должны присутствовать в продукте.
9. **Разработчик** — специалист, занимающийся разработкой **программного обеспечения**.
10. **Тестировщик** — специалист, который занимается тестированием программного обеспечения (ПО) с целью **выявления ошибок** в его работе для их последующего исправления.
11. **Локализатор** — специалист, занимающийся **адаптацией ПО** к национальным особенностям страны.
12. **Заказчик** — сторона, заинтересованная в осуществлении проекта и достижении его целей. **Будущий владелец результатов** проекта.
13. **Пользователи** — юридические и физические лица, являющиеся покупателями и пользователями результата проекта, **определяющие требования** к производимой продукции и оказываемым услугам, формирующие спрос на них.

### ✔️ 6. Что такое жизненный цикл ПП?

**Жизненный цикл программного обеспечения** — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

### ✔️ 7. Какие модели жизненного цикла ПП Вы можете назвать (дайте краткую характеристику каждой модели, когда ее можно применять, когда не следует)?

В лекции называли эти три.

1. **Каскадная (водопадная) модель** (англ. waterfall model) — модель процесса разработки ПО, жизненный цикл которой выглядит как поток, **последовательно** проходящий фазы **анализа требований, проектирования, реализации, тестирования, внедрения и сопровождения**. Каскадная модель хорошо зарекомендовала себя при построении относительно простых ПО, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к продукту.

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

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

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

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

3. **Итерационные (Agile) методологии** — нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых **итерациями**, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект **готов к выпуску в конце каждой итерации**. По окончании каждой итерации команда выполняет **переоценку приоритетов разработки**.

**Модель выбирается на этапе планирования**

### ✔️ 8. Какую модель ЖЦ можно применять при условии частых изменений в требованиях? Основные принципы Agile методологий?

Итерационную (Agile) модель

**Основные идеи:**

1. **Люди и взаимодействие** важнее процессов и инструментов
2. **Работающий продукт** важнее исчерпывающей документации
3. **Сотрудничество с заказчиком** важнее согласования условий контракта
4. **Готовность к изменениям** важнее следования первоначальному плану

**Основные принципы:**

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

### ✔️ 9. Каковы преимущества и недостатки каскадной модели?

Ответ из консультации выделен жирным

**Достоинства модели:**

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

**Недостатки модели:**

1. Сложность чёткого формулирования требований и **невозможность их динамического изменения** на протяжении всего жизненного цикла
2. Низкая гибкость в управлении проектом
3. Последовательность линейной структуры процесса разработки, в результате возврат к предыдущим шагам для решения возникающих проблем приводит к **увеличению затрат и нарушению графика работ**
4. Непригодность промежуточного продукта для использования
5. Невозможность гибкого моделирования уникальных систем
6. **Позднее обнаружение проблем**, связанных со сборкой, в связи с одновременной интеграцией всех результатов в конце разработки
7. Недостаточное участие пользователя в создании системы — в самом начале (при разработке требований) и в конце (во время приёмочных испытаний)
8. Пользователи не могут убедиться в качестве разрабатываемого продукта до окончания всего процесса разработки. Они не имеют возможности оценить качество, т. к. нельзя увидеть готовый продукт разработки
9. У пользователя нет возможности постепенно привыкнуть к системе. Процесс обучения происходит в конце жизненного цикла, когда ПО уже запущено в эксплуатацию;
10. Каждая фаза является предпосылкой для выполнения последующих действий, что превращает такой метод в рискованный выбор для систем, не имеющих аналогов, т. к. он не поддается гибкому моделированию

### ✔️ 10. Кто определяет цели и задачи тестирования в проекте?

**Тест-лид** (ну или команда тестирования во главе с тест-лидом). Не менеджер проекта, так как процесс тестирования независим (цели и задачи, конечно определяются с учетом всего проекта, но не более).

### ✔️ 11. Кто формулирует требования к продукту?

**Заказчик**. Либо менеджер, если берет ответственность на себя за несогласованность с заказчиком (аналитики только собирают требования и обрабатывают).

### ✔️ 12. На что влияет качество существующих процессов?

В первую очередь на **качество продукта**. Затем уже на время и все остальное.

### ✔️ 13. Что влияет на выбор модели ЖЦ проекта?

1. Информация о продукте (масштаб, сложность)
2. Ожидания заказчика от проекта
3. Ограничения
4. Ожидания по качеству (высокие требования)
5. Готовность заказчика участвовать в разработке
6. Пожелания заказчика

### ✔️ 14. Что такое «тестирование»?

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

Процесс тестирования:
- **Планирование** (Test Planning)
- **Разработка тестов** (Test Case Design)
- **Аудит\Ревью тестов** (Test Case Review)
- **Выполнение тестов** (Test Case Execution)
- **Верификация исправленных дефектов** (Bug\Defects Fixes Verification)
- **Метрики и отчеты** (Test Reporting and Metrics Collection)

### ✔️ 15. Цели и задачи тестирования?

Она не ожидает что мы прям перечислим цели и выделим задачи. Не обязательно между собой разделять. Главный пойнт в том, что **мы (тестировщики) не можем обеспечить качество**, можем только проверить соответствие уровню качества. Соответсвенно нельзя говорить про обеспечение качества здесь.

Цели тестирования:
- Определение **степени соответствия требованиям** к функциональности и производительности
- Поиск **дефектов**
- **Предотвращение обнаружения** дефектов заказчиком
- Участие в процессе обеспечения качества
- Укладываться в сроки
- Следовать правилам команды тестировщиков

### ✔️ 16. В чем отличие тестирования от отладки?

Тестирование занимается **выявлением** ошибок, а отладка **выявлением и устранением** ошибок.

### ✔️ 17. Что такое Верификация (verification) и что такое Валидация (validation)?

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

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

Ответ из видео короче, по сути такой же.

### ✔️ 18. Какие стратегии\подходы тестирования Вы знаете? Перечислите их.

1. **Тестирование черного ящика** (поведенческое тестирование) — стратегия (метод) тестирования, в которой мы не используем знания о внутренней структуре системы для создания тест-кейсов и тестирования.
2. **Тестирование серого ящика** — мы используем часть знаний о системе, но основной подход похож на черный ящик.
3. **Тестирование белого ящика** — мы используем знания о системе при создании тест-кейсов и тестировании.

### ✔️ 19. Какие уровни тестирования Вы знаете? Перечислите их.

1. **Модульное(Unit testing)** - тестируются отдельные модули системы (модуль это минимальная единица кодирования, которую возможно проверить (метод, класс, функция, процедура)). Используется стратегия белого ящика.
2. **Интеграционное** - тест взаимодействия между этими юнитами. Используется стратегия белого ящика.
3. **Системное** - тестирования всей системы. Используется стратегия черного или серого ящика. В лабораторных у нас системное тестирование.
4. **Приемочное** - как системное, только тестируется в реальном окружении заказчиком/пользователями. Используется стратегия черного ящика.

Может быть ещё **Системно-интеграционное** - если система взаимодействует с другой системой.

Разделение на уровни производится по степени зрелости продукта.

### ✔️ 20. Какие виды тестирования Вы знаете? Перечислите их.

**По критерию запуска программы:**
1. **Статическое** - не запускаем код, просто читаем и ищем баги
2. **Динамическое** - проводим тестирование запуская приложения

**По принципу выполнения ТК:**
1. **Ручное** - не автоматизируется выполнение ТК
2. **Автоматизирование** - автоматизируется выполнение ТК. Автоматизация может быть на любом уровне тестирования

**По атрибутам продукта:**
1. **Функциональное тестирование**
1. Тестирование пользовательского интерфейса (GUI)
2. **Нефункциональное тестирование**
1. Тестирование производительности
2. Нагрузочное тестирование
3. Стрессовое тестирование
4. Юзабилити тестирование (тестирование удобства использования)
5. Тестирование безопасности
6. Тестирование локализации
7. Тестирование совместимости

**Еще виды тестирования:**
1. Тестирование инсталляции
2. Тестирование масштабируемости
3. Тестирование надежности

**Связанные с изменениями виды тестирования:**
1. **Регрессионное тестирование** - повторное выполнение тестов, которые были успешно выполнены ранее, при внесении любого изменения кода (новая функциональность, исправление дефектов, рефакторинг). Бывает полное и частичное. Определяете степень влияния изменений на функциональность, находите ТК на затронутую функциональность, тестируете в приоритете от самого важного до не важного пока хватает времени. Выполняется на этапе верификации исправленных дефектов.
2. **Дымовое тестирование (Smoke testing)** — тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции
3. **Повторное тестирование (Re-testing)** — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок. В отличие от регрессионного, проверяет только то, что баги исправлены. Регрессионное проверяет также что изменения не повлияли на другие модули ПО и не вызвали новые баги.
4. **Тестирование сборки (Build verification testing)** — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию
5. **Проверка согласованности (Sanity testing)** — это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования

**Виды изменений кода:**
1. Исправление дефектов
2. Добавление нового функционала
3. Рефакторинг

### ✔️ 21. Перечислите основные этапы процесса тестирования.

1. Планирование
2. Разработка ТК
3. Аудит ТК
4. Выполнение ТК и фиксация результата (успешно/неуспешно + отчёт о дефекте)
5. Верификация исправленных дефектов (обычно тут регрессионное тестирование)
6. Составление метрик и отчетов

### ✔️ 22. Что такое требования к ПО?

Задокументированные ожидания заказчика (Спецификации, user story)

### ✔️ 23. Какие бывают типы требований?

**Главные:**
1. Функциональные - что делает система
2. Не функциональные - как быстро/хорошо/красиво

**Дополнительно:**
1. Бизнес требования
2. Системные требования

### ✔️ 24. Что такое Test Case?

**Тест-кейс** - минимальный элемент тестирования. Отвечает следующим требованиям:
1. При разработке ТК мы думаем о том, какой дефект он должен найти (В отличие от тестового сценария - в нем несколько дефектов может быть найдено).
2. У ТК ожидаемый результат всегда после последнего шага (В отличие от тестового сценария).
3. Тест-кейс всегда имеет отношение к одному требованию или одной фиче (В отличие от сценария, который обычно покрывает несколько требований\фич).

### ✔️ 25. Что должно быть в описании тест-кейса (приведите пример)?

**Обязательно:**
1. Предусловие
2. Шаги
3. Ожидаемый результат

**Дополнительно:**
1. ID
2. Заголовок
3. Приоритет
4. Тип
5. Статус

### ✔️ 26. Что такое Test Matrix (Тестовая матрица)?

Набор тест кейсов, структурированный в виде таблицы. Позволяет наглядно отображать тест-кейсы.

### ✔️ 27. Что является источником\основанием для создания тест-кейсов?

Требования заказчика

### ✔️ 28. Какие техники создания тест-кейсов Вы знаете? Перечислите и опишите основную идею каждой из них.

**Техники Black box:**
1. Разбиение на классы эквивалентности
2. Анализ граничных значений
3. Таблица решений
4. Метод функциональных диаграмм
5. Техника предположения об ошибке

**Техники White box:**
1. Statement coverage -- каждый оператор должен быть выполнен хотя бы один раз
1. Вranch\Decision coverage -- каждое решение должно принять значения истина и ложь по крайней мере один раз и для каждой точки входа должно быть выдано управление хотя бы один раз (IF, CASE, Loop)
1. Control-Flow Based Testing -- строим блок-схему и проверяем каждый узел
1. Condition coverage -- все возможные результаты каждого решения в условии выполнялись хотя бы один раз (каждая компонента логического условия в результате выполнения тестовых примеров должна принимать все возможные значения) и каждой точке входа в программу или подпрограмму должно быть передано управление хотя бы один раз. Более сильный критерий, чем покрытие решений.
1. Data-Flow testing -- анализируем все переменные в коде: их определение (“definitions”\”write”) и использование (“uses”\”read”)

Может ли какой-то набор техник гарантировать полное покрытие тест кейсами? Нет, применяем всё, в том числе и интуицию тестировщика.

### ✔️ 29. Что такое «ошибка» (дефект, «баг»)?

Несоответствие ПО требованиям заказчика
Несоответствие полученного результата ожидаемому (На языке тест кейсов)

### ✔️ 30. Какая информация обязательно должна быть в отчете об ошибке, чтобы ее можно было воспроизвести?

**Основное:**
1. Предусловие
2. Шаги
3. Ожидаемый результат
4. Полученный результат
5. Окружение
6. Версия приложения

**Дополнительно:**
1. Заголовок
2. ID
3. severity - критичность дефекта (Степень влияния данного дефекта на работоспособость продукта)
4. Приоритет
5. Связь с требованием
6. Связь с ТК

### ✔️ 31. Приведите пример жизненного цикла ошибки.

1. Обнаружение
2. Исправляется
3. Исправлено
4. Тестируется
5. Протестировано
6. Закрыто

### ✔️ 32. Что такое Тест План?

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

### ✔️ 33. Что такое «Качество программного продукта»?

Степень соответствия программного продукта требованиям.

### ✔️ 34. Как можно описать качество ПП?

Измеряется следующим образом:
1. Реализация всех требований
2. Допустимое количество дефектов, которое может быть найдено заказчиком, и их критичность

### ✔️ 35. Назовите характеристики (атрибуты) ПП?

1. Функциональность
2. Безопасность
3. Надежность
4. Быстрота
5. Производительность
6. Масштабируемость

### ✔️ 36. Что такое «внешнее качество»?

То, что видит заказчик. Тестировщики в основном придают значения внешнему качеству.

### ✔️ 37. Что такое «внутреннее качество»?

Качество кода - эффективность/переносимость. То, что видит команда разработки.

### ✔️ 38<a title="Вопрос на пятерку">*</a>. Что такое Quality Assurance (Обеспечение качества)?

Процесс предотвращения дефектов путем **улучшения процессов**. Охватывает **все** процессы на **всех** этапах разработки для обеспечения необходимого уровня качества ПО.

Объектом являются процессы, **цель — предотвращение дефектов**

### ✔️ 39<a title="Вопрос на пятерку">*</a>. Каковы основные задачи, цели и Quality Control?

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

Объектом является продукт, задача — поиск дефектов с целью дальнейшего устранения

### ✔️ 40. К чему относится тестирование: Quality Assurance или Quality Control?

Тестирование относится к Quality Control. Вообще говоря, Тестирование входит в QC, QC входит в QA.

### ✔️ 41. Кто отвечает за качество продукта в проекте?

За принятие решений отвечает менеджер проекта. Но в общем понимании за обеспечение качества отвечает вся команда.

### ✔️ 42. Что такое «стоимость качества»?

Стоимость плохого качества - затраты на поиск и устранение дефектов.

Вообще говоря стоимость качества (Cost of Quality) - это метод определения затрат, связанных с обеспечением качества. Затраты на профилактику и затраты на оценку (затраты на соответствие) включают стоимость планирования качества, контроля качества и обеспечения качества для соответствия требованиям (т. е. обучение, системы контроля качества и т. д.).

### ✔️ 43. Какие системы управления качеством вы знаете?

Системы управления качеством содержат описание требований к процессам.

Сказала, что не нужно вдаваться в подробности. Назвала только эти две.
1. ISO
2. CMMI

### 🔄 44. Что такое «Комплексная модель производительности и зрелости процессов» (Capability Maturity Model Integration)?

**Комплексная модель производительности и зрелости** (Capability Maturity Model Integration, CMMI) – набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.

Подробнее тут — https://habr.com/ru/post/79130/

Ответ из видео:
Описание требований к процессу. Есть общая рекомендация но не говорится деталей реализации. Есть 5 уровней. Можно применять как к одному процессу, так и ко всем процессам.

Уровни CMM:
- Initial (Начальный) - успех зависит от героев, нет понимания о разделении на процессы
- Managed - есть понимание основных процессов, которые существуют (прояснение требований, план, разработка, тестирование, контроль прогресса)
- Defined - описаны и стандартизованы процессы, они общие для всех и им все следуют, проводится обучение
- Quantitively managed - собираем метрики, по которым можем оценить процессы
- Optimizing - можем думать о том, как оптимизировать процессы на основании собранных метрик