fbpx

Olenemata sellest, kas kodeerite tarkvara oma ettevõtte liikmetele või laiale kliendibaasile, õigete testimistavade ja raamistike olemasolu, olgu need siis käsitsi, automatiseeritult või hübriidselt, viib järjepideva tarkvara kvaliteedi, parema maine ja tõhususe saavutamiseni.

Sõltuvalt sellest, millises ettevõttes te töötate, toimub suur osa testimisest käsitsi.

Lugege lähemalt, mis on käsitsi testimine, mida ettevõtted testivad käsitsi testimise abil ja mitmeid muid olulisi fakte tarkvara testimise protsesside kohta.

 

Table of Contents

Mis on käsitsi testimine?

tarkvara testimise automatiseerimise segaduse selgitamine

Käsitsi testimine on tarkvara testimise liik, mille puhul testija täidab testjuhtumi käsitsi, ilma automatiseeritud vahendite abita.

Ettevõtted kasutavad manuaalset testimist kui meetodit vigade või probleemide tuvastamiseks oma tarkvaras. Kuigi mõned kirjeldavad seda kui lihtsat või primitiivset testimise vormi, tuvastab see lõppkokkuvõttes programmi funktsionaalsuse ilma kolmanda osapoole testimisvahendeid kasutamata.

Kõigil tarkvara testimise vormidel on mõningaid manuaalseid aspekte, sest on olemas rakenduse mõned funktsioonid, mida on lihtsalt võimatu testida ilma käsitsi sekkumiseta.

 

1. Millal on vaja teha manuaalset testimist?

 

On mitu etappi, kus arendajad kasutavad käsitsi testimist, millest esimene on kogu põhifunktsionaalsuse arendamise etapis.

Kui tarkvara põhifunktsionaalsus on väljatöötamisel, testivad tarkvaraarendajad, et kõik programmi osad toimiksid käsitsi, sest see on kiirem kui testjuhtumite loomine üsna lihtsate koodiosade jaoks.

Manuaalne testimine on levinud ka arenduse viimastes etappides, kui programmile on loodud kasutajaliides. Kasutajaliidese testimine tähendab, et vaadatakse, kuidas reaalne kasutaja reageerib sellele, kuidas menüüd on kujundatud ja kuidas süsteem töötab.

Kuna see hõlmab pigem palju kvalitatiivseid andmeid ja isiklikke arvamusi kui puhtaid kvantitatiivseid näitajaid, on käsitsi testimine ideaalne võimalus toote kohta parema ülevaate saamiseks.

 

2. Kui te ei pea tegema käsitsi testimist.

 

On mõned juhtumid, kus käsitsi testimine võtaks palju rohkem aega ja vaeva kui vaja, esimene neist on andmebaaside testimine.

Andmebaasid töötlevad tohutuid andmehulki ja nende käsitsi sisestamine võtaks palju aega ja oleks organisatsiooni jaoks ebaefektiivne.

Sellistel juhtudel on automaatsete süsteemide kasutamine ideaalne, kuna need suudavad piiratud aja jooksul töödelda suuri andmepakette.

Manuaalne testimine on vähem kasulik ka sellistes valdkondades nagu koormustestid, kus arendaja teeb teste, et näha, kuidas tema tarkvara saab hakkama märkimisväärse kasutajakoormusega.

See kehtib sageli veebirakenduste ja serveriga programmide puhul, mis nõuavad põhjalikku hindamist. Manuaalsete testide läbiviimine nõuaks palju inimesi, kes kõik pääsevad rakendusele korraga ligi, ning see võib põhjustada suuri tööjõukulusid teenuse puhul, mida saab automatiseeritud tarkvara testimise süsteemi abil palju odavamalt teostada.

 

3. Kes on kaasatud käsitsi testimisse?

 

Käsitsi testimisega tegelevad töötajad sõltuvad sellest, millises ettevõttes te töötate.

 

Mõned inimesed, kes on seotud käsitsi testimise protsessiga, lisaks sellele, millises arendusmeeskonnas neid rolle leidub:

 

– Arendaja:

 

Arendaja osaleb protsessis pidevalt, testides tarkvara põhifunktsionaalsust ja tehes koodi uuendusi sõltuvalt QA testija tagasisidest.

Arendajad teevad palju käsitsi testimist, kuna nad vastutavad selle eest, et moodulid töötaksid tarkvaraarenduse varases etapis kõrgetasemeliselt.

 

– QA testija

 

Suuremates meeskondades töötavad QA testijad ainult ettevõtte testimise eest ja tagavad, et rakendus töötab nii, nagu klient ootab.

QA testija on eelkõige oluline arenduse testimise, integreerimise ja hoolduse etapis, võttes üle käsitsi testimise arendajatelt endilt, kes testivad kogu rakendamise ajal.

 

– QA juht

 

Töötab suurimates arendusettevõtetes, QA juhid määravad testijad projekti konkreetsetele ülesannetele ja valdkondadele.

Samuti vastutavad nad täidetavate asjade nimekirja koostamise ja katsearuannete lugemise eest. See on eriti oluline käsitsi testimisel, sest töötajate rahulolu võib anda palju paremaid tulemusi.

 

Mida me testime manuaalsete testidega?

 

Manuaalsete testidega uuritakse mitut erinevat tarkvara aspekti, millest igaüks on manuaalse testimise puhul parem tänu testide spetsiifilistele väljakutsetele.

 

Mõned peamised funktsioonid, mille puhul on manuaalsete testide kasutamisest kasu, lisaks põhjustele, miks manuaalsed testid siinkohal õitsevad, on järgmised:

 

1. Põhifunktsionaalsus

 

Tarkvara testimise protsessi üks esimesi osi on tarkvara põhifunktsionaalsuse kontrollimine.

Selles etapis vaatab arendaja või testija läbi ühe funktsionaalse koodimooduli ja hindab, kas see töötab ootuspäraselt. Kuna need moodulid on väikesemahulised, tasub keskenduda käsitsi testimisele, sest automatiseerimine võtaks liiga kaua aega.

Selle näiteks on andmebaasi tarkvara, mille testijad sisestavad funktsiooni mingi andmestiku ja teavad juba oodatavat väljundit.

Kui need vastavad, on test edukas. Protsessi selles etapis toimuv testimine loob tugeva aluse ettevõtte ülejäänud tööle.

 

2. Kasutajaliidese disain

 

Kasutajaliidese all mõistetakse tarkvara kasutajaliidest ehk menüüd, nuppe ja interaktiivsust, mis on kasutajale kättesaadavad.

Kasutajaliidese testimine keskendub nii sellele, kuidas kasutajaliides töötab, kui ka sellele, kas see on kasutajale mugav, sealhulgas kas kasutaja saab suhelda kõigi funktsioonidega ja kas menüüd on esteetiliselt meeldivad.

Manuaalne testimine on selles etapis hädavajalik, sest kvalitatiivne teave, näiteks kas kasutajaliidesed näevad head välja, ei ole midagi sellist, mida automatiseeritud programm suurepäraselt suudab.

 

3. Penetratsiooni testimine

 

Penetratsioonitestimine tähendab tarkvarapaketi testimist, et näha, kui kergesti saab väline osapool sellele tarkvarale ebaseaduslikul viisil ligi.

Tarkvara automatiseerimine keskendub pigem mõnede konkreetsete sammude järgimisele ja juba rakenduse osaks olevate protsesside lõpuleviimisele kui uute valdkondade uurimisele, mis on turvalisuse testimise puhul hädavajalik.

Näiteks võib ettevõte palgata eetilise häkkeri, kes hindab tema tarkvara ja otsib võimalusi, kuidas pahatahtlik osapool võiks pääseda ligi kasutaja andmetele.

See on üha olulisemaks muutunud pärast seda, kui GDPR on kogu Euroopas seadusega kehtestatud.

 

4. Uurimuslik testimine

 

Uurimuslik testimine viitab testimisele, mida tuleb teha ainult üks või kaks korda, saades selle nime, kuna see on osa tarkvara “uurimisest” ootamatute funktsioonide või vigade leidmiseks.

Manuaalne testimine sobib sellisel juhul paremini, sest testjuhtumi koodi kirjutamine võtab aega ja keegi, kes läheb käsitsi tarkvarasse ja uurib seda, võtab vähem aega.

