Тестування. Фундаментальна теорія
Шановне панство, нарешті переклав статтю українською. Якщо виявили неточності перекладу — прошу в коментарі :) Все буде Україна!
UPD: Запрошую гості на подкаст QA Балачки, а також пропоную замість зайвої феліжанки кави задонатити на дрони для 3 ОШБ, які я збираю власноруч на постійній основі. Прогрес можна відслідковувати в інсті. Дякую, що наближаєте перемогу!
Нещодавно був на співбесіді на Middle QA на проекті, який очевидно перевищує мої можливості. Витратив багато часу на те, що зовсім не знав, і мало часу на повторення простої теорії, а дарма.
Нижче основи основ для повторення перед співбесідою на посаду Trainee та Junior: визначення тестування, якість, верифікація / валідація, цілі, етапи, тест-план, пункти тест-плану, тест-дизайн, техніки тест-дизайну, traceability matrix, тест-кейс, чек-ліст, дефект, error/defect/failure, баг репорт, severity vs priority, рівні тестування, види / типи, підходи до інтеграційного тестування, принципи тестування, статичне та динамічне тестування, дослідницьке / ad-hoc тестування, вимоги, життєвий цикл багу, стадії розробки програмного забезпечення, qa/qc/test engineer, діаграма зв’язків.
Друга частина про методології тут.
Всі зауваження, коригування та доповнення дуже вітаютсья.
Тестування програмного забезпечення — перевірка відповідності між реальною та очікуваною поведінкою програми, що здійснюється на скінченній множині тестів, вибраних у певний спосіб. У більш широкому розумінні, тестування — це одна з методик контролю якості, яка включає активності з планування робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) та аналізу отриманих результатів (Test Analysis).
Якість програмного забезпечення (Software Quality) — це сукупність характеристик програмного забезпечення, які відносяться до його здатності задовольняти встановлені та передбачувані потреби. [Quality management and quality assurance]
Верифікація (verification) — це процес оцінки системи або її компонентів з метою визначення, чи відповідають результати поточного етапу розробки умовам, сформованим на початку цього етапу [IEEE]. Так, верификація включає перевірку, чи досягаються наші цілі, терміни та завдання, визначені на початку поточної фази розробки проекту.
Валідація (validation) — це процес визначення відповідності розроблюваного ПЗ очікуванням і потребам користувача, вимогам до системи [BS7925-1].
Також можна зустріти інший тлумачення:
Процес оцінки відповідності продукту явним вимогам (специфікаціям) називається верифікацією (verification), тоді як оцінка відповідності продукту очікуванням та вимогам користувачів називається валідацією (validation). Також часто можна зустріти таке визначення цих понять:
Валідація — «is this the right specification?».
Верифікація — «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) Environmental needs;
l) Responsibilities;
m) Staffing 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). Зазвичай це створення комбінацій умов (причин) для отримання відповіді від системи (Наслідок). Наприклад, ви перевіряєте можливість додавання клієнта за допомогою певної екранної форми. Для цього вам потрібно буде ввести кілька полів, таких як «Ім’я», «Адреса», «Номер телефону», а потім натиснути кнопку «Додати» — це «Причина». Після натискання кнопки «Додати», система додає клієнта до бази даних і відображає його номер на екрані — це «Наслідок».
• Попереднє вгадування помилок (Error Guessing — EG). Це коли тестувальник використовує свої знання системи та здатність інтерпретувати специфікацію для «вгадування» умов, за яких система може видати помилку.
Наприклад, специфікація стверджує: «користувач повинен ввести код». Тестувальник буде думати: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код?» і так далі. Це і є передбачення помилки.
• Вичерпне тестування (Exhaustive Testing — ET) — це крайній випадок. В межах цієї техніки вам потрібно перевірити всі можливі комбінації вхідних значень, і в принципі, це має виявити всі проблеми. На практиці застосування цього методу неможливе через величезну кількість можливих вхідних значень.
• Таблиця прийняття рішень (decision table) — чудовий інструмент для упорядкування складних бізнес-вимог, які повинні бути реалізовані в продукті. У таблицях рішень наведено набір умов, одночасне виконання яких повинно призвести до певної дії.
• Попарне тестування (Pairwise Testing) — це метод формування наборів тестових даних. Суть попарного тестування полягає у формуванні наборів даних, в яких кожне значення, що тестується, кожного перевірюваного параметра поєднується хоча б один раз з кожним значенням, що тестується, всіх інших перевірюваних параметрів.
Допустимо, ви маєте три вхідні параметри: стать, вік та наявність дітей, на основі яких розраховується певне значення (податок) для людини. Вибираючи значення для тестування, ви маєте ураховувати всі можливі комбінації цих параметрів.
Наприклад, для випадків з полом (чоловічий або жіночий), віком (до 25, від 25 до 60, понад 60) та наявністю дітей (так або ні). Для перевірки правильності розрахунків, можна, звичайно, перебрати всі комбінації значень всіх параметрів:
| № | стать | вік | діти |
|---|---|---|---|
| 1 | чоловік | до 25 | дітей немає |
| 2 | жінка | до 25 | дітей немає |
| 3 | чоловік | дітей немає | |
| 4 | жінка | дітей немає | |
| 5 | чоловік | старше 60 | дітей немає |
| 6 | жінка | старше 60 | дітей немає |
| 7 | чоловік | до 25 | дітей є |
| 8 | жінка | до 25 | дітей є |
| 9 | чоловік | дітей є | |
| 10 | жінка | дітей є | |
| 11 | чоловік | старше 60 | дітей є |
| 12 | жінка | старше 60 | дітей є |
А можна вирішити, що нам не потрібні всі комбінації значень всіх параметрів з усіма, а ми хочемо лише переконатися, що ми перевіримо всі унікальні пари значень параметрів. Так, саме так. Наприклад, з точки зору параметрів статі та віку, ми хочемо переконатися, що точно перевіримо чоловіка до 25 років, чоловіка у віці від 25 до 60 років, чоловіка після 60 років, а також жінку до 25 років, жінку у віці від 25 до 60 років і жінку після 60 років. І точно так само для всіх інших пар параметрів. І таким чином, ми можемо отримати значно менше наборів значень (вони містять усі пари значень, хоча деякі можуть повторюватись):
| № | стать | вік | діти |
|---|---|---|---|
| 1 | чоловік | до 25 | дітей немає |
| 2 | жінка | до 25 | дітей є |
| 3 | чоловік | дітей є | |
| 4 | жінка | дітей є | |
| 5 | чоловік | старше 60 | дітей є |
| 6 | жінка | старше 60 | дітей є |
Такий підхід наближено і складає суть техніки попарного тестування — ми не перевіряємо всі можливі поєднання всіх значень, але перевіряємо всі пари значень.
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)
Види Тестових Сценаріїв:
Тест кейси розділяються за очікуваним результатом на позитивні та негативні:
• Позитивний тест кейс використовує лише коректні дані та перевіряє, що додаток правильно виконав викликану функцію.
• Негативний тест кейс оперує як коректними, так і некоректними даними (принаймні один некоректний параметр) та має на меті перевірити виникнення виключних ситуацій (спрацювання валідаторів). Він також перевіряє, що викликана функція застосунком не виконується при спрацюванні валідатора.
Чек-лист (checklist) — це документ, який описує, що повинно бути протестовано. При цьому чек-лист може мати різний рівень деталізації. Рівень деталізації чек-листа залежить від вимог до звітності, рівня знання продукту співробітниками і складності продукту.
Зазвичай, чек-лист містить лише дії (кроки), без очікуваного результату. Чек-лист менш формалізований, ніж тестовий сценарій. Він є відповідним, коли тестові сценарії є зайвими. Також чек-лист асоціюється з гнучкими підходами до тестування.
Дефект (або баг) — це невідповідність фактичного результату виконання програми очікуваному результату. Дефекти виявляються на етапі тестування програмного забезпечення (ПЗ), коли тестувальник порівнює отримані результати роботи програми (компоненти або дизайну) з очікуваним результатом, який описаний в специфікації вимог.
Error — це помилка користувача, коли він намагається використовувати програму неправильним способом.
Наприклад, введення літер у поля, де потрібно вводити числа (вік, кількість товару і т.д.).
В якісній програмі передбачені такі ситуації, і виводяться повідомлення про помилку (error message) з червоним хрестиком.
Bug (defect) — це помилка розробника (або дизайнера, або іншої особи, яка бере участь у розробці), тобто коли в програмі щось йде не так, як планувалося, і програма виходить з-під контролю. Наприклад, коли немає жодного контролю над введенням користувача, в результаті неправильні дані можуть спричинити збої або інші непередбачувані проблеми у роботі програми. Або всередині програма побудоавана так, що з самого початку не відповідає очікуванням.
Failure — це сбій (не обов’язково апаратний), який виникає в роботі компонента, програми або системи. Так, існують дефекти, які приводять до сбоїв (A defect caused the failure) і існують такі, які не призводять. UI-дефекти, наприклад. Але апаратний збій, незалежний від програмного забезпечення, також є 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) Ім’я співробітника, призначеного для вирішення проблеми
Середовище (Environment)
ОС / Сервісний пак і т.д. / Браузер + версія / ... Інформація про середовище, на якому була виявлена помилка: операційна система, сервісний пак, для веб-тестування — назва і версія браузера і т.д.
...
Опис
Кроки для відтворення (Steps to Reproduce) Кроки, за якими можна легко відтворити ситуацію, що призвела до помилки.
Фактичний результат (Result) Результат, отриманий після пройдених кроків для відтворення
Очікуваний результат (Expected Result) Очікуваний правильний результат
Додатково (Additional)
Прикріплений файл (Attachment) Файл з логами, знімком екрана або будь-яким іншим документом, який може допомогти уточнити причину помилки або вказати на шлях вирішення проблеми.
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)
• Тестування користувацького інтерфейсу (GUI 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)
Функціональне тестування розглядає передбачену заздалегідь поведінку і базується на аналізі специфікацій функціональності компонента або системи в цілому.
Тестування користувацького інтерфейсу (GUI Testing) — це функціональна перевірка інтерфейсу на відповідність вимогам, таким як розмір, шрифт, кольори, послідовність дій (consistent behavior).
Тестування безпеки — це стратегія тестування, що використовується для перевірки безпеки системи, а також аналізу ризиків, пов’язаних з забезпеченням цілісного підходу до захисту застосунку від хакерських атак, вірусів, несанкціонованого доступу до конфіденційної інформації.
Тестування взаємодії (Interoperability Testing) — це функціональне тестування, яке перевіряє здатність застосунку взаємодіяти з одним або кількома компонентами або системами. Це включає тестування сумісності (compatibility testing) і інтеграційне тестування.
Тестування навантаження (Performance and Load Testing) — це автоматизоване тестування, яке імітує роботу певної кількості бізнес-користувачів на загальному (спільному для них) ресурсі.
Тестування на стрес (Stress Testing) дозволяє перевірити, наскільки працездатним є застосунок і система в цілому в умовах стресу, а також оцінити здатність системи до відновлення, тобто повернення до нормального стану після припинення впливу стресового навантаження. В даному контексті стресом може бути збільшення інтенсивності виконання операцій до дуже високих значень або аварійна зміна конфігурації сервера. Також одним із завдань під час стрес-тестування може бути оцінка деградації продуктивності, тому цілі стрес-тестування можуть перекриватися з цілями тестування продуктивності.
Обсягове тестування (Volume Testing) має на меті отримання оцінки продуктивності при збільшенні обсягів даних у базі даних застосунку.
Тестування стабільності або надійності (Stability / Reliability Testing) має на меті перевірку працездатності додатка під час тривалого (багатогодинного) тестування з середнім рівнем навантаження.
Тестування встановлення (Installation Testing) спрямоване на перевірку успішної установки і налаштування, а також оновлення або видалення програмного забезпечення.
Тестування зручності використання (Usability Testing) — це метод тестування, спрямований на встановлення ступеня зручності використання, навчаності, зрозумілості та привабливості для користувачів розроблюваного продукту в контексті визначених умов. Сюди також входять:
User eXperience (UX) — це враження, яке відчуває користувач під час використання цифрового продукту, тоді як User Interface (UI) — це інтерфейс, який дозволяє взаємодіяти «користувач — веб-ресурс».
Тестування на відмову та відновлення (Failover and Recovery Testing) перевіряє тестований продукт з точки зору здатності протистояти і успішно відновлюватися після можливних відмов, спричинених помилками програмного забезпечення, відмовами обладнання або проблемами зв’язку (наприклад, відмова мережі). Метою даного виду тестування є перевірка систем відновлення (або дублювання основного функціоналу систем), які у випадку виникнення відмов забезпечують збереженість та цілісність даних тестованого продукту.
Конфігураційне тестування (Configuration Testing) — спеціальний вид тестування, спрямований на перевірку роботи програмного забезпечення за різних конфігурацій системи (зазначених платформах, підтримуваних драйверах, за різних конфігурацій комп’ютерів тощо).
Димове (Smoke) тестування розглядається як короткий цикл тестів, що виконується для підтвердження того, що після збірки коду (нового або виправленого) встановлювана програма запускається і виконує основні функції.
Регресійне тестування — це вид тестування, спрямований на перевірку змін, зроблених у програмі або навколишньому середовищі (виправлення дефекту, злиття коду, міграція на іншу операційну систему, базу даних, веб-сервер або сервер застосунку), щоб підтвердити факт, що попередні функціональності працюють так само, як раніше. Регресійними можуть бути як функціональні, так і нефункціональні тести.
Повторне тестування — це процес тестування, під час якого виконуються тестові сценарії, що виявили помилки під час останнього запуску, з метою підтвердження успішного виправлення цих помилок.
В чьому полягає різниця між regression testing і re-testing?
Повторне тестування (re-testing) — перевіряється виправлення помилок (багів).
Регресійне тестування (Regression testing) — перевірка того, що виправлення помилок, а також будь-які зміни в коді додатку не мають впливу на інші модулі програмного забезпечення і не викликають нових помилок (багів).
Тестування збірки (Build Verification Test) — це тестування, спрямоване на визначення відповідності випущеної версії критеріям якості для подальшого початку тестування. За своїми цілями, тестування збірки є аналогом Димового Тестування, спрямованого на перевірку нової версії перед подальшим тестуванням або використанням. Воно може проникати глибше, в залежності від вимог до якості випущеної версії.
Санітарне тестування — це спрямоване тестування, яке достатньо для доведення того, що конкретна функція працює відповідно до вимог, зазначених у специфікації. Є підмножиною регресійного тестування. Воно використовується для перевірки працездатності певної частини програмного застосунку після внесених змін у цю частину або в навколишнє середовище. Зазвичай його виконують вручну.
Підходи до інтеграційного тестування:
• Знизу вгору (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 context dependent)
Тестування виконується по-різному залежно від контексту. Наприклад, програмне забезпечення, в якому безпека має критичне значення, тестується інакше, ніж сайт електронної комерції.
Принцип 7 — Омана щодо відсутності помилок (Absence-of-errors fallacy)
Виявлення та виправлення дефектів не допоможуть, якщо створена система не відповідає користувачеві і не задовольняє його очікування та потреби.
Статичне та динамічне тестування
Статичне тестування відрізняється від динамічного тим, що воно проводиться без запуску програмного коду продукту. Тестування виконується шляхом аналізу програмного коду (code review) або скомпільованого коду. Аналіз може проводитися як вручну, так і з використанням спеціальних інструментальних засобів. Метою аналізу є виявлення помилок і потенційних проблем в продукті на ранніх етапах. До статичного тестування також відноситься тестування специфікацій та іншої документації.
Дослідницьке / ad-hoc тестування
Найпростіше визначення дослідницького тестування — це розробка та виконання тестів у той самий час. Це є протилежністю сценарного підходу (з його попередньо визначеними процедурами тестування, незалежно від того, чи вони виконуються вручну чи автоматизовано). Дослідницькі тести, на відміну від сценарних тестів, не визначені заздалегідь і не виконуються з точним дотриманням плану.
Різниця між ad hoc та дослідницьким тестуванням полягає в тому, що в теорії ad hoc тестування може здійснюватися ким завгодно, тоді як для проведення дослідницького тестування необхідні вміння та володіння певними техніками. Зверніть увагу, що ці певні техніки включають не тільки техніки тестування.
Вимоги — це специфікація (опис) того, що має бути реалізовано.
Вимоги описують те, що необхідно реалізувати, без деталізації технічного аспекту рішення. Вони визначають «що», а не «як».
Вимоги до вимог:
• Коректність
• Однозначність
• Повнота набору вимог
• Відсутність суперечностей у наборі вимог
• Перевіряемість (здатність до тестування)
• Трасованість
• Зрозумілість
Життєвий цикл дефекту (бага)
Етапи розробки програмного забезпечення (ПЗ) — це етапи, які проходять розробники програмного забезпечення, перш ніж програма стає доступною для широкого кола користувачів. Розробка програмного забезпечення починається з першого етапу — етапу «пре-альфа», і продовжується через різні етапи, на яких продукт вдосконалюється та модернізується. Завершальним етапом цього процесу є випуск на ринок остаточної версії програмного забезпечення — «релізу для широкого загалу користувачів».
Програмний продукт проходить наступні етапи:
• Аналіз вимог до проєкту.
• Проєктування.
• Реалізація.
• Тестування продукту.
• Впровадження та підтримка.
Кожній стадії розробки програмного забезпечення присвоюється певний порядковий номер. Крім того, кожна стадія має свою власну назву, яка відображає готовність продукту на цьому етапі.
Життєвий цикл розробки програмного забезпечення:
• Збір вимог
• Планування і дизайн
• Розробка/імплементація
• Тестування
• Деплоймент
• Підтримка
Життєвий цикл тестування програмного забезпечення:
• Пре-альфа
• Альфа
• Бета
• Кандидат на реліз
• Реліз
• Післярелізний
QA/QC/Test Engineer
Отже, ми можемо побудувати модель ієрархії процесів забезпечення якості: Тестування — частина Контролю якості (QC). QC — частина Забезпечення якості (QA).
Діаграма зв’язків — це інструмент управління якістю, що базується на визначенні логічних зв’язків між різними даними. Цей інструмент використовується для встановлення взаємозв’язків між причинами та наслідками в досліджуваній проблемі.
Джерела: www.protesting.ru, bugscatcher.net, qalight.com.ua, thinkingintests.wordpress.com, книга ISTQB, www.quizful.net, bugsclock.blogspot.com, www.zeelabs.com, devopswiki.net, hvorostovoz.blogspot.com.
Ресурси рекомендовані в коментарях Sofiya Novachenko: istqbexamcertification.com www.testingexcellence.com
Mikhail Onipko
Sofiya Novachenko
Taras Fedas
Serhii Khutornyi
Юлія Новікова
Ksenija Taradajka
Олена Миколюк
Serguéi
Ostap Hapyak
Yuriy Bondarenko
Serhii Abdiushev
Roman Stas
Olha Morhun
Dima Verdysh
kyrylogarmash
Serhii Sryvkin
Андрій Рибак
Dmytro Kovalchuk
wife of an acrobat
Олег Дорожко
Ігор Котельников
Марія Нагул
Vitalii Voloboiev
Ювженко Денис
Егор Альтшулер
Taras Voloshenko
Сергей Маршалов
Георгий Чупахин
Сашко Сливка
Oleksii Mishko
Евгения Сабада
Котэ
Фрэнк Сайдботтом
Luci
Владимир Дзикевич
Oleh Plyhan
Sergii Alekseev
Sergei Martyniuk
Рабингранат Кагор
Eugene Stogniy
Oleksandr Panchenko
Anastasiia Drachuk
Igor Moroz
Oleg Zarevych
Romania Derzhylo
Михаил Кузьмин
Ivan Yeremenko
Pavel Chausov
Pilar Mirto
Vitaliy Zakharkin
Alyoshina Yuliya
Olga Orlenko
Olga Orlenko
Oleksandra B
Oleksii Ostash
Ігор Сліпченко
Ruslan Krucheniuk
Viktor Aleshchenko
Mikhail Shmagailo
Oleksii Pavlov
Алексей Кравчук
Igor Berestiannyi
Evgeny Filon
Наталья Шматенко
Ярослав Ларионов
Антон Шамрай
Александр Корж
Alex Lychak
Лилёчек Червона
Котэ гуляющее само по себэ
Nastia K
Volodymyr
Rostyslav Gnatovsky
Helen Zamora
Julia Voloshka
Vitalina Gaburak
Роман Бурко
Anna Kalinichenko
Anna Kalinichenko
Татьяна Ходаковская-Драченко
Евгений Епишев
Array
Serhii Maksymchuk
Alexey Korobko
Elizaveta Balenko
Globalistineta Kovalenko
Ilona H
Andrii Zatullo
Денис Крупченко
Iryna Onyshchuk
Сергей Левченко
Світлана Новицька
Oleksandra Perekhrest
Антон Пименов
Michael Vitiuk
Александр Турков
Sergii Semenov
Евгений Москаленко
Hennadii Mishchevskyi
Петро
Марат Карамян
Егор Павлючков
Tymur Daudov
Александр Горбенко
Denys Sergiichuk
Alexei Vinogradov
Andrey Ostapenko
Ihor Bodnar
Татьяна Логвиненко
Артём Москалец
Tim Tretyak
Дмитрий Накидень
Karyna Holubova
Max Krasilnik
Олександр Терешков
Андрей Лысенко
Larisa Timiș
Alexander Azarov
Victor Belugin
Yevhenii Kundii
Khrystyna Shumska
Igor Lytvynenko
Tania Slukhai
Victoria Diachenko
Vitalii Zadyraka
Найкращі коментарі пропустити