Тестування диму проти осудності: різниця з прикладами

smoke testing vs sanity testing

Детально вивчіть відмінності між тестуванням диму та тестуванням розумності на прикладах:

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

У більшості випадків ми плутаємося між значенням перевірки розумності та перевірки диму. Перш за все, ці два тестування - це “ інший ”І виконуються на різних етапах циклу випробувань.

Що ви дізнаєтесь:

• Перевірка розумності
• Мій досвід
• Тестування розумності проти регресійного тестування
• Стратегія тестування мобільних додатків
• Запобіжні заходи
• Тестування диму
• Приклади тестування диму
  • # 1) Прийомне тестування
  • # 2) Тестування інтеграції
  • # 3) Тестування системи
• Важливість у методології SCRUM
• Тест на дим проти побудови випробувальних тестів
• Цикл тесту на дим
• Хто повинен проводити тест на дим?
• Чому ми повинні автоматизувати тести на дим?
• Переваги та недоліки
• Різниця між тестом на дим і розум
  • ТЕСТУВАННЯ ДИМУ
  • ТЕСТУВАННЯ САНІТНОСТІ
• Рекомендована література

Перевірка розумності

Тестування на обґрунтованість проводиться, коли в якості контролю якості ми не маємо достатньо часу для запуску всіх тестових випадків, нехай це буде Функціональне тестування , Тестування інтерфейсу користувача, ОС чи браузера.

Отже, я б визначив,

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

Хіба ми всі не потрапляємо в ситуацію, коли нам доводиться виходити з обліку через день-два, але збірка для тестування все ще не випущена?

Як створити новий проект Java в eclipse - -

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

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

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

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

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

Мій досвід

З моєї 8+ років кар'єри в тестуванні програмного забезпечення, я 3 роки працював у Спритний методолог y, і це був час, коли я здебільшого використовував тест на розум.

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

Отже, ось деякі ключові вказівки, якими я дотримувався в таких ситуаціях:

# 1) Посидьте з менеджером та розробницькою командою, коли вони обговорюють впровадження, тому що вони повинні працювати швидко, і тому ми не можемо очікувати, що вони пояснять нам окремо.

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

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

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

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

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

# 5) Коли команда розробників тестує в кінці, спробуйте створити пару з ними (так зване сполучення dev-QA) і зробити базовий раунд на самому їх налаштуванні, це допоможе уникнути збірки туди-сюди, якщо основна реалізація не вдається .

# 6) Тепер, коли у вас є збірка, спершу протестуйте бізнес-правила та всі випадки використання. Ви можете зберегти такі тести, як перевірка поля, навігації тощо на потім.

# 7) Які б помилки ви не виявили, занотуйте їх усі та намагайтеся повідомляти їх розробникам, а не повідомляти окремо, тому що їм буде легко працювати над цілою групою.

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

# 9) Це найважливіша частина, і справді останній крок вашої стратегії перевірки розумності - «Коли ви складаєте електронний лист випуску або документ, згадайте всі тестові випадки, які ви виконували, помилки, знайдені маркером стану, і якщо щось залишилось неперевірені згадайте це з причинами ' Спробуйте написати чітку історію про своє тестування, яка розповість всім про те, що було перевірено, перевірено, а що ні.

Я дотримувався цього релігійно, коли використовував це тестування.

Дозвольте поділитися власним досвідом:

# 1) Ми працювали над веб-сайтом, і він використовував спливаючі оголошення на основі ключових слів. Раніше рекламодавці розміщували ставки для певних ключових слів, що мали екран, розроблений для них. Значення ставки за замовчуванням відображалося як $ 0,25, яке учасник може навіть змінити.

Було ще одне місце, де ця ставка за замовчуванням відображалася, і її також можна було змінити на інше значення. Клієнт надійшов із запитом змінити значення за замовчуванням із $ 0,25 на $ 0,5, але він згадав лише очевидний екран.

Під час нашої дискусії про мозковий штурм ми забули (?) Про цей інший екран, оскільки він не надто використовувався для цієї мети. Але під час тестування, коли я провів основний випадок, коли ставка становила 0,5 дол. США, і перевірив кінець у кінець, я виявив, що cronjob для того самого провалився, оскільки в одному місці він знайшов 0,25 дол.

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

# два) У рамках того ж проекту (згаданого вище) нас попросили додати невелике текстове поле для приміток / коментарів для торгів. Це було дуже просте впровадження, і ми взяли на себе зобов'язання здійснити його того ж дня.

Отже, як уже згадувалося вище, я перевірив усі бізнес-правила та випадки використання навколо них, і, провівши тестування на перевірку, виявив, що коли я вводив комбінацію спеціальних символів, наприклад, сторінка виходила з ладу.

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

