Тестування вимог — перший крок в роботі над проектом
Ця доповідь виникла з потреби систематизувати знання, що стосуються роботи з вимогами в Neadevis, з одного боку, а з іншого — показати, яким чином ми працюємо з проектами fix price, які ризики та особливості ми намагаємось мінімізувати як компанія, що займається аутсорсинговою діяльністю, і, як наслідок, надавати хороший сервіс для наших клієнтів. Доповідь доволі стара — 2010 року. І хочеться, щоб ми поглянули на питання роботи з вимогами з висоти пташиного польоту й водночас заглибились у деякі конкретні приклади того, яким чином тестуються вимоги, які є інструменти тестування, які є, передусім, категорії, за якими вимірюється якість вимог.
Отже, ми поговоримо про методи тестування вимог, про критерії, за якими оцінюється якість вимог, і зробимо певні висновки. Давайте поглянемо на цей процес і спробуємо зрозуміти, навіщо взагалі все це відбувається в принципі — для чого нам тестувати вимоги?
До нас часто надходять запити клієнтів. Вони бувають більш сформованими, більш формалізованими чи менш формалізованими. І ми намагаємося з ними розібратись таким чином, щоби отримати на вході документ, який можна достатньо добре оцінити та на основі цього ініціювати розробку.
Отже, які в нас є передумови перед тим, як почати тестувати вимоги? Вони проаналізовані й задокументовані аналітиком, тобто є щось, з чим ми можемо працювати. Аналітик, в даному випадку — це роль, а не конкретна людина. Аналітик самостійно проводить певну оцінку та перевірку цих вимог. Під час тестування вимог відбувається наступний процес: всі зацікавлені особи підтверджують, що вимоги коректні, зрозумілі і достатні для того, щоб розпочинати роботу. А користувачі підтверджують, що вимоги відображають їхні потреби в роботі. Основним критерієм готовності вимог є те, чи містять вимоги достатньо інформації для того, щоб розпочинати розробку. І важливо відзначити, що і замовник, і користувачі, і проектна команда, якою планується робота над проектом, — всі беруть участь у тестуванні вимог і враховують різні пов’язані з тестуванням вимог аспекти.
Методи тестування вимог
Тестування вимог дозволяє зменшити кількість допрацювань і змін. Тобто ми заздалегідь придивились до того, що нам потрібно зробити, вивчили деякі речі, які в майбутньому підвищують ризик краху проектів та унеможливлюють зміни. Це хороший процес, що дозволяє цілій команді ознайомитися і зрозуміти, що ж ми будемо будувати. Давайте поглянемо, які існують методи тестування вимог. Їх є три.
Перевірка документації
Цей метод дозволяє перевірити вимоги на правильність, повноту, відслідковуваність, важливість, зрозумілість, однозначність та вимірюваність. Виконується перевірка документації в достатньо простий спосіб. Тобто ми дивимося, читаємо і перед тим, як знайомитися з вимогами, задаємо собі правильні питання, звертаємо увагу на певні речі, про які я скажу пізніше, — і тим самим перевіряємо вимоги. Документація приймається замовниками, аналітиками, проектними менеджерами, тестувальниками.
Як один із прикладів, які можна навести — це формальний checklist, що містить перелік параметрів, аспектів, критеріїв тощо — всього, на що необхідно перевіряти вимоги.
Сильні сторони.
Скоріш за все, це класний метод, тому що ним дуже легко і просто користуватися, і він не має якихось спеціальних вимог. Покриває досить велику кількість критеріїв якості та потребує невеликих трудовитрат, порівняно з іншими варіантами.
Слабкі сторони.
Якість проекту дуже залежить від того, хто перевіряє. Якщо він читає уважно, то багато питань підніме і задасть. Якщо він читає неуважно — результат буде відповідним.
Потребується залучення різних спеціалістів. І останнє — необхідний якийсь документ, якийсь артефакт з формалізованими вимогами. Без цього артефакту складно здійснювати таку перевірку.
Ось приклад із власної практики, в даному випадку в ролі аналітика. Коли я працював аналітиком, для мене завжди було вкрай важливо, щоб і проектна команда, і замовник детально ознайомились із вимогами. Коли даєш документ на 90 сторінок — це не завжди просто. Тому я іноді включав певні речі, які допомагали переконатися, чи прочитаний документ. Наприклад, я обіцяв пиво тим, хто дійде до визначеного місця в документі. Були випадки, коли на етапі узгодження вимог на одному з моїх місць роботи вимоги узгоджував головний бухгалтер, який їх читав, узгоджував, розумів, що все в порядку, а потім говорив, що ні — «мене зрозуміли неправильно», і під кожним словом розумів інше. Тобто цей документ хороший, проте не дає стопроцентної гарантії якості.
Аналіз поведінки системи
Це метод, коли ми формалізуємо події, тобто формуємо вимоги у форматі «вхід — вихід», «подія — наслідок», «умова — відповідь». Щось подається на вхід до системи, з системою щось відбувається, і вона має дати щось на виході. Найпоширеніший спосіб, у який це відбувається, — це або тест-кейси, або юз-кейси. Тест-кейси готують тестувальники, юз-кейси — зрозуміло, готують аналітики. Як і в будь-якого методу, у нього є і плюси, і мінуси.
Сильні сторони.
Цей інструмент дуже добре дозволяє перевіряти вимоги на повноту, зрозумілість та однозначність. Я пам’ятаю, як найпідступніші, найцікавіші питання починали з’являтися в мене саме тоді, коли тестувальник починав писати тест-кейси — і в цей момент ми реально починали розуміти, що ж у цих вимогах написано, які є підводні камені, які можливі випадки, що могли б нам пізніше зіпсувати проект. Вміння написати тест-кейси і юз-кейси дозволяє подати вимоги у структурованій формі, на основі чого програмістам легко програмувати, а тестувальникам — тестувати.
Слабкі сторони.
Написання сценаріїв, точніше аналіз поведінки системи потребує величезної кількості часу і спеціальної підготовки. Ми не можемо дозволити працювати з вимогами звичайному працівникові.
Прототипування
Це ще один інструмент (і метод) тестування вимог.
Під прототипом ми розуміємо створення майбутньої моделі системи. Прототипування застосовується для перевірки вимог на повноту, правильність, реалізовуваність і на зручність використання користувацького інтерфейсу (якщо ми говоримо про розробку інформаційної системи).
Фактично, це чи не єдиний спосіб перевірити вимоги на реалізовуваність і на зручність користування інтерфейсом. Використовується аналітиками — найчастіше, а також архітекторами. Є різні приклади прототипів:
Горизонтальний — це модель якомога більшої кількості спектрів системи. Дуже часто ми це спостерігаємо, коли фахівці з користувацької поведінки проектують якісь нові мобільні додатки — тобто коли хочеться показати красиву картинку.
Вертикальний — коли докладно прототипується певна вузко спрямована модель або функція системи.
Також прототипи можуть бути throw-away, які ми зробили і потім викинули. Або ж еволюційний прототип, який ми зробили і який далі буде розвиватись.
З прикладів, які були у мене. Ми часто використовуємо прототипи, щоб перевірити, чи зможемо ми взагалі технічно щось зробити. І коли все виходить добре — тоді це приклад еволюційного прототипу, який ми далі нарощуємо і розвиваємо.
Сильні сторони.
Користувач отримує можливість справді побачити індивідуальне рішення. З багатьма користувачами неможлива дискусія на тему «має бути форма, на якій буде 1, 2, 3, 4, 5». Доки ти не намалюєш, не покажеш, яким воно буде у дійсності — вони не зрозуміють, що це має бути. Тобто у них з’являється чудова можливість побачити рішення — а це прекрасний наглядний посібник для розробників і тестувальників: не потрібно багато писати і говорити, чи відповідає система прототипу, чи ні — цього в більшості випадків буде достатньо.
Слабкі сторони.
Перш за все, потрібно зрозуміти, що створення хорошого прототипу вимагає значних часових витрат. І також потрібна спеціальна підготовка, зокрема, якщо йдеться про розробку еволюційного прототипу.
У деяких проектах ми йдемо за принципом: давайте зробимо proof of concept (POC), поглянемо, як воно працює, що і як відбувається, і якщо воно нас влаштовує, то лише тоді ми переходимо до самої роботи.
Що хочеться сказати у підсумку про методи? Інструменти тестування вимог не є відкриттям для більшості спеціалістів (це не rocket science) — ми всі цим користуємося щоденно у своїй роботі. Інакше ми б дуже важко досягали тих цілей у проектах, які перед нами стоять.
Друге. Повнота вимог — це основна характеристика вимог, на перевірку яких спрямована більшість змін. Чому повнота дуже важлива? Тому що за повнотою в нас найчастіше іде scope. Замовник має бути впевнений, що він отримає те, що йому потрібно, і те, з чим він зможе досягнути своїх функціональних задач, своїх бізнес-задач. Так само й ми як виконавці хочемо бути впевненими, що ми нічого не пропустили, і що потім у нас не буде болючих розмов — було це в скопі чи ні, як ми це розуміли і тому подібне.
І ще одне, для того, щоб ефективно тестувати вимоги, важливо залучати різних спеціалістів.
Критерії оцінки якості вимог
Ми будемо говорити про критерії, які не залежать від проекту — від контексту проекту і технології, і так само про ті, які залежать від проекту і технології.
Правильність
Перший критерій — це правильність. Мається на увазі, що кожна вимога має бути чітко описана і точно розроблена. Тобто кожна вимога має правильно й точно описувати те, що має бути розроблено. Недотримання цього критерію призводить до розробки неправильної функціональності.
Як тестується вимога за цим критерієм? Перевіркою документації або прототипом на правильність.
Ким тестується? Тут найскладніше: ми як виконавець у більшості випадків не можемо оцінити, чи ці вимоги є правильні, чи не правильні. Ми можемо мати доменну експертизу і щось радити, ми можемо дивитись на речі логічно і питати себе: а чи справді це має сенс? Але врешті-решт, відповідальність за те, щоб висунути правильні вимоги, несе замовник. Так працюють у моделі чистого аутсорсингу. Якщо ми представляємось як subject-matter експерти в тих доменах, в яких ми розбираємось, то ми маємо право і можемо челенджити правильність вимог. Але врешті-решт рішення приймає замовник. Хто платить гроші — той їх і затверджує.
Ось приклад. Чи знаємо ми, що дане кубічне рівняння вирішуване? Не знаємо. Віримо тому, хто нам цю задачу поставив.
Повнота вимог
Найбільший головний біль і проблема — це повнота (чи неповнота) вимог.
Які критерії? По-перше, всі вимоги мають бути задокументовані. І кожна вимога — містити всю необхідну інформацію для проектування, розробки і тестування рішень. Недотримання критерію повноти, зрозуміло ж, призводить до розповзання scope-робіт і незадоволення користувачів. А розповзання скопа — до усіх бюджетних, грошових та інших неприємностей.
Чому критерій не досягається? Я бачу чотири причини.
Відсутність уявлення про те, що ж ми реально збираємось будувати. Тобто ми програмуємо-програмуємо, але не розуміємо, для чого це, не розуміємо, які функції воно зв’язує і т.п.
Інші причини: недостатня увага до контексту системи, недостатній аналіз вимог та відсутність відповідальності.
Як тестується?
Задаванням питань користувачам. Які ще є неописані та неусвідомлені вимоги? Що не так в поточній системі або в поточних бізнес-процесах? Що ви потребуєте виправити?
Ми створюємо моделі поведінки системи, а в деяких випадках розробляємо прототипи, в тому числі користувацького інтерфейсу, й аналізуємо контекст, в якому буде використовуватися система. Тестується вимога за цим критерієм користувачами і тестувальниками.
Приклад: система повинна розв’язувати квадратне рівняння за такою-то формулою. Чи є ця вимога повною? Виникає безліч питань. Наприклад, що відбуватиметься з від’ємним дискримінантом? Яким чином ми будемо виводити результати? Яким чином будемо вводити дані?
Хочеться навести ще приклад, коли неуважне ставлення до контексту системи (або, навпаки, уважне) дозволяє перевірити багато вимог. На одному з моїх місць роботи, в одному з проектів замовник хотів розробити систему узгодження договірної документації. І коли ми оцінювали scope, було чітко зрозуміло, що робити — узгоджувальник перший, другий, третій; деякі узгодження були послідовними, деякі паралельними — все було добре. Але ми достатньо довго спілкувалися з користувачами і розуміли, що кожен із них, з одного боку, хоче відчувати власну важливість, з іншого — хоче убезпечитися від можливих неправильних рішень, можливо, передати узгодження договірної документації під відповідальність комусь іншому.
Тому найбільший біль і найбільша проблема в даному випадку виникала щодо того, яким чином будуть відбуватися відхилення від неузгодження документів. Тобто всім було зрозуміло, як працює основний процес, але не було зрозуміло, як працює зворотній процес. Саме тому, що ми відчували цей контекст, ми змогли правильно підняти питання і вибудувати правильний бізнес-процес ще до того, як запустимо систему, щоб зробити це з мінімальними змінами. Основна дискусія була про те, щоб не прийняти неузгодження договірного документу, які — попередні чи наступні — узгодження потрібно відмінити. Ця дискусія і увага до контексту дозволили нам уникнути дуже багатьох неприємностей і вивести цілий пласт вимог, які мали бути адресовані.
Зрозумілість
Наступний критерій — це зрозумілість вимог.
Тобто вимоги, які інтерпретуються по-різному, мають бути або перероблені, або видалені.
Що таке опис критерію? Це однакова інтерпретація, відсутність двозначності вимоги; вимога описана чітко, зрозуміло і коротко; всі спеціальні терміни виписані та визначені. Недотримання критерію призводить до необхідності переробляти роботу, до розширення скопу та інших найрізноманітніших неприємностей.
Тестується найчастіше перевіркою специфікації. Ми перевіряємо специфікацію на те, чи всі вимоги з предметної області описані та чи кожен із термінів, які зустрічаються у специфікації, відповідають своєму визначенню.
Тестується тестувальниками і розробниками. Тим, хто пише вимоги, предметна область найчастіше зрозуміла.
Несуперечливість
Тобто важливо впевнитись, що реалізація однієї вимоги не перешкоджає реалізації іншої вимоги.
Наприклад, ми хочемо кнопку квадратну або круглу. Тобто ми можемо зробити перше або друге, але не третє. Суть вимоги полягає в тому, що вона може бути реалізована без конфлікту з іншими вимогами.
Недотримання цього критерію призводить до необхідності переробляти роботу.
Тестується тестувальниками, розробниками, аналітиками.
Вимога не повинна визначати технічне рішення
Це важливий критерій, про який нечасто згадують, а проте він є важливим питанням у сфері функціональності: вимога не повинна визначати технічне рішення. Тобто важливо розділяти нав’язування технічного рішення і відправні обмеження, які є в компанії. Вимога має бути сформульована так, щоб надавати широкий вибір варіантів її реалізації.
Недотримання критерію призводить до створення неефективного рішення і до втрати реальних вимог, які існують у замовника. Вимоги не втілюються з кількох причин. Наприклад, тому, що користувачі вважають, ніби їхня роль — у прийнятті рішень щодо дизайну системи. Вони не усвідомлюють і не говорять про свої реальні потреби.
Наведу один з прикладів із практики. В одному з останніх проектів замовник сказав, що мобільний додаток повинен сформувати pdf-документ і відправити його на пошту замовникові. Ми почали копати, що за цим відбувається. Насправді на смартфоні має бути підписаний якийсь документ, схожий на паперовий, і потім клієнту на пошту має прийти pdf-версія цього підписаного документа. Тобто це були реальні вимоги, які ховались за тим, що мобільний додаток має відправляти pdf. Звичайно ж, розуміння цієї ситуації дозволило нам зробити інший дизайн: щоб мобільний додаток збирав підпис, генерував документ, не схожий на pdf і давав інформацію на сервер — а тоді вже сервер формував pdf-документ, який би надходив до клієнта. Ось ці всі речі необхідно дуже правильно перевіряти.
Тестується розробниками і архітекторами.
Вимірюваність
Наступний критерій — це вимірюваність вимог. Вимога, яку неможливо виконати, повинна бути перероблена або вилучена. Що мається на увазі? Вимога має бути сформульована таким чином, щоб можна було довести відповідність системи пред’явленій вимозі. Вимога не повинна містити невимірюваних характеристик або таких, які не піддаються тестуванню.
Мій улюблений приклад нетестувальної характеристики — «мінімалістичний зручний дизайн». В такому критерії дуже складно розуміти, що є «мінімалістичним» дизайном, що є «красивим» дизайном і т. д. Це дуже спантеличує. Інший приклад погано вимірюваних вимог: «при вивантаженні приблизно двохсот активів система повинна відгукуватися через
Тестується тестувальниками.
Ми поговорили про вимоги, які в принципі не залежать від проекту і технології. Але є також критерії, що залежать від проекту і технології.
Досяжність
Отже, вимога повинна бути досяжною. Треба розуміти і планувати результат реалізації кожної вимоги. Мається на увазі, що якщо вимога технічно реалізовувана — то її реалізація вписується в часові й фінансові обмеження проекту. Недотримання цього критерію призводить до зірвання строків та перевитрат бюджету. Тестується за допомогою оцінки трудовитрат на реалізацію вимоги. В даному випадку це відповідальність проектного менеджера.
Дуже часто є клієнти, у яких є класні фантазії, вони хочуть багато всього реалізувати. Коли розумієш, чого це буде коштувати і скільки часу витратиться — ОК, мабуть не зараз.
Свіжий приклад. Один із достатньо зрілих, сеньйорних замовників організації високого рангу не мав сумніву, що певну систему легко можна зробити такою ж красивою, як і додатки Apple. Він говорив про останні тренди в технологіях і про те, що ми повинні розробити чудовий, вражаючий дизайн. І тільки аргументи про те, скільки коштує розробка цього чудового якісного дизайну, повернули його в адекватний вимір.
Реалізовуваність
Це про те, що вимога взагалі-то технічно може бути виконана. Адже існують як організаційні, так і технічні обмеження.
Недотримання критерію призводить до зриву термінів робіт і неможливості реалізувати проект в цілому. Тут найчастіше допомагають вертикальні прототипи, коли ми певні речі на початку хочемо спробувати, впевнитись, що вони працюють, та дослідити обмеження у використовуваних технологіях. Це основна задача архітекторів та розробників. Це для того, щоб впевнитися: ми зможемо це зробити.
Важливість (пріоритетність)
Принцип Парето всі чули, і всі про нього знають. При розробці бережливого стартапу відомий концепт MVP (minimum viable product) — коли ми хочемо виконати перш за все ті вимоги, які вирішують найбільше завдань (тобто 20% вимог, які вирішують 80% задач, поставлених перед системою). Це складна дискусія. І багато колег, які займаються розробкою стартапів, часто стикаються з тим, що деякі речі, здавалось би, недоцільні, власник бізнесу смакує з відчуттям значимості.
Отже, що значить важливість? Що у кожної вимоги є пріоритет, що позначає важливість вимоги у релізі. І має бути можливість прослідкувати зв’язок кожної з вимог з цілями і задачами проекту. Недотримання критерію призводить до неможливості гнучко управляти змінами і взагалі — до неможливості повністю вирішити бізнес-задачу. Критерій не досягається, коли користувачі створюють вимоги «про запас».
Вимоги тестуються на пріоритетність замовником і проектним менеджером.
Відслідковуваність
Кожна вимога може бути співставлена з елементом системи, де вона має бути реалізована. Кожна системна вимога може бути співставлена з бізнес-потребою (і навпаки).
Недотримання критерію відслідковуваності призводить до неможливості ефективно управляти процесом зміни вимог (важливі вимоги можуть бути втрачені, а менш значні навпаки — реалізовані). Критерій не досягається через надто складну структуру вимог.
Тестується аналітиками і замовниками способом перевірки системних вимог на наявність посилань на бізнес-вимоги.
На завершення хочеться сказати:
- Вимоги необхідно тестувати. Якщо у вас хороші вимоги на старті — у вас буде хороший результат на виході.
- Вимагайте багато критеріїв, яким вони повинні задовільняти.
- Тестування вимог проводьте із залученням широкого кола спеціалістів — як зі сторони замовника, так і зі сторони виконавця.
Цікаво, яким чином ви тестуєте вимоги, на які критерії ви звертаєте увагу? Будь ласка, діліться у коментарях.
