Димовий тест. Покриваємо проект smoke-тестами, доки він не згорів

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

Димове тестування:

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

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

Санітарне тестування:

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

Приклад для кращого розуміння різниці між димовим та санітарним тестуванням:

Існує проект, для якого заплановано початковий реліз. Команда розробників випускає білд на тестування, команда тестувальників розпочинає роботу. Найперше тестування - це тестування на придатність. Потрібно з'ясувати, чи можна працювати з цією версією чи ні. Це і є димове тестування. Якщо команда дає добро на подальшу роботу з білдом, він вирушає на глибші стадії тестування. Уявимо, що білд має три модулі: “Логін”, “Адмін” та “Співробітник”. Команда тестувальників перевіряє працездатність виключно основних функцій кожного з модулів, не заглиблюючись у перевірку деталей. Це буде санітарне тестування.

Ще кілька відмінностей між димовим та санітарним тестуванням:

• Димове тестування проводиться і розробниками та тестувальниками;
• Санітарне тестування проводиться лише тестувальниками.

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

• Димове тестування відбувається як стабільний, так і не стабільний білд;
• Санітарне тестування відбувається відносно стабільна версія складання.

Кирило Флягін, геймдизайнер, QA Lead

Проведемо літню аналогію із цими видами тестування. Допустимо, ви хочете купити кавун. Димове тестування - це коли ви перевіряєте його візуально, дивіться на смужки, стискаєте, стукаєте, оцінюєте. Є майстри, які примудряються так купити справді смачну ягоду. У санітарному тестуванні ви вирізуєте пірамідку у верхній частині та перевіряєте її колір (як один із компонентів), при цьому зовсім не знаєте, чи такий кавун весь. Але за вирізану частину ви цілком упевнені.

What is Smoke Testing?

Smoke testing is defined as type of software testing що determines whether deployed build is stable or not. Це служить як confirmation whether the QA team може здійснюватися з further testing. Smoke tests є minimal set of tests run on each build. Here is the cycle where smoke testing is involved

Smoke testing is a process where the software build is deployed to QA environment and is verified to ensure the stability of the application. Це також називається "Build verification Testing" або “Confidence Testing.”

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

Це є міні-і швидкий регресивний test of major functionality. Це є простий тест, що показує, що продукт ready for testing. Ця процедура визначається, якщо будова flawed as to make any further testing a waste of time and resources.

Смокі тести qualify build for further formal testing. Головне керування губами випробування є виявленим раніше major issues. Структурні випробування є розроблені для демонстраційної системи stability і conformance to requirements.

Будівлі включають всі файли файлів, libraries, reusable modules, engineered components, які вимагаються до implement one or more product functions.

In this tutorial, you will learn-

When do we do smoke testing

Смока Testing є певною мірою, колинова функціонування програмного забезпечення є розвиненою і вдосконаленою з існуючою будовою, що розробляється в QA/staging environment. Існує те, що всі важливі функціонали є працюючим коректно або не.

У цьому випробуванні метод, розвиток team deploys the build in QA. Підприємствами для тестових випадків є такі, і вони є тестувальниками, які використовуються для будівництва. QA team test the application at the critical functionalities. Ці серії тестових випадків є розроблені для експонування errors, що є в будівництві. Якщо ці випробування є прописані, QA team continues with Functional Testing .

У будь-якому віці повідомлено про необхідність керувати системою back to development team. Якщо це є зміна в будівництві, ми робимо Smoke Testing для забезпечення stability.

Example: -New registration button is added in login window and build is deployed with the new code. We perform smoke testing on a new build.

Who will do Smoke Testing

Після завершення будівництва на QA навколишнього середовища, Smoke Testing is performed by QA engineers/QA lead. Коли є нова будівля, QA team визначає важливу функціональність в application to perform smoke testing. QA team checks для showstoppers в application that is under testing.

Testing done в розвитку навколишнього середовища на code to ensure the correctness of application before releasing build to QA, this is known as Sanity testing. It is usually narrow and deep testing. Це є процеси, які встановлюють, що застосування під час розробки мети його основні функціональні вимоги.

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

Why do we do smoke testing?

