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

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

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

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

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

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

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

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

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

Це тягне за собою купу проблем і витрат часу, коштів, нервових клітин.

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

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

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

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

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

Але ​​найбільша причина – дефект у вимогах.

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

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

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

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

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

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

Усім!

Колегам, девелоперам, тімліду, бізнес-аналітику, продакт-менеджеру, замовнику.

Чим більше правильних питань ставить тестувальник, тим краще буде для продукту в майбутньому.

Чим краще пропрацьоване розуміння продукту, тим більше це розуміння розширить кругозір і стане працювати на тестувальника і на продуктивність команди. А ще це все значно спрощує спілкування з розробником і не тільки.

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

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

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

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

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

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

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

Не завжди те, що замовник бачить червоним – є червоним. Тому варто перепитати.

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

Слід вислухати всі сторони і все записати.

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

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

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

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

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

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

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

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

copy_dyzajn_bez_nazvy_1.300x0.png.pagespeed.ce.TIhmWk741o.png

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

Публікації

Відео