search

scholokov / long-travel-2

10 stars 2 forks source link

20171027_cherkasy/Відсутній контент в розділі "Військово-історичний об’єкт", коли вибираєш сторінку "Цікаві місця" #4764

Open Yourdos opened 9 months ago

Yourdos commented 9 months ago

Components : Browser Google Chrome Версія 109.0.5414.168 Platform : OS Windows 8.1

Step to reproduce :

  1. Відкрити розділ "Цікаві місця" в хедері застосунку : https://test.long-travel.live/places/
  2. Звернути увагу на розділ внизу сторінки "Військово-історичний об’єкт"

Actual result : При вибору розділу "Військово-історичний об’єкт" відбувається перехід на сторінку з відсутньою інформацією.

Expected result : Відбувається перехід до інформативної сторінки з фото контентом. (З відомої причини не відбувається)

Attachements : image

Additional Information: Виконання вимог пункту 5.4 цікаві місця - не забеспечується.

DmytroMarkulych commented 9 months ago
  1. Summary баг репорту має відповідати на питання Де? Що? Коли? . І описувати фактично яку проблему маємо.
  2. Обов'язково перед summary має вказуватися id подорожі.
  3. Кроки для відтворення пишуться в наказовому відмінку. Не варто вживати слова "Далі" а просто дії які виконуємо.
  4. Актуальний та очікуваний результати: Коли ми маємо розбіжність між тим що є на сайті і тим як має бути (наші вимоги, дизайн), то вказуємо конкретні дані, не використовуючи "Інший, не коректно" і все в цьому роді
  5. Посилання на документацію вказуємо окремим пунктом.
  6. Має бути скріншот із видаленням області в якій є дефект.
  7. Варто додавати атрибути баг репорту такі як: Issue Type, Severity, Priority, Components, Platform

І в кінці по Вашому баг репорту. В кроках для відтворення, ми вказуєте, що спочатку відкриваємо сторінку із подорожжю, а тоді переходимо на Головну. Тобто сенсу в кроку №1 немає, так як баг репорт описує проблему на сторінці Цікаві місця

Yourdos commented 9 months ago
  1. Варто додавати атрибути баг репорту такі як: Issue Type, Severity, Priority, Components, Platform з цим я згідний це не Джира тут потрібно все вносити в текстовому режимі, а чи потрібно забеспечувати скрінами кожен баг, достатньо покроково вказати шлях (моя думка)
    тут я не зрозумів поясніть - Тобто сенсу в кроку №1 немає, так як баг репорт описує проблему на сторінці Цікаві місця ---- в мене задача була все ж старт з https://github.com/scholokov/long-travel-2/issues/3430
scholokov commented 9 months ago

скріни мають бути завжди. це не залежить від багтрекеру. у житті у крайніх випадках може і не бути, але то скоріше виняток. 99,9 багів мають мати скріни. у навчанні 100%

Yourdos commented 9 months ago

на писав в приватні

DmytroMarkulych commented 9 months ago
  1. Не важливо, чи ми працюємо в Jira, Github, ClickUp,Trello чи навіть google tables.. Атрибути мають бути присутні в будь якому випадку, це база, основа, грунт баг репорту. Вони допомагають ставити пріорітети, і моніторити який стан справ з тим чи іншим функціоналом. Дають розуміння, чи можна релізити ту чи іншу фічу. І в першу чергу зберігають час всій команді, в тому числі і Вам, як QA. Якщо ж ви маєте бажання, тратити час спочатку на зведення дефекту, без атрибутів, а тоді на 20 хвилинний дзвінок із РМ про пріорітетатах баг репортів, то завжди будь ласка, але таким чином продукт буде будувати довго. Дані атрибути є best practice, які мають за собою сотні годин змін, помилок і дискусій. Тому, це є обов'язковим, не залежно від тест-трекеру..
  2. Скріншот потрібен, ви навчаєтеся, і це чудовий час щоб робити правильні звички.. Відкрию секрет, ніхто не любить читати, девелопери не виключення, і в такому випадку у вас швидше за все буде дзвінок, і ви будете тратити свій час щоб пояснити що там не так.. Скрін коштує 20 секунд. Дзвінок із девом - 2-10 хв. Цінуйте свій час, і час інших.
  3. Якщо ж ви тестуєте подорож черкаси, будь ласка, заводьте дефекти в межах даної подорожі. Якщо ж ви переходите на іншу сторінку, і заводите дефект на елементи які знаходять на ній, це автоматично тестування іншої сторінки
DmytroMarkulych commented 9 months ago
  1. Дані атрибути по факту описані ось тут:

Image

  1. Хорошим тоном є робити скрін всієї сторінки, із стрілочкою на проблемний елемент. Використовуйте devtools для відображення більшої кількості інформації на скріні.
  2. Посилання на документацію вказуємо окремим пунктом "Додаткова інформація"
  3. В Summary краще вказати не "коли", а "після", тобто після якоїсь дії