Defekti elutsükkel - nagu te juba praeguseks võisite teada saada, on testi täitmine etapp, kus testija teostab tegelikult skripte. Testiskriptide täitmise protsess on ettevõttes erinev ja see võib erineda ka sama ettevõtte eri projektides.
Nüüd on päevade jooksul saadaval testi täitmiseks vajalikke tööriistu, näiteks tööriistad - kvaliteedikeskus, Microsofti visuaalstuudio ja nii edasi. Tegeliku ja oodatava tulemuse võrdlemiseks iga sammu tegelik täitmisprotsess jääb funktsionaalse testija jaoks samaks, sõltumata kasutatavatest tööriistadest.
- Mis saab siis, kui tegelik käitumine pole võrdne eeldatava käitumisega?
Kui testija leiab, et tegelik testimistulemus ei võrdu eeldatava tulemusega, logitakse viga.
- Kuidas viga registreerida?
Nüüd on päevade jooksul saadaval palju tööriistu, mõned puuduste logimise tööriistad on ClearQuest (IBM), HP kvaliteedikeskus, avatud lähtekoodiga tööriistad, näiteks defektide elutsükkel JIRA-s ja nii edasi.
Seal on mõned kohustuslikud väljad, mis on ühised kõigil puuduste logimise tööriistadel, need väljad on -
- Defekti elutsükkel Kirjeldus
- Defektide elutsükli kokkuvõte
- Defekt on loginud
- Defekt määratud
- Defekti raskusaste
- Defekti prioriteet
- Täiendavad hetktõmmised
- Väljalaske number / nimi
Defekt elutsükkel
Defekti elutsükkel algab uue defekti registreerimisest. Kui viga registreeritakse, läheb see olekusse „Uus”.
Tester - uus defekt
Kellele uus defekt määrata?
Tester võib määrata defekti arendajale või arendusjuhtmele. See otsus puuduste määramise kohta on projektiti erinev. Mõnedes töökohtades on defekti olelustsükli protsess, mille abil saab selle otse vastavale arendajale määrata ja mõnes kohas omistatakse defekt esmalt dev-juhile ja dev-juht omakorda määrab selle arendajale.
Defekti määramine (uus) - defekti olelustsükli arendaja
Defektide määramine (uus) - arendaja Dev Leadà
Defektide analüüs
Arendaja analüüsib defekti, et kontrollida, kas see on reprodutseeritav. Testija kõige olulisem panus on kõigi vajalike detailide lisamine defekti. Defektide kokkuvõte, puuduste üksikasjalik kirjeldus on väljad, mis aitavad huvirühmadel defekti korraga mõista. Defektide kokkuvõttes peaks alati olema ainult vea kõrge tase. Samal ajal peaks sellel olema piisavalt teavet defektide ülevaate kirjeldamiseks ühes reas.
Defekti kirjeldus on koht, kus testija peaks sisaldama kogu vajalikku teavet, näiteks keskkond, stsenaarium, kasutatud katseandmed, eeldatav tulemus, tegelik tulemus, viide failidele / andmetele ja viide hetktõmmisele.
Siin on lühike ülevaade defekti üksikasjalikust kirjeldusest -
Keskkond
Katsekeskkond, kus defekt leiti. Sageli on projektidel mitu testimiskeskkonda, kus testimisrühm viib läbi testimist. Näiteks - AT (koostise testimiskeskkond), PT (toote testimiskeskkond), UAT (kasutaja aktsepteerimise testimiskeskkond) jne. Erinevate keskkondade loomise eesmärk on see, et see võimaldaks arendus- ja testimismeeskonnas paindlikkust, et kood saaks juurutada ükskõik millisesse saadaolevasse keskkonda, et katsetamist õigeaegselt alustada.
Mõnikord on tootetest (mida nimetatakse ka süsteemitestiks) ja UAT-testimine kattuvaks, seetõttu on paralleelse testimise jätkamiseks kohustuslik mitme keskkonna olemasolu.
On juhtumeid, kui arendusmeeskond vajab testimisrühma teatatud probleemide silumiseks täiendavat keskkonda. Samuti on arendusmeeskonnal spetsiaalne keskkond üksuse testimiseks.
Seega, kui tegemist on mitme keskkonnaga, tuleb puuduse korral mainida konkreetset keskkonda, kus probleem leiti.
Stsenaarium
Stsenaarium on testi läbiviija poolt defekti viinud sammude kogum. Testija peaks siinkohal mainima kõiki toiminguid, mida arendaja saab defekti taasesitamiseks teha. Tihti on aegu, mil testija teatab puudusest, kuid arendaja ei suuda seda sama korrata ja seetõttu lükatakse defekt tagasi. See võib juhtuda kirjelduses nimetatud valede sammude / puuduvate sammude tõttu. Selged sammud aitavad kõigil defekti mõista ja seda kopeerida, ilma et oleks vaja sisendite saamiseks katsetaja poole pöörduda. Hästi dokumenteeritud stsenaarium on hõlpsasti loetav, hõlpsasti mõistetav ja täpsed sammud, mida tuleb defekti kordamiseks järgida.
Testi andmed
Testija peaks mainima andmeid, mis kasutati testimisprotsessi käigus, mis viis välja probleemini. See teave annab arendajale võimaluse kasutada sarnaseid andmeid defekti taastootmiseks ja selle algpõhjuse leidmiseks.
On mõned stsenaariumid, kus testija leiab defekti konkreetsete andmete abil, kuid sama probleemi ei saa sarnaste andmete abil korrata. See võib juhtuda andmete rikkumise tõttu, seega annab andmete sisestamine võimaluse välja selgitada defekti algpõhjus. Kui tegemist on andmete rikkumisega, ei pruugi arendaja kooditasemele kaevata. Seda tüüpi defekti saab muuta andmedefektiks.
Oodatud ja tegelik tulemus
See on üksikasjaliku kirjeldusvälja esiletõstetud punkt, kus testija tõendab, et ilmnenud viga on tõepoolest puudus. Oodatava tulemuse selgesõnaline mainimine muudab asjad iga sidusrühma osalise jaoks selgeks, kui ta peab viga veaks. Kujutage ette, et defekt on sisse logitud koos kõigi üksikasjadega, kuid see ei täpsusta stsenaariumi eeldatavat tulemust!
Tavaliselt sisestab testija ainult oodatava tulemuse, mis võib olla reas või kahes reas, kuid on väga oluline nimetada eeldatava tulemuse allikas. Allikas siin viide dokumendile, kus oodatav tulemus on nimetatud. See võib olla nõudedokument või süžeeskeemi viide.
Viited failidele / andmetele
Mõnikord hõlmab defekt faili loomist või failisisendit. Sellise stsenaariumi korral peaks testija pakkuma teavet kasutatud faili kohta, mis põhjustas rakenduses selle probleemi. Neid faile saab lisada defektide haldamise tööriista abil või nende kohta saate viite. Nendele võrdluskohtadele peaksid olema kättesaadavad kõik sidusrühmad.
Viide hetkeseisule
Piltvõtted mängivad väga olulist rolli, kui soovite neile kuvada ekraanil kuvatavat täpset vea ilmumist lehe katkemise korral või kui soovite kuvada ekraanil navigeerimise üksikasju. Ülevaade annab kiire ülevaate tekkinud veast, ekraanist, milles defekt leiti, ekraanil kasutatud andmetest jne. Kõigil defektihaldusriistadel on hetktõmmiste lisamise võimalus. Mõnikord võib testija lisada ka Exceli arvutustabeleid või Word-dokumente.
Need olid puuduste logimise erinevad komponendid ja igaühe parimad tavad. Tulles tagasi defekti elutsükli juurde, kui defekt on arendajale määratud, analüüsib ta seda, kasutades defektiühikus esitatud andmeid. Kui analüüsi kohaselt on logitud probleem tõepoolest defekt, siis arendaja "avab" defekti, et seda parandada.
Soovitatavad kursused
- Veebiteenused Java koolituskomplektis
- Mängude arendamise koolitus C ++ klassis
- Täielik eetilise häkkimise koolitus
- Vegas Pro 13 koolituskursust
Uus - avatud
Defekt avatud olekus näitab, et see on arendusplaadil ja arendajad tegelevad selle parandamisega. Kui analüüsimisel selgub, et logitud probleem ei ole puudus, võib see juhtuda siis, kui süsteemi eeldatava käitumise osas on mõistmislünki. Kui analüüs ütleb, et viga on kehtetu, lükkab arendaja selle defekti tagasi. Terminoloogia on „tagasi lükatud” või „tagasi testimise juurde”.
Uus - naaske testimise juurde.
Kuidas testija peaks valideerima, kas defekt oli tõepoolest vigane?
See on stsenaarium, kus täpne nõudedokument aitab kõigil meeskonna liikmetel jõuda järeldusele, kas logitud viga oli kehtetu või kehtiv. Nõudedokumentidele viitamine aitab testijatel ja arendajatel jõuda samale järeldusele ning see hõlbustab tõesti aruteluprotsessi.
On stsenaariume, kus projekteerimis- ja nõudedokumentide õigsuses seatakse kahtluse alla, viitega nendele dokumentidele defektide arutelude ajal, peetakse sellisel ajal ärianalüütiku juurde tagasi pöördumist parimaks võimaluseks päringute selgitamiseks.
Parima tava kohaselt peaksid nõude- ja kujundusdokumendid olema alati ajakohased, et neile ilma mitmetähenduslikkuseta osutada.
Olekus „Avatud” töötab arendusmeeskond defekti parandamise nimel, kui defekt on parandatud, muutub staatus olekuks „Valmis juurutamiseks”.
Avatud - kasutuselevõtuks valmis
Juurutamine on protsess, kus muudatused laaditakse üles serverisse, nii et testimismeeskond saaks töötada koodi fikseeritud versiooniga. Tavaliselt on igal projektil selle ülesande jaoks eraldi juurutusmeeskond.
Nii et kõrgel tasemel koosneb tarkvarameeskond peamiselt neist 3 grupist -
- Areng
- Defektide olelustsükkel testimisel
- Kasutuselevõtt (või mõnikord nimetatakse seda ka meeskonnana)
Kui ehitamine on kasutusele võetud ja defekt on uuesti testimiseks saadaval, määratakse see uuesti testimise jaoks sobivale testijale.
Defekt määratud - juhtme testimine.
Testijuht - individuaalne testija.
Määratud defekt - individuaalne testija.
Mõnes töökohas määratakse defekt kõigepealt testjuhtmele ja ta omistab selle omakorda üksikule testijale, kuid mõnes kohas määratakse defekt otse testijale, kes seda testib, või sellele, kes defekti tõstis.
Olek muutub siin juurutusvalmiduseks - valmis SIT-testimine.
Nüüd on defekt testija taldrikul. Testimisrühm valib defekti ja selleks on kaks võimalust, kas parandus töötab korrektselt või ilmneb sama probleem uuesti. Sõltuvalt tulemustest võib defekt liikuda järgmistesse olekutesse -
Valmis SIT-i testimine - suletud
Valmis SIT-i testimine - avage uuesti
Mõlemas ülaltoodud stsenaariumis peab testija lisama tehtud katsete kommentaarid. See hõlmab testitud stsenaariumide ja kasutatud andmete mainimist. Kui defekt uuesti avatakse, peaks testija andma täpsed toimingud, mis uuesti tõrkeni viisid.
Taasavamise olek on sama nagu defekti olek „Uus”.
Kui defekt on uuesti avatud, järgib see uuesti sama tsüklit.
Defektide olelustsükli probleemid
- Defektide tõsiduse üle otsustamine - see on testijate v / s-i arendajate seas üks levinumaid aruteluteemasid (sageli kaklevad).
- Defekti ei saa arendaja süsteemis korrata.
- Stsenaariumi korral ilmnenud puudus, mida ei ole nõuetes ja kujundusdokumentides nimetatud.
- Defekt leitakse, kuid seda ei saa tõsta, kuna stsenaariumi esinemine tootmiskeskkonnas pole teostatav.
Kuidas peaks testija ületama väljakutseid?
- Tõsidus on otseselt võrdeline defekti poolt rakendusele avaldatava mõjuga, kui testija ei saa defekti tõttu edasi tegutseda, on see kindlasti märgitud suurima raskusastmega.
- Kui testimise jätkamiseks on olemas lahendus, tuleks see märkida keskmise raskusastmega. Lisaks edasise defektide olelustsükli testimise mõju kaalumisele võib tõsiduse üle otsustada ka olukorra, kus kogu moodul tõrkub, isegi juhul, kui testida saab mõnda teist moodulit, kuid praeguse mooduli tõsidus on kõrge nii et defekt peaks olema märgitud kõige tõsisemaga.
- Kui defekti ei saa arendaja süsteemis korrata, on tõenäoline, et arendus- ja testimiskeskkond pole sünkroonis. Testimissüsteemis korratavat defekti peetakse alati kehtivaks defektiks.
- Võib esineda olukordi, kus defekt registreeritakse ettevõtte üldist stsenaariumi arvestades, kuid otsest stsenaariumi ei ole nõuetes ega kujundusdokumendis nimetatud. Parimaks tavaks peetakse alati katseetappide järgimise asemel arvesse võtma tegelikke äristsenaariume. Suhtlus ärianalüütikute ja muude sidusrühmadega mängib olulist rolli selliste puuduste tuvastamisel.
- On stsenaariume, kus testija avastab testimisfaasis lünga äriloogikas. Selliste lünkade leidmist peetakse jälle testija suureks plussiks. Kujunduslünki käsitletakse tavaliselt täiustuste kaudu.
- Parandamine - kui tarkvara elutsükli testimise ajal tuleb käitumist muuta, luuakse täiendus, mida saab kasutada praeguses või järgmises väljaandes, võttes arvesse arendus- ja testimisrühmade ajakava ja ribalaiust.
- On mõned stsenaariumid, mida testija võib sihtotstarbelise testimise käigus katsetada, mis võivad tegelikult olla valed stsenaariumid, arvestades nende esinemise võimalust tootmises.
Kes on testija parim sõber?
Kuhu testija peaks ebaselguse korral pöörduma? Vastus sõltub päringu tüübist. Kui päring puudutab nõudeid, on soovitatav kõigepealt meeskonnas arutada, et korrektsem süsteemist aru saada, näiteks vanemate liikmetega nõu pidades. Järgmine kontaktpunkt peaks olema ärianalüütikud.
Kui päring puudutab testimisprotsessi, on soovitatav pöörduda testimisjuhtkonna või testihalduri poole.
Kui päring on seotud rakenduse tehniliste võimaluste mõistmisega, võib arendusmeeskonna liige olla õige inimene, kelle poole pöörduda.
Kuna testimine on protsess, mis nõuab süsteemi üldist mõistmist, aitab suhtlus testijal saada küsimustele kiire vastus, see sõltub lihtsalt õigetele isikutele õigete küsimuste esitamisest. Õigel ajal küsimuste esitamisest kõrvale hiilimine võib põhjustada defekti lekkimise tootmiskeskkonda.
Kui oluline on täna testija roll ettevõttes?
On projekte, kus testimismeeskond on võrdselt oluline kui arendusmeeskond ja mõne stsenaariumi korral on rohkem sõltuvust katsemeeskonnast kui arendusmeeskonnast. Hilisem stsenaarium on haruldane, kuid mõnes töökohas on see olemas. See on juhtunud aja jooksul ja võib olla mingil konkreetsel perioodil, kui arendusmeeskond pole testimismeeskonnaga võrreldes palju kogenud. On inimesi, kes mõistavad üldist voogu ja funktsionaalsust paremini kui enamik teisi meeskonnaliikmeid. Selline inimene võiks olla osa testimis- / arendusmeeskonnast. See on üks teguritest, mis otsustab konkreetse projekti sõltuvuse meeskonnast / üksikisikust.
Milline on testija karjäär?
Inimesel võib kuluda natuke aega, et mõista üldist testimisprotsessi, domeeni ja muid ülesandeid, millega ta eeldatavasti igapäevases elus tegeleb. Selle mõistmise põhjal on soovitatav võtta vastu otsus uurida täiendavaid valdkondi, mida testija võiks kasutada. Protsessis on alati võimalusi erinevate voogude automatiseerimiseks. Väikeste kommunaalkulude loomine võib meeskonda ka suuresti aidata. Kui testija oskab hästi programmeerida, peetakse seda suureks plussiks. See avab võimalused automatiseerimisrollide jaoks. Jõudluskontroll on ka testijate üks karjäärivõimalusi. Ärianalüütik on veel üks võimalus. Ettevõtte analüütikuteks on vajalikud oskuste kogumid, millel on head suhtlemisoskused. Testimine avab testijatele palju võimalusi töötada erinevates domeenides, tööriistades, protsessides ja nii edasi. See sõltub lihtsalt inimesest, et ta kiireneks ühe testimise põhipiirkonna sisemusse ja hakkaks seda tegema. Testimisvaldkondadele spetsialiseerumiseks on palju eri tööriistadele omaseid sertifikaate. Tavalise müüja sertifikaadi omamine on karjääri edendamiseks eelis, kuid ainuüksi sertifikaat ei saa teid pikemas perspektiivis aidata, kui see pole ühendatud õige töökogemusega.
Soovitatavad artiklid
Siin on mõned artiklid, mis aitavad teil tarkvaratestimise kohta üksikasjalikumat teavet saada, nii et minge lihtsalt lingi kaudu.
- 6 kõige hämmastavamat tarkvaratestimise intervjuu küsimust
- Karjäär tarkvara testimisel
- Kuidas saada paremat karjääri kasvu tarkvaratesterite töös