Що таке баг і як з ним боротися

Що таке баг?

У сучасному світі nothing is perfect — ніщо не бездоганно. Дрібниця, що впливає на фідбек від користувача або суттєва проблема, що уповільнює розробку?

Так, сьогодні ми поговоримо про баги. Що це таке та чому їх обов’язково потрібно фіксувати? Давайте розберемося.

З технічної точки зору баг — це помилка, що виникає під час розробки програмного забезпечення (ПЗ).

Баг — від англійського bug, тобто «жук». Восени 1947 року інженери Гарвардського університету ніяк не могли зрозуміти, в чому причина несправності ЕОМ Mark II, поки не виявили метелика, що застряг між контактами реле. Один із них записав у документації це як «Перший випадок виявлення бага». Таким чином з того часу помилки виконання ПЗ стали називати багами.

Як із ними боротися? По-перше, відтворіть баг і переконайтеся, що вам зрозуміло, в якому випадку він виникає. Після цього можна розпочинати роботу з кодом.

У цьому процесі криється два завдання: найголовніше — усунути проблему, але й не допустити появи нових. Що ж, головне правило лікаря – не нашкодити. Це підходить і для світу розробки.

Щоб перевірити, що баг виправлено і нічого нового у процесі не зламалося, потрібно буде провести автоматичні чи мануальні тести.

Алгоритм виправлення бага виглядає так:

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

Чому виникають баги?

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

До вищезазначених причин додамо такі:

• помилки та неуважність при написанні коду;
• нерозуміння логіки певної ділянки коду;
• незнання особливостей мови програмування;
• неправильно складені тести;
• відсутність обробки помилок та взаємодії з ними;
• копіювання чужих помилок.

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

Неуважність при написанні коду

Помилки — невід’ємна частина життя. Іноді натхнення приходить так швидко, що записати все правильно ми просто не встигаємо.

Приклад: вся команда не могла зрозуміти, чому текст не працює, перевіряли в полі значення Сontact. Під час перевірки коду тесту (з увімкненим spellchecker) виявили, що буква «С» написана кирилицею.

У прикладі нижче в missKey пропущено букву «s»:

У таких випадках на допомогу прийдуть:

• аналізатори коду;
• перевірка коду;
• парне програмування.

Нерозуміння логіки коду

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

Якщо можливості зв’язатися з автором коду немає, можна використовувати тести. Також брейншторм з менеджером проекту чи QA — хороша альтернатива.

Нерозуміння особливостей мови програмування

Мова програмування дуже швидко змінюється. Потрібно стежити за оновленнями та бути уважним до деталей.

Наприклад, для вхідного параметра value = 10 умова виконуватиметься. Потрібно додати порівняння ===.

Тести

Як ми вже писали вище, тести поділяються на мануальні та автоматизовані.

Мануальне тестування — це тестування вручну, коли тестувальник перевіряє помилки під час виконання програми, сам вигадуючи тести чи користуючись відповідною документацією.

Іноді таких фахівців називають «манкі-тестерами» Від англ. monkey — мавпа, як би натякаючи на те, що подібна робота ніби не надто інтелектуальна, хоча насправді це не так.

Мануальний тестувальник повинен мати посидючість, уважність, логіку і любов до досліджень, інакше йому не вдасться знайти всі помилки.

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

Автотестер повинен вміти:

• працювати з командним рядком;
• працювати з мовою програмування;
• користуватися інструментами розробників.

Відсутність взаємодії з помилками

Щоб пізнати дзен та навчитися ефективно взаємодіяти з багами, потрібно вміти убезпечити свій код від зовнішнього впливу:

• перевіряти вхідні параметри;
• обробляти винятки;
• застосовувати патерн Null-object.

Копіювання чужих помилок

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

Класифікація багів: якими вони бувають?

Існують дві основні класифікації багів: за ступенем критичності та пріоритетності.

За ступенем критичності можна назвати такі баги:

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

За пріоритетністю виділяють баги:

• fix in release — можна виправити у новій версії продукту. Як правило, це баги, виявлені під час тестування нового функціоналу системи.
• must fix — терміново виправити. Часто це блокуючі баги, що усувають вихід нової версії в спеціальному сервісному пакеті.
• fix if time — виправити, якщо дозволяє час.
• never fix — ніколи не виправляти, наприклад, баги знайдені в продукті, що вже не підтримується.

Як уникнути появи багів?

Чи можна уникнути появи багів? Це практично неможливо. Будь-яка помилка — це досвід. Головне своєчасно її помітити та виправити.

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

Висновок

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

Щоб спростити собі роботу і менше переписувати код після рев’ю тестувальників, багато розробників відразу покривають код автотестами.