Шлях виправлення багу або to be, or not to be…

Вступ

Багато хто чув фразу відомого давньогрецького філософа Арістотеля, що життя – це рух, а рух – це життя. Із з цим важко не погодитись, враховуючи кількість досліджень про вплив фізичної активності на здоров’я та довжину життя людини, але чи мав Арістотель на увазі тільки фізкультуру? Як на мене, вищезазначене твердження справедливе до будь-якої активності будь-якого об’єкта, не обов’язково істоти, але і визначення терміну «життя» в даному контексті далеке від біологічного. Але у нас тут «тусня» фахівців галузі QA, тому я спробую прикласти тезис Арістотеля до наших професійних реалій.

Цікавий факт:

Крім того, що Арістотель був відомим філософом та одним з фундаторів географії (першим схарактеризував природу океану і землі, пояснив колообіг води в природі, описав дію і характер землетрусу, вітрів, променів, грому і веселки, метеорів і комет, Чумацького шляху), він також відомий тим, що певний час виховував Олександра Македонського, який потім сказав: «Від батька я отримав життя, а від Арістотеля те, за що мене варто шанувати». Тому поважаймо тих людей, які брали участь у формування нас, як особистостей та фахівців!

Частина 1: Найфундаментальніше поняття та усе, що з ним пов’язано

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

І усі ці баги живуть та процвітають: кішка – лякає людей, зі стільця всі падають, а люстра просто висить та нікому не світить, отже, Арістотель все ж таки щось знав! Але ми з вами, шановні читачі, професіонали своєї справи, тому маємо знати, що насправді існують не тільки баги, а й дефекти, помилки, несправності та збої (англ. bugs, defects, error, fault, and failure). Ви, звичайно, можете мене запитати, навіщо нам розрізняти це все, якщо наша справа – це виявити та задокументувати, а виправляти – то вже до інших? Ну, питання досить дискусійне: з одного боку, ця інформація може знадобитись вам при складанні екзамену на сертифікацію ISTQB, тому ці знання можна вважати інвестицією в майбутнє, також завдяки такій таксономії ми можемо отримати багато корисної додаткової інформації, але про це трохи згодом; а з іншого боку, у буденності нашої галузі усе називають багами та на цьому квит. Як на мене, знання за плечима не носити, тому пропоную все ж таки розглянути вищезазначені поняття та порівняти для кращого розуміння різниці.

Предмет порівняння	Bug (баг)	Defect (дефект)	Error (помилка)	Fault (несправність)	Failure (збій)
Визначення	неформальна назва дефекту	різниця між фактичними та очікуваними результатами	недолік у коді, через який ми не можемо виконати або скомпілювати код	стан, який призводить до того, що програмне забезпечення не може виконати основні функції	стан, в якому програмне забезпечення не може виконувати свої основні функції або не працює взагалі
Виявлення	виявляють та надсилають інженери-тестувальники	виявляють та надсилають інженери-тестувальники	повідомляють розробники та інженери з автоматизованого тестування	людський фактор спричиняє несправності	вручну протягом усього циклу розробки
Типи	-Логічні -Алгоритмічні -Ресурсні	За пріоритетом: -Високі -Середні -Низькі За серйозністю: -Критичні -Значні -Незначні -Легкі	-Синтаксичні -Інтерфейсу користувача -Управління потоком -Обробки помилок -Розрахунку -Апаратні -Тестування	-Бізнес-логіки -Функціональності та логіки -Графічного інтерфейсу -Продуктивності -Безпеки -Програмного / апаратного забезпечення	–

Отже, як бачимо, межа між цими поняттями досить тонка, але вона є. А тепер, як і обіцяв, поговоримо про додаткову інформацію, яку більшість початківців несвідомо ігнорує. Є такий загальноприйнятий, але ніде не прописаний, принцип лопати: «Якщо знайшов баг, то копай поруч». Мається на увазі, що кожний баг треба досліджувати, але якщо ви ще не вмієте, то зараз я все покажу:

• Причина чи наслідок: Треба зрозуміти, що саме було знайдено, бо, можливо, є шанс знайти щось більше.  Наприклад, головний біль – це наслідок, а ось удар по голові – це вже причина болю.

