База знань

Звідки беруться помилки в ПЗ?

Чому програми працюють неправильно? Все дуже просто – вони створюються і використовуються людьми.

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

Помилка (error) – це дія людини, яка може привести до неправильного результату.

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

Дефект, Баг (Defect, Bug) – недолік компонента або системи, який може привести до відмови певної функціональності. Дефект, виявлений під час виконання програми, може викликати відмову окремого компонента або всієї системи.

При виконанні коду програми, дефекти, закладені ще під час його написання, можуть проявитися: програма може не робити того, що повинна або навпаки – робити те, чого не повинна, тобто  відбувається збій.

Збій (failure) – невідповідність фактичного результату (actualresult) роботи компонента або системи очікуваного результату (expectedresult).

Збій в роботі програми може бути індикатором наявності в ній дефекту.

Таким чином, баг існує при одночасному виконанні трьох умов:

– відомий очікуваний результат;

– відомий фактичний результат;

– фактичний результат відрізняється від очікуваного результату.

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

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

Всього існує кілька джерел дефектів і, відповідно, збоїв:

– помилки в специфікації, дизайні або реалізації програмної системи;

– помилки використання системи;

– несприятливі умови навколишнього середовища;

– умисне заподіяння шкоди;

– потенційні наслідки попередніх помилок, умов або навмисних дій.

Дефекти можуть виникати на різних рівнях, і від того, чи будуть вони виправлені і коли, буде залежати якість системи.

Якість (Quality) – показник того, наскільки  сукупність притаманних характеристик відповідає вимогам.

Якість програмного забезпечення (Software Quality) – це сукупність характеристик програмного забезпечення, що відображають його здатність задовольняти встановлені і передбачувані потреби.

Вимога (Requirement) – потреба або очікування, які встановлені. Зазвичай передбачаються або є обов’язковим.

Для демонстрації залежності якості системи від дефектів, які з’являються в ній  на різних рівнях процесу розробки, можна навести таку схему:

oshibki_v_po

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

У другому  випадку помилки були допущені вже при кодуванні, що спричинило появу дефектів у готовому продукті.  Але на цьому рівні баги досить легко виявити і виправити, оскільки ми бачимо невідповідність вимогам.

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

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

Умовно, можна виділити 5 причин виявлення дефектів в програмному коді:

  • Недоліки  або відсутність спілкування в команді

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

  • Складність програмного забезпечення

Сучасне ПЗ складається з безлічі компонентів, які об’єднуються в складні програмні системи. Багатопотокові програми, клієнт-серверна і розподілена архітектура, багаторівневі бази даних – програми стають все складнішими в написанні і підтримці, і  відповідно важчою стає робота програмістів. А чим важче робота, тим більше помилок може допустити людина, яка все це виконує.

  • Зміни вимог

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

  • Погано документований код

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

  • Засоби розробки ПЗ

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

Набагато більше інформації на курсі базовий модуль тестування