IT SHATLE Clienthttps://teletype.in/atom/itshatle2026-05-25T18:13:19.931Zitshatle:homework14qa2022-03-11T12:03:19.245Z2022-03-11T12:03:19.245Z

1. На примере какого либо веб-сайта найти GET и POST запросы. Сделать скриншоты и/или видео.

<p id="D1xC">1. На примере какого либо веб-сайта найти GET и POST запросы. Сделать<br />скриншоты и/или видео.</p> <p id="4MG4"><br />2. Пройти документацию Postman и записать исполнение на видео:<br />● <a href="https://learning.postman.com/docs/getting-started/installation-and-updates/" target="_blank">https://learning.postman.com/docs/getting-started/installation-and-updates/</a><br />● <a href="https://learning.postman.com/docs/getting-started/sending-the-first-request/" target="_blank">https://learning.postman.com/docs/getting-started/sending-the-first-request/</a></p> <p id="EsZn"><br />3. Подготовиться к тесту по теме.</p> itshatle:lecture9qa2022-03-10T08:28:13.087Z2022-03-10T08:49:32.899Z

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

<h3 id="oVbl">Определение и атрибуты баг репорта</h3> <p id="1y0p"></p> <p id="KyxH">Определение баг репорта<br />Баг репорт (Bug Report) - это документ, описывающий ситуацию или<br />последовательность действий приведшую к некорректной работе объекта<br />тестирования, с указанием причин и ожидаемого результата.<br />На практике это карточка с заданием, которую завели багтрекинговой системе.<br />Система отслеживания багов (Bug Tracking System) - прикладное приложение,<br />которое помогает учитывать и контролировать баги, пожелания пользователей, а<br />также следить за процессом устранения этих ошибок и выполнения или<br />невыполнения пожеланий.</p> <p id="3EUG"><br />Как правило, баг трекинговой системой является общая для проекта система<br />отслеживания заданий (Task Tracking System).</p> <p id="7Epv"><br />Примеры TTS:<br />1. Jira<br />2. Trello<br />3. Redmine<br />4. Asana<br />5. Basecamp<br />6. Bugzilla<br />7. ClickUp<br />8. Backlog<br />9. Bontq<br />10. YouTrack</p> <p id="exnj">Помимо багов туда вносятся запросы на новую функциональность (new feature<br />requests) и другие задачи технического и нетехнического характера.</p> <p id="WgFM"><br />Атрибуты баг-репорта<br />Атрибуты могут отличаться в зависимости от требований компании и проекта.</p> <p id="cRTw"><br />1. Название (Summary)<br />То поле, которое существует всегда. Краткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. Строится в формате “В какой части системы воспроизводится баг: что происходит и при каких условиях”.<br />Есть такое выражение: прочитав короткое описание бага, разработчик должен<br />понять в чем состоит проблема, прочитав детальное описание бага - знать строку<br />кода, которую править.</p> <p id="mXi6"><br />2. Проект (Project)<br />Название тестируемого проекта. Не обязательно, если проект один.</p> <p id="Zjd7"><br />3. Компонент приложения (Component)<br />Название модуля или функции тестируемого продукта. Не обязательно, так как<br />зачастую достаточно информации в саммари.</p> <p id="RnBC"><br />4. Версия (Version)<br />Версия приложения, на которой была найден баг. Указывается, если это необходимо для его определения. Помимо версии может указываться сборка (Build) или ветка (Branch).</p> <p id="MCZG"><br />5. Важность(Severity)<br />Это атрибут, характеризующий влияние дефекта на работоспособность приложения. Подробнее разберём в следующей части.</p> <p id="yzlx"><br />6. Приоритетность(Priority)</p> <p id="6kcQ">Приоритет выполнения задания по исправлению бага. Подробнее разберём в<br />следующей части.</p> <p id="l89t"><br />7. Статус бага (Status)<br />Зависит от BTS и используемой методологии разработки.</p> <p id="nNEl"><br />8. Автор (Author)<br />Создатель баг репорта. В BTS, как правило присваивается и сохраняется<br />автоматически.</p> <p id="Bfqc"><br />9. Ответственный за исправление (Assigned To)<br />Имя разработчика, назначенного на исправление проблемы. Иногда ответственного назначает PM (для этого бывает необходимым саначала назначить ответственным PM) или сами разработчики “ассайнятся” на выполнение задания.</p> <p id="KCI5"><br />10. Окружение (Environment)<br />Как правило, это информация о браузере и операционной системе. Может быть не обязательным, если баг не чувствителен к изменению среды.</p> <p id="SGv4"><br />11. Шаги воспроизведения (Steps)<br />Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. Их детализация зависит от стабильности состава и осведомлённости в работе с<br />разработываемым приложением участников команды. Чем детализированнее<br />расписаны шаги (в пределах здравого смысла), тем меньше вероятность двоякого понимания содержания бага. Чаще всего является обязательным полем.</p> <p id="STZe"><br />12. Фактический результат (Result)<br />Что происходит после выполнения шагов. Является обязательным полем.</p> <p id="MPVL"><br />13. Ожидаемый результат (Expected Result)<br />Что конкретно должно происходить после выполнения шагов. Является<br />обязательным полем. В идеале ожидаемый результат может быть один, но на практике их бывает несколько. Если необходима аргументация, то мы приводим<br />ссылку на спецификацию или другой проектный документ с указанием требования, официально утверждённые общепринятые мировые стандарты, примеры из других наиболее известных приложений. Также тестировщик может основываться только на личном опыте. В случае возникновения спорных ситуаций, за решением необходимо обращаться к BA и/или PM.</p> <p id="ekPJ"><br />14. Вложения (Attachments)<br />Файлы, которые могут помочь в воспроизведении бага или указать на способ<br />решения проблемы: файлы логов, скриншоты с разметкой и Dev Tools (об этом в<br />другой теме), видео воспроизведения багов, файлы необходимые для загрузки в<br />форму, связанная с заданием необходимая проектная документация.<br />При описании бага, старайтесь не использовать сленг, сокращения, аббревиатуры, не ссылайтесь в шагах на другие таски (задания), спецификацию. Используйте разметку текста, если необходимые поля не предусмотрены или не настроены в BTS.</p> <p id="RQqo"></p> <h3 id="LCxW"> Важность бага</h3> <p id="ogbK"><br />Также понимается как серьёзность бага. Проставляется тестировщиком.<br />Градация важности <br />S1 Блокирующая (Blocker)<br />Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или её ключевой функциональностью становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.</p> <p id="PE88"><br />S2 Критическая (Critical)<br />Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в<br />системе безопасности, проблема, приведшая к временному падению сервера или<br />приводящая в нерабочее состояние некоторую часть системы, без возможности</p> <p id="g0xM">решения проблемы, используя другие входные точки. Решение проблемы<br />необходимо для дальнейшей работы с ключевой функциональностью тестируемой системой.</p> <p id="NGkV"><br />S3 Значительная (Major)<br />Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.</p> <p id="uXmk"><br />S4 Незначительная (Minor)<br />Незначительная ошибка, не нарушающая бизнес логику тестируемой части<br />приложения, очевидная проблема пользовательского интерфейса.</p> <p id="QYvk"><br />S5 Тривиальная (Trivial)<br />Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо<br />воспроизводимая проблема, малозаметная посредствам пользовательского<br />интерфейса, проблема сторонних библиотек или сервисов, проблема, не<br />оказывающая никакого влияния на общее качество продукта. Зачастую такие баги даже не вносят в BTS. Иногда называется Enhancement (небольшая<br />поправка-улучшение), но не путать с Improvement - улучшение, которое достаточно значительно меняет бизнес-логику существующей функциональности или заметно изменяет UI.</p> <p id="qbBS"><br />Зачастую используется не пятиуровневая, а четырёхуровневая (например: Blocker, Critical, Major, Minor) или даже трёхуровневая (например: Major, Medium, Minor).<br />Названия статусов важности могут быть кастомизированы (изменены в зависимости от проекта).<br />Хорошим тоном считается внесение багов всех уровней важности, потому что баг<br />маленькой важности может обладать высоким приоритетом, однако и тут следует ориентироваться на правила принятые на проекте по соглашению между его участниками.</p> <h3 id="Mjzs">Приоритетность бага</h3> <p id="fEPs"><br />Приоритет бага определяет порядок его исправления. Обычно проставляется PM, но зависит от проекта. Также в зависимости от проекта статусов приоритета бага может быть больше или меньше и называться они могут по-другому (например, тут тоже могут быть блокеры или такой статус приоритета как Moderate), либо может ставиться только высокий приоритет или не ставиться вовсе, но рассмотрим наиболее общепринятый вариант.</p> <p id="vzuU"><br />Градация приоритетности<br />P1 Высокий (High)<br />Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является<br />критической для проекта.</p> <p id="F1IJ"><br />P2 Средний (Medium)<br />Ошибка должна быть исправлена, ее наличие не является критичной, но требует<br />обязательного решения.</p> <p id="p8lJ"><br />P3 Низкий (Low)<br />Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.</p> <p id="xmoL"><br />Также в работе вы можете услышать или использовать такие понятия:<br />● Hotfix (хотфикс - “горячее исправление”) - максимально быстро выполненное<br />исправление, когда влияние бага настолько велико, что нельзя было<br />откладывать его исправление, тестирование и релиз ни на минуту. Например,<br />после релиза выяснилось, что каким-то образом на лайф окружение<br />просочился блокирующий или критический баг и его нужно исправить прямо<br />сейчас, тогда делается hotfix.<br />● ASAP (As Soon As Possible, АСАП - как можно скорее) - запрос выполнения задания в кратчайшие сроки. Может исходить от PM или заказчика / CEO.<br />Обработанный и утверждённый запрос будет являтся самым приоритетным из</p> <p id="QWIM">всех (исключение - масштабный блокер, который покрывает основную или<br />бóльшую часть приложения). Он же может быть Immediate.</p>