Month: October 2025

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

Іншими словами — це відповіді на запитання:

• Що має робити програма?
• Як вона повинна працювати?
• Для кого вона створюється і в яких умовах буде працювати?

Основні цілі вимог

1. Зрозуміти потреби користувача
   • Визначити, які проблеми треба вирішити
   • Які задачі автоматизувати або спростити
2. Служити основою для розробки
   • Вимоги — це вихідна точка для розробників, дизайнерів, тестувальників і менеджерів
3. Зменшити ризики непорозумінь
   • Узгоджений документ із вимогами запобігає суперечкам і повторній розробці
4. Забезпечити можливість тестування
   • Вимоги повинні бути перевірюваними: по ним створюються тест-кейси

Класифікація вимог

1. Функціональні вимоги (Functional Requirements)

Це вимоги, які описують конкретну поведінку або функціональність системи.

Вони відповідають на питання: “Що повинна робити система?”

Приклади:

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

2. Нефункціональні вимоги (Non-Functional Requirements)

Ці вимоги описують якість системи, як вона виконує свої функції.

Вони відповідають на питання: “ЯК повинна працювати система?”

Приклади:

• Система повинна обробляти не менше 500 запитів на секунду.
• Інтерфейс має бути доступним для людей із вадами зору (відповідність WCAG).
• Додаток має працювати офлайн.

Сюди входять:

• Продуктивність
• Безпека
• Масштабованість
• Надійність
• Зручність інтерфейсу (usability)
• Сумісність із платформами (Windows, iOS, Android тощо)

3. Бізнес-вимоги (Business Requirements)

Це високорівневі цілі проєкту або продукту з погляду бізнесу.

Приклади:

• Надати клієнтам можливість купувати квитки онлайн.
• Оптимізувати витрати на обробку заявок на 20% протягом півроку.
• Зменшити кількість дзвінків до служби підтримки.

4. Системні вимоги (System Requirements)

Це вимоги до технічного середовища, в якому працюватиме система.

Приклади:

• Підтримка ОС: Windows 11, Ubuntu 22.04.
• Робота на сервері з мінімум 8 GB RAM та 4 CPU.
• Підключення до бази даних PostgreSQL.

Як формуються вимоги?

1. Збір вимог (Requirements Elicitation)

Це процес збору інформації про те, що потрібно системі. Залучаються:

• Замовники
• Кінцеві користувачі
• Бізнес-аналітики
• Архітектори / розробники

Методи:

• Інтерв’ю
• Опитування
• Аналіз існуючої системи
• Спостереження
• Воркшопи
• Аналіз конкурентів

2. Аналіз і документування

Вимоги формулюються в структурованому вигляді:

• У вигляді документа SRS (Software Requirements Specification)
• У вигляді User Stories (у Agile-проєктах)
• У вигляді Use Case діаграм або UML-діаграм

3. Перевірка та валідація

Потрібно переконатися, що:

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

Хто бере участь у роботі з вимогами?

Роль	Що робить
Бізнес-аналітик	Збирає та формулює вимоги
Product Owner	Визначає пріоритети функцій (у Scrum)
Розробник	Оцінює складність реалізації
Тестувальник (QA)	Готує тест-кейси на основі вимог
Архітектор	Визначає, як технічно реалізувати вимоги

Як виглядає документ з вимогами (SRS)?

Типовий зміст:

1. Вступ
2. Опис системи
3. Функціональні вимоги
4. Нефункціональні вимоги
5. Інтерфейси користувача
6. Обмеження
7. Глосарій термінів

Якими мають бути хороші вимоги?

Вимоги повинні бути:

• Чіткими — без двозначностей
• Повними — охоплювати всі сценарії
• Такими, що можна перевірити — можна протестувати
• Послідовними — не суперечити одна одній
• Зрозумілими — написаними зрозумілою мовою

Приклад вимоги:

User Story (Agile формат):

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

Acceptance Criteria:

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

Висновок

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

• чи отримає замовник те, що очікує;
• чи зможе команда реалізувати продукт у строки;
• чи буде система зручною, ефективною та безпечною.

Чіткі вимоги = менше багів, менше переробок, більше задоволених користувачів.