Smoke testing plays є важлива роль у програмі розвитку, як її функція коректності системи в початкових масштабах. By this, we can save test effort. Як результат, smoke tests bring the system to a good state. Once we complete smoke testing тільки we start functional testing.

• Всі show stoppers в будівництві будуть встановлені шляхом виконання герметичного тестування.
• Smoke testing is done after the build is released to QA. З допомогою герметичного тестування, максимальні дії є identified в початкових етапах розвитку software.
• З гальмуванням тестування, ми неспроможні до detektion and correction of major defects.
• Під час керування тестом, QA team може дотримуватися помилок до application functionality, що може бути узгоджено з новий код.
• Smoke testing finds the major severity defects.

Example 1: Logging window: Добре переміщатися до next window with valid username and password on clicking submit button.

Example 2: Userunable to sign out з веб-сторінки.

How to do Smoke Testing?

Smoke Testing є зазвичай, що manually тому що є можливість пристосування самої через автоматизацію. It may vary from organization to organization.

Manual Smoke testing

У загальному, smoke testing is done manually. Це approaches variations від однієї організації до інших. Smoke testing is carried to ensure the navigation of critical paths is as expected and doesn"t hamper the functionality. Якщо ви збираєтеся вивчати функціональні випробування, будуть виконані випробування, вивчається і спрямований на розвиток team for correction. will get integrated with old builds to maintain the correctness of the system.

Якщо Ви хочете створити просту комп'ютерну програму, яка складається з одного файлу, Вам просто необхідно зібрати та зв'язати весь написаний Вами код у цей файл. На звичайнісінькому проекті, яким займається команда розробників, існують сотні, навіть тисячі файлів. Це «сприяє» тому, що процес створення програми, що здійснюється, стає все більш складним і трудомістким: ви повинні «збирати» програму з різних компонентів.

Практика, що застосовується, наприклад, у Microsoft та деяких інших компаніях, що займаються розробкою ПЗ, полягає в щоденному складанні (білдуванні) програми, яка доповнюється димовим тестуванням. Щодня, після того, як кожен файл зібраний (збілдований, побудований), пов'язаний (слінкований), і об'єднаний у програму, що виконується, сама програма піддається досить простому набору тестів, мета яких полягає в тому, щоб побачити, «димить» чи програма під час роботи. Ці тести і називаються димовими (від англ. Smoke – дим). Найчастіше цей процес досить добре автоматизований (або має бути таким).

ПЕРЕВАГИ. Цей простий процес забезпечує кілька суттєвих переваг.

Мінімізація ризику під час інтеграції

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

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

Зниження ризику низької якості програмного продукту

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

Допомога у діагностиці помилок

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

Поліпшення морального духу

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

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

Ось кілька подробиць цього принципу.

Щоденне складання програми

Фундаментальною частиною щоденного складання є складання тієї частини, що була зроблена останньою. Джим Маккарті (Jim McCarthy) у журналі Dynamics of Software Development (Microsoft Press, 1995) назвав щоденне білдування проекту його серцебиттям. Якщо серцебиття немає – проекту немає, він мертвий. Менш образно щоденне білдування описали Майкл Касамано (Michael Cusumano) та Річард Селбі (Richard W. Selby), назвавши його синхронізуючим імпульсом проекту (Microsoft Secrets, The Free Press, 1995). Кожен розробник пише код по-своєму і він, код, може виходити за загальноприйняті на проекті рамки - це нормально, але при кожній дії синхронізуючого імпульсу код повертається до стандарту. Наполягаючи на веденні розробки з використанням імпульсу синхронізації постійно, Ви перешкоджаєте виходу проекту із синхронізації повністю.

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

Перевірка на невдале складання

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

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

Хорошим збиранням є та, при якій як мінімум:

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

Щоденні димові тести

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

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

Димове тестування має розвиватися лише на рівні з проектом. На початку димові тести перевірятимуть щось просте, наприклад, чи може проект видавати повідомлення «Hello, World!». З розвитком системи димові тести стають глибшими. Час, який витрачається на перші димові тести, обчислюється кількома секундами, проте зі зростанням системи зростає кількість необхідного для димового тестування часу. Наприкінці проекту димове тестування може тривати протягом годин.

Визначення групи збирання

