Чому вимоги такі важливі для тестувальника?

Найперше – що таке вимоги?

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

Для опису функціональних вимог часто використовуються користувацькі сценарії (use cases). У користувацьких сценаріях представлені варіанти того, як користувач може взаємодіяти з ПЗ.

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

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

Якщо на проекті ідеальний стан задокументованих і підтримуваних вимог – тестувальнику можна позаздрити.

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

Чому ж так важливо чітко розуміти вимоги, виставлені замовником, і як в результаті це впливає на вартість продукту?

В ідеальному світі продукт після релізу:

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

Але чому так є далеко не завжди?

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

Але ​​найчастішою причиною появи помилок загалом є невідтестовані та невідшліфовані вимоги. Ціна помилки зростає пропорційно до часу її життя у системі.

Чим пізніше після початку роботи над проектом знайдений дефект (в дизайні, в коді, на проді), тим він дорожчий. А відомо, що знайти помилку в роботі продукту вже в релізі – ох, це звісно, ще той екшн.

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

Вимога - це фактично текст, який відображає те як клієнт бачить собі роботу системи. В ідеалі це має бути опрацьовано, описано бізнес аналітиком з усіма важливими деталями. Та ідей багато, вони появляються швидше ніж встигаємо їх задокументувати, то ж деталі часто упускають. Деталі, це саме цінне для тестувальника. Тому виникає необхідність дописувати деталі, уточнювати, знаходити відповідь, допридумувати і затверджувати у замовника. Так складаються обставини, що тестувальнику необхідно включатись у процес обговорення вимог. Вчасно поставлене питання «А чому саме так?» може викликати у замовника більш поглиблений аналіз вимоги. І в процесі обговорення будь яка хаотична думка перетвориться у впорядку, структуровану інформацію про роботу системи чи її функції.

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

Кому ставити ці питання?

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

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

Це буде корисно, тому що:

- ваш час не йтиме на пояснення понять початківцям чи новеньким на проекті (та й досвідченим);

- новоприбулим це буде додатковим ознайомленням з продуктом;

- дефекти і тікети можуть бути легко знайдені в 1500+ тасок в Jira.

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

Документація, що робити з нею?

Можливі кілька варіантів рішення цієї проблеми:

- найпростіший у виконанні (але важкий у впровадженні) - розробити темплейт для вимог, яким слідуватиме вся команда. І обов'язково, щоб для продукту цей темплейт адаптувався з функцією «підтримки в актуальному вигляді».

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

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

Вивчати, аналізувати, розуміти, тестувати вимоги та опиратися на них у професі тстування – шлях до успіху та формування професійного авторитету.

А твій шлях в ІТ - може розпочатися з Практичного курсу тестування з працевлаштуванням

copy_copy_copy_copy_copy_dyzajn_bez_nazvy.320x0.jpeg.pagespeed.ce.D7h1tfNTLf.jpg

Курси та події

Публікації

Відео