Меню

Мистецтво повідомлення про помилки: як продати на ринок та виправити помилки?

art bug reporting

Спробуйте Наш Інструмент Для Усунення Проблем

Чому існує потреба в маркетингу помилок?

Перше, що мені спадає на думку, коли я починаю писати цю статтю, це слова Джем Канер - «Найкращий тестер - це не той, хто знаходить найбільше помилок або хто бентежить більшість програмістів. Найкращий тестер - той, хто виправляє більшість помилок '.

Зараз - в чому різниця між пошук більшості помилок і виправлення більшості помилок ?

Чи не очевидно, що будь-яка помилка входила в система управління помилками повинен бути виправлений розробником? Відповідь - ні. Фактори, такі як час випуску товару на ринок, час завершення проекту за графіком та розробники, що працюють у непрактичні щільні графіки тощо змушують компанії випускати продукт із невеликою кількістю помилок, які значною мірою не вплинуть на користувачів.

Мистецтво звітування про помилки

(зображення джерело )

Хто надає впевненість керівництву, заявляючи, що помилки, наявні в продукті, не вплинуть на довіру, надійність та інтерес зацікавлених сторін замовника? - Інженер-випробувач або команда випробувачів - обов’язок кожного інженера-випробувача - виправити помилки, які можуть мати негативний вплив на якість продукції.

Пріоритет помилки , на мій погляд, багато в чому залежить від того, як тестувальник представляє проблему командам розробників та управління.

Думайте про це як про рекламу чи маркетинг проблеми - це передбачає 2 кроки:

  1. Напишіть або правильно повідомляти про помилки
  2. Знати все про помилку, тому будь-які подальші подробиці можна пояснити краще

Що ви дізнаєтесь:

Мистецтво повідомлення про помилки

Так, повідомлення про помилки - це мистецтво . Спосіб написання помилки показує технічну майстерність, знання домену та можливості спілкування інженера-випробувача.

Як правило, помилка повинна містити таку інформацію:

  • Підсумок помилок
  • Кроки для відтворення
  • Вкладені файли (Знімок, файли журналів тощо,)
  • Відтворюваність помилок
  • Серйозність помилок
  • Версія програмного забезпечення, інформація про довкілля
  • Інша інформація на основі організаційних вимог.

Важлива примітка: Завжди копайте глибше, щоб знайти першопричину проблеми та повідомити про неї. Наприклад, проста помилка входу з правильною комбінацією імені користувача та пароля може бути пов’язана з різними причинами, такими як:

  1. Повноваження для входу взагалі не перевірені
  2. Проблеми з таймаутом мережі у випадку віддаленого входу
  3. Система може розглядати всі CAPS як не CAPS.

Отже, як тестер, ви зможете розшифрувати відмінності, дотримуючись зведених тверджень про помилки:

  • “Не вдається ввійти з правильним ім’ям користувача та паролем”
  • 'Неможливо увійти з правильним ім'ям користувача та паролем, коли ім'я користувача чи пароль містить поєднання алфавітів CAPS та не CAPS'.

Останнє є дуже чітким описом проблеми і є однозначним. Завдяки цьому ви не тільки підвищуєте довіру до тестувальника, але й повідомляєте про фактичну проблему, а не про симптом.

Тепер давайте розглянемо кожну сферу, яка бере участь у звіті про помилку, та обговоримо важливі аспекти кожного з них:

№1. Підсумок помилок

Підсумок помилок повинен надати швидкий знімок того, в чому саме полягає проблема. Це повинно бути точно і добре спрямовано.

Приклад :

Окрім теорії, я спробую пояснити на прикладах.

Припустимо, простий модуль входу. Припустимо, проблема в тому, що новий користувач, який відвідує веб-сайт, не може ввійти за допомогою пароля за замовчуванням. Коли я представив той самий сценарій багатьом студентам, яких я навчав на початковому етапі навчання, у відповідь на помилки було кілька відповідей. Нижче наведено декілька зразків того, як виглядало резюме:

як читати файл .bin

' Новий користувач не може ввійти »

'Вхід користувача працює не так, як очікувалося'

“Користувач не може ввійти з правильним паролем”

короткий зміст помилок неправильно і правильно

З наведених зразків, чи можете ви вибрати одне твердження, яке насправді описує проблему? Я не думаю. Короткий зміст завжди повинен містити повну інформацію про невдалий сценарій.

