"Суперечка про помилку це функція, створена для того, щоб надати вам можливість надіслати запит нашим менеджерам суперечок для остаточного перегляду, якщо ви вважаєте, що ваша помилка законна або безпричинно знижена"
Мотивація
Отримати відхилення помилки ніколи не легко переварити, але наші досвідчені тестери знають, як з цим впоратися. Вони знають, коли та як подати успішне оскарження помилок, щоб їхні звіти про помилки остаточно перевірили менеджери суперечок. Суперечка про помилку - це функція, розроблена для того, щоб надати вам можливість надіслати запит нашим менеджерам суперечок для остаточного розгляду, якщо ви вважаєте, що ваша помилка є законною або безпричинно знижена. Докладніше про функцію оскарження помилок можна знайти тут.
Коли слід надсилати суперечки про помилки
Щоб запобігти блокуванню диспутів протягом місяця, вам потрібно переконатися, що ви надсилаєте оскарження лише тих помилок, у яких ви на 100% впевнені. Може здатися, що ми намагаємося вас налякати, але це не наша мета. Ми хочемо, щоб ви почали думати про помилку, яку ви надіслали, і про причини відхилення/повернення, наведені в коментарі TL.
Запитайте себе: «Чи я щось не помітив? Чи я завантажив журнал консолі, щоб підтвердити свою заяву про помилку? Чи є шанс, що я забув щось поділитися у звіті про помилку? Чи я правильно зрозумів продукт?». Щойно ви відповісте на ці запитання, ви отримаєте відповідь, надсилаєте ви оскарження помилок чи ні.
Що містить хороша суперечка про помилку
Ви коли-небудь думали про те, щоб подати скаргу до суду? Це не дуже відрізняється від подання оскарження помилок. Обидва вони повинні містити:
Офіційне привітання для рецензента
Пояснення, чому ви звернулися до них
Причина, чому ви вважаєте, що ваші права були порушені
Додаткові докази, такі як вкладення, посилання та журнали
Пропоноване рішення проблеми
На завершення офіційне привітання
Вирішення суперечок: роль менеджерів суперечок
Метою менеджерів суперечок є забезпечення чесності у вирішенні суперечок між лідерами команд і тестувальниками.
Якщо обидві сторони наводять вагомі аргументи і вага їхніх претензій однакова, перевага надається тестувальнику, а диспут-менеджери приймають рішення на користь тестувальника. У таких випадках проблеми тестувальника є пріоритетними.
Однак, якщо диспут відхилено, це означає, що для відхилення є справжні причини, і тестувальник повинен з цього навчитися.
Менеджери диспутів прагнуть підтримувати баланс справедливості щодо тестувальників, завжди враховуючи правила та якість звіту про помилку, а також застосовуючи свій великий досвід під час розгляду суперечок щодо помилок. Їхня мета — бути якомога справедливішим у процесі прийняття рішень.
Позитивний приклад суперечки про помилку
Вище ви бачили, що потрібно для успішного оскарження помилок. А тепер подивимося, як це виглядає на практиці. Приклад нижче охоплює реальний сценарій. Іноді тестувальникам не потрібно використовувати всі згадані вище елементи, щоб довести, що проблема дійсна. У позитивному прикладі нижче ви бачите, що тестер використовував лише 4 елементи:
Привітання «Hello Dispute Team»
Причина, чому тестер вважає проблему помилкою
Можливі наслідки та аудиторія, якщо помилку не буде виправлено
Офіційне привітання в кінці: «Перевірте ще раз! Дякую!».
Беручи до уваги те, що тестер був максимально коротким і настільки докладним, наскільки це було необхідно, можна зробити висновок, що пошук правильного балансу також є ключем до успіху. Що також підвищить шанси на успіх диспуту, так це надання додаткової інформації, яка не була включена в початковий звіт про помилку. Наприклад, другий скрінкаст або журнал консолі завантажується на Google Диск і використовується як посилання в суперечці.
Негативний приклад суперечки про помилку
Вступати в суперечку про помилки з гнівом або різкими словами ніколи не є гарною ідеєю. Ви можете спробувати, але отримаєте відмову, попередження або навіть заборону на нашій платформі. Отже, обчисліть можливі сценарії грубості, непрофесійності чи насильства. Звучить погано, так?
Деякі з наших тестувальників, з іншого боку, не читають або забувають наші правила, що призводить до відхилення звітів про помилки та відхилень суперечок щодо помилок. У наведеному нижче випадку тестер написав:
Заголовок і фактичний результат мають бути схожими.
Заголовок має на меті дати короткий опис того, коли, де і що відбувається. Він має бути якомога коротшим і описовим, наскільки це необхідно. З іншого боку, у «Фактичних результатах» тестувальники мають детально пояснити, в чому полягає проблема, вказати масштаб проблеми, інші сторінки, на які вона впливає (якщо такі є), тощо. Поділитися всіма цими деталями в заголовку звіту про помилку було б неможливо .
На відео точно показана послідовність всіх кроків і показана описана проблема.
Скрінкаст не повинен показувати всі кроки, які потрібно виконати, щоб відтворити помилку. На відео повинні бути показані лише останні один-два кроки.
Чого не вистачало в суперечці про помилку?
Офіційне привітання на початку
Знання про наші правила
Знання про наші стандарти якості звіту про помилку
Додаткова інформація на підтримку заяви про серйозність помилки
Більше прикладів помилок тестувальників під час подання оскарження помилок:
Відправка тільки "Прошу переглянути!" у суперечці про помилку
Напис "Дякую, TL. Я розумію!" вважаючи, що вони відповіли за допомогою коментаря до звіту про помилку
Звернення до диспут-менеджера як керівника групи
Брехня про запити без відповіді тощо.
Пам’ятайте, що ми бачимо історію кожного звіту про помилку. Шлях правди та наполегливої праці є єдиною гарантією того, що ми будемо розглядати вас для можливого підвищення в майбутньому. Якщо ви хочете зробити свою кар'єру з нами, переконайтеся, що ви робите правильні кроки в цьому напрямку.