Чому не рекомендується розміщувати кілька дефектів в одному випуску / квитку?

Я не впевнений, що це місце, щоб задати таке концептуальне питання (Stackoverflow точно не є).

Я бачив це запитання в іспиті з декількома варіантами (одна відповідь), подібним до іспитів ISTQB :

Чому не рекомендується повідомляти про декілька дефектів в одному випуску / квитку?

а. Щоб звіт був стислим та зрозумілим.

б. Тому що розробники можуть виправити лише одну помилку.

c. Оскільки групи тестувальників тестування оцінюються за кількістю виявлених помилок.

г. Системи управління помилками не підтримують цю особливість декількох помилок.

Моя єдина думка - aце правильна відповідь.

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

d - плагіни Redmine / Trac підтримують кілька полів.

Відповідь відповідно до аркуша відповідей є b.

Може хтось пояснить, чому? Коментарі з думкою про відповіді вітаються.

Уявіть, якби Stack Overflow мав настанову: замість того, щоб задавати одне запитання, ви підходите і запитуєте в тому ж питанні, що б вам не спадало на думку, всі ваші питання, які ви мали протягом останніх двох тижнів. Що би означало опонентне і протилежне право? Якими були б назви питань? Як прийняти найкращу відповідь? Як позначити питання?

Система відстеження помилок робиться для ... відстеження помилок. Відстеження помилки означає:

1. Створення запису про те, що помилка може існувати з інформацією про її відтворення,

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

3. Стверджуючи, що помилка зараз вирішена,

4. Підтвердження того, що помилка вирішена.

У дуже спрощеній моделі 1 і 4 виконає замовник, а 2 і 3 - розробник.

Уявіть собі такий журнал:

• Перший день [Клієнт] При натисканні на кнопку "Видалити" у вікні "Інформація про продукт" програма зависає. Перезапуск програми показує, що продукт не видалено. Очікувана поведінка полягає у видаленні продукту.

• День 4 [Розробник] <Проблема відтворена>

• День 5 [Розробник] <Питання вирішено в редакції 5031>

• День 12 [Клієнт] <Квиток закритий: проблема вирішена>

Журнал простий і зрозумілий . Ви можете легко відстежувати, що було зроблено та коли , яка редакція вирішена, яку помилку тощо. Наприклад, якщо система відстеження помилок інтегрована з контролем версій, при перегляді конкретної редакції ви можете перевірити, які помилки в ній були вирішені.

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

Легко перепризначити квиток або спочатку визначити, хто саме той, хто повинен відповідати за помилку.

Тепер уявіть собі такий журнал:

• Перший день [Клієнт] Додаток зависає, коли я натискаю кнопку "Видалити" у вікні "Інформація про продукт". Також колір фону лівої панелі темно-синій, тоді як він повинен бути фіолетовим. Я також зазначив, що текст вікна "Інформація про продукт" недостатньо перекладений німецькою мовою; це очікується? Коли остаточний переклад буде доступний? До речі, ви отримали нову піктограму, яку я надіслав для дії "Опублікувати продукт"? Я не бачу його у вікні "Синхронізувати дані".

• День 6 [Розробник] Я змінив колір на фіолетовий.

• День 7 [Розробник] Так, нормально, що переклад німецькою мовою є неповним.

• 8 день [Замовник] Добре для німецької. Що з італійською? Люсія надіслала вам файл XML два дні тому.

• День 9 [Розробник] Зараз це нормально.

• День 10 [Клієнт] Добре для кнопки «Видалити»? Дивно, на моєму комп’ютері він все ще висить.

• День 11 [Розробник] Ні, я хотів сказати, що це нормально для італійського перекладу.

• День 12 [Замовник] Бачу. Дякую. Але з кольором є проблема. Ви змінили його на темно-фіолетовий, але він повинен бути світло-фіолетовим, як у верхній панелі головного вікна.

• День 13 [Розробник] Я оновив іконку.

• День 14 [Замовник] Піктограма? Яка ікона?

• День 15 [Розробник] Піктограма, яку ви попросили мене оновити.

• День 16 [Клієнт] Я ніколи не просив вас оновити будь-яку піктограму.

• День 17 [Розробник] Звичайно, ви запитали. Дивіться цей квиток. Ви писали, що піктограму продукту для публікації слід оновити. Я це зробив.

  ⁞

• День 100 [Замовник] Отже, а що з записами в журналі?

• День 101 [Розробник] Я поняття не маю, про що ти говориш. Навіть не в цьому квитку, а в 6199 році. Я закриваю цей як вирішений. <Квиток закритий: проблема вирішена>

• День 102 [Клієнт] Вибачте за повторне відкриття, але проблема не вирішена. Я говорю про записи в журналі: я минулого тижня сказав вам, що текст іноді є недійсним, коли він містить символи unicode. Ти пам'ятаєш? <Квиток знову відкритий>

• День 103 [Розробник] Я туманно пам'ятаю щось подібне, але після пошуку останніх трьох сторінок цього квитка я не можу знайти жодного сліду. Чи можете ви написати ще раз, в чому була проблема?

  ⁞

