Меню

Відстеження помилок у прямому ефірі, тестові показники та тестовий вихід - Безкоштовний навчальний день з контролю якості 6-й день

live project bug tracking

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

Це заключна частина нашого “ Навчання з тестування програмного забезпечення на живому проекті ”Серія.

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

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

Відстеження помилок у прямому ефірі, показники тесту та тестовий вихід

Що відбувається, коли ми стикаємося з цими відхиленнями?

Ми, очевидно, повинні їх записати та відстежити, щоб переконатися, що ці відхилення будуть оброблені та врешті-решт зафіксовані на AUT.

# 1) Ці відхилення називаються Дефектами / помилками / проблемами / аваріями / помилками / несправностями.

# два) Усі наступні випадки можна реєструвати як дефекти

  • Відсутні вимоги
  • Неправильно працюючі вимоги
  • Додаткові вимоги
  • Невідповідність довідкового документа
  • Проблеми, пов’язані з навколишнім середовищем
  • Пропозиції щодо вдосконалення

# 3) Запис дефектів здебільшого проводиться в листах Excel або за допомогою програмного забезпечення / інструменту управління дефектами. Щоб отримати інформацію про те, як обробляти дефекти за допомогою інструментів, спробуйте скористатися такими посиланнями:

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

Як ефективно реєструвати дефекти

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

Як створити масив рядків

Зазвичай такі звіти є частиною звіту про дефекти:

  • Ідентифікатор дефекту: Для унікальної ідентифікації.
  • Опис дефекту: Це як заголовок, щоб коротко описати проблему.
  • Модуль / розділ AUT: Це необов’язково, лише для додання більшої ясності щодо позначення області АВТ, де була проблема.
  • Етапи відтворення: Яка точна послідовність операцій, які слід виконати на AUT для відтворення помилки, слід перерахувати тут. Крім того, якщо будь-які вхідні дані є специфічними для проблеми, ця інформація також повинна бути введена.
  • Серйозність: Щоб вказати інтенсивність проблеми та врешті-решт вплив, який це може мати на функціонування AUT. Вказівки щодо призначення та значення, які слід призначити в цьому полі, можна знайти в документі плану тестування. Тож, будь ласка, зверніться до Документ плану тесту зі статті 3 .
  • Статус: Буде обговорено далі в статті.
  • Знімок екрана: Знімок програми, щоб показати помилку, коли вона сталася.

