Питання #43 Як Ви розумієте, що таке рівні тестування?

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

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

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

Простіше кажучи… якщо рівні тестування назвати простою мовою, на «банальному» прикладі, то звучало б це так:

Отож, приклад тестування предмету двері:

Тестування Дверей

  1. Cпочатку ми протестуємо функціонал ручки від дверей окремо від самого полотна дверей (модульне тестування, юніт тестування);
  2. Потім двері і ручку протестуємо приміряючи так би мовити — наскільки вони пасують один до одного (інтеграційне тестування);
  3. Далі тестуємо увесь комплект разом (системне тестування);
  4. Приймальне тестування — це коли проводиться тестування повністю зібраних дверей за обраним набором тест-кейсів до моменту доки не буде досягнута необхідна якість разом із замовником;
  5. Регресійне тестування — повноцінне тестування дверей у зборі після ремонту, виправлення деяких помилок, так як процес налагодження спричинив виникнення нових проблем з дверима — нехай, скриплять у незначній мірі.
  6. Continuous testing — процес тестування і налагодження може проходити безперервно у процесі повного функціювання дверей (ми пропускаємо крізь двері людей, не знімаючи їх із завіс). Отже:

Рівні тестування програмного забезпечення:

  1. Unit Testing or Component Testing — модульне або компонентне тестування;
  2. Integration Testing — інтеграційне тестування;
  3. System Testing системне тестування;
  4. Acceptance Testing — приймальне тестування.

Додаткові рівні тестування ПО:

  1. Continuous testing безперервне тестування, новомодна тенденція філософії DevOps;
  2.  Regression testing регресійне тестування.
Графічне відображення рівнів тестування
Рівні Тестування програмного забезпечення.

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

Питання #44 Що таке Unit Testing?

Для кращого розуміння просто перекладіть слово Unit  з англійської, одиниця, частина, елемент, орган. Зрозуміло? Звідси Unit Testing (юніт-тестування) — передбачає тестування окремих модулів і компонент програми. Чи не містить та частинка багу, не видає помилок, чи правильно функціонує?

Зазвичай юніт-тестуванням займаються самі розробники програмісти, творці свого коду… така собі “самоперевірка”, використовуючи методи дебагу коду інструментами розробника у браузері, призначені бібліотеки для цього «діла» та інколи спеціальні фреймворки. Знайдені таким чином дефекти, програміст одразу за собою виправляє без формальностей пов’язаних із внесенням і описом у Bug Tracking System.

Питання #45 Яка різниця між Модульним та Компонентним тестуванням?

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

Питання #46 А Ви знаєте що таке є TDD?

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

Схожий підхід Test First — спочатку тестування. При цьому підході створюються або інтегруються у програму невеликі шматки коду, а паралельно запускаються тести на навмисно тільки «невдалі спроби», написані ще до початку кодування. Розробка ведеться до тих пір поки всі тести не будуть успішними, доки помилок не залишиться більше. Тобто ці 2 підходи передбачають еталонне програмування по заданому зразку, по схемі.

Питання #47 І яка різниця між Test First & Test Driven Development?

