Поняття та види вимог до програмного продукту

Привіт! Вітаємо на другому уроці з основ QA. Сьогодні говоритимемо про важливу складову забезпечення якості — вимоги. Будь-яка розробка програмного продукту складається з етапу документування вимог. Опис того, як повинен працювати продукт, може бути деталізованим чи навпаки містити лише загальне бачення. Але усі деталі того, що потрібно зробити, обовʼязково маються бути записані.

Вимоги — це специфікація (опис) того, що має бути реалізовано у програмному продукті. Документ, в якому описуються вимоги називається специфікацією до програмного продукту (software specification). Або його ще можуть називати технічним завданням (ТЗ). 

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

Розрізняють декілька видів специфікацій вимог:

• Бізнес-вимоги (business requirements) виражають мету, заради якої розробляється продукт (навіщо він потрібен, яка від нього очікується користь, як замовник за його допомогою отримуватиме прибуток):
  ◦ Наприклад, автоматизація процесу документообігу зможе зекономити компанії $1,000,000 на рік операційних витрат;

• Користувацькі вимоги (user requirements) описують завдання, які користувач зможе виконувати за допомогою системи, що розробляється (реакцію системи на дії користувача, сценарії роботи користувача):
  ◦ Наприклад, система повинна надати можливість користувачеві оплатити товари на сайті в один клік через Apple Pay або Google Pay;

• Функціональні вимоги (functional requirements) описують поведінку системи, тобто її дії (обчислення, перетворення, перевірки, обробку даних тощо):
  ◦ Наприклад, для реєстрації в системі новий користувач повинен заповнити поля електронної адреси та пароля, які є обовʼязковими;

• Нефункціональні вимоги (non-functional requirements) описують властивості системи (зручність використання, безпека, надійність):
  ◦ Наприклад, інформація про доставку товару має бути доступна користувачеві менш ніж за 3 кліки.

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

Як QA-спеціалістам аналізувати вимоги

Аналіз вимог — це частина процесу розробки програмного забезпечення, що складається зі збирання вимог, їх систематизації, виявлення взаємозв'язків, а також документування. У процесі аналізу вимог важливо брати до уваги можливі розбіжності у вимогах від різних учасників розробки (замовників, розробників та кінцевих користувачів). Можна по-різному трактувати одну і ту ж саму вимогу, що призведе до непорозумінь та перероблення функціонала декілька разів.

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

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

До характеристик хороших вимог належать:

• Завершеність: з вимоги чітко зрозуміло, яка функція повинна бути реалізована:
  ‍◦ Користувач повинен мати можливість додати повідомлення у відповідь на розміщене на сайті оголошення;

• Несуперечливість: вимоги не перетинаються між собою і не суперечать одна одній:
  ◦ Повідомлення повинне автоматично відправитись при натисканні кнопки “Надіслати”. Повідомлення повинне відправитись при натисканні клавіші “Enter”. (це приклад суперечливості у двох вимогах, оскільки не зрозуміло, яким чином відправити повідомлення);

• Можливість реалізувати та протестувати: вимога повинна бути описана так, щоб її можна було запрограмувати та потім перевірити:
  ◦ Користувач може відправити декілька повідомлень у відповідь на одне оголошення;

• Однозначність: вимога однаково зрозуміла усім членам команди розробки, немає двозначності в трактуванні:
  ◦ Користувач може відправити повідомлення розміром до 500 символів з пробілами;

• Виставлений пріоритет: за наявності пріоритету можна чітко зрозуміти важливість конкретної вимоги для користувача (наприклад, високий пріоритет). 

Для QA-спеціалістів важливо вміти розбиратись із вимогами, адже вони становлять значну частину роботи. Щоб перевірити відповідність вимог до вищезазначених критеріїв, часто потрібно ставити уточнювальні запитання, щоб чітко розуміти, як повинен працювати функціонал. Також важливо дивитися на вимогу з точки зору того, як її можна перевірити та протестувати (і чи це взагалі можливо). Якщо придумати перевірку одразу неможливо, потрібно уточнювати деталі, доки не стане зрозуміло. Також слід памʼятати, що продукт розробляється для користувачів і варто час від часу ставити себе на їхнє місце. Це допоможе зрозуміти, наскільки вимога вписується в загальний функціонал програмного продукту.

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

Тестова документація як спосіб перевірки вимог

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

Документування процесу тестування дозволяє:

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

Найбільш розповсюдженими видами тестової документації є: 

• Тест-план (test plan);
• Чекліст (checklist);
• Тест-кейс (test case);
• Набір тестів (test suite).

В цьому уроці ми зупинимось лише на тест-кейсі. Написання тест-кейсів — один із найважливіших обовʼязків тестувальників. Отже, почнімо знайомство з цим видом документації.

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

Тест-кейси бувають позитивні та негативні:

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

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

Тепер розберімо основні складові тест-кейсу та перейдімо до прикладу його написання. Отже, для тест-кейсу необхідно заповнити такі основні дані:

• назва (title, summary);
• передумови (preconditions);
• кроки (steps);
• очікуваний результат (expected result);
• пріоритет (priority).

В цьому уроці ми тестуватимемо одну зі сторінок сайту Beetroot Academy, для якої відомі такі вимоги:

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

Тест-кейс 1.1 — позитивний

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

Тест-кейс 1.2 — позитивний

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

‍

Завдання: напиши 4 позитивні тест-кейси, щоб перевірити наступні 4 вимоги із заданого списку до сторінки Beetroot Academy (по одному тест-кейсу на кожну вимогу).

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

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

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

‍

Завдання: напиши 1 негативний тест-кейси для 1 вимоги (на вибір).

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

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

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