Selle näiteks on see, kui arendaja tahab kontrollida, kas teatud funktsioon on õigesti integreeritud, kusjuures üks test kontrollib, et andmed liiguvad õigesti läbi programmi.

 

Manuaalsete testide elutsükkel

 

Manuaalsete testide elutsüklis on mitu etappi, kusjuures manuaalset testimist kasutatakse tarkvarapaketi mitmesuguste aspektide uurimiseks.

 

Mõned manuaalsete testide elutsükli etapid on järgmised:

 

– Planeerimine

 

Planeerige testimisvoor, mis hõlmab rakenduse nõuete hindamist, konkreetseid teste, mida tuleb teha, ja ehitust, millega te tarkvara testite.

Selles etapis kirjutatakse kõik testjuhtumid, mida manuaalne testija peab täitma, ja luuakse testkeskkond. Olge põhjalik, et vältida seda, et manuaalsed testijad teeksid teste kogemata erinevalt.

 

– Testimine:

 

Täitke testid. See hõlmab testjuhtumite mitmekordset läbimist, et saada järjepidevaid andmeid ja märkida üles kogu saadud teave.

Kui te erinete üldse testjuhtumist, märkige üles, kuidas ja miks. Erinevused on kõige tavalisemad otsestest testide puhul, kuid kõikidel käsitsi tehtavatel testidel võib esineda mõningaid erinevusi testija töös.

 

– Analüüs:

 

Analüüsige kõiki testidest saadud tulemusi. See hõlmab tarkvara vigade ja võimalike probleemide põhjuste väljaselgitamist.

Minge kaugemale lihtsast funktsionaalsusest ja integreerige kvalitatiivset teavet, näiteks kaaluge rakenduse disaini.

Kvalitatiivne teave õitseb eriti hästi käsitsi testimisel, sest testijad koguvad kirjeldavaid andmeid, mis annavad arendajatele teavet väikestest kohandustest, mis parandavad oluliselt kellegi kogemust rakendusega.

 

– Rakendamine:

 

Kasutage eelnevaid aruandeid mitmesuguste muudatuste rakendamiseks. Olenevalt muudatustest võib see olla pikk protsess, kus arendajad katsetavad koodiga, et leida lahendus eelmistes versioonides esinevatele vigadele.

Manuaalse testimise kasutamisel saavad arendajad lisakasu sellest, et nad räägivad kõik muudatused koos testijaga läbi. See aitab mõlemal poolel korralikult mõista, mida on vaja kohandada ja kuidas seda saab kohandada, olenemata sellest, kas tegemist on funktsionaalse või disainimuudatusega.

 

– Taaskäivitage planeerimine:

 

Samal ajal, kui arendajad loovad eelmiste testide probleemide lahenduse, planeerige järgmise testide komplekti. See hõlmab viimaste uuenduste testimist ja viimases versioonis esinenud vigade taastamist.

See pidev testide tsükkel tähendab, et tarkvara on alati paranev ja mitte kunagi staatiline. Käsitsi testimine võib tunduda, et see võtab kaua aega, kuid paindlikkus ja järjepidevus, mida see pakub korduvtestide puhul, annab investeeringule märkimisväärset tulu.

 

Manuaalse testimise eelised

 

Manuaalse testimise kasutamisest on tarkvaraarendusettevõttes palju kasu, alates tarkvara enda kvaliteedist ja lõpetades sellega, kuidas projekt mõjutab ettevõtte rahaasju.

 

Mõned käsitsi testimise kasutamise eelised ettevõttes on järgmised:

 

1. Suurem paindlikkus

 

Testide automatiseerimiseks on vaja, et QA analüütik läheks tarkvarasse ja kodeeriks testjuhtumi, mis täidab iga kord täpseid samme.

Kuigi see on mõnikord kasulik, võib inimtester läbida protsessi ja märgata midagi ebakorrektset enne uurimist ja ilma, et ta peaks muutma ühtegi rida koodi.

See suurendab oluliselt teie testide paindlikkust ja tähendab, et leiate oma programmis probleeme, mis muidu jääksid märkamata, ning teil on suurem võimalus neid probleeme parandada.

 

2. Kvalitatiivne teave

 

Kvalitatiivne teave viitab teabele, mis kirjeldab midagi, ja seda tüüpi teavet saavad inimtestijad pakkuda arendajate meeskonnale.

Manuaalne testija saab ettevõttele teada anda, kui teatud menüü tundub “kohmakalt” ja selgitada, miks, samas kui automatiseerimisprogramm ei suuda seda arendajale pakkuda.

See tähendab, et rakendades käsitsi testimist oma töövoogudesse, saavad ettevõtted märkimisväärselt tõsta rakenduse standardit viisil, millega nad oleksid hädas, kui nad kasutaksid oma protsessides ainult testide automatiseerimist.

 

3. Keskkonnast tulenevaid piiranguid ei ole

 

Automatiseeritud testimine põhineb olemasoleva platvormi kasutamisel, kusjuures mõnel neist on suhteliselt ranged piirangud.

Piirangud, millega mõned (kuigi mitte kõik) platvormid silmitsi seisavad, hõlmavad seda, et nad ei saa töötada selliste platvormidega nagu Linux, nad saavad töötada ainult teatud kodeerimiskeelega ja nad saavad töödelda ainult teatud arvu ülesandeid.

Kui töötate oma testimisprotsessides koos inimestega, kaovad need piirangud tegelikult ära. Teid piiravad ainult teie käsitsi testijate oskused, mitte aga tehnilised probleemid.

See aitab teil luua testimisstrateegia, mis uurib programmi põhjalikumalt, ilma et peaksite tegema kompromisse.

 

4. Võimaldab kasutatavuse testimist

 

Kasutatavuse testimine on selline testimine, mille käigus hinnatakse, kas tarkvara on “kasutatav”, sealhulgas seda, kuidas see lõppkasutajale tundub ja kas see on kasutatav.

Seda tüüpi testimine läheb kaugemale sellest, et hinnata sõna otseses mõttes, kas funktsiooni saab kasutada, vaid uuritakse, kas keegi otsustaks seda konkureerivate toodete asemel kasutada.

Manuaalse kasutatavuse testimise rakendamine annab ettevõtetele parema ülevaate ja aitab teha kohandusi, mis muudavad rakenduse konkurentsivõimelisemaks, mida automatiseerimine ei suuda arendusmeeskondadele pakkuda.

 

Manuaalse testimise väljakutsed

 

Nagu igasuguse protsessi puhul arendajana, on ka käsitsi testimise kui kvaliteedi tagamise vahendi kasutamisega seotud mõned väljakutsed.

Olles teadlik neist probleemidest, saate kohandada tarkvara käsitsi testimisel kasutatavat tehnikat, vältides nii, et need probleemid ei põhjustaks tõsiseid probleeme, ja tõstes protsessi lõpus programmi standardit.

 

Mõned peamised probleemid, millega ettevõtted seisavad silmitsi, kui nad kasutavad manuaalset testimist, on järgmised:

 

1. Testija oskuste tase

 

Esimene suur väljakutse, millega tuleb toime tulla, on kõigi meeskonna manuaalsete testijate nõutav oskuste tase.

Andekate manuaalsete testijate abil näevad ettevõtted selget kasu, sest nad leiavad vead kiiremini ja on kindlad, et nende tarkvara töötab ootuspäraselt. Parimad ettevõtted otsivad alati manuaalseid testijaid, kes on oma ala esirinnas, et tagada suurem jõudlus.

Testijana püüdke alati õppida ja arendada neid oskusi. Paremad oskused tähendavad, et annate ettevõttele rohkem väärtust, sest käsitsi testimine leiab rohkem vigu ja parandab kasutajakogemust. Parimad manuaalsed testid pärinevad testijatelt, kes on kulutanud aega oma oskuse lihvimisele.

 

2. Testimise maksumus

 

Manuaalne testimine on igas suuruses ettevõtete jaoks tavaline protsess, kuid sõltuvalt sellest, kuidas te käsitsi testimist kasutate, võivad kulud suureneda.

Näiteks võib ettevõte, kus on mitu kõrge kvalifikatsiooniga testijat, kulutada palju raha, kui testimine toimub korduvalt, sest te maksate tegelikult iga kohalviibija aja eest. See on automatiseeritud testimisprotsesside puhul vähem probleemiks.

