Jinsi ya Kuanzisha Kazi ya QA Kutoka Mwanzo

Ni hali ya kawaida: kampuni ya kuanza ina wazo jipya na huajiri idadi kadhaa ya watengenezaji kujenga mtindo wa kufanya kazi wa wazo hilo.

Kwa sababu ya asili ya wanaoanza, yaani, sio pesa nyingi zinazopatikana na muda mfupi wa kukuza wazo, juhudi kuu inazingatia kujenga bidhaa mpya kuipeleka kwa umma ili kupima maji, na kwa kawaida, kujaribu na QA sio kipaumbele cha kwanza kwa timu ya maendeleo.

Baada ya kubainika kuwa wazo limefanikiwa, kampuni inataka kupanua wazo na kuanza kuajiri watengenezaji zaidi, lakini wakati huo huo, pia wanataka bidhaa ipimwe kabla ya kwenda kwa umma.


Kwa muda, upimaji unafanywa na yeyote anayepatikana katika kampuni hiyo, na kwa kiasi kikubwa ni ya kutokuwepo bila michakato sahihi ya kufuata.

Halafu inakuja wakati kampuni ya kuanzisha inaamua kuajiri mtu wao wa kwanza mwandamizi wa QA kuanza kutekeleza mchakato mpya wa QA kwa timu ya maendeleo.


Kwa madhumuni ya kifungu hiki, nitachukulia kuwa kuanzisha ni kampuni ya wavuti, n.k. tovuti ya e-commerce.



Utekelezaji wa Mchakato wa QA

Lengo kuu la kuwa na mchakato wa Uhakikisho wa Ubora ni kuhakikisha kuwa bidhaa inayofaa imejengwa sawa, mara ya kwanza. Hiyo inamaanisha, tunahitaji kuhakikisha kuwa mahitaji yanafafanuliwa kwa usahihi na timu ya maendeleo ina uelewa thabiti wa utendaji wa huduma mpya kabla ya kuanza kuweka nambari.

Ni muhimu kutambua kuwa upimaji sio awamu, ni shughuli na kwamba upimaji huanza tangu mwanzo wa mchakato wa maendeleo, tangu wakati hadithi za watumiaji zinaandikwa.

Upimaji unapaswa kusaidia maendeleo na kwa hivyo shughuli za upimaji ni sawa na shughuli za maendeleo, na katika kila hatua ya mchakato wa maendeleo tunahitaji kuhakikisha kuwa nambari imejaribiwa kabisa.


Kabla ya kutekeleza mchakato wa upimaji, tunahitaji kujua mbinu na mchakato wa sasa wa maendeleo na ikiwa ni lazima tufanye marekebisho ili kuboresha mchakato.

Upimaji wa Ukandamizaji / Upimaji wa Sprint

Unapoanza kama mtu wa kwanza wa QA katika kampuni, uwezekano ni kwamba hakuna upimaji wa urekebishaji uliopo na kwa hivyo huduma mpya zinapotengenezwa, haujui ikiwa zitaathiri vibaya wavuti ya sasa ya kazi. Kwa kuongezea, unahitaji kuendelea na timu ya maendeleo kujaribu huduma mpya ili kuhakikisha zinafanya kazi vizuri na kulingana na uainishaji.

Kuna kazi angalau mbili sambamba: Upimaji wa hadithi mpya kwenye mbio na kufanya kiwango cha upimaji wa regression.

Upimaji wa huduma mpya unachukua kipaumbele kwani kuna uwezekano mkubwa wa kupata mende kwa nambari mpya kuliko kuvunja wavuti ya sasa ya kufanya kazi. Lakini, wakati huo huo, Upimaji wa Ukandamizaji unahitajika ili kuhakikisha kuwa programu iliyopo inaendelea kufanya kazi tunapojenga huduma mpya.


Kifurushi cha upimaji wa urekebishaji kinahitaji kutekelezwa mara tu ikiwa kuna sasisho la programu, ili timu ya maendeleo ipate maoni ya haraka juu ya afya ya maombi.

Hakuna wakati wa kutosha wa kuandika vipimo vya kurudi nyuma na vile vile kufuata upimaji wa huduma mpya. Je! Tunawezaje kuvunja mzunguko huu?

Kawaida, wakati wa siku chache za kwanza za mbio, watengenezaji wana shughuli nyingi za kuweka alama na kwa hivyo huduma mpya hazitakuwa tayari kujaribu kwa muda. Hapa kuna nafasi nzuri ya kuanza kufanya kazi kwenye vipimo vya kurudi nyuma.

Kuna mazoea bora ya upimaji wa urekebishaji, lakini kwa ujumla, njia hiyo itakuwa kutambua safari kuu za watumiaji katika wavuti yote, ili kila toleo mpya la wavuti, tunaweza kuwa na hakika kwamba programu bado inaweza kutumika na wengi watumiaji.


Hakuna haja ya kuwa na orodha kamili ya matukio haya, tu kuu na muhimu zaidi yatatosha kuanza kifurushi kidogo cha kurudi nyuma ambacho kinaweza kutekelezwa kwenye kila jengo. Baadaye, wakati kifurushi cha kukomaa kinakua, tunaweza kuanza kuongeza hali zaidi.

Jambo muhimu zaidi, hali hizi za kurudi nyuma zinapaswa kuwa otomatiki.

Jaribio la Kujiendesha

