Як тестувальнику розібратися з вимогами

Навіщо тестувальнику вимоги

Я почну трохи здалеку, щоб окреслити велику картинку і дати трохи контексту.

Тож спочатку поговоримо про shift-left approach або shift-left testing. Мета такого підходу — починати тестування якомога раніше та уникнути ситуації, коли тестування проводиться лише у кінці циклу розробки.

Основні переваги такого підходу:

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

Для наочності, скільки коштує виправити дефект на різних стадіях життєвого циклу ПО:

Джерело: https://deepsource.io/blog/exponential-cost-of-fixing-bugs/

Що це значить для тестувальників?

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

Для початку — теорія

Якщо ви загуглите, що таке вимоги (і знайдете BABOK: Business Analysis Body Of Knowledge), то отримаєте приблизно такий результат:

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

BABOK також класифікує вимоги за такими типами:

Business Requirements – Вимоги до бізнесу
Stakeholder Requirements – Вимоги до зацікавлених сторін
Solution Requirements – Вимоги до рішення
Transition Requirements – Вимоги до переходу

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

Вимоги до рішення описують конкретні характеристики, якими повинен володіти продукт, щоб відповідати потребам зацікавлених сторін і самого бізнесу. Вони діляться на дві великі групи:

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

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

Трохи інша класифікація

Але я б хотіла написати трохи про інше, ніж про суху теорію, яку не завжди зрозуміло як застосовувати у житті.

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

Нумо розбиратися.

З моєї упередженою точки зору, вимоги можуть бути:

явними
неявними
деталізованими
високорівневими
усними
письмовими
те, про що всі знають
здоровий глузд (common sense)
….

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

Явні чи неявні

Тут все просто і складно одночасно. З явними вимогами, наче зрозуміло, це те, що дає замовник. “Зробіть сайт” — це дуже-дуже високорівнева вимога, висловлена явно.

Для неявних вимог, на мою думку, можна навести декілька прикладів.

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

Як можна перевести такі припущення у видиму площину? Знову ж таки, питати й розмовляти з PO/BA на проєкті. А щоб знати, що такі питання можуть з’явитися, треба цікавитися галуззю, новинами та мати широкий кругозір.

Усні та письмові вимоги

Легше за все, коли вимоги записані, правда ж? Але теж можуть бути цікаві варіанти. Ідеально, коли є Confluence чи подібний інструмент, де можна подивитися попередні версії документа, залишити коментарі та зручно шукати.

Notion, OneNote, Google Doc, Miro, etc. — варіантів для ведення документації безліч. Якісь мені видаються більш зручними, якісь менше, але гнучкість наше все, тому вивчайте можливості системи, з якою вам випало працювати. І обов’язково показуйте команді цікавинки.

Трохи складніший варіант, коли вимоги та тікети це одне й те саме. Класно, коли є коментарі з додатковою інформацією. Шукати потрібне складніше, проте легше прослідкувати якою була імплементація.

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

Наступні варіанти і їх комбінації я дуже не люблю, бо це ускладнює роботу:

все у пошті,
все у месенджерах,
був мітинг, де про щось домовились усно
був мітинг, але потім у месенджері передомовились, etc

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

Які проблеми тут виникають?

Проблеми з усними вимогами, можна звести до виразу “якщо це не було записано, цього не було”. Є багато різних історій, в основі яких міскомунікація.

Ще одна проблема — зазвичай немає єдиного джерела вимог, відповідно, команди мають різну інформацію і діють, відповідно до знань.

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

Багато уроків можна винести з цієї ситуації, один із них — якщо у вас багато джерел, які видають вимоги, то синхронізація буде дуже складною.

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

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

Деталізація вимог

Спробую пояснити на невеликому прикладі. Створімо сторінку для логіна користувача.

Варіант 1

Як користувач, я хочу мати сторінку для логіну, щоб мати змогу зайти в особистий кабінет.

Варіант 2

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

Варіант 3

Як користувач, я хочу мати сторінку для логіну, щоб мати змогу зайти в особистий кабінет.
Потрібно створити сторінку логіну, для входу користувача. На сторінці має бути поле логін і пароль, кнопки Вхід та Скасувати.
Поле Логін:
- від 5 до 25 символів
- тільки латиниця
- можна використовувати спецсимволи _, *, !

