Тестування вимог — перший крок у роботі над проектом. Тестування вимог відносять до нефункціонального виду тестування.

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

Доречно, кілька графічних схем для наглядності і кращого сприйняття інформації, особливо візуалам: 

Залежність вартість помилок у вимогах

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

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

Ще один малюночок за даними книги Стіва Макконела «Досконалий код». Пропонуємо за наданим посиланням, як потрібно, завантажити книгу Стіва Макконела «Досконалий код» 2 – ге видання

Схема допущення помилок у вимогах
Порівняльна схема розподілу помилок

Дивлячись на порівняльну діаграму, бачимо загальну частку помилок пов’язаних з вимогами ПЗ.

Що таке вимога?

З точки зору клієнта/замовника:

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

З точки зору клієнта/ кінцевого користувача аплікації:

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

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

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

Як ще класифікують вимоги?

  • Бізнес-вимоги;
  • Функціональні вимоги — вимоги, що описують функціональність проекту. Від джунів часте питання. А що таке функціональні вимоги? Ось, маєте: вимоги користувацького, аппаратного, програмного інтерфейсу тощо;
  • Нефункцірнальні вимоги;
  • За способом подачі вимоги можуть виражатися у вигляді текстових тверджень і графічних моделей;
  • Явні;
  • Неявні вимоги;
  • Вимоги за критеріїями ефективності, ризиками, критеріями безпеки та правильності системи т.п.

Проблеми вимог:

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

На противагу характеристики хороших вимог:

  • Перший критерій — це правильність. Мається на увазі, що кожна вимога має бути чітко описана і точно розроблена. Тобто кожна вимога має правильно й точно описувати те, що має бути розроблено. Недотримання цього критерію призводить до розробки неправильної функціональності. Ким тестується? Тут найскладніше: ми як виконавець у більшості випадків не можемо оцінити, чи ці вимоги є правильні, чи не правильні. Ми можемо мати доменну експертизу і щось радити, ми можемо дивитись на речі логічно і питати себе: а чи справді це має сенс? Відповідальність за те, щоб висунути правильні вимоги, несе замовник.  Але врешті-решт рішення приймає замовник. Хто платить гроші — той їх і затверджує.
  • Завершеність (анг. Complete) — вимога повинна містити всю інформацію, необхідну для розробників. Повнота вимог, це основний критерій готовності вимог і показник того, що можна розпочинати розробку.  Чому повнота дуже важлива? Тому що за повнотою в нас найчастіше іде scope. Замовник має бути впевнений, що він отримає те, що йому потрібно, і те, з чим він зможе досягнути своїх функціональних задач, своїх бізнес-задач. Які критерії? По-перше, всі вимоги мають бути задокументовані. І кожна вимога — містити всю необхідну інформацію для проектування, розробки і тестування рішень. Недотримання критерію повноти, зрозуміло ж, призводить до розповзання scope-робіт і незадоволення користувачів. А розповзання скопа — до усіх бюджетних, грошових та інших неприємностей.
  • Ясність (анг. Clear) — вимоги повинні бути зрозумілими, зі стандартною структурою речення. Тобто вимоги, які інтерпретуються по-різному, мають бути або перероблені, або видалені. Це однакова інтерпретація, відсутність двозначності вимоги; вимога описана чітко, зрозуміло і коротко; всі спеціальні терміни виписані та визначені. Гарний та поганий приклад. Вимога повинна містити достатню кількість інформації.
  • Коректність і узгодженість (анг. Unambiguous) — вимога повинна чітко вказувати на те, що повинен виконувати додаток. У вимогах не місце для припущень.

неоднозначні терміни, котрі категорично не можна вживати: залежності, швидко, повільно, можливо, наскільки можливо, нормально, оптимально, краще

  • Перевірятися (анг. Verifiable) — вимога повинна однозначно пі перевірки виконується вимога чи ні.
  • Необхідність (анг. Necessary) — не потрібно документувати вимоги заради галочки.
  • Реальність (анг. feasible) — визначається балансом між цінністю та необхідними ресурсами.
  • Модифікуватися — набір вимог повинен бути таким, щоб його можна було легко переписати 1 вимогу, при цьому не змінюючи вимоги в інших місцях. Окремі вимоги не повинні також суперечити одна одній
  • Простежуваність ( анг. consistently) — можливість відслідковувати зв’язок між вимогою та іншими артефактами проекту, кожна вимога повинна маркуватися унікальним ідентифікатором, за яким легко її простежити. Для цього також добре вимоги упорядковувати по важливості, терміновості для прикладу.

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

