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

Ціль і зміст тестового плану

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

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

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

Заходи з планування тестування можуть включати наступне:

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

Приблизний зміст тестового плану

1. Ідентифікатор плану тестування
2. Вступ
3. Тестові елементи
4. Функції для перевірки
5. Функції, які не підлягають тестуванню
6. Підхід
7. Критерії проходження/непроходження
8. Критерії призупинення/відновлення
9. Потреби середовища
10. Потреби в кадрах і навчанні
11. Обов’язки
12. Розклад
13. Планування ризиків і непередбачених ситуацій
14. Дозволи
15. Глосарій

Стратегія тестування та підхід

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

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

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

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

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

Критерії входу та виходу

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

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

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

Типові критерії входу включають:

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

Типові критерії виходу включають:

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

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

Техніки оцінки

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

Оцінка на основі коефіцієнтів	У цій техніці, заснованій на показниках, цифри збираються з попередніх проєктів в організації, що дає змогу отримати «стандартні» коефіцієнти для подібних проєктів. Коефіцієнти власних проєктів організації (наприклад, взяті з історичних даних) зазвичай є найкращим джерелом для використання в процесі оцінки. Потім ці стандартні співвідношення можна використовувати для оцінки зусиль тестування для нового проєкту. Наприклад, якщо в попередньому проєкті співвідношення зусиль на розробку та тестування було 3:2, а в поточному проєкті зусилля на розробку очікується в 600 людино-днів, зусилля на тестування можна оцінити як 400 людино-днів.
Екстраполяція	У цьому методі, заснованому на показниках, вимірювання проводяться якомога раніше в поточному проєкті для збору даних. Маючи достатньо спостережень, зусилля, необхідні для роботи, що залишилася, можна приблизно оцінити шляхом екстраполяції цих даних (зазвичай шляхом застосування математичної моделі). Цей метод дуже підходить для ітераційних SDLC. Наприклад, команда може екстраполювати тестові зусилля в майбутній ітерації як усереднене значення з останніх трьох ітерацій.
Delphi	У цій ітераційній експертній техніці експерти роблять оцінки на основі досвіду. Кожен експерт окремо оцінює зусилля. Результати збираються, і якщо є відхилення, що виходять за межі узгоджених меж, експерти обговорюють свої поточні оцінки. Потім кожного експерта просять зробити нову оцінку на основі цього відгуку, знову окремо. Цей процес повторюється, поки не буде досягнуто консенсусу. Planning Poker — це варіант Wideband Delphi, який зазвичай використовується в розробці програмного забезпечення Agile. У Planning Poker оцінки зазвичай робляться за допомогою карток із числами, які представляють розмір зусиль.
Трибальна оцінка	У цій експертній методиці експерти роблять три оцінки: найбільш оптимістичну оцінку (a), найбільш ймовірну оцінку (m) і найбільш песимістичну оцінку (b). Остаточна оцінка (E) є їх середнім зваженим арифметичним. У найпопулярнішому варіанті цієї методики оцінка обчислюється як E = (a + 4*m + b) / 6. Перевагою цієї методики є те, що вона дозволяє експертам розрахувати похибку вимірювання: SD = (b – a) / 6. Наприклад, якщо оцінки (в людино-годинах) такі: a=6, m=9 і b=18, тоді остаточна оцінка становить 10±2 людино-години (тобто від 8 до 12 людино-годин), оскільки E = (6 + 4*9 + 18) / 6 = 10 і SD = (18 – 6) / 6 = 2.

Тестові набори (Test Suites)

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

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

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

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

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

Пріоритезація тест-кейсів

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

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

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

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

В ідеалі тестові кейси повинні бути впорядковані для виконання на основі їх рівнів пріоритету, використовуючи, наприклад, одну із згаданих вище стратегій визначення пріоритетів.

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

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

Тестова піраміда

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

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

Кількість і назва шарів може відрізнятися. Наприклад, оригінальна модель тестової піраміди (Кон 2009) визначає три рівні: «модульні тести», «сервісні тести» та «тести інтерфейсу користувача». Інша популярна модель визначає тести компонентів, тести інтеграції (інтеграції компонентів) і наскрізні тести. Також можна використовувати інші рівні тестування.

Тетові квадранти

Тестові квадранти, визначені Брайаном Маріком (Marick 2003, Crispin 2008), групують рівні тестування з відповідними типами тестування, діяльністю, технікою тестування та робочими продуктами в розробці програмного забезпечення Agile.

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

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