Поле Пароль
- від 10 до 25 символів
- тільки латиниця
- обов’язково використовувати спецсимволи `!@#$%^&*()_-+={[}]|\:;”‘<,>.?/
Кнопка Вхід має бути зеленого кольору. При клацанні на кнопку, система перевіряє дані користувача. Якщо вони вірні, то користувача треба перенаправити в особистий кабінет. Якщо ні — відобразити текст “Ваші логін/пароль некоректні, будь ласка, перевірте дані”.
Кнопка Скасувати має бути сірого кольору. При клацанні на кнопку, користувач має повернутися на попередню сторінку.

Як вважаєте, останній варіант показує достатній рівень деталізації?

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

Як розташувати все на сторінці?
Який фон має бути?
Для логіну і пароля ми очікуємо великі літери, маленькі, або і те та інше?
Якщо користувач вводить пароль неправильно декілька разів, ми маємо відобразити інший текст?
Якщо користувач забув пароль, який флоу ми можемо запропонувати?
А у базі даних є окрема таблиця, по якій можна перевірити? (в нас взагалі є база даних чи це рядки в excel? І так бувало)
А як шифрувати паролі?

Чим більше питань ви згенеруєте, тим більш зрозумілий обсяг робіт ви отримаєте.

Чи завжди треба все це записувати та оформлювати саме як документ або сторінку у конфлюенс? Простої відповіді немає. Вичерпне тестування, як ми пам’ятаємо, неможливо. Вичерпна ж документація може займати величезну кількість часу, якого, зазвичай, немає. Так, ідеально, коли все зібрано в одному документі. На практиці, це дуже залежить від проєкту. Проте вся ця інформація вам знадобиться для тестування.

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

І повертаючись до shift-left approach — простіше сісти за вимоги з ПО і розробником і все це поговорити до імплементації. Ніж отримати на тестування функціонал, зроблений по розпливчастим і не до кінця проясненим вимогам. Це не лише загальмує випуск функціонала, але й відобразиться на моралі команди.

Про “це і так всі знають”

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

втрачаються, і вже ніхто не пам’ятає, чому робимо саме так
починають перевикористовувати, не замислюючись, чому так.

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

Що можна зробити, якщо ти новачок на такому проєкті?

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

Таким чином можна створити базу знань для онбордингу та глибше розібратися у передумовах архітектурних (і не тільки) рішень.

Про здоровий глузд

Визначення каже, що це

базовий рівень практичних знань і суджень, які необхідні всім нам, щоб допомогти нам жити розумно і безпечно

В контексті продукту, це можуть маленькі речі, які не документують, тому що загальновідомо що: температура тіла вимірюється у градусах Цельсія, швидкість у кілометрах на годину, формат дати це день-місяць-рік, а для імені користувача вистачить трьох полів — прізвище, ім’я, по батькові.

А тепер подивіться на цей список, такий зрозумілий для нас. І уявіть, що клієнт у вас зі Штатів або ЮК.

До речі, як вважаєте, треба документувати такі речі чи ні?

Інший приклад: кнопка Yes має бути зеленою, а No – червоною. Червона кнопка Yes заплутає користувача.

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

Ще приклад: два-три кольори тексту на вебсайті — допомагають візуально виділити цікавинки, десять кольорів зроблять текст складним для сприйняття.

Що робити, якщо однієї бази знань немає, і вимоги розпилені де тільки можливо?

Не все треба змінювати

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

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

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

Збирати самому

Для кожної фічі можна створити окремий документ чи вкладку і додавати туди все, що видається важливим. Окремо можна записувати свої питання чи коментарі, які точно з’являться.

Разом з розробниками обговоріть свої думки та разом додайте те, що допоможе якісно протестувати фічу.

Також буде корисно показати записи й питання PO/PM/BA, щоб уточнити, чи правильно ви розумієте що і як має бути зроблено.

Якщо у команді є практика писати тест кейси, це стане гарним фундаментом.

Якщо ні, то як наступний рівень складності — збери записи у чекліст або аксептанс критерії. І потихеньку формуй у команди корисну звичку мати таку штуку для кожної фічі. Головне на старті – keep it simple, щоб зберегти баланс між витраченим часом і користю.

Поговоріть з командою

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

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

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

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

Матеріали

Поширюй: