Kiel Agordi QA-Funkcion De Scratch

Ĝi estas kutima scenaro: startfirmao havas novan ideon kaj dungas kelkajn programistojn por konstrui funkcian modelon de la ideo.

Pro la naturo de la noventreprenoj, do ne multe da financado disponebla kun mallonga tempo por disvolvi la ideon, la ĉefa penado estas enfokusigita al konstruado de la nova produkto por publikigi ĝin por provi la akvojn, kaj tiel nature, testi kaj QA ne estas la ĉefa prioritato por la disvolva teamo.

Post kiam evidentiĝas, ke la ideo sukcesis, la kompanio volas plivastigi la ideon kaj komencas dungi pli da programistoj, sed samtempe ili ankaŭ volas, ke la produkto estu testita antaŭ ol ĝi aperos al la publiko.


Dum kelka tempo, testado estas farita de iu ajn disponebla en la kompanio, kaj ĝi estas plejparte ad hoc sen sekvaj taŭgaj procezoj.

Poste venas momento, kiam la starta kompanio decidas dungi sian unuan altrangan QA-homon por komenci efektivigi novan QA-procezon por la disvolva teamo.


Por la celo de ĉi tiu artikolo, mi supozos, ke la starto estas interreta kompanio, ekz. retkomerca retejo.





Efektivigo de QA-Procezo

La ĉefa celo de havado de kvalito-certiga procezo estas certigi, ke la ĝusta produkto estas konstruita ĝuste, la unuan fojon. Tio signifas, ke ni devas certigi, ke la postuloj estas ĝuste difinitaj kaj ke la disvolva teamo bone komprenas la funkciecon de novaj funkcioj antaŭ ol komenci kodigi.

Gravas noti, ke testado ne estas fazo, ĝi estas agado kaj ke testado komenciĝas de la komenco de la disvolva procezo, ĝuste de kiam la uzaj rakontoj estas verkitaj.

Testado devas subteni disvolviĝon kaj do testaj agadoj estas paralele al la evoluaj agadoj, kaj en ĉiu stadio de la disvolva procezo ni devas certigi, ke la kodo estas ĝisfunde testita.


Antaŭ ol efektivigi testan procezon, ni devas scii la nunajn disvolvan metodaron kaj procezon kaj se necese fari ĝustigojn por plibonigi la procezon.

Regresa Testado / Spurttestado

Kiam vi komencas kiel la unua homo de QA en la kompanio, verŝajne estas, ke ne ekzistas regresa testado kaj tial, kiam novaj funkcioj disvolviĝas, vi tute ne scias, ĉu ili influas la nunan funkcian retejon. Cetere, vi devas resti ĉe la disvolva teamo por testi la novajn funkciojn por certigi, ke ili funkcias ĝuste kaj laŭ specifoj.

Paralele estas almenaŭ du taskoj: Testado de novaj rakontoj en la spurto kaj plenumado de iom da regresa testado.

Testado de la novaj funkcioj prioritatas, ĉar ekzistas pli da probablo trovi cimojn en nova kodo ol rompi la nunan laborejon. Sed samtempe necesas Regresa Testado por certigi, ke la ekzistanta aplikaĵo plu funkcias dum ni konstruas novajn funkciojn.


Regresa testopakaĵo devas esti ekzekutita tuj kiam ekzistas ĝisdatigo de la aplikaĵo, do disvolva teamo povas akiri rapida reago pri la sano de la aplikaĵo.

Ne estas sufiĉe da tempo por verki regresajn testojn kaj por resti laŭ la provado de novaj funkcioj. Kiel ni povas rompi ĉi tiun ciklon?

Kutime, dum la unuaj tagoj de la spurto, programistoj okupiĝas pri kodado kaj do la novaj funkcioj ne pretos provi dum kelka tempo. Jen bona ŝanco eklabori pri la regresaj testoj.

Estas plej bonaj praktikoj por regresa testado, sed ĝenerale la aliro estus identigi la ĉefajn kernajn uzantajn vojaĝojn tra la retejo, tiel ke ĉe ĉiu nova eldono de la retejo, ni povas esti certaj, ke la aplikaĵo ankoraŭ estas uzebla de plimulto de ĝiaj uzantoj.


Ne necesas esti ĝisfunda listo de ĉi tiuj scenaroj, nur la ĉefaj kaj plej gravaj sufiĉos por komenci malgrandan regresan pakon, kiu povas esti plenumita ĉe ĉiu konstruado. Poste, dum la regresa pako maturiĝos, ni povas komenci aldoni pli da scenaroj.

Plej grave, ĉi tiuj regresaj scenoj devas esti aŭtomatigitaj.

Aŭtomata Testado

