Тестування

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

Якість програмного забезпечення (Software Quality) – це сукупність характеристик програмного забезпечення, яка відображає його здатність задовольняти встановлені та допустимі вимоги. [ISO 8402:1994]

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

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

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

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

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

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

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

1. Брак або відсутність спілкування в команді

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

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

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

3. Зміна вимог

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

4. Погано задокументований код

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

5. Середовище розробки ПЗ

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