Hvernig setja á upp QA aðgerð frá grunni

Það er venjuleg atburðarás: sprotafyrirtæki hefur nýja hugmynd og ræður fjölda verktaka til að byggja upp vinnulíkan af hugmyndinni.

Vegna eðlis sprotafyrirtækja, þ.e. ekki mikið fjármagn í boði með stuttum tíma til að þróa hugmyndina, beinist aðalátakið að því að byggja nýju vöruna til að koma henni út fyrir almenning til að prófa vötnin, og svo náttúrulega, að prófa og QA er ekki forgangsverkefni þróunarteymisins.

Eftir að augljóst er að hugmyndin hefur gengið vel vill fyrirtækið auka hugmyndina og hefja ráðningu fleiri forritara en á sama tíma vilja þeir einnig að varan verði prófuð áður en hún fer út á almenning.


Um tíma eru prófanir gerðar af hverjum sem er í boði í fyrirtækinu og það er að mestu leyti ad-hoc án viðeigandi ferla til að fylgja.

Svo kemur að því að sprotafyrirtækið ákveður að ráða fyrsta háttsetta mann sinn til að hefja nýtt QA ferli fyrir þróunarteymið.


Að því er varðar þessa grein ætla ég að gera ráð fyrir því að gangsetningin sé vefmiðlað fyrirtæki, t.d. netviðskiptavefur.





Að innleiða QA ferli

Meginmarkmiðið með gæðatryggingarferli er að tryggja að rétta vöran sé byggð rétt, í fyrsta skipti. Það þýðir að við verðum að tryggja að kröfurnar séu rétt skilgreindar og þróunarteymið hafi góðan skilning á virkni nýrra eiginleika áður en byrjað er að kóða.

Það er mikilvægt að hafa í huga að prófun er ekki áfangi, það er virkni og að prófun hefst strax í upphafi þróunarferlisins, alveg frá því notendasögurnar eru skrifaðar.

Prófun ætti að styðja við þróun og prófunarstarfsemi er því samhliða þróunarstarfseminni og á hverju stigi þróunarferlisins þurfum við að tryggja að kóðinn sé prófaður rækilega.


Áður en við förum í prófunarferli verðum við að þekkja núverandi þróunaraðferðafræði og ferli og ef nauðsyn krefur að laga til að bæta ferlið.

Aðhvarfsprófun / sprettprófun

Þegar þú byrjar sem fyrsti QA maðurinn í fyrirtækinu eru líkurnar á því að engin aðhvarfsprófun sé til staðar og svo sem nýir eiginleikar eru þróaðir hefurðu ekki hugmynd um hvort þeir hafi neikvæð áhrif á núverandi vinnandi vefsíðu. Þar að auki þarftu að fylgjast með þróunarliðinu til að prófa nýju eiginleikana til að tryggja að þeir virki rétt og í samræmi við forskriftir.

Það eru að minnsta kosti tvö verkefni samhliða: Prófun nýrra sagna á sprettinum og framkvæmd að einhverju leyti aðhvarfsprófunar.

Prófun á nýju lögunum hefur forgang þar sem meiri líkur eru á að finna villur í nýjum kóða en að brjóta núverandi vinnusíðu. En á sama tíma er krafist aðhvarfsprófa til að tryggja að núverandi forrit haldi áfram að virka þegar við byggjum upp nýja eiginleika.


Aðgerðarprófunarpakki þarf að framkvæma um leið og það er uppfærsla á forritinu, svo þróunarteymið geti fengið hröð viðbrögð um heilsufar umsóknarinnar.

Það er ekki nægur tími til að skrifa aðhvarfspróf sem og að fylgjast með prófunum á nýjum eiginleikum. Hvernig getum við brotið þessa hringrás?

Venjulega, fyrstu dagana á sprettinum, eru verktaki uppteknir af kóðun og því eru nýju aðgerðirnar ekki tilbúnar til að prófa um stund. Hér er gott tækifæri til að byrja að vinna að aðhvarfsprófunum.

Það eru bestu aðferðir til að prófa afturhvarf, en almennt er nálgunin sú að bera kennsl á helstu ferðir notenda um vefsíðuna, þannig að við hverja nýja útgáfu vefsíðunnar getum við treyst því að forritið sé enn nothæft af meirihluta þess notendur.


Það þarf ekki að vera tæmandi listi yfir þessar sviðsmyndir, bara helstu og mikilvægustu munu duga til að koma af stað litlum aðhvarfspakka sem hægt er að framkvæma í hverri byggingu. Seinna, þegar aðhvarfspakkinn þroskast, getum við byrjað að bæta við fleiri sviðsmyndum.

Mikilvægast er að þessar aðhvarfsaðstæður ættu að vera sjálfvirkar.

Sjálfvirk próf

