Принципи тестування програмного забезпечення пропонують загальні вказівки, спільні для всіх видів тестування, щоб допомогти QA інженерам розробити оптимальну стратегію тестування.
Принцип 1: Тестування показує наявність дефектів
Тестування може показати, що дефекти присутні, але не може довести, що дефектів більше немає. Скільки б успішних тестів ви не провели, ви не можете стверджувати, що немає таких тестів, які не знайшли б помилку.
Цей принцип допомагає визначити очікування стейкхолдерів. Не робіть заяв, що програмне забезпечення не містить дефектів.
Принцип 2: Вичерпне тестування неможливе
Для проведення вичерпного тестування, доведеться перевірити всі можливі вхідні значення та всі шляхи виконання програми, але в більшості випадків кількість таких варіацій наближається до нескінченності, або просто на порядки перевершує відведений час і бюджет. Замість спроб “протестувати все”, потрібен певний підхід до тестування (стратегія), що забезпечить оптимальний обсяг тестування для даного проекту та даних замовників (або/та інших зацікавлених осіб).
Під час визначення достатнього обсягу тестування, необхідно враховувати ризики (технічні, пов’язані з бізнесом, тощо), та обмеження проекту в плані часу, бюджету, ресурсів. Оцінювання та управління ризиками – одна з найважливіших активностей у будь-якому проекті.
Намагання провести вичерпне тестування спалить час і гроші, не впливаючи на загальну якість. Правильний шлях – оптимізувати кількість тестових кейсів за допомогою стандартних стратегій тестування.
Принцип 3: Раннє тестування
Тестові активності мають починатися якомога раніше в SDLC (Software Development Life Cycle), а саме коли сформовано вимоги. Цей принцип пов’язаний з поняттям «ціна дефекту» (cost of defect). Ціна дефекту суттєво зростає впродовж життєвого циклу розробки ПЗ. Чим раніше виявлено дефект, тим швидше, простіше і дешевше його виправити (або взагалі уникнути). Дефект знайдений у вимогах обходиться найдешевше.
Ще одна важлива перевага раннього тестування – економія часу. Тестові активності можуть починатися ще до того, як написано перший рядок коду. По мірі того, як готуються вимоги та специфікації, тестувальники можуть починати розробку та рев’ю тест-кейсів. І коли з’явиться перша тестова версія продукту, можна буде одразу приступати до виконання тестів.
Принцип 4: Скупчення дефектів
Невелика кількість модулів (компонентів системи) містить більшість дефектів, виявлених на етапі тестування. Багато тестувальників спостерігали такий ефект – дефекти «кучкуються». Це може відбуватися тому, що певна ділянка коду особливо складна та заплутана, або внесення змін спричиняє «ефект доміно».
Це знання нерідко використовується для оцінки ризиків, під час планування тестування – QA інженери фокусуються на відомих «проблемних зонах». Також корисно проводити аналіз першопричин (root cause analysis), щоб виявити причини виникнення скупчень дефектів і спрогнозувати їх потенційну появу в майбутньому.
Принцип 5: Парадокс пестициду
Це феномен, згідно з яким що більше ви тестуєте ПЗ, то більш несприйнятливим воно стає до наявних тестів. Тобто кожен метод або набір тестів, котрий використовується для пошуку дефектів, може залишати частину не знайдених помилок, проти яких ці тести неефективні.
Наявні тести застарівають після виправлення дефектів і не можуть виявити нові, з чого випливає, що набір тестів, тестових даних і підходів, потрібно постійно переглядати і покращувати для виявлення не знайдених помилок. Також є сенс оновлювати тести і тестові дані, після виправлення вже знайдених дефектів.
Принцип 6: Тестування залежить від контексту
Тестування виконується по-різному, в залежності від контексту. Наприклад, тестування систем, критичних з точки зору безпеки, проводиться інакше, ніж тестування інтернет-магазину. Цей принцип тісно пов’язаний з поняттям ризиків.
Ризик – це потенційна проблема. У ризиків є ймовірність (likelihood) – вона завжди вища за 0 і нижча за 100%, і є вплив (impact) – ті негативні наслідки, яких ми остерігаємось. Аналізуючи ризики, ми зважуємо ці два аспекти: ймовірність і вплив.
Те саме можна сказати і про світ програмного забезпечення: різні системи, пов’язані з різними рівнями ризику, вплив того чи іншого дефекту також сильно варіюється. Одні проблеми досить тривіальні, інші можуть дорого обійтися і призвести до великих втрат грошей, часу, ділової репутації, а в деяких випадках навіть призвести до нещасних випадків. Рівень ризику впливає на вибір методологій, технік і типів тестування.
Принцип 7: Хибна думка про відсутність помилок
Виявлення та виправлення дефектів марне, якщо побудована система незручна для використання, і не відповідає потребам та очікуванням користувачів.
Замовники програмного забезпечення – люди й організації які купують і використовують його, для виконання своїх повсякденних завдань, насправді не дуже цікавляться дефектами та їхньою кількістю, окрім тих випадків, коли вони безпосередньо стикаються з нестабільністю продукту. Користувачі ПЗ більш зацікавлені в тому, щоб воно допомагало їм ефективно виконувати свої завдання.
Навіть якщо ви виконали всі тести і не виявили помилок, це ще не є гарантією того, що програмне забезпечення відповідатиме потребам і очікуванням користувачів. Інакше кажучи, верифікація не дорівнює валідації (докладніше про верифікацію та валідацію в розробці програмного забезпечення).