Ось деякі з обов’язкових полів. Цей шаблон можна розширити (наприклад, включити ім’я тестувальника, який повідомив про проблему) або укласти контракт ( Наприклад, ім'я модуля видалено) за потреби.

Дотримуючись наведених вище вказівок та використовуючи шаблон вище, зразок журналу дефектів / звіту може виглядати так:

Зразок звіту про дефекти для проекту OrangeHRM Live:

Звіт OrangeHRM про дефекти

=> Клацніть тут, щоб завантажити звіт про дефекти проекту

Нижче наведено зразок звіту про дефекти, створений в інструменті управління тестами qTest: (Клацніть на зображення, щоб збільшити)

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

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

Цикл дефектів:

Життєвий цикл дефектів 1

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

Кілька покажчиків під час відстеження помилок

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

Повний життєвий цикл дефектів

Для нашого проекту в прямому ефірі, якби ми мали слідувати життєвому циклу дефекту для дефекту 1

як відкрити файл
  • Коли я (тестувальник) створюю його, його статус є 'Новий'. Коли я призначаю його керівнику команди контролю якості, статус все ще залишається 'Новим', але власник тепер є керівником контролю якості.
  • Ведучий контролю якості перевірить проблему, і визначивши, що це дійсна проблема, проблема призначається ліду розробника. На цьому етапі статус є 'Призначений' а власником є ​​Dev lead.
  • Потім розробник призначить цю проблему розробнику, який працюватиме над її усуненням. Тепер статус буде 'В роботі' (або щось подібне до цього ефекту), власником є ​​розробник.
  • Для дефекту 1 розробник не може відтворити помилку, тому він повертає її команді контролю якості та встановлює статус як 'Не здатний до розмноження'.
  • В іншому випадку, якщо розробник міг працювати над цим і виправити проблему, статус буде встановлено на 'вирішено' і випуск буде передано команді з контролю якості.
  • Потім команда контролю якості забере його, повторно протестує проблему і, якщо це виправлено, встановить статус на 'зачинено' . Якщо проблема все ще існує, статус встановлюється на 'Відкрити знову' і процес триває.
  • Залежно від інших ситуацій статус можна встановити як 'Відкладено' , “Недостатньо інформації”, 'Дублікат' , 'працюючи за призначенням' , тощо розробником.
  • Цей метод реєстрації дефектів, звітності та розподілу їх, управління ними є одним з основних видів діяльності, що виконується членами команди контролю якості на етапі виконання тесту. Це робиться щодня до завершення певного циклу тестування.
  • Після завершення циклу 1 команді розробників знадобиться день чи два, щоб консолідувати всі виправлення та відновити код до наступної версії, яка буде використана для наступного циклу.
  • Той самий процес знову продовжується і для циклу 2. В кінці циклу існує ймовірність того, що в програмі все ще можуть бути проблеми, «Відкриті» чи незакріплені.
  • На цьому етапі - чи продовжуємо ми продовжувати цикл 3? Якщо так, коли ми припинимо тестування?

Критерії виходу для тестування OrangeHRM Live Project

Тут ми використовуємо те, що ми називали б “Критеріями виходу”. Це заздалегідь визначено в документі 'План випробувань'. Це просто у формі контрольного списку, який визначатиме, завершувати ми тестування після циклу 2 або йти ще на один цикл. Схоже, що нижче, при заповненні, беручи до уваги деякі гіпотетичні відповіді на наступні питання стосовно проекту OrangeHRM:

Критерії виходу з тесту

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

Тестові показники

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

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

Метрики відіграють життєво важливу роль у заповненні цієї прогалини. Метрики - простими словами, розумні цифри, які команда тестування збирає та підтримує . Наприклад, якщо я сказав, що пройшло 90% тестових кейсів, це має більший сенс, ніж сказати про 150 тестових кейсів. Чи не так?

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

Нижче наведено найбільш часто збираються тестові показники для більшості проектів:

  • Прохідний відсоток тестових випадків
  • Щільність дефектів
  • Відсоток критичних дефектів
  • Дефекти, розумне число

Перевірте Звіт про стан, що додається до цієї статті щоб побачити, як використовуються ці показники.

Звіт про випуск тесту / звіт про завершення

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

Зразок тестової реєстрації електронної пошти:

Кому: Клієнт, прем'єр-міністр, команда розробників, команда DB, BA, команда контролю якості, команда з питань навколишнього середовища (та будь-хто інший, кого потрібно включити)
Електронна адреса: Привіт команда,

Команда QA підписує програмне забезпечення OrangeHRM версії 3.0 після успішного завершення двох циклів функціонального тестування веб-сайту.

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

Список відомих проблем також додається до електронного листа. (Знову ж таки, можна додати будь-які інші посилання, які мають сенс.)

Дякую,
Лідер команди QA.

Вкладення: Остаточний звіт про виконання, остаточний звіт про випуск / дефект, список відомих проблем

Після того, як команда з контролю якості надішле електронний лист про тестування, ми офіційно закінчимо процес STLC. Це не обов'язково означає завершення етапу 'Тестування' SDLC. Нам ще потрібно закінчити тестування UAT, щоб це сталося. Знайдіть докладніше про тестування UAT тут .

Після завершення UAT SDLC переходить до фази розгортання, де вона працює, і доступна для споживачів / кінцевих користувачів.

Це воно!

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

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

^