Í lipru verkefni, þar sem sprettur tekur venjulega um það bil tvær vikur, er ekki nægur tími til að gera allar prófanir handvirkt. Það eru prófanir á nýjum sögum sem og afturprófun. Þó að það sé skynsamlegt að gera könnunarpróf til að prófa nýja eiginleika, þá ætti að gera sjálfvirk próf til aðhvarfs til að draga úr því hversdagslega verkefni að framkvæma sömu prófin ítrekað handvirkt.

Dreifing / uppbygging leiðsla

Dreifing eða smíði leiðsla í lipru verkefni skilgreinir hvernig saga verður frá vöruefnisstöðu til lifandi framleiðslusíðu. Það skilgreinir ferli og þær athafnir sem gerast á hverju stigi.


Til að hrinda í framkvæmd árangursríku QA ferli sem tryggir að við gefum oft út gæðakóða verður að skilgreina dreifingarleiðsluna og fylgja henni eftir af öllum hagsmunaaðilum. Dreifingarleiðslan er hryggurinn við afhendingu hugbúnaðar.

Leiðslan ætti að byggja á bestu starfsvenjum og ná yfir þá starfsemi sem á sér stað á hverju stigi.

Sögusmiðjur

Ein mikilvægasta verkefnið í lipru verkefni eru tíðir sögusmiðjustundir. Þetta er þegar eigandi vörunnar, verktaki og prófunarmenn koma saman í herbergi og byrja að útfæra og útlista smáatriðin í sögunum. Þetta er mikilvægt vegna þess að allir ættu að hafa sama skilning á sögunni áður en þróunarstarfið hefst.

Gæðatrygging snýst um forvarnir gegn göllum frekar en uppgötvun og svo í sögusmiðjunum fær liðið tækifæri til að spyrja spurninga um smáatriði sögunnar, allar tæknilegar eða hönnunarþvinganir og hvers kyns hindranir til að þróa sögurnar.

Hér er frábært tækifæri til að byrja að skrifa út viðmiðunarskilyrði fyrir sögurnar. Allir ættu að leggja sitt af mörkum og byrja að hugsa um mögulegar sviðsmyndir fyrir hverja sögu, þar sem hver og ein mun hafa aðra hugmynd, svo því fleiri hausar á sögunni, þeim mun fleiri atburðarás er hægt að hugsa um og meiri líkur á að koma í veg fyrir að gallar lifi.

Þegar allir eru vissir um smáatriði og umfang hverrar sögu byrjar þróun.

Hönnuður próf / prófun á þróun

Allir ættu að vera ábyrgir fyrir gæðum vörunnar en ekki bara prófanir. Sem slíkt þarf að vera nægilegt magn af „verktakaprófum“ til að tryggja að skrifaður kóði sé af háum gæðum áður en honum er dreift í prófunarumhverfi til frekari prófana.

Vissulega ætti að prófa vel hvert einasta verk. Ofan á það þurfa að vera samþættingarpróf, API próf sem og HÍ próf.

Jafningjakóði gagnrýni eða „kumpánsprófun“ geta sett annað auga á verk verktakans. Prófari getur hjálpað til við að fara yfir einingaprófin og API prófin til að tryggja að réttar prófanir hafi verið skrifaðar, auk þess að hjálpa til við að skrifa hágæða sjálfvirkar HÍ próf.

Stöðug samþætting / prófunarumhverfi

Til þess að prófa nýja eiginleika á áhrifaríkan hátt verðum við að tryggja að kóðinn virki ekki aðeins á vél verktakans heldur einnig í öðru umhverfi og samþættur kóða annarra verktaka.

Stöðug samþætting hjálpar til við að bera kennsl á byggingarvandamál snemma í ferlinu, þannig að þegar dreifing mistakast getum við farið að skoða hvaðan vandamálið kemur.

Prófumhverfi gefa prófendum og öðrum liðsmönnum tækifæri til að prófa nýju eiginleikana áður en þeir fara í loftið.

Óvirkni próf

Þegar þess er krafist ættum við einnig að framkvæma prófanir sem ekki eru virkar, svo sem árangur, álag og öryggisprófun. Oft er áherslan lögð á að tryggja að virkni virki vel, en próf sem ekki eru virk skulu hafa sömu forgang, sérstaklega fyrir vefforrit þar sem þau gætu orðið fyrir miklu álagi og / eða árásum.

Með því að framkvæma prófanir sem ekki eru hagnýtar getum við verið viss um að forritið okkar ráði við álag á álagstímum og það sé ekki opið fyrir öryggishótunum.

Önnur atriði sem þarf að huga að

  • Cross-browser, Cross device testing
  • Farsíma- og spjaldtölvuprófun
  • Samhliða framkvæmd sjálfvirkra prófana
  • Rannsóknarpróf
  • Verkfæri, svo sem Jira, Jenkins, Selen, etc ...
  • Stöðug framför
  • Ráðning prófara