На більшості проектів є певний співробітник, відповідальний за перевірку щоденного складання системи та виконання димових тестів. Ця робота є частиною обов'язків даного співробітника, але на великих проектах таких співробітників може бути більше і така робота є основним їх обов'язком. Наприклад, у групі збирання проекту Windows NT 3.0 було чотири особи (Pascal Zachary, Showstopper!, The Free Press, 1994).

Додавайте ревізію до складання тільки якщо це має сенс

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

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

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

Але на деяких проектах запроваджуються більш серйозні штрафні санкції. Наприклад, розробники компанії Microsoft, які перебувають у проектах із високим пріоритетом (Windows NT, Windows 95, Excel), носили пейджери і, у разі виявлення перевірки, вони мали прибути працювати. Навіть якщо поломка або помилка були виявлені о 3 ранку.

Збирайте систему та «димайте» її навіть під тиском

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

Хто виграє від цього процесу? Деякі розробники протестують проти щоденних збірок, обґрунтовуючи свої протести непрактичністю цього заняття та його тимчасовими витратами. Але всі складні системи останнього часу піддавалися щоденним збиранням та прогону димових тестів. До моменту свого випуску Microsoft Windows NT 3.0 містила в 40 000 файлах 5,6 мільйонів рядків. Повне складання займало 19 годин і виконувалося на кількох комп'ютерах. Незважаючи на це, розробники примудрялися щоденно збирати систему. Будучи професійною командою, група розробників NT своїм успіхом багато в чому зобов'язана щоденному складання. Ті розробники, які працюють на менш складних проектах і тому не користуються перевагами процесу щоденного складання, повинні замислитися над тим, щоб придумати собі якісь розумні пояснення.

• Tutorial

Доброго вам дня!

Хочу зібрати всю необхідну теорію з тестування, яку запитують на співбесідах у trainee, junior і трошки middle. Власне, я зібрав уже багато. Мета цього посту в тому, щоб спільно додати втрачене і виправити/перефразувати/додати/зробитиЩоЩе з тим, що вже є, щоб стало добре і можна було взяти все це і повторити перед черговою співбесідою про всяк випадок. Втім, колеги, прошу під кат, кому почерпнути щось нове, кому систематизувати старе, а кому зробити свій внесок.

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

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

У темі: визначення тестування, якість, верифікація / валідація, цілі, етапи, тест план, пункти тест плану, тест дизайн, техніки тест дизайну, traceability matrix, tets case, чек-лист, дефект, error/deffect/failure, баг репорт , severity vs priority, рівні тестування, види / типи, підходи до інтеграційного тестування, принципи тестування, статичне та динамічне тестування, дослідницьке / ad-hoc тестування, вимоги, життєвий цикл бага, стадії розробки програмного забезпечення, decision table, qa/qc/test Engineer, діаграма зв'язків.

Поїхали!

Тестування програмного забезпечення- перевірка відповідності між реальною та очікуваною поведінкою програми, що здійснюється на кінцевому наборі тестів, обраному певним чином. У більш широкому сенсі, тестування - це одна з технік контролю якості, що включає активності з планування робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) і аналізу отриманих результатів (Test Analysis).

Якість програмного забезпечення (Software Quality)- це сукупність параметрів програмного забезпечення, які належать до його здатності задовольняти встановлені та передбачувані потреби.

Верифікація (verification)- це процес оцінки системи або її компонентів з метою визначення, чи задовольняють результати поточного етапу розробки умов, сформованих на початку цього етапу. Тобто. чи виконуються наші цілі, терміни, завдання розробки проекту, визначені на початку поточної фази.
Валідація (validation)- це визначення відповідності розроблюваного ПЗ очікуванням та потребам користувача, вимогам до системи.
Також можна зустріти іншу інтерпретацію:
Процес оцінки відповідності продукту явним вимогам (специфікаціям) і є верифікація (verification), водночас оцінка відповідності продукту очікуванням та вимогам користувачів є валідація (validation). Також часто можна зустріти таке визначення цих понять:
Validation - 'is ​​this the right specification?'.
Verification - 'is ​​the system correct to specification?'.

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

Етапи тестування:
1. Аналіз
2. Розробка стратегії тестування
та планування процедур контролю якості
3. Робота з вимогами
4. Створення тестової документації
5. Тестування прототипу
6. Основне тестування
7. Стабілізація
8. Експлуатація