Ideaalne vastumeede sellele probleemile on ette planeerimine, sest mida rohkem aega kulutate testide planeerimisele ja nende tegemise järjekorrale, seda väiksem on võimalus, et personalikulud suurenevad, kuna inimesed teevad teste, mida nad ei pea tegema.

 

3. Ajamahukas

 

Arvutid on inimestest kiiremad igasugustes asjades, alates malekäigu kavandamisest kuni raha investeerimiseni börsil või isegi lihtsalt nupu vajutamisest pärast värvimuutust. Sama kontseptsioon kehtib ka testimise puhul, kus kasutajatel kulub aega kogu teabe lugemiseks ja menüüdes navigeerimiseks.

Manuaalne testimine võib seega võtta palju kauem aega kui testide automatiseerimine. Selle vastu võitlemiseks kasutage manuaalsete ja automatiseeritud testide kombinatsiooni, võtke manuaalsete testijate alt ära lihtsad ülesanded ja kasutage neid hoopis seal, kus on vaja ekspertiisi. Protsesside lihtsustamine on ideaalne ka käsitsi testimise jaoks, sest see võtab ära võimalikult palju samme.

 

4. Võimalikud vead

 

Inimesed teevad vigu. See on loomulik, olgu see siis testi sammude vales järjekorras täitmine või tulemuste ebatäpne märkimine tänu valele klõpsule. Need vead võivad aga põhjustada tõsiseid probleeme tarkvara testimise korra täpsusega.

Manuaalsed testijad, kes on väsinud või väsinud sama ülesande täitmisest ikka ja jälle, teevad suurema tõenäosusega vigu kui teised, seega kasutage võimaluse korral automatiseerimist, et seda vältida, või tehke testijatele regulaarselt pausid, sest see hoiab neid tähelepanelikumalt toimuvaga kursis.

Juhid võivad kaaluda ka töökoormuse juhtimist, et vältida inimeste läbipõlemist ja probleemide tekkimist.

 

Manuaalsete testide omadused

 

Käsitsi tehtavatel testidel on mõned peamised omadused, mida tuleb otsida. Need määratlevad, mis on käsitsi tehtav test, ja on olulised omadused, mida saate oma testide kavandamisel arvesse võtta.

 

Lugege lähemalt mõnest manuaalsete testide peamisest omadusest ja sellest, mida need aktiivse testimise keskkonnas tähendavad:

 

1. Optimeeritud testjuhtumid

 

Käsitsi testimise puhul on testjuhtumid väga optimeeritud. See viitab juhistele, mis manuaalsel testijal on testi lõpetamise ees, kusjuures kõrge optimeerimise tase toob kaasa testimismeeskonna aja- ja ressursisäästu, kuna nad täidavad vähem ülesandeid.

Katsuge alati piirata testjuhtumi suurust, kui see on võimalik, et kasutada olemasolevaid ressursse maksimaalselt ära.

 

2. Arusaadavamad mõõdikud

 

Parimal manuaalsel testimisel on arusaadavamad mõõdikud. Kui testide automatiseerimine genereerib pidevalt keerulist statistikat ja teavet, ei ole nende näitajate pakutav ülevaade väärt seda aega, mis kulub käsitsi testerile nende täitmiseks või arvutamiseks.

Alternatiivina hõlmavad manuaalsed testid palju lihtsamaid mõõdikuid, mida on lihtne genereerida ja mille hilisem analüüs võtab vähem aega.

 

3. Intelligentne aruandlus

 

Käsitsi testimine viib testimismeeskonna arukama aruandluse koostamiseni. Automaatsed testid genereerivad protsessi lõpus oma aruandeid, mille tulemuseks on, et kõik aruanded on ühesuguses formaadis.

Inimtestijad on palju paindlikumad ja saavad ise aruandeid koostada, lisades vajaduse korral arendusmeeskonnale mis tahes teavet, mida nad peavad kasulikuks.

 

4. Strateegiate uuesti käivitamine

 

Kordusstrateegia viitab viisile, kuidas testimismeeskond teste ikka ja jälle läbi viib, kogudes andmeid ülesannete korduval täitmisel.

Käsitsi testimine tähendab, et korduvtestimise strateegiad on palju paindlikumad, sest testijad saavad teha rohkem teste, kui nad arvavad, et on veel midagi uurida.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Mõned manuaalsed testid soodustavad aktiivselt ka kasutaja sooritatavate tegevuste varieeruvust, andes andmeid laiema käitumisvahemiku kohta. See loob rohkem andmeid tarkvara kohta ja viib ühtsemate ajakohastamisstrateegiate väljatöötamiseni.

 

Manuaalsete testide tüübid

 

Ettevõtted kasutavad kolme erinevat tüüpi manuaalset testimist, mille erinevus sõltub testijate juurdepääsu tasemest. Iga tüüp on kasulik oma ainulaadses kontekstis.

 

Manuaalsete testide peamised liigid on järgmised:

 

1. Valge kasti testimine

 

Valge kasti testimine on testimise vorm, mille puhul testijad saavad näha kogu tarkvara lähtekoodi ja projekteerimisdokumentatsiooni.

Selline suurem juurdepääs tähendab, et testija saab näha kõiki koodi üksikuid aspekte ja seda, kuidas need mõjutavad tarkvara toimimist. See on ideaalne arendusprotsessi kõige varasemates etappides, sest arendajad saavad oma koodi käsitsi vaadata, võrrelda seda testjuhtumitega ja leida hõlpsasti üles ala, mis põhjustab olulisi probleeme, enne kui nad olemasolevaid vigu parandavad.

 

2. Musta kasti testimine

 

Musta kasti testimine viitab testimise vormile, mille puhul testijad ei näe, mis toimub kasutajaliidese taga. See tähendab, et puudub juurdepääs koodile või projekteerimisdokumentatsioonile, mistõttu testijad lähenevad tarkvarale täieliku teadmatusega.

Manuaalsed testijad kasutavad seda lähenemisviisi arendusprotsessi viimastes etappides, kuna kasutaja vastuvõtu testimine ja lõpp-testimine nõuavad pigem lõppkasutaja kui arendusprotsessis osaleva isiku vaatenurka.

 

3. Grey box testimine

 

Halli kasti testimine on kombinatsioon musta kasti ja valge kasti testimisest ning nõuab, et testija saaks näha osa dokumentatsioonist ja lähtekoodist. See ühendab endas eelise, et on võimalik näha probleemide võimalikke põhjusi, kuid samas piiritleb teavet, aidates selliseid funktsioone nagu andmete käitlemine.

Kasutage kogu arendusprotsessi vaheetapis käsitsi halltasandi testimist, andes testijatele lisateavet, kuid sundides neid siiski paljuski oma intuitsioonile tuginema, et lõppkasutaja saaks süsteemidest aru.

 

Segaduse selgitamine – Manuaalne testimine vs. automatiseeritud testimine

 

Tarkvara testimisega on seotud kaks eri valdkonda, käsitsi testimine ja automatiseeritud testimine. Hoolimata sellest, et mõlemal on tegelikult sama funktsioon, on need erinevad distsipliinid, mida ettevõtted kasutavad oma tarkvarapakettide kontrollimiseks.

Lugege edasi, et saada rohkem teavet selle kohta, mis on automatiseeritud testimine, erinevus automatiseeritud testimise ja käsitsi testimise vahel ning millal kasutada mõlemat tüüpi testimist teie tarkvara kvaliteedikontrolli protsessides.

 

1. Mis on automatiseeritud testimine?

 

Automaattestimine on protsess, mille käigus testija kasutab kolmanda osapoole tööriista, et automatiseerida tarkvara, uurides tarkvara, kuna see korduvalt täidab sama protsessi, et tagada, et see täidab organisatsiooni jaoks piisavalt kõrgeid standardeid. Testide automatiseerimise peamine eelis on see, et see on palju kiirem protsess, eriti kui täidetakse selliseid lihtsaid ülesandeid nagu andmete sisestamine.

Selle näiteks on andmebaasi testimine, et tagada kogu teabe nõuetekohane töötlemine, tuhandete andmete sisestamine tarkvarasse mõne hetkega ja tulemuste hindamine pärast seda.

Ettevõtted kasutavad automatiseeritud testimist peamiselt suurte ja väga korduvate ülesannete puhul. Kuna automatiseeritud süsteem ei tee väiksemaid vigu, näiteks sisestades vale teabe või klõpsates valel lingil.

