Тестування документації (Documentation testing)
Погана документація може вплинути на якість продукту. Тестування артефактів, розроблених до, під час та після тестування продукту, називається тестуванням документації. Це нефункціональний тип тестування програмного забезпечення. Ми знаємо, що дефекти, виявлені на етапі тестування, є дорожчими, ніж якби вони були виявлені на етапі вимог. Вартість виправлення помилки збільшується тим більше, що пізніше ви знайдете її. Таким чином, тестування документації може розпочатися з самого початку процесу розробки програмного забезпечення, щоб заощадити велику суму грошей. Деякі артефакти, що часто перевіряються:
Requirement documents
Test Plan
Test case
Traceability Matrix (RTM)
Техніки тестування вимог:
Взаємний перегляд (peer review). Взаємний перегляд («рецензування») є однією з технік тестування вимог, що найбільш активно використовуються, і може бути представлений в одній з трьох наступних форм (у міру наростання його складності і ціни):
Побіжний перегляд (walkthrough) може виражатися як у показі автором своєї роботи колегам з метою створення загального розуміння та отримання зворотного зв'язку, так і в простому обміні результатами роботи між двома та більше авторами для того, щоб колега висловив свої питання та зауваження. Це найшвидший, найдешевший і найчастіше використовуваний вид перегляду. Для запам'ятовування: аналог швидкого перегляду - це ситуація, коли ви в школі з однокласниками перевіряли перед здаванням твору один одного, щоб знайти описки і помилки.
Технічний перегляд виконується групою фахівців. В ідеальній ситуації кожен фахівець має представляти свою галузь знань. Тестований продукт не може вважатися досить якісним, поки хоча б у одного переглядача залишаються зауваження. Для запам'ятовування: аналог технічного перегляду - ситуація, коли якийсь договір візує юридичний відділ, бухгалтерія тощо.
Формальна інспекція (inspection) є структурованим, систематизованим і документованим підходом до аналізу документації. Для його виконання залучається велика кількість фахівців, саме виконання займає чимало часу, і тому цей варіант перегляду використовується досить рідко (як правило, при отриманні на супровід та доопрацювання проекту, створенням якого раніше займалася інша компанія). Для запам'ятовування: аналог формальної інспекції – це ситуація генерального прибирання квартири (включаючи вміст усіх шаф, холодильника, комори тощо).
Запитання . Наступною очевидною технікою тестування та підвищення якості вимог є (повторне) використання технік виявлення вимог, а також (як окремий вид діяльності) – питання. Якщо хоч щось у вимогах викликає у вас нерозуміння чи підозра – запитуйте. Можна спитати представників замовника, можна звернутися до довідкової інформації. З багатьох питань можна звернутися до досвідченіших колег за умови, що вони мають відповідну інформацію, раніше отриману від замовника. Головне, щоб ваше питання було сформульоване таким чином, щоб отримана відповідь дозволила покращити вимоги;
Тест-кейси та чек-листи. Ми пам'ятаємо, що хороша вимога є перевіреною, а отже, повинні існувати об'єктивні способи визначення того, чи правильно реалізовано вимогу. Продумування чек-листів чи навіть повноцінних тест-кейсів у процесі аналізу вимог дозволяє нам визначити, наскільки вимогу перевіряємо. Якщо ви можете швидко вигадати кілька пунктів чек-листа, це ще не ознака того, що з вимогою все добре (наприклад, воно може суперечити якимось іншим вимогам). Але якщо жодних ідей щодо тестування вимоги на думку не спадає - це тривожний знак. Рекомендується спочатку переконатися, що ви розумієте вимогу (зокрема прочитати сусідні вимоги, поставити запитання колегам тощо.). Також можна поки що відкласти роботу з цією конкретною вимогою і повернутися до неї пізніше - можливо, аналіз інших вимог дозволить вам краще зрозуміти, і це конкретне. Але якщо ніщо не допомагає – скоріш за все, з вимогою щось не так. Задля справедливості слід зазначити, що на початковому етапі опрацювання вимог такі випадки трапляються дуже часто - вимоги сформовані дуже поверхово, розпливчасто і явно потребують доопрацювання, тобто. тут немає необхідності проводити складний аналіз, щоб констатувати неперевірюваність вимоги. На стадії ж, коли вимоги вже добре сформульовані та протестовані, ви можете продовжувати використовувати цю техніку, поєднуючи розробку тест-кейсів та додаткове тестування вимог. що на початковому етапі опрацювання вимог такі випадки трапляються дуже часто - вимоги сформовані дуже поверхово, розпливчасто та явно потребують доопрацювання, тобто. тут немає необхідності проводити складний аналіз, щоб констатувати неперевірюваність вимоги. На стадії ж, коли вимоги вже добре сформульовані та протестовані, ви можете продовжувати використовувати цю техніку, поєднуючи розробку тест-кейсів та додаткове тестування вимог. що на початковому етапі опрацювання вимог такі випадки трапляються дуже часто - вимоги сформовані дуже поверхово, розпливчасто і вочевидь потребують доопрацювання, тобто. тут немає необхідності проводити складний аналіз, щоб констатувати неперевірюваність вимоги. На стадії ж, коли вимоги вже добре сформульовані та протестовані, ви можете продовжувати використовувати цю техніку, поєднуючи розробку тест-кейсів та додаткове тестування вимог.
Дослідження поведінки системи . Ця техніка логічно випливає з попередньої (продумування тест-кейсів та чек-листів), але відрізняється тим, що тут тестуванню піддається, як правило, не одна вимога, а цілий набір. Тестувальник подумки моделює процес роботи користувача з системою, створеною за тестованими вимогами, і шукає неоднозначні або зовсім неописані варіанти поведінки системи. Цей підхід складний, вимагає достатньої кваліфікації тестувальника, але здатний виявити нетривіальні недоробки, які майже неможливо помітити, тестуючи окремо.
Малюнки (графічне уявлення) . Щоб побачити загальну картину вимог цілком, дуже зручно використовувати малюнки, схеми, діаграми, інтелект-карти тощо. Графічне уявлення зручне одночасно своєю наочністю та стислою (наприклад, UML-схема бази даних, що займає один екран, може бути описана кількома десятками сторінок тексту). На малюнку дуже легко помітити, що якісь елементи «не стикуються», де чогось не вистачає і т.д. Якщо ви для графічного представлення вимог використовуватимете загальноприйняту нотацію (наприклад, вже згаданий UML), ви отримаєте додаткові переваги: вашу схему зможуть легко розуміти і доопрацьовувати колеги, а в результаті може вийти хороше доповнення до текстової форми подання вимог.
Прототипування . Можна сміливо сказати, що прототипування часто є наслідком створення графічного уявлення та аналізу поведінки системи. З використанням спеціальних інструментів можна дуже швидко зробити нариси інтерфейсів користувача, оцінити застосовність тих чи інших рішень і навіть створити не просто «прототип заради прототипу», а заготівлю для подальшої розробки, якщо виявиться, що реалізоване в прототипі (можливо, з невеликими доробками) влаштовує замовника.
Докладний аналіз прикладу тестування вимог можна прочитати у книзі Святослава Куликова “Тестування програмного забезпечення. Базовий курс” у розділі 2.2.7. "Приклад аналізу та тестування вимог".
Джерела:
Дод. матеріал:
Last updated