Тестування документації — що це таке?

Дехто, окрім тестування вимог розрізняє окрему парафію, яку називає тестування документації — та більшість фахівців вважають просто це дублюванням, бо як ми обговорювали вище на Agile проектах документації як такої не має. А як і є, то може бути на такій стадії що мало інформативна, в основі цих документів усе одно лежать вимоги. Вимоги беруть до уваги при проектуванні ПЗ, а потім ці ж самі вимоги використовуються в процесі перевірки ПЗ. Наприклад:

  • Технічне завдання;
  • Специфікації щодо архітектури та дизайну;
  • Проектна документація;

Проектна документація — включає у свою чергу продакт документацію, а також користувацькі інструкції та супровідну документацію, маркетингову документацію тощо. Отже, логічно

Тестування документації — це комплекс заходів опрацювання і співставлення того що у ній міститься з вимогами по функціоналу, зовнішньому вигляду, термінах виконання, compliance -ом (перевірка на відповідність із стандартами, нормативними актами з контролю якості) тощо

До теми хто не в курсі що таке Compliance : QA у ролі Compliance Officer — ЦІКАВО ?

Процес тестування вимог може передбачати розробку наступних доків:

1) Test plan
2) Test design and Test case specification
3) Test Strategy
4) Test summary reports
5) Weekly Status Report
6) User Documents/ manuals
7) User Acceptance Report
8 ) Risk Assessment
10) Bug reports
11) Test data
12) Test analysis ect

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

Найбільш часто застосовуваними тестувальниками є:

  • Test Plan
  • Test Scenario
  • Test Case
  • Traceability Matrix

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

Завдяки хорошій документації:

  • економимо на швидкості розробки, бо всі учасники проекту конкретно знають що повинні робити, завдяки документованим крокам-алгоритмам;
  • запобігаємо допущенню помилок розробником при написанні коду, якщо теж передбачити у документації чітко прописані інструкції по пунктах красномовні для нього;
  • цей пункт пов’язаний з попереднім, хороша документація страхує від переробок через невідповідність вже реалізованого функціоналу, відповідно до записаних вимог. Зробили, не те що потрібно — ай-яй-яй теж буває 🙂 Наявність такого дефекту у документації прямо пропорційно призводить до значн-о-г-о збільшення фінансових видатків і часу, витраченого на виправлення допущених помилок. Дана обставина стосуються перш за все бізнес-цілей проекту порятунок ТОП 3-х складових часу-витрат-грошей;

Окрім, усунення перерахованих ризиків невідповідностей, тестування документації може вирішити важливі питання:

  • скорочення часу на тестування — наскільки якісніше описана функціональність, тим простіше її протестувати у повному обсязі;
  • зокрема скорочення часу на приймальне тестування та самої передачі в експлуатацію програмного продукту — свого роду документація виступає у ролі контракту;
  • скорочення витрат на подальшу технічну підтримку (за рахунок швидкого пошуку відповідей у ​​документації);
  • скорочення витрат та часу на розробку нової функціональності за потреби;

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

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

Але у реальності зазвичай у тестувальників зовсім то не так все … Комплект технічної документації, як такий переважно узагалі відсутній.

Часто наші студенти, та й узагалі тестувальники джуни задають питання:

— А що якщо не має документації узагалі? Що мені робити?

Відповідь проста: Узяти її та зробити з нуля, а що? Слабо? Потім і самому буде легше у роботі.

Головні джерела для створення документації:

  • код програми
  • прототип програми
  • вимоги

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

Як бути з проектами fix price?

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

Кілька прикладів із повсякденного досвіду стосовно важливості і необхідністі ведення документації:

Скандальний клієнт пред’являв свої Фе!!! по проекту, і в першу чергу звинуватили QA. Питання стосувалося сумісності функціоналу веб-сайту. Команді пощастило, були докази того, що дана вимога не зазначалася у документації, й тому дана розбіжність не перевірялася.

 Китайське прислів’я — “Чорнило надійніше за пам’ять!” 

 
