Рівень 5. Робота з дефектами
Одвічні запитання тестувальника: "Заводити баг чи не заводити? Баг чи фіча?"
Баг
Для початку давайте розберемося, що таке цей горезвісний баг і що за зухвалість така — фіча?
Баг (англ. bug — жук, дрібна комаха) — поширена серед програмістів назва помилок у програмах.
Баг слід відрізняти від глюка, який є не чим іншим, як симптомом бага, що викликає в користувача нервово-істеричну реакцію.
Також є похідне від «баг» поняття «бага». «Бага» — те саме, що й «баг», тільки жіночого роду. Вважається, що фіксити «багу» приємніше, ніж «баг».
Термін «баг» зазвичай уживається щодо помилок, які проявляють себе на стадії роботи програми, на відміну, наприклад, від помилок проєктування чи синтаксичних помилок.
Фіча (від feature; властивість, здатність, можливість, функціональність тощо). Зазвичай уживається щодо якоїсь програми: "Важлива фіча програми — можливість експортувати звіт у таблицю Excel".
Також відома фраза «це не баг, це фіча» (іноді «багофіча»). Таким чином, будь-який задокументований баг, що не впливає на працездатність програми (та й коли впливає — нерідко теж), переходить до категорії її функціональностей (особливостей). Такою «багофічею» була неймовірна можливість у Windows 98 перезапустити Windows, не перезавантажуючи комп’ютер. Треба було, натискаючи «Перезавантаження» у вікні «Завершення роботи», натиснути Shift. Це сильно економило час на перезавантаження, але при цьому воно ніби як було багом.
Написання баг-репорту
Баг-репорт — це технічний документ, тому мова опису проблеми має бути технічною. Слід використовувати правильну термінологію для назв елементів користувацького інтерфейсу (editbox, listbox, combobox, link, text area, button, menu, popup menu, title bar, system tray тощо), дій користувача (click link, press the button, select menu item тощо) та отриманих результатів (window is opened, error message is displayed, system crashed тощо).
Вимоги до обов’язкових полів баг-репорту
Обов’язковими полями баг-репорту є: короткий опис (Bug Summary), пріоритет (Priority), кроки відтворення (Steps to Reproduce), фактичний результат (Actual Result), очікуваний результат (Expected Result).
Нижче наведено вимоги та приклади щодо заповнення цих полів.
Принцип створення заголовка баг-репорту
Принцип "Де? Що? Коли?"
Як приклад — створення заголовка баг-репорту. Заголовок, або summary, має відображати всю суть бага і бути таким, щоб без прочитання повного опису бага було зрозуміло, про що йдеться.
Для створення заголовка складіть речення, у якому факти дефекту викладено в такій послідовності:
- Де? У якому місці інтерфейсу користувача чи архітектури програмного продукту перебуває проблема. Причому починайте речення з іменника, а не з прийменника.
- Що? Що відбувається чи не відбувається згідно зі специфікацією або вашим уявленням про нормальну роботу програмного продукту. При цьому вказуйте на наявність або відсутність об’єкта проблеми, а не на його вміст (його вказують в описі). Якщо вміст проблеми варіюється, усі відомі варіанти зазначаються в описі.
- Коли? У який момент роботи програмного продукту, після настання якої події чи за яких умов проблема проявляється.
Наприклад:
Що: неправильний розрахунок даних
Де: на сторінці NNN
Коли: після введення в поле Y від’ємного значення.
Старайтеся не писати фрази на кшталт «я клікаю на посилання», «я натискаю кнопку» та подібні. І заголовок, і описи кроків — це настанова до дії для тих, хто виправлятиме проблему, тому краще формулювати як «клікнути на посилання», «натиснути на кнопку»
Наприклад:
Мобільна версія сайту > Фільтр записів за часом > При одночасному виборі двох значень дропдауна часу сторінка зависає
Різниця між багом і баг-репортом
У вас, напевно, виникло запитання — "у чому різниця між багом і баг-репортом?". Уточню: баг — це сама помилка по суті, зате коли тестувальник опише її за всіма правилами, вона перетвориться на баг-репорт, про який зазвичай кажуть: "Я відкрив багу" або "Я завів баг". Крім того, баг-репорт може містити як один конкретний баг, так і всі знайдені баги під час тестування програми/сайту/застосунку.
Чому так? Коли ви працюєте з баг-трекінговою системою, зазвичай на кожен баг створюється власний окремий електронний документ (баг-репорт) і так далі для кожного з них. А коли ви працюєте без баг-трекінгової системи, баги оформлюють або в текстовому документі, або в таблиці й туди ж записують усі інші знайдені баги. Не створюватимете ви окремий файл для кожного бага.
Багато хто вважає, що все тестування зводиться до пошуку багів, але ми з’ясували на першому рівні, що це не так. Проте не применшуватимемо значення цієї роботи. Адже 80–90% роботи тестувальника — це пошук помилок. Але важливо запам’ятати одне: тестувальника цінують не за знайдені ним баги, а за непропущені. Тобто провал — це коли користувачі в отриманому продукті виявили дефекти, особливо якщо вони заважають бізнес-процесу. Пропуск багів, які важко виловити або які впливають на дуже малу кількість користувачів, не вважається провалом для тестувальника.
Ще трохи про баг-репорт
- Опис помилки (bug, defect report) є, поряд зі звітом про тестування, основним артефактом, за який відповідає тестувальник
- Рекомендована форма опису помилок для систем, орієнтованих на реалізацію інтерактивного діалогу з користувачем: Що я зробив Що я очікував Що я отримав
- Види дефектів співвідносяться з видами тестування, що проводилися для їх виявлення (рівень 2). Є ще дефекти, спричинені порушенням угод про кодування, стандартів користувацьких інтерфейсів та інші.
- Алгоритм трекінгу дефектів (обліку кроків з опрацювання повідомлення про помилку) може відрізнятися від проєкту до проєкту.
Рекомендована схема трекінгу помилки:
- Тестувальник заносить повідомлення про помилку й адресує його провідному тестувальнику, попередньо вказавши пріоритет помилки.
- Провідний тестувальник перевіряє повноту опису помилки (посилання на вимоги, скриншоти, логи системи чи застосунку) та відтворюваність ситуації, що спричинила збій, а також уточнює пріоритет і передає помилку до групи розробки.
- Зворотний трекінг здійснюється у зворотній послідовності через усі ланки шляху трекінгу.
Моя думати, що ти втомився, але сили зла не дрімають, і добре підготуватися мусиш ти. Спробуй надихнутися та зосередитися
Основні поля баг-репорту:
Короткий опис (Summary)
Короткий опис проблеми, що чітко вказує на причину й тип помилкової ситуації.
Проєкт (Project)
Назва проєкту, що тестується
Компонент застосунку (Component)
Назва частини або функції продукту, що тестується
Номер версії (Version)
Версія, на якій було знайдено помилку
Пріоритет (Priority)
Найпоширенішою є п’ятирівнева система градації серйозності дефекту:
- P1 Блокувальний (Blocker)
- P2 Критичний (Critical)
- P3 Значний (Major)
- P4 Незначний (Minor)
- P5 Тривіальний (Trivial)
(докладніше дивіться нижче в розділі «Пріоритизація дефекту»)
Серйозність (Severity)
Серйозність дефекту:
- S1 Високий (High)
- S2 Середній (Medium)
- S3 Низький (Low)
(докладніше дивіться нижче в розділі «Градація серйозності»)
Статус (Status)
Статус бага. Залежить від процедури, що використовується, та життєвого циклу бага (bug workflow and life cycle)
Автор (Author) або Reporter
Ім’я автора баг-репорту
Призначено на (Assigned To)
Ім’я співробітника, призначеного на вирішення проблеми
Оточення
ОС / Сервіс-пак тощо / Браузер + версія / ...
Інформація про оточення, у якому було знайдено баг: операційна система, сервіс-пак, для веб-тестування – назва й версія браузера тощо.
Опис
Кроки відтворення (Steps to Reproduce)
Кроки, за якими можна легко відтворити ситуацію, що призвела до помилки.
Фактичний результат (Result)
Результат, отриманий після виконання кроків відтворення
Очікуваний результат (Expected Result)
Очікуваний правильний результат
Доповнення
Прикріплений файл (Attachment)
Файл із логами, скриншот або будь-який інший документ, що може допомогти з’ясувати причину помилки чи вказати спосіб розв’язання проблеми
Пріоритизація дефектів
Градація пріоритету дефекту (Priority). Під час опису бага використовується лише англійська назва пріоритету.
- Блокувальний баг (Blocker)
Блокувальна помилка, що призводить застосунок у неробочий стан, унаслідок чого подальша робота з системою, що тестується, або її ключовими функціями стає неможливою. Розв’язання проблеми необхідне для подальшого функціонування системи. - Критичний баг (Critical)
Критична помилка, неправильно працююча ключова бізнес-логіка, діра в системі безпеки, проблема, що призвела до тимчасового падіння сервера або приводить у неробочий стан певну частину системи, без можливості розв’язати проблему через інші точки входу. Розв’язання проблеми необхідне для подальшої роботи з ключовими функціями системи, що тестується. - Значний баг (Major)
Значна помилка, або найстандартніший баг, призначається, коли частина основної бізнес-логіки працює некоректно. Помилка не критична, або є можливість працювати з функцією, що тестується, через інші точки входу. - Незначний баг (Minor)
Незначна помилка, що не порушує бізнес-логіку тієї частини застосунку, що тестується, або очевидна проблема користувацького інтерфейсу. - Тривіальний баг (Trivial)
Тривіальна помилка, що не стосується бізнес-логіки застосунку, погано відтворювана проблема, малопомітна помилка користувацького інтерфейсу, проблема сторонніх бібліотек чи сервісів, проблема, що не має жодного впливу на загальну якість продукту.
Пріоритизація дефектів
Градація серйозності дефекту (Severity)
- S1 Високий (High)
Помилку слід виправити якомога швидше, оскільки її наявність є критичною для проєкту. - S2 Середній (Medium)
Помилку слід виправити, її наявність не є критичною, але вимагає обов’язкового розв’язання. - S3 Низький (Low)
Помилку слід виправити, її наявність не є критичною й не потребує термінового розв’язання.
Порядок виправлення помилок за їхніми пріоритетами:
High -> Medium -> Low
Основні помилки під час складання баг-репортів
- Недостатність наданих даних
Не завжди та сама проблема проявляється за всіх уведених значень і під будь-яким користувачем, що увійшов у систему, тому наполегливо рекомендується вносити в баг-репорт усі необхідні дані. - Визначення пріоритету та серйозності
Дуже часто серйозність дефекту завищують або занижують, що може призвести до неправильної черговості під час розв’язання проблеми. - Мова опису
Часто під час опису проблеми використовують неправильну термінологію або складні мовні звороти, що можуть ввести в оману людину, відповідальну за розв’язання проблеми. - Відсутність очікуваного результату
Якщо ви не вказали, якою має бути потрібна поведінка системи, ви витрачаєте час розробника на пошук цієї інформації й тим самим сповільнюєте виправлення дефекту. Ви маєте вказати пункт у вимогах, написаний тест-кейс або ж вашу особисту думку, якщо ця ситуація не була задокументована.
Відповідальні особи за оформлення полів баг-репорту
Робота з дефектами
(трекінг за статусами)
На схемі зображено класичний алгоритм обробки бага. Баги може заводити будь-хто, але зазвичай це тестувальник або саппорт (другий варіант поганий). Після створення баг отримує статус "new" і йде на перевірку, отримуючи статус "in review". Уточнімо, що не в усіх компаніях роблять баг-рев’ю, і тоді тестувальник одразу переносить баг у стан "open". У разі рев’ю баг можуть закрити (якщо він неактуальний) або передати до відділу розробки на виправлення, той самий "open". Після виправлення багу присвоюється статус "resolved", і тестувальник приступає до перевірки якості виправлення дефекту. Тут два шляхи: повернути на доопрацювання зі статусом "reopen" або закрити баг. У деяких випадках можна навіть перевідкрити закриту багу, якщо вона раптом воскресла в новій версії.
Resolution — причина присвоєння статусу
Статусів у життєвому циклі дефекту обмежена кількість, а для того щоб описати причину того чи іншого статусу, використовують резолюцію. Вона пояснює причину встановлення статусу. Адже всі баги врешті-решт будуть закриті, але причини закриття в усіх різні. Щось виправили, щось відклали, а дещо взагалі виявилося не багом. Вибір резолюцій на проєкті залежить від методології розробки ПЗ. Давайте розглянемо стандартний набір резолюцій:
Fixed/Resolved — найкращий статус, баг виправлено : )
As designed/By design — запропонований баг є фічею
Cannot Reproduce — баг більше не відтворюється, потрібно його перевірити й або уточнити опис, або закрити, якщо відтворити не вдалося
Deferred/Postponed — відкладено до кращих часів
Obsolete/Not relevant — баг застарів, і йому "пора на пенсію", або він просто став неактуальним
Not a bug — ваш баг не визнали таким
Duplicate — такий баг уже є, і один із них слід закрити
Won’t fix — виправляти не хочуть із різних причин, наприклад через надто малий вплив на користувачів за великої складності виправлення
Incomplete — незавершений баг: ганьба й осуд тестувальникові, якому повернули баг із таким статусом, бо не зумів він описати все правильно
Merged — фікс злитий з іншим функціоналом, або задачу включено в основний код, і вона більше не є самостійним кодом
SF Closed — і таке буває, баг самоліквідувався
Статуси можуть бути й іншими в конкретній компанії, а вище перелічено всі стандартні статуси.
Серйозні жарти
Баги класифікують за ступенем їхньої шкідливості:
- showstopper’и
- серйозні
- дрібні
- маячня
- прискіпливість тестувальників
За частотою появи:
- постійно
- іноді (найпідліший тип бага, «плаваючий»)
- лише на машині замовника
Також баги класифікують за тим, хто і де помітив симптоми. Наприклад, якщо баг помітив Мегабос Усіх Замовників на вже запущеній системі, то виправляти його всі вихідні буде весь IT-відділ, разом із прибиральницею.
Особливо приємні баги — showstopper’и, знайдені в п’ятницю ввечері. Вони можуть доставити невимовну насолоду будь-якому програмістові, який любить іти з роботи в суботу зранку.
Баги у великій кількості виробляють аутсорсерські «фабрики» та різноманітні неохайні кодери. Продукти, що містять передозування цих багів, називаються багодромом.
Існує спеціальне закляття: «Це не баг, це фіча», яке дає змогу позбутися бага з найменшими втратами, тобто нічого не роблячи. Проте цим чаклунством володіють лише найдосвідченіші програмісти.
Бойова настанова
Перш ніж самостійно оформлювати баги, перегляньте приклад розстановки пріоритетів для багів. Кожного бага за пріоритетом, так би мовити. Уточнімо також, що в нашій класифікації пріоритет первинний, а серйозність вторинна. Це означає, що спершу визначається пріоритет бага, а кожен із пріоритетів, своєю чергою, ділиться на 3 рівні серйозності, щоб виділити баг серед його друзів. Для цього прикладу взято баги із сайту з купівлі печива (рівень 4).
Blocker
Під час купівлі печива натискання на кнопку "Додати в кошик" перенаправляє на несподівану сторінку. Немає можливості перейти на сторінку з кошиком покупок. Workaround відсутній
Critical
Неможливо купити цукерку на паличці (конкретний вид). Натискання на кнопку "Купити" нічого не дає. У консолі з’являється помилка "Unexpected error", кількість товару в кошику не збільшується
Major
У галереї кексів на головній сторінці не працює одне із зображень. Безкінечно крутиться прелоадер. Кроки відтворення: прокрутити галерею на 5 картинок ...
Minor
Орфографічна помилка в посиланні "купити печиво зараз-зараз" на головній сторінці
Trivial
Посилання "купити печиво зараз-зараз" на головній сторінці не змінює колір після переходу по ньому. ОР: відвідані посилання фіолетового кольору
Відеоурок – усе про баг-репорт на практиці
Практика
Скопіюй собі таблицю мого баг-репорту. Обери останній прийнятий і оцінений баг з останнього домашнього завдання та оформи його за всіма правилами.
Практичне завдання
Вітаю тебе, мій учню! Хочу подякувати тобі за чудове тестування. Мені дуже сподобалися баги, які ти мені надіслав, тому я хочу більше багів!
Але тепер, коли ти знаєш усе про баги, вони мають бути бездоганно оформлені.
Отже, завдання:
Протестувати сайт і знайти всі баги. Баги потрібно оформити згідно з прикладом баг-репорту.
Це найпростіший сайт із тих, що тобі доводилося тестувати, тому буде 2 рівноцінні оцінки:
за знайдені дефекти та за правильність оформлення баг-репорту — вірний опис, правильний пріоритет тощо.
