Основні підходи до ефективного тестування ПЗ

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Усім привіт! Мене звати Вероніка, я General QA Engineer, маю понад чотири роки досвіду роботи. Свою кар’єру в ІТ я розпочала ще навчаючись в університеті, з позиції AQA. Згодом окрім автоматизації, я почала займатись і мануальним тестуванням. Я переконана, що успішне тестування вимагає від нас усвідомлення та дотримання певних принципів.

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

Що таке принципи тестування

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

Принцип 1. Тестування показує наявність дефектів, а не їх відсутність

Що нам каже посібник Foundations of Software Testing: ISTQB Certification:

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

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

Один з випадків, з мого досвіду роботи:

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

Цей дефект підтверджує принцип, що якщо проблему не було виявлено, це не є доказом того що її немає.

Принцип 2. Вичерпне тестування неможливе

Знову звертаємось до посібника Foundations of Software Testing:

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

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

Розглянемо приклад:

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

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

Принцип 3. Раннє тестування економить час і гроші

З посібника Foundations of Software Testing: ISTQB Certification:

Тестування повинно починатися якомога раніше в життєвому циклі розробки програмного забезпечення або системи і повинно бути зосередженим на визначених цілях.

Швидкий початок тестування може зменшити кількість проблем, виявлених на наступних етапах тестування. Як показало дослідження, проведене IBM: те, що коштує один долар, щоб виправити на етапі проєктування, може коштувати п’ятнадцять на етапі тестування та сотню, якщо це буде виявлено на проді.

Раннє тестування також економить час. Наприклад Unit testing або Integration testing можуть швидко виявити недоліки, які можуть спричинити значні затримки розробки, якщо їх виявити пізніше під час тестування системи.

Такі історії, мабуть, траплялись у всіх, я не виняток:

Принцип 4. Скупчення дефектів

З Foundations of Software Testing: ISTQB Certification:

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

Під час тестування більшість виявлених дефектів пов’язані з невеликою кількістю модулів. Іншими словами, 80% дефектів можна знайти у 20% протестованих модулів. Якщо ви знаєте про ці модулі, то можете зосередити свої зусилля на цих критичних областях.

Цей принцип 80:20 також називається принципом Парето — 80% дефектів пов’язані з 20% коду. Хоча багато хто вважає, що він базується на спостереженні, що 80% користувачів використовують 20% програмного забезпечення. Саме ці 20% програмного забезпечення найбільше будуть містити дефектів.

У моїй практиці найчастіше були проблеми з онлайн-оплатою (як просто картою, так і Apple Pay/Google Pay), аутентифікацією користувача та логуванням дій користувача.

Головна задача — визначити найбільш проблемні місця у ПЗ або системі, і далі приділяти більше часу їхньому тестуванню.

Принцип 5. Парадокс пестициду

Звертаємось до нашого посібника Foundations of Software Testing: ISTQB Certification:

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

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

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

Наприклад, маємо логін-форму, де у поле «Пароль» користувачі можуть вводити свої паролі без врахування верхнього або нижнього регістру, тобто «Password» = «password».

Маємо тест-кейс:

Принцип 6. Тестування залежить від контексту

З посібника Foundations of Software Testing:

Тестування проводиться по-різному в різних контекстах. Наприклад, критичні для безпеки ПЗ будуть тестуватися інакше, ніж ecommerce-сайт.

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

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

Для прикладу розглянемо наступні ситуації:

Принцип 7. Відсутність помилок оманлива

З посібника:

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

Іноді програмне забезпечення, яке було протестоване та на 99% без помилок, може бути непридатним для використання. Це може статися, коли об’єкт тестування перевірявся за неправильними вимогами, або просто виявився незручним для користувача. Тестування полягає не лише у виявленні помилок або дефектів; воно також використовується для оцінки того, чи задовольняються бізнес-потреби.

Я думаю, у кожного таке було: викатили фічу, вона чудово працює, зі старих функцій нічого не відпало. Дефектів наче нема, все супер. Потім ви показуєте це клієнту, а він каже: «Це все не те. Давайте, переробляйте».

Приклад з особистого досвіду

У тестуванні недостатньо покладатися лише на відсутність помилок, а також дуже важливо враховувати потреби користувачів. Бо наша головна мета — щоб продукт міг задовольняти потреби користувачів.

Рецензент статті — Геннадій Міщевський.