2. Пройти документацию Postman и записать исполнение на видео:
● https://learning.postman.com/docs/getting-started/installation-and-updates/
● https://learning.postman.com/docs/getting-started/sending-the-first-request/

3. Подготовиться к тесту по теме.

Определение баг репорта
Баг репорт (Bug Report) - это документ, описывающий ситуацию или
последовательность действий приведшую к некорректной работе объекта
тестирования, с указанием причин и ожидаемого результата.
На практике это карточка с заданием, которую завели багтрекинговой системе.
Система отслеживания багов (Bug Tracking System) - прикладное приложение,
которое помогает учитывать и контролировать баги, пожелания пользователей, а
также следить за процессом устранения этих ошибок и выполнения или
невыполнения пожеланий.

Как правило, баг трекинговой системой является общая для проекта система
отслеживания заданий (Task Tracking System).

Примеры TTS:
1. Jira
2. Trello
3. Redmine
4. Asana
5. Basecamp
6. Bugzilla
7. ClickUp
8. Backlog
9. Bontq
10. YouTrack

Помимо багов туда вносятся запросы на новую функциональность (new feature
requests) и другие задачи технического и нетехнического характера.

Атрибуты баг-репорта
Атрибуты могут отличаться в зависимости от требований компании и проекта.

1. Название (Summary)
То поле, которое существует всегда. Краткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. Строится в формате “В какой части системы воспроизводится баг: что происходит и при каких условиях”.
Есть такое выражение: прочитав короткое описание бага, разработчик должен
понять в чем состоит проблема, прочитав детальное описание бага - знать строку
кода, которую править.

2. Проект (Project)
Название тестируемого проекта. Не обязательно, если проект один.

3. Компонент приложения (Component)
Название модуля или функции тестируемого продукта. Не обязательно, так как
зачастую достаточно информации в саммари.

4. Версия (Version)
Версия приложения, на которой была найден баг. Указывается, если это необходимо для его определения. Помимо версии может указываться сборка (Build) или ветка (Branch).

5. Важность(Severity)
Это атрибут, характеризующий влияние дефекта на работоспособность приложения. Подробнее разберём в следующей части.

6. Приоритетность(Priority)

Приоритет выполнения задания по исправлению бага. Подробнее разберём в
следующей части.

7. Статус бага (Status)
Зависит от BTS и используемой методологии разработки.

8. Автор (Author)
Создатель баг репорта. В BTS, как правило присваивается и сохраняется
автоматически.

9. Ответственный за исправление (Assigned To)
Имя разработчика, назначенного на исправление проблемы. Иногда ответственного назначает PM (для этого бывает необходимым саначала назначить ответственным PM) или сами разработчики “ассайнятся” на выполнение задания.

10. Окружение (Environment)
Как правило, это информация о браузере и операционной системе. Может быть не обязательным, если баг не чувствителен к изменению среды.

11. Шаги воспроизведения (Steps)
Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. Их детализация зависит от стабильности состава и осведомлённости в работе с
разработываемым приложением участников команды. Чем детализированнее
расписаны шаги (в пределах здравого смысла), тем меньше вероятность двоякого понимания содержания бага. Чаще всего является обязательным полем.

12. Фактический результат (Result)
Что происходит после выполнения шагов. Является обязательным полем.

13. Ожидаемый результат (Expected Result)
Что конкретно должно происходить после выполнения шагов. Является
обязательным полем. В идеале ожидаемый результат может быть один, но на практике их бывает несколько. Если необходима аргументация, то мы приводим
ссылку на спецификацию или другой проектный документ с указанием требования, официально утверждённые общепринятые мировые стандарты, примеры из других наиболее известных приложений. Также тестировщик может основываться только на личном опыте. В случае возникновения спорных ситуаций, за решением необходимо обращаться к BA и/или PM.

14. Вложения (Attachments)
Файлы, которые могут помочь в воспроизведении бага или указать на способ
решения проблемы: файлы логов, скриншоты с разметкой и Dev Tools (об этом в
другой теме), видео воспроизведения багов, файлы необходимые для загрузки в
форму, связанная с заданием необходимая проектная документация.
При описании бага, старайтесь не использовать сленг, сокращения, аббревиатуры, не ссылайтесь в шагах на другие таски (задания), спецификацию. Используйте разметку текста, если необходимые поля не предусмотрены или не настроены в BTS.

Важность бага

Также понимается как серьёзность бага. Проставляется тестировщиком.
Градация важности
S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или её ключевой функциональностью становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.

S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в
системе безопасности, проблема, приведшая к временному падению сервера или
приводящая в нерабочее состояние некоторую часть системы, без возможности

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

S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.

S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части
приложения, очевидная проблема пользовательского интерфейса.

S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо
воспроизводимая проблема, малозаметная посредствам пользовательского
интерфейса, проблема сторонних библиотек или сервисов, проблема, не
оказывающая никакого влияния на общее качество продукта. Зачастую такие баги даже не вносят в BTS. Иногда называется Enhancement (небольшая
поправка-улучшение), но не путать с Improvement - улучшение, которое достаточно значительно меняет бизнес-логику существующей функциональности или заметно изменяет UI.

Зачастую используется не пятиуровневая, а четырёхуровневая (например: Blocker, Critical, Major, Minor) или даже трёхуровневая (например: Major, Medium, Minor).
Названия статусов важности могут быть кастомизированы (изменены в зависимости от проекта).
Хорошим тоном считается внесение багов всех уровней важности, потому что баг
маленькой важности может обладать высоким приоритетом, однако и тут следует ориентироваться на правила принятые на проекте по соглашению между его участниками.

Приоритетность бага

Приоритет бага определяет порядок его исправления. Обычно проставляется PM, но зависит от проекта. Также в зависимости от проекта статусов приоритета бага может быть больше или меньше и называться они могут по-другому (например, тут тоже могут быть блокеры или такой статус приоритета как Moderate), либо может ставиться только высокий приоритет или не ставиться вовсе, но рассмотрим наиболее общепринятый вариант.

Градация приоритетности
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является
критической для проекта.

P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует
обязательного решения.

P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Также в работе вы можете услышать или использовать такие понятия:
● Hotfix (хотфикс - “горячее исправление”) - максимально быстро выполненное
исправление, когда влияние бага настолько велико, что нельзя было
откладывать его исправление, тестирование и релиз ни на минуту. Например,
после релиза выяснилось, что каким-то образом на лайф окружение
просочился блокирующий или критический баг и его нужно исправить прямо
сейчас, тогда делается hotfix.
● ASAP (As Soon As Possible, АСАП - как можно скорее) - запрос выполнения задания в кратчайшие сроки. Может исходить от PM или заказчика / CEO.
Обработанный и утверждённый запрос будет являтся самым приоритетным из

всех (исключение - масштабный блокер, который покрывает основную или
бóльшую часть приложения). Он же может быть Immediate.