how review srs document
Ово је други водич у нашем „Бесплатна обука за тестирање софтвера на мрежи уживо“ серија. Ако сте нови овде, погледајте први уводни водич: Крај тренинга за тестирање софтвера на пројекту уживо.
Хајде сада да уђемо у детаљну анализу како се дешава пролазак кроз СРС, шта је то што морамо препознати из овог корака, које кораке морамо предузети пре него што започнемо, који су изазови са којима бисмо могли да се суочимо итд. детаљан начин.
Фаза дизајнирања СДЛЦ-а:
Следећа фаза СДЛЦ-а је „Дизајн“ - овде се функционални захтеви преводе у техничке детаље. У овај корак су укључени тимови за развој, дизајн, окружење и податке. Исход овог корака је обично технички пројектни документ - ТДД.
Улазни податак је СРС документ, како за стварање ТДД-а, тако и за тим КА-а да почне да ради на КА аспекту пројекта, а то је преглед СРС-а и идентификација циља теста.
Шта ћете научити:
- Шта је СРС преглед?
- Пред кораци за преглед спецификација софтверских захтева
- Да ли је предложак потребан за тест сценарије?
- Нека важна запажања у вези са прегледом СРС
- Препоручено читање
Шта је СРС преглед?
СРС је документ који креира развојни тим у сарадњи са пословним аналитичарима и тимовима за заштиту животне средине / података. Типично, овај документ након финализације делиће се са КА тимом на састанку на којем је договорено детаљно упутство.
Понекад нам за већ постојећу апликацију можда неће требати званични састанак и неко ко ће нас водити кроз овај документ. Можда ћемо имати потребне информације да то урадимо сами.
Преглед СРС-а није ништа друго него пролазак кроз документ о спецификацији функционалних захтева и покушај разумевања каква ће бити циљна апликација.
Формални формат и узорак подељени су са свима вама у претходном чланку. Не значи нужно да ће сви СРС бити тачно документовани. Увек, облик је секундарни у односу на садржај .
Неки тимови ће само одабрати да напишу листу са набрајањем, неки тимови ће укључити случајеве употребе, неки тимови ће укључити узорке снимака екрана (попут документа који смо имали), а неки само описују детаље у пасусима.
Пред кораци за преглед спецификација софтверских захтева
Корак 1) Документи пролазе кроз више ревизија, зато се уверите да имамо праву верзију референцираног документа, СРС.
Корак 2) Успоставите смернице о томе шта се очекује на крају прегледа од сваког члана тима. Другим речима, одлучите шта се очекује од овог корака - обично је излаз овог корака идентификација сценарија испитивања. Сценарији тестирања нису ништа друго до само један линијски показивач „шта тестирати“ за одређену функционалност.
Корак # 3) Такође утврдите смернице о томе како треба представити овај резултат - мислим, образац.
како копирати низ у јави
Корак # 4) Одлучите хоће ли сваки члан тима радити на целом документу или ће га поделити између себе. Препоручује се да сви читају све јер ће то спречити концентрацију знања код одређених чланова тима.
Али у случају великог пројекта, са СРС документима који се крећу близу 1000 страница, приступ разбијања модула документа и додељивања појединим члановима тима је најпрактичнији.
Корак # 5) Преглед СРС-а такође помаже у бољем разумевању постоје ли посебни предуслови потребни за тестирање софтвера.
Корак # 6) Као нуспроизвод, наводи се листа упита код којих је неке функције тешко разумети или ако је потребно додати више информација у функционалне захтеве или ако се утврде грешке у СРС-у.
Шта нам је потребно за почетак?
- Тачна верзија СРС документа
- Јасна упутства о томе ко ће радити на чему и колико времена имају.
- Шаблон за креирање тест сценарија.
- Остале информације о томе - коме се обратити у случају питања или кога пријавити у случају недоследности документације
Ко би пружио ове информације?
Вође тимова су генерално одговорни за пружање свих ставки наведених у одељку изнад. Међутим, доприноси чланова тима су увек важни за успех целог овог подухвата.
Вође тимова често питају - Какве врсте инпута? Зар не би било боље доделити одређени модул некоме ко га занима него члану тима који то није? Зар не би било лепо одлучити се за циљни датум на основу мишљења тима, него ли на њих донијети одлуку? Такође, за успех пројекта важни су предлошци.
По правилу, предлошци имају већу стопу ефикасности када су прилагођени погодности и удобности одређеног тима. Стога треба напоменути да су вође тимова више од свега чланови тима. Укључивање вашег тима у свакодневне одлуке пресудно је за несметано одвијање пројекта.
Да ли је предложак потребан за тест сценарије?
Зашто шаблон за тест сценарије - није ли довољно ако само направимо листу?
како прегледати епс датотеке у Виндовс 10
Сигурно је. Међутим, софтверски пројекти нису емисије „један човек“. Они укључују тимски рад .
Замислите тим од 4 - 4 ако сваки од њих одлучи да прегледа по један модул спецификације софтверских захтева. Члан тима А је направио листу на листу папира. Члан тима 2 је користио екцел лист. Члан тима 3 је користио бележницу. Члан тима 4 је употребио реч доц. Како објединити сав посао урађен за пројекат на крају дана?
Такође, како можемо да одлучимо који је стандард и како да кажемо шта је исправно, а шта није ако нисмо креирали правила, за почетак?
То је оно што је образац: Скуп смерница и договорени формат за уједначеност и сагласност читавог тима.
Како направити шаблон за КА тест сценарије?
Предлошци не морају бити сложени или нефлексибилни.
Све што треба да буду ефикасан механизам за стварање корисног артефакта за тестирање. Нешто једноставно попут оног које видимо доле:
Заглавље овог предлошка садржи простор потребан за прикупљање основних информација о пројекту, тренутном документу и референцираном документу.
Табела испод ће нам омогућити да креирамо тест сценарије. Укључене колоне су:
Колона бр. 1) ИД сценарија теста
Сваки ентитет у нашем процесу тестирања мора бити јединствено препознатљив. Дакле, сваком тестном сценарију мора бити додељен ИД. Морају се дефинисати правила која се морају придржавати приликом додељивања овог ИД-а.
Зарад овог чланка следићемо конвенцију о именовању као ТС (префикс који означава Тест Сценарио) праћен „_“, назив модула МЕ (Ми Инфо модул Оранге ХРМ пројекта), затим ‘_’, а затим пододељак ( На пример, МЕ за Ми Инфо Модуле, П. за фотографију и тако даље), а затим серијски број. Пример би био: „ТС_МИ_МИМ_01“.
Колона бр. 2) Захтев
Помаже нам што када креирамо тестни сценарио, можемо да га вратимо у одељак документа СРС одакле смо га изабрали. Ако захтеви имају ИД, могли бисмо то да користимо. Ако не, бројеви одељака или чак бројеви страница СРС документа одакле смо идентификовали тестирани захтев ће бити од користи.
Колона бр. 3) Опис сценарија теста
Једноставна линија која прецизира „шта да тестирам“. Такође бисмо га означили као тест тест.
Колона бр. 4) Значај
Ово даје идеју о важности одређене функције за АУТ. Вредности попут високе, средње и ниске могу се доделити овом пољу. Такође можете изабрати бодовни систем, попут 1-5, 5 је најважније, 1 мање важно. Какву год вредност ово поље могло да има, мора се унапред одлучити.
Колона бр. 5) Број тест случајева
Груба процена о томе колико бисмо појединачних тест случајева могли на крају написати тај један тест сценарио. На пример, Да бисмо тестирали пријаву, укључујемо следеће ситуације: Исправите корисничко име и лозинку. Исправно корисничко име и погрешна лозинка. Тачна лозинка и погрешно корисничко име. Дакле, потврђивање функционалности пријаве резултираће са 3 тест случаја.
Белешка: Можете да проширите овај образац или уклоните поља како вам одговара.
На пример , у заглавље можете да додате „Прегледао“ или уклоните датум креирања итд. Такође у табелу можете да додате поље „Креирао“ да бисте одредили тестера одговорног за одређени тестни сценарио или уклонили „Не. тест случајева “. Избор је на вама. Идите са оним што најбоље одговара целом тиму.
Погледајмо сада наш наранџасти ХРМ СРС документ и креирајмо тест сценарије
Про врх: погледајте садржај у узорку СРС-а који смо пружили у првим водичима да бисте стекли добру идеју о томе како ће неки документ тећи и колико посла може да укључује.Секција 1 је сврха документа. Тамо нема проверивих захтева.
Одељак 2.1 : Преглед пројекта- Публика- ни тамо нема проверљивих захтева.
Одељак 2.2 : Хардвер и хостинг - Овај одељак говори о томе како ће бити смештена Оранге ХРМ страница. Да ли су ове информације важне нама тестерима? Одговор је Да и Не. Да, јер када тестирамо морамо да имамо окружење које је слично окружењу у стварном времену.
Ово нам даје идеју како то треба да буде. Не, јер то није тест тест - врста предуслова да би се тестирање догодило.
Одељак 3: Овде се налази екран за пријаву и детаљи о типу налога који морамо имати да бисмо ушли на веб локацију. Ово је тест тест. Дакле, то мора бити део наших тест сценарија.
Погледајте документ о сценаријима испитивања где су додати сценарији за неколико одељака СРС-а. За вежбање, молимо додајте остале сценарије на сличан начин. Међутим, идем право на одељак 4 документа.
Одељак 4: Естетски / ХТМЛ захтеви и смернице - Овај одељак најбоље објашњава како неки захтеви можда неће имати смисла за тест тим у време прегледа СРС-а, али тим би требало да их забележи као све провериве захтеве.
Како их тестирати и ако нам треба посебна поставка / помоћ било ког тима да то потврди, детаљи су које у овом тренутку можда не знамо. Али њихово укључивање у наш опсег тестирања први је корак да осигурамо да их не пропустимо.
аргументи командне линије у примерима скрипте љуске
Узорци сценарија теста за апликацију ОрангеХРМ: (кликните за увећање слике)
=> Молимо погледајте и преузмите документ Тест сценарији за више информација.
Нека важна запажања у вези са прегледом СРС
# 1) Ниједна информација не сме бити откривена.
#два) Извршите анализу изводљивости да ли је одређени захтев тачан или не, као и да ли се може тестирати или не.
# 3) Уколико не постоје засебне перформансе / обезбеђење или било који други облик тестних тимова, наш је посао осигурати да сви нефункционални захтеви морају бити узети у обзир.
# 4) Нису све информације циљане на тестере, па је важно разумети шта треба напоменути, а шта не.
# 5) Значај и бр. тест случајева за тестни сценарио не морају бити тачни и могу се попунити приближном вредношћу или могу остати празни.
Да резимирамо, СРС прегледа резултате у:
- Листа сценарија за тестирање
- Резултати прегледа - Грешке у документацији / захтеву пронађене статичким пролажењем / верификацијом СРС документа
- Списак питања за боље разумевање - у случају било ког
- Прелиминарна идеја о томе како би требало да изгледа окружење за тестирање
- Идентификација опсега теста и оквирна идеја о томе колико бисмо тест случајева могли на крају имати, па колико нам времена треба за документацију и евентуално извршење.
Важне напомене:
# 1) Сценарији тестирања нису екстерни испоручени подаци (не деле се са пословним аналитичарима или развојним тимовима), али су важни за интерну потрошњу квалитета. Они су наш први корак ка 100% циљу покривености тестом. Једном завршени тестови пролазе кроз стручну проверу и када се то уради, сви су обједињени.
За више детаља о начину прегледа КА докумената погледајте чланак: Како извршити прегледе пробне документације у 6 једноставних корака.
#два) Могли бисмо да користимо алат за управљање тестовима попут ХП АЛМ или кТест за креирање тест сценарија. Међутим, креирање тест сценарија у реалном времену је ручна активност. По мом мишљењу, згодније је ручно. Будући да је корак 1, још увек не морамо да износимо велике пушке. Једноставни екцел листови су најбољи начин за то.
Следећи корак ове серије је тај - радићемо на стварању тест случајева и ући даље у фазу дизајнирања тестова. Пре тога ћемо такође ући у - Шта је планирање теста?Где се то уклапа у читав КА пројекат? Као и увек, радите са нама за најбоље резултате.
КА тренинг дан 3: Како написати СРС документ испочетка.
Молимо вас да наставите са питањима и коментарима. Ценимо вашу читалачку публику!
Препоручено читање
- Програм курса за тестирање софтвера - детаљан план обуке на мрежи
- Курс за тестирање софтвера: Који институт за тестирање софтвера да се придружим?
- Обука за тестирање софтвера: Обука од краја до краја на пројекту уживо - Бесплатна онлајн обука за КА 1. део
- Најбољи алати за тестирање софтвера 2021. [Алати за аутоматизацију КА теста]
- Повратне информације и прегледи курса за тестирање софтвера
- Често постављана питања о КА курсевима за тестирање софтвера
- Ресурси и преузимања софтвера за испитивање квалитета софтвера
- КА Водич за оутсоурцинг: Тестирање софтвера за оутсоурцинг компаније