Принципи тестування
Last updated
Last updated
Тестування демонструє наявність дефектів (Testing shows presence of defects)
Вичерпне тестування недосяжне (Exhaustive testing is not possible)
Раннє тестування (Early testing)
Нагромадження/кластеризація дефектів (Defect clustering)
Парадокс пестициду (Pesticide paradox)
Тестування залежить від контексту (Testing is context dependent)
Помилка про відсутність помилок (Absence of errors fallacy)
Принцип 1. Тестування показує наявність дефектів Тестування може показати, що дефекти присутні, але може довести, що дефектів більше немає. Скільки б успішних тестів ви не провели, ви не можете стверджувати, що немає таких тестів, які б не знайшли помилку.
Принцип 2 . Для проведення вичерпного тестування доведеться протестувати всі можливі вхідні значення і всі шляхи виконання програми, в більшості випадків кількість таких варіацій прагне нескінченності або просто перевищує відведений час і бюджет. Замість спроб «протестувати все» нам потрібен певний підхід до тестування (стратегія), який забезпечить правильний обсяг тестування для даного проекту, даних замовників (та інших зацікавлених осіб) та даного продукту. Визначаючи, який обсяг тестування достатній, необхідно враховувати рівень ризику, включаючи технічні ризики та ризики, пов'язані з бізнесом, та такі обмеження проекту як час та бюджет. Оцінка та управління ризиками – одна з найважливіших активностей у будь-якому проекті.
Принцип 3. Ранне тестування Тестові активності повинні починатися якомога раніше в SDLC, а саме коли сформовані вимоги. Цей принцип пов'язані з поняттям «ціна дефекту» (cost of defect). Ціна дефекту суттєво зростає протягом життєвого циклу розробки ПЗ. Чим раніше виявлено дефект, тим швидше, простіше та дешевше його виправити. Дефект, знайдений у вимогах, обходиться найдешевше. Ще одна важлива перевага раннього тестування – економія часу. Тестові активності можуть починатися ще до того, як написано перший рядок коду. У міру того, як готуються вимоги та специфікації, тестувальники можуть приступати до розробки та реву тест-кейсів. І коли з'явиться перша тестова версія, можна відразу приступати до виконання тестів.
Принцип 4. Скупчення дефектів
Невелика кількість модулів містить більшість дефектів, виявлених на етапі передрелізного тестування, або демонструють найбільшу кількість відмов на етапі експлуатації. Багато тестувальників спостерігали такий ефект – дефекти «купкуються». Це може статися тому, що певна область коду особливо складна і заплутана, або тому, що внесення змін робить «ефект доміно». Це знання часто використовується для оцінки ризиків під час планування тестів – тестувальники фокусуються на відомих «проблемних зонах». Також корисно проводити аналіз першопричин (root cause analysis), щоб запобігти повторній появі дефектів, виявити причини виникнення скупчень дефектів та спрогнозувати потенційні скупчення дефектів у майбутньому.
Принцип 5 .
Boris Beizer у своїй книзі Software Testing Techniques пояснив парадокс пестициду як феномен, за яким чим більше ви тестуєте ПО, тим несприйнятливіше воно стає до наявних тестів, тобто.
кожен метод та набір тестів, який використовується для запобігання або пошуку помилок, може залишати частину не знайдених помилок, проти яких ці методи та тести є неефективними;
наявні тести старіють після виправлення дефекту та не можуть виявити нові;
З чого випливає, що набір тестів, тестових даних та підходів потрібно постійно переглядати та покращувати для виявлення не знайдених помилок, а також необхідно оновлювати тести та тестові дані після виправлення вже знайдених дефектів.
Принцип 6. Тестування залежить від контексту Тестування виконується по-різному залежно від контексту. Наприклад, тестування критичних систем з точки зору безпеки проводиться інакше, ніж тестування сайту інтернет-магазину. Цей принцип тісно пов'язані з поняттям ризику. Що таке ризик? Ризик – це потенційна проблема. У ризику є ймовірність (likelihood) - вона завжди вища за 0 і нижче 100% - і є вплив (impact) - ті негативні наслідки, яких ми побоюємося. Аналізуючи ризики, ми завжди зважуємо ці два аспекти: ймовірність та вплив. Те саме можна сказати і про світ ПЗ: різні системи пов'язані з різними рівнями ризику, вплив того чи іншого дефекту також сильно варіюється. Одні проблеми досить тривіальні, інші можуть дорого обійтися і призвести до великих втрат грошей, часу, ділової репутації, а в деяких випадках навіть призвести до травм та смерті. Рівень ризику впливає вибір методологій, технік і типів тестування. Принцип 7. Помилка про відсутність помилок Знаходження та виправлення дефектів марно, якщо побудована система незручна для використання та не відповідає потребам та очікуванням користувачів. Замовники ПЗ - люди та організації, які купують і використовують його, щоб виконувати свої повсякденні завдання - насправді зовсім не цікавляться дефектами та їх кількістю, крім тих випадків, коли вони безпосередньо стикаються з нестабільністю продукту. Їм також нецікаво, наскільки ПЗ відповідає формальним вимогам, задокументованим. Користувачі ПЗ більш зацікавлені в тому, щоб воно допомагало їм ефективно виконувати завдання. ПЗ має відповідати їхнім потребам, і саме з цього погляду вони його оцінюють. Навіть якщо ви виконали всі тести та помилок не виявили, це ще не гарантія того, що програмне забезпечення відповідатиме потребам та очікуванням користувачів. Інакше висловлюючись, верифікація не дорівнює валідації.
Джерела:
Дод. матеріал:
7 принципів тестування. ,