Найперше – що таке вимоги?
Вимоги описують логіку роботи продукту (функціональні вимоги), його зовнішній вигляд (користувацький інтерфейс), а також нефункціональні вимоги.
Для опису функціональних вимог часто використовуються користувацькі сценарії (use cases). У користувацьких сценаріях представлені варіанти того, як користувач може взаємодіяти з ПЗ.
Нефункціональні вимоги описують обмеження пов'язані з дизайном продукту та його реалізацією (продуктивність, безпека, надійність, сумісність, стандарти якості).
Все це структурує, допомагає планувати і здійснювати всі процеси розробки програмного забезпечення.
Якщо на проєкті ідеальний стан задокументованих і підтримуваних вимог – тестувальнику можна позаздрити.
Але часто буває так, що на проєкті відсутня документація, не вистачає часу на роботу з вимогами, і фактично, можна вважати що основне джерело інформації для тестувальника є відсутнім. Це вимагає від тестувальника додаткової самостійної роботи над вимогами, чи над правилами роботи системи. Все ж таки треба на щось опертись під час тестування, як мінімум, виявити усі функції та визначитися з їхньою роботою. Також важливо сформувати нефункціональні вимоги, щоб якісно перевірити роботу системи у різних середовищах, з різними навантаженнями тощо.
Чому ж так важливо чітко розуміти вимоги, виставлені замовником, і як в результаті це впливає на вартість продукту?
В ідеальному світі продукт після релізу:
- приносить мільйони власнику без додаткових витрат на підтримку,
- поліпшується з кожною новою версією,
- радує користувачів новими, ідеально працюючими фічами,
- отримує 5 зірочок у відгуках…
Але чому так є далеко не завжди?
На тестування виділяється менше часу ніж необхідно для проходження повного циклу тестування, з достатнім часом на фікс та ретестінг. Тому стає необхідним виставляти пріоритети та тестувати найважливіше у найкоротші проміжки часу. Також, зміни до вимог в процесі розробки, значуще впливають на збільшення обсягів роботи, які годі заменеджити в заздалегідь визначені часові рамки.
Але найчастішою причиною появи помилок загалом є невідтестовані та невідшліфовані вимоги. Ціна помилки зростає пропорційно до часу її життя у системі.
Чим пізніше після початку роботи над проєктом знайдений дефект (в дизайні, в коді, на проді), тим він дорожчий. А відомо, що знайти помилку в роботі продукту вже в релізі – ох, це звісно, ще той екшн.
Отже, тестувальник мусить дбати про наявність вимог, які прямують до ідеальних. Інакше не бачити йому/їй вільної годинки на обід, та й про спокійну вечерю можна забути на час релізу.
Вимога - це фактично текст, який відображає те, як клієнт бачить роботу системи. В ідеалі це має бути опрацьовано, описано бізнес-аналітиком з усіма важливими деталями. Та ідей багато, вони з'являються швидше, ніж встигаємо їх задокументувати, то ж деталі часто упускають. Деталі - цінні для тестувальника. Тому виникає необхідність дописувати деталі, уточнювати, знаходити відповідь, допридумувати і затверджувати у замовника. Так складаються обставини, що тестувальнику необхідно включатись у процес обговорення вимог. Вчасно поставлене питання «А чому саме так?» може викликати у замовника більш поглиблений аналіз вимоги. І в процесі обговорення будь-яка хаотична думка перетвориться у структуровану інформацію про роботу системи чи її функції.
Ставити питання – особливе завдання тестувальника. Він доглибинно має розуміти вимоги, всі нюанси, і наперед бачити кінцевий результат.
- Кому ставити ці питання?
Можна усім колегам на проєкті, але найкраще коли є бізнес-аналітик, чи продакт овнер, які власне і займаються встановленням правил роботи системи. Більше правильних питань ставить тестувальник - детальніше та повноцінніше будуть описані вимоги, це дозволить швидше досягнути реалізації задуманого у виробництві програмного продукту. Краще пропрацьоване розуміння продукту допомагатиме усім учасникам команди, підвищуватиме їхню продуктивність. Якщо чітких вимог немає та немає розуміння правильної роботи системи – все це виливається у непорозуміння в команді, неякісний продукт, зіпсовану репутацію.
В ході тестування ми приміряємо на себе роль кінцевого користувача. І якщо при вивченні документації продукту є непорозуміння, важливо вийти в одне інформаційне поле зі зрозумілою всім мовою. У кожного продукту може бути своя внутрішня термінологія. Хорошою практикою може стати словник термінів.
Це буде корисно, тому що:
- час не йтиме на пояснення понять початківцям чи новеньким на проєкті (та й досвідченим);
- новоприбулим це буде додатковим ознайомленням з продуктом;
- дефекти та тікети можуть бути легко знайдені в 1500+ тасок в Jira.
Не завжди те, що замовник бачить червоним – є червоним. Тому варто перепитати. Навіть якщо всі учасники команди ясно розуміють, про що мова, корисно буде зафіксувати це. І обговорити з колегами з різними ролями. Слід вислухати всі сторони та все записати. Так, іноді щоб зібрати і розібратись у вимогах, потрібно більше часу, більше відповідальності, і, звісно, більше документації.
- Документація, що робити з нею?
Можливі кілька варіантів розв'язання цієї проблеми:
- найпростіший у виконанні (але важкий у впровадженні) - розробити темплейт для вимог, яким слідуватиме вся команда. І обов'язково, щоб для продукту цей темплейт адаптувався з функцією «підтримки в актуальному вигляді».
- уточнюємо, просимо розповісти, показати, ставимо питання. З подальшою фіксацією всього почутого і побаченого. Одна з практик – якщо щось упущено / відрізняється від вимог - це дефект.
- скромна сторінка у власному просторі для тестової документації, де тестувальник сам собі режисер – фіксує всі проблемні моменти продукту і зберігає.
Вивчати, аналізувати, розуміти, тестувати вимоги та опиратися на них у професії тестування – шлях до успіху та формування професійного авторитету.
- Як працювати з вимогами – дізнайся на практичному Воркшопі: Business Requirements. Stakeholder Management. Business Model Canvas.
- Стань бізнес-аналітиком на Курсі: Business Analysis (доступний в записі з 30.08.2022р.)
- Вивчай англійську для роботи бізнес-аналітиком на Course: English for BA
А твій шлях в ІТ може розпочатися з Практичного курсу тестування з працевлаштуванням