• Квадрант Q1 (звернення до технологій, підтримка команди). Цей квадрант містить компонентні тести та тести інтеграції компонентів. Ці тести мають бути автоматизовані та включені в процес CI.
• Квадрант Q2 (бізнес, підтримка команди). Цей квадрант містить функціональні тести, тести історій користувача, прототипи користувацького досвіду, тестування API та моделювання. Ці тести перевіряють критерії прийнятності та можуть бути ручними або автоматизованими.
• Квадрант Q3 (бізнес, критика продукту). Цей квадрант містить дослідницьке тестування, тестування зручності використання, користувацьке приймальне тестування. Ці тести орієнтовані на користувача і часто ручні.
• Квадрант Q4 (розгляд технології, критика продукту). Цей квадрант містить димові тести та нефункціональні тести (крім тестів зручності використання). Ці тести часто автоматизовані.

В цьому відео поговоримо про тестовий план і планування:
00:00 Ціль і зміст тестового плану
05:20 Стратегія тестування та підхід
10:16 Критерії входу та виходу
14:34 Техніки оцінки
21:18 Тестові набори (Test Suites)
22:54 Пріоритезація тест-кейсів
26:18 Тестова піраміда
28:12 Тетові квадранти

Тест-датасет (Test Data) – це набір даних, які використовуються для виконання тестів під час тестуванна ПЗ. Ці дані вводяться у тести для перевірки різних аспектів програмного продукту, таких як правильність роботи, відповідність вимогам, ефективність та інші характеристики. Тест-датасети можуть включати в себе різні види даних, такі як числа, рядки, дати, файли, зображення тощо, в залежності від конкретного тестового сценарію. Основні аспекти тест-датасетів:

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

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

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

Числові дані	◦ Цілі числа. ◦ Дійсні (з плаваючою комою) числа. ◦ Великі та малі значення для перевірки меж та роботи з екстремальними значеннями.
Рядкові дані	◦ Тексти різної довжини. ◦ Спеціальні символи та символи з різних алфавітів. ◦ Дані з пробілами або іншими спеціальними символами.
Дані дат та часу	◦ Дати з різних періодів (сьогодні, минуле, майбутнє). ◦ Різні формати дат та часу. ◦ Дані, які включають в себе зміну часового поясу або літній/зимовий час.
Дані для тестів граничних значень	Границі допустимих значень параметрів, межі допустимого діапазону.
Дані для тестів на введення	◦ Коректні дані, щоб перевірити правильність обробки валідних вхідних даних. ◦ Некоректні дані, щоб перевірити обробку невалідних вхідних даних.
Дані для тестів на функціональність	◦ Вхідні дані, що відображають різні сценарії використання продукту. ◦ Дані, які перевіряють взаємодію з іншими частинами системи.
Дані для тестів на продуктивність	◦ Великі обсяги даних для перевірки ефективності та завантажувальної здатності.
Дані для тестів безпеки	◦ Дані, що можуть викликати помилки безпеки (SQL-ін’єкції, переповнення буфера тощо). ◦ Дані для тестування доступу до обмежених ресурсів.
Дані для тестування інтерфейсів	Дані для введення через різні інтерфейси (веб, мобільний, API).
Дані для тестів на відновлення	Дані, які моделюють втрату з’єднання чи аварійне вимкнення системи.

Переваги

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

Реалістичність тестів	Тест-датасети можуть відображати реальні умови використання продукту, допомагаючи впевнитися, що тести проводяться в умовах, близьких до реального використання.
Покриття різноманітних сценаріїв	Тест-датасети дозволяють вам покривати різноманітні сценарії використання, включаючи граничні умови, неправильні вхідні дані та інші аспекти, що сприяє високій якості тестування.
Впевненість в правильності результатів	З використанням тест-датасетів можна більш впевнено стверджувати, що результати тестів є об’єктивними і релевантними для реального використання продукту.
Автоматизація тестування	Тест-датасети є важливим елементом автоматизованих тестів. Вони дозволяють легко повторювати тести з різними вхідними даними та аналізувати результати.
Спрощення створення тестів	Застосування тест-датасетів полегшує створення тестових сценаріїв. Замість ручного введення великої кількості даних можна використовувати готові тест-датасети або автоматизовані генератори тестових даних.
Прискорення процесу тестування	Завдяки попередньому підготовленню тест-датасетів можна ефективно виконувати тести та отримувати результати швидше, що важливо для процесу Continuous Integration / Continuous Delivery (CI/CD).
Масштабованість тестового процесу	Тест-датасети дозволяють розширювати обсяг тестів і визначати, як продукт веде себе при великій кількості різних вхідних даних.
Покращення виявлення помилок	Тест-датасети допомагають виявляти різні види помилок, такі як проблеми з обробкою великих обсягів даних, некоректними вхідними даними та інших.

Складнощі

Хоча використання тест-датасетів має численні переваги, в тому числі покращення реалістичності тестів та ефективності тестового процесу, також можуть виникати деякі складнощі.

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