Mõned peamised tarkvarad, mis seda kasutavad, on live-serverid ja andmebaasid, kuna need käitlevad palju teavet ja suurt kasutajakoormust, mistõttu on vaja testimise vormi, mis vastab nõudmistele.

 

2. Mis vahe on manuaalsetel ja automatiseeritud testidel?

 

Peamine erinevus manuaalsete ja automatiseeritud testide vahel on nende täitmise meetod.

Manuaalne testimine tugineb täielikult inimesele, kes viib testimise lõpule, jälgib testjuhtumit lõpuni ja märgib seejärel kõik andmed üles.

Automaatsete testide puhul vastutab arvutiprogramm testjuhtumite täitmise eest pärast seda, kui QA analüütik on need algselt kirjutanud.

Mõned automatiseeritud testiplatvormid genereerivad kasutajatele ka oma aruandeid, mis vähendab aega, mida keegi peab kulutama kõigi eksperimendi andmete kogumisele. Selle asemel saavad nad oma aega kulutada tarkvarapaketi probleemide lahendamiseks.

 

3. Kokkuvõte: Automaatne testimine Vs automatiseeritud testimine

 

Manuaalse ja automatiseeritud testimise vahel on mõned põhimõttelised erinevused, kuna need kaks kontseptsiooni tuginevad täiesti erinevatele alustele, et korralikult toimida.

Siiski saavad nad paljude arendusprojektide puhul teha tihedat koostööd. Kasutades automatiseeritud testimist mõne raskema ülesande puhul ja rakendades manuaalseid testimistehnikaid nende puhul, mis sõltuvad suuremast paindlikkusest, saate oma testimisprotsesse märkimisväärselt kiirendada.

Üks suurimaid väärarusaamu testimise kohta on see, et teil tuleb teha binaarne valik, kuid see ei võiks olla kaugemal tõtt, kui tegemist on tõhusa kvaliteedi tagamise meeskonnaga.

 

Manuaalse testimise 5 müüdi ümberlükkamine

 

Manuaalse testimise ümber on mõned müütid, mida inimesed usuvad, millest igaüks suunab inimesi järgima vähem kui ideaalseid meetodeid ja muudab tulemuste saamise keerulisemaks kui vaja.

 

Viis peamist müüti, mis ümbritsevad käsitsi testimist, on järgmised:

 

1. Testimine on ainus osakond, mis vastutab toote kvaliteedi eest

 

Toote kvaliteet on kogu ettevõtte, mitte ainult kvaliteedi tagamise meeskonna ülesanne.

Tarkvara testimine on olemas selleks, et eemaldada vead, kus iganes võimalik, mis tähendab, et paljud inimesed näevad vigade parandamist ja leidmist kui QA meeskonna ainupädevust. Vastupidi, arendajad ise vastutavad koodi kirjutamise eest, samas kui juhtkond vastutab arenduse korraldamise eest.

Igaühel, kellel on ettevõttes mingi roll, on teatav vastutus piisavalt kõrge standardiga toote loomise eest, selle asemel, et loota testimismeeskonnale, kes leiab kõik probleemid ja saadab toote pärast seda võimalikult kiiresti välja.

 

2. Käsitsi testimine ei ole enam oluline

 

Seoses tehisintellekti ja üha enam levinud robotiseeritud protsesside automatiseerimise levikuga on mõned, kes usuvad, et käsitsi testimine ei ole tarkvaraarenduses enam oluline. Ettevõtted näevad automatiseerimise suhtelist odavust ja otsustavad seda teed valida igal võimalusel.

Käsitsi testimine on endiselt üks ettevõtte kõige olulisemaid vahendeid tänu E2E, musta kasti ja GUI testimise kasulikkusele. Manuaalse testimise rakendamisega leiavad ettevõtted tarkvaraprobleeme, mida automaatika muidu ei avastaks, parandades oma toodet rohkem kui võimalik kasu, mida nad võiksid näha ainult automatiseerimise abil.

 

3. See on mõeldud inimestele, kes ei oska kodeerida.

 

Üks peamisi eeldusi, mis mõnedel inimestel on, on see, et inimesed, kes ei oska kodeerida, otsustavad hoopis testida.

See on aga kaugel tõest. Koodikirjaoskus on paljudes testimisülesannetes kohustuslik, sest halli ja valge kasti testimine põhineb koodi lugemisel ja arusaamisel, kuidas see võib kaasa aidata tarkvarapaketis esinevate vigade tekkimisele.

Eeldades, et testimisega tegelevad ainult inimesed, kes ei oska koodi koostada, piirdute potentsiaalselt sellega, et teie meeskonnas on madalama tasemega testimispersonal. Kui olete testija, kaaluge oma standardite parandamiseks kodeerimiskursuse läbimist.

 

4. Saate luua veavaba tarkvara

 

Mõned inimesed tulevad käsitsi testimise valdkonda eeldusega, et kvaliteedi tagamise meeskond suudab leida kõik vead tarkvaras ja aidata arendusmeeskonnal need lahendada.

Teoreetiliselt võiks see viia toote valmimiseni, millel ei ole üldse mingeid vigu ja mis rahuldab klienti täielikult. See on muidugi tarkvara testimise ideaalne lõppeesmärk, kuid see on harva võimalik.

Isegi maailma suurimate firmade kõige paremini häälestatud tarkvarapaketid sisaldavad vigu, ja kuigi eesmärk peaks olema vähendada vigade arvu nii palju kui võimalik, ei ole tegelikult kahju, kui paar väiksemat probleemi jõuavad lõplikku versioonile. Sel põhjusel on oluline avaldamisjärgne käsitsi testimine ja arendamine.

 

5. Testimine ei anna mingit lisaväärtust

 

Üks suurimaid müüte mis tahes vormis tarkvara testimise ümber on see, et see ei anna tarkvarapaketile mingit lisaväärtust. Kliendid hindavad aga alati kvaliteeti kui ühte rakenduse kõige olulisemat aspekti, vigased või madala kvaliteediga programmid kaotavad kohe oma kasutajad, kes otsivad alternatiive.

Lihvitud toode on ettevõttele palju väärtuslikum kui see, mis ei tööta korralikult, ja selle töö keskmes on tõhus testimine. Kõrgtehnoloogiline testimine toob märkimisväärset tulu, kui ettevõtted otsustavad korralikult investeerida.

Lühidalt öeldes annab hübriidne käsitsi + automatiseeritud testimise strateegia alati parema testi tulemuse kui ükskõik kumba neist strateegiatest, kui neid kasutatakse ainult.

 

Mida on vaja käsitsi testimise alustamiseks?

 

On mõned asjad, mida vajate käsitsi testimise alustamiseks, ja kui teil on kõik need funktsioonid olemas, siis on testimine mitte ainult lihtsam, vaid üldse võimalik.

 

Mõned asjad, mida on vaja käsitsi testimise alustamiseks, on järgmised:

 

1. Tarkvara

 

Esimene asi, mida testija vajab tarkvara testimiseks, on tarkvara ise. Lõppude lõpuks on manuaalne testimine tegelikult võimatu, kui midagi testimiseks ei ole olemas.

Tõhus tarkvara testimine hõlmab tarkvara kõige uuema iteratsiooni kasutamist, kuna see sisaldab kogu kasutaja vajadustele vastavat lähtekoodi ja esindab toodet õiglasemalt praegusel kujul.

Kui võimalik, koostage rakendus täiesti värskelt, et saada võimalikult täpne ülevaade tarkvarast.

 

2. Tarkvara nõuded

 

Testijal peab olema juurdepääs tarkvara nõuetele. See ei viita riistvarale või operatsioonisüsteemile, mida pakett vajab, vaid pigem selle tarkvara lühikirjeldusele, mille kallal arendaja töötab.

Kui testimise etapis on tarkvara nõuded üksikasjalikumad, tähendab see, et kvaliteedi tagamise töötajad otsivad algusest peale kõiki olulisi funktsioone, märkides üles, kus on probleeme tarkvaraga, ja soovitades kohandusi.

Ilma selleta töötab testija ilma igasuguse juhendamiseta ja ei tea, kas tema poolt edastatav teave on arendusmeeskonnale tegelikult kasulik.

 

3. Sobiv riistvara

 