Наступного разу надали тестувати продукт, який мав трохи заплутану функціональність. А якщо чесно не реально зрозуміти, як використовувати його без інструкцій або доп. навчання.  І щоб попрацювати з ним тестувальники стали просити PM -а довідкові документи, а відповідь “Ні, не має жодних документів. Тестуйте як хочете!” Зустрічне питання, а як юзеру розібратися з програмою, якщо тестувальники не в силі? Та ще й на цьому продукті збираються заробляти гроші?

Також, багато людей прямо без будь-якого сорому говорять: “Я не маю ні часу, ні бажання, коли не має готової документації з нею возитися. Хай робить документацію, пише тест-кейси, тест-план, summary bug report, якусь проектну документацію, той хто має багато вільного часу. Я просто тестую і скидаю Баги у Джіру. А уявлення про тестування документації у мене загальне теоретичне ще з курсів. Погодьтеся підхід не Ахті )))

Працювати з документацією / над документацією — повинно бути гарною звичкою.

 

Переваги ведення документації для самих тестувальників:

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

А що ж таке химерне «Якість документації»?

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

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

 

Приклади типових дефектів, які знижують якість та цінність документації:

 

  • документація занадто об’ємна, як книга “Война і мір”;
  • навпаки документація не повна, з неї нічого не зрозуміло;
  • протиріччя пунктів / розділів у документах один-одному;
  • недостатня деталізація вимог, звідси їх неоднозначна інтерпретація;
  • граматичні помилки;
  • невдале оформлення, немає покажчика, змісту, щоб можна було швидко знайти потрібне місце, немає глосарію, зносок, словника, де могли бути вказані всі незнайомі терміни.

Техніки застосовувані до тестування документації та вимог:

Тестувач може вказати на логічні помилки в постановці задач, невідповідності в вимогах, а також скласти чек-лист, перелік перевірок за наданим вимогами наступними способами:

Біглий перегляд — швидке ознайомлення з документацією.

Технічний перегляд — це вже уважна вичитка документації, подекуди групою фахівців колег з (Text Writer, BA, PM, Team Lead, Dev)  що представляють різні області.

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

Консультування, співпраця з колегами — показ роботи QA колегам з метою отримання зворотної зв’язку, запитань та зауважень. Всі відгуки й зауваження допоможуть поліпшити кінцеву версію документу. Документ / вимоги не можуть бути якісними, поки хоча б у одного з фахівців є зауваження.

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

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

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

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

Оформлення результатів тестування

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

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

Формат оформлення правил перевірки в методиці передбачав мінімум дій за заповненням: щоб потрібно було тільки вказати, в документі чи дотримуються вимоги правил (так / ні) і якщо виявлено невідповідність — вказати номер сторінки. Таким чином, знижується трудомісткість документації і одразу формувався готовий звіт.

Проте, як таких підходів до шаблонів документації в IT явним чином не визначено. Кожен має право оформляти принципі програмну документацію як бажає. Тому категорично казати, що є правильним і неправильним не можна. Щоправда до документації існують стандарти:

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

Корисні поради тестувальнику

На завершення наведено 10 простих порад, які допоможуть документації досягти цілей:

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

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

#3. Створення та підтримка стандартних шаблонів тестування документації класна штука, ще краще коли QA їх реально використовують. Це може бути хоч шаблон тест-кейсів, use-case у Excel

#4. Перед тим, як записати можливі тест-кейси, переконайтеся в тому, що Ви розумієте вимогу. Незабувайте про тестування контексту.

#5. Не тільки створюйте документацію, але й оновлюйте її, коли це потрібно.

#6. Те саме зміна, корегування вимог важлива фаза проекту не забудьте додати, оновлювати їх список теж.

#7. Слідкуйте за системою керування версіями. Це допоможе легко manage and track документи.

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

#9. Документуйте так, щоб документ був зрозумілий не тільки Вам. Будьте готові завжди надати документацію на вимогу зацікавленій особі. Це дуже добре коли замовник активно бере участь у розробці проекту, приймає кожен новий реліз;

#10. Поділіться всіма документами, пов’язаними з проектами, в одному місці, доступному кожному члену команди для довідки, а також для оновлення, коли це необхідно.

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

Підсумки:

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

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

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

Related posts

Командний рядок

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

Сьогодні я розповідатиму про один із най-най-най необхідних інструментів для будь-якого тестувальника,...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.