10 reasons why your bugs are getting rejected
Я не збираюся її щадити. За останні три дні вона відхилила 7 помилок. Я знаю, що вона використовує особисті образи як професійний меч ……
Товариш по команді розпалювався, і дискусія раптово загорілася, коли пара інших товаришів по команді поділилася тим самим досвідом з іншими розробниками. Зустріч команди обговорила питання обговорення помилок. Після обговорення ми всі вирішили зробити просту вправу, щоб в майбутньому врятувати себе від приниження відхиленої помилки.
підрядок (0,0) java
Кожен з нас почав робити нотатки, оскільки причини відхилення помилок за останні 10 помилок, про які повідомляли та відхиляли. Список цих приміток про відхилення виявився корисним для розуміння майбутнього відстеження повідомлень про помилки та того, що було зроблено неправильно.
Відмова від помилок та причини цього
Замість того, щоб розкривати список, я хотів би поділитися підсумковими пунктами списку. Ось -
# 1) Нерозуміння вимог:
З будь-якої причини, якщо ви не розумієте вимоги належним чином, ви точно будете звертати увагу на неправильно витлумачену вимогу при фактичній реалізації, і коли ви не знайдете її, це буде помилка на вашу думку, яка нарешті отримає відхилення.
Приклад із реального життя : Випробувавши рецепт, ви виявили, що він був несмачним, оскільки сіль не додавалась, але ви не знали, що сіль повинна додаватися під час подачі, інакше це може вплинути на зовнішній вигляд рецепта.
# 2) Впровадження вимоги:
В рамках попередньої дискусії ви знали, що конкретна вимога буде реалізована XYZ. Але під час розробки розробник виявив, що неможливо пройти шлях XYZ, тому він пішов шляхом ABC, і вам про це не повідомляли.
Зрештою, ви збираєтеся повідомити про помилку, коли виявили, що вимога не була реалізована так, як вона обговорювалась.
Приклад із реального життя : Ви попросили кравця підготувати сорочку, і коли вас попросили про судовий розгляд, ви відхилили це, сказавши, що не знайшли на ньому ґудзиків. Коли кравець пояснить, що надягання кнопок спереду вплинуло б на загальний вигляд сорочки, а отже, він поклав її всередину передньої межі, ви, безумовно, би оніміли.
# 3) Немає чітких вимог:
Коли чітких вимог немає, кожен може вільно прийняти цю вимогу по-своєму, і це призводить до припущення на особистому рівні. Коли ви бачите, що особисте припущення не виконується, ви позначаєте це як помилку.
Приклад із реального життя : Вам потрібно намалювати цикл, коли вчителька оголосила, що очікувала від учнів малювати велосипед. Через півгодини, перевіривши малюнок усіх, вона не знайшла нікого, що відповідає її очікуванням. Кожен сприйняв туманне твердження по-своєму, і результатом став триколісний велосипед, дитячий цикл, занадто багато циклів, велосипед на візку тощо.
# 4) Зміна вимоги:
Ще один приклад неправильного спілкування, більшість часу. Коли тестери не повідомляються про зміни вимог, буде повідомлено про нові помилки та в кінцевому підсумку відхилено.
Приклад із реального життя : Ви точно відхилите бутерброд, коли виявите, що в ньому використовується медовий хліб, а не банановий, який ви замовили. Хоч би ви знали, що ваш партнер змінив тип хліба на замовлення, поки ви говорили по телефону, і, звичайно, він / вона не знайшов необхідним ділитися ним з вами.
# 5) Розуміння сфери застосування:
Під час тестування ви починаєте тестувати те, що не повинно розглядатися як тестоване в певний момент або яке взагалі не охоплюється критеріями товару; ви станете жертвою відхилення помилок.
Приклад із реального життя : Ви повинні підмітати кімнату, і це єдиний фокус. І все-таки, якщо ви скаржитеся на безлад у інших районах, вас точно будуть ігнорувати.
# 6) Тестове середовище:
Додаток / продукт - це сукупність багатьох вимог до апаратного та програмного забезпечення - основних та другорядних, і коли не використовується належне тестове середовище або щось не вистачає в тестовому середовищі, програма / продукт аварійно завершує роботу та повідомляється про критичну помилку….
Потім відбувається глибоке розслідування, оскільки більшість випадків ми ненавмисно не дбаємо про надання незначних деталей про тестове середовище, яке ми використовували, і це збільшує роботу розробника. Зрештою помилка відхиляється.
Приклад із реального життя : Ті смачні булочки, які ви дегустували в будинку друга перед кількома днями, були приголомшливими, і після дотримання рецепту булочки були навіть не ближчі до тієї, яку ви мали.
Ну, ви не повинні були використовувати несвіже масло, оскільки свіже масло не було в наявності, ви не повинні були додавати щіпку грамового борошна, як ви думали, це може додати смаку, ви не повинні готувати його на сковороді, як духовку не працював.
як додати елементи масиву
Рекомендована література => Як ефективно підготувати “Тестове середовище”.
# 7) Використані дані тесту:
Тестові дані, що використовувались для тестування, не відповідали вимогам.
Приклад із реального життя : Навіть знаючи, що калькулятор корисний для чисельної обробки, якщо ви намагаєтесь додати спеціальні символи і коли калькулятор несподівано відповідає, ви вважаєте, що це було неправильно. Справді?
Рекомендована література => Поради щодо проектування даних тесту і Тестові методи управління даними .
# 8) Повторювана помилка:
Хтось уже повідомляв про ту ж помилку, і ви не подбали про те, щоб перевірити її, перш ніж повідомляти про помилку. Знову відмова.
Приклад із реального життя: Співробітник служби підтримки клієнтів не буде радий, коли він отримає кілька дзвінків на скарги на один і той же товар від кожного члена сім'ї. Не вдалося б одного дзвінка, подумає він.
# 9) Неправильний опис помилки:
Коли розробник не може зрозуміти, що ви намагалися передати через звіт про помилку, очікуйте, що його буде відхилено, оскільки вони також завантажені іншими завданнями, і коли вони не знаходять належного опису та необхідних деталей у звіті про помилку, незалежно від того, як критичною помилкою є, як очікується, вона буде позначена як Відхилена.
Рекомендована література => Як написати хороший звіт про помилки? Поради та підказки.
Приклад із реального життя: Вам потрібно розблокувати машину, сісти і почати, рухаючи клавіші за годинниковою стрілкою ... машина не заводилася, і ви засмучені. Вам не доручали перевірити бензин? О, помилка в посібнику, оскільки передбачалося, що ви точно зрозумієте, що за замовчуванням його слід перевірити.
найкраще віддалене шпигунське програмне забезпечення для мобільних телефонів -
# 10) Невідтворювані помилки:
Повідомляючи про помилку, ви ніколи не усвідомлювали важливості відтворюваності помилки. Просто переконавшись, чи помилка відтворюється завжди або випадково, це може заощадити години роботи та ще одну відхилену помилку.
Приклад із реального життя: Що перевірить лікар, коли ви скаржитеся на сильний застуду, але він не виявляє жодних симптомів. О, я просто важко чхав , не покращить ситуацію.
Висновок
Найчастіше наша людська природа дозволяє нам думати негативно, коли відхилена помилка. Справді, розробники не бачать конкретної причини відхилити помилку, якщо вона є дійсною.
Тож наступного разу, будь ласка, не зосереджуйтесь на кількості помилок. Зосередьтеся на якісних помилках з належною деталізацією, тому що в кінцевому рахунку важливо те, як ви допомогли поліпшити якість товару, а не те, скільки помилок ви повідомили.
Також прочитайте => Як вирішити всі помилки без позначки 'Недійсна помилка'?
Про автора: Ця корисна стаття написана членом команди STH Бхумікою Мехтою. Вона є керівником проекту, що має понад 7 років досвіду тестування програмного забезпечення.
Щасливого тестування! Як зазвичай чекаємо ваших поглядів на те саме.
Рекомендована література
- Як вирішити всі помилки без будь-якої мітки 'Недійсна помилка'?
- Чому звітування про помилки - це мистецтво, якому повинен навчитися кожен тестувальник?
- Мистецтво повідомлення про помилки: як продати на ринок та виправити помилки?
- Чому у програмного забезпечення виникають помилки?
- 7 типів програмних помилок, які повинен знати кожен тестер
- 11 способів дізнатися, що ти випробувач ..
- Зразок звіту про помилки
- 5 способів бути сміливим і впевненим у собі тестувальником програмного забезпечення