Багато хто різниці між цими підходами не виділяє, оскільки грань між ними надто тонка. На нашу думку, різниця полягає лише в тому, що при підході TDD (Test Driven Development наголос робиться на постійний рефакторинг (перевірці якості коду програміста), а другий підхід Test First у більшій мірі спрямований на періодичну перевірку.

Питання #48 Що таке Екстремальне програмування?

Екстремальне програмування (ХР, Extreme Programming) — знову ж таки, це є ще один вид сучасних гнучких методологій, підходів до розробки програмного забезпечення. Згідно Вікіпедії: ХР пропагує: часті “випуски” програми у коротких циклах розробки, з метою поліпшити продуктивність праці та покращити можливості виконання вимог замовника що змінюються, зменшення часу на “доставку” ПЗ.

Розглянуті теми Test Driven Development, Test First, Екстремальне програмування, Continuous integration testing, Регресійне тестування — сьогодні доволі модні теми, які у всіх є на слуху, тому поряд зі Scrum -ом і Agile підходами Вас цілком можуть про них запитати на співбесіді на QA тест-інженера. Думаю, елементарно Ви вже зможете відповісти 😆 А як хочете знати більше, читайте Кента Блека, його гарні книжечки тут на сайті у розділі IT КНИГИ особливо радимо ось цю Екстремальне програмування, TDD.

Питання #49 Що таке інтеграційне тестування?

Інтеграційне тестування (Integration testing) — спрямоване на перевірку взаємодії між модулями, компонентами програми, а також перевірку взаємодії програми з різними частинами системи (операційною системою, обладнанням, сервером, пристроями, іншими зв’язками у системі).

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

Рівні інтеграційного тестування: 

  • Component Integration testing (Компонентний інтеграційний рівень) — взаємодія перевіряється після проведення компонентного тестування;
  • System Integration Testing (Системний інтеграційний рівень) — взаємодія перевіряється після проведення системного тестування.

Питання #50 Які типи інтеграційних тестів знаєте?

  • Big Bang Integration Testing (Тестування інтеграції великого вибуху)  це коли тестування інтеграції і “збірка” програми починається тільки після того, як основні елементи програми розроблені, або майже система є готова. Відрізняється від системного тестування, оскільки тут ми зосереджуємось на тестуванні на взаємодії / комунікації між модулями. Підхід “великого вибуху” вважається не дуже доцільним, і його застосовують лише для невеликих проектів.
  • Top Down Integration Testing (Тестування інтеграції зверху вниз)  тестування / інтеграція починається від верхніх модулів до модулів нижчого рівня з використанням заглушок, оскільки існує велика ймовірність того, що модулі нижчого рівня, просто ще не були розроблені. Основна перевага Top Down Integration Testing логічно, що не потрібно чекати, поки всі модулі будуть розроблені.
  • Bottom Up Integration Testing (Тестування інтеграції знизу вгору)  тестування починається з модулів нижнього рівня до модуля вищого рівня в ієрархії. Тут в поміч ідуть драйвери.
  • Hybrid Integration Testing (Гібридне інтеграційне тестування)  називається також Sandwich approach це комбінація тестування як згори вниз, так і знизу вгору. У такому підході інтеграція починається з середнього шару і тестування здійснюється в обох напрямках. Такий спосіб інтеграційного тестування поєднує у собі 2 попередні, оскільки допомагає швидше протестити інтерфейс.

Питання #51 Що таке Stub?

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

Питання #52 Що таке Драйвер?

У випадку інтеграційного тестування «Bottom Up — знизу вгору» драйвери використовуються з протилежною від Заглушок ціллю — для імітації роботи модулів вищої міри, щоб випробувати відповідні модулі, які розроблені нижче в ієрархічній схемі. Знову ж таки, модулі вищого рівня, можливо, не були розроблені і їх слід замінити “тимчасовими” модулями.

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

Питання #53 Що таке Test Harness? Чому ми потребуємо протестовування?

Контрольна проводка  це збірка, колекція test scripts та test data, які зазвичай пов’язують з юніт-тестуванням пристроїв та інтеграційним тестуванням. Воно включає заглушки та драйвери, необхідних для тестування програмних модулів та інтегрованих компонентів. Детальніше ми про це поговоримо коли-небудь, коли глибше розбиратимемо автоматизоване тестування.

Питання #54 Що таке Incremental testing?

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

Зазначимо лище, що інкрементальне тестування проводиться одночасно у різних напрямках: згори, вниз, зсередини, одночасно із застосуванням заглушок і драйверів — така… собі «солянка послідовного тестування інтеграції».

Питання #55 Що таке системне тестування?

Системне тестування — це рівень тестування ПЗ, де систему тестують як щось «ціле» на відповідність вимогам до системи. Основне завдання перевірити, як функціональні, так і не функціональні вимоги. Проводиться QA командою після завершення інтеграційного тестування і до завершального етапу Acceptance Testing (приймального тестування). Одним словом — це всім відоме Black Box Testing (тестування чорної скриньки) потрібно протестувати програму від початку до кінця, без знання поглиблено її архітектури.

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

Існує два підходи до системного тестування:

  • На базі вимог (Requirements based)  це коли для кожної вимоги пишуться тестові випадки (test cases), які перевіряють виконання цієї вимоги.
  • На базі тестових випадків (Use case based)  ґрунтуючись на уявленнях про способи використання продукту, створюються тестові випадки використання (Use Cases). По кожному конкретному (Use Cases) можна, в свою чергу, створити один або більше сценаріїв. На перевірку кожного сценарію пишуться тест кейси (Test cases), які повинні бути протестовані. Перегляньте попередню шпаргалку для тестувальника QA там відмальована схема сценаріїв (Use Cases).

Питання #56 Що таке приймальне тестування?

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

Приймальне тестування виконується згідно до Плану приймальних робіт (Product Acceptance Plan) або згідно іншого документу, де описаний набір дій, пов’язаний із проведенням приймального тестування, датою релізу, відповідальними з кожної із сторін і т.п.

Питання #57 Які типи приймального тестування Ви знаєте?

Alpha Testing & Beta Testing — Альфа тестування & Бета тестування.

Alpha Testing

Beta Testing

Форма приймального тестування закритою групою.Виконується після альфа-тестування та в реальному середовищі без присутності, але під контролем розробників зазвичай.
Може проводитися, як власними розробниками та QA, так і невеликим колом потенційних кінцевих користувачів.Форма приймального тестування на стороні клієнта або кінцевого користувача.
Альфатестування не відкрите для світу.Бетатести або бетаверсія програми  відкрита для всього світу. Досить популярна методика, коли у відомих компаній чергова бета-версія тестується кінцевими користувачами: Linux, Mozila, геймдев всякий. І тестувальникам початківцям на волонтерських умовах, досить корисно заради досвіду долучатися до таких проектів. Інколи, навіть варто його вказувати у резюме тестувальника.
Може здійснюватися у формі Білої скриньки разом із тестами Чорного ящику. Більше про це у Частині 2 шпаргалки для QA Техніки Тестування.ПАМʼЯТАЙТЕ! Бетатести — це тести та техніки тестування лише Чорної скриньки.

Питання #58 Які є методи приймального тестування?

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

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

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

Питання #59 Що таке Crowdsourced testing?

Crowdsourced testing — це теж своєрідний тип Незалежного Тестування, Тестування на замовлення. Crowdsourced testing проводиться великою групою людей, QA спільнотою або фахівцями з якості найманими, як правило, на великих спеціалізованих форумах тестувальників.

Хлібні адреси таких форумів тестувальників розглядалися нами тут: Топ сайтів фріланс тестування або найкращі точки роботи QA віддалено

Питання #60 Що таке регресійне тестування?

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

Але, за Канером розрізняють 3 типи регресійних тестів:

  • Регресія багів (Bug Regression) спроба доказати, що помилка котра подавалася на виправлення, насправді не виправлена. Але коли все ОК тести переходять на завершальну стадію Final Regression Test.
  • Регресія старих багів (Old Bug Regression)  спроба доказати, що недавня зміна коду чи даних знову спричинила появу виправлених старих помилок, тобто старі баги стали знов відтворюватися.
  • Регресія побічного ефекту (Side Effect Regression) спроба доказати, що недавнє зміна коду чи даних поламала інші частини розроблюваної програми.

Кроки Регресійного тестування:

  1. Обрати поле тестів для регресії;
  2. Вибрати інструмент автоматизованого тестування і автоматизувати процес тестування;
  3. Верифікація програми у контрольних точках;
  4. Оновлення автоматизованих тестів згідно вимог при необхідності;
  5. Складення розкладу тестів;
  6. Інтегрувати тести з білдами;
  7. Аналіз результатів.

Питання #61 Що таке Retesting?

Retesting (інколи вживають термін, повторне тестування) це повторна перевірка, коли ми перевіряємо чи вирішена остаточно фіксена проблема?

Питання #62 Яка різниця між Regression та Retesting -ом?

Регресінг

Ретестінг

Регресінг  це виявлення дефектів у вже випробуваних ділянках програми. Перевірка регресії передбачає тестування програми, щоб переконатися, що нова зміна коду, функціональності програми не впливає на інші частини програми. А при Retesting -гу, ми просто перевіряємо, чи вирішено раз та назавжди питання з фіксенням якогось багу чи ні? Тому повторна перевірка має більший пріоритет за регресійне тестування. Хоча ці обидва види тестування не заборонено проводити паралельно.
Метою регресійного тестування є перевірка непередбачених непрямих факторів. Повторне ж тестування виконується для перевірок.
При регресійному тестуванні перевіряються абсолютно всі тести, в той час як при повторному  тільки не пройдений.
Автоматизовувати доцільно, навіть кращеНЕ автоматизують.
Регресійна перевірка проводиться у разі, коли нові фічі системи були додані або проводилися модифікації або поліпшення самого коду. Повторне тестування виконують із застосуванням ті ж даних і в тому ж середовищі, що і раніше, але вже на новому білді.
Тесткейси для регресійного тестування можна створювати на основі специфікацій проекту або іншої документації, а також на основі готових звітів про помилки.  Повторні тесткейси можуть бути доступні тільки після завершення самого процесу тестування.

Питання #63 What is Sanity Testing?

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

Питання #64 У чому різниця між тестуванням та відлагодженням?

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

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

Питання #65 Що таке Безперервне Тестування?

Безперервне Тестування є важливою складовою сучасного підходу Безперервної Розробки, XP (Екстремального програмування) та DevOps.

Маніфест Continuous Testing:

Build – Test – Learn … and Repeat!

Питання #66 Що таке тестування мутацій?

Mutation Testing (Тестування мутацій)   це тестування WhiteBox & Regression Testing, за якого вихідний код програми навмисно мутується, щоб викликати дефект у роботі. Після цього виконуються автоматизовані тестові скрипти, щоб перевірити реакцію програми на ці зміни. Якщо тести після неправильної зміни коду успішно виконуються, значить або код не покритий тестами, або написані тести є неефективними. Критерій, що визначає ефективність набору автоматичних тестів, називається індикатором показника мутації (MSI — Mutation Score Indicator).

Питання #67 Що таке аналіз ризиків у тестуванні ПЗ?

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

Related posts

Leave a Comment

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