Tarkvaratesteri töö sissejuhatus
Mis on esimene asi, mis teile pähe tuleb, kui mõelda tarkvara testimise tööle? Mittekodeeriv teos? Või amet, mis on väga lihtne, kuna see annab teile võimaluse teiste töös vigu leida (vigade leidmine, kui teistes on meie kõigi jaoks kõige lihtsam ülesanne)? Või peate seda kutsealaks, mis tegeleb toote õigsuse kontrollimisega? Kõik need mõtted on õiged ja on tarkvaratesti töö igapäevane tegevus. Kuid tarkvara testimine ei piirdu ainult nende tegevustega.
Rakenduse mõistmine
Rakendus võib olla mis tahes domeenist - tervishoiuteenused, kindlustus, rahandus jne. Rakenduse domeeni õppimine on iga tarkvara töö jaoks väga oluline, et rakenduse testimisel avada uksed erinevate nurkade alt ja erinevatest vaatenurkadest mõtlemiseks. Selle peamine eeldus on alati ilmsete ja mitte nii ilmsete rakendusteede paljastamine ja kinnitamine. Rakenduse põhjalike teadmiste omamine aitab toodet tõhusalt valideerida, samal ajal võib testija saada eeliseks projektis, kus teda peetakse toote käitumisega seotud esmaseks teadmiste allikaks.
Kuigi domeeni ja funktsionaalsuse õppimine on pidev protsess, on teise oluliseks teguriks testimisprotsessi tundmine.
Testimisprotsess
Testimisprotsess võib erinevatel ettevõtetel ja isegi projektidel erineda. Täna on meil mitmesuguseid tarkvaraarenduse mudeleid, näiteks V-mudel, prototüüpimismudel või hoopis teine metoodika, näiteks tarkvaraarenduse Agile-lähenemine. Arendusmudeli muutumisega varieerub ka järgitav testimisviis. V-mudelis töötamisel on selgelt määratletud protsessid, samal ajal kui paindlikul metoodikal töötamine peaks eeldatavasti testima pidevalt muutuvates tingimustes.
Töö ei ole veel sujuv, omades vastuvõetavaid domeeniteadmisi ja mõistmist testimisprotsessist, järgmine väljakutse, mis eluga kaasneb, on mitmesuguste tööriistade õppimine.
Tööriistad
Tööriistad tähendavad testihaldusriistu, defektide logimise tööriistu, andmebaasihaldusriistu ja nii edasi.
Erinevate puudustega logimistarkvarade, millel on omadused ja tööriistad, mõni avatud lähtekoodiga ja mõni litsentsitud, puhul on alati eeliseks teadmine mitme tööriista kohta. See aitab tal hõlpsalt erinevaid tööriistu järgides projekte või meeskondi üle viia. Piisavate teadmistega domeenist, protsessist ja tööriistadest on Tarkvara Testeri töö elus rohkem, mis muudab tema tööpäevad keeruliseks ja põnevaks. Meeskondadevaheline koostöö on iga projekti õnnestumise üks olulisi tegureid ja tõhusa koostöö korral on suhtlemisel väga oluline roll.
Soovitatavad kursused
- J2EE põhjalik kursus
- R-programmeerimise veebipõhine koolitus
- Minge programmeerimiskursusele
- Veebipõhine sertifitseerimiskoolitus Haskelli programmis
Suhtlus
Suhtlus mängib tarkvara kvaliteedi seisukohalt väga olulist rolli, kuna tarkvara arendamise algfaasidest alates on testimisrühma liikmed kaasatud (kui parimat tava) nõuete arutamisse ning ärianalüütikute küsitlemisele juhul, kui nõude osas on küsimusi või lünki. Tõhusa suhtlemisoskusega töötaja suudab riske tõhusalt kommunikeerida, saab arendusmeeskonnaga tõhusalt suhelda ja testi tulemuste ning katsearuannete tõhusat edastamist.
Tarkvaratestri töö kavandamine
Nagu nimigi ütleb, on testi kavandamine etapp, kus testimiseks valmistatakse ette. Tsteriks ettevalmistamine hõlmab erinevaid toiminguid, mida tster teeb, et tõhusalt rakendust rakendada. See aitab rakendust valideerida ja rakenduse puudusi tõhusalt avastada. Planeerimise alustamiseks läbib test ootuste mõistmiseks vajalikud nõuded.
1. Nõuded
Testimismeeskonnale võiks esitada nõudeid kaadrite, süžeeskeemide, exceli lehtede kujul. Kõigi nende dokumentide eesmärk on esitada kliendi nõudmised tõhusal ja hõlpsasti mõistetaval viisil. Raamraami dokument pole midagi muud kui dokument, mis võib olla PowerPointi esitluse vormis, mis kujutab kliendi nõudeid. Samadel joontel kujutavad süžeeskeemid tavaliselt ekraanide vajalikku välimust / kujundust. Tänapäeval on turul saadaval mitmesuguseid tööriistu, mida saab kasutada vajalike dokumentide ettevalmistamiseks. Nõutavate dokumentide loomine on ärianalüütiku peamine kohustus. Eeldatakse, et maitsed mõistavad nõudeid põhjalikult. Et nii testijad kui ka arendajad saaksid nõuetest õigesti aru, hoiavad ärianalüütikud foorumit avatud, et kõik võiksid esitada ja saada küsimustele vastused mis tahes nõude kohta. Avatud küsimuste ja päringute arutamise ja edastamise platvorm on projektiti erinev. See võib olla e-kirjade ahel või konverentskõne või isegi jagatud draivi hoidla, mida hooldatakse kõigi avatud küsimuste ja nende vastuste jälgimiseks, nagu ärianalüütik pakub.
Selge suhtlus ja suhtluse rekord mängivad tõestuseks väga olulist rolli. Nõude väike eeldus võib mõnikord põhjustada toote olulisi puudusi. Igas etapis soovitatakse tarkvara testijal omadusi hoida side puhtana. Tarkvaratester Tööalane suhtlus võiks toimuda ärianalüütikutega või isegi meeskonnas. Selge suhtlus aitab eeldustest eemale hoida planeerimise ja teostamise ajal. Samal ajal on soovitatav omada suhtlusprotokolli (eelistatavalt e-posti teel suhtlemine). Nõuete päringute kohta kirjaliku teatise omamine aitab testi täitmise hilisematel etappidel, kus funktsionaalsus ei pruugi olla arenenud, nagu kinnitatakse salvestatud teatises.
2. stsenaarium
Kui nõuded on arusaadavad, hakkab testija stsenaariume dokumenteerima testistsenaariumi dokumendis. Stsenaarium, nagu nimigi ütleb, on funktsionaalsuse voog, mida kasutaja järgib ülesande täitmiseks.
Näited stsenaariumidest -
- Kasutajal peaks olema võimalik edukalt sisse logida.
- Kasutajal peaks olema võimalik süsteemis pileteid broneerida.
- Kasutajal peaks olema võimalik süsteemis pileteid tühistada.
- Kasutajal peaks olema võimalik profiili üksikasju vaadata / värskendada.
Need on loogilised ülesanded, mida kasutaja süsteemis täidab. Need rühmitatud loogilised ülesanded aitavad ennustajatel teha meelde kõiki võimalikke stsenaariume, mida kasutajalt oodatakse. Need stsenaariumid dokumenteeritakse tavaliselt Exceli lehtedel või mõnikord mõnda tööriista kasutades. Vanasõna õnnestub kõigi selliste stsenaariumide väljavõtmiseks nõudedokumentidest. Selliseid stsenaariume sisaldavat dokumenti nimetatakse testistsenaariumi dokumendiks (või kuskil kõrgetasemelise stsenaariumi dokumendiks). See dokument on sisenddokument katsejuhtumite koostamiseks.
3. Juhtum
Sel juhul on tegemist tarkvara Testeri töötsenaariumi üksikasjalikuma versiooniga, kus stsenaarium on jaotatud üksikasjalikumaks sammuks, mida kasutaja rakenduse kasutamise ajal tegelikult täidab. Ülalnimetatud stsenaariumidel põhinev lihtne näide on:
Stsenaarium - Kasutajal peaks olema võimalik edukalt sisse logida.
Testijuhtumid:
- Kontrollige, kas kasutaja saab sisestada õige kasutajanime.
- Kontrollige, kas kasutaja saab parooli sisestada.
- Pärast õige kasutajanime ja parooli sisestamist nupul Logi sisse klõpsamisega kinnitage, et kasutaja saab edukalt sisse logida.
Selliste juhtumite loend võib hõlmata iga välja valideerimiskontrolli, negatiivsete stsenaariumide kontrollimist jne.
Allpool on toodud mõned täiendavad näited nende juhtumite kohta -
- Kui kasutajat pole sisestatud, veenduge, et süsteem sisestaks vastava vea.
- Kui parool pole sisestatud, kontrollige seda, sisestatakse süsteemis asjakohane tõrge.
- Kui kasutajanimi ja parool on sisestamata, kontrollige süsteemi viga.
- Kontrollige, kas vale parooli sisestamisel edastab süsteem vastava tõrketeate.
- Kontrollige, kas vale kasutajanime sisestamisel edastab süsteem asjakohase veateate.
4. Nõude jälgitavuse maatriks (RTM)
Nõude jälgitavuse maatriks, nagu nimigi viitab, aitab tõestada, et kontrollitakse ja integreeritakse ettevõtte pakutavate nõuete ulatus testimisdokumentidesse, näiteks stsenaariumidesse ja testjuhtumitesse.
Parima tava kohaselt on see eraldi dokument, mis näitab nõude numbri kaardistamist stsenaariumide / juhtumitega, mis seda nõuet sisaldavad.
Seda dokumenti ei pruugi kasutada igasugused projektid, kuid selle kasutamisel aitab see tugevalt üles leida nõudmistele vastavat kõrgetasemelist stsenaariumi. See näitab katvust ja seda saab kasutada vähemalt ühe juhtumi olemasolu kontrollimiseks iga nõude osas. RTM-i dokumendi loomist ja haldamist peetakse parimaks tavaks, kuid mitte igasugused projektid (näiteks Agile) ei kasuta tarkvara tõestust töödokumendiks. Kui nõuded muutuvad väga sageli, võib selle dokumendi säilitamine olla üle kuulatud. Selle ülekulude vältimiseks ja samal ajal võimalus nõuete jälgimiseks kaasata mõned projektid jälgitavuse osa Tarkvara Testeri tööjuhtumisse või selle stsenaariumi dokumenti.
Oluline aspekt on võimalus leida stsenaariumid / juhtumid vastavalt nõudmistele ja vastupidi. Hästi dokumenteeritud nõuded muudavad Proveri ülesande nende dokumentide loomise ja hooldamise lihtsamaks. Mitmetähenduslikud nõudmised, pidevalt muutuvad nõuded muudavad vanade elu keerukamaks ja võivad viia vastuoluliste väljastatavate dokumentide saamiseni, mille tulemuseks on valideerimise kaotamine ja seega lõpptoote defekt.
Senine tester oli teekonna kavandamiseks ja katseteks ettevalmistamiseks. Kuna sõja ettevalmistamine on osa sõjast, kehtib ka siin. Mida ladusamad need dokumendid on loodud, seda on proveril lihtsam funktsionaalsust kinnitada ja peaaegu kõik puudused avastada. Testeri teekonna järgmine etapp on teostus.
Tarkvara testri täitmine töötab
Selles etapis võetakse kasutusele kõik ülalnimetatud dokumendid. Stsenaariumi loomiseks kasutati nõudeid, selle loomiseks kasutati stsenaariumi Juhtumid. see juhtumidokument on siin iseseisvaks dokumendiks rakenduse valideerimise alustamiseks. Prover alustab rakenduse valideerimist, käivitades juhudokumendi toimingud. Ühte stsenaariumi valideerimiseks võib kasutada mitut nimetatud juhtumit või isegi üks katsejuhtum võib vastata ühele stsenaariumile. Kõik sõltub stsenaariumide keerukusest või mõnikord testimeeskonnas järgitavast standardist. Seega võib üks katsejuhtumi dokument sisaldada 20–50 testjuhtumit või 100–120 testjuhtumit. Need numbrid on mõeldud ainult selgitamiseks, need võivad projektides erineda. Selle etapi tulemuseks on testidefektid. Selles faasis tõstatatud kehtivate defektide arv annab hea ettekujutuse rakenduse stabiilsusest, katsetamise kvaliteedist, ehituse kvaliteedist ja paljudest muudest tootele otseselt mõjuvatest teguritest. See etapp on kõige olulisem, kuna testija õnnestub katta kõiki testjuhtumeid (valideerides peaaegu kõik nõutavad kasutajarajad) ja samal ajal tõsta nii palju kehtivaid defekte kui võimalik. Selles testimisfaasis tuleb tegutseda kogu ettevõtte jaoks ettevalmistamise, suhtlemisoskuste ja päringutega.
Tarkvara testri defektid töötavad
Selle juhtumi täitmise ajal tõstetakse defektiks mis tahes käitumine, mis ei ole võrdne oodatava tulemusega. Igal katsejuhtumil on kirjeldus, eeldatav tulemus ja veerg tegeliku tulemuse kohta. Ehkki nendes tarkvara Testeri töö kavandamise dokumentides on kirjeldus ja oodatavad tulemused ning tegelike tulemuste tühi veerg. Testijuhtumite täitmise ajal peaks testija täitma tegeliku tulemuse veeru. Samal ajal, kui tegelik ei võrdu loodetud tulemusega, logitakse viga. Defekti logimine ei tähenda lihtsalt arendaja teavitamist probleemist. See on jällegi ametlik protsess, mida tavaliselt tehakse tööriista abil. Praegu on turul mitmesuguseid tööriistu, mõned avatud lähtekoodiga ja mõned litsentsitud. Igal puuduste logimise tööriistal on järgmised väljad -
- Projekti / väljalaske nimi
- Defektide kokkuvõte
- Defekti üksikasjalik kirjeldus
- Defekti raskusaste
- Defekti prioriteet
- Faas leiti defekt
- Määratud
- Lisad
Nagu näeme, on kõigi nende väljade eesmärk leida ametlik protsess, mis võimaldaks arutada täpsustatud üksikasju. See aitab arendajatel oma keskkonnas esinevat puudust reprodutseerida ja seda parandada. Allpool on kõigi nende väljade lühikirjeldus -
- Projekti / väljalase nimi - selle väljaande nimi, kus defekt leiti, tavaliselt on projektil mitu väljalaset ja samal projektil võib olla mitu alamprojekti. See väli aitab tõstatada konkreetse väljalaske probleemi.
- Defektide kokkuvõte - leitud defekti lühike üherealine kirjeldus.
- Defekti üksikasjalik kirjeldus - see on defekti üksikasjalik kirjeldus. See peaks sisaldama üksikasju, nagu keskkond, kus defekt leiti, ja kasutatud katseandmeid, tegelikke tulemusi, mis eeldasid tulemust, ja mis tahes lisateavet, mis lisab sidusrühmadele väärtuslikumat teavet defekt.
- Defekti tõsidus - see näitab, kui tõsine defekt on. Tavaliselt on selle väärtused sarnased kriitilise, kõrge, keskmise, madala või numbriliste väärtustega, näiteks 4, 3, 2, 1.
- Defekti prioriteet - see näitab, kui kiire on defekti kõrvaldamine.
- Faas, milles defekt leiti - Kuna defekte saab registreerida paljudes etappides, ühiku testimise faas, SIT (süsteemi integreerimise testimine), UAT (kasutaja aktsepteerimise testimine) või isegi tootmisetapp.
- Määratud - arendaja või arendusjuhi nimi.
- Manused - see andis testijale võimaluse manustada ekraanipilt ekraanilt, kus probleem ilmnes.
Testi täitmise ja puuduste logimine on etapp, kus testijal võib olla palju väljakutseid. Mõned neist suhtlevad arendajatega tõhusalt. Kas võime väita, et kas puuduse registreerimine kogu vajaliku teabega ei ole arendajatele defekti mõistmiseks piisav?
See on nii ja mõnel juhul nõuab see täiendavat selgitust / arutelu arendajatega. On juhtumeid, kus testija kohtub ootamatu käitumisega, milles ta ei pruugi olla kindel, kas tegemist on puudusega. Selliste tingimustega seisavad tavaliselt silmitsi vanad vanemad, kes on meeskonnas uued, kellel on piiratud teadmised domeenist või kellel on ebaselged nõuded. Noh, testerit ei tule siin süüdistada, kui on lühikesed tähtajad ja pidevalt muutuvad nõuded ning enamikul juhtudest õpivad proverd domeeni tundma õppimise ajal katsejuhtumeid kavandades ja teostades. Nagu näeme, ei ole testija tee nii lihtne, kui tajutakse. See nõuab pidevalt õppimist, head suhtlemisoskust, häid koostööoskusi ja innukust kohandada end tingimustes, kus kasutatavates valdkondades, tööriistades ja protsessides on muudatusi. Kui me rääkisime manuaalsete testijate teekonnast, siis üldine protsess kehtib ka automatiseerimistestide kohta. Teisest küljest on automatiseerimisel protsessis olulisi muudatusi, kuna testimise ja planeerimise ulatus ning teostus erinevad oluliselt.
Arvestades vanasõidu teekonda, nagu eespool arutatud, kas me võime ikkagi öelda, et tarkvara testri omaduste töö on lihtsam kui arendaja oma?
Võib öelda, et lisaks testija v / s-i arendaja rollide võrdlemisele on kasulikum arutleda selle üle, kuidas kahe koostöö tulemus võib olla toote tervikuna suur edu. Mõnikord unustame, et testija ülesanne on leida rakenduses probleeme ja mitte osutada arendajate vigadele. Kui unustame oma töö idee, viib see mõnikord tarbetu aruteluni. Siiski on täheldatud, et on võrdselt häid testimis-, arendusmeeskondi, kus kõik saavad aru, et lõppeesmärk on muuta rakendus ootuspäraselt toimivaks. Lootkem, et kõik vaatavad testimistöö positiivset külge kui rolli, mis aitab toodet puhastada, ja mitte seda, milles lihtsalt leitakse vigu!
Soovitatavad artiklid
See on olnud juhend ilmselgete ja mitte nii ilmselgete rakendusteede paljastamiseks ja valideerimiseks, mis on tarkvara testri tööst alati peamine. Need on järgmised tarkvara testerite tööga seotud välised lingid.
- Defektide elutsükkel tarkvara testimisel
- 6 kõige hämmastavamat tarkvaratestimise intervjuu küsimust
- Karjäär tarkvara testimisel