Поняття димового тестування

Димове тестування (Smoke testing) також є аналогом тестування складання (Build Verification Testing) – це тип тестування програмного забезпечення, який включає невичерпний набір тестів, спрямованих на перевірку роботи найбільш важливих, критичних функцій в системі. Результат цього тестування використовується для визначення того, чи досить стабільна збірка, щоб продовжити подальше тестування.

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

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

Переваги димового тестування:

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

Поняття санітарного тестування

Санітарне тестування або перевірка працездатності (Sanity testing) – це дуже коротка поглиблена перевірка певної функціональності комп'ютерної програми, системи, веб-сайту, розрахунків і так далі, яка проводиться з метою переконатися, що система працює належним чином. Цей вид тестування часто виконується до початку повного циклу регресійного тестування, але після проведення димового тестування.

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

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

Декілька важливих особливостей санітарного тестування:

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

Переваги санітарного тестування:

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

Порівняльна таблиця димового і санітарного тестування

Smoke testing (Димове тестування)

Sanity testing (Перевірка працездатності, санітарне тестування)

Виконується на початкових збірках програмного продукту перед регресійним тестуванням Проводиться на збірках, які успішно пройшли димові випробування і перед циклом регресійного тестування
Тестована збірка може бути стабільною або нестабільною Тестована збірка відносно стабільна
Мотивом є перевірка стабільності нової зібраної версії продукту в цілому Основною метою є перевірка раціональності системи в деталях, щоб приступити до ретельного тестування
Збій при тестуванні призводить до негайної відмови від цієї збірки програмного забезпечення Збій в перевірці працездатності поміщає збірку програмного забезпечення в список відхилених
Може виконуватися як розробниками, так і тестувальниками Зазвичай проводиться тестувальниками
Включає документацію і роботу за сценарієм Не робить акценту на якій-небудь документації і роботу за сценарієм
Можна розглядати як загальний вигляд тестування, що поверхнево покриває усі основні функції без глибокого тестування Спеціалізована або детальніше орієнтована методика тестування, спрямована на певну функціональність або функцію
Може бути виконано як автотестами, так і вручну Зазвичай виконується вручну
Економить зусилля команди тестувальників і мінімізує час роботи над дефектним складанням програмного забезпечення Зберігає час в умовах, коли його недостатньо для максимально великого регресійного тестування

Приклади використання димового і санітарного тестування

Розглянемо детальніше ці види тестування на прикладі реальних кейсів.

Приклад димового тестування. Припустимо, що в тестованому проекті є п'ять модулів, таких як:

  • вхід в систему;
  • перегляд користувача;
  • сторінка відомостей про користувача;
  • створення нового користувача;
  • створення завдань і так далі.

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

  • користувач може увійти з дійсними обліковими даними;
  • користувач НЕ може увійти з недійсними обліковими даними;
  • після входу може бути створений новий користувач або ні;
  • чи доступний для використання створений користувач або ні.

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

Приклад санітарного тестування. Знову припустимо, що в нашому проекті є п'ять модулів, таких як:

  • вхід в систему;
  • перегляд користувача;
  • сторінка відомостей про користувача;
  • створення нового користувача;
  • створення завдань і так далі.

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

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

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

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