Tarkvara testimiseks on vaja riistvara, mis vastab selle programmi vajadustele, mida see töötab.

Näiteks kui testija otsib vigu või probleeme uues videomängus, mis nõuab täiustatud riistvara ja tal on ainult madala tasemega arvuti, ei saa ta tarkvara korralikult testida.

See on väiksem probleem väikeste rakenduste või veebitööriistade puhul. Veenduge, et kasutatav riistvara vastab tarkvara vajadustele, enne kui alustate testimist, valides riistvara pärast konsulteerimist arendusmeeskonnaga tarkvara nõuete osas.

 

Käsitsi testimise protsess

 

Käsitsi testimise protsessis on mitu sammu, millest igaüks mängib oma osa teie programmi täpse ülevaate andmisel.

 

Need sammud hõlmavad järgmist:

 

1. Analüüsige nõudeid

 

Manuaalse testimise esimene samm on rakenduse nõuete analüüsimine. See hõlmab rakenduse lühikirjelduses loetletud erinõudeid, mõningaid disainidokumendi funktsioone ja kõiki muid programmi osi, mida te ootate (näiteks juriidilised nõuded).

Nende analüüsimine protsessi alguses tähendab, et te teate, mida te tarkvara uurides testite.

 

2. Loo testimisplaan

 

Kui teate, mida on vaja testida, koostage testimisplaan. See tähendab, et te peate teadma, milliseid funktsioone te testite, kuidas täpselt te neid testite ja millal te need testid lõpetate.

Testimisplaani koostamisega tagate, et kõik vajalikud testid on ette valmistatud ja et te ei jäta kogemata ühtegi funktsiooni kasutamata.

See aitab ka tööjõu haldamisel, sest te teate, kui palju ja millal käsitsi testereid vajate.

 

3. Testjuhtumite kirjutamine

 

Alustage tarkvara testjuhtumite kirjutamist. Testjuhtum on sündmuste kogum, mida täidate tarkvara testimisel, järgides neid iga kord rangelt, et veenduda, et tegemist on õiglase testiga.

Mõelge igal juhul läbi konkreetne käsitsi tehtav test ja lisage võimalikult palju üksikasju, sest see vähendab võimalust, et keegi kaldub esialgsest plaanist kõrvale.

 

4. Vaadake oma juhtumid läbi

 

Pärast kõigi testjuhtumite kirjutamist vaadake need põhjalikult läbi. See hõlmab testjuhtumite üleandmist juhtivtöötajatele, eelistatavalt kvaliteedijuhtidele.

Kolmanda osapoole kaasamisega korrektuuriprotsessi tõstate testjuhtumite standardit, kõrvaldades võimalikud vead. Juhendaja saab teha ettepanekuid paranduste kohta, mis lõppkokkuvõttes muudavad teie käsitsi testimise tõhusamaks ja aitavad teil leida rakenduses kõik probleemid.

Veenduge, et iga üksik testjuhtum on enne testide teostamist kontrollitud.

 

5. Viige läbi manuaalsed testid

 

Kui juht kinnitab testjuhtumi, alustage testide täitmist. Järgige neid protsessi alguses sätestatud järjekorras, et tagada iga testi lõpuleviimine ja tagada, et inimesed täidavad testid aeglaselt ja hoolikalt.

Kui saad testid 100%-liselt õigesti teha, säästad palju aega, kuna pead mõnes täitmises vigu tegema ja tagasi minema ning uuesti kontrollima, kas tulemused on õiged.

Kirjutage teave üles, et vähendada võimalust, et unustate olulise teabe ära.

 

6. Teatage kõikidest vigadest

 

Kui olete lõpetanud manuaalsed testid ja leidnud kõik vead, lõpetage aruandlusprotsess.

See hõlmab aruande koostamist arendusmeeskonnale, kus on loetletud kõik vead, kus te need leidsite ja sammud, mida te nende taastamiseks võtsite. Kaasa kõik andmed, mida te oma testimisel genereerite.

Kvalitatiivsematel testidel arutage üksikasjalikult rakenduse disaini, mis tahes probleeme, mis teil esinesid, ja mõningaid võimalikke parandusi, mis muudavad rakenduse kasutajasõbralikumaks.

Pidage meeles, et just selles etapis on manuaalne testimine automaatika suhtes tõeliselt hea, sest manuaalsed testijad saavad anda kvalitatiivset teavet, mida automaatika sageli ei suuda.

 

Parimad praktikad manuaalseks testimiseks

 

Parimad tavad viitavad mõningatele asjadele, mis on ühised kõigis manuaalse testimise liikides, mis aitavad parandada testimisprotsessi standardit. Parimate tavade järgimine tähendab lõppkokkuvõttes seda, et saate kvaliteetse testi, millel on täpsed ja usaldusväärsed tulemused.

 

Mõned parimad tavad, mida tuleb silmas pidada, kui läbite käsitsi testimise protsessi:

 

1. Keskendu selgusele

 

Selguse rõhutamine kogu manuaalse testimise käigus on hädavajalik.

Võimalikult selge olemine vähendab osakondade ja spetsialistide vahelise väärteomenetluse võimalust, aidates inimestel keskenduda tarkvara õigete valdkondadega tegelemisele. See on eriti oluline käsitsi testimisel, kuna seal on rohkem ruumi juhiste tõlgendamiseks.

See hõlmab selge testjuhtumi kirjutamist, mida testija saab järgida, tulemuste märkimist lihtsal ja arusaadaval viisil ning kõigi organisatsiooni liikmete abistamist, et nad saaksid aru rakendusele esitatavatest nõuetest.

 

2. Kasutage pidevat läbivaatamist

 

Vaadake kõik testimise käigus läbi nii sageli kui võimalik.

Tõhus läbivaatamisprotsess hõlmab tähelepanu pööramist sellele, kuidas töötajad toimivad, testjuhtumite läbivaatamist, et kontrollida, kas need töötavad ikka nii, nagu te ootate, ja tarkvara enda läbivaatamist, et veenduda, et edusamme tehakse.

Hoides silma peal protsessi iga üksiku aspekti kvaliteedil, tagate, et standardid ei libise ja et saate algusest lõpuni piisavalt kõrgetasemelise toodangu.

 

3. Ärge lihtsalt jahtige vigu

 

Mõned inimesed arvavad, et tarkvara testimise peamine eesmärk on leida vigu, kuid see pole kaugeltki nii. Protsess hõlmab ka selle tagamist, et rakendus töötaks kõrgetasemeliselt, töötaks prognoositavalt ja oleks kasutajale mugav.

See kasutatavus on ju manuaalse testimise keskmes, sest see on peaaegu “automatiseerimata”.

Kui leiate testjuhtumi järgimisel vigu, siis lisage need oma aruandesse, kuid testiga mitteseotud vigade leidmine võib arendajaid segadusse ajada ja viia protsessi eeldatavast positsioonist tahapoole.

 

Manuaalse testi väljundite tüübid

 

Manuaalsest testimisest saad mitut erinevat tüüpi väljundit, millest igaüks annab ainulaadse ülevaate rakenduse toimimisest.

 

Manuaalsete testide väljundite tüübid on järgmised:

 

1. Vigade logi

 

Defektilogi on nimekiri või dokument, mis sisaldab kõiki probleeme, mida tarkvara testimisel esineb. Mida pikem on defektilogi, seda rohkem on probleeme, mis vajavad tarkvaras parandamist.

Need võivad olla kas automaatsed või käsitsi kirjutatud käsitsi testija poolt, kusjuures käsitsi testijad täidavad seda ülesannet programmi kvalitatiivsemates aspektides, kuna automatiseerimisplatvormid ei suuda moodustada arvamusi tarkvara kvaliteedi kohta ja lihtsalt genereerivad mõõdikuid.

 

2. Kvalitatiivsed andmed

 

See viitab suulisele ja kirjalikule tagasisidele, mida manuaalne testija esitab arendusmeeskonnale tavaliselt pärast testimise, näiteks kasutaja vastuvõtutestide läbiviimist.

UAT keskendub selle tagamisele, et keskmine kasutaja naudib tarkvara ja kasutab seda ootuspäraselt, mis tähendab, et võrreldes selliste aspektidega nagu funktsioonide testimine, on keskendumine teistsugune.

Kvalitatiivsed andmed saadakse kas aruteluna arendajaga või pika kirjaliku aruande vormis.

 

