# Этапы тестирования
### Содержание
* #### [**Этап 1: Оценка плана разработки и состояния проекта**](#h-1-1)
* #### [**Этап 2: Разработка плана тестирования**](#h-2-1)
* #### [**Этап 3: Сбор требований**](#h-3-1)
* #### [**Этап 4: Тест-дизайн**](#h-4-1)
* #### [**Этап 5: Тестирование билда**](#h-5-1)
* #### [**Этап 6: Выполнение тестов и фиксация результатов**](#h-6-1)
* #### [**Этап 7: Приемочное тестирование**](#h-7-1)
* #### [**Этап 8: Репорты и результаты тестов**](#h-8-1)
* #### [**Этап 9: Установка продукта**](#h-9-1)
* #### [**Этап 10: Корректировки**](#h-10-1)
* #### [**Этап 11: Оценка эффективности тестирования**](#h-11-1)
#### **Этап 1: Оценка плана разработки и состояния проекта**
Предварительный этап, в котором задействуются *верификация*, *валидация* и *план тестирования*. На этом этапе тестировщики, со своей точки зрения, оценивают полноту и корректность *плана разработки*, включая тестирование. Основываясь на *расширяемости* и *полноте плана проекта*, тестировщики оценивают количество ресурсов, которые будут выделять на тестирование в этом проекте.
#### **Этап 2: Разработка плана тестирования**
Создание плана тестирования вполне стандартный процесс, не выходящий за рамки общего паттерна *планирования* программных продуктов. Структура плана тестирования описывается [стандартом IEEE](https://testengineer.ru/chto-takoe-test-plan-i-kak-ego-napisat/#:~:text=%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BD%D0%BE%20%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D1%83%20IEEE%20829%2C%20%D1%82%D0%B5%D1%81%D1%82%20%D0%BF%D0%BB%D0%B0%D0%BD%20%D0%B4%D0%BE%D0%BB%D0%B6%D0%B5%D0%BD%20%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D1%82%D1%8C%20%D0%B8%D0%B7%2019%20%D0%BF%D1%83%D0%BD%D0%BA%D1%82%D0%BE%D0%B2), контекст зависит от проекта, и от скиллов команды.
#### **Этап 3: Сбор требований**
Неполные, неточные, несогласованные *требования* вызывают, возможно, большинство проблем в программных продуктах. Неспособность получить качественно сформулированные требования на 3-м этапе значительно увеличивает стоимость продукта и вызывает задержки. Тестировщики во время в*ерификации требований* должны гарантировать, что требования точные, полные, и не противоречат друг другу.
#### **Этап 4: Тест-дизайн**
Этап оценки как «внешнего», так и «внутреннего» дизайна, главным образом это техники верификации. QA-команда позаботится, чтобы планирование было эффективным, особенно что касается окружения и аппаратной части.
#### **Этап 5: Тестирование билда**
Метод, выбранный для билда продукта во внутреннем дизайн-документе, будет определять тип и объем тестирования, количество привлеченных тестировщиков. Если автоматизация внедрена в больших масштабах, понадобится меньше ручного тестирования на этом этапе. Если продукт делается по модели водопада, он довольно уязвим к ошибкам и должен будет проходить дополнительные *верификации*. В целом, значительно дешевле обнаруживать и устранять дефекты на раннем этапе разработки, чем на более позднем, во время *динамического тестирования*.
#### **Этап 6: Выполнение тестов и фиксация результатов**
Тестирование кода при его выполнении (то есть динамически). Подходы, методы, и инструменты, изложенные в *плане тестирования*, будут задействованы сейчас и покажут свою эффективность. Происходит проверка, соответствует ли выполняемый код требованиям, и *структурным спецификациям*.
#### **Этап 7: Приемочное тестирование**
Этап приемочного тестирования: конечные пользователи оценивают работоспособность и полезность приложения при выполнении его основных функций. Продукт проверяется *с точки зрения пользователя*, что может немного отличаться от задокументированных *требований*.
#### **Этап 8: Репорты и результаты тестов**
Репорты, то есть отчеты и промежуточные результаты в процессе тестирования, поступают постоянно. Репорт может быть как письменным, так и устным. Важно, чтобы дефекты и/или уточнения по продукту были зафиксированы как можно раньше, а значит корректировки были сделаны как можно раньше — это экономия времени и усилий.
#### **Этап 9: Установка продукта**
QA-команда подтвердила, что продукт готов к передаче в *продакшен*, тогда переходят к установке и тестированию в *прод-окружении* (в реальных условиях). Идет тестирование продукта в операционной системе, уточняется взаимодействие со связанными продуктами, и другие стандартные процедуры в реальном *окружении*.
#### **Этап 10: Корректировки**
Этап обслуживания/поддержки готового продукта, в том числе maintenance-тестированием. Требования к продукту могут изменяться/совершенствоваться и на этом позднем этапе, поэтому в тест-план могут вноситься изменения; корректировки/совершенствования продукта должны быть протестированы и оценены QA-командой.
#### **Этап 11: Оценка эффективности тестирования**
Финальный этап: оценка эффективности QA-команды на этом проекте. Оценивают сами тестировщики (точнее лиды), а еще лучше, если работу команды оценят разработчики, пользователи, и специалисты по качеству (QC), если такая должность [есть ](https://testengineer.ru/raznica-mezhdu-qa-i-qc/)в организации.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://qabook.gitbook.io/start/teoriya-testirovaniya/osnovy-testirovaniya/etapy-testirovaniya.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.