📑Существует несколько понятий, что такое #ЖЦдефекта, приведу несколько:
📌Жизненный цикл дефекта (Defect Lifecycle) – это последовательность этапов, которые проходит дефект на своём пути с момента его создания до окончательного закрытия;
📌Жизненный цикл дефекта - это последовательность перехода дефекта между разными статусами и специалистами, которые с ним работают;
📌 Жизненный цикл дефекта – это стадии, которые проходит ошибка с начала своего существования и до ее полного разрешения. Чтобы было проще воспринимать, жизненный цикл рисуют схематично, где отображаются все статусы и действия, которые эти статусы и сменяют.
😄Я тоже нарисовала свою схему в посте 👉😁
ЖЦ дефекта бывает разным, все зависит от проекта какие статусы необходимы для работы, и не все могут быть добавлены, данные статусы находятся в системе отслеживания ошибок - JIRA

Рассмотрим статусы:
🖍Обнаружен (Submitted) – дефект найден в веб или мобильном приложении
🖍 Новый (New) – дефект зарегистрирован (заведен) в системе управления дефектами
🖍Назначен (Assigned) – дефект назначен на Dev Lead или developer, или Project Manager
На данном этапе ответственный за дефект изучает его и по полученным результатам статус дефекта может быть следующим:
🖍🖍Открыт (Opened) - разработчик начинает работу исправления дефекта (анализ, редактирование)
🖍🖍Отклонен (Declined or Rejected) - по разным причинам дефект не считается дефектом или считается неактуальным дефектом, или не является обоснованным. Дефект не рассматривается для исправления или реализации
🖍🖍 Отложен (Deferred or Postponed) - в режиме ожидания, этот дефект исправят в других версиях приложения. Дефект получает такой статус по нескольким причинам: низкий приоритет ошибки, недостаток времени
🖍🖍 Дубликат (Duplicated) - когда дефект уже существует в системе по отслеживанию ошибок или есть два дефекта, которые являются следствием одной проблемы, один из них получает этот статус
🖍🖍Не является багом (Not a bug) - назначается в том случае, когда функциональные возможности программы меняться не будут. Или как говорят «Это не баг, а фича»)))

Если дефект всё же дефект, то далее статусы:
🖍В работе (In Progress)- разработчик работает над задачей
🖍Ревью кода (Code Review) - перед отправкой на сборку изменённого кода другой разработчик проверяет код
🖍Исправлен (Fixed or Resolved) - разработчик сделал необходимые изменения в коде, протестировал эти изменения сам. Дефект со статусом «Исправлен» возвращается на проверку к тестировщику
Ещё есть статуса:
✏️(Не сделан) Unresolved — присваивается тимлидом команды разработчиков при открытии нового бага
✏️(Не исправлен) Won‘t Fix – резолюция применяется, если открытый баг не может быть исправлен, описанный дефект не является багом, данный баг, по разным причинам, нет необходимости устранять
✏️ (Не воспроизводится) Cannot Reproduce – такая резолюция присваивается если открытый баг не удалось воспроизвести.
Далее...
🖍Тестирование в режиме ожидания(Pending retest or Ready for QA) - после исправления дефекта разработчик предоставил новый код для повторного тестирования. Тестирование находится на рассмотрении у тестировщика
🖍 Повторное тестирование (Re-testing or In QA) - тестировщик повторно проверяет код, измененный разработчиком, с целью посмотреть, исправлен ли дефект
🖍Проверен (Verified) - если дефект не воспроизводится, тестировщик подтверждает, что этот дефект исправлен
🖍Переоткрыт (Reopened) - если дефект воспроизводится, то тестировщик переоткрывает его и назначает на разработчика. Этот дефект проходит через жизненный цикл дефекта еще раз
🖍 Закрыт (Closed) - если тестировщик уверен, что дефект исправлен и больше не воспроизводится, то он его закрывает. Этот статус означает, что дефект протестирован и одобрен

Хочу отметить, что все статусы будут на английском языке на работе. И наименования могут отличаться.

А также моя схема включает все статусы сразу, просто, чтобы вы знали, какие статусы существуют.

Данный файл будет обновляться - первая версия☺️
#шаблонтестовогосценария

Шаблон чек-листа - первая версия☺️
#шаблончеклиста

Небольшая памятка: еще писала на работе:)
#тестовыйсценарий
💿 Тестовые сценарии должны быть написаны на основе аналитики (требований), необходимо проверить все сценарии, описанные в аналитике;
💿 Тестовые сценарии должны быть однозначными, т.е. должны быть составлены и сформулированы таким образом, чтобы они не допускали двусмысленного толкования, а четко понимались всеми участниками;
💿 Использовать детальные предусловия в тестовых сценариях.

☺ Характеристики хорошего тестового сценария☺
- Точный и строгий – ничего лишнего
- Допускает многократное использование
- Атомарный – используется сам по себе и в составе других сценариев
- Неделимый
- Связан с требованиями
- Имеет ценность для системы и команды тестирования
- Не должен быть ни слишком простым, ни слишком сложным
- Реализует обоснованную вероятность выявления дефекта
- Не затрагивает другие функции
- Не пересекается с другими тестами
- Описывает проверку одной функциональной области

#кроссворд
📱по горизонтали:
1️⃣. один из видов тестирования, направленного на проверку соответствий функциональных требований ПО к его реальным характеристикам;
6️⃣. написанием тестов должны заниматься «специально обученный человек» это ...;
9️⃣. набор инструментов для ускоренной разработки сайта, нацелен на решение определенных задач;
1️⃣1️⃣. «фасадная» часть программы, это единственная часть, с которой взаимодействуют пользователи.

📱по вертикали:
2️⃣. помогает создавать надежные тесты автоматизированной проверки и улучшать общую логику тестирования на проектах;
3️⃣. набор инструкций, для автоматической проверки определенной части программного обеспечения;
4️⃣. инструмент для автоматизированного управления браузерами;
5️⃣. одно из преимуществ автоматизации: все написанные тесты всегда будут выполняться однообразно, то есть исключен «человеческий фактор»;
7️⃣. запуск всех необходимых тестов;
8️⃣. один из видов тестирования программного обеспечения, при котором тестируются отдельные модули или компоненты программного обеспечения;
🔟. доклад о результатах тестирования;
1️⃣2️⃣. программно-аппаратная часть сервиса, набор средств, с помощью которых происходит реализация логики веб-сайта.

#автоматизация