3. Veateated

 

Veateated on lühikesed tekstirida, mis näitavad, kas tarkvarapaketis on tekkinud viga ja kui on, siis milline on selle olemus.

Enamik arendajaid kirjutab põhjaliku süsteemi, mis kirjeldab, mis on probleem ja miks see esineb, kasutades veakoode probleemi piiritlemiseks. Kui arendaja märgib üles kõik tarkvaras olevad veateated, teab ta kohe tekkinud probleemi põhjust ja on teadlik võimalikest sammudest selle lahendamiseks.

 

Manuaalsete testide näited

 

On mõned näited manuaalsest testimisest, mida tuleks kaaluda, kui õppida rohkem selle kohta, kuidas läbida manuaalset testimist. Iga neist on konkreetne testimisdistsipliin, mis leiab aset konkreetses arendustsükli punktis, pakkudes arendajatele rohkem teavet ja juhiseid, kuidas nende toodet täiustada.

 

Mõned näited käsitsi tehtavate testide formaatide kohta on järgmised:

 

1. Üksuse testimine

 

Üksuste testimine on protsess, mille käigus veendutakse, et iga üksus tarkvarapaketis töötab ootuspäraselt. Üksus või moodul viitab üksikule funktsioonile, mis kodeeritakse iseseisvalt, enne kui see protsessi lõpus kompileeritakse üheks suuremaks tarkvarapaketiks.

Näiteks võib keegi testida funktsiooni “SORT”, et veenduda, et see korrastab andmeid korralikult, enne kui see integreeritakse laiemasse paketti.

Peamine kasu ühiktestimise lõpuleviimisest on see, et saate aru, et kõik süsteemid töötavad korralikult omaette, kusjuures kõik hilisemates etappides tekkivad probleemid tulenevad sellest, kuidas kõik funktsioonid omavahel integreeruvad.

Nende testide käsitsi täitmine on sama oluline, sest see säästab aega, mis kuluks keeruliste automatiseerimistestide kodeerimisele.

 

2. Lõppkatsetused

 

Lõppkokkuvõtte testimine on kogu rakenduse testimine alates tarkvara esmakordsest avamisest kuni kõigi funktsioonide täitmiseni.

Hea näide läbivast testimisest on mobiilirakendus, mis arvutab, kui palju te teenite makse, mille puhul testija laeb rakenduse alla ja läbib kõik funktsioonid, et saada lõplik arvutus. Testija märgib kõik probleemid, mis tal tekkisid, ja edastab need arendajatele.

Arendajad saavad kasu sellest, et seda testimise vormi viivad läbi peamiselt manuaalsed testijad, sest see annab võimaluse näha, kuidas kõik tarkvara üksused koos töötavad, kusjuures see hilisema etapi testimine tagab, et rakendus töötab korralikult, kui kõik on kokku pandud.

Lõppkokkuvõtte testimine erineb kasutaja vastuvõtutestimisest, kuna lõppkokkuvõtte testimine on peamiselt sisemine protsess, erinevalt kasutaja vastuvõtutestimise protsessist, mis on avalikkusele suunatud.

 

3. Kasutaja vastuvõtu testimine

 

Kasutajate vastuvõtutestimine on tarkvara testimise protsessi viimane etapp, mille käigus veendutakse, et toode sobib toote sihtkliendile. See hõlmab potentsiaalsetele klientidele juurdepääsu võimaldamist rakendusele, et nad saaksid seda kasutada ja anda tagasisidet.

Üks levinumaid näiteid kasutajate heakskiidu testimise kohta tänapäeva tarkvaraarenduses on videomängude alfa- ja beetatestimine, mille käigus mängijad saavad mängu mängida ja teatada kõikidest selles esinevatest probleemidest.

Peamine eelis kasutaja vastuvõtutestide läbiviimisel on see, et saate oma toote kohta välise vaatenurga, mitte ei toetu toote loomisel aktiivselt osalenud inimeste vaatenurgale, mis kõrvaldab igasuguse testimist mõjutava eelarvamuse võimaluse. Käsitsi testimine on vajalik, kuna automatiseeritud süsteem ei suuda täpselt jäljendada klientide tundeid.

 

Manuaalse testimise käigus avastatud veatüübid ja vead, mida automatiseeritud testimine ei tuvasta.

 

Manuaalne testimine leiab igasuguseid vigu, vigu ja probleeme, nagu ka automaatne testimine. Siiski on tarkvaras mõningaid probleeme, mille avastamisel on manuaalne testimine suurepärane, kuid mida automatiseerimine ei suuda tuvastada.

 

Mõned peamised veatüübid ja vead käsitsi testimisel on järgmised:

 

1. Kehv töövoog

 

“Töövoog” viitab teele, mida kasutaja läbib, et jõuda rakenduses konkreetsesse punkti ja viia protsess lõpule. Kuigi mõne töövooga ei pruugi tehniliselt midagi viga olla, võib see siiski olla problemaatiline, kuna see ei pruugi olla arusaadav tavainimesele.

Sellistel juhtudel teavitab manuaalne testija arendajat disainiga seotud probleemidest ja soovitab muudatusi, aidates kasutajatel olla rakendusega mugavam ja tuttavlikum viisil, mida automatiseeritud süsteemid ei mõistaks.

 

2. Graafilised probleemid

 

Veebirakendused töötavad mitmetes seadmetes, kusjuures monitoride resolutsioonid ja suurused varieeruvad pidevalt sõltuvalt sellest, milline telefon, tahvelarvuti või ekraan on kasutajale kättesaadav.

Halvasti optimeeritud rakenduses võib see põhjustada, et varad venivad ja näevad vähemkasutatavates seadmetes halvemini välja, kusjuures automatiseerimisvahendid lihtsalt järgivad menüüd ja ei märka seda.

Erinevate seadmete rakendamisel võivad manuaalsed testijad leida graafilisi vigu, mille parandamisel saavad kasutajad parema kogemuse tarkvarapaketi kasutamisel.

 

3. Ebatäpsed lingid

 

Mõned veebisaidid või rakendused on seotud sotsiaalmeedia veebisaitidega nuppude ja sisseehitatud linkide kaudu. Need ei pruugi aga alati õigesse kohta linkida, sest arendusprotsessis on tehtud trükiviga või viga, mida automatiseeritud süsteem ei pruugi leida.

Valesse kohta minevad lingid võivad tekitada segadust ja kahjustada oluliselt säilitamist. Manuaalsed testijad käivad läbi kõik programmi lingid ja tagavad, et need viivad õigesse kohta, aidates lõppkasutajatel jõuda sinna, kuhu nad soovivad, mitte sattuda eksitusse.

 

Üldine käsitsi testimise metoodika

 

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Mõõdikud on lihtsad ja mõõdetavad numbrilised väärtused, mis näitavad midagi pärast testi lõppu. Need kõik on oma olemuselt kvantitatiivsed, mis muudab need arendaja seisukohast kergemini hinnatavaks.

 

Mõned levinumad manuaalse testimise mõõdikud, mida testijad kasutavad, on järgmised:

 

1. Defektid

 

Defektide mõõdik on suhteliselt lihtne ja viitab tarkvarapaketis esinevate vigade või vigade arvule. Defekt on mis tahes juhtum, mille puhul tarkvara ei toimi ootuspäraselt, alates tarkvara funktsionaalsusest kuni graafika toimimiseni. defektide analüüs kui mõõdik on suhteliselt lihtne, kusjuures rohkem defekte on ettevõtte jaoks suurem probleem.

Jälgides, kas vigade arv suureneb või väheneb iteratsioonist iteratsiooni, saate parema ülevaate sellest, kas tarkvara kvaliteet liigub õiges suunas, kui seda jätkuvalt uuendatakse.

 

2. Defektid katsetustunni kohta

 

Defektid testitunni kohta võtab defektide näitaja ja lisab sellele veel mõned üksikasjad, jagades defektide arvu testijate poolt tarkvarale kulutatud tundide arvuga.

Näiteks lihtne viie defektiga veebitööriist, mille käivitamiseks kulub kaks minutit, näeks parem välja kui kümne defektiga, mida kasutate tund aega baasmõõdiku abil.

Selle täiendava arvutuse abil saavad manuaalsed testijad parema ettekujutuse defektitihedusest, mõistes, kui tihti kasutaja tõenäoliselt defektiga kokku puutub ja kas see mõjutab tõsiselt tema aega rakendusega.

