План уроку:

• Що таке баг. Причини виникнення дефектів

• Основні атрибути баг-репорту

• Життєвий цикл баг-репорту

• Що таке severity та priority

• Практики написання хороших баг-репортів

• Практика написання звітів про дефекти

Причини виникнення дефектів

Атрибути баг-репорту

Severity vs Priority

Життєвий цикл багу

Практики написання хороших баг-репортів

Алгоритм оформлення баг-репорту

Ви знайшли баг!

… І що тепер?

Виявивши баг, не поспішайте одразу до баг-трекеру!

Треба впевнитись що це дійсно дефект

Алгоритм дій:

1. Дослідить дефект

2. Визначте його вплив

3. Створіть детальний звіт

Алгоритм оформлення баг-репорту. Дослідження дефекту

1. Відтворіть дефект

• Переконайтесь, що дефект гарантовано відтворюється послідовністю кроків

• Зафіксуйте умови відтворення

o На приклад: середовище, версії компонентів, дозволи аккаунту (н.п. Адмін) і т.д.

• Складіть

o Найкоротший шлях відтворення

o Альтернативні шляхи відтворення

o Шляхи обходу дефекту (за наявності)

2. Визначте очікуваний результат

• Знайдіть докази що підтверджують очікуваний результат. Це можуть бути як вимоги у будь-якому форматі (.doc, сторінка на Confluence) так і тікети з менеджмент інструменту, як то: задачі, дефекти а також тест кейси.

3. Вхідні дані

• Перевірте, чи впливають вхідні дані на відтворення дефекту

• Якщо дефект відтворюється тільки на певних значеннях занотуйте їх

4. Оцініть вплив дефекту на продукт

• Приблизно визначте наскільки сильно дефект впливає на функціонал та кінцевого користувача

• Визначте як глибоко проник дефект. Чи відтворюється він на вищих середовищах – Acceptance, UAT, etc?

Алгоритм дій при критичному дефекті

Не гайте час – ескалюйте свою знахідку безпосереднього до керівництва!

(Test Lead/Dev Lead/etc).

Вони визначать пріоритет виправлення в залежності від ситуації на проєкті.

Алгоритм оформлення баг-репорту. Створення звіту про дефект

1. Формулювання суті проблеми (Title):

• Суть дефекту має вкладатись в одне речення.

• Використовуйте шаблон «Що? Де? Коли?»

2. Опис проблеми (Summary/Desription):

• Коротко але детально напишіть

o Умови відтворення дефекту

o Потенційний вплив на продукт

o Можливість обійти баг

• Додайте посилання на

o Джерело очікуваного результату

o Дотичні задачі/дефекти/тест кейси

• Напишіть кроки відтворення та кінцевий реальний (actual) та очікуваний (expected) результати

• Вкажіть вхідні дані:

o Якщо дефект відтворюється тільки на певних значеннях даних детально вкажіть що і де писати.

o Якщо дані складно отримати - додайте sql запити що можуть допомогти

3. Додаткові дані

• Будь-яка ілюстративна інформація надзвичайно важлива

• Додавайте скріншоти чи записи екрану, файли з логами і т.д.

Хороші заголовки

Який з заголовків хороший а який поганий?

Що робить хороший заголовок – хорошим?

Що? Де? Коли?

«Що?» (Що відбувається?) – це НЕ іменник, а те що відбулось, своєрідне ДІЄСЛОВО-уточнення («Що виконується?» або «Що НЕ виконується?»).

Що відбувається? – «Редактор зависає»

«Де?» – місце в системі (додатку/веб-сайті), де був знайдений баг.

Де? – «на сторінці фотографії»

«Коли?» (Після чого? Внаслідок якої дії? У період якої дії?) – дія, яка викликала собою результат, що відрізняється від очікуваного.

Коли? – «після вставки тексту, який має в собі символ N з буферу обміну після натискання

«Ctrl+V»

Приклади. Що? Де? Коли?

Q&A 

Дякую всім за заняття!🙌🏻

❗️🎓Урок 9. Управління дефектами. Практика у JIRA

❗️🖥 Матеріали до уроку

❗️📖 Домашня робота до уроку

Нагадую, що дедлайн здачі домашніх робіт – до наступного уроку.

Якщо виникають складнощі, пишіть, допоможу із задоволенням 😌

Запис лекції тренер опублікує трохи пізніше 🖥

Не забудьте повторити матеріал та підготуватися до наступного уроку📚

Успіху і до зустрічі!🤩