Hvernig á að sigrast á áskorunum við lipra prófanir

Hver eru algengustu viðfangsefnin við prófraunir hugbúnaðar eða QA í liprum verkefnum? Hvernig er að vera QA í lipru liði?

Allt frá því að lipur þróunaraðferðafræði var kynnt í hugbúnaðargerð hefur hlutverk QA í liprum verkefnum breyst töluvert. Það er ekki lengur lið QA sitjandi í horni, fjarri verktaki og hönnuðum, og beðið eftir því að þróunarteymið afhendi verk til að prófa.

Einn mikilvægasti þátturinn fyrir QA í liprum verkefnum er að hafa góðan skilning á lipurri þróunaraðferðafræði og ferlum. Mörg lipur fyrirtæki fylgja Scrum ramma um afhendingu gæða hugbúnaðar, svo vertu viss um að þú þekkir Scrum.

Agile Testing Challenges

Kjarni lipurrar þróunar er skila vinnandi hugbúnaði oft , í hvert skipti sem þú bætir við eða eykur lítinn eiginleika sem er virði fyrir viðskiptavininn. Það er í sjálfu sér mikil áskorun ekki aðeins fyrir prófunarmenn heldur einnig forritara og alla aðra sem koma að afhendingu umsóknar.

Í þessari grein skrá ég nokkrar af algengustu áskorunum við lipra prófanir fyrir QA í liprum verkefnum og hvernig á að vinna bug á þeim.

Breytingarkröfur / síðustu stundar breytingar

Að breyta kröfum eða sleppa sögum um miðjan sprett er ekki óalgengt í liprum verkefnum. Þetta getur verið martröð fyrir allt liðið þar sem það þýðir að vinnan sem þegar hefur verið unnin gæti verið úreld að fullu eða gera breytingar á því sem þegar er hálfnað.

Þessar kröfubreytingar og beiðnir á síðustu stundu geta haft áhrif á umfang prófana sem geta valdið prófamönnum ónæði.

Hvernig á að sigrast á:

Prófarar ættu að geta brugðist við breytingum, vitandi að í liprum verkefnum eru breytingar óhjákvæmilegar. Þegar kröfur breytast sérstaklega undir lok sprettsins þegar ekki er nægur tími til að prófa á fullnægjandi hátt, ættu prófunaraðilar að veita eins miklar upplýsingar og mögulegt er um hvaða próf hafa verið keyrð og hvaða hluti umsóknarinnar hefur ekki verið prófaður vel svo að liðið getur tekið upplýsta ákvörðun (hugsanlega byggt á áhættu) hvort hún sleppi aðgerðinni eða ekki.

Reyndu að fá verktakana líka til að prófa, þar sem próf og gæði ættu að vera á ábyrgð alls teymis.

Ekki nægar upplýsingar um söguna

Það munu koma tímar þegar eigandi vöru sem skrifar sögur notenda, hefur einhverja hugmynd um nýjan eiginleika en hefur ekki allar upplýsingar til að skrifa gott sett af samþykkisviðmið til að skilgreina að fullu hegðun eiginleikans. Þeir biðja þróunarteymið að búa til frumgerð svo þeir geti fengið fleiri hugmyndir um virkni og hegðun eiginleikans.

Þetta skapar áskorun fyrir prófunarmenn vegna þess að skortur er á skilningi og kröfum og því er ekki hægt að smíða viðeigandi prófdæmi.

Hvernig á að sigrast á:

Þú þarft ekki mjög nákvæmar kröfur til að hefja prófanir, svo byrjaðu á því að hugsa um sviðsmyndir á háu stigi sem prófa hugmyndina að sögunni, frekar en að bíða eftir að fá fulla skýringu á eiginleikanum. Með því að leggja drög að prófunaraðstæðum á háu stigi, jafnvel þegar smáatriðin breytast, ætti samhengið að vera það sama.

Stöðug prófun

Í lipurri prófun er ekki áfangi, heldur virkni. Prófun hefst alveg frá byrjun, jafnvel áður en þróunin hefst.

Til þess að fá sléttan akstur á sprettinum ættu sögurnar í eftirstöðvunum að hafa verið útfærðar á sögusnyrtingunum. Þetta þýðir að QA ætti að vinna með vörueigendum til að læra smáatriði sögunnar og síðan hjálpa til við að skrifa góð viðtökuviðmið.

