ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 1.3.

Протягом останніх 50 років було запропоновано ряд принципів тестування, які пропонують загальні вказівки для всіх тестів.

Тестування показує наявність дефектів, а не їх відсутність (версія 3.1)

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

Тестування показує наявність, а не відсутність дефектів. (версія 4.0)

Тестування може показати наявність дефектів в тестовому об’єкті, але не може довести, що дефектів немає (Buxton 1970). Тестування знижує ймовірність того, що дефекти залишаться невиявленими в об’єкті тестування, але навіть якщо дефектів не буде виявлено, тестування не може підтвердити правильність об’єкта тестування.

Вичерпне тестування неможливе (версія 3.1)

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

Вичерпне тестування неможливо (версія 4.0)

Перевірити все неможливо, за винятком тривіальних випадків (Manna 1978). Замість того, щоб намагатися провести вичерпне тестування, слід використовувати методи тестування, визначення пріоритетів тестових випадків і тестування на основі ризику, щоб зосередити зусилля на тестуванні.

Раннє тестування економить час і гроші (версія 3.1)

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

Раннє тестування економить час і гроші (версія 4.0)

Дефекти, усунуті на ранній стадії процесу, не призведуть до наступних дефектів у похідних робочих продуктах. Вартість якості буде знижена, оскільки пізніше в SDLC виникатиме менше збоїв (Boehm 1981). Щоб виявити дефекти на ранній стадії, статичні та динамічні випробування слід починати якомога раніше.

Дефекти групуються разом (версія 3.1)

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

Дефекти групуються разом (версія 4.0)

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

Остерігайтеся парадоксу пестицидів (версія 3.1)

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

Тести зношуються (версія 4.0)

Якщо ті самі тести повторювати багато разів, вони стають все більш неефективними у виявленні нових дефектів (Beizer 1990). Щоб подолати цей ефект, може знадобитися модифікувати існуючі тести та тестові дані, а також написати нові тести. Однак у деяких випадках повторення тих самих тестів може мати позитивний результат, наприклад, у автоматизованому регресійному тестуванні.

Тестування залежить від контексту (версія 3.1)

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

Тестування залежить від контексту (версія 4.0)

Немає єдиного універсального підходу до тестування. Тестування проводиться по-різному в різних контекстах (Kaner 2011).

Відсутність помилок є оманою (версія 3.1)

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

Помилка про відсутність дефектів (версія 4.0)

Очікувати, що перевірка програмного забезпечення забезпечить успішну роботу системи, є помилкою (тобто помилковим уявленням). Ретельне тестування всіх зазначених вимог і усунення всіх виявлених дефектів все одно може призвести до створення системи, яка не відповідає потребам і очікуванням користувачів, яка не сприяє досягненню бізнес-цілей замовника та є гіршою порівняно з іншими системами-конкурентами. На додаток до верифікації також має бути проведена перевірка (Boehm 1981).