Тест план (Test Plan)- це документ, що описує весь обсяг робіт із тестування, починаючи з опису об'єкта, стратегії, розкладу, критеріїв початку та закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення.
Відповідає на запитання:
Що треба випробувати?
Що тестуватимете?
Як тестуватимете?
Коли тестуватимете?
Критерії початку тестування.
Критерії закінчення тестування.

Основні пункти тест плану
У стандарті IEEE 829 перераховані пункти, з яких повинен (нехай може) складатися тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Економічні потреби;
l) Responsibilities;
m) StafÞng and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Тест дизайн- це етап процесу тестування ПЗ, на якому проектуються та створюються тестові випадки (тест кейси), відповідно до визначених раніше критеріїв якості та цілей тестування.
Ролі, відповідальні за тест дизайн:
Тест аналітик – визначає «ЩО тестувати?»
Тест дизайнер – визначає «ЯК тестувати?»

Техніки тест дизайну

Еквівалентний Поділ (Equivalence Partitioning – EP). Як приклад, у вас є діапазон допустимих значень від 1 до 10, ви повинні вибрати одне правильне значення всередині інтервалу, скажімо, 5, і одне неправильне значення поза інтервалом - 0.

Аналіз Граничних Значень (Boundary Value Analysis – BVA). Якщо взяти приклад вище, як значення для позитивного тестування виберемо мінімальну і максимальну межі (1 і 10), і значення більше і менше меж (0 і 11). Аналіз Граничний значень може бути застосований до полів, записів, файлів, або до будь-яких сутностей, що мають обмеження.

Причина/Слідство (Cause/Effect - CE). Це, як правило, введення комбінацій умов (причин) для отримання відповіді від системи (Слідство). Наприклад, ви перевіряєте можливість додавати клієнта, використовуючи певну екранну форму. Для цього вам необхідно буде ввести кілька полів, таких як "Ім'я", "Адреса", "Номер Телефону", а потім натиснути кнопку "Додати" - ця "Причина". Після натискання кнопки «Додати» система додає клієнта в базу даних і показує його номер на екрані - це «Слідство».

Вичерпне тестування (Exhaustive Testing – ET)- Це крайній випадок. У межах цієї техніки ви повинні перевірити всі можливі комбінації вхідних значень, і в принципі це має знайти всі проблеми. Насправді застосування цього методу неможливо, через велику кількість вхідних значень.

Traceability matrix- Матриця відповідності вимог - це двовимірна таблиця, що містить відповідність функціональних вимог (functional requirements) продукту та підготовлених тестових сценаріїв (test cases). У заголовках колонок таблиці розташовані вимоги, а заголовках рядків - тестові сценарії. На перетині - відмітка, що означає, що вимога поточної колонки покрита тестовим сценарієм поточного рядка.
Матриця відповідності вимог використовується QA-інженерами для валідації покриття продукту тестами. МСТ є невід'ємною частиною тест-плану.

Тестовий випадок (Test Case)- це артефакт, що описує сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації функції або її частини, що тестується.
Приклад:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

Кожен тест кейс повинен мати 3 частини:
PreConditions Список дій, які призводять систему до стану придатного для проведення основної перевірки. Або перелік умов, виконання яких свідчить, що система перебуває у придатному щодо основного тесту стану.
Test Case Description Список дій, що переводять систему з одного стану в інший, для отримання результату, на підставі якого можна зробити висновок про задоволення реалізації, поставленим вимогам
PostConditions Список дій, що переводять систему в початковий стан (стан до проведення тесту - initial state)
Види Тестових Випадків:
Тест кейси поділяються за очікуваним результатом на позитивні та негативні:
Позитивний тест кейс використовує тільки коректні дані і перевіряє, що програма правильно виконала функцію, що викликається.
Негативний тест кейс оперує як коректними так і некоректними даними (мінімум 1 некоректний параметр) і ставить за мету перевірку виняткових ситуацій (спрацьовування валідаторів), а також перевіряє, що функція, що викликається додатком, не виконується при спрацьовуванні валідатора.

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

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