Data Flow Testing — це тип білого (white-box) тестування програмного забезпечення, який фокусується на відстеженні потоку даних у програмі для виявлення потенційних помилок, пов’язаних із використанням змінних.

Основна ідея:

В Data Flow Testing аналізується, як змінні оголошуються, ініціалізуються, використовуються та знищуються в програмному коді. Головна мета — виявити логічні помилки, які можуть виникнути через неправильне використання змінних.

Основні поняття:

• Def (Definition) — місце, де змінна отримує значення (наприклад, через присвоєння або введення).
• Use (Usage) — місце, де змінна використовується (наприклад, у виразах, умовах тощо).
• Kill (Undefined) — момент, коли змінна перестає бути дійсною (наприклад, вихід за межі області видимості).

Приклади помилок, які може виявити Data Flow Testing:

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

Як працює:

1. Код представляється у вигляді Control Flow Graph (CFG) — граф, де вузли — це інструкції або блоки коду, а ребра — переходи.
2. Для кожної змінної визначаються точки:
   • де вона оголошується/отримує значення (Def);
   • де вона використовується (Use).
3. Створюються шляхи Def-Use: від точки присвоєння до точки використання без повторного присвоєння.
4. Тест-кейси створюються для покриття всіх таких шляхів.

Переваги:

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

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

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

Основні терміни:

• Control Flow Graph (CFG) — граф керування потоком, у якому вузли представляють блоки коду (наприклад, оператори або групи інструкцій), а ребра — можливі переходи між цими блоками залежно від умов.
• Блок (Basic Block) — послідовність інструкцій, що виконується без розгалужень.

Основні види контрольного тестування потоку:

1. Statement Coverage (Покриття операторів):
   • Перевіряє, чи всі інструкції коду були виконані хоча б один раз.
2. Branch Coverage (Покриття гілок / умов):
   • Перевіряє, чи всі можливі гілки (true/false) умов були пройдені.
3. Path Coverage (Покриття шляхів):
   • Перевіряє всі можливі унікальні шляхи виконання коду. Найглибший рівень, але часто складний для реалізації через велику кількість можливих шляхів.

Мета Control Flow Testing:

• Виявити:
  • логічні помилки;
  • помилки умовного переходу;
  • пропущені шляхи;
  • нескінченні цикли або недосяжний код.

Приклад:

def absolute_value(x):
    if x >= 0:
        return x
    else:
        return -x

Для цього прикладу Control Flow Testing має охопити два шляхи:

• коли x >= 0 (гілка if);
• коли x < 0 (гілка else).

Переваги:

• Дає глибоке розуміння внутрішньої логіки програми.
• Допомагає виявити складні, умовно-залежні помилки.

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

Loop Testing — це тип тестування програмного забезпечення, що належить до категорії білого ящика (white-box testing). Основна мета loop testing — перевірити правильність циклічних конструкцій (loops) у програмному коді.

Що саме тестується?

Тестуються цикли різного типу:

• for
• while
• do-while
• рекурсивні виклики (у деяких випадках)

Основні типи циклів, що тестуються

1. Прості цикли (Simple Loops). Цикл з однією умовою, наприклад:

for i in range(5):
   print(i)

2. Вкладені циклик (Nested loops). Один цикл всередині іншого.

for i in range(3):
    for j in range(2):
        print(i, j)

3. Залежні цикли

4. Cкладні цикли

Основна мета loop testing:

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

Типові тести:

1. Zero Iteration (нуль разів) — цикл не виконується зовсім
2. One Iteration (один раз)
3. Typical Iteration (звичайна кількість разів)
4. Max Iteration (максимально допустима кількість)
5. Beyond Max (понад межу) — для виявлення помилок переповнення

Приклад (Python):

def count_positive(nums):
    count = 0
    for num in nums:
        if num > 0:
            count += 1
    return count

Loop Testing тут перевірить:

• Порожній список ([])
• Список з 1 елементом ([5])
• Список з позитивними й негативними значеннями ([-1, 2, 3])
• Інші граничні випадки (дуже великий список, змішані значення, межа між негативним і позитивним (-1, 0, 1), усі значення негативні тощо)

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