Димове тестування – це процес, який використовується для тестування програмного забезпечення, щоб визначити, чи є розгорнута збірка програмного забезпечення стабільною.
Коли ви тестуєте програмне забезпечення, ви запускаєте серію тестів, призначених для оцінки кожної з основних функцій програмного забезпечення.
Інструменти тестування диму перевіряють, чи працюють найважливіші функції програмного забезпечення. Існує багато різних підходів до тестування диму, а сучасні технології роблять автоматизоване тестування диму можливим для більшості програмних продуктів.
У цій статті ми глибоко зануримося в димове тестування, щоб розглянути типи, процеси та підходи до димового тестування, які використовують тестувальники програмного забезпечення. Ми також розглянемо сучасні інструменти тестування диму, включаючи автоматизацію тестування диму.
Коротше кажучи, ви дізнаєтеся все, що вам коли-небудь знадобиться про тестування на дим.
Що таке димове тестування в розробці програмного забезпечення?
Smoke-тестування – це процес тестування програмного забезпечення на відповідність основним вимогам функціональності та стабільності. По суті, це різновид мініатюрного швидкого регресійного тестування, який передбачає перевірку найважливіших функцій програмного забезпечення, щоб переконатися, що вони працюють на базовому рівні.
Димове тестування є важливим початковим етапом процесу контролю якості, оскільки воно показує, чи повинна команда продовжувати подальше тестування або негайно відправити продукт назад розробникам.
Якщо продукт не пройшов тест на дим, це означає, що початкова збірка має суттєві недоліки, які необхідно усунути до початку подальших випробувань.
Коли потрібно проводити тестування на дим?
Ми тестуємо програмне забезпечення щоразу, коли розробляємо нові функції та інтегруємо їх в існуючу збірку, а також перед тим, як нова збірка буде розгорнута для QA. Проведення димового тестування на цьому етапі запобігає витрачанню грошей та інших ресурсів на QA-тестування програмного забезпечення з серйозними базовими проблемами.
Для проведення QA димового тесту команда розробників розгортає нову збірку програмного забезпечення в QA, бере підмножину тестових кейсів і запускає їх на збірці. Команда QA тестує додаток на його найважливіші функціональні можливості. Якщо димовий тест пройдено, команда QA продовжить функціональне тестування, а якщо ні, то збірка повертається до команди розробників для подальшої розробки.
Таке тестування димом відбувається щоразу, коли до збірки програмного забезпечення додаються нові функції.
Можуть бути й інші випадки, коли команди QA будуть курити тестове програмне забезпечення, наприклад:
● Перед тим, як вносити новий код до репозиторію
Перед великою серією випробувань, включаючи регресійне та приймальне тестування
Після розгортання нової збірки програмного забезпечення
Якщо ви не проведете димовий тест на цих етапах, ви можете виявити серйозні дефекти на більш пізніх етапах тестування функціональності, що може вплинути на дату випуску нової збірки або призвести до більш серйозних порушень у вашому графіку.
Коли не потрібно проводити тестування на дим
Важливо проводити димове тестування при тестуванні програмного забезпечення щоразу, коли ви вносите будь-які зміни в програмний код або додаєте нові функції до збірки.
Це також важливий підготовчий крок до тестування функціональності, оскільки він не дає командам QA витрачати час на тестування ще не готового програмного забезпечення.
Якщо ваше програмне забезпечення не відповідає цим критеріям, можливо, вам не доведеться проводити тестування на дим на даний момент… хоча автоматизовані інструменти для тестування на дим дозволяють легко та економічно ефективно проводити регулярні тести на дим, щоб переконатися, що програмне забезпечення завжди функціонує належним чином.
Хто бере участь у тестуванні диму
Тестування диму проводиться інженерами QA або QA-лідером; це перший етап QA-тестування, який проводиться в середовищі QA.
Команда QA відповідає за тестування збірки програмного забезпечення та оцінку його продуктивності за різних умов і навантажень. Під час димового тесту інженери QA шукатимуть “шоустопери”, або помилки, які зупиняють розробку і повинні бути виправлені, перш ніж тестування продовжиться.
Порівнюючи тестування на дим з тестуванням на осудність та регресійним тестуванням, важливо враховувати не лише те, що тестується, але й те, хто проводить тестування.
Димове тестування в тестуванні програмного забезпечення завжди проводиться фахівцями з тестування якості. Це відрізняє тестування на дим від тестування на осудність, яке проводиться в середовищі розробки і зазвичай не передбачає залучення команди QA.
Життєвий цикл димового тесту
Життєвий цикл димового тесту ілюструє, де димовий тест відбувається під час розробки продукту та тестування якості. Розуміння кожного етапу цього циклу допоможе вам краще зрозуміти, як димове тестування вписується в процес тестування, а також відмінності між димовим тестуванням, тестуванням на адекватність та регресійним тестуванням.
1. Код
Першим етапом створення будь-якого програмного забезпечення завжди є написання та створення коду. Код слугує будівельним блоком будь-якого програмного забезпечення, і команда розробників повинна написати код, перш ніж його можна буде протестувати на стабільність і функціональність.
2. Юніт-тестування
Зазвичай модульне тестування виконується розробниками, хоча іноді QA-інженери також можуть виконувати деякі модульні тести. Модульне тестування гарантує, що різні модулі або елементи коду працюють так, як очікується, до того, як окремі модулі будуть інтегровані в єдину збірку програмного забезпечення.
Зазвичай модульне тестування відбувається паралельно з розробкою, оскільки воно виявляє помилки та баги в коді, які можна швидко виправити.
3. Інтеграційне тестування
Інтеграційне тестування – це процес перевірки того, як окремі модулі працюють разом, коли вони інтегровані в єдине програмне забезпечення.
Навіть якщо кожен окремий підрозділ функціонує добре, часто можуть виникати проблеми, коли ці підрозділи інтегровані один з одним. Інтеграційне тестування зазвичай проводять розробники, хоча різні підходи до цього виду тестування означають, що його можна проводити на різних етапах процесу створення програмного забезпечення.
4. Перевірка на осудність
Тестування на адекватність – це різновид регресійного тестування, і зазвичай це останній вид регресійного тестування. Це відбувається на етапі розробки збірки, після того, як всі помилки, виявлені регресійним тестуванням, були виправлені.
Тестування на адекватність зазвичай відбувається дуже швидко і просто існує для того, щоб переконатися, що програмне забезпечення працює безперебійно і що всі знайдені помилки були адекватно виправлені.
Тестування на дим і тестування на адекватність іноді плутають, але важливо пам’ятати, що тестування на адекватність відбувається в середовищі розробки, в той час як тестування на дим відбувається в середовищі контролю якості.
5. Випробування на дим
Тестування диму – це перший етап QA-тестування і перший тип тесту, який проводиться в середовищі QA.
Димове тестування зазвичай відбувається перед тестуванням на адекватність та регресійним тестуванням, незважаючи на те, що його зазвичай проводять QA-команди. Це швидкий і простий процес тестування – і сьогодні більшість QA-команд використовують автоматизоване димове тестування при тестуванні програмного забезпечення – який визначає, чи є збірка стабільною і чи потрібно запускати подальші тести.
Оскільки димове тестування є найшвидшим і найпростішим тестом у порівнянні з регресійним тестуванням, доцільно провести його першим, перш ніж переходити до інших, більш складних тестів.
6. Функціональне тестування
Функціональне тестування є наступним етапом життєвого циклу тестування програмного забезпечення, і воно проводиться в середовищі QA.
Функціональне тестування перевіряє кожну функцію програмного додатку на відповідність його вимогам і зосереджується на функціях, зручності використання, доступності та умовах помилок.
Функціональні випробування можна починати після того, як тест на дим пройдено.
Застосування для тестування диму на різних рівнях
Димові випробування застосовуються на трьох різних рівнях тестування: димові випробування на рівні приймання, димові випробування на рівні системи та димові випробування на рівні інтеграції.
1. Рівень приймального тестування
Димове тестування на рівні прийняття зазвичай проводиться, коли збірка програмного забезпечення передається до QA. Цей тип QA димового тесту просто перевіряє базову функціональність збірки і те, чи відповідає вона очікуваній функціональності.
2. Рівень тестування системи
Тестування диму на системному рівні передбачає тестування найважливіших робочих процесів системи. Це робиться після тестування самої системи і перед проведенням повного регресійного тестування системи.
На системному рівні найпоширенішою формою димового тестування є автоматизоване димове тестування.
3. Рівень тестування інтеграції
На рівні тестування інтеграції димові тести гарантують, що всі наскрізні функції програмного забезпечення працюють, як очікувалося, і що базова інтеграція є функціональною.
Цей тип тестування диму зазвичай відбувається, коли реалізуються окремі модулі або коли кілька модулів інтегровані в одну збірку програмного забезпечення.
Ручні та автоматизовані тести на дим
Коли команди розробників програмного забезпечення вперше починають проводити димові випробування, вони повинні прийняти рішення про те, чи будуть вони проводити ручні або автоматизовані димові випробування.
Хоча автоматизовані тести на дим зазвичай дають швидші та економічно ефективніші результати, їх створення та впровадження також може зайняти певний час. Багато команд починають зі створення ручних тестів на дим, перш ніж розглядати автоматизацію в подальшому.
1. Ручне тестування на дим
Ручні тести на дим досить прості в розробці і зазвичай можуть бути виконані нетехнічними фахівцями, які не входять до складу команд QA або розробників. Це означає, що ручні тести на дим часто надають перевагу в невеликих компаніях, які ще не мають спеціального керівника з контролю якості.
Під час ручного тестування димом важливо протестувати кілька варіантів використання, які охоплюють достатньо основних функцій програмного забезпечення, але не охоплюють так багато, що тестування димом займе занадто багато часу. Ідеальною кількістю сценаріїв використання зазвичай вважається від 20 до 50.
Переваги проведення тестів на дим вручну
Проведення ручних тестів на дим в процесі контролю якості має багато переваг порівняно з автоматизованими тестами на дим. Ручні тести на дим часто дають більш детальну інформацію про продуктивність і функціональність програмного забезпечення порівняно з автоматизованими тестами.
Неінженери можуть виконувати ручне тестування
У той час як автоматизоване тестування диму зазвичай вимагає досвіду інженерів-програмістів і розробників, ручне тестування диму можуть проводити члени команди з меншим досвідом.
Зазвичай це вигідно в невеликих командах, де ресурси вже можуть бути розтягнутими, а час спеціалістів надзвичайно цінний.
Ви можете створити власний тест на дим для кожного завдання
Якщо ви хочете переконатися, що ваш димовий тест точно охоплює найважливіші функції будь-якого програмного додатка і фокусується на тих функціях, які є більш важливими для кожної збірки, створення ручного димового тесту дозволяє тестувальникам адаптувати тест до кожного проекту.
Такі ручні тести на дим можуть дати більш корисні результати порівняно з деякими автоматизованими тестами, але це означає, що їх налаштування та проведення забирає багато часу.
Ручні тести виявляють якісні дані
Коли ви проводите автоматизований тест на дим, все, на що ви можете розраховувати, – це кількісні дані про те, які аспекти тесту пройшли, а які – ні.
Коли члени команди проводять ручне тестування диму, вони можуть використовувати своє розуміння, інтуїцію та судження, щоб оцінити не тільки те, чи пройшла збірка, але й те, як та/або чому вона не пройшла.
Проблеми ручного тестування на дим
Проведення тестування диму вручну також пов’язане з багатьма труднощами, і саме тому багато компаній вирішують використовувати автоматизоване тестування диму, де це можливо.
Ручне тестування диму є ретельним, але також дуже трудомістким.
Ручні тести на дим займають багато часу
Ручні тести на дим займають значно більше часу, ніж автоматизовані, і вимагають набагато більше уваги від вашої команди.
У той час як автоматизовані тести можуть просто запускатися у фоновому режимі, вашій команді потрібно буде виділити спеціальний час для проведення ручного тесту на дим.
Ручні тести не можна запускати занадто часто
Через величезну кількість часу і ресурсів, які вимагають ручні тести на дим, вони не можуть проводитися так само регулярно, як автоматизовані тести на дим.
Для проведення ручного тесту на дим тестувальники програмного забезпечення повинні виділити кілька годин, до півдня, залежно від складності тесту.
Це усуває можливість щоденного тестування на дим, яке вважається найкращою галузевою практикою.
Завжди є місце для помилок
Оскільки люди проводять тестування вручну, завжди існує ймовірність того, що під час ручного тестування на дим можуть бути допущені помилки.
З цієї причини ручне тестування диму зазвичай не є настільки повним, як автоматизоване тестування, особливо коли йдеться про виявлення тонких помилок, які легше пропустити, або коли проводиться надзвичайно повторюване тестування, що може призвести до втрати уваги тестувальників під час тестування.
Коли використовувати ручне тестування на дим
Ручне димове тестування найчастіше використовується в невеликих командах, які не мають ресурсів, щоб виділити інженерів для автоматизованого димового тестування, або у випадках, коли потрібне додаткове людське розуміння і судження.
З цієї причини ручне тестування диму часто реалізується в димових випробуваннях на інтеграційному рівні.
2. Автоматизоване тестування диму
Автоматизоване тестування на дим може бути реалізоване інженерами-програмістами з навичками кодування, необхідними для створення та запуску серії відповідних сценаріїв використання для кожної збірки програмного забезпечення.
Автоматизоване тестування диму відбувається набагато швидше, ніж ручне, зазвичай займає не більше 30-60 хвилин, і його можна проводити у фоновому режимі, поки всі члени команди розробників і QA продовжують виконувати свої повсякденні завдання.
З цієї причини автоматизоване тестування на дим стало звичним явищем в індустрії програмного забезпечення, оскільки все більше фірм прагнуть підвищити ефективність робочих місць.
Переваги автоматизації димових випробувань
Автоматизація димових випробувань пропонує багато переваг для тих компаній, які мають час і ресурси для її впровадження. Це швидко і ефективно, а оскільки автоматизовані тести не створюють навантаження на команди і ресурси, їх можна проводити регулярно навіть у невеликих компаніях.
Автоматизоване тестування – це швидко
Автоматизоване тестування диму відбувається набагато швидше, ніж ручне тестування, причому більшість автоматизованих тестів займає не більше 30-60 хвилин.
Для порівняння, ручне тестування може тривати годинами.
Автоматизовані тести на дим вимагають мінімальних ресурсів і після впровадження дуже прості у використанні.
Автоматизація робить можливим щоденне тестування на дим
Сучасні найкращі галузеві практики диктують, що щоденні тести на дим є ідеальним рішенням, особливо при роботі з програмним забезпеченням, яке постійно перебуває в стані потоку.
Ручні тести на дим занадто трудомісткі, щоб проводити їх щодня, але автоматизовані тести на дим легко проводити на початку кожного робочого дня.
Автоматизація виключає людські помилки
Автоматизовані тести запускаються зі скриптів, які готуються заздалегідь і створюються відповідно до високих стандартів. Це означає, що ймовірність того, що автоматизований тест пропустить велику помилку або важливу проблему, дуже низька.
Автоматизація може імітувати тести навантаження та продуктивності
Тести навантаження та продуктивності оцінюють, наскільки добре додаток працює, коли ним користується багато користувачів одночасно. Автоматизоване димове тестування може імітувати додаткове навантаження від кількох користувачів так, як це неможливо при ручному тестуванні, і надає додатковий рівень даних про продуктивність програмного забезпечення в певних умовах.
Проблеми автоматизації димових випробувань
Автоматизація димових випробувань не позбавлена складнощів. Впровадження автоматизованого тестування на дим може бути більш трудомістким та ресурсоємним, особливо в невеликих командах з меншою кількістю інженерів у розпорядженні.
Технічні вимоги
Автоматизовані тести на дим вимагають більше технічних знань і навичок у кодуванні, ніж ручні тести на дим. Інженери-програмісти повинні мати час і знання, щоб знати, як створювати автоматизовані тести, перш ніж їх можна буде впроваджувати, і не всі команди обов’язково матимуть для цього ресурси.
Брак людського розуміння
Автоматизоване тестування дає загальне уявлення про функціональність програмного забезпечення, а при проведенні автоматизованого димового тесту тестувальники програмного забезпечення отримують уявлення про основні функції програмного забезпечення, що є кінцевою метою димового тесту.
Однак автоматизовані тести не дають жодного уявлення про більш предметні аспекти продуктивності програмного забезпечення, такі як юзабіліті та доступність.
Коли впроваджувати автоматизацію димових випробувань
Автоматизація часто використовується в димовому тестуванні, оскільки метою димового тестування є просто перевірка базової функціональності, з чим автоматизоване тестування справляється відносно добре.
Команди з достатніми технічними навичками для впровадження автоматизованого тестування диму, швидше за все, матимуть час і ресурси, щоб інвестувати в цей процес, а більші, більш усталені компанії, швидше за все, відчуватимуть більший тиск, щоб відповідати найкращим стандартам щоденного тестування диму.
Автоматизація димових випробувань проти ручного тестування на дим
Не існує правильного чи неправильного способу проведення тестування на дим, і те, що добре працює для однієї команди, може не спрацювати для іншої.
Перш ніж проводити димовий тест, командам розробників слід проаналізувати свої цілі, ресурси та довгострокові плани проекту. Процес ручного тестування програмного забезпечення може бути навчальним для молодих спеціалістів, які тільки починають працювати в сфері контролю якості, але для більш досвідчених команд рідко є перевага у виборі ручного тестування над автоматизованим.
Випробування гібридного диму
Третій варіант для команд, які не можуть обрати між ручним та автоматизованим тестуванням на дим і перевіркою на осудність, – обрати гібридне тестування.
Гібридне тестування поєднує в собі аспекти як ручного, так і автоматизованого димового тестування для підвищення загальної продуктивності та ефективності випробувань. При використанні гібридного методу випробування на дим більша частина випробування може бути автоматизована, але певні аспекти виконуються вручну. Це дозволяє командам зосередити більше уваги на тих аспектах збірки, які цього потребують, зберігаючи при цьому загальну тривалість димового тесту на низькому рівні.
Типи тестування на дим
Тестування на дим можна умовно розділити на дві категорії: формальне та неформальне тестування на дим. Чи є тестування диму формальним або неформальним, залежить від того, чи ініціюється воно керівником QA офіційно, чи просто проводиться як частина розробки.
1. Формальні випробування на дим
Під час формального димового тесту розробники програмного забезпечення передають зібране програмне забезпечення QA-інженеру або QA-лідеру для формального тестування. Керівник QA призначає тестувальників для виконання завдання з тестування диму і просить їх виконати тест на дим, використовуючи інструменти для тестування диму, такі як автоматизація або вручну.
Під час проведення формальних випробувань на дим тестувальники QA збирають результати тесту в офіційний звіт, який може бути проаналізований керівником QA.
Формальне димове тестування проводиться у важливі моменти процесу створення програмного забезпечення, наприклад, перед виконанням функціонального тестування нових функцій.
2. Неформальні тести на тютюновий дим
Неформальні димові тести – це димові тести, що виконуються на збірці програмного забезпечення під час розробки або процесу контролю якості, про які формально не звітують і не вимагають від керівника QA.
Щоденні тести на дим, які багато команд розробників програмного забезпечення проводять за протоколом, є прикладом неформальних тестів на дим.
Неформальні тести можуть проводитися від випадку до випадку, коли QA-інженери вважають, що вони можуть бути корисними.
Що потрібно для початку тестування на дим
Перш ніж розпочати тестування димом у тестуванні програмного забезпечення, важливо зібрати всі необхідні речі, включаючи файли даних і навички у вашій організації.
Те, що вам знадобиться для проведення тесту на дим, залежить від того, чи плануєте ви проводити автоматизований або ручний тест на дим, а також від того, які інструменти тестування ви використовуєте, щоб полегшити процес.
1. Список тестових кейсів
Перш ніж розпочати тест на дим, вам знадобиться вичерпний перелік усіх тестових кейсів, які ви хочете оцінити за допомогою тесту на дим.
Тестові кейси – це окремі набори дій, які ви хочете протестувати, щоб оцінити, чи відповідає результат виконання цих дій тим результатам, які ви очікуєте.
Наприклад, дуже простий тестовий випадок може полягати в тому, що програма завантажує головну інформаційну панель, коли ви відкриваєте програму.
2. Тестові файли
Перш ніж запустити тест на дим, вам потрібно зібрати всі тестові файли, на яких ви збираєтеся проводити тест на дим. Ви можете скористатися командним рядком програмного забезпечення для тестування диму, яке ви використовуєте, щоб зібрати всі ваші файли в одному місці.
Те, як ви збираєте файли і де ви їх зберігаєте, залежить від того, як працює ваша організація.
3. Інструменти для тестування диму
Ви можете виконати базовий тест на дим без використання будь-яких спеціальних інструментів, але використання інструментів для тестування на дим може допомогти вам підвищити точність результатів і прискорити процес тестування на дим.
Спочатку вивчіть інструменти для тестування диму в Інтернеті і виберіть програмне забезпечення, яке автоматизує або оптимізує ваш тест на дим відповідно до ваших конкретних потреб і бюджету.
Процес тестування диму
Найкращий спосіб проведення тестування на дим залежить від організації, і якщо ви новачок у цьому питанні, можливо, вам варто поекспериментувати з різними підходами, щоб зрозуміти, що найкраще підходить для вашої команди.
Нижче наведено приклад проведення базового тесту на дим для оцінки основних функцій вашого програмного забезпечення.
Крок 1: Виберіть тестові кейси
Першим кроком до проведення тесту на задимленість є вибір тестових кейсів, на яких ви збираєтеся проводити тест на задимленість.
Розробляючи тест на дим, інженери-програмісти та інженери з контролю якості повинні враховувати, які функції програмного забезпечення є найбільш важливими для програмного забезпечення і як найкраще протестувати ці функції. Не витрачайте час на тестування функцій, які не є важливими для роботи програми.
Крок 2: Створіть тести на дим
Після того, як ви визначили тестові кейси, які збираєтеся використовувати, ви можете написати тестові скрипти для їх перевірки. Використовуйте єдиний скрипт для тестів на дим, щоб підвищити гнучкість під час проведення тесту.
Якщо ви вирішите автоматизувати тестування на дим, вам не доведеться писати ручні тестові скрипти щоразу, коли ви захочете запустити тест на дим. Ви можете використовувати пакети для автоматизації тестування програмного забезпечення для автоматизації подібних скриптів.
Крок 3: Проведіть тести на дим
Після того, як ви створили скрипти для димового тестування, ви можете запустити їх на вашій збірці, щоб знайти баги та інші серйозні помилки. Це не повинно зайняти більше 30-60 хвилин, і після завершення тестування ви зможете оцінити результати, щоб визначити свої подальші кроки.
Крок 4: Виправте помилки
Мета димового тестування при розробці програмного забезпечення – виявити будь-які серйозні помилки або шоу-стопери до того, як почнеться повноцінне QA-тестування.
Якщо ваші димові тести виявили будь-які значні проблеми, які порушують основні функції вашої збірки програмного забезпечення, важливо відправити програмне забезпечення і ваш аналіз назад команді розробників для виправлення помилок, перш ніж продовжувати QA.
Найкращі практики для тестування на дим
Димове тестування – це надійний спосіб виявлення основних помилок у збірках програмного забезпечення на всіх етапах розробки. Дотримання найкращих галузевих практик – найкращий спосіб забезпечити ефективність, точність і продуктивність ваших тестів на дим.
1. Часто проводьте тести на дим
Не завжди є можливість проводити тести на дим щодня, особливо якщо ви проводите ручні тести, а не автоматизовані тести на дим.
Проводьте тести на дим якомога частіше, а також щоразу, коли вносите зміни до вашого програмного забезпечення. Як тільки ви зможете, найкращою практикою вважається проведення щоденних тестів на дим.
2. Ніколи не пропускайте етапи тестування
Якщо ви поспішаєте, може виникнути спокуса пропустити деякі етапи тестування, щоб швидше просунутися в процесі розробки, але і димове, і регресійне тестування необхідні для того, щоб ваша розробка йшла за планом.
Завжди тестуйте свої збірки на дим і здоровий глузд, перш ніж переходити до наступного етапу.
3. Тестуйте кожну зміну
Не існує єдиного застосування для тестування на дим. Ви можете і повинні використовувати димові тести для перевірки кожної зміни, яку ви вносите до збірки програмного забезпечення, а також для тестування вашого програмного забезпечення між різними етапами розробки.
Димові тести повинні передувати інтеграційному тестуванню, тестуванню продуктивності та функціональному тестуванню.
4. Відстежуйте результати тестування
Перевірка результатів формальних випробувань на дим є стандартною практикою, але навіть при проведенні неформальних випробувань на дим інженери повинні вести певний облік результатів.
Це полегшує передачу результатів розробникам і дозволяє відстежувати, які функції не пройшли тест.
5. Проведіть тест на дим двічі
Запуск тесту на дим двічі може здатися надмірністю, але якщо ви дійсно хочете виявити всі помилки під час тесту, краще запустити його двічі.
Це гарантує, що ваш тест на дим має всі шанси виявити основні помилки та проблеми, які можуть спричинити подальші проблеми, якщо їх не виправити негайно.
6. Виберіть правильний тип димового тесту
Вибір ручного або автоматизованого тестування на дим залежить від розміру та потреб вашої команди. Переконайтеся, що ви вибрали найкращий тип тестування для вашого проекту, щоб оптимізувати ефективність без шкоди для точності результатів.
Типи результатів тесту на дим
Коли ви проводите тест на дим, ви можете очікувати, що ваш тест на дим призведе до одного з двох різних результатів для кожного тестового випадку, який ви оцінюєте: пройшов або не пройшов.
1. Перепустка
Один з можливих результатів для кожного тестового випадку, який ви запускаєте, – це проходження тесту на дим. Це означає, що фактичний результат тесту збігається з очікуваним результатом тесту.
Наприклад, якщо ви запускаєте тест на те, що відбувається при завантаженні програми, і вона завантажується на екран, який повинен відкриватися при завантаженні, ваш скрипт повинен відображати це як пропуск.
2. Провал.
Якщо ваш тест на дим не спрацював для певного тестового випадку, це зазвичай означає, що фактичний результат тесту не збігається з очікуваним результатом тесту.
Наприклад, якщо ви тестуєте додаток для здійснення покупок і один з тестових кейсів перевіряє функціональність додавання товарів до кошика, тест не пройдено, якщо товари, які ви додаєте до кошика, не з’являються в ньому так, як ви очікуєте.
Приклади тестових кейсів для тестування диму
Коли ви намагаєтеся придумати, які тестові кейси включити в димовий тест, напишіть список основних функцій вашого програмного забезпечення і подумайте, які з них є важливими для запуску і використання програмного забезпечення.
Деякі приклади тестових кейсів для тестування на дим можуть допомогти вам визначити, які тестові кейси використовувати у вашому власному тесті на дим.
1. Перевірка облікових даних для входу
Якщо ваш додаток вимагає, щоб користувачі входили в систему, ви можете створити тестовий кейс, який перевіряє, чи працює процес перевірки облікових даних належним чином.
Для цього створіть скрипт, який автоматизує дії входу в систему, запуску тесту та перевірки результатів. Якщо програма увійде до системи, як очікувалося, цей тест з димом пройдено.
2. Створення нового документа
Ви можете створити тестовий кейс, щоб оцінити, чи дозволяє ваше програмне забезпечення користувачам створювати новий документ належним чином. Створіть скрипт, який автоматизує створення, іменування та збереження документів у вашому програмному забезпеченні, і запустіть його.
Будь-які серйозні проблеми, що виникають і перешкоджають цьому процесу, означатимуть, що тест на дим не пройшов.
3. Вихід з системи
Якщо ваш додаток має функцію входу в систему, він також повинен мати функцію виходу з системи. Запустіть скрипт, щоб перевірити, що відбувається, коли користувачі натискають кнопку “вийти”.
Якщо користувач не може успішно вийти з системи після натискання цієї кнопки, тест на дим не пройдено.
Типи помилок і багів, виявлених під час димового тестування
Димові тести можуть допомогти вам виявити помилки та баги, які порушують основну функціональність вашого програмного забезпечення. Залежно від того, коли ви запускаєте димовий тест і що ви хочете перевірити, ви можете знайти різні типи помилок і багів за допомогою димового тестування.
1. Функціональні помилки
Функціональні помилки – це помилки, які виникають, коли ваше програмне забезпечення поводиться не так, як ви очікуєте, або коли воно не працює належним чином.
Більшість тестових кейсів, які ви будете перевіряти за допомогою димових тестів, є функціональними тестами, тому функціональні помилки, швидше за все, будуть виявлені за допомогою таких тестів.
2. Логічні помилки
Логічні помилки являють собою недоліки в логіці коду і також можуть спричинити неправильну поведінку програмного забезпечення. Логічні помилки можуть призвести до неправильних результатів або навіть до збоїв у роботі програми.
Поширеною логічною помилкою є нескінченний цикл, який змушує програму повторювати одні й ті ж дії знову і знову, поки вона не вийде з ладу.
3. Помилки інтеграції
Якщо ви запускаєте димовий тест на рівні інтеграції, ви можете виявити помилки інтеграції під час тесту. Вони виникають, коли два окремих набори коду не бездоганно інтегруються один з одним. Вони можуть бути викликані широким спектром проблем сумісності в коді і можуть вимагати складних рішень для усунення.
Загальні показники тестування на дим
Під час проведення тесту на задимленість команди QA можуть використовувати метрики для оцінки результатів тесту на задимленість і судження про те, чи пройшов тест, чи ні.
Окрім того, що показники димового тесту визначають, чи здатне програмне забезпечення належним чином виконувати свої основні функції, вони також можуть оцінювати швидкість і час завантаження програмного забезпечення.
1. Швидкість роботи програмного забезпечення
Димові тести можна використовувати для перевірки відповідності швидкості та часу завантаження програмного забезпечення певним критеріям, визначеним в окремих тестових кейсах.
Наприклад, якщо ви тестуєте поведінку програмного забезпечення під час завантаження програми, і програма завантажується, як очікувалося, але займає дві хвилини, ви можете позначити це як “Не вдалося”, оскільки вона не відповідає очікуваному часу завантаження.
2. Надійність
Запуск тесту на дим двічі також може допомогти вам перевірити надійність вашого програмного забезпечення. Якщо певні тестові кейси проходять один раз і один раз не проходять, це означає, що якась помилка в коді спричиняє помилки, які можуть не виникати кожного разу при використанні програми, але все одно можуть спричинити серйозні проблеми для користувачів.
Найкращі безкоштовні інструменти для тестування диму
Інструменти для тестування диму можуть допомогти вам проводити тести на дим більш ефективно і швидко, щоб ви могли отримати максимальну віддачу від ваших тестів на дим.
Нижче наведені деякі з найкращих інструментів для тестування диму, які сьогодні доступні безкоштовно.
5 найкращих безкоштовних інструментів для тестування на дим
1. ZAPTEST безкоштовна версія
ZAPTEST – це безкоштовний інструмент, який дозволяє користувачам автоматизувати тестування програмного забезпечення та RPA, не сплачуючи жодної копійки.
Ви можете використовувати версію ZAPTEST FREE для проведення простих тестів на дим на різних платформах, включаючи мобільні, веб-платформи, API і платформи LOAD.
Якщо ви хочете спробувати автоматизоване тестування диму, безкоштовна версія ZAPTEST допоможе вам переконатися в перевагах автоматизації з перших рук. Він також простий у використанні, навіть якщо ви не маєте технічної освіти, оскільки має безкодовий інтерфейс і використовує найсучаснішу технологію комп’ютерного зору.
Найголовніше, що ZAPTEST FREE добре…. вільні назавжди! На противагу цьому, багато інструментів для тестування диму та загальної автоматизації програмного забезпечення мають початковий тестовий період, після якого ви будете змушені платити за підписку.
2. Селен
Selenium – це безкоштовний інструмент з відкритим вихідним кодом, за допомогою якого ви можете запускати різні види тестів для вашого програмного забезпечення, включаючи димове та регресійне тестування. Він працює з багатьма мовами програмування і особливо добре підходить для тестування веб-додатків.
3. Аппій.
Якщо ви хочете проводити тестування мобільних додатків на задимленість та осудність, Appium є кращим вибором, ніж Selenium. Appium простий у встановленні та використанні і може використовуватися для проведення простих тестів на дим для додатків, розроблених як для iOS, так і для Android.
4. Тестове посилання
Testlink – це безкоштовний веб-інструмент управління, який дозволяє користувачам створювати плани тестування та тестові кейси в єдиній структурованій системі. Testlink може допомогти вам спланувати тестування диму, а також окреслити ваші очікування та метрики перед початком тестування.
5. Вовк з контролю якості
QA Wolf – це безкоштовний наскрізний інструмент тестування, який дозволяє користувачам створювати автоматизований QA димовий тест разом з іншими функціональними тестами. QA Wolf може використовуватися навіть людьми без технічних навичок або навичок програмування, що означає, що це чудовий вступ до автоматизації тестування для більшості QA-команд.
Найкращі інструменти для тестування диму на підприємстві
Якщо ви готові вкласти трохи грошей у свої інструменти для тестування диму, ви можете придбати корпоративні інструменти, які мають більш широкі можливості для тестування диму і дають більш ретельні результати.
Нижче наведено список з п’яти найкращих інструментів для автоматизації тестування диму на підприємстві на ринку.
5 найкращих інструментів для автоматизації тестування диму на підприємстві
1. Видання ZAPTEST ENTERPRISE
ZAPTEST ENTERPRISE – це пакет для тестування програмного забезпечення та RPA, який може повністю автоматизувати будь-який тип тестування, включаючи тестування на дим.
Безкоштовна версія підходить для невеликих компаній, які хочуть дізнатися, що може зробити ZAPTEST, але якщо ви шукаєте платне рішення, яке є простим у використанні і підходить для тестування будь-якого програмного забезпечення або програми, на будь-якій платформі, браузері або пристрої, І з реалізацією 1SCRIPT на всіх цих платформах, тоді ZAPTEST ENTERPRISE – це відмінне місце для початку.
2. SoapUI
SoapUI – це інструмент для корпоративного тестування, який дозволяє легко керувати та виконувати наскрізні QA-тести програмного забезпечення. Це відносно простий в установці інструмент, але він має свої обмеження, що відображається на його ціні.
3. Свідчення
Testim – це платний інструмент для тестування диму, який використовує ШІ для створення безкодових тестів, що оцінюють функціональність вашого програмного забезпечення. Javascript API Testim можна використовувати для рефакторингу, кастомізації та налагодження тестів.
4. Робот Т-план
T-Plan Robot – це корпоративний інструмент тестування, який QA-інженери можуть використовувати для автоматизації скриптових дій користувачів і роботизованої автоматизації процесів (RPA) на Windows, Mac, Linux і мобільних пристроях. Ви можете використовувати T-Plan Robot для автоматизації тестів на дим для цілого ряду додатків і створювати автоматизовані сценарії, які можна запускати в ключові моменти розробки.
5. Контроль якості в тропічних лісах
Rainforest QA – це інструмент QA для тестування диму, який дозволяє користувачам керувати і проводити як ручне, так і автоматизоване тестування диму з єдиної інформаційної панелі. Це робить його ідеальним для організацій, зацікавлених у застосуванні гібридного підходу, і він підходить для величезного спектру платформ, включаючи хмарні додатки, Windows і Mac.
Коли слід використовувати інструменти для тестування корпоративного та вільного куріння?
Корпоративні та безкоштовні інструменти для тестування диму можуть задовольнити подібні потреби дещо по-різному. Зазвичай, безкоштовні інструменти слугують чудовим шлюзом для організацій, яким комфортно працювати з ручним тестуванням диму, але які хочуть більш детально вивчити автоматизоване тестування диму.
Вони також можуть бути більш придатними для невеликих стартапів, у яких ще немає грошей на платні інструменти.
Інструменти корпоративного тестування зазвичай стають більш життєздатним варіантом у міру розширення компаній. Вони мають низку переваг над безкоштовними інструментами, зазвичай пропонуючи більшу гнучкість, кращу підтримку та зручніші інтерфейси, що дозволяє навіть нетехнічним фахівцям легко проводити автоматизоване тестування на дим.
Контрольний список для тестування на дим
Перед початком тестування на дим команда QA може скористатися цим контрольним списком, щоб переконатися, що вона охоплює всі етапи процесу тестування на дим.
Визначте інструменти для тестування диму, які ви збираєтеся використовувати
Виберіть, чи будете ви створювати ручний або автоматизований тест
Виберіть тестові кейси, які ви хочете протестувати
Створіть тестові скрипти для кожного випадку
Визначте вимоги до проходження для кожного тестового кейсу
Проведіть тести на дим
Проаналізуйте результати
Зворотний зв’язок з розробниками та QA
Висновок
Димове тестування є важливим етапом у розробці програмного забезпечення та забезпеченні якості. Це гарантує, що продукт буде функціональним до того, як відбудеться подальше тестування, що запобігає ризику того, що команди QA витрачатимуть час і ресурси на інтенсивне функціональне тестування збірки, яка ще не є стабільною.
Тестування диму – це відносно швидкий і простий процес, який слід проводити командам розробників програмного забезпечення якомога частіше.
Оскільки підприємства прагнуть досягти оптимальної ефективності завдяки використанню передових інструментів, які підтримують гіперавтоматизацію, RPA та інші суміжні технології, автоматизоване тестування диму стає все більш поширеним в організаціях усіх розмірів.
Як ручне, так і автоматизоване тестування диму все ще має місце в сучасних середовищах контролю якості, але оскільки автоматизоване тестування стає все більш поширеним, немає сумнівів, що воно стане нормою.
Поширені запитання та ресурси
Які найкращі курси з автоматизації димових випробувань?
Якщо ви хочете дізнатися більше про автоматизацію тестування диму, ось кілька прикладів онлайн-курсів, які ви можете пройти:
● Курси з тестування на дим на Coursera
● Курси з тестування диму Udemy
● Курси з тестування на дим від Skillshare
Один з найкращих курсів для початківців – Certified Tester ISTQB Foundation Level (CTFL), доступний на Udemy.
Кожен з цих онлайн-ресурсів пропонує курси з тестування на дим для учнів з різними здібностями, причому на цих сайтах можна пройти як безкоштовні, так і платні курси.
Якщо ви хочете отримати сертифікат, шукайте курси, акредитовані CAST.
Які найкращі книги про тестування на дим?
Якщо ви хочете дізнатися більше про димне тестування, ви можете прочитати книги про тестування програмного забезпечення та димне тестування, щоб розвинути своє розуміння підходів і переваг димного тестування. Деякі з найкращих книг про тестування на дим включають:
Мистецтво тестування програмного забезпечення, Гленфорд Дж. Майерс, Том Баджетт та Корі Сендлер
Тестування програмного забезпечення, Рон Паттон
Автоматизація тестування програмного забезпечення, Марк Фьюстер та Дороті Грем
Однак, існує безліч фантастичних книг про тестування програмного забезпечення, які допоможуть вам зрозуміти більше про те, як, чому і що таке тестування.
Виберіть книгу, яка вам до душі і більш детально досліджує теми, які вас найбільше цікавлять.
Які 5 найкращих запитань на співбесіді при тестуванні на дим?
Якщо ви плануєте проходити співбесіду на посаду, яка може передбачати тестування на дим, підготуйтеся до співбесіди, підготувавши відповіді на поширені запитання, наприклад, на такі:
Коли правильно проводити тестування на дим?
Як би ви вирішили, які тестові кейси використовувати в димовому тесті?
Чим тестування на дим відрізняється від інших видів тестування, наприклад, тестування на осудність?
Скільки знань з кодування необхідно для проведення тестів на дим?
Що ви будете робити, якщо тест на дим не пройде?
Які найкращі навчальні посібники з тестування диму є на YouTube?
Якщо ви візуал, ви можете скористатися цими відео на YouTube, щоб дізнатися більше про тестування на дим:
Посібник з тестування диму Edureka
Що таке тестування на дим?
Тестування на дим проти тестування на осудність
Як підтримувати тести на дим?
Супровід димових тестів – це гарантія того, що створені вами димові тести залишатимуться здоровими та актуальними в процесі реалізації вашого проекту зі створення програмного забезпечення.
Виконуйте щоденні тести на дим і створюйте нові тестові кейси в міру необхідності.
Ви також можете максимізувати користь від ваших тестів диму, тісно співпрацюючи з тими розробниками, чиї внески не покращують якість їх коду.
Що таке димове тестування в розробці програмного забезпечення?
Димове тестування в інженерії програмного забезпечення також називають тестуванням верифікації збірки, і це простий і швидкий тест, який дозволяє переконатися, що збірка програмного забезпечення є стабільною.
Димове тестування використовується для перевірки основних функціональних можливостей збірки і слугує попереднім тестом перед подальшим QA-тестуванням.
Тестування на дим проти тестування на осудність
Тестування на дим і адекватність – це обидва типи тестування, які передбачають швидке тестування основних функціональних можливостей програмної збірки або продукту.
Однак, в той час як димове тестування перевіряє, чи працюють основні функції програмного забезпечення так, як очікувалося, тестування адекватності зазвичай використовується для перевірки того, чи виправлення помилок виправило виявлені проблеми.
Тестування диму є більш формальним і задокументованим процесом, який зазвичай виконується до того, як збірка буде визнана стабільною, в той час як тестування адекватності є неформальним типом тесту, який може бути виконаний як частина регресійного тестування на відносно стабільних збірках.
Димове тестування vs регресійне тестування
Димове та регресійне тестування – це типи тестування, які перевіряють, чи продовжує програмне забезпечення працювати належним чином після внесення нових змін.
Однак, димове тестування – це відносно швидкий і неглибокий тип тестування, який просто перевіряє основні функції і гарантує стабільність роботи програмного забезпечення.
Регресійне тестування – це більш глибокий тест, який займає набагато більше часу і оцінює збірку більш детально.
Тестування на дим проти тестування на адекватність проти регресійного тестування
Коли ви порівнюєте тестування на дим і осудність з регресійним тестуванням, важливо розуміти, що всі три типи тестів необхідні для якісної розробки та контролю якості програмного забезпечення.
Димове тестування і тестування на адекватність пропонують швидкий спосіб перевірити, чи нормально функціонує програмне забезпечення, в той час як регресійне тестування дає більш глибоке розуміння роботи продукту.
Команди QA спочатку викурюють тестове програмне забезпечення, а потім, якщо програмне забезпечення проходить цю перевірку, може відбутися тестування на адекватність, а пізніше регресійне тестування.
Автоматизоване тестування диму за допомогою інструментів для тестування диму стає все більш поширеним, але деякі види тестування, такі як регресійне тестування, поки що неможливо повністю автоматизувати через складну природу тесту.
Нарешті, якщо ви шукаєте інструменти для тестування на платформах Windows, iOS, Android, UI тестів, Linux і багатьох інших, завантажте ZAPTEST БЕЗКОШТОВНО!
