SRS (Software Requirements Specification) — це специфікація програмних вимог, один із головних документів у процесі розробки та тестування програмного забезпечення.
У контексті тестування ПЗ, SRS — це основне джерело інформації для створення тест-кейсів, планів тестування та визначення критеріїв прийнятності (acceptance criteria).
Що таке SRS
SRS описує, як саме має працювати майбутня система — з технічної точки зору. Якщо BRD відповідає на питання «що потрібно бізнесу», то SRS пояснює «як саме програмне забезпечення має це реалізувати».
Основний зміст SRS
Типова структура SRS включає такі розділи:
Вступ
Мета документа
Сфера застосування системи
Терміни, скорочення
Посилання на інші документи (наприклад, BRD)
Загальний опис
Контекст системи
Основні функції
Типи користувачів
Обмеження, припущення, залежності
Функціональні вимоги
Детальний опис кожної функції системи
Вхідні та вихідні дані
Валідаційні правила
Взаємодія між компонентами
Нефункціональні вимоги
Продуктивність
Безпека
Надійність
Зручність використання (usability)
Сумісність
Інтерфейсні вимоги
Опис GUI (екрани, поля, кнопки)
Інтеграції з іншими системами або API
Роль SRS у тестуванні
Для тестувальників SRS є детальним технічним джерелом вимог, на основі якого вони можуть:
Розробити тест-кейси з точним описом очікуваної поведінки системи;
Побудувати RTM (Requirements Traceability Matrix), щоб переконатися, що всі вимоги покрито тестами;
Зрозуміти логіку бізнес-процесів і перевірити, чи система працює відповідно до вимог;
Виявити суперечності або пропуски у вимогах ще до початку розробки.
Взаємозв’язок із іншими документами
Документ
Опис
Хто створює
Рівень деталізації
BRD
Бізнес-вимоги — що потрібно бізнесу
Бізнес-аналітик
Високий, загальний
FRD
Функціональні вимоги — що має робити система
Системний аналітик
Середній
SRS
Специфікація програмних вимог — як це має бути реалізовано
Тестові артефакти — це усі матеріали, створені, використані або отримані під час тестування програмного забезпечення, незалежно від того, чи це документи, файли, скрипти, звіти або дані.
Вони є результатом діяльності команди тестування на різних етапах життєвого циклу тестування (SDLC/STLC — Software / Software Testing Life Cycle). Артефакти допомагають:
планувати тестування,
виконувати його за структурованим підходом,
аналізувати результати,
забезпечувати прозорість процесу для всіх учасників проєкту (тестувальників, розробників, менеджерів, замовників).
Класифікація тестових артефактів
Артефакти етапу аналізу вимог
Ці документи допомагають зрозуміти, що саме потрібно тестувати і як вимоги перетворюються у тестові об’єкти.
Артефакт
Опис
Requirements Specification / BRD / SRS
Документ із вимогами (Business Requirements Document, Software Requirements Specification). Це вихідна база для створення тестових сценаріїв.
Requirements Traceability Matrix (RTM)
Матриця трасування — зв’язує вимоги з тест-кейсами, дефектами і результатами, забезпечуючи повноту покриття.
Testability Review Report
Звіт про огляд вимог із точки зору можливості тестування (чи чіткі, вимірювані, однозначні).
Risk Assessment / Risk Matrix
Ідентифікація та оцінка ризиків для пріоритезації тестування (які області продукту найкритичніші).
Impact Analysis Report
Аналіз впливу змін у вимогах або коді на вже розроблені тести.
Артефакти планування тестування
Артефакт
Опис
Test Strategy
Загальна стратегія тестування для продукту або всієї організації.
Test Plan
Детальний план проведення тестування конкретної версії або релізу.
Test Schedule / Test Calendar
Графік тестування із зазначенням термінів і відповідальних.
Test Environment Plan / Configuration Specification
Документ, що описує налаштування тестового середовища, серверів, баз даних, версій ПЗ, залежностей тощо.
Entry / Exit Criteria
Формальні критерії початку та завершення тестування (іноді виділяються як окремий документ).
Resource Plan
Опис ролей, необхідних ресурсів (людських, технічних, часових).
Артефакти дизайну тестів
Артефакт
Опис
Test Scenarios
Узагальнені ситуації або бізнес-процеси для перевірки.
Test Cases
Покрокові інструкції для тестування функцій.
Test Data
Вхідні дані (текстові, числові, SQL, JSON, CSV тощо) для виконання тестів.
Test Design Techniques Documents
Документи або шаблони, що описують, які техніки тест-дизайну застосовано (еквівалентні класи, граничні значення, pairwise тощо).
Checklists
Списки ключових перевірок без детальних кроків.
Test Suites / Test Sets
Групи тест-кейсів, об’єднаних за логікою або ціллю тестування.
Test Coverage Matrix
Матриця покриття вимог або функціональних областей тестами.
Артефакти підготовки середовища
Артефакт
Опис
Environment Setup Guide
Покрокова інструкція з розгортання тестового середовища.
Build Verification Checklist (Smoke Test Checklist)
Список перевірок для визначення, чи придатна збірка для подальшого тестування.
Test Data Initialization Scripts
Скрипти для наповнення БД або системи тестовими даними.
Environment Access Matrix
Хто має доступ до яких середовищ (QA, Staging, UAT, Prod).
Артефакти виконання тестування
Артефакт
Опис
Test Execution Log / Run Log
Записи про виконання тестів: коли, ким, які кейси, із яким результатом.
Test Scripts (Automation)
Автоматизовані тести (наприклад, у Selenium, Cypress, JMeter).
Exploratory Testing Notes / Session Reports
Нотатки тестувальників після сеансів дослідницького тестування.
Screenshots / Video Evidence
Докази виконання тестів, часто прикріплюються до звітів.
Error Logs / System Logs
Технічні логи системи, що підтверджують помилки.
Артефакти управління дефектами
Артефакт
Опис
Defect Report / Bug Report
Звіт про знайдений дефект із усіма деталями для відтворення.
Defect Triage Report
Звіт або протокол розгляду дефектів (пріоритезація, призначення, статус).
Defect Density Metrics
Аналітика за кількістю дефектів на одиницю коду, модуль або функціональність.
Reopen Analysis
Аналіз повторно відкритих дефектів.
Артефакти звітності та аналізу результатів
Артефакт
Опис
Test Summary Report
Підсумковий звіт про проведене тестування.
Test Metrics & Dashboards
Ключові показники: % успішних тестів, кількість дефектів, покриття тощо.
Release Readiness Report
Звіт про готовність продукту до релізу (з урахуванням тестових результатів).
Quality Report / QA Health Report
Комплексна оцінка якості продукту та процесу тестування.
Lessons Learned Document
Аналіз помилок і покращень після завершення тестового циклу.
Postmortem / Retrospective Notes
Документи після релізу — що вдалося, що ні, які дії заплановані для оптимізації QA-процесу.
Додаткові або допоміжні артефакти
Артефакт
Опис
User Acceptance Testing (UAT) Plan / Results
План і результати тестування користувачами або бізнесом.
Performance Test Plan / Results
Документи для навантажувального, стресового тестування.
Security Test Report / Vulnerability Report
Звіти безпекового тестування, знайдені вразливості.
Compliance & Audit Reports
Підтвердження відповідності продукту стандартам (наприклад, ISO, GDPR).
Configuration Management Records
Відстеження версій тестових артефактів, змін у середовищі.
Automation Framework Documentation
Опис архітектури автоматизації, структури тестів, підходів.
Mock / Stub / Test API Specifications
Документація щодо симуляторів або фіктивних сервісів для інтеграційного тестування.
Підсумки
Тестові артефакти — це не лише тест-кейси та баг-репорти. Вони охоплюють усі продукти діяльності QA-команди: від аналізу вимог і планування до звітування, метрик, автоматизації та аудиту.
Повний набір артефактів залежить від:
типу проєкту (web, mobile, enterprise);
моделі SDLC (Waterfall, Agile, DevOps);
рівня зрілості QA-процесу;
регуляторних вимог (наприклад, у фінтех або медичному ПЗ потрібна більша формалізація).
Якість програмного забезпечення (Software Quality) — це багатовимірне поняття, яке охоплює надійність, зручність, ефективність, безпеку, підтримуваність та інші властивості, що визначають, наскільки добре продукт відповідає вимогам, очікуванням користувачів і бізнес-цілям.
Іншими словами: якість — це міра відповідності між тим, що програмне забезпечення повинно робити, і тим, що воно фактично робить, а також наскільки добре воно це робить.
Якість як частина життєвого циклу розробки (SDLC)
Якість не з’являється лише на етапі тестування — вона формується на кожному етапі життєвого циклу ПЗ:
Етап SDLC
Як він впливає на якість
Збір і аналіз вимог
Якщо вимоги нечіткі або неповні — продукт не відповідатиме очікуванням користувачів.
Проєктування (Design)
Визначає архітектуру, яка впливає на масштабованість, продуктивність і стабільність.
Розробка (Development)
Від якості коду, дотримання стандартів, рефакторингу залежить надійність і підтримуваність.
Тестування (Testing)
Дозволяє перевірити функціональність, виявити дефекти та оцінити нефункціональні характеристики.
Деплоймент і підтримка
Якість підтримки, оновлень, виправлень і користувацького досвіду формує довіру користувачів.
Отже, якість — це не лише “тестування без багів”, а результат командної культури та процесів.
Компоненти якості програмного забезпечення
Міжнародний стандарт ISO/IEC 25010:2011 визначає 8 основних характеристик якості:
Можливість перенесення ПЗ на інші платформи чи середовища.
Quality Assurance (QA) vs Quality Control (QC) vs Testing
Поняття
Характеристика
Мета
QA (Quality Assurance)
Сукупність процесів, що забезпечують створення якісного продукту. Включає планування, аудит, стандартизацію, вдосконалення процесів.
Запобігання дефектам
QC (Quality Control)
Дії з перевірки відповідності результату встановленим вимогам — рев’ю, тестування, інспекції.
Виявлення дефектів
Testing (Тестування)
Практичний процес виконання ПЗ для пошуку дефектів. Один з інструментів QC.
Виявлення помилок у функціонуванні системи
Отже, тестування — лише частина загальної системи забезпечення якості.
Метрики якості програмного забезпечення
Щоб керувати якістю, її потрібно вимірювати. Використовуються різні метрики, наприклад:
Тип метрики
Приклади
Що показує
Процесні (Process metrics)
% покриття тестами, кількість багів на реліз, час на виправлення дефекту
Ефективність процесу розробки
Продуктові (Product metrics)
Кількість дефектів на 1К рядків коду, рівень code coverage, середній час відповіді
Стан і якість продукту
Користувацькі (User metrics)
NPS (Net Promoter Score), CSAT (Customer Satisfaction), кількість скарг
Задоволення користувачів
Культура якості в команді
Висока якість досягається не лише технічними засобами, а й культурою розробки, коли:
команда відповідально ставиться до якості продукту;
процеси прозорі та контрольовані;
рішення приймаються на основі даних і зворотного зв’язку;
розробники, тестувальники, аналітики й менеджери працюють спільно над якістю, а не перекладають відповідальність.
Підсумки
Якість програмного забезпечення — це сукупність властивостей продукту та процесів його створення, які забезпечують відповідність очікуванням користувачів, вимогам бізнесу та технічним стандартам, забезпечуючи при цьому стабільність, ефективність, безпеку й зручність використання.
Якісні вимоги до програмного забезпечення — це основа для успішної розробки, тестування та підтримки будь-якої програмної системи. Вони мають бути чітко сформульовані, однозначно трактовані всіма учасниками проєкту, повними, реалістичними та придатними для перевірки. Існує низка загальноприйнятих характеристик, які визначають якість вимог. Нижче подано основні характеристики з поясненнями та прикладами.
1. Однозначність (Unambiguousness)
Пояснення: Вимога повинна мати лише одне трактування, бути чіткою й зрозумілою для всіх: замовника, аналітика, розробника, тестувальника.
Погано:
Система має працювати швидко.
Добре:
Система повинна обробляти запит на пошук протягом не більше 2 секунд при одночасному навантаженні до 1000 користувачів.
2. “Перевірюваність” – можливість перевірки чи підтвердження (Verifiability)
Пояснення: Має бути можливість перевірити виконання вимоги шляхом тестування, інспекції або іншого методу.
Погано:
Інтерфейс повинен бути інтуїтивно зрозумілим.
Добре:
Інтерфейс має відповідати гайдам користувача Apple HIG та мати не більше 3 рівнів вкладеності меню.
3. Повнота (Completeness)
Пояснення: Вимоги мають охоплювати всі аспекти функціональності, обмежень, винятків тощо. Не повинно бути “дірок”, неясних посилань чи відсутніх частин.
Погано:
Система повинна обробляти запити користувача.
Добре:
Система повинна обробляти запити на:
реєстрацію нового користувача,
зміну пароля,
видалення облікового запису.
4. Зрозумілість (Understandable / Clear)
Пояснення: Вимоги повинні бути написані простою, доступною мовою, зрозумілою всім учасникам проєкту. Варто уникати спеціалізованих термінів без пояснення.
Погано:
Система повинна реалізувати функціональність REST API з підтримкою OAuth 2.0, PKCE flow та JWT токенів без state management.
Добре (із поясненням):
Система повинна надавати REST API, що використовує протокол авторизації OAuth 2.0 з підтримкою механізму PKCE для безпечної автентифікації мобільних клієнтів.
5. “Здійсненність” або можливість реалізації (Feasibility)
Пояснення: Вимоги мають бути технічно здійсненними та відповідати часовим, фінансовим і ресурсним обмеженням.
Погано:
Система повинна мати 100% безвідмовність.
Добре:
Система повинна забезпечувати доступність на рівні 99.9% протягом місяця.
6. Послідовність (Consistency)
Пояснення: Вимоги не повинні суперечити одна одній. Усі положення повинні бути логічно узгодженими.
Погано:
Вимога 1: Користувач може скасувати замовлення в будь-який час. Вимога 2: Замовлення не можна скасувати після оплати.
Добре:
Користувач може скасувати замовлення в будь-який час до моменту оплати.
7. Можливість трасування (Traceability)
Пояснення: Вимога повинна мати унікальний ідентифікатор і бути пов’язаною з цілями бізнесу, сценаріями використання, тест-кейсами, кодом. Це дозволяє відстежити весь життєвий цикл вимоги.
Приклад:
Вимога ID: FR-05. Пов’язана з бізнес-ціллю BG-02 (збільшення конверсії в реєстрації), сценарієм UC-01, тест-кейсом TC-05.
8. Модульність (Modularity / Atomicity)
Пояснення: Кожна вимога має описувати одну логічну функціональність, не бути надто загальною або складеною з кількох частин.
Погано:
Система має надавати авторизацію і реєстрацію, а також зміну пароля.
Добре:
FR-01: Система повинна надавати функцію реєстрації нового користувача.
FR-02: Система повинна надавати функцію входу користувача.
FR-03: Користувач може змінити пароль зі свого профілю.
9. Актуальність (Up-to-date / Valid)
Пояснення: Вимоги повинні бути актуальними, відповідати реальним потребам бізнесу та не містити застарілих або скасованих положень.
Приклад: Якщо бізнес відмовився від підтримки мобільного додатку, відповідні вимоги мають бути вилучені з документації.
10. Пріоритизація (Prioritized)
Пояснення: Вимоги мають бути розділені за рівнями важливості (наприклад: обов’язкові, бажані, додаткові). Це допомагає в плануванні релізів і розподілі ресурсів.
Приклад:
Обов’язкова: Реєстрація користувача
Бажана: Вхід через Google
Додаткова: Темна тема інтерфейсу
Якісні вимоги — це запорука успішного проєкту. Невизначені, суперечливі або неповні вимоги можуть призвести до непорозумінь, збоїв у роботі програми, перевищення бюджету або незадоволення замовника. Тому дуже важливо дотримуватись вищенаведених характеристик при зборі, аналізі та документуванні вимог.
Збір вимог до програмного забезпечення (software requirements elicitation) —один із найважливіших етапів у розробці програмного забезпечення, під час якого аналітики, розробники або продакт-менеджери виявляють, формулюють і документують функціональні й нефункціональні потреби зацікавлених сторін (стейкхолдерів).
Помилки на цьому етапі призводять до:
невідповідності продукту очікуванням клієнта
перевитрат бюджету
затримок у розробці
переробок і конфліктів
Основні методи збору вимог
1. Інтерв’ю (Interviews)
Суть: Один з найпоширеніших методів — бесіда з окремими користувачами чи стейкхолдерами для виявлення їхніх очікувань, проблем, потреб.
Типи:
Структуроване — з чітким планом і питаннями.
Неструктуроване — у вільній формі.
Напівструктуроване — поєднання двох підходів.
Приклад: Інтерв’ю з бухгалтером, щоб дізнатися, які звіти йому потрібні в ERP-системі.
Переваги:
Дозволяє глибоко розуміти контекст.
Можна задавати уточнюючі питання.
Недоліки:
Вимагає часу.
Результати залежать від досвіду аналітика та щирості користувача.
Коли використовувати: На ранніх етапах проєкту для виявлення ключових потреб.
2. Опитування (Surveys, Questionnaires)
Суть: Розсилка форм із запитаннями для великої кількості користувачів, щоб зібрати статистику, думки чи побажання.
Типові формати:
Закриті питання (із варіантами відповідей)
Відкриті питання
Приклад: Опитування працівників компанії про бажаний функціонал у новій системі відстеження робочого часу.
Переваги:
Ефективно при великій кількості респондентів.
Дані легко агрегуються.
Недоліки:
Мало глибини.
Може бути низька якість відповідей.
Коли використовувати: Коли треба зібрати узагальнені думки від широкої аудиторії.
3. Фокус-групи (Focus Groups)
Суть: Організація дискусії з 5–10 учасниками, які представляють типових користувачів. Обговорюють функціональність, очікування, можливі проблеми.
Приклад: Фокус-група лікарів для обговорення майбутньої медичної інформаційної системи.
Переваги:
Генерація ідей у динаміці.
Виявлення різних точок зору.
Недоліки:
Домінування окремих учасників.
Важко модераувати.
Коли використовувати: У B2C або B2B проєктах, де важливі думки кінцевих користувачів.
4. Спостереження (Observation / Job Shadowing)
Суть: Аналітик спостерігає за тим, як користувач виконує свої завдання в реальному робочому середовищі. Іноді — взаємодіє з ним (active observation).
Варіанти:
Пасивне — без втручання.
Активне — з питаннями, уточненнями, взаємодією.
Приклад: Спостереження за працівником складу, який обробляє замовлення, щоб виявити вимоги до нової WMS (Warehouse Management System).
Переваги:
Виявлення прихованих, неочевидних вимог.
Розуміння реального процесу.
Недоліки:
Вимагає часу.
Поведінка користувача може змінюватися під спостереженням.
Коли використовувати: У складних процесах, де користувач сам не може чітко описати свої дії.
5. Прототипування (Prototyping)
Суть: Створення початкової (навіть дуже спрощеної) версії продукту чи інтерфейсу для збору зворотного зв’язку.
Види прототипів:
Low-fidelity (паперові макети, wireframes)
High-fidelity (інтерактивні UI-моделі)
Приклад: Макет мобільного застосунку для керування доставкою, створений у Figma.
Переваги:
Краще розуміння потреб користувачів.
Зниження ризику непорозумінь.
Недоліки:
Займає час на розробку прототипу.
Користувачі можуть подумати, що система вже готова.
Коли використовувати: Для візуалізації складних інтерфейсів або перевірки гіпотез.
6. Workshops (Робочі сесії, воркшопи)
Суть: Інтерактивні зустрічі з представниками різних груп стейкхолдерів, де обговорюються вимоги, сценарії, очікування, проблеми.
Формати:
Семінари з фасилітатором
Картування процесів (process mapping)
User journey mapping
Приклад: Воркшоп із відділами HR і IT для проєктування системи управління персоналом.
Переваги:
Швидка генерація вимог.
Узгодження між сторонами.
Недоліки:
Складність організації.
Потреба в досвідченому модераторі.
Коли використовувати: Коли потрібно зібрати думки кількох груп одночасно.
7. Аналіз документів (Document Analysis)
Суть: Вивчення наявних специфікацій, технічних документів, процесів, політик, звітів тощо.
Приклад: Аналіз документації старої CRM-системи перед створенням нової.
Переваги:
Допомагає зрозуміти поточні процеси.
База для порівняння “як є” vs “як має бути”.
Недоліки:
Документи можуть бути застарілими або неповними.
Коли використовувати: На старті, особливо при заміні чи інтеграції з існуючими системами.
8. Use Cases / User Stories / Scenarios
Суть: Опис конкретних дій користувача з системою, щоб зрозуміти функціональні вимоги.
Формати:
Use Case (формальний опис з умовами, діями)
User Story (наприклад: “Як менеджер, я хочу бачити звіт про продажі, щоб аналізувати продуктивність”)
Сценарії (step-by-step interaction)
Переваги:
Фокус на поведінці системи.
Дає контекст.
Недоліки:
Потребує досвідчених аналітиків.
Коли використовувати: У системах із великою кількістю ролей та дій.
9. Мозковий штурм (Brainstorming)
Суть: Колективне генерування ідей без критики з метою зібрати максимум варіантів.
Приклад: Сесія з маркетологами для ідей майбутнього мобільного застосунку для клієнтів.
Переваги:
Висока креативність.
Може дати нестандартні рішення.
Недоліки:
Не завжди структуровані результати.
Не кожна ідея практична.
Коли використовувати: На ранніх етапах, коли ще немає чіткого бачення продукту.
10. Рев’ю існуючих систем (Interface Analysis / Benchmarking)
Суть: Аналіз зовнішніх або внутрішніх систем, щоб зрозуміти, як вони працюють, і що можна поліпшити.
Приклад: Вивчення функціональності конкурентного мобільного банкінгу.
Переваги:
Можна запозичити вдалі рішення.
Виявлення недоліків у поточному продукті.
Недоліки:
Ризик копіювання без глибокого розуміння.
Може обмежити креативність.
Коли використовувати: Для редизайну систем або створення MVP.