Defektide ja rakenduse suuruse tasakaalustamine on alati kasulik probleemide kontekstualiseerimiseks.

 

3. Läbiviidud testjuhtumite protsent

 

Mõned testjuhtumid toimuvad lihtsa läbimise ja läbikukkumise põhimõttel ning see mõõdik annab protsendi läbitud testjuhtumitest. Mida suurem on läbitud testjuhtumite protsent, seda paremini toimib rakendus.

Kui võimalik katse kasutada läbitud testjuhtumi protsenti funktsioonide kaupa, mitte kogu rakendust uurides. See annab üksikasjalikumat teavet selle kohta, mis töötab ja mis mitte, aidates arendajatel teha muudatusi seal, kus need on vajalikud, selle asemel, et viia lõpule täiendav uurimine, et näha, kus täpselt probleem on. Mida kiiremini leiate probleemi põhjuse, seda parem.

 

7 viga ja lõksu manuaalsete testide rakendamisel

 

Tarkvara testimise valdkonnas on mitmeid levinud vigu, millest igaüks võib viia vigade leidmata jätmiseni ja testimise oodatust pikemaajalise ja kallima kuluga testimiseni.

 

Mõned peamised vead ja lõksud, mida tuleb jälgida ja vältida manuaalse testimise rakendamisel oma töös, on järgmised:

 

1. Vea parandamine ise

 

Arendusprotsessi mõnes etapis on arendaja isik, kes vastutab nii koodi testimise kui ka probleemide lahendamise eest. See võib viia selleni, et nad püüavad ise tarkvaraprobleeme lahendada, hoolimata sellest, et nad ei pruugi probleemi põhjusest täielikult aru saada.

Võimaluse korral püüdke tagada, et testija ja lahenduse kodeerija vahel oleks selge vahe. Sellise eristamise abil vähendate võimalust, et keskendute liiga palju konkreetse leitud vea parandamisele, selle asemel, et arvestada ülejäänud tarkvara.

Jagage tööd alati laiali, kui on võimalik, et saada mingi teema kohta laiemalt eksperditeadmisi.

 

2. Testidega kiirustamine

 

Mõnel tarkvaral on väga lühikesed avaldamise tähtajad, mis võib panna testijad keskenduma testide kiiremale läbimisele, et jõuda tähtajani. See on tõsine viga, sest sellega kaasneb oht, et olulised vead pääsevad läbi. Manuaalne testimine võib seda probleemi veelgi süvendada, sest inimesed tunnevad survet ja kiirustavad aktiivselt.

Proovige võtta testjuhtumite täitmisel võimalikult palju aega, käies iga sammu hoolikalt läbi ja märkides andmeid põhjalikumalt üles. Isegi kui te peate väljaandmist pisut edasi lükkama, on parem saata valmis toode kui selline, mis ei meeldi kasutajatele kehvade standardite tõttu.

 

3. Kehv kommunikatsioon

 

Meeskonnasisese suhtluse tähtsus on igas tarkvaraarendusprojektis ülimalt oluline, kusjuures inimesed saavad oma kolleegidelt võimalikult palju teavet ja kasutavad seda teavet toote täiustamiseks. See kehtib nii osakondade vahelise kui ka ühe osakonna sisese pideva vestluse kohta.

Mida tõhusamalt suhtleb QA meeskond arendajatega, seda paremad on nende juhised uuenduste loomisel, kusjuures kõik saavad ühiselt kasu kõige kõrgema taseme toote väljastamisest.

Käsitsi testimine võimaldab paremat suhtlemist, kuna testija saab kogemusest täielikku ülevaadet, mis annab rohkem selgust ja üksikasju.

 

4. Katsetamine ilma ettevalmistuseta

 

Ettevalmistus kasvatab täiuslikkust ja see kehtib kogu tarkvara testimise valdkonnas. Manuaalse testimise puhul tähendab see, et lisaks lühikese kokkuvõtte õppimisele tuleb võtta aega tarkvara mõistmiseks ja luua testjuhtumid, mis esitavad asjakohaseid väljakutseid kõigile nendele eesmärkidele.

Kui te võtate aega, tähendab see, et teie testjuhtumid vastavad teie kui arendaja vajadustele ja te leiate palju tõenäolisemalt kõik süsteemi kõige olulisemad vead. See aitab ka testijatel testjuhtumeid selgemalt läbi lugeda ja neid täpsemalt täita.

 

5. Oma instinktide eiramine

 

Kui ettevõte alustab käsitsi testimist, teeb ta seda mitmel põhjusel, sealhulgas seetõttu, et ta soovib inimtesteri kohanemisvõimet ja instinkte. Tarkvara testimisel võite märgata, et midagi tundub kummaline, kuigi see ei ole aktiivselt testjuhtumi osa, mis sunnib teid mitte tegema mingeid muudatusi või uurima edasi. See on viga.

Lase alati oma uudishimu rahuldada ja kuula, mida su vaist ütleb, sest see aitab leida probleeme, mida automatiseeritud testjuhtum ei suuda. Manuaalsed testijad valitakse nende intelligentsuse ja asjatundlikkuse tõttu, seega nende omaduste kasutamine on testi potentsiaali maksimaalne ärakasutamine.

 

6. Hirm vigu kartes

 

Igaüks teeb vigu, olenemata sellest, millise tööga te tegelete. Siiski on parem seda tunnistada, kui minna protsessi, kartes, et võite teha vea. See tekitab teile rohkem stressi ja põhjustab veelgi tõenäolisemalt probleeme teie testimise tulemuslikkusega. Automatiseerimisel seda probleemi ei ole, kusjuures käsitsi testijad on surve suhtes tundlikumad.

Lähenege oma ülesannetele loomulikult ja kui teete vea, püüdke see võimalikult kiiresti parandada. Tarkvara testimine on etapp, kus te avastate ja parandate probleemid, ning juhuslik testimisprobleem ei hävita tarkvara lõppkasutaja jaoks, kui te selle parandate.

 

7. Pauside tegemata jätmine

 

Käsitsi testimine nõuab suurt tähelepanu iga üksiku testi üksikasjadele, mis võib testija jaoks olla väsitav. Sellest hoolimata keskenduvad mõned testijad ja ettevõtted sellele, et testijad jätkaksid tööd kogu päeva jooksul ilma väsimuse või keskendumishäirete tõttu tehtavate lisapausideta.

See on oluline viga. Tagage testimise töötajatele puhkepausid kogu päeva jooksul, sest see vähendab probleemide tekkimise võimalust ja hoiab testimise võimalikult täpsena. Kui olete ise testija, püüdke koos juhtkonnaga aktiivselt hoolitseda enda ja oma lähedaste vaimse tervise eest.

 

Parimad manuaalsed testimisvahendid

 

Kui te lõpetate käsitsi testimise, ei pea te iga tööosa üksi lõpule viima. Mõnel juhul võib tööriista kasutamine olla ideaalne vahend testimise haldamiseks ja protsessi võimalikult sujuvaks muutmiseks. Kui te olete testija, kes mõtleb, kuidas oma standardeid parandada, võiks tööriistade vaatamine olla ideaalne algus.

 

5 parimat tasuta manuaalset testimistööriista

 

Kui alustate tarkvara testimise mis tahes uue tööriistaga, siis soovite veenduda, et saate oma investeeringu eest head tulu. See viitab ajale, mida te investeerite tarkvarasse, ja rahasummale, mida te kulutate litsentsi hankimiseks.

Tasuta manuaalsete testimisvahenditega on raha eest väärtuse saamine palju lihtsam ja te ei kannata ostja kahetsust, kui see ei toimi.

 

Mõned parimad tasuta käsitsi testimise tööriistad, mis on kvaliteedi tagamise meeskondadele kättesaadavad, on järgmised:

 

1. JIRA

 

JIRA on tarkvara testimise dokumentatsioonivahend, mis võimaldab arendajatel luua pileteid mis tahes vigade, probleemide või paranduste kohta, mis vajavad tuge. See platvorm on varustatud ka prioriteetide seadmise vahenditega, nii et arendusmeeskond saab oma programmi täiustamisel kõigepealt sorteerida kõige olulisemad probleemid.

 

2. LoadRunner

 

