20171027_cherkasy/Відсутнє посилання "Global maps" яке забеспечує перехід повернення до відображення всіх подорожей

[Yourdos]

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

Step to reproduce :

1. Перейти на сторінку "Подорожі" застосунку в хедері сторінки : https://test.long-travel.live/travels/
2. Звернути увагу випливаюче меню на карти здійснених подорожів "Long-Travel"

Actual result : При скролингу до низу меню виконаних подорожів відсутнє посилання "Global maps"

Expected result : Відбувається перехід повернення до відображення всіх подорожей.

Attachements : https://github.com/scholokov/long-travel-2/assets/125985509/e897c5f1-40f8-4b26-bada-15194ba2b4fd

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

[DmytroMarkulych]

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

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

[Yourdos]

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

[DmytroMarkulych]

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

[DmytroMarkulych]

1. Дані атрибути по факту описані ось тут:

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