how create requirements traceability matrix
Шта су захтеви Матрица следљивости (РТМ) у тестирању софтвера: Водич по корак по корак за стварање Матрице следљивости са примерима и узорком шаблона
Данашњи водич говори о важном КЦ алату, који је или превише поједностављен (читати превиђен) или превише наглашен - тј. Матрица следљивости (ТМ).
Најчешће, израда, преглед или дељење матрице следљивости није један од примарних резултата процеса осигурања квалитета - тако да није претежно концентрисан на њега, што доводи до недовољног нагласка. Супротно томе, неки клијенти очекују да ТМ открије разорне аспекте свог производа (на тесту) и разочарани су.
„Када се користи правилно, матрица сљедивости може бити ваш ГПС за ваше КА путовање“.
Као што је то општа пракса у СТХ , видећемо аспекте „Шта“ и „Како“ ТМ-а у овом чланку.
Шта ћете научити:
- Шта је матрица сљедивости захтјева?
- Испитајте покривеност и следљивост захтева
- Како створити матрицу сљедивости захтјева
Шта је матрица сљедивости захтјева?
У Матрици следљивости захтева или РТМ поставили смо поступак документовања веза између корисничких захтева које је клијент предложио до система који се гради. Укратко, то је документ на високом нивоу за мапирање и праћење захтева корисника са тест случајевима како би се осигурало да се за сваки захтев постигне одговарајући ниво тестирања.
Процес прегледа свих тест случајева који су дефинисани за било који захтев назива се сљедивост. Следљивост нам омогућава да утврдимо који захтеви су произвели највећи број недостатака током процеса испитивања.
Фокус сваког тестирања је и треба да буде максимална покривеност тестом. Покривеност једноставно значи да морамо да тестирамо све што треба да се тестира. Циљ било ког пројекта тестирања треба да буде 100% покривеност тестом.
Матрица сљедивости захтјева успоставља начин да осигурамо да провјере ставимо на аспект покривености. Помаже у стварању снимка како би се идентификовале празнине у покривености. Укратко, такође се може назвати метриком која одређује број покренутих, положених, неуспелих или блокираних тест случајева, итд. За сваки захтев.
Зашто је потребна следљивост захтева?
Матрица сљедивости захтјева помаже у повезивању захтјева, Тест случајева , и тачно оштећен. Цела апликација се тестира тако што има следљивост захтева ( Енд то Енд тестирање примене).
како пријавити ред у јави
Следљивост захтева обезбеђује добар „квалитет“ апликације пошто се тестирају све функције. Контрола квалитета може се постићи када се софтвер тестира на непредвиђене сценарије са минималним недостацима и задовољењем свих функционалних и нефункционалних захтева.
Матрица матрице сљедивости захтјева за тестирање софтверске апликације у предвиђеном временском трајању, опсег пројекта је добро утврђен и његова реализација је постигнута у складу са захтјевима и потребама купаца, а трошак пројекта је добро контролисан.
Пропуштања оштећења су спречена јер се целокупна апликација тестира у складу са својим захтевима.
Врсте матрице сљедивости
Следљивост унапред
У „Захтеви за праћење унапред“ у тестовима. Осигурава да пројекат напредује у жељеном правцу и да се сваки захтев темељито тестира.
Следљивост уназад
Тест случајеви су мапирани са захтевима у „Следљивост уназад“. Његова главна сврха је осигурати да тренутни производ који се развија буде на правом путу. Такође помаже да се утврди да се не додају никакве неспецификоване функционалности и тиме утиче на обим пројекта.
Двосмерна следљивост
(Напред + назад): Матрица добре следљивости садржи референце од тест случајева до захтева и обрнуто (захтеви за тест случајеве). Ово се назива „двосмерна“ следљивост. Осигурава да се сви тестови могу пратити у складу са захтевима и сваки наведени захтев има тачне и важеће случајеве испитивања за њих.
Примери РТМ-а
# 1) Пословни услови
БР1 : Опција писања е-поште би требала бити доступна.
Тест сценариј (техничка спецификација) за БР1
ТС1 : Обезбеђена је опција Нова порука.
Тест случајева:
Тест случај 1 (ТС1.ТЦ1) : Опција Нова порука је омогућена и успешно ради.
Тест случај 2 (ТС1.ТЦ2) : Опција Нова порука је онемогућена.
# 2) Дефекти
Након извршавања тест случајева ако се утврде било који недостаци који се такође могу навести и мапирати са пословним захтевима, тест сценаријима и тест случајевима.
На пример, Ако ТС1.ТЦ1 не успе, тј. Опција Састави пошту иако омогућена не ради исправно, квар се може евидентирати. Претпоставимо да је аутоматски генерисани или ручно додељени број квара Д01, а затим се то може пресликати са БР1, ТС1 и ТС1.ТЦ1 бројевима.
Стога сви Захтеви могу бити представљени у табеларном формату.
| Пословни захтев # | Тест сценариј # | Тест Цасе # | Дефецтс # |
|---|---|---|---|
| БР1 | ТС1 | ТС1.ТЦ1 ТС1.ТЦ2 | Д01 |
| БР2 | ТС2 | ТС2.ТЦ1 ТС2, ТЦ2 ТС2.ТЦ3 | Д02 Д03 |
| БР3 | ТС3 | ТС1.ТЦ1 ТС2.ТЦ1 ТС3.ТЦ1 ТС3.ТЦ2 | НУЛА |
Испитајте покривеност и следљивост захтева
Шта је покривеност тестом?
Тест Цовераге наводи који се захтеви купаца морају верификовати када фаза тестирања започне. Покривеност тестом је термин који одређује да ли су тест случајеви написани и извршени како би се обезбедило потпуно тестирање софтверске апликације, на такав начин да се пријаве минимални или НИЛ кварови.
Како постићи тест покривеност?
Максимална покривеност тестом може се постићи успостављањем добре „следљивости захтева“.
- Мапирање свих унутрашњих недостатака у дизајнираним тест случајевима
- Мапирање свих грешака које је пријавио купац (ЦРД) у појединачне испитне случајеве за будући пакет регресионих тестова
Врсте спецификација захтева
# 1) Пословни захтеви
Стварни захтеви купаца наведени су у документу познатом као Документ о пословним захтевима (БРС) . Овај БРС је детаљно изведена листа захтева високог нивоа, након кратке интеракције са клијентом.
Обично је припремају „Пословни аналитичари“ или пројекат „Архитекта“ (у зависности од организације или структуре пројекта). Документ „Спецификације софтверских захтева“ (СРС) изведен је из БРС-а.
# 2) Документ о спецификацији софтверских захтева (СРС)
То је детаљан документ који садржи све прецизне детаље свих функционалних и нефункционалних захтева. Овај СРС је основа за дизајнирање и развој софтверских апликација.
# 3) Документа о пројектним захтевима (ПРД)
ПРД је референтни документ за све чланове тима у пројекту како би им тачно рекао шта производ треба да ради. Може се поделити у одељке као што су Сврха производа, Карактеристике производа, Критеријуми за објављивање и Буџетирање и распоред пројекта.
# 4) Користите документ случаја
То је документ који помаже у дизајнирању и примени софтвера према пословним потребама. Мапира интеракције између глумца и догађаја са улогом коју треба извршити да би се постигао циљ. То је детаљан детаљни опис како задатак треба извршити.
На пример,
Глумац: Купац
Улога: Скинути игрицу
Преузимање игре је успешно.
Случајеви употребе такође могу бити део који је укључен у СРС документ према процесу рада организације.
# 5) Документ о верификацији недостатака
Документирано садржи све детаље везане за недостатке. Тим може да одржи документ „Провера неисправности“ за отклањање и поновно испитивање недостатака. Испитивачи могу упутити документ „Провера неисправности“, када желе да провере да ли су недостаци отклоњени или не, могу поново тестирати кварове на различитим ОС-има, уређајима, различитој конфигурацији система итд.
Документ „Верификација неисправности“ је згодан и важан када постоји посебна фаза отклањања и верификације квара.
# 6) Приче корисника
Корисничка прича се првенствено користи у развоју програма „Агиле“ за описивање софтверске функције из перспективе крајњег корисника. Корисничке приче дефинишу типове корисника и на који начин и зашто желе одређену особину. Захтев је поједностављен стварањем корисничких прича.
Тренутно се сва софтверска индустрија креће ка коришћењу корисничких прича и агилног развоја и одговарајућих софтверских алата за бележење захтева.
Изазови за прикупљање захтева
# 1) Прикупљени захтеви морају бити детаљни, недвосмислени, тачни и добро прецизирани. Али тамо је НЕМОЈ одговарајућа мера за израчунавање ових детаља, недвосмисленост, тачност и добро дефинисане спецификације потребне за прикупљање захтева.
#два) Тумачење „пословног аналитичара“ или „власника производа“ који пружа информације о захтевима је критично. Слично томе, тим који прима информације мора да изнесе одговарајућа појашњења како би разумео очекивања заинтересованих страна.
Разумевање мора бити усклађено и са пословним потребама и са стварним напорима потребним за имплементацију апликације.
# 3) Информације би такође требале бити изведене са становишта крајњег корисника.
# 4) Сукоби или противречност захтева држава заинтересованих страна у различито време.
# 5) Тачка гледишта крајњег корисника не узима се у обзир из више разлога, а даље заинтересоване стране мисле да „потпуно“ разумеју шта је потребно за производ, што обично није случај.
# 6) Развијени ресурси са недостатком вештина за апликацију.
# 7) Честе промене обима примене или промене приоритета за модуле.
# 8) Пропуштени, имплицитни или недокументирани захтеви.
# 9) Недоследни или нејасни захтеви које су утврдили купци.
# 10) Закључак свих горе наведених фактора је да „успех“ или „неуспех“ пројекта у великој мери зависи од захтева.
Како следљивост захтева може помоћи
# 1) Где се примењује захтев?
На пример,
Услов: Примените функцију „Састави пошту“ у поштанској апликацији.
Имплементација: На главној страници треба да се стави и приступи дугме „Састави пошту“.
# 2) Да ли је неопходан услов?
На пример,
Услов: Примените функцију „Састави пошту“ у апликацији за пошту само одређеним корисницима.
Имплементација: Према корисничким правима приступа ако је поштанско сандуче „Само за читање“, у овом случају неће бити потребно дугме „Састави пошту“.
# 3) Како да протумачим захтев?
На пример,
Услов: Функција „Састави пошту“ у апликацији за пошту са фонтовима и прилозима.
Имплементација: Када се кликне на „Састави пошту“, које све функције треба да буду обезбеђене?
- Тект Боди за писање е-поште и уређивање различитих врста фонтова, а такође их подебљано, курзив, подвлачи
- Врсте прилога (слике, документи, други имејлови итд.)
- Величина прилога (максимална дозвољена величина)
Тако се Захтеви рашчлањују на под-захтеве.
# 4) Које одлуке о дизајну утичу на примену захтева?
На пример,
Услов: Сви елементи „Примљено“, „Послана пошта“, „Радне верзије“, „Нежељена пошта“, „Отпад“ итд. Требало би да буду јасно видљиви.
Имплементација: Елементи који ће бити видљиви требају бити приказани у формату „Дрво“ или „Таб“.
# 5) Да ли су додељени сви захтеви?
На пример,
Услов: Обезбеђена је опција „Отпад“ за пошту.
Имплементација: Ако је обезбеђена опција „Отпад“ за пошту, тада опција „Избриши“ е-поште (захтев) мора бити иницијално примењена и требало би да ради тачно. Ако опција „Избриши“ пошту функционише исправно, тада ће се у „Отпад“ прикупљати само избрисани имејлови, а примена опције „Захтев“ поште (захтев) имаће смисла (биће корисно).
Предности РТМ-а и покривеност тестом
# 1) Израђена и тестирана верзија има потребну функционалност која задовољава потребе и очекивања „купаца“ / „корисника“. Купац мора добити оно што жели. Изненадити купца апликацијом која не ради оно што се очекује није ни за кога задовољавајуће искуство.
#два) Крајњи производ (софтверска апликација) развијен и испоручен купцу мора обухватати само функционалност која је потребна и очекује се. Додатне функције обезбеђене у софтверској апликацији у почетку могу изгледати привлачно док се не потроши време, новац и напор да се развије.
Додатна функција такође може постати извор кварова, што може узроковати проблеме купцу након инсталације.
# 3) Почетни задатак програмера се јасно дефинише како се прво ради на примени захтева који су од високог приоритета, према захтевима купца. Ако су захтеви високог приоритета купца јасно назначени, тада се те компоненте кода могу развити и применити на првом приоритету.
Стога се осигурава да шансе да крајњи производ буде отпремљен купцу буду у складу са највишим захтевима и да су у складу са распоредом.
# 4) Испитивачи прво верификују најважнију функционалност коју имплементирају програмери. Како се прво врши верификација (тестирање) приоритетне софтверске компоненте, помаже у утврђивању када и да ли су прве верзије система спремне за објављивање.
# 5) Тачни планови теста, испитни случајеви су написани и извршени који потврђују да су сви захтеви за пријаву правилно примењени. Мапирање тест случајева са захтевима помаже да се осигура да се не пропусте већи недостаци. Даље помаже у примени квалитетног производа према очекивањима купаца.
# 6) У случају да од клијента постоји „Захтев за промену“, све компоненте апликације на које захтев за промену утиче се модификују и ништа се не превиди. Ово додатно побољшава процену утицаја захтева за промену на софтверску апликацију.
# 7) Наизглед једноставан захтев за промену може подразумевати измене које је потребно извршити на неколико делова апликације. Боље је извести закључак о томе колико ће напора бити потребно пре него што пристанете на измену.
Изазови у покривености тестом
# 1) Добар комуникацијски канал
Ако постоје неке промене које сугерише Актери , исто треба саопштити тимовима за развој и тестирање у ранијим фазама развоја. Без овога на време Развој, испитивање примене и откривање / отклањање недостатака не могу се обезбедити.
# 2) Давање приоритета тестним сценаријима је важно
Тежак је задатак утврдити који су приоритетни, сложени и важни сценарији испитивања. Покушавам да тестирам све Тест сценарији је готово неостварив задатак. Циљ тестирања сценарија мора бити врло јасан са становишта пословања и крајњег корисника.
# 3) Имплементација процеса
јединични тест вс пример интеграционог теста
Процес тестирања мора бити јасно дефинисан узимајући у обзир факторе као што су техничка инфраструктура и имплементације, тимске вештине, прошла искуства, организационе структуре и процеси који се прате, процене пројеката повезане са трошковима, временом и ресурсима и локацијом тима према временским зонама.
Јединствена примена процеса узимајући у обзир поменуте факторе осигурава да је сваки појединац који се бави пројектом на истој страници. Ово помаже у несметаном протоку свих процеса који се односе на развој апликација.
# 4) Доступност ресурса
Ресурси су две врсте, тестери специфични за домен квалификованих корисника и алати за тестирање које користе тестери. Ако тестери добро познају домен, могу да напишу и примене ефикасне тест сценарије и скрипте. Да би применили ове сценарије и скрипте, тестери би требали бити добро опремљени одговарајућим „алатима за тестирање“.
Једину квалификовану испитивачицу и одговарајуће алате за тестирање могу обезбедити добру примену и благовремену доставу апликације купцу.
# 5) Ефективна примена стратегије тестирања
' Стратегија тестирања ’је сама по себи велика и засебна тема дискусије. Али овде за „Тест Цовераге“ ефикасна примена стратегије тестирања осигурава да „ Квалитет ’ пријаве је Добро и то је одржава током времена свуда.
Ефикасна „Тест стратегија“ игра главну улогу у планирању за све врсте критичних изазова, што даље помаже у развоју боље примене.
Како створити матрицу сљедивости захтјева
Да бисмо били са нама, морамо тачно знати шта је то што треба пратити или ући у траг.
Тестери почињу да пишу своје тест сценарије / циљеве и на крају тестове на основу неких улазних докумената - Документ о пословним захтевима, Документ о функционалним спецификацијама и документ техничког дизајна (опционо).
Претпоставимо, следеће је наш документ о пословним захтевима (БРД): ( Преузмите овај примерак БРД-а у екцел формату )
(Кликните било коју слику за увећање)
Испод је наш документ о функционалним спецификацијама (ФСД) заснован на тумачењу документа о пословним захтевима (БРД) и његовом прилагођавању рачунарским апликацијама. У идеалном случају, сви аспекти ФСД-а морају бити решени у БРД-у. Али ради једноставности, користио сам само тачке 1 и 2.
Узорак ФСД одозго БРД: ( Преузмите овај пример ФСД-а у екцел формату )
Белешка : БРД и ФСД нису документовани од стране КА тимова. Ми смо пуки потрошачи докумената заједно са осталим пројектним тимовима.
На основу горња два улазна документа, као тим за осигурање квалитета, дошли смо до доле наведене листе сценарија на високом нивоу које ћемо тестирати.
Узорци сценарија испитивања са горњих БРД и ФСД: ( Преузмите ову датотеку Пример сценарија за тестирање )
Кад једном стигнемо овде, сада би било добро време да започнемо са стварањем матрице следљивости захтева.
Ја лично преферирам врло једноставан Екцел лист са колонама за сваки документ који желимо да пратимо. Будући да пословни захтеви и функционални захтеви нису јединствено нумерисани, за праћење ћемо користити бројеве одељака у документу.
(Можете одабрати да пратите на основу бројева линија или бројева са набрајаним тачкама итд., У зависности од тога шта посебно има смисла за ваш случај.)
Ево како би једноставна матрица сљедивости изгледала за наш примјер:
Горњи документ успоставља траг између БРД-а до ФСД-а и на крају до сценарија испитивања. Стварањем оваквог документа можемо да се уверимо да је тестни тим узео у обзир сваки аспект почетних захтева приликом креирања својих пробних комплета.
Можете то оставити на овај начин. Међутим, како би био читљивији, више волим да укључим називе одељака. Ово ће побољшати разумевање када се овај документ дели са клијентом или било којим другим тимом.
Исход је следећи:
Опет, избор да користите претходни или новији формат је ваш.
Ово је прелиминарна верзија вашег ТМ-а, али генерално не служи својој сврси када се овде зауставите. Максималне користи од тога могу се добити када га екстраполирате све до недостатака.
Да видимо како.
За сваки тестни сценарио који сте смислили имат ћете најмање 1 или више тест случајева. Дакле, укључите другу колону када стигнете тамо и напишите ИД-ове тест примера као што је приказано доле:
У овој фази се за проналажење празнина може користити матрица следљивости. На пример, у горе наведеној Матрици сљедивости видите да нема тест случајева написаних за ФСД одјељак 1.2.
Као опште правило, било који празан простор у Матрици следљивости је потенцијално подручје за истраживање. Дакле, јаз попут овог може значити једну од две ствари:
- Тест тим је некако пропустио да размотри функцију „Постојећи корисник“.
- Функционалност „Постојећи корисник“ је одложена за касније или уклоњена из захтева за функционалност апликације. У овом случају, ТМ показује недоследност у ФСД-у или БРД-у - што значи да треба извршити ажурирање ФСД и / или БРД докумената.
Ако је то сценарио 1, назначиће места на којима тест тим треба још мало да ради како би осигурао 100% покривеност.
У сценарију 2, ТМ не показује само празнине, већ указује на нетачну документацију која захтева тренутну корекцију.
Хајде да сада проширимо ТМ како бисмо укључили статус извршења тест случаја и недостатке.
Доња верзија Матрице следљивости се обично припрема током или након извођења теста:
Преузмите шаблон Матрице сљедивости захтјева:
=> Предложак матрице следљивости у Екцел формату
Важне напомене
Следе важне напомене које треба напоменути у вези са овом верзијом Матрице следљивости:
# 1) Такође се приказује статус извршења. Током извршавања даје обједињени снимак како напредује посао.
# 2) Дефекти: Када се ова колона користи за успостављање уназад сљедивости, можемо рећи да је функционалност „Нови корисник“ највише мањкава. Уместо да извештава да су ти и тако тестни случајеви пропали, ТМ пружа транспарентност пословном захтеву који има највише недостатака, показујући на тај начин квалитет у погледу онога што клијент жели.
# 3) Као даљи корак, можете кодирати ИД квара како бисте представили њихова стања. На пример, ИД оштећења у црвеној боји може значити да је још увек отворен, а у зеленој боји може значити да је затворен. Када се то уради, ТМ ради док се отвара или затвара извештај о провери стања који приказује статус квара који одговарају одређеној БРД или ФСД функционалности.
најбољи софтвер за поправку рачунара за Виндовс 10
# 4) Ако постоји документ техничког дизајна или случајеви употребе или било који други артефакти које бисте желели да пратите, увек можете проширити горе створени документ тако да одговара вашим потребама додавањем додатних колона.
Да резимирамо, РТМ помаже у:
- Обезбеђивање 100% покривености тестом
- Приказивање недоследности захтева / документа
- Приказивање укупног статуса неисправности / извршења са фокусом на пословне захтеве.
- Ако би се променили одређени пословни и / или функционални захтеви, ТМ помаже у процени или анализи утицаја на рад КА тима у смислу поновног прегледа / прераде тестних случајева.
Поред тога,
- Матрица сљедивости није специфичан алат за ручно тестирање, може се користити и за пројекте аутоматизације. За пројекат аутоматизације, ИД тест случаја може указивати на име скрипте Аутоматион Тест.
- То такође није алат који могу да користе само КА. Развојни тим може користити исто за мапирање БРД / ФСД захтева у блокове / јединице / услове кода створене како би били сигурни да су сви захтеви развијени.
- Алати за управљање тестовима попут ХП АЛМ долазе са уграђеном функцијом следљивости.
Важно је напоменути да јеначин на који одржавате и ажурирате своју матрицу следљивости одређује ефикасност њене употребе. Ако се често не ажурира или се ажурира погрешно, алат представља терет уместо да буде помоћ и ствара утисак да сам алат није вредан употребе.
Закључак
Матрица сљедивости захтјева је средство за мапа и траг све захтеве клијента са тест случајевима и откривеним недостацима. То је појединачни документ то служи главној сврси да се не пропусте ниједан тест случај и тиме је покривена и тестирана свака функционалност апликације.
Добра „покривеност тестом“ која се планира пре времена спречава понављање задатака у фазама тестирања и цурење недостатака. Велики број недостатака указује на то да је тестирање добро обављено и да се тиме побољшава „квалитет“ апликације. Слично томе, врло низак број дефеката указује на то да тестирање није урађено до ознаке и то негативно утиче на „квалитет“ апликације.
Ако је покривеност тестом обављена темељно, онда се може оправдати низак број недостатака и овај број недостатака може се сматрати пратећом статистиком, а не примарном. Квалитет апликације назива се „Добар“ или „Задовољавајући“ када је покривеност тестом максимална, а број недостатака минимизиран.
О аутору: Чланица СТХ тима Урмила П. искусна је КА професионалка са висок квалитет вештине тестирања и праћења проблема.
Да ли сте креирали матрицу сљедивости захтјева у својим пројектима? Колико је слично или другачије од онога што смо створили у овом чланку? Поделите своја искуства, коментаре, размишљања и повратне информације о овом чланку путем својих коментара.
Препоручено читање
- Узорак предлошка плана тестирања софтвера са форматом и садржајем
- Како написати ефикасан сажети извештај о тесту (Пример примера за преузимање)
- Узорак предлошка тест примера са примерима тест примера (преузми)
- Пример узорка за извештај о испитивању прихватљивости са примерима
- Како написати документ стратегије тестирања (са узорком предлошка стратегије тестирања)
- Како тестирати спецификацију софтверских захтева (СРС)?
- Топ 20+ најбољих алата за управљање захтевима (комплетна листа)
- Контролне листе за тестирање софтвера КА (укључени су узорци контролних листа)