LoadRunner ühildub mitmete arendusvahenditega ja aitab jõudluse testimisel mitmesugustes seadistustes, genereerides jõudlustesti andmeid üksikasjalikult. Tööriist aitab ka kategoriseerida mõned peamised jõudlusprobleemide põhjused, mida arendaja soovib tõhususe suurendamiseks kasutada.

 

3. SonarQube

 

Toetab mitmesuguseid programmeerimiskeeli läbi manuaalse testimise töö, jälgides mõõtmisi aja jooksul, et vähendada käsitsi testijate enda poolt täidetava aruandluse hulka. Väga kohandatav ja tõhusalt integreeritav mitmete suuremate kolmandate osapoolte rakendustega.

 

4. Trac

 

Pythonis välja töötatud Trac on projektijuhtimise vahend, mis pakub teile oma vaateajalugu, koodi ja kõiki muudatusi, nii et näete testide vahel tehtud muudatusi. Ka vigade kõrvaldamine Traci kaudu kasutab piletihaldussüsteemi, mis lihtsustab probleemi leidmist ja selle parandamist kasutaja jaoks.

 

5. NUnit

 

JUnitil põhinev NUnit on täielikult avatud lähtekoodiga tööriist, mis toetab andmesidekeskseid teste ja integreerub tõhusalt mitmete platvormidega. Saate juurdepääsu kvantitatiivsetele andmetele ka pärast käsitsi tehtud testide lõpetamist, mis annab arendajatele parema ülevaate, et parandada võimalikke probleeme.

 

5 parimat tasuta automatiseeritud testimise tööriista

 

Kuigi manuaalsel testimisel on palju eeliseid, onautomatiseerimise rakendamine teie testimisprotsessides mõnikord ideaalne võimalus.

See aitab teil kõrvaldada mõned puudused, mis kaasnevad ainult käsitsi testimisega, saades samas hea ülevaate tarkvarast. Automatiseerimine nõuab alustamiseks mõningaid vahendeid ja paljud arendajad eelistavad kasutada tasuta vahendeid, kui nad alustavad tööd ja saavad platvormiga hakkama.

 

Mõned parimad saadaval olevad tasuta automatiseerimise testimisvahendid on järgmised:

 

1. ZAPTEST TASUTA VÄLJAANNE

 

ZAPTEST Free Edition on loodud selleks, et aidata testijatel integreerida automatiseerimine oma töösse, keskendudes platvormideülesusele ja sellele, et kasutajad rakendaksid automatiseerimist nii, et see toetaks korralikult käsitsi testimist. Mis tahes ülesande automatiseerimine on peamine tõmbenumber, kusjuures kõik tarkvara aspektid on automatiseeritavad ZAPTESTi tasuta versiooni kaudu.

 

2. Appium

 

Avatud lähtekoodiga testide automatiseerimise raamistik, mis keskendub konkreetselt veebipoodides töötavate rakenduste mobiilseadmete automatiseerimisele. Appium töötab erinevate APIde ja operatsioonisüsteemidega, sealhulgas iOS, Windows, Mobile, Web ja Android.

 

3. Kataloni platvorm

 

Katalon on koodivaba lahendus, mis aitab testijatel, kellel puudub kogemus kodeerimises, saavutada paremat automatiseeritud testimistööd. Sellel platvormil on kauplus koos mitmesuguste laiendustega, kuid see tähendab, et selleks, et testimistarkvara maksimaalselt ära kasutada, peate tõenäoliselt panustama palju aega ja potentsiaalselt ka raha selle kohandamisse vastavalt oma vajadustele.

 

4. Robotium

 

Avatud lähtekoodiga tööriist, mis on spetsiaalselt suunatud Androidi testimisele, võimaldades samal ajal kasutaja aktsepteerimist ja halli kasti testimist. Kuigi see rakendus töötab kõrgetasemeliselt, on kasutajatele mõningaid riske, sest platvormideülesed rakendused vajavad siiski testimist kõigil teistel platvormidel.

 

5. Loadster

 

Loadster on tööriist, mis on mõeldud ettevõtetele, kes töötavad suure kasutajaskonnaga rakendustega. Selle tööriista kasutamine aitab arendajatel valmistuda suuremateks liiklussageduse tippudeks ja saavutada optimaalne jõudlus isegi siis, kui ettevõtte serveritele avaldatakse märkimisväärset survet. Lisaks käsitsi testimise abistamisele saab Loadster automatiseerida mõningaid testija ülesandeid, näiteks koormuse taastamist.

 

Kokkuvõte

 

Kokkuvõtteks võib öelda, et manuaalne testimine on iga organisatsiooni jaoks kasulik. Testijad saavad avastada muidu nähtamatuid probleeme ja anda üksikasjalikku tagasisidet rakenduse kohta, mida automaatika lihtsalt ei suuda.

Kuigi manuaalsel testimisel on mõningaid puudusi, kasutavad arukad ettevõtted üha enam manuaalsete ja automatiseeritud testide hübriidsüsteemi, mis aitab arvestada mõlema puudusi, kasutades samal ajal mõlema eeliseid.

Manuaalne testimine on parema tarkvaraarenduse selgroog ja selle õige kasutamine võib teie tulemuse suhtes suurt vahet teha.

 

KKK ja ressursid

 

Manuaalne testimine võib olla keeruline teema, seega on arusaadav, et teil võib olla veel küsimusi selle kohta, kuidas see toimib. Tutvu mõne sageli esitatud küsimusega manuaalse testimise kohta koos mõningate ressurssidega, millest saad kasu, kui õpid aja jooksul paremaks manuaalseks testijaks saama.

 

1. Parimad kursused käsitsi testimise automatiseerimise kohta

 

– “Testautomaatika alused” – Udemy

– “Testautomaatika koolituskursused” – NobleProg

– “Käsitsi testimise koolitus – Ühendkuningriik” – The Knowledge Academy

– “Käsitsi ja automatiseeritud testimine” – IT Talent Hub

 

2. Millised on 5 kõige olulisemat intervjuuküsimust manuaalse testimise kohta?

 

– “Kas teil on kogemusi käsitsi testimisega?” – Tehakse kindlaks, kas kandidaadil on palju kogemusi testimiskeskkonnas töötamisel.

– “Mis vahe on manuaalsel testimisel ja testide automatiseerimisel?” – Tehakse kindlaks, kas kandidaadil on põhilised tehnilised teadmised testimisprotsessidest.

– “Kuidas olete ületanud probleeme tarkvara testimise keskkonnas?” – Hinnatakse kandidaadi probleemide lahendamise oskust käsitsi testimise valdkonnas.

– “Milline on ideaalne vahend käsitsi testimise toetamiseks?” – Kujuneb parem ettekujutus töövoogudest, mida kandidaat kasutab, ja sellest, kas see sobib ettevõttele.

– “Kas teil on mugav töötada meeskonnas?” – Andke intervjueerijale teada, kas kandidaat on võimeline töötama suuremas rühmas.

 

3. Parimad Youtube’i õpetused käsitsi testimise kohta

 

– “Käsitsi testimine (täielik kursus)” – SDET- QA Automation Techie

– “SOFTWARE TESTING TUTORIAL – Meisterda tarkvara testimine ja murra töö testimises” – Software Testing Mentor

– “Mis on manuaalne testimine? | Manuaalse testimise õpetus algajatele | Edureka” – edureka!

– “Käsitsi testimise (funktsionaalne) kontseptsioonid” – Naveen AutomationLabs

– “Manuaalse testimise õpetused” – Software Testing Academy

 

4. Kuidas hooldada manuaalseid teste?

 

On mõned asjad, mida saate teha käsitsi tehtavate testide hooldamiseks, millest esimene on testijate eest hoolitsemine. Pannes heaolu testimisprotsessi keskmesse, tagate, et kõik on võimelised pöörama tähelepanu ja saavutama oma parima tulemuse.

Lisaks sellele keskenduge sellele, et teil oleksid head tugistruktuurid. See tähendab, et juhid peavad tagama, et testimine on järjepidev ja annab võimaluse korral täpseid tulemusi.

Ei ole mingit ranget mehaanilist või automatiseeritud hooldust iseenesest, kuid inimeste eest hoolitsemine on iseenesest üks testimise hooldamise vorm.

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post

Virtual Expert

ZAPTEST

ZAPTEST Logo