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

У даній статті ми виділили основні критерії, які, принаймні, допоможуть відповісти на питання: на підставі чого були зроблені висновки про високу якість продукту?

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

Здатність програмного продукту виконувати свої функції (відповідність вимогам)

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

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

Стабільність системи

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

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

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

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

Продуктивність програмного продукту

Це швидкість виконання стандартних функціональних операцій продукту. У цьому випадку критерієм якості може бути або середній час виконання аналогічних операцій у конкурентних продуктах, або показник може бути визначений як “не гірше, ніж у попередніх версіях” (щодо продукту, який вже випускався).

Підтримувані платформи (конфігурації)

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

Кількість інцидентів на продану копію (на одного користувача)

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

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