is there any start stop boundary qa s role scrum
Која је улога КА у Сцрум-у: Сцрум активности за тестере
Овај чланак није само водич о неким процесима или методама или упутствима о томе како радити као КА. Уместо тога, ово је чланак у којем желим да поделим сопствено искуство рада као виши КА у СЦРУМ-у.
Мој претходни ЦТО је то увек говорио ‘Са слободом долази и одговорност’. Ако вам је дана слобода да радите свој посао на свој начин, онда сте ви и само ви одговорни за свој рад или задатке или активности.
О овоме се ради у Сцруму !! Дозволите ми да вам дам основну идеју о Сцруму док настављамо даље.
Шта ћете научити:
Преглед Сцрум-а
Сцрум је подскуп агилна методологија и лаган је процесни оквир који се широко користи.
Сцрум нам помаже да купце учинимо задовољнима дајући им производ у малим модулима, а такође држи купца свесним да њихови често променљиви захтеви могу успорити активности. Издања су кратка и ради се према капацитету укљученог тима, па су шансе за неуспехе или несрећне купце у великој мери смањене.
С друге стране, захтеви (у овом случају Усер Сториес) се финализују пре него што Спринт почне, како би се избегла поновна обрада, што резултира одложеним или неуспелим Спринтом (изузеци су увек ту).
Али највећи изазов за КА је то што је издавање кратко, а Спринт је углавном 15-дневни циклус. Стога испорука производа без грешака за највише 4-5 дана (узимање времена за развој) захтева много напора и паметног размишљања.
Ја сам КА свог тима:
О да, ја сам КА свог тима и важан сам играч свог тима. Зашто?? Јер су купци, БА, Сцрум Мастер и сви остали нејасни у погледу квалитета, изгледа и осећаја и перформанси апликације или производа.
У Сцруму, пошто је трајање спринта кратко, КА мора да наступи на паметан начин и отуда потреба КА да одмах од почетка буде укључен у „Планирање“ постаје веома важна. Постоје случајеви када КА може играти улогу власника проки производа када наруџбеница није доступна, помажући на тај начин БА-у у стварању сценарија / случајева испитивања критеријума за прихватање.
Програмери такође приступају КА у тренуцима када се суочавају са проблемима у вези са функционалношћу или пословним правилима. У Сцруму је фокус само на глатком и успешном издању Спринта и не ради се о томе да „Мој рад“ или „Ваш рад“ пруже руку када вам се тим обраћа за помоћ.
У вези Сцрум тимова, здрави односи између чланова тима играју пресудну улогу и пошто сте КА, требали бисте бити врло опрезни док саопштавате своје мишљење о корисничким причама које тестирате. Ваша комуникација треба да се односи на корисничку причу или функционалност, а не на особу која је на томе радила.
У Сцруму, КА се не оцењује нити цени због броја грешака које он / она открије, али и због тога како он / она комуницира са тимом, помаже тиму и мотивише га чак иу тешким тренуцима.
Поред тестирања задатака спринта, писање планова испитивања / тест случајева / докумената о издању такође покушава да укључи и више јер је трајање издања Спринта кратко и циљ је свима „Да успешно испоручимо радни производ без грешака помажући једни другима“.
КА је укључен у готово све активности које се изводе у Спринту и технички не постоји граница за почетак или заустављање КА активности. За разлику од традиционалног модела Ватерфалл, где је КА ограничен само на тестирање издања, овде КА има много више одговорности. Дакле, предложио бих да испробате и обавите више следећих активности.
Активности које треба пратити
Доље је дато неколико активности које бих вам предложио да пратите као КА у Сцруму.
како направити ватрогасни зид
# 1) Задржавање дубље:
Под овим мислим на то да када су корисничке приче и њихови критеријуми за прихватање спремни, темељито их проучите и размислите дубље о зависностима, скривеним исходима и да ли постоји бољи начин за то.
О томе комуницирајте и сарађујте са БА и развојним тимом, јер се може догодити да они такође нису размишљали о овоме. Поделите своје идеје и налазе са тимом.
Ако откријете да постоје скривене препреке или негативни утицаји, онда ће их подизање уз помоћ Сцрум Мастер-а и развојних људи дати времена да размисле и понашају се у складу с тим. Ова активност у Сцруму постаје веома критична када је пројекат великог обима и када постоје модули распоређени по тимовима.
Док проучавамо зависности, утицај је веома важан за осигурање квалитета и чак и развојни тим чини свестан истог. Да бисте то урадили, разговарајте са КА осталим тимовима и преузмите информације од њих.
# 2) Укључите се у процене:
Уобичајена пракса је укључивање КА у процене, али много пута због малог спринта од КА се можда неће тражити процена за тестирање задатака и остављање 3/4/5 дана за рад на тестирању.
Никада не прихватај ово. Подигните свој глас ако морате, али уверите се да дајете процену тестирања која треба да садржи време потребно за сваки рад.
Може укључивати време за истраживање, време за подешавања, време за прикупљање историјских података итд., Али будите строги и прецизни у погледу времена потребног за спровођење активности тестирања и додајте ове временске вредности у корисничку причу заједно са временом развојних задатака .
Ово је веома важно, јер ако покушате да обавите свој посао у предвиђеном времену и ако не успете да довршите, само ћете ви бити одговорни за неуспех. Када се дода КА време, Сцрум Мастер, ПО ће бити свестан укључених КА активности и потребног времена.
# 3) Упаривање КА за развој:
У идеалном случају, у Сцруму се Спринт Усер Сториес предају на тестирање након што се развој заврши и након што се изврши дев тестирање, али проблем је овде што до тренутка када се предају КА на тестирање једва 4-5 дана до Демо или рецензије остају.
Сада, ако као КА откријете чак 4 блокатора или функционалне грешке, мораћете да радите касно увече или викендом да бисте испунили датум издавања, јер ће бити потребно функционално тестирање, регресије итд. Ово се чини као традиционални модел водопада, што није најбољи начин за постизање, у Сцруму је то најпаметнији начин „Спречите недостатке, а не проналазите недостатке“.
Отуда је решење да направите упаривање КА за програмере и извршите основни круг тестирања на подешавању програма чим програмери буду спремни за приче чак и пре формалног издања за тестирање.
Следећи критеријуми се могу узети у обзир приликом израде БВТ-а на подешавању програма за корисничке приче:
- Критеријуми за прихватање сваке корисничке приче: БВТ корисничких прича у складу са критеријумима прихватања.
- Недостатак поверења у програмере: Понекад програмери нису сигурни у неке примене, па стога разговарају о таквим применама и раде БВТ за оне на истом подешавању развојног програма.
- Зависности / Испитивање утицаја: БВТ зависности или утицаја на / од осталих модула нових имплементација.
- Јединствено тестирање: Направите БВТ са програмером Унит тестова које су креирали, ако је потребно помозите им додавањем или ажурирањем унит тестова.
Ово ће вам помоћи да смањите грешке и уштедети, уштедећете време свима, јер је пре објављивања у КА већина отказивајућих или функционалних грешака већ исправљена. Не заборавите да уочите те недостатке у свом алату пре прегледа спринта и преместите их до стања „затворено“.
# 4) КА на белој табли:
Увек сам лично подстицао свој тим да уврсти задатке КА на Вхите Сцрум таблу, укључујући и грешке. Ово помаже Сцрум Мастеру да схвати КА статус корисничке приче једноставним гледањем табле.
Не. грешака на листи обавеза, грешке на листи У току, КА активности на листи Обавезе, У току и на листи Готово говоре саме за себе. Сматрам да је заиста болно када неко дође да пита о статусу тестирања појединачних прича за Спринт, јер морам потрошити додатно време да извадим свој статус из алата за компајлирање и покажем их или израдим е-поруку.
Једноставно више волим да усмерим ту особу на Сцрум Боард и пустим је да то сама схвати. Дајте предност сјајној изванредној боји за КА Стицки листиће.
# 5) Документација:
Ово је један од недостатака или недостатака Сцрума јер због мале величине Спринта нема пуно времена за документацију и никада нисам видео техничког писца у Сцрум тиму. Сцрум Мастер / БА не мора и не ажурира увек документе о информацијама о производу.
Проблем долази ако се придруже нови чланови или у најгорем случају ако се промене пословна правила, функционалности и како то водити, јер ће тражење информација у „Готовим“ корисничким причама бити попут тражења игле у пласту сена.
Решење је да се у спринту креира засебни задатак кад год је то могуће (углавном у заосталим временима или када је радни опсег врло мали) за документацију, тако да можете да прегледате документе и ажурирате их или да их Сцрум Мастер или БА ажурирају.
КА је права особа која ће вам помоћи у ажурирању докумената, јер сте ви та која тестира, верификује корисничке приче и познаје функционалност у и изван ње. Урадите то сами ако нема БА и ако је ваш Сцрум Мастер заузет ажурирањем.
# 6) Преглед спринта / демонстрација спринта:
Углавном се дешава да је КА тај који је изабран да демонстрира ПО организацијама и заинтересованим странама. али ако не наговорите свог Сцрум Мастер-а да то учини. Служба за осигурање квалитета је права особа која даје демонстрацију пошто је тестирала корисничку причу у и изван ње.
КА може да демонстрира са пословног становишта јер познаје функционалности, токове и правила пословања. Добро се припремите за демонстрацију и покушајте да одговорите на свако питање које имају ПО и заинтересоване стране. Ово ће вам помоћи да постанете контакт особа за њих у одсуству Сцрум Мастер-а и БА-а.
# 7) Понашајте се као БА:
Ово није редован задатак, а ни не очекује се од КА-а, али покушајте да уђете у ову улогу кад се укаже шанса, јер је КА најбоља особа која треба да буде БА. На пример, покушајте да размислите и представите да ли се токови, функционалности или пословна правила могу модификовати на начин који ће користити купцу.
Размислите и потражите тренутне трендове у корисничком интерфејсу, изглед и осећај апликације и како је може беатификовати, учинити једноставнијом за употребу итд. Ако је тим заглављен у неком проблему, укључите се и покушајте да дате једноставан и паметан решење. Ово ће дати подстицај вашој улози и биће фактор који ће допринети вашем расту у каријери.
Шансе се јављају током позива са организацијом наручилаца када се разговара о неким проблемима или у прегледу / демонстрацији где можете дати предлоге.
Закључак
Сцрум је веома различита методологија од уобичајене методе Ватерфалл, а Сцрум Мастер је фацилитатор. Отуда немојте очекивати да он / она дефинише ваше активности уместо вас.
У Сцруму нема почетне и крајње границе улоге КА-а. КА треба и мора бити укључен у сваку активност од самог почетка до краја, одмах од предпланирања до прегледа / демонстрације спринта и мора учествовати у свим активностима.
Ово ће помоћи да се разуме производ или апликација јер (као што сам већ рекао) не постоји одговарајућа документација доступна током рада у Сцруму. Од вас се очекује да будете одговорни, мотивисани и проактивни. Стога немојте чекати да неко дође и каже вам шта или како треба да радите.
Требали бисте сами предузимати иницијативе, помагати тиму на сваки могући начин, одржавати здрав однос, водити евиденцију о текућим стварима у тиму и најважније бити јасни у вези са својим задацима у датом спринту.
Овде нема менаџера који ће вас надгледати или пратити ваше активности. Увек будите спремни са руком помоћи за свој тим и добићете најбоље могућности.
Слободно изразите своје мисли / сугестије о овом информативном чланку у одељку за коментаре испод.
Препоручено читање
- Улога пословних аналитичара у СЦРУМ-у и зашто је КА најбољи за ову улогу?
- Онлине квиз Агиле Сцрум: Проверите своје знање о Агиле Сцрум-у
- Инсталирајте своју апликацију на уређај и започните тестирање из програма Ецлипсе
- Канбан вс Сцрум вс Агиле: Детаљна упоредба за проналажење разлика
- Како испоручити софтверске функције високе вредности у кратком временском периоду помоћу Агиле Сцрум процеса
- Агиле Манифест: Разумевање агилних вредности и принципа
- Триагинг дефекта у Сцрум-у: Како је то организовано у Сцрум Сетуп-у
- Најбољи алати за тестирање софтвера 2021. године [КА Тест Аутоматион Тоолс]