• День 460 [Розробник] Я провів дві години на пошуки сліду того, що ви сказали про файли, надіслані зашифрованими через мережу. Я не впевнений, що зможу знайти точний запит.

• День 460 [Замовник] Ви, хлопці, справді повинні бути більш організованими. Я останні чотири тижні повідомляв вас про цю проблему. Чому ти все забуваєш?

  ⁞

Про що цей журнал? Її вирішили 43 рази та знову відкрили 43 рази. Це означає, що розробник настільки дурний, що не може вирішити ту саму проблему протягом 460 днів? Ага, ні, зачекайте, цей квиток тим часом було призначено 11 розробникам. Яка угода? Як шукати конкретну проблему? Вона фактично призначена Ванесі, але її п’ять колег стурбовані також семи з одинадцяти номерів цього квитка. Коли квиток слід закрити? Це коли половина питань вирішена? А може, десять з одинадцяти?

Примітка. Ви можете вважати, що таких журналів не існує. Повірте, я їх бачив не один раз.

Просто прокоментуйте свою заяву:

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

Це передбачає, що всі виправлені помилки будуть виправлені одночасно. Уявіть сценарій, коли квиток піднімається проти v1 продукту з двома випусками:

1. Кнопка скидання форми фактично подає форму, а не очищення значень
2. Розмір шрифту на кнопці становить 110%, коли він повинен бути 115%.

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

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

Область застосування:

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

Навпаки, у квитках з дефектом GUI прийнято містити кілька специфікацій, оскільки кожен квиток GUI є фактично "переробленим" (дефектом дизайну), "переглянутою специфікацією" або "запитом на функції" (відсутня функціональність).

Однією з важливих цілей відстеження дефектів є спілкування та координація між різними ролями (програмісти, тестери, клієнти та менеджери).

У проектах, де якість коду має велике значення (наприклад, порівняно з зручністю для користувачів), відстеження дефектів може складатися з декількох граней, одна з яких орієнтуватиметься на відстеження дефектів коду , окремо від відстеження удосконалень та запитів підтримки клієнтів.

Метою системи відстеження дефектів коду є:

• Увімкнути незалежне та однозначне відстеження незалежно відтворюваних дефектів;
• Забезпечити найкраще наближення (відповідність один до одного) до першопричини кожного дефекту.

Роблячи це, він повинен максимально використовувати такі бажані якості:

• Ефективно масштабуйте, оскільки кількість дефектів збільшується з часом.
• Попередити синдром рухомої цілі.

Відмова: ця перефразовка є з мого особистого досвіду. Це може бути недостатньо або неправильно для цілей іспиту на сертифікацію.

Незалежне та однозначне відстеження означає, що:

1. Кожен дійсний дефект може бути або усунений, або не вирішений , без двозначності.

   • Причина 1: спростити управління,
     • Приклад: вона дозволяє використовувати "кількість невирішених квитків" як метрику.
   • Причина 2: перевести на предмет, що діє
     • Приклад: якщо це не вирішено, відповідальність покладається на призначеного програміста. Якщо це вирішено, але не закрито, відповідальність лежить на призначеному тестері (верифікаторі).
   • Наслідок: У цій методології частково усунений дефект заслуговує на те, щоб його розбити на кілька залежних дефектів.

2. Незалежно відтворювані дефекти слід відстежувати незалежно.

   • "Незалежне відтворення" означає, що вони можуть мати різні стани. Одне може бути виправлене, а інше залишається зламаним.
   • Причина: мінімізувати невідповідність між відстеженням дефектів та аналізом першопричини.
     • Вважається, що кожна коренева причина, яка може бути простежена до дефекту коду, вимагає хоча б однієї зміни коду.
     • Якщо два дефекти відтворюються незалежно, знадобляться кілька змін коду.
     • Якщо два дефекти можна відтворити незалежно, їх потрібно перевірити (перевірити), оскільки проходження одного тесту не означає, що інший тест буде пройдено.
   • Приклад 2: Якщо спочатку вважалося, що два симптоми мають однакову першопричину, і тому їх класифікують в один і той же квиток, і пізніше їх було показано як самостійне відтворення, то їх слід розділити на два білети.

Подивіться на це з точки зору когось іншого, хто використовує систему, з'явившись через кілька місяців. Вони знаходять помилку в програмі. Вони навколо Google і бачать, що є квиток на підтримку, який відповідає їхнім проблемам. І ей, це закрито! Дивовижно! Це було виправлено в останній версії! Отже, вони оновлюються ... а помилка все ще є? Що не так з цими дурними розробниками?!?

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

Набагато краще дати кожному клопу власний квиток, і якщо у вас є кілька помилок, пов'язаних, але, мабуть, відмінних, у більшості систем відстеження помилок є функція, яка дозволяє зв’язувати одну помилку з іншою. (А якщо ні, ви можете просто помістити його у звіт. "Дивіться також помилку № 12345.")