Інструменти

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

Excel або інші електронні таблиці	Електронні таблиці, такі як Microsoft Excel чи Google Sheets, можуть бути використані для створення і редагування тест-датасетів. Вони надають зручний інтерфейс та можливості часткової автоматизації завдяки макросам та формулам.
Генератори тестових даних	Існують спеціальні інструменти для генерації випадкових чи реалістичних тестових даних. Приклади цих інструментів включають Faker (для різних мов програмування), Mockaroo, DataFactory та інші.
SQL-запити	Для тестування можна використовувати SQL-запити для створення, оновлення чи видалення тестових даних. Це може бути корисно, зокрема, при тестуванні систем, що використовують бази даних.
API для генерації даних	Деякі компанії та сервіси надають API для генерації тестових даних. За допомогою таких API можна отримати реалістичні дані для тестування.
Спеціалізовані інструменти для тестування баз даних	Деякі інструменти, такі як DbUnit для Java чи tSQLt для Microsoft SQL Server, можуть допомагати в підготовці та управлінні тестовими даними в базах даних.
Середовища розробки та інструменти тестування	Інколи тестові дані можна підготовити за допомогою розробницьких середовищ та інструментів тестування, таких як Eclipse, Microsoft Visual Studio, Atom, SlickEdit.

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

В цьому відео поговоримо про:
00:00 Тест-датасети
06:13 Переваги
09:56 Складнощі
14:15 Інструменти

Логи тестування (Test Logs) – це записи або документація, яка фіксує події, результати та іншу інформацію, пов’язану з процесом тестування програмного забезпечення. Ця інформація може включати в себе різні аспекти тестування, такі як виконані тести, отримані результати, помилки, виправлення помилок та інші аспекти тестового циклу.

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

Логи тестування (Test Logs) можуть містити різноманітну інформацію, залежно від конкретних потреб проєкту та виду тестування. Однак типові елементи інформації, які часто включаються в логи тестування, включають:

Дата і час	Фіксація часу виконання тестів допомагає відстежувати хронологію подій та прогресу тестування.
Опис тесту	Інформація про конкретний тест, включаючи його мету, вхідні дані, очікувані результати та інші відомості, що характеризують тест-кейс.
Результат тесту	Запис про те, чи пройшов тест успішно, чи відбулася помилка. Якщо тест виявив помилку, лог може включати деталі про цю помилку.
Стан системи	Інформація про стан системи або середовища тестування на момент виконання тесту. Це може включати версії програмного забезпечення, конфігурації середовища та інші деталі.
Відомості про виконавця	Інформація про того, хто виконував тест, може бути корисною для відстеження виконавчого процесу та вирішення питань, пов’язаних з виконанням конкретних тестів.
Логи подій	Записи подій або дій, які відбулися під час виконання тесту, такі як введення, виведення, обробка помилок тощо.
Версії програмного забезпечення	Інформація про версії компонентів програмного забезпечення, які тестувалися, може бути важливою для визначення сумісності та виявлення проблем.

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

Переваги

Використання логів тестування має кілька значущих переваг:

Відстеження прогресу	Логи тестування дозволяють команді відстежувати прогрес тестування. Записи про виконані тести, їхні результати та стан системи допомагають визначити, наскільки продуктивно використовуються ресурси для тестування.
Виявлення і аналіз помилок	Якщо тест виявляє помилку або несправність, логи надають деталі про цю проблему. Це сприяє швидкому виявленню, відлагодженню та виправленню помилок.
Документація тестування	Логи служать важливим джерелом документації тестового процесу. Вони фіксують введені тести, очікувані результати, виявлені помилки та інші важливі аспекти, що характеризують якість продукту.
Верифікація відповідності до вимог	Логи допомагають перевірити, чи відповідає програмний продукт встановленим вимогам. Вони можуть включати в себе результати виконання тестів, що вказують на те, чи функціональні вимоги виконуються належним чином.
Покриття тестування	Аналіз логів дозволяє визначити, які частини програмного продукту були покриті тестами, а які ще потребують уваги. Це важливо для забезпечення високої якості продукту та визначення стратегій тестування.
Спрощення співпраці в команді	Логи є ефективним інструментом для обміну інформацією між членами команди тестування та розробниками. Вони надають об’єктивну та конкретну інформацію про стан продукту, що полегшує взаємодію та вирішення питань.
Автоматизація та реалізація CI/CD	Логи є необхідною частиною автоматизованих тестів і процесів Continuous Integration / Continuous Delivery (CI/CD). Вони дозволяють визначити стабільність тестів та автоматизованих процесів.

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

Складнощі

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

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

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

В цьому відео поговоримо про:
00:00 Тестові логи
04:24 Переваги
07:03 Складнощі