Category: Тестування ПЗ

До цієї групи зазвичай відносять:

• Підтверджувальне тестування – Confirmation testing (ISQTB)
• Регресійне тестування – Regression testing (ISTQB)
• Димове тестування – Smoke testing
• Тестування працездатності – Sanity testing
• Тестування супроводу – Maintenance testing

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

Підтверджувальне тестування та Регресійне тестування

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

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

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

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

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

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

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

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

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

Методи регресійного тестування

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

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

Вибір тестів для регресії

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

Ефективний набір регресійних тестів можна створити, вибравши такі типи тестів:

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

Позитивне / Негативне тестування

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

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

Автоматизація регресії

Selenium – популярна платформа з відкритим кодом, яка використовується для автоматизації веб-браузерів. Його ключовий компонент, Selenium WebDriver, надає простий API для взаємодії з веб-елементами, що дозволяє розробникам автоматизувати такі завдання, як натискання кнопок, заповнення форм і навігація сторінками. Завдяки підтримці кількох мов програмування та браузерів Selenium широко використовується для веб-тестування та автоматизації.

Watir – що розшифровується як Web Application Testing in Ruby, є системою тестування з відкритим вихідним кодом, яка фокусується на автоматизації веб-браузерів за допомогою мови програмування Ruby. Він пропонує зручний та інтуїтивно зрозумілий API, який використовує виразний синтаксис Ruby для взаємодії з веб-елементами та імітації дій користувача, таких як натискання кнопок і заповнення форм. Ключова відмінність Watir полягає в його повній інтеграції з Ruby, що робить його улюбленим вибором для тестувальників і розробників, які віддають перевагу Ruby.

IBM DevOps Test UI (Ra­­­­tional Functional Tester) – це автоматизований інструмент функціонального та регресійного тестування для графічного інтерфейсу користувача та тестування на основі даних. Він підтримує низку програм, включаючи веб-додатки, .Net, Java, Siebel, SAP тощо. Платний.

Katalon Studio – це рішення для автоматизованого тестування, яке використовує фреймворки Selenium і Appium для веб-тестування, тестування API, мобільних пристроїв і комп’ютерів. Має обмежену безкоштовну версію.

TestComplete –  розроблений компанією SmartBear Software, є автоматизованим інструментом тестування інтерфейсу користувача, який дозволяє створювати автоматизовані функціональні тести для настільних, веб- та мобільних додатків. Платний.

Smoke testing та Sanity testing

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

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

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

Наприклад, якщо функція, що відповідає за розрахунки видає результат 2*2=3, тоді наврядчи є сенс тестувати більш складні операції, такі як розрахунок складних відсотків, наприклад.

Smoke	Sanity
Перевіряє стабільність нової збірки	Перевіряє стабільність нових функцій або змін коду в існуючій збірці
Охоплює ключові функції наскрізними перевірками	Охоплює певні модулі, у код яких внесено зміни
Може виконуватися як тестувальниками, так і розробниками	Зазвичай виконується тестувальниками
Часто визначаються як підтип приймального тестування (є позиції, що можна відносити до регресійного тестування)	Підтип регресійного тестування

В цьому відео поговоримо про:
00:00 Типи тестування пов’язані зі змінами
03:00 Підтверджувальне та регресійне тестування
06:30 Методи регресійного тестування
08:16 Вибір тестів для регресії
09:38 Позитивне та негативне тестування (ліричний відступ)
10:51 Автоматизація регресії
15:59 Smoke testing та Sanity testing

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

Вгадування помилок (Error guessing)

Вгадування помилок — це техніка, яка використовується для передбачення появи помилок, дефектів і збоїв на основі знань тестувальника, зокрема:

• Як програма працювала в минулому
• Якого типу помилки, як правило, допускаються
• Збої, які виникли в інших програмах

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

Як додаток працював у минулому?

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

Які помилки зазвичай виявляють?

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

Які збої виникли в інших програмах?

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

Підводні камені

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

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

Вгадування помилок буде ефективним, якщо:

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

Дослідницьке тестування (Exploratory testing)

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

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

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

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

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

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

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

1. Створіть таксономію помилок (класифікацію)	• Класифікуйте загальні типи несправностей, виявлених у минулих проєктах • Проаналізуйте першопричину проблем або несправностей • Знайдіть ризики та розробіть ідеї для тестування програми.
2. Тестовий чартер	• Що і як тестувати • Тестові ідеї є відправною точкою дослідницького тестування • Тестовий чартер допомагає визначити, як кінцевий користувач може використовувати систему
3. Інтервали часу	• Цей метод передбачає спільну роботу пари тестувальників не менше 90 хвилин • У цьому 90-хвилинному сеансі не повинно бути перерв • Таймбокс можна продовжити або скоротити на 45 хвилин • Цей сеанс заохочує тестувальників реагувати на відповідь системи
4. Перегляд та аналіз результатів	• Оцінка дефектів • Навчання з тестування • Аналіз зон покриття • Зведення вихідних результатів • Порівняйте результати з чартером

Тестування засноване на контрольних списках (Check-list based teting)

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

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

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

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

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

За відсутності детальних тестових кейсів тестування на основі контрольного списку може надати вказівки та певний ступінь узгодженості для тестування.

В цьому відео поговоримо про:
00:15 Техніки засновані на досвіді
02:28 Вгадування помилок
07:49 Дослідницьке тестування
13:57 Тестування на основі контрольного списку

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

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

Зручність супроводу

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

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

Можливість багаторазового використання (Reusability) — ступінь, в якій актив може бути використаний в декількох системах чи при створенні інших активів.

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

Можливість модифікацій (Modifiability) — ступінь простоти ефективної та раціональної зміни продукту або системи без додавання дефектів та зниження якості продукта.

Напрямки тестування:

• заплановані вдосконалення
• коригування та екстрені зміни
• зміни робочого середовища (наприклад, заплановані оновлення операційної системи або бази даних)
• оновлення програмного забезпечення COTS.

Maintainability (Зручність супроводу) and Maintenance (супровід/підтримка)

Не слід плутати maintainability testing (тестування зручності супроводу) та maintenance testing (тестування супроводу). У тестуванні супроводу причиною тестування є зміна системи. У тестуванні зручності супроводу причиною тестування є визначення того, наскільки добре систему можна оновлювати, змінювати та підтримувати.

Maintenance testing (Тестування супроводу)

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

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

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

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

Обсяг технічного обслуговування залежить від:

• Ступінь ризику зміни, наприклад, ступінь зв’язку зміненої області програмного забезпечення з іншими компонентами чи системами
• Розмір існуючої системи
• Розмір зміни

Тригери супроводу:

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

Impact analysis (Аналіз впливу)

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

Аналіз впливу також може допомогти визначити вплив зміни на існуючі тести. Побічні ефекти та уражені області в системі потрібно перевірити на регресії.

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

Аналіз впливу може бути складним, якщо:

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

Портативність

Портативність (Portability) включає можливість адаптації, можливість встановлення, можливість заміни.

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

Можливість встановлення (Installability) — ступінь простоти ефективного, раціонального, успішного встановлення або видалення продукта або системи в заданому середовищі.

Можливість заміни (Replaceability) — здатність продукта замінити інший конкретний програмний продукт для досягнення тих самих цілей в тих же умовах.

Тестування портативності

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

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

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

В цьому відео поговоримо про:
02:10 Тестування зручності супроводу (Maintainability testing)
09:16 Тестування супроводу (Maintenance testing)
15:05 Аналіз впливу (Impact analysis)
17:35 Тестування портативності (Portability testing)