En lerta projekto, kie spurto kutime daŭras ĉirkaŭ du semajnojn, ne estas sufiĉe da tempo por fari ĉiujn testojn permane. Estas provado de novaj rakontoj kaj ankaŭ regresa testado. Kvankam havas sencon fari esplorajn testojn por testi novajn funkciojn, regresaj testoj devas esti aŭtomatigitaj por redukti la sekularan taskon plurfoje plenumi la samajn testojn permane.

Deplojo / Konstrua Dukto

Disvolviĝo aŭ konstrua dukto en facilmova projekto difinas kiel rakonto venas de produkta postrestado al viva produktejo. Ĝi difinas procezon kaj la agadojn okazantajn en ĉiu stadio.


Por efektivigi sukcesan QA-procezon, kiu certigas, ke ni ofte publikigas kvaliton-kodon, la deploja dukto devas esti difinita kaj plenumata de ĉiuj koncernatoj. La deploja dukto estas la spino de programara liverado.

La dukto devas baziĝi sur plej bonaj praktikoj kaj ampleksi la agadojn okazantajn en ĉiu etapo.

Fabrikaj Laborrenkontiĝoj

Unu el la plej gravaj agadoj en lerta projekto estas oftaj kunvenoj pri rakontaj laborejoj. Jen kiam la produkto-posedanto, programistoj kaj testistoj kunvenas en ĉambro kaj komencas ellabori kaj esplori la detalojn de la rakontoj. Ĉi tio gravas, ĉar ĉiuj devas kompreni la historion antaŭ ol komenci la disvolvan laboron.

Kvalitkontrolo temas pri difektopreventado prefere ol detekto kaj do en la rakontaj laborejoj, la teamo havas la ŝancon demandi pri la detaloj de la rakonto, pri iuj teknikaj aŭ projektaj limoj kaj pri iuj blokiloj por disvolvi la rakontojn.

Jen bonega okazo ekverki la akceptajn kriteriojn por la rakontoj. Ĉiu devas kontribui kaj ekpensi pri la eblaj scenaroj por ĉiu rakonto, ĉar ĉiu havos malsaman ideon, do ju pli da kapoj en la rakonto, des pli multaj scenaroj povas esti pripensitaj kaj la pli granda ŝanco malhelpi difektojn vivi.

Post kiam ĉiuj certas pri la detalo kaj amplekso de ĉiu rakonto, disvolviĝo komenciĝas.

Elprovanta Provado / Provado Dum Disvolviĝo

Ĉiuj respondecas pri kvalito de la produkto kaj ne nur testiloj. Kiel tia, necesas sufiĉa kvanto de 'ellaboranto-testado' por certigi, ke la skribita kodo estas altkvalita antaŭ ol esti deplojita al testmedio por plua testado.

Certe ĉiu nova funkcio devas esti bone provita. Aldone al tio, necesas integriĝaj testoj, API-testoj kaj UI-testoj.

Samrangaj kodaj recenzoj aŭ 'kamaradaj testoj' povas doni duan okulon al la laboro de la programisto. Testanto povas helpi revizii la unuajn testojn kaj ankaŭ la API-testojn por certigi, ke ĝustaj testoj estis verkitaj, kaj ankaŭ helpi verki la altnivelajn aŭtomatigitajn UI-testojn.

Kontinua Integriĝo / Testaj Medioj

Por efike testi novajn funkciojn, ni devas certigi, ke la kodo funkcias ne nur sur la maŝino de la programisto sed ankaŭ en aliaj medioj, kaj integrita kun la kodo de alia programisto.

Kontinua Integriĝo helpas identigi iujn ajn konstruajn problemojn frue en la procezo, tiel ke kiam la deplojo malsukcesas, ni povos ekrigardi de kie venas la problemo.

Testaj Medioj donas al testantoj kaj aliaj teamanoj la ŝancon testi la novajn funkciojn antaŭ ol vivi.

Ne-Funkcia Testado

Kiam necesas, ni ankaŭ faru nefunkciajn testojn, kiel testojn pri agado, ŝarĝo kaj sekureco. Sufiĉe ofte la fokuso estas certigi, ke la funkciado bone funkcias, tamen nefunkciaj testoj devas ricevi la saman prioritaton, precipe por retaj programoj, ĉar ili povus esti submetitaj al peza ŝarĝo kaj / aŭ atakoj.

Farante nefunkcian testadon, ni povas esti certaj, ke nia aplikaĵo povas trakti ŝarĝon dum pintaj tempoj kaj tio ne estas malferma al sekurecaj minacoj.

Aliaj konsiderindaj punktoj

  • Kruco-retumilo, Krucaparata testado
  • Testado pri Poŝtelefonoj kaj Tablojdoj
  • Paralela plenumo de aŭtomataj testoj
  • Esplora Testado
  • Iloj, kiel ekzemple Jira, Jenkins, Seleno, ktp ...
  • Kontinua Plibonigo
  • Varbado de Testistoj