# 3) Нещодавно я працював над проектом мобільних додатків, і ми мали вимогу оновити час доставки, показаний у додатку, відповідно до часового поясу. Це було не лише для тестування в додатку, але й для веб-служби.

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

Тестування розумності проти регресійного тестування

Нижче наведено кілька відмінностей між ними:

Стратегія тестування мобільних додатків

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

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

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

Нижче наведено кілька вказівок, які допоможуть вам успішно виконати це тестування на мобільному додатку:

# 1) Перш за все, проаналізуйте вплив версії ОС на реалізацію разом із вашою командою.

Спробуйте знайти відповіді на запитання, наприклад, чи буде поведінка відрізнятися в різних версіях? Чи буде впровадження працювати з найнижчо підтримуваною версією чи ні? Чи будуть проблеми з продуктивністю впровадження версій? Чи існує якась особлива особливість ОС, яка може вплинути на поведінку впровадження? тощо

# два) Як зазначено вище, проаналізуйте також моделі телефонів, тобто чи є якісь функції телефону, які можуть вплинути на впровадження? Чи реалізація змін поведінки за допомогою GPS? Чи змінюється поведінка впровадження з камерою телефону? тощо. Якщо ви виявите, що це не впливає, уникайте тестування на різних моделях телефонів.

# 3) Якщо не буде внесено жодних змін інтерфейсу для впровадження, я б рекомендував тримати тестування інтерфейсу з найменшим пріоритетом, ви можете повідомити команду (якщо хочете), що інтерфейс не буде перевірятися.

# 4) Щоб заощадити свій час, уникайте тестування на хороших мережах, оскільки очевидно, що впровадження буде працювати належним чином у потужній мережі. Я б порадив почати з тестування в мережі 4G або 3G.

# 5) Це тестування має бути здійснено за менший час, але переконайтесь, що ви виконали принаймні один польовий тест, якщо це не є простою зміною інтерфейсу користувача.

# 6) Якщо вам потрібно протестувати матрицю різних ОС та їх версії, я б запропонував зробити це розумно. Наприклад, виберіть для тестування пари найнижчої, середньої та останньої версій ОС. У документі про випуск можна зазначити, що не кожна комбінація перевірена.

# 7) Подібним чином, для перевірки розумності впровадження інтерфейсу користуйтеся екранами малого, середнього та великого розмірів, щоб заощадити час. Ви також можете використовувати симулятор та емулятор.

Запобіжні заходи

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

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

Щоб ви не стали жертвою цього, переконайтесь, що:

• Ніколи не приймайте збірку для тестування, доки клієнт не отримає письмових вимог. Трапляється, що клієнти повідомляють про зміни або нові реалізації усно або в чаті чи простому лайнері в електронному листі і очікують, що ми будемо ставитись до цього як до вимоги. Примусіть свого клієнта надати деякі основні пункти функціональності та критерії прийнятності.
• Завжди робіть грубі примітки про тестові кейси та помилки, якщо у вас недостатньо часу, щоб їх акуратно написати. Ніколи не залишайте ці документи без документів. Якщо є трохи часу, поділіться цим зі своїм керівником або командою, щоб, якщо чогось не вистачає, вони могли легко вказати на це.
• Якщо у вас і вашої команди не вистачає часу, переконайтеся, що помилки позначені у відповідному стані в електронному листі? Ви можете надіслати команді повний список помилок і змусити розробників відповідним чином позначити їх. Завжди тримайте м’яч на майданчику іншого.
• Якщо у вас є Рамка автоматизації готові, використовуйте це і уникайте робити Тестування вручну , таким чином за менший час ви можете покрити більше.
• Уникайте сценарію 'випустити за 1 годину', якщо ви не впевнені на 100%, що зможете здійснити доставку.
• І останнє, але не менш важливе, як уже згадувалося вище, складіть докладний електронний лист-випуск, в якому повідомляється про тестоване, що залишається осторонь, причини, ризики, які помилки усунені, що є «Запізнілими» тощо.

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

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

Тестування диму

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

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

У світлі цього, як система контролю якості забезпечить безперебійну роботу основних функціональних можливостей?

Відповіддю на це буде виконання а Тестування диму .

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

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

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

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

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

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

# 1) Прийомне тестування

Щоразу, коли збірка випускається на перевірку якості, проводиться тест на дим у формі Прийомне тестування слід зробити.

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

Візьмемо наступні приклади як реалізації, зроблені у збірці, щоб зрозуміти тести диму для них:

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

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

# 2) Тестування інтеграції

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

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

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

