Меню

3 стратегії боротьби з дефектом блокатора

3 strategies dealing with blocker defect

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

Дефекти блокаторів додають тонни драматизму звичайним тестовим дням.

У цій статті я хочу висвітлити деякі кроки, які тестер може зробити, маючи справу з ними.

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

Чи завжди це означає, що нам потрібно повністю припинити тестування, якщо натрапимо на проблему блокування?

У деяких випадках “Так”, але, можливо, не завжди. Можуть бути випадки, коли можлива певна діяльність з тестування.

Справа з дефектом блокатора

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

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

Давайте стрибнемо прямо.

Кроки, які ви повинні зробити, коли натрапите на дефект блокатора

Крок 1: Зіткнувшись з проблемою, витратьте час на пошук першопричини.

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

Я багато робив цього у своїх проектах, і це призвело до швидкого виправлення. Переваги аналізу корінних причин є:

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

Отже, я пропоную завжди перевіряти наш кінець, перш ніж реєструвати дефект.

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

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

що таке матриця простежуваності при тестуванні програмного забезпечення

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

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

Нижче наведено деякі загальні категорії, основні причини та способи усунення:

# 1) Файл хостів Проблема - Скажімо, у файлі хостів є неправильні параметри, що спричиняють проблему. У цьому випадку ви можете або оновити файл хосту самостійно, або звернутися за допомогою до когось, хто має доступ для оновлення та продовження виконання тесту.

Запитання та відповіді на інтерв’ю для pl sql

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

Примітка: Перш ніж робити це, уточнюйте у своїх проектних команд, чи може команда з контролю якості вносити ці зміни.

# 2) Конфігурація - Часто ми відзначали проблеми з конфігурацією, такі як не вказівка ​​на правильне середовище чи інші налаштовані проблеми, які блокують проблеми. У таких випадках тестувальники можуть внести зміни та продовжити тестування.

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

# 3) Випуск коду - Якщо ви відчуваєте, що проблема пов’язана з кодом, тестери нічого не можуть зробити. Зафіксуйте дефект блокувальника та дочекайтеся виправлення, щоб продовжити тестування.

# 4) Проблема розгортання - Погана розгортання - ще одна поширена причина проблем із блокуванням, які можна виявити під час перевірки стану розумності. Тут також тестування слід негайно припинити до отримання нової збірки.

# 5) Вниз навколишнього середовища - Якщо середовище не працює, скажіть, що база даних не підключається до сервера або URL-адреса не працює у випадку веб-сайтів; У цих випадках тестери не можуть зробити багато іншого, крім як повідомити про дефект і дочекатися, поки система запрацює.

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

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

Ось декілька вказівок:

  • Знайдіть баланс і розпізнайте зупинку, коли дійдете туди.
  • Досвід та досвід тестувальника є критично важливими для успішного проведення RCA. Однак бажано залучити команду та керівника команди, коли це необхідно.
  • Коли ви відчуваєте, що RCA вимагає багато часу, спочатку повідомте про проблему негайно та надайте якомога більше інформації. Знімок екрану завжди корисний.
  • Якщо потрібно, виконайте подальші дії. Надішліть електронний лист менеджеру або розробнику, щоб привернути увагу до критичної проблеми.
  • Продовжуйте вирішувати проблеми, попереджаючи необхідні сторони.

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

  • Керівництво повинно бути поінформоване про всі простої, якщо проблема виявляється дефектом showstopper. Ця інформація повинна бути передана клієнту, а також може вимагати оновлення плану проекту (терміни контролю якості), зміни результатів тощо.
  • Будь-яка затримка результатів забезпечення якості повинна підтверджуватися доказами. Тому завжди краще спілкуватися якомога швидше, а не чекати до кінця дня.

Крок No3: Тепер, переходячи до останнього кроку, оскільки ми закінчили аналізувати проблему та повідомляти її, що буде далі?

  • Якщо проблема блокує доступ до однієї функціональної області, перевірте, чи не впливає це на інші області
  • Якщо програма інтерфейсу не працює, перевірте, чи можна продовжувати тестування серверного / проміжного програмного забезпечення / бази даних.
  • Якщо жодна робота з виконання тесту не може відбутися, спробуйте робота над деякою документацією пов'язані з вашим проектом.
  • Ви також можете спробувати визначити сфери для автоматизації якщо ви повторюєте багато роботи вручну. Не завжди для автоматизації потрібно використовувати інструмент. Скажімо, створення звітів для вас є монотонним завданням, тобто однією областю, яку можна автоматизувати за допомогою простих макросів Excel тощо.
  • Проведіть час, знаючи про інструменти з відкритим кодом, які можуть бути впроваджені у ваш проект
  • Останнє, але не найменш важливе , працювати у напрямку інновацій, мантри, яка керує світом в даний час!

Нарешті , блок-схема, яка узагальнює всю дискусію!

Блок-схема: Кроки для усунення дефекту блокатора

дефект блокатора

Автор : Ця чудова стаття написана членом команди STH Приєю Р.

Які кроки ви робите, коли натрапляєте на дефект блокатора?

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

^