• Час виникнення: Варто спробувати знайти той момент, коли проблема виникла, бо, можливо, вона встигла нашкодити в багатьох місцях. Наприклад, якщо ми спіймали мишу у вітальні, треба піти обов’язково перевірити льох із продуктами, можливо, вона вже встигла там побувати.

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

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

• Об’єктивна вартість: Скільки збитків завдала ця проблема? Відповівши на це запитання, ми зрозуміємо критичність цієї проблеми, що стане нам у пригоді під час написання баг репорту, та упевнимося у своїй професійності, що може трохи підняти нашу самооцінку, мов, не дарма їмо свій хліб, але тут головне не загратись, бо так і до статусу супергероя недалеко. Наприклад, якщо під час тестування безпеки нам вдалося знайти місце потенційної втрати користувацьких даних, то у баг репорту сміливо пишемо: «Severity: Critical».

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

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

Частина 2: Життєвий цикл багу та таємниця назви

Після того, як ми з’ясували що таке баг, познайомились з його колегами та розглянули принцип їх дослідження, виникає справедливе питання: «А що далі, вже після того, як ми добряче «познайомились» з проблемою?». А відповідь буде така: «Варто відкрити йому шлях до виправлення!». Тобто запустити процес, який дасть змогу його позбутись. Цей процес має назву «життєвий цикл багу» (знов згадуємо про Арістотеля). Звичайно, що знавці теорії тестування вже давно все описали: і етапи, і схеми, і статуси, тому я хотів би представити трохи дороблену версію цього шляху:

Ну, що, як вам? Нічого не нагадує? Якщо казати по-розумному, то це розгалужений алгоритм, а якщо по-людськи, то це якійсь складний шлях, що має свої правила руху. Тож, пропоную ознайомитись зі всіма етапами «шляху виправлення багів» (так, саме завдяки цій аналогії обрана перша частина назви цієї статті) прикладі досвідченого багу Валерія:

1. Тестувальник знаходить баг, тобто Валерія, та добре із ним знайомиться. Саме на цьому етапі варто чітко визначити, чи Валерій все ж таки баг, чи ні: декілька разів відтворити ситуацію, в якій з ним можна зустрітись, та перевірити вимоги, бо пізніше, коли Валерія буде висвітлено і навіть призначено людей для його виправлення, буде не зовсім гарно сказати: «Ой, щось я помилився, тут все ок».

2. Призначається статус «New». Валерій береться на облік, на нього складаються документи (маю на увазі ID та баг репорт), для того, щоб за ним було зручно слідкувати.

3. PM аналізує поданий баг. Взагалі PM та Валерій дуже комунікабельні хлопці: PM особисто знайомиться майже з кожним товаришем Валерія (або, принаймні, одним оком дивиться за ними, якщо не має на це часу), а сам Валерій із товаришами прагнуть познайомитись з якомога більшою кількістю людей (QA, Dev, PM, можливо навіть BA).

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

5. Якщо Валерій не є багом, то PM надає йому статус «Rejected». Тобто Валерій не має права знаходитись на цьому шляху, оскільки не є достатньо поганим, том отримує відповідь: «Із речами на вихід!».

6. Якщо Валерій все ж таки є багом, але із ним щось не так: не з нашої зони відповідальності; настільки маленький, що зачекає; наразі немає часу із ним возитись, — то PM надає йому статус «Deferred», тобто відкладає. І Валерій буде чекати стільки, скільки треба.

7. Якщо брат-близнюк Валерія вже знаходиться на нашому шляху, то PM надає статус «Duplicated». Оскільки репорти однакові, тобто помічають один і той самий баг, то другий ніхто, звичайно не заводить.

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

9. Як тільки розробник закінчив роботу, і Валерій перестав бути шкідливим, то статус змінюється на «Fixed». З цього моменту наш продукт повинен працювати як годинник, якщо ми, звичайно, не знайдемо іншого Валерія.

10. Далі тестувальник зобов’язаний перевірити, чи дійсно Валерій знешкоджений. Тому після повернення до місця зустрічі та відтворення умов появи, тестувальник підтверджує, що все ок, і змінює статус на «Closed».