Að veita prófessorum snemma endurgjöf til forritara. Sem prófendur verðum við ekki aðeins að ganga úr skugga um að nýi eiginleikinn virki eins og hann er tilgreindur í samræmi við viðmiðunarskilyrði þess, við verðum líka að ganga úr skugga um að nýi kóðinn hafi ekki brotið núverandi virkni, þ.e við höfum ekki dregist aftur úr, og við höfum að koma þessum upplýsingum fljótt á framfæri.

Hvernig á að sigrast á:

Gakktu úr skugga um að hver saga hafi fullnægjandi viðmiðunarviðmið og að samhengi sögunnar sé vel skilið af öllum áður en þú byrjar að vinna að þróun.

Byrjaðu að búa til prófanir (sjálfvirkar eða handvirkar) eins fljótt og auðið er svo að þegar möguleikinn er til prófunar geturðu byrjað strax.

Prófunaraðilar ættu að hvetja verktaki til að gefa sýninni snemma sýnileika með því að dreifa reglulega í prófunarumhverfi þar sem prófunaraðilar og / eða vörueigendur geta keyrt prófanir sínar, frekar en að bíða eftir að eiginleikinn verði fullbúinn áður en prófað er.

Sjálfvirkt aðhvarfspróf til að létta eitthvað af áreynslunni og frelsa tíma þinn fyrir rannsóknarpróf.

Tæknilegar færni / sjálfvirkni prófana

Að vinna í lipru umhverfi þýðir að prófunaraðilarnir ættu að vera tæknilega færir til að hjálpa forriturum með samþættingarprófanir og API prófanir, svo og sjálfvirkniathuganir á forskriftarþáttum HÍ með Selenium eða svipuðu tæki.

Ef prófunarmennirnir koma frá eingöngu handbók eða rannsóknargrunni munu þeir eiga erfitt með að fylgjast með afhendingarhraða þar sem þeir þurfa að prófa stöðugt.

Árangursprófanir eru einnig mikilvægar sérstaklega fyrir forrit á vefnum til að tryggja að forritið þoli mikið álag á álagstímum. Ef fyrirtæki þitt er ekki með sérstakt afköst próf, er gert ráð fyrir að virkni prófanir taka einnig þátt í árangur próf.

Hvernig á að sigrast á:

Byrjaðu á því að læra nokkur smáforrit eða forritunarmál, svo sem Ruby og Java - þetta eru vinsælustu tungumálin í tækniprófssamfélaginu.

Ef þú þekkir nú þegar forritun og festist skaltu fá hjálp frá verktaki.

Selenium tólið er vinsælasta sjálfvirka prófunartækið í vafra, þannig að ef verkefnið er byggt á vefnum, þá er það mikil eign að hafa góða þekkingu á tækinu.

JMeter er líka annað frábært tæki til að hafa þekkingu á. Það er opið uppsprettuprófunartæki og tiltölulega auðvelt að læra, svo halaðu því niður og byrjaðu að leika þér með suma eiginleika þess.

Margar vafrar / margar tæki

Nú á dögum samanstendur arkitektúr margra vefsíðna af „bakenda“ og „framenda“. Framhliðin er að mestu byggð á JavaScript og CSS sem hugsanlega gæti hagað sér öðruvísi þegar litið er á hana úr mismunandi vöfrum eða tækjum.

Að tryggja að vefsíða virki eins og við er að búast í öllum helstu vöfrum og vinsælum farsímum eða spjaldtölvum er sannarlega efsta áskorun prófenda í liprum verkefnum.

Hvernig á að sigrast á:

Sjálfvirkni er lykilatriðið hér. Að skrifa próf og keyra það í mörgum vöfrum er það sem sjálfvirkni gerir best.

Þú getur notað Selen Grid með Docker til að stjórna og keyra sjálfvirku prófin þín samhliða í mörgum vöfrum.

Annað frábært tæki þarna úti fyrir prófanir í mörgum vöfrum er BrowserSync .

Samskipti

Sama hversu gott ferlið er eða hversu vel ofangreind atriði fara fram, ef skortur er á samskiptum meðal liðsmanna eða við vörueigendur, hönnuði osfrv, þá gengur ekkert.

Hvernig á að sigrast á:

Gakktu úr skugga um að skilvirk samskipti séu á milli teymisins. Taktu þátt með verktaki og vörueigendum stöðugt.

Gakktu úr skugga um að það sé til staðar ferli og að hver liðsmaður fylgi því ferli. Oft eru helstu mál eða villur ekki greindar snemma vegna þess að ferlinu var ekki fylgt og teymið náði ekki samskiptum.