Меню

3 найгірші звички звітування про дефекти та як їх зламати

3 worst defect reporting habits

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

Дефекти - це серйозні справи, а невеликі помилки можуть коштувати дорого.

Ви знаєте, що робити, коли виявите дефект. Ви повідомляєте про це; або в a Трекер дефектів / Інструмент управління дефектами або в аркуші Excel. Основні принципи однакові для обох методів.

Інструменти управління дефектами не гарантують кращого звітування. Це хороші практики, які рятують день.

Щоб оцінити добро, ми повинні визнати, чого ні.

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

3 найгірші звички звітування про дефекти та як їх зламати

звички з найгіршим дефектом

Тут йдеться:

# 1) Лінощі

Не витрачаючи час, щоб зробити якнайкраще, що можеш.

Це процес відстеження дефектів більшість команд:

(Примітка- натисніть на будь-яке зображення, щоб збільшити його)

відстеження дефектів

Як бачите, тест-лідер переглядає дефекти перед тим, як відправити їх до команд контролю якості.

Цей огляд включає підтвердження:

  • Дійсність - це помилка?
  • Повнота - Назва, кроки, дані, знімок екрана тощо.
  • Дублікати
  • Відтворюється чи ні ... тощо.

Я не з чуток знаю, що неможливо, щоб провідний контроль якості був 100% ретельним.

Отже, таке ставлення: «Я повідомлю про проблему так, як хочу. Потенційний клієнт може перевірити повторно. Він може вирішити, дійсний / повний дефект чи ні »- це кінець вашої команди з контролю якості та ваша довіра.

Чи знали ви, що деякі клієнти мають SLA для кількості допустимих недійсних дефектів? Як тільки кількість перевищує, вони починають карати підрядників за кожний повідомлений недійсний дефект?

Засіб захисту: Проведіть належну ретельність і відповідайте за результат. Повернувся дефект через недостатньо інформації або що це не помилка? Не завжди це може бути виною команді розробників. Справа не в тому, що вони не хочуть мати проблеми в додатку. Це може бути справжнє безладдя. Нехай це не сталося.

# 2) Поспіх

Давайте зробимо це за допомогоюприклад.

Нижче наведено знімок екрана OpenEMR екран створення пацієнта. Це система управління лікарнями з відкритим кодом.

Цей екран дозволяє користувачеві вводити дату народження пацієнта за допомогою функції календаря. Що він не робить, це обмежує доступ до вибору з календаря. Я маю на увазі, що ви можете вибрати DOB, наприклад, '31 березня 1983 року' з календаря. Пізніше змініть його на '31 лютого 1983'.

open-emr-календар-функція

open-emr-вгадування помилок

Чому 31 лютого? Втілювати відгадування помилок і спробуйте негативні дані в полі; в чому вся суть тестування, чи не так?

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

Зверніть увагу на поля віку та дати народження на екрані нижче:

опенемр-тест-тестер

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

  • Це помилка.
  • Це відтворюється.
  • Це не дублікат (для підтвердження зв’яжіться зі своєю командою)
  • Ви знаєте точний опис проблеми
  • Крім того, ви знаєте точні кроки, завдяки яким це відбувається.

Тепер, коли у вас є сировина, ви готові піти.

Ви починаєте повідомляти про це. Призначення тяжкості дефекту є обов'язковим кроком, і ваша команда може використовувати щось подібне до наступна таблиця для довідки:

Серйозність Вплив
1 (критичний) • Ця помилка є достатньо критичною для того, щоб зірвати систему, спричинити пошкодження файлів або потенційну втрату даних
• Це викликає ненормальне повернення до операційної системи (аварійне завершення роботи або з'являється повідомлення про збій системи).
• Це призводить до зависання програми та вимагає перезавантаження системи.
2 (високий) • Це призводить до відсутності життєво важливих функціональних можливостей програми з обхідним шляхом.
3 (середній) • Ця помилка погіршить якість системи. Однак є розумне рішення для досягнення бажаної функціональності - наприклад, через інший екран.
• Ця помилка перешкоджає тестуванню інших ділянок продукту. Однак інші області можна перевірити незалежно.
4 (низький) • Існує недостатнє або незрозуміле повідомлення про помилку, яке має мінімальний вплив на використання продукту.
5 (косметичний) • Існує недостатнє або незрозуміле повідомлення про помилку, яке не впливає на використання продукту.

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

Виглядає приблизно так?

НЕПРАВИЛЬНО. За даними пацієнта, всі щеплення та інші нагадування прострочені. Це може бути і не правильно. Крім того, для пацієнта їх вік визначає, звертатися він до педіатра чи загального лікаря тощо.

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

open-emr-клінічне нагадування

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

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

Засіб захисту: Не поспішайте повідомляти. Будьте впевнені на 100%, що розумієте вплив проблем з багатьох сторін. Це найкраща додана вартість, яку ми можемо запропонувати тестувальникам. Ми не просто говоримо: “Щось не працює”. Ми також говоримо: 'Ось що станеться, якщо це продовжить не працювати'. Тонни різниці, чи не так?

# 3) Відсутність творчості

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

У вашому Інструмент управління дефектами ви також можете подати дефект типу 'Пропозиція щодо вдосконалення'. Тут ви можете займатися творчістю.

Засіб захисту: Думати за межами коробки. Якщо ви вважаєте, що в певній функції відсутній фактор «Вау», і ви знаєте, як її внести, висуньте ідею вперед. У гіршому випадку це може бути відхилено, і це нормально. Важливою є спроба.

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

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

Я би хотів, щоб я був таким творчим! Але, можливо, ми всі можемо працювати над цим.

Ось бонус. Контрольний список для звільнення цих шкідливих звичок:

1. Чи мій заголовок передає проблему чітко і коротко?
Наприклад:“Створити пацієнта не працює” - це невдалий заголовок. «Створення пацієнта не вдається, навіть якщо всі поля введення містять правильні значення».

2. Який показник відтворюваності?
Іншими словами, чи завжди це трапляється? Чи знаю я точну послідовність кроків, які повторять проблему?

3. Це специфічна платформа, браузер чи користувач?

Чотири. Чи виконано ці кроки та переходить до вашої проблеми?

5 . Чи додано скріншот?

6. Чи потрібно мені коментувати свій знімок екрана, щоб виділити певні області?

7. Чи назва файлу зображення додається описовою?
Не використовуйте щось на зразок 'Untitled.jpg'. Дайте йому описову назву.

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

9. Чи можу я надати будь-які інші дані, щоб підкріпити свій дефект?
(Приклад:посилання на FRD або розмова з клієнтом тощо)

10. Чи розумію я, наскільки серйозна проблема з різних точок зору?

одинадцять. Чи знаю я першопричину проблеми? Якщо так, чи маю я докази (можливо, файли журналів) і чи можу я їх включити? Зверніть увагу, що ви не завжди можете це знати або вам це потрібно знати. Але якщо ви це зробите, включити його не завадить.

12. Чи у звіті про дефект відсутні проблеми з граматикою, форматом, орфографією та пунктуацією?

як користуватися thread.sleep в Java

13. Чи знаю я спосіб вдосконалення продукту?

Ви думаєте, це забирає багато часу? Що ж, як тільки це стане звичкою, це вже не буде.

Вкорінення на краще повідомлення про дефекти рутини!

Про автора: Ця стаття написана членом команди STH Свати.

Не соромтеся розміщувати свої запити / коментарі нижче.

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

^