11. Якщо ж розробник не до кінця виправив Валерія і тестувальник з’ясував це, то статус змінюється на «Reopened». Тобто Валерій повертається до розробника на 8-й етап.

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

Далі хотілося б висвітлити ту одвічну проблему, якої ми трохи торкнулись у 4-му етапі нашого «шляху виправлення»: баг або фіча. Якщо із терміном «баг» ми вже добре знайомі то, то «фічу» треба трохи пояснити. «Фічею» (від англійського feature, «характеристика, властивість») називають додаткову, спеціально придуману (і, можливо, неочевидну) опцію програми. Як же їх відрізнити? Все просто: дивимося у вимоги, і якщо цієї властивості не було прописано, то на поточний момент це баг, бо все, що відхиляється від вимог – це не норма. Але, звичайно, якщо фіча є корисною для проєкту, то її треба узгодити із PM чи BA і занести у вимоги, і тільки тоді вона припинить бути багом.

Цікавий факт:

Існує стереотип, що деякі вразливі розробники не зовсім адекватно сприймають термін «баг», і коли до них приходить тестувальник із таким «багом», у них починаються легкі прояви агресії та стадія відмови, бо в їх розумінні баг – це серйозна проблема, яка заважає роботі усього продукту, і, якщо багом виявляється щось менш критичне, можуть початися «гойдалки» типу: «Хіба це баг? І так піде!» або «Це не баг, а фіча! Нащо це виправляти?» і так далі. Тому, якщо ви не хочете перевіряти, чи існує цей стереотип, чи ні, рекомендується замість терміну «баг» вживати терміни «недолік» або «дефект», і розробник буде задоволений, і баг виправлений!

Наостанок, хочеться все ж таки пояснити причину вибору саме такої другої частини назви статті. Як ви, шановні читачі, вже могли помітити, друга частина назви – це перші строки монологу Гамлета відомої п’єси Шекспіра. У цьому монолозі мова йде про життєву позицію людини, який вибір їй зробити: підкоритися ударам долі чи боротися, захищаючи свою гідність. Герой не може обрати ні те, ні інше, тому замислюється над іншим виходом з ситуації: піти з життя, тобто уникнути вибору. Мені здається, що усі фахівці галузі QA постають перед аналогічним питанням: застрягти на певному рівні, виправдовуватись складними часами та працювати упівсили або витрачати купу часу (часто особистого), розбиратись з усіма нюансами галузі та кожного дня покращувати себе як спеціаліста. Також існує третій варіант – взагалі піти з галузі, бо тут занадто важко: багато нюансів, велика конкуренція і так далі. Саме з цієї причини кожний фахівець приймає рішення, яке визначає його як людину і як спеціаліста. Тому, шановні читачі, вибір за вами!

Підсумок

У цій статті ми говорили про так званий «шлях виправлення багу», розбирали таке поняття, яке у класичнішому варіанті називається життєвий цикл багу.

Ми почали з розмірковувань над тезисом Арістотеля («життя – це рух, а рух – це життя») і розглянули найрозповсюдженіший термін нашої галузі  – «баг» (це коли щось не так, як треба). Також з’ясували, що існують інші пов’язані поняття, а саме дефекти, помилки, несправності та збої (англ. defects, error, fault, and failure), порівнявши їх у таблиці для наочності. Висвітлили метод аналізу багів (причина чи наслідок, час виникнення, метод виявлення, можливість раннього виявлення, об’єктивна вартість, типізація), завдяки якому можна отримати купу додаткової інформації та неабияк покращити увесь процес забезпечення якості.

Далі ми розглянули усі етапи життєвого циклу багу (сподіваюсь вам сподобався Валерій) та запропонували підхід до розв’язання одвічної проблеми «баг або фіча» (якщо цієї властивості не було прописано у вимогах, то на поточний момент це баг). Наостанок розглянули важливу проблему, висвітлену у монолозі Гамлета однойменної п’єси Шекспіра (to be, or not to be…), та провели аналогію із проблематикою галузі QA (стояти на місці, розвиватись або піти).

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