Error- Помилка користувача, тобто він намагається використовувати програму іншим способом.
Приклад - вводить літери на поля, де потрібно вводити цифри (вік, кількість товару і т.п.).
У якісній програмі передбачені такі ситуації та видаються повідомлення про помилку (error message), з червоним хрестиком.
Bug (дефект)- Помилка програміста (або дизайнера або ще кого, хто бере участь у розробці), тобто коли в програмі щось йде не так як планувалося і програма виходить з-під контролю. Наприклад, коли ніяк не контролюється введення користувача, в результаті невірні дані викликають краші або інші "радості" у роботі програми. Або всередині програма побудована так, що спочатку не відповідає тому, що від неї очікується.
Failure- збій (причому не обов'язково апаратний) у роботі компонента, всієї програми чи системи. Тобто є такі дефекти, які призводять до збоїв (A defect caused the failure) і існують такі, які не призводять. UI-дефекти, наприклад. Але апаратний збій, що ніяк не пов'язаний із software, теж є failure.

Баг Репорт (Bug Report)- це документ, що описує ситуацію або послідовність дій, що призвела до некоректної роботи об'єкта тестування, із зазначенням причин та очікуваного результату.
Шапка
Короткий опис (Summary) Короткий опис проблеми, що явно вказує на причину та тип помилкової ситуації.
Проект (Project) Назва проекту, що тестується
Компонент програми (Component) Назва частини або функції продукту, що тестується
Номер версії (Version) Версія на якій було знайдено помилку
Серйозність (Severity) Найбільш поширена п'ятирівнева система градації серйозності дефекту:
S1 Блокуючий (Blocker)
S2 Критичний (Critical)
S3 Значний (Major)
S4 Незначний (Minor)
S5 Тривіальний (Trivial)
Пріоритет (Priority) Пріоритет дефекту:
P1 Високий (High)
P2 Середній (Medium)
P3 Низький (Low)
Статус (Status) Статус бага. Залежить від процедури та життєвого циклу бага (bug workflow and life cycle)

Автор (Author) Творець баг репорту
Призначений на (Assigned To) Ім'я співробітника, призначеного для вирішення проблеми
Оточення
ОС/Сервіс Пак і т.д. / Браузера + версія / ... Інформація про оточення, на якому було знайдено баг: операційна система, сервіс пак, для WEB тестування - ім'я та версія браузера і т.д.
…
Опис
Кроки відтворення (Steps to Reproduce) Кроки, якими можна легко відтворити ситуацію, що призвела до помилки.
Фактичний Результат (Result) Результат, отриманий після проходження кроків до відтворення
Очікуваний результат (Expected Result) Очікуваний правильний результат
Доповнення
Файл з логами, скріншот або будь-який інший документ, який може допомогти прояснити причину помилки або вказати на спосіб вирішення проблеми.

Severity vs Priority
Серйозність (Severity) – це атрибут, що характеризує вплив дефекту на працездатність програми.
Пріоритет (Priority) - це атрибут, що вказує на черговість виконання завдання чи усунення дефекту. Можна сміливо сказати, що це інструмент менеджера з планування робіт. Що пріоритет, то швидше потрібно виправити дефект.
Severity виставляється тестувальником
Priority - менеджером, тимлідом чи замовником

Градація Серйозності дефекту (Severity)

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

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

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

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

S5 Тривіальна (Trivial)
Тривіальна помилка, що не стосується бізнес логіки програми, погано відтворювана проблема, малопомітна за допомогою інтерфейсу користувача, проблема сторонніх бібліотек або сервісів, проблема, що не впливає на загальну якість продукту.

Градація Пріоритету дефекту (Priority)
P1 Високий (High)
Помилка має бути виправлена ​​якнайшвидше, т.к. її наявність є критичною для проекту.
P2 Середній (Medium)
Помилка має бути виправлена, її наявність не критична, але вимагає обов'язкового рішення.
P3 Низький (Low)
Помилка має бути виправлена, її наявність не критична, і не вимагає термінового рішення.

Рівні Тестування

1. Модульне тестування (Unit Testing)
Компонентне (модульне) тестування перевіряє функціональність та шукає дефекти в частинах програми, які доступні та можуть бути протестовані окремо (модулі програм, об'єкти, класи, функції тощо).

2. Інтеграційне тестування (Integration Testing)
Перевіряють взаємодію між компонентами системи після проведення компонентного тестування.

3. Системне тестування (System Testing)
Основним завданням системного тестування є перевірка як функціональних, і функціональних вимог у системі загалом. При цьому виявляються дефекти, такі як неправильне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або неправильна функціональність, незручність використання і т.д.

4. Операційне тестування (Release Testing).
Навіть якщо система задовольняє всім вимогам, важливо переконатися в тому, що вона задовольняє потреб користувача і виконує свою роль у середовищі своєї експлуатації, як це було визначено у бізнес-моделі системи. Слід врахувати, що бізнес модель може містити помилки. Тому важливо провести операційне тестування як фінальний крок валідації. Крім цього, тестування в середовищі експлуатації дозволяє виявити і нефункціональні проблеми, такі як: конфлікт з іншими системами, суміжними в галузі бізнесу або програмних та електронних оточення; недостатня продуктивність системи серед експлуатації та інших. Вочевидь, що перебування подібних речей на стадії впровадження - критична і дорога проблема. Тому так важливо проведення не тільки верифікації, а й валідації з ранніх етапів розробки ПЗ.

5. Приймальне тестування (Acceptance Testing)
Формальний процес тестування, який перевіряє відповідність системи вимогам та проводиться з метою:
визначення чи задовольняє система приймальним критеріям;
винесення рішення замовником чи іншою уповноваженою особою приймається додаток чи ні.

Види/типи тестування

Функціональні види тестування
Функціональне тестування (Functional testing)
Тестування безпеки (Security and Access Control Testing)
Тестування взаємодії (Interoperability Testing)

Нефункціональні види тестування
Усі види тестування продуктивності:
o навантажувальне тестування (Performance and Load Testing)
o стресове тестування (Stress Testing)
o тестування стабільності чи надійності (Stability / Reliability Testing)
o об'ємне тестування (Volume Testing)
Тестування установки (Installation testing)
Тестування зручності користування (Usability Testing)
Тестування на відмову та відновлення (Failover and Recovery Testing)
Конфігураційне тестування (Configuration Testing)

Пов'язані зі змінами види тестування
Димове тестування (Smoke Testing)
Регресійне тестування (Regression Testing)
Повторне тестування (Re-testing)
Тестування складання (Build Verification Test)
Санітарне тестування або перевірка узгодженості/справності (Sanity Testing)

Функціональне тестуваннярозглядає заздалегідь зазначену поведінку і ґрунтується на аналізі специфікацій функціональності компонента чи системи загалом.

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

Тестування взаємодії (Interoperability Testing)- це функціональне тестування, що перевіряє здатність програми взаємодіяти з одним і більше компонентами або системами і включає тестування сумісності (compatibility testing) та інтеграційне тестування

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

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

Об'ємне тестування (Volume Testing). Завданням об'ємного тестування є отримання оцінки продуктивності зі збільшенням обсягів даних у базі даних додатку

Тестування стабільності чи надійності (Stability / Reliability Testing). Завданням тестування стабільності (надійності) є перевірка працездатності програми при тривалому (багатогодинному) тестуванні із середнім рівнем навантаження.

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

Тестування зручності користування- це метод тестування, спрямований на встановлення ступеня зручності використання, навченості, зрозумілості та привабливості для користувачів продукту, що розробляється в контексті заданих умов. Сюди також входить:
Тестування інтерфейсу користувача (англ. UI Testing) - це вид тестування дослідження, що виконується з метою визначення, чи зручний деякий штучний об'єкт (такий як веб-сторінка, інтерфейс користувача або пристрій) для його передбачуваного застосування.
User eXperience (UX) - відчуття, яке випробовує користувач під час використання цифрового продукту, тоді як User interface - це інструмент, що дозволяє здійснювати інтеракцію «користувач - веб-ресурс».

Тестування на відмову та відновлення (Failover and Recovery Testing)перевіряє тестований продукт з точки зору здатності протистояти та успішно відновлюватися після можливих збоїв, що виникли у зв'язку з помилками програмного забезпечення, відмови обладнання або проблемами зв'язку (наприклад, відмова мережі). Метою даного виду тестування є перевірка систем відновлення (або дублюючих основний функціонал систем), які, у разі виникнення збоїв, забезпечать збереження та цілісність даних продукту, що тестується.

Конфігураційне тестування (Configuration Testing)- спеціальний вид тестування, спрямований на перевірку роботи програмного забезпечення при різних конфігураціях системи (заявлених платформах, драйверах, що підтримуються, при різних конфігураціях комп'ютерів і т.д.)

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

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

Повторне тестування- Тестування, під час якого виконуються тестові сценарії, що виявили помилки під час останнього запуску, для підтвердження успішності виправлення цих помилок.
У чому різниця між regression testing та re-testing?
Re-testing - перевіряється виправлення багів
Regression testing - перевіряється те, що виправлення багів не вплинуло інші модулі ПЗ і викликало нових багів.

Тестування складання або Build Verification Test- Тестування спрямоване на визначення відповідності, випущеної версії, критеріям якості для початку тестування. За своїми цілями є аналогом Димового Тестування, спрямованого на прийняття нової версії в подальше тестування або експлуатацію. Вглиб воно може проникати далі, залежно від вимог якості випущеної версії.

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

Передбачення помилки (Error Guessing – EG). Це коли тест аналітик використовує свої знання системи та здатність до інтерпретації специфікації щодо того, щоб «передбачити» за яких вхідних умов система може видати помилку. Наприклад, специфікація каже: "користувач повинен ввести код". Тест аналітик буде думати: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код? ", і так далі. Це і є передбачання помилки.

Підходи до інтеграційного тестування:

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

Зверху донизу (Top Down Integration)
Спочатку тестуються всі високорівневі модулі і поступово один за одним додаються низькорівневі. Усі модулі нижчого рівня симулюються заглушками з аналогічною функціональністю, потім у міру готовності заміняються реальними активними компонентами. Таким чином, ми проводимо тестування зверху вниз.

Великий вибух ("Big Bang" Integration)
Усі або практично всі розроблені модулі збираються разом у вигляді закінченої системи або її основної частини, а потім проводиться інтеграційне тестування. Такий підхід дуже добрий для збереження часу. Проте якщо тест кейси та його результати записані не так, то сам процес інтеграції сильно ускладниться, що стане перепоною для команди тестування при досягненні основної мети інтеграційного тестування.

Принципи тестування

Принцип 1- Тестування демонструє наявність дефектів (Testing shows presence of defects)
Тестування може показати, що дефекти є, але не може довести, що їх немає. Тестування знижує ймовірність наявності дефектів, що у програмному забезпеченні, але, навіть якщо дефекти були виявлено, це доводить його коректності.

Принцип 2- Вичерпне тестування є недосяжним (Exhaustive testing is impossible)
Повне тестування з допомогою всіх комбінацій вводів і передумов фізично нездійсненно, крім виняткових випадків. Замість вичерпного тестування повинні використовуватися аналіз ризиків та встановлення пріоритетів, щоб точніше сфокусувати зусилля з тестування.

Принцип 3- Раннє тестування (Early testing)
Щоб знайти дефекти якомога раніше, активності з тестування повинні бути розпочаті якомога раніше в життєвому циклі розробки програмного забезпечення або системи, і повинні бути сфокусовані на певних цілях.

Принцип 4- Скупчення дефектів (Defects clustering)
Зусилля тестування повинні бути зосереджені пропорційно до очікуваної, а пізніше реальної щільності дефектів по модулях. Як правило, більша частина дефектів, виявлених при тестуванні або спричинили основну кількість збоїв системи, міститься в невеликій кількості модулів.

Принцип 5- Парадокс пестициду (Pesticide paradox)
Якщо ті самі тести будуть проганятися багато разів, зрештою цей набір тестових сценаріїв більше не знаходитиме нових дефектів. Щоб подолати цей «парадокс пестициду», тестові сценарії повинні регулярно рецензуватися та коригуватися, нові тести мають бути різнобічними, щоб охопити всі компоненти програмного забезпечення, або системи, та знайти якнайбільше дефектів.

Принцип 6- Тестування залежить від контексту (Testing is concept depending)
Тестування виконується по-різному, залежно від контексту. Наприклад, програмне забезпечення, в якому критично важлива безпека, тестується інакше, ніж сайт електронної комерції.

Принцип 7- Помилка про відсутність помилок (Absence-of-errors fallacy)
Виявлення та виправлення дефектів не допоможуть, якщо створена система не підходить користувачеві та не задовольняє його очікуванням та потребам.

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

Дослідницьке / ad-hoc тестування
Найпростіше визначення дослідницького тестування - це розробка та виконання тестів одночасно. Що є протилежністю сценарного підходу (з його наперед визначеними процедурами тестування, неважливо ручними або автоматизованими). Дослідницькі тести, на відміну від сценарних тестів, не визначені заздалегідь і не виконуються точно відповідно до плану.

Різниця між ad hoc та exploratory testing у тому, що теоретично, ad hoc може провести будь-хто, а для проведення exploratory необхідна майстерність та володіння певними техніками. Зауважте, що певні техніки це не тільки техніки тестування.

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

Вимоги до вимог:
Коректність
Недвозначність
Повнота набору вимог
Несуперечність набору вимог
Перевірюваність (тістопридатність)
Трасування
Розуміння

Життєвий цикл бага

Стадії розробки ПЗ- це етапи, які проходять команди розробників програмного забезпечення, перш ніж програма стане доступною для широкого кола користувачів. Розробка ПЗ починається з початкового етапу розробки (стадія «пре-альфа») і продовжується стадіями, на яких продукт доопрацьовується та модернізується. Фінальним етапом цього процесу стає випуск ринку остаточної версії програмного забезпечення («загальнодоступного релізу»).

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

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

Життєвий цикл розробки ПЗ:
Пре-альфа
Альфа
Бета
Реліз-кандидат
Реліз
Пост-реліз

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

QA/QC/Test Engineer


Отже, ми можемо побудувати модель ієрархії процесів забезпечення: Тестування - частина QC. QC – частина QA.

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

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

Приклади

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

Історія

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

Повторне народження терміна відбулося в радіоелектроніці. Перше увімкнення нового радіоелектронного пристрою, що прийшов з виробництва, відбувається на дуже короткий час (менше секунди). Потім інженер руками обмацує всі мікросхеми щодо перегріву. Мікросхема, що сильно нагрілася за цю секунду, може свідчити про грубу помилку в схемі. Якщо перше включення не виявило перегріву, то пристрій знову вмикається на більший час. Перевірка повторюється. І так далі кілька разів. Вираз «smoke-test» використовується інженерами в жартівливому сенсі, оскільки появи диму, а значить і псування частин пристрою, намагаються уникнути.

Автоматизація

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

Напишіть відгук про статтю "Smoke test"

Посилання

• на Jargon File (англ.)
• msdn.microsoft.com/ru-ua/library/ms182613(VS.90).aspx - Правила з коротких тестів від Microsoft.

Уривок, що характеризує Smoke test

Для князя Андрія минуло сім днів з того часу, як він прийшов до тями на перев'язувальному пункті Бородинського поля. Весь цей час він перебував майже в постійному непритомності. Гаряче стан і запалення кишок, які були пошкоджені, на думку лікаря, який їхав з пораненим, повинні були забрати його. Але на сьомий день він із задоволенням з'їв скибу хліба з чаєм, і лікар помітив, що загальний жар зменшився. Князь Андрій ранком прийшов до тями. Першу ніч після виїзду з Москви було досить тепло, і князя Андрія залишили для ночівлі в колясці; але в Митищах поранений сам зажадав, щоб його винесли і щоб йому дали чаю. Біль, завданий йому перенесенням у хату, змусив князя Андрія голосно стогнати і знепритомніти. Коли його поклали на похідному ліжку, він довго лежав із заплющеними очима без руху. Потім він відкрив їх і тихо прошепотів: Що ж чаю? Пам'ятливість ця до дрібних подробиць життя вразила лікаря. Він помацав пульс і, на подив і невдоволення своєму, помітив, що пульс був кращим. До невдоволення свого це помітив лікар тому, що він з досвіду свого був переконаний, що жити князь Андрій не може і що якщо він не помре тепер, то він тільки з великими стражданнями помре кілька днів після. З князем Андрієм везли майора, що приєднався до них у Москві, його полку Тимохіна з червоним носиком, пораненого в ногу в тій же Бородінській битві. При них їхав лікар, камердинер князя, його кучер і два денники.