Katika mradi wa agile, ambapo sprint kawaida hudumu kwa wiki mbili, hakuna wakati wa kutosha kufanya upimaji wote kwa mikono. Kuna upimaji wa hadithi mpya pamoja na upimaji wa kurudi nyuma. Ingawa ni jambo la busara kufanya upimaji wa uchunguzi ili kujaribu vipengee vipya, vipimo vya kurudisha nyuma vinapaswa kuwa kiotomatiki ili kupunguza kazi ya kawaida ya kufanya majaribio hayo hayo kwa mikono.

Upelekaji / Bomba la Kujenga

Kupelekwa au ujenzi wa bomba katika mradi wa agile hufafanua jinsi hadithi inapata kutoka kwa mrundikano wa bidhaa kwenda kwa wavuti ya uzalishaji wa moja kwa moja. Inafafanua mchakato na shughuli zinazotokea katika kila hatua.


Ili kutekeleza mchakato wa QA uliofanikiwa ambao unahakikisha kuwa tunatoa nambari ya ubora mara kwa mara, bomba la kupeleka lazima lifafanuliwe na kuzingatiwa na wadau wote. Bomba la kupelekwa ni mgongo wa uwasilishaji wa programu.

Bomba linapaswa kutegemea mazoea bora na kujumuisha shughuli zinazotokea katika kila hatua.

Warsha za Hadithi

Moja ya shughuli muhimu zaidi katika mradi wa agile ni vikao vya semina za hadithi za mara kwa mara. Huu ndio wakati mmiliki wa bidhaa, waendelezaji na wanaojaribu hukusanyika kwenye chumba na kuanza kufafanua na kutoa maelezo ya hadithi. Hii ni muhimu kwa sababu kila mtu anapaswa kuwa na uelewa sawa wa hadithi kabla ya kuanza kazi ya maendeleo.

Uhakikisho wa Ubora ni juu ya kuzuia kasoro badala ya kugundua na kwa hivyo katika semina za hadithi, timu hupata nafasi ya kuuliza maswali juu ya maelezo ya hadithi, vikwazo vyovyote vya kiufundi au muundo na vizuizi vyovyote vya kukuza hadithi.

Hapa kuna fursa nzuri ya kuanza kuandika vigezo vya kukubalika kwa hadithi. Kila mtu anapaswa kuchangia na kuanza kufikiria juu ya hali zinazowezekana kwa kila hadithi, kwani kila mmoja atakuwa na wazo tofauti, kwa hivyo vichwa zaidi juu ya hadithi, hali zaidi zinaweza kufikiria na nafasi kubwa ya kuzuia kasoro kupata moja kwa moja.

Mara tu kila mtu anapokuwa na hakika juu ya undani na upeo wa kila hadithi, maendeleo huanza.

Upimaji / Upimaji wa Msanidi Programu Wakati wa Maendeleo

Kila mtu anapaswa kuwajibika kwa ubora wa bidhaa na sio tu wanaojaribu. Kwa hivyo, kuna haja ya kuwa na kiwango cha kutosha cha 'upimaji wa msanidi programu' ili kuhakikisha kuwa nambari iliyoandikwa ni ya hali ya juu kabla ya kupelekwa kwenye mazingira ya majaribio kwa upimaji zaidi.

Hakika kila kipande kipya cha utendaji kinapaswa kupimwa vizuri. Juu ya hayo, kuna haja ya kuwa na vipimo vya ujumuishaji, vipimo vya API na vile vile UI.

Mapitio ya nambari za rika au 'upimaji wa marafiki' yanaweza kuweka jicho la pili juu ya kazi ya msanidi programu. Jaribu inaweza kusaidia kukagua vipimo vya kitengo na vile vile vipimo vya API ili kuhakikisha kuwa vipimo sahihi vimeandikwa, na pia kusaidia kuandika vipimo vya kiwango cha juu vya kiotomatiki vya UI.

Mazingira endelevu ya ujumuishaji / mtihani

Ili kujaribu kwa ufanisi huduma mpya, tunahitaji kuhakikisha nambari inafanya kazi sio tu kwenye mashine ya msanidi programu lakini pia kwenye mazingira mengine, na kuunganishwa na nambari nyingine ya msanidi programu.

Ujumuishaji unaoendelea husaidia kutambua shida zozote za ujenzi mapema katika mchakato, ili wakati upelekaji ukishindwa tunaweza kuanza kuangalia suala hilo linatoka wapi.

Mazingira ya Mtihani huwapa wanaojaribu na wanachama wengine wa timu nafasi ya kujaribu huduma mpya kabla ya kwenda moja kwa moja.

Upimaji Usio wa Kazi

Inapohitajika, tunapaswa pia kufanya upimaji usio wa utendaji, kama vile upimaji wa utendaji, mzigo na usalama. Mara nyingi lengo ni kuhakikisha utendakazi unafanya kazi vizuri, hata hivyo upimaji ambao sio wa kazi unapaswa kupewa kipaumbele sawa, haswa kwa matumizi ya wavuti kwani wangeweza kubeba mzigo mzito na / au mashambulizi.

Kwa kufanya upimaji ambao sio wa kazi, tunaweza kuwa na uhakika kwamba programu yetu inaweza kushughulikia mzigo wakati wa kilele na ambayo haifunguki kwa vitisho vya usalama.

Pointi zingine za kuzingatia

  • Kivinjari msalaba, Upimaji wa kifaa cha Msalaba
  • Upimaji wa Simu na Ubao
  • Utekelezaji sawa wa vipimo vya otomatiki
  • Upimaji wa Uchunguzi
  • Zana, kama vile Jira, Jenkins, Selenium, nk…
  • Uboreshaji unaoendelea
  • Kuajiri Wakujaribu