У навчальному каталозі після вибору категорії список товарів змінюється, але кнопка скидання фільтра не повертає початковий стан. Повідомлення «фільтр зламався» залишає розробнику багато запитань: який саме фільтр, на якій сторінці, після яких дій і що мало відбутися? Багрепорт для сайту перетворює таке спостереження на перевірювану задачу, яку можна відтворити та закрити за зрозумілим критерієм.
Нижче описано умовну вправу, а не випадок реального клієнта. Для неї достатньо браузера та доступу до тестової копії каталогу. Не потрібні адміністративні права, встановлення пакетів чи зміни коду. Якщо перевіряєте продуктивний магазин, обмежуйтеся безпечним переглядом: не створюйте платних замовлень і не змінюйте чужі дані лише заради відтворення помилки.
Почніть із одного спостереження, а не діагнозу
Корисний заголовок описує дію та збій: «Скидання категорії залишає попередній список товарів». Формулювання «JavaScript працює неправильно» вже припускає причину, яку ще не доведено. Проблема може бути в обробнику кнопки, відповіді сервера, збереженому стані або іншому компоненті. Спочатку зафіксуйте видиму поведінку; технічну гіпотезу додайте окремо й прямо назвіть припущенням.
Не поєднуйте кілька незалежних проблем в одну заявку. Якщо одночасно помітили неправильний список і перекритий заголовок на телефоні, створіть окремі описи з власними кроками. Спільна дата виявлення не означає спільну причину. Невелика задача дозволяє перевірити виправлення без суперечки про те, чи залишилася частина великого повідомлення невиконаною.
Визначте очікувану поведінку до оцінки серйозності. Якщо скидання має очищати лише категорію, воно не обов’язково повинне прибирати пошуковий текст і сортування. Підставою може бути погоджена вимога, підпис кнопки або опис сценарію. Коли вимоги немає, поставте питання про потрібну поведінку, а не оформлюйте власне очікування як доведений дефект.
Побудуйте найкоротший шлях до збою
Запишіть початкову адресу та стан сторінки. Для вправи можна позначити шлях як «тестовий каталог», не вигадуючи адресу робочого сервісу. Укажіть, чи користувач увійшов, чи є текст у пошуку, яке сортування вибране та чи відкривали сторінку повторно. Саме прихований початковий стан часто пояснює, чому інша людина не бачить описаного результату.
Послідовність для навчального прикладу: відкрити каталог без фільтрів; вибрати одну категорію; дочекатися зміни списку; натиснути скидання категорії; порівняти список і позначення активного фільтра. Кожна дія має бути окремим кроком. Не додавайте випадкових переходів і повторних натискань, якщо без них помилка теж виникає: коротший сценарій легше повторити.
Напишіть очікуваний і фактичний результат окремими реченнями. Наприклад, очікується повернення товарів усіх категорій зі збереженням сортування; фактично позначення категорії зникає, а список залишається попереднім. Не обмежуйтеся словом «не працює»: у цьому прикладі частина інтерфейсу вже змінилася, і ця різниця допомагає звузити перевірку. Не називайте приклад результатом тестування вашого магазину.
Повторіть сценарій кілька разів і запишіть реальний результат, не підставляючи вигаданий відсоток відтворення. Якщо збій випадковий, зафіксуйте час, попередню дію та спостережувані відмінності між спробами. Не перетворюйте перезавантаження сторінки на доказ виправлення: воно може лише очищати стан. Потрібно повторити той самий шлях, який спричинив проблему.
Додайте докази, які допомагають відтворенню
До опису додайте браузер і його фактичну версію, операційну систему та тип пристрою. Для проблеми макета корисні розмір області перегляду та орієнтація екрана. Не вигадуйте параметри й не пишіть «на всіх телефонах», якщо перевірили один. Запишіть перевірене середовище та окремо перелічіть те, що ще потрібно перевірити.
Скріншот має показувати місце помилки й достатній контекст: активний фільтр, кнопку та список. Якщо важлива послідовність, короткий запис екрана корисніший за кілька непов’язаних зображень. До запису залиште текстові кроки, щоб задачу можна було зрозуміти без перегляду відео. Приберіть особисті дані, приватні вкладки, сповіщення та інформацію про чужі замовлення перед передачею матеріалу.
Якщо вмієте користуватися інструментами розробника, додайте точний текст відповідної помилки й час її появи. Наявність червоного повідомлення сама по собі не доводить зв’язок із фільтром. Порівняйте момент натискання з моментом помилки. Не надсилайте повний мережевий експорт без перевірки: він може містити токени, cookies або тіла приватних запитів. Безпечніше передати мінімальний очищений фрагмент.
Узгодьте пріоритет і критерій завершення
Опишіть наслідок для користувача: неможливо повернути повний каталог без повторного відкриття сторінки. Окремо зазначте доступний обхідний шлях і його обмеження. Пріоритет залежить від впливу та домовленостей команди, а не тільки від емоційності повідомлення. Не називайте задачу критичною через сам факт помилки, але й не приховуйте блокування важливого сценарію, якщо воно справді підтверджене.
Критерій завершення для вправи: після скидання категорія не позначена, список відповідає початковому набору, погоджене сортування збережене, повторний вибір і скидання працюють. Якщо проблему виявлено на телефоні, перевірка має включати це середовище. Додайте також сусідній сценарій із пошуком, якщо його поєднання з категорією входить у вимоги, а не довільно розширюйте задачу після ремонту.
Після виправлення повторіть початкові кроки на погодженій тестовій версії й зафіксуйте результат. Укажіть версію збірки або дату перевірки, якщо вони відомі. Якщо збій залишився, доповніть ту саму задачу новими доказами. Для майбутніх оновлень збережіть цей сценарій як регресійну перевірку; технічні зміни варто окремо перевірити перед відправленням у Git.
Висновок: хороший багрепорт не вимагає вгадувати причину чи писати код. Він містить спостереження, початковий стан, короткі кроки, очікування, фактичний результат і перевірку завершення. Якщо помилку складно повторити або описати без розкриття приватних даних, AriZone може допомогти підготувати безпечний сценарій діагностики й погодити наступні дії.
Залиште коментар