• Здійснено інтеграцію модулів маршруту та зупинки.
• Здійснено інтеграцію оновлення статусу прибуття та відображено те саме на екрані зупинок.
• Здійснено інтеграцію модулів функціональної доставки до моменту доставки.

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

# 3) Тестування системи

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

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

Зазвичай це робиться за допомогою засобів автоматизації.

Важливість у методології SCRUM

На сьогодні проекти майже не дотримуються методології Waterfall при реалізації проектів, переважно всі проекти відповідають Agile та СКРУМ лише. У порівнянні з традиційним методом водоспаду, тестування диму має високі поваги в SCRUM та Agile.

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

Ось деякі з них винос про важливість цього тестування в SCRUM:

• Після двотижневого спринту час перерви відводиться на QA, але іноді нарощування QA затримується.
• У спринтах найкраще для команди, щоб про проблеми повідомляли на ранній стадії.
• Кожна історія має набір критеріїв прийнятності, отже тестування перших 2-3 критеріїв прийнятності дорівнює тестуванню диму цієї функціональності. Клієнти відмовляються від доставки, якщо не відповідає одному критерію.
• Тільки уявіть, що станеться, якщо команда розробників доставить вам збірку за 2 дні, а для демонстрації залишиться лише 3 дні, і ви зіткнетеся з основним збоєм функціональності.
• В середньому, спринт має історії від 5-10, тому, коли дається збірка, важливо переконатися, що кожна історія реалізована, як очікувалося, перед тим, як приймати збірку в тестування.
• Коли вся система повинна бути випробувана та регресована, спринту присвячується діяльність. Через два тижні, можливо, трохи менше для тестування всієї системи, тому дуже важливо перевірити основні функціональні можливості перед початком регресії.

Тест на дим проти побудови випробувальних тестів

Тестування диму безпосередньо пов’язане з тестуванням на прийнятність будівельних конструкцій (BAT).

У BAT ми проводимо те саме тестування - щоб перевірити, чи не відбулася збірка і чи нормально працює система. Іноді трапляється так, що коли створюється збірка, з’являються деякі проблеми, а коли вона доставляється, збірка не працює для контролю якості.

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

Цикл тесту на дим

Наступна блок-схема пояснює цикл тестування диму.

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

Тестовий цикл

Хто повинен проводити тест на дим?

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

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

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

Отже, індивідуальні служби контролю якості проводять це тестування для історій, якими вони володіють.

Чому ми повинні автоматизувати тести на дим?

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

Найкращий спосіб зробити це тестування - скористатися інструментом автоматизації та запланувати запуск димового набору при створенні нової збірки. Можливо, ти думаєш, чому я повинен? “Автоматизувати пакет тестування диму”?

Давайте розглянемо наступний випадок:

Скажімо, до випуску у вас тиждень, і із загальної кількості 500 тестових випадків ваш набір для випробувань диму налічує 80–90. Якщо ви почнете виконувати всі ці 80–90 тестових випадків вручну, уявіть, скільки часу у вас піде? Думаю 4-5 днів (мінімум).

Але якщо ви використовуєте автоматизацію та створюєте сценарії для запуску всіх цих 80-90 тестових кейсів, то в ідеалі вони будуть запущені за 2-3 години, і ви отримаєте результати з собою миттєво. Чи це не заощадило ваш дорогоцінний час і не дало вам результатів щодо вбудовування набагато менше часу?

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

Для цього проекту у мене було 800 тестів, а 250 - дим. Застосовуючи селен, ми могли легко автоматизувати та отримати результати цих 250 тестів за 3-4 години. Це не тільки заощадило наш час, але і показало нам СКАРЕЙ про виставкові магазини.

Отже, якщо це неможливо автоматизувати, візьміть допомогу автоматизації для цього тестування.

Переваги та недоліки

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

Переваги:

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

Недоліки:

найкращий додаток для шпигунства на іншому телефоні

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

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

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

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

Різниця між тестом на дим і розум

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

Далі наведено схематичне зображення їх відмінностей:

ТЕСТУВАННЯ ДИМУ

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

ТЕСТУВАННЯ САНІТНОСТІ

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

Сподіваюся, вам ясно зрозумілі відмінності між цими двома важливими та важливими типами тестування програмного забезпечення. Не соромтеся ділитися своїми думками в розділі коментарів нижче !!

Рекомендована література

• Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
• Різниця між робочим столом, тестуванням клієнтського сервера та веб-тестуванням
• Функціональне тестування проти нефункціонального тестування
• Завантажити тестувальник електронної книги
• Альфа-тестування та бета-тестування (повний посібник)
• Посібник із тестування на портативність із практичними прикладами
• Типи тестування програмного забезпечення: різні типи тестування з деталями
• Функціональне тестування проти тестування продуктивності: чи слід це робити одночасно?