Розглянемо наступне твердження:

«Новий користувач не може ввійти в систему за допомогою пароля за замовчуванням, наданого електронною поштою або через SMS»

Як бачите, із наведеного твердження розробник може чітко зрозуміти, в чому проблема та де проблема.

Отже, спробуйте знайти правильні слова для опису резюме, які безпосередньо дають інформацію. Необхідно уникати загальних тверджень, таких як «не працює належним чином», «працює не так, як очікувалося» тощо.

№2. Етапи відтворення та вкладень

Невідтворювані помилки завжди відходять на другий план, хоча вони можуть бути значними. Тому подбайте про те, щоб правильно та наочно написати кроки.

Кроки повинні бути точними і точно такими ж, як ті, що призвели до проблеми. Для помилок, пов’язаних з функціональністю, найкращим прикладом є наступний зразок.

Приклад :

Розглянемо те саме питання, зазначене в попередньому розділі.

  1. Створіть нового користувача за допомогою опції 'Зареєструватися' на домашній сторінці. (Приклад імені користувача: HelloUser)
  2. Буде отримано електронне повідомлення та SMS із паролем за замовчуванням. Ідентифікатор електронної пошти та номер мобільного телефону для SMS надаються під час створення користувача на кроці 1. (Зразок електронного листа: HelloUser@hello.com , Зразок мобільного номера: 444-222-1123)
  3. Виберіть варіант Вхід на домашній сторінці.
  4. У текстовому полі імені користувача вкажіть зразок імені користувача, наданий на кроці 1.
  5. У полі пароля вкажіть пароль за замовчуванням, отриманий по електронній пошті або SMS.
  6. Натисніть кнопку Увійти
  7. Очікуваний результат: Користувач повинен мати можливість входу за допомогою наданого імені користувача та пароля та переходу на Сторінку облікового запису користувача.
  8. Фактичний результат: З'явиться повідомлення 'Недійсне ім'я користувача / пароль'.

кроки звіту про дефект

Якщо якась інформація не наведена у наведеному вище зразку, тоді вона буде призводять до прогалин у спілкуванні і розробник не зможе відтворити проблему. Кроки повинні бути конкретними та детальними із зразками даних, які ви використовуєте під час тестування.

Якщо можливо або де це можливо, надайте a знімок того, що ви точно бачите на екрані. Таким чином, це не лише забезпечить розробникам хороший огляд проблеми, а й підтвердить результат вашого тесту.

нефункціональний тестові випадки, такі як стресові ситуації, тести на стабільність або ефективність, на додаток до вищезазначених деталей, інформація про сценарій, який спричиняє стрес для системи, може передаватися такою, як вона є. Крім того, існує небагато систем, які звітують журнали про кожну виконану операцію. Журнали - це, як правило, друковані виписки, надані розробниками в їх коді. Щоразу, коли модуль виконується, відповідні журнали будуть надруковані або відображені. Коли журнали доступні, це значною мірою допоможе розробникам у відтворенні проблеми.

№3. Відтворюваність помилок

Питання, яке є великим чи малим, буде пріоритетним на основі відтворюваності. Його можна побачити завжди, іноді, рідко або навіть лише один раз. Випуск, який відтворюється як “завжди”, буде пріоритетним, ніж інші.

не може відтворити дефект

Отже, обов’язком інженера-випробувача є відстеження сценарію саме для проблеми, яка завжди відтворюється. Іноді може бути декілька питань, які не виходять з-під контролю інженера-випробувача, що призведе до того, що випуск відтворюватиметься лише кілька разів, але в багатьох випробуваннях. У таких випадках завжди згадуйте кількість судових розглядів, виконується певний сценарій, а також кількість випадків, коли проблема розглядається під час цих судових процесів.

Це, у свою чергу, додало б довіри до згаданого вами звіту про помилки. Знову ж таки, це покращило б вашу репутацію тестувальника. Пізніше я розповім вам причини доброї репутації.

No4. Серйозність помилок

Суворість, безсумнівно, є одним з найбільших факторів, що впливають на пріоритетність помилки.

Далі наводяться різні категорії тяжкості. Зверніть увагу, що це лише загальні зразки, і вони різняться залежно від компанії.

  1. Серйозність 1 - Показати пробку - для катастрофічних помилок, без виправлення, користувач не зможе продовжувати користуватися програмним забезпеченням, і не існує можливих обхідних шляхів
  2. Серйозність 2 - висока - для помилок, подібних до серйозності 1, але є обхідне рішення
  3. Тяжкість 3 - середня
  4. Серйозність 4 - низька
  5. Серйозність 5 - тривіальна.

Наприклад, давайте порівняємо дві подібні проблеми.

У наших телевізійних приставках небагато постачальників послуг надають інформацію про частоту послуги відповідно до поточного рівня. Припустимо, що частота відображається як 100 МГц замість 100,20 МГц. Це може не впливати на перегляд користувачем послуг, але може вплинути на моніторинг діагностики встановлених вершин. Отже, це можна подати як проблему серйозності 3.

Якщо припустити подібну проблему в банківському домені: якщо залишок на вашому рахунку відображається як 100 доларів, а не 100,20 доларів, уявіть вплив проблеми. Це повинен бути дефект серйозності -1. Як ви можете бачити в обох випадках, проблема дуже схожа на те, що користувальницький інтерфейс не відображає цифри після десяткової коми. Але вплив залежить від домену.

Ефективна участь у нарадах з контролю версій програмного забезпечення

Зазвичай кожна організація має свій власний процес для розслідування помилок та визначення пріоритетів. Як правило, протягом проекту відбуватимуться збори з певними інтервалами, щоб обговорити помилки та визначити те саме.

Процес під час таких зустрічей такий:

  1. Запитуйте список помилок із системи управління помилками відповідно до серйозності.
  2. Подивіться на резюме та обговоріть вплив помилки на досвід користувача при використанні програмного продукту.
  3. На основі оцінки ризику та впливу встановіть пріоритет і призначте помилку відповідному розробнику для її виправлення.

На етапі №2 важливо, щоб кожен інженер-випробувач виступав за вплив помилки на взаємодію з користувачем, якщо помилка не отримала пріоритету, на який вона заслуговує. Зрештою, саме ми, інженери-тестувальники, враховуємо точку зору користувача, щоб писати тестові кейси та тестувати продукт.

Розглянемо наведений вище приклад проблеми не відображення цифр після десяткової коми у банківському домені. Для розробника це може здатися менш серйозною проблемою. Він міг би стверджувати, що замість того, щоб оголосити змінну цілим числом, він оголосив би це плаваючою комою для вирішення проблеми, а отже, менш суворою.

Але як випробувач, ваша роль пояснює ситуацію із клієнтом. Ваша думка повинна полягати в тому, як користувач скаржиться в цьому випадку. Тестер повинен сказати, що це спричинить паніку серед користувачів, оскільки клієнт втрачає свої гроші в копійках.

Вплив неправильної маркетингу помилки

Якщо помилка не продається належним чином, це створить такі проблеми:

  • Неправильний пріоритет дефекту
  • Затримка у вирішенні важливих питань
  • Випуск продукту з серйозними дефектами
  • Негативні відгуки клієнтів
  • Девальвація вартості бренду

Вплив неправильної маркетингу помилки

Окрім усіх вищезазначених причин, дуже важливо побудувати свій репутація інженера-випробувача . Це більше схоже на розвиток цінності бренду для себе.

На початковому етапі вашої кар’єри, якщо ви можете зберегти свою кількість “Неможливо відтворити” або “Потрібна додаткова інформація” або “Недійсна помилка” або зміни ступеня серйозності як можна нижчі, на одному етапі ваші помилки не будуть вивчатися взагалі, і вони будуть безпосередньо призначені відповідному розробнику для виправлення.

Щоб розвинути таку цінність бренду та завоювати довіру своєї команди та команд розробників / або менеджерів, вам слід розвинути деякі технічні навички щодо перевірки знань, доменних та комунікативних навичок.

Висновок

Будь-який товар чи послуга, великі чи малі, завжди обов’язково зазнають невдач без належної реклами. Після створення бренду будь-який невеликий товар може стати супер хітом для аудиторії.

Сказавши це, надмірна реклама товару також може завдати шкоди репутації.

Отже, помилка завжди повинна бути написана чітко, коротко і точно, щоб вона давала точне місце помилки на обширній / вичерпній карті програмного забезпечення. Я повторюю, що це не тільки покращує якість програмного забезпечення, але й значно зменшує витрати на тестування та розробку програмного забезпечення.

Зараз ще не пізно! Давайте продовжувати і негайно виправляти помилки!

новий приватний сервер world of warcraft - -

Рекомендована література

^