Nesvarbu, ar programuojate programinę įrangą savo įmonės nariams, ar plačiam klientų ratui, tinkama rankinio, automatinio ar hibridinio testavimo praktika ir sistemos padeda užtikrinti nuoseklią programinės įrangos kokybę, geresnę reputaciją ir efektyvumą.
Priklausomai nuo įmonės, kurioje dirbate, daug testavimo atliekama rankiniu būdu.
Sužinokite daugiau apie tai, kas yra rankinis testavimas, ką įmonės testuoja rankiniu testavimu ir daug kitų svarbių faktų apie programinės įrangos testavimo procesus.
Kas yra rankinis testavimas?
Rankinis testavimas – tai toks programinės įrangos testavimo būdas, kai testuotojas testavimo atvejį atlieka rankiniu būdu, nenaudodamas jokių automatizuotų priemonių.
Įmonės naudoja rankinį testavimą kaip metodą programinės įrangos klaidoms ar problemoms nustatyti. Nors kai kas tai apibūdina kaip paprastą ar primityvią testavimo formą, galiausiai nustatomas programos funkcionalumas nenaudojant trečiųjų šalių testavimo įrankių.
Visoms programinės įrangos testavimo formoms būdingi tam tikri rankinio testavimo aspektai, nes kai kurių programos funkcijų tiesiog neįmanoma išbandyti be rankinio įsikišimo.
1. Kada reikia atlikti rankinį testavimą?
Kūrėjai rankinį testavimą atlieka keliais etapais, iš kurių pirmasis yra pagrindinio funkcionalumo kūrimo etapas.
Kai kuriama pagrindinė programinės įrangos funkcija, programinės įrangos kūrėjai tikrina, ar kiekviena programos dalis veikia rankiniu būdu, nes taip greičiau nei kurti gana paprastų kodo dalių testavimo atvejus.
Rankinis testavimas taip pat paplitęs vėlesniuose kūrimo etapuose, kai sukuriama programos vartotojo sąsaja. Naudotojo sąsajos testavimo metu tikrinama, kaip realus naudotojas reaguoja į tai, kaip sukurti meniu ir kaip veikia sistema.
Kadangi tai susiję su daugybe kokybinių duomenų ir asmenine nuomone, o ne vien kiekybiniais rodikliais, rankinis testavimas yra idealus variantas, padedantis geriau suprasti produktą.
2. Kai nereikia atlikti rankinio testavimo
Yra keli atvejai, kai rankinis testavimas pareikalautų daug daugiau laiko ir pastangų, nei būtina, pirmiausia – duomenų bazių testavimas.
Duomenų bazėse apdorojami didžiuliai duomenų kiekiai, o jų įvedimas rankiniu būdu užimtų daug laiko ir būtų neefektyvus organizacijai.
Tokiais atvejais idealiai tinka naudoti automatizuotas sistemas, nes jos gali apdoroti didelius duomenų paketus per ribotą laiką.
Rankinis testavimas taip pat mažiau naudingas tokiose srityse kaip apkrovos testai, kai kūrėjas atlieka bandymus, norėdamas patikrinti, kaip jo programinė įranga susidoroja su didelėmis naudotojų apkrovomis.
Dažnai taip būna internetinių programų ir programų su serveriais, kuriuos reikia nuodugniai įvertinti, atveju. Atliekant rankinius testus vienu metu prie taikomosios programos turi prisijungti daug asmenų, o tai gali lemti dideles darbo sąnaudas paslaugai, kurią automatizuota programinės įrangos testavimo sistema gali atlikti daug pigiau.
3. Kas dalyvauja rankiniame testavime?
Darbuotojai, atliekantys rankinį testavimą, priklauso nuo įmonės, kurioje dirbate, pobūdžio.
Kai kurie žmonės, dalyvaujantys rankinio testavimo procese, be to, kokioje kūrimo komandoje galite rasti šiuos vaidmenis:
– Kūrėjas:
Kūrėjas nuolat dalyvauja šiame procese, testuodamas pagrindines programinės įrangos funkcijas ir atnaujindamas kodą, atsižvelgdamas į QA testuotojų atsiliepimus.
Kūrėjai atlieka daug rankinio testavimo, nes jie yra atsakingi už tai, kad moduliai veiktų pagal aukštus standartus ankstyvaisiais programinės įrangos kūrimo etapais.
– QA testuotojas
Didelėse komandose dirbantys QA testuotojai atlieka tik įmonės testavimą ir užtikrina, kad programa veiktų taip, kaip tikisi klientas.
Kokybės užtikrinimo testuotojas visų pirma yra svarbus kūrimo testavimo, integravimo ir priežiūros etapuose, perimdamas rankinį testavimą iš pačių kūrėjų, kurie testuoja visą diegimo procesą.
– QA vadovas
Didžiausiose kūrimo įmonėse QA vadovai paskirsto testuotojus konkrečioms užduotims ir projekto sritims.
Jie taip pat yra atsakingi už reikalingų atlikti darbų sąrašo sudarymą ir bandymų ataskaitų skaitymą. Tai ypač svarbu atliekant rankinį testavimą, nes darbuotojų pasitenkinimas gali užtikrinti daug geresnius rezultatus.
Ką testuojame naudodami rankinius testus?
Yra keletas skirtingų programinės įrangos aspektų, kuriuos tikrina rankiniai testai, ir kiekvienas iš jų yra geresnis, kai naudojamas rankinis testavimas dėl specifinių testų iššūkių.
Kai kurios iš pagrindinių funkcijų, dėl kurių jums naudinga naudoti rankinius testus, be to, kad rankiniai testai čia puikiai veikia, yra šios:
1. Pagrindinės funkcijos
Viena iš pirmųjų programinės įrangos testavimo proceso dalių yra pagrindinė programinės įrangos funkcionalumo analizė.
Šiame etape programuotojas arba testuotojas peržiūri vieną iš funkcinių kodo modulių ir įvertina, ar jis veikia taip, kaip tikėtasi. Dėl nedidelės šių modulių apimties verta sutelkti dėmesį į rankinį testavimą, nes automatizavimas užtruktų pernelyg ilgai.
Pavyzdys – duomenų bazės programinė įranga, kai bandytojai į funkciją įveda duomenis ir jau žino, kokio rezultato tikimasi.
Jei jie sutampa, testas atliktas sėkmingai. Šiame proceso etape atliekamas testavimas yra tvirtas pagrindas likusiam įmonės darbui.
2. Vartotojo sąsajos dizainas
Naudotojo sąsaja – tai programinės įrangos naudotojo sąsaja, t. y. naudotojui prieinami meniu, mygtukai ir interaktyvumas.
Atliekant naudotojo sąsajos bandymus daugiausia dėmesio skiriama naudotojo sąsajos veikimo būdui ir tam, ar naudotojui patogu ja naudotis, įskaitant tai, ar naudotojas gali sąveikauti su visomis funkcijomis ir ar meniu yra estetiški.
Šiame etape būtina atlikti rankinį testavimą, nes kokybinė informacija, pavyzdžiui, ar sąsajos atrodo gerai, nėra tai, ką automatizuota programa gali padaryti.
3. Įsiskverbimo testavimas
Įsiskverbimo testavimas – tai programinės įrangos paketo testavimas, siekiant nustatyti, kaip lengvai išorinė šalis gali neteisėtomis priemonėmis pasiekti programinę įrangą.
Programinės įrangos automatizavimo metu daugiausia dėmesio skiriama keliems konkretiems veiksmams atlikti ir užbaigti procesus, kurie jau yra taikomosios programos dalis, o ne tirti naujas sritis – tai būtina atliekant saugumo bandymus.
Pavyzdžiui, įmonė gali pasamdyti etišką įsilaužėlį, kad šis įvertintų jos programinę įrangą ir surastų bet kokią galimybę piktavališkai šaliai pasiekti naudotojo duomenis.
Tai tampa vis svarbiau po to, kai visoje Europoje buvo priimtas BDAR kaip teisės aktas.
4. Žvalgomasis testavimas
Tiriamasis testavimas – tai testavimas, kurį reikia atlikti tik vieną ar du kartus, o toks pavadinimas atsirado dėl to, kad jo metu „tiriama” programinė įranga ir ieškoma netikėtų funkcijų ar klaidų.
Šiuo atveju geriau tinka rankinis testavimas, nes užtrunka parašyti testavimo atvejo kodą, o kas nors, kas rankiniu būdu įeina į programinę įrangą ir ją patikrina, užima mažiau laiko.
Pavyzdžiui, kai kūrėjas nori patikrinti, ar tam tikra funkcija yra tinkamai integruota, ir vienu bandymu patikrinti, ar duomenys teisingai perkeliami per programą.
Rankinių testų gyvavimo ciklas
Rankinių testų gyvavimo ciklą sudaro keli etapai, o rankiniai testai naudojami įvairiems programinės įrangos paketo aspektams tirti.
Kai kurie iš rankinių testų gyvavimo ciklo etapų yra šie:
– Planavimas
Suplanuokite testavimo etapą, į kurį įeina programos reikalavimų įvertinimas, konkretūs testai, kuriuos reikia atlikti, ir programinė įranga, su kuria testuojate programinę įrangą.
Šiame etape rašomi visi testavimo atvejai, kuriuos turi atlikti rankinis testuotojas, ir sukuriama testavimo aplinka. Būkite kruopštūs, kad rankiniai testuotojai netyčia neatliktų testų skirtingais būdais.
– Testavimas:
Atlikite testus. Tai reiškia, kad bandymų atvejus reikia atlikti kelis kartus, kad gautumėte nuoseklius duomenis, ir užsirašyti visą gautą informaciją.
Jei nukrypstate nuo testavimo atvejo, pasižymėkite, kaip ir kodėl. Variacijos dažniausiai pasitaiko atliekant galutinius testus, tačiau visuose rankiniuose testuose gali būti tam tikrų skirtumų, susijusių su testuotojo darbo metodu.
– Analizė:
Išanalizuokite visus testų rezultatus. Tai apima programinės įrangos klaidų ir galimų problemų priežasčių nustatymą.
Neapsiribokite vien tik funkcionalumu ir įtraukite kokybinę informaciją, pvz., atsižvelgdami į programos dizainą.
Kokybinė informacija ypač klesti atliekant rankinį testavimą, kai testuotojai generuoja aprašomuosius duomenis, kurie informuoja kūrėjus apie nedidelius pakeitimus, kurie labai pagerina programėlės naudojimo patirtį.
– Įgyvendinimas:
Naudokitės ankstesnėmis ataskaitomis, kad įgyvendintumėte įvairius pakeitimus. Priklausomai nuo pakeitimų, tai gali būti ilgas procesas, kai kūrėjai eksperimentuoja su kodu, kad išspręstų ankstesnėse versijose buvusias klaidas.
Naudodami rankinį testavimą kūrėjai gauna papildomos naudos, nes su testuotoju aptaria visus pakeitimus. Tai padeda abiem pusėms tinkamai suprasti, ką ir kaip reikia koreguoti, nesvarbu, ar tai būtų funkciniai, ar dizaino pakeitimai.
– Iš naujo pradėkite planavimą:
Kol kūrėjai taiso ankstesnių testų problemas, planuokite kitą testų rinkinį. Tai apima naujausių atnaujinimų testavimą ir bandymus atkurti paskutinėje versijoje buvusias klaidas.
Nuolatinis bandymų ciklas reiškia, kad programinė įranga visada tobulėja ir niekada nėra statiška. Gali atrodyti, kad rankinis testavimas užima daug laiko, tačiau dėl lankstumo ir tęstinumo, kurį suteikia pakartotiniai testai, investicijos labai atsiperka.
Rankinio testavimo privalumai
Programinės įrangos kūrimo įmonėje rankinio testavimo naudojimas turi daug privalumų, pradedant pačios programinės įrangos kokybe ir baigiant tuo, kaip projektas veikia įmonės finansus.
Rankinio testavimo privalumai įmonėje yra šie:
1. Didesnis lankstumas
Norint automatizuoti bandymus, reikia, kad QA analitikas įeitų į programinę įrangą ir sukurtų bandomąjį atvejį, kuris kiekvieną kartą atliktų tikslų veiksmų rinkinį.
Nors kartais tai yra naudinga, žmogus testuotojas gali pereiti procesą ir pastebėti, kad kažkas ne taip, kaip reikia, prieš atlikdamas tyrimą ir nekeisdamas nė vienos kodo eilutės.
Tai gerokai padidina jūsų testų lankstumą ir reiškia, kad rasite programos problemų, kurios kitu atveju liktų nepastebėtos, ir turėsite daugiau galimybių jas ištaisyti.
2. Kokybinė informacija
Kokybinė informacija – tai informacija, kuri ką nors apibūdina, ir tai yra informacijos rūšis, kurią testavimo specialistai gali pasiūlyti programuotojų komandai.
Rankinis testuotojas gali pranešti bendrovei, kad tam tikras meniu yra „nepatogus”, ir paaiškinti, kodėl, o automatizavimo programa negalėtų pateikti tokios informacijos kūrėjui.
Tai reiškia, kad įmonės, į savo darbo eigą įtraukdamos rankinį testavimą, gali gerokai padidinti programėlės standartą taip, kaip joms būtų sunku, jei savo procesuose naudotų tik testavimo automatizavimą.
3. Nėra aplinkos apribojimų
Automatinis testavimas priklauso nuo esamos platformos naudojimo, o kai kurios iš jų turi gana griežtus apribojimus.
Kai kurių (nors ne visų) platformų apribojimai yra tokie: negalima dirbti su tokiomis platformomis kaip „Linux”, galima dirbti tik su tam tikra kodavimo kalba ir tik su tam tikru užduočių skaičiumi.
Kai testavimo procesuose dirbate su žmonėmis, šie apribojimai iš esmės išnyksta. Jus riboja tik rankinių testuotojų įgūdžiai, o ne techninės problemos.
Tai padės jums sukurti testavimo strategiją, kuri padės išsamiau ištirti programą ir nereikės daryti kompromisų.
4. Leidžia atlikti tinkamumo naudoti bandymus
Naudojamumo testavimas – tai toks testavimas, kurio metu vertinama, ar programinė įranga yra tinkama naudoti, įskaitant tai, kaip ji atrodo ir kaip ją jaučia galutinis naudotojas.
Atliekant tokio tipo bandymus ne tik tiesiog vertinama, ar funkcija gali būti naudojama, bet ir tikrinama, ar kas nors pasirinktų ją naudoti, palyginti su konkurentų produktais.
Įgyvendindamos rankinį tinkamumo naudoti testavimą įmonės įgyja daugiau įžvalgų ir gali atlikti koregavimus, kad programėlė taptų konkurencingesnė, o to automatizavimas negali pasiūlyti kūrimo komandoms.
Rankinio testavimo iššūkiai
Kaip ir bet kokio tipo procese, taip ir kūrėjui, naudojant rankinį testavimą kaip kokybės užtikrinimo priemonę, kyla keletas sunkumų.
Žinodami apie šiuos iššūkius galite pritaikyti metodus, kuriuos naudojate testuodami programinę įrangą rankiniu būdu, taip užkirsdami kelią rimtoms problemoms ir padidindami programos standartą proceso pabaigoje.
Kai kurie iš pagrindinių iššūkių, su kuriais susiduria įmonės, atliekančios rankinį testavimą, yra šie:
1. Testavimo įgūdžių lygiai
Pirmasis didelis iššūkis, su kuriuo tenka susidurti, yra reikalaujamas visų komandoje dirbančių rankinio testavimo specialistų įgūdžių lygis.
Talentingi rankiniai testuotojai įmonėms duoda akivaizdžią naudą, nes jos greičiau aptinka klaidas ir gali būti tikros, kad jų programinė įranga veikia taip, kaip tikimasi. Geriausios įmonės visada ieško rankinių testuotojų, kurie yra šios srities lyderiai, kad būtų užtikrintas didesnis našumas.
Būdamas testuotojas, visada stenkitės mokytis ir tobulinti šiuos įgūdžius. Patobulinti įgūdžiai reiškia, kad bendrovei suteiksite daugiau naudos, o rankiniu testavimu bus rasta daugiau klaidų ir pagerinta naudotojų patirtis. Geriausius rankinius testus atlieka testuotojai, kurie praleido daug laiko tobulindami savo įgūdžius.
2. Testavimo išlaidos
Rankinis testavimas yra įprastas procesas bet kokio dydžio įmonėms, tačiau priklausomai nuo to, kaip naudojate rankinį testavimą, išlaidos gali išaugti.
Pavyzdžiui, įmonė, turinti kelis aukštos kvalifikacijos testavimo darbuotojus, gali išleisti daug pinigų, jei testavimas atliekamas pakartotinai, nes iš tikrųjų mokate už visų darbuotojų laiką. Tai mažiau aktualu automatinio testavimo procesuose.
Ideali išeitis šiai problemai spręsti – planavimas iš anksto, nes kuo daugiau laiko skirsite planuodami atliekamus testus ir jų atlikimo tvarką, tuo mažesnė tikimybė, kad personalo išlaidos padidės, nes žmonės atliks testus, kurių jiems nereikia.
3. Laiko sąnaudos
Kompiuteriai greičiau už žmones sugeba atlikti įvairius dalykus – nuo šachmatų ėjimo planavimo iki pinigų investavimo akcijų rinkoje ar net paprasčiausio mygtuko paspaudimo pakeitus spalvą. Tokia pati koncepcija taikoma ir testavimui, kai naudotojams reikia laiko perskaityti visą informaciją ir naršyti po meniu.
Todėl rankinis testavimas gali užtrukti daug ilgiau nei naudojant testavimo automatizavimą. Kovokite su tuo, derindami rankinius ir automatinius testus, iš rankinių testuotojų atimdami smulkias užduotis, o naudodami juos ten, kur reikia kompetencijos. Procesų supaprastinimas idealiai tinka ir rankiniam testavimui, nes reikia atlikti kuo daugiau veiksmų.
4. Klaidų tikimybė
Žmonės daro klaidų. Tai natūralu, nesvarbu, ar atliekant testą veiksmai atliekami netinkama tvarka, ar dėl klaidingo paspaudimo netiksliai užrašomi rezultatai. Tačiau dėl šių klaidų gali kilti rimtų programinės įrangos testavimo režimo tikslumo problemų.
Rankiniu būdu dirbantys testuotojai, kurie yra labiau pavargę ar pavargę nuo tos pačios užduoties atlikimo kartas nuo karto, dažniau daro klaidas nei kiti, todėl, jei įmanoma, naudokite automatizavimą, kad to išvengtumėte, arba reguliariai suteikite testuotojams pertraukas nuo ekrano, nes taip jie bus budresni ir geriau supras, kas vyksta.
Vadovai taip pat gali atsižvelgti į darbo krūvio valdymą, kad žmonės neperdegtų ir neturėtų problemų.
Rankinių testų charakteristikos
Yra kelios pagrindinės savybės, į kurias reikia atkreipti dėmesį atliekant rankinius testus. Jie apibrėžia, kas yra rankinis testas, ir yra svarbios savybės, kurias galite numatyti kurdami testus.
Sužinokite daugiau apie kai kurias pagrindines rankinių testų savybes ir jų reikšmę aktyvaus testavimo aplinkoje:
1. Optimizuoti testavimo atvejai
Atliekant testavimą rankiniu būdu, testavimo atvejai yra labai optimizuoti. Tai reiškia instrukcijas, kurias rankiniu būdu dirbantis testuotojas turi pateikti prieš atlikdamas testą, o aukštas optimizavimo lygis leidžia testavimo komandai sutaupyti laiko ir išteklių, nes ji atlieka mažiau užduočių.
Visada stenkitės apriboti bandymų atvejo dydį, jei įmanoma, kad kuo geriau išnaudotumėte turimus išteklius.
2. Suprantamesni rodikliai
Geriausias rankinis testavimas pasižymi suprantamesniais rodikliais. Kai testavimo automatizavimas nuolat generuoja sudėtingą statistiką ir informaciją, įžvalgos, kurias gali suteikti šie rodikliai, nėra vertos laiko, kurio prireiktų rankiniam testuotojui juos užpildyti ar apskaičiuoti.
Rankiniu būdu atliekamiems bandymams galima taikyti paprastesnius rodiklius, kuriuos lengva generuoti ir kurių analizė vėliau užima mažiau laiko.
3. Pažangios ataskaitos
Atlikdami rankinį testavimą, testavimo komanda pateikia pažangesnes ataskaitas. Automatiniai testai proceso pabaigoje sukuria savo ataskaitas, todėl visos ataskaitos paprastai būna to paties formato.
Žmonės testuotojai yra daug lankstesni ir gali patys kurti ataskaitas, prireikus įtraukti bet kokią informaciją, kuri, jų manymu, yra naudinga kūrimo komandai.
4. Pakartotinai paleisti strategijas
Pakartotinio paleidimo strategijos – tai būdas, kuriuo testavimo komanda testus atlieka pakartotinai, rinkdama duomenis iš pakartotinių užduočių atlikimo atvejų.
Rankinis testavimas reiškia, kad pakartotinio testavimo strategijos yra daug lankstesnės, nes testuotojai gali atlikti daugiau testų, jei mano, kad reikia dar ką nors ištirti.
Kai kurie rankiniai testai taip pat aktyviai skatina naudotojo atliekamų veiksmų įvairovę, todėl galima gauti duomenų apie įvairesnį naudotojo elgesį. Taip gaunama daugiau duomenų apie programinę įrangą, o tai padeda kurti nuoseklesnes tolesnes atnaujinimo strategijas.
Rankinių testų tipai
Įmonės naudoja tris skirtingus rankinio testavimo tipus, kurių skirtumus lemia testuotojų prieigos lygis. Kiekvienas tipas naudingas savo unikaliomis aplinkybėmis.
Pagrindiniai rankinių testų tipai:
1. Baltosios dėžės testavimas
„Baltosios dėžės” testavimas – tai testavimo būdas, kai testuotojai gali matyti visą programinės įrangos šaltinio kodą ir projektavimo dokumentaciją.
Ši didesnė prieiga reiškia, kad testuotojas gali matyti visus atskirus kodo aspektus ir jų poveikį programinės įrangos veikimui. Tai idealiai tinka ankstyviausiems kūrimo proceso etapams, nes kūrėjai gali rankiniu būdu peržiūrėti savo kodą, palyginti jį su bandymų atvejais ir lengvai rasti sritį, kurioje kyla didelių problemų, prieš taisydami esamas klaidas.
2. Juodosios dėžės testavimas
„Juodosios dėžutės” testavimas – tai toks testavimo būdas, kai testuotojai nemato, kas vyksta už vartotojo sąsajos. Tai reiškia, kad nėra galimybės susipažinti su jokiu kodu ar projektavimo dokumentais, todėl bandytojai prie programinės įrangos prieina visiškai neturėdami jokių žinių.
Rankiniu būdu dirbantys testuotojai šį metodą taiko vėlesniuose kūrimo proceso etapuose, nes naudotojo priėmimo testavimui ir testavimui „nuo galo iki galo” reikia galutinio naudotojo, o ne asmens, dalyvavusio kūrimo procese, požiūrio.
3. Pilkosios dėžės testavimas
Pilkosios dėžės testavimas – tai juodosios ir baltosios dėžės testavimo derinys, todėl testuotojas turi turėti galimybę susipažinti su kai kuriais dokumentais ir išeities kodu. Taip derinama galimybė matyti galimas bet kokių problemų priežastis ir kartu riboti informaciją, o tai padeda atlikti tokias funkcijas, kaip duomenų tvarkymas.
Vidutiniais kūrimo proceso etapais naudokite rankinį pilkosios dėžės testavimą, suteikdami testuotojams tam tikrą papildomą informaciją, tačiau vis tiek priversdami juos pasikliauti savo intuicija dėl daugelio funkcijų, kad užtikrintumėte, jog galutinis vartotojas galėtų suprasti sistemas.
Išaiškinti tam tikrą painiavą – rankinis testavimas ir automatizuotas testavimas
Programinės įrangos testavimas apima dvi skirtingas disciplinas: rankinį testavimą ir automatizuotą testavimą. Nepaisant to, kad abi šios sritys atlieka tą pačią funkciją, jos yra skirtingos disciplinos, kurias įmonės naudoja savo programinės įrangos paketams tikrinti.
Toliau skaitykite daugiau apie tai, kas yra automatizuotas testavimas, kuo skiriasi automatizuotas testavimas nuo rankinio testavimo ir kada programinės įrangos kokybės užtikrinimo procesuose naudoti kiekvieną iš šių dviejų testavimo tipų.
1. Kas yra automatizuotas testavimas?
Automatinis testavimas – tai procesas, kai testuotojas, naudodamasis trečiosios šalies įrankiu, automatizuoja programinę įrangą ir tikrina, kaip programinė įranga pakartotinai atlieka tą patį procesą, kad įsitikintų, jog ji veikia pagal pakankamai aukštus organizacijos standartus. Pagrindinis testų automatizavimo privalumas yra tas, kad tai daug greitesnis procesas, ypač atliekant tokias nereikšmingas užduotis kaip duomenų įvedimas.
Pavyzdys – duomenų bazės testavimas, siekiant įsitikinti, kad ji tinkamai tvarko visą informaciją, per kelias akimirkas į programinę įrangą įvedant tūkstančius duomenų ir po to įvertinant rezultatus.
Įmonės automatizuotą testavimą pirmiausia naudoja didelėms ir labai pasikartojančioms užduotims atlikti. Kadangi automatinė sistema nepadarys smulkių klaidų, pvz., įvesdama neteisingą informaciją arba spustelėdama neteisingą nuorodą.
Vienos iš pagrindinių programinės įrangos dalių, kuriose tai naudojama, yra tiesioginės transliacijos serveriai ir duomenų bazės, nes jose apdorojama daug informacijos ir didelės naudotojų apkrovos, todėl reikia atlikti bandymus, kurie atitiktų reikalavimus.
2. Kuo skiriasi rankiniai ir automatiniai testai?
Pagrindinis skirtumas tarp rankinių ir automatizuotų testų yra jų atlikimo būdas.
Atliekant testavimą rankiniu būdu, testavimą atlieka tik žmogus, kuris stebi testavimo atvejį iki galo ir užrašo visą informaciją.
Atliekant automatinius testus, kompiuterinė programa atsakinga už testavimo atvejų užbaigimą po to, kai juos iš pradžių parašo QA analitikas.
Kai kurios automatinio testavimo platformos taip pat pačios generuoja ataskaitas naudotojams, todėl žmogui nereikia gaišti laiko renkant visus eksperimento duomenis. Vietoj to jie gali skirti laiko programinės įrangos paketo problemoms ištaisyti.
3. Išvada: Testavimas rankiniu būdu ir automatizuotas testavimas
Rankinis ir automatinis testavimas iš esmės skiriasi, nes šios dvi sąvokos, norėdamos tinkamai veikti, remiasi visiškai skirtingais pagrindais.
Tačiau jie gali glaudžiai bendradarbiauti daugelyje plėtros projektų. Naudodami automatizuotą testavimą kai kurioms sunkesnėms užduotims atlikti ir taikydami rankinio testavimo metodus toms užduotims, kurios reikalauja daugiau lankstumo, galite gerokai paspartinti testavimo procesus.
Vienas didžiausių klaidingų įsitikinimų apie testavimą yra tai, kad reikia pasirinkti vieną iš dviejų variantų, tačiau tai negali būti toliau nuo tiesos bet kokiai veiksmingai kokybės užtikrinimo komandai.
5 mitų apie rankinį testavimą paneigimas
Yra keletas mitų, kuriais tiki žmonės, susijusių su rankiniu testavimu, ir kiekvienas iš jų skatina žmones taikyti ne pačius geriausius metodus ir apsunkina rezultatų gavimą.
Penki pagrindiniai mitai, susiję su rankiniu testavimu:
1. Testavimas yra vienintelis skyrius, atsakingas už gaminio kokybę.
Produkto kokybė yra visos įmonės, o ne tik kokybės užtikrinimo grupės vaidmuo.
Programinės įrangos testavimo tikslas – pašalinti klaidas, kai tik įmanoma, todėl daugelis žmonių mano, kad klaidų taisymas ir paieška yra vienintelė QA komandos atsakomybė. Priešingai, patys kūrėjai yra atsakingi už kodo rašymą, o vadovų komanda – už kūrimo organizavimą.
Kiekvienas įmonės darbuotojas yra atsakingas už pakankamai aukšto lygio produkto sukūrimą, o ne už tai, kad testavimo komanda rastų visas problemas ir kuo greičiau pristatytų produktą.
2. Rankinis testavimas nebeturi reikšmės
Atsiradus dirbtiniam intelektui ir vis dažniau naudojamam robotizuotam procesų automatizavimui, kai kas mano, kad rankinis testavimas programinės įrangos kūrime nebeturi reikšmės. Įmonės mato, kad automatizavimas yra palyginti pigus, ir, kai tik įmanoma, renkasi šį kelią.
Rankinis testavimas tebėra vienas svarbiausių įmonės įrankių dėl E2E, „juodosios dėžės” ir GUI testavimo naudingumo. Įgyvendindamos rankinį testavimą įmonės randa programinės įrangos problemų, kurių automatinis testavimas nepastebėtų, ir taip pagerina savo produktą labiau, nei būtų galima pasiekti naudojant vien tik automatinį testavimą.
3. Tai skirta žmonėms, kurie nemoka programuoti
Viena iš pagrindinių prielaidų, kurias daro kai kurie žmonės, yra ta, kad žmonės, kurie nemoka programuoti, renkasi testuoti.
Tačiau tai toli gražu nėra tiesa. Kodo išmanymas yra būtinas daugelyje testavimo funkcijų, nes atliekant pilkosios ir baltosios dėžutės testavimą reikia skaityti kodą ir suprasti, kaip jis gali prisidėti prie bet kokių programinės įrangos pakete esančių klaidų.
Jei manote, kad testavime dalyvauja tik žmonės, kurie nemoka programuoti, galite apriboti savo komandą ir turėti žemesnio lygio testavimo darbuotojus. Jei esate testuotojas, apsvarstykite galimybę baigti kodavimo kursus, kad pagerintumėte savo standartus.
4. Galite sukurti programinę įrangą be klaidų
Kai kurie žmonės, pradėję dirbti rankinio testavimo srityje, daro prielaidą, kad kokybės užtikrinimo komanda gali surasti kiekvieną programinės įrangos klaidą ir padėti kūrėjų komandai ją pašalinti.
Teoriškai tai leistų sukurti gaminį, kuriame nebūtų jokių klaidų ir kuris visiškai patenkintų kliento poreikius. Tai, žinoma, yra idealus galutinis programinės įrangos testavimo tikslas, tačiau tai retai kada įmanoma.
Net ir didžiausios Žemės kompanijos puikiai suderintos programinės įrangos paketai turi klaidų, ir nors tikslas turėtų būti kuo labiau sumažinti klaidų skaičių, nėra nieko blogo, jei kelios nedidelės klaidos patenka į galutinę versiją. Dėl šios priežasties svarbu atlikti rankinį testavimą ir plėtrą po išleidimo.
5. Testavimas nesukuria jokios pridėtinės vertės
Vienas didžiausių mitų, susijusių su bet kokios formos programinės įrangos testavimu, yra tas, kad jis nesukuria jokios pridėtinės vertės programinės įrangos paketui. Tačiau klientai visada vertina kokybę kaip vieną svarbiausių programos aspektų, nes dėl klaidų ar prastos kokybės programų vartotojai iš karto praranda savo naudotojus ir ieško alternatyvų.
Išbaigtas produktas įmonei yra daug vertingesnis už netinkamai veikiantį produktą, o šio darbo pagrindas – veiksmingas testavimas. Aukštos klasės bandymai duoda didelę grąžą, jei įmonės nusprendžia tinkamai investuoti.
Trumpai tariant, hibridinė rankinio ir automatizuoto testavimo strategija visuomet duos geresnius testavimo rezultatus nei bet kuri iš šių strategijų, jei būtų naudojama tik viena iš jų.
Ko reikia norint pradėti rankinį testavimą?
Norint pradėti rankinio testavimo procesą, reikia kelių dalykų, o turint visas šias funkcijas, testavimas tampa ne tik lengvesnis, bet ir įmanomas.
Keletas dalykų, kurių reikia norint pradėti rankinį testavimą:
1. Programinė įranga
Pirmas dalykas, kurio reikia testuotojui, kad galėtų atlikti programinės įrangos testavimą, yra pati programinė įranga. Juk rankinis testavimas iš tikrųjų neįmanomas, jei nėra nieko, ką būtų galima testuoti.
Atliekant veiksmingą programinės įrangos bandymą reikia naudoti naujausią programinės įrangos iteraciją, nes joje yra visas naudotojo poreikius atitinkantis pirminis kodas ir ji teisingiau atspindi esamą produktą.
Jei įmanoma, programėlę sukurkite visiškai naują, kad gautumėte kuo tikslesnį programinės įrangos vaizdą.
2. Programinės įrangos reikalavimai
Testuotojas turi turėti prieigą prie programinės įrangos reikalavimų. Tai nereiškia, kad paketas turi būti susijęs su aparatine įranga ar operacine sistema, bet greičiau su programinės įrangos, kurią kūrėjas kuria, santrauka.
Išsamesni programinės įrangos reikalavimai testavimo etape reiškia, kad kokybės užtikrinimo darbuotojai nuo pat pradžių ieško visų svarbių funkcijų, atkreipia dėmesį į tai, kur yra kokių nors programinės įrangos problemų, ir rekomenduoja pakeitimus.
Be to, testuotojas dirba be jokių nurodymų ir nežino, ar jo teikiama informacija iš tikrųjų naudinga kūrimo komandai.
3. Tinkama techninė įranga
Programinei įrangai testuoti reikalinga aparatinė įranga, atitinkanti vykdomos programos poreikius.
Pavyzdžiui, jei bandytojas ieško klaidų ar problemų naujame vaizdo žaidime, kuriam reikia pažangios techninės įrangos, o turi tik žemo lygio kompiuterį, jis negalės tinkamai išbandyti programinės įrangos.
Mažoms programėlėms ar žiniatinklio įrankiams tai nėra tokia svarbi problema. Prieš pradėdami bandymus įsitikinkite, kad naudojama aparatinė įranga atitinka programinės įrangos poreikius, ir pasirinkite aparatinę įrangą pasikonsultavę su kūrimo komanda dėl programinės įrangos reikalavimų.
Rankinio testavimo procesas
Atliekant rankinio testavimo procesą reikia atlikti kelis veiksmus, kurių kiekvienas yra svarbus siekiant tiksliai įvertinti programą.
Šie veiksmai apima:
1. Išanalizuoti reikalavimus
Pirmasis rankinio testavimo proceso žingsnis – analizuoti programėlės reikalavimus. Tai apima konkrečius reikalavimus, išvardytus programos santraukoje, kai kurias projektavimo dokumento funkcijas ir kitas programos dalis, kurias tikitės pamatyti (pvz., teisinius reikalavimus).
Analizuodami juos proceso pradžioje, žinote, ką tikrinate, kai tikrinate programinę įrangą.
2. Sukurti bandymų planą
Kai žinote, ką reikia išbandyti, sukurkite bandymų planą. Tai reiškia, kad reikia žinoti, kokias funkcijas testuojate, kaip tiksliai jas testuojate ir kada atliekate šiuos testus.
Sudarydami bandymų planą įsitikinsite, kad visi reikalingi bandymai yra parengti iš anksto ir kad netyčia nepraleisite jokių funkcijų.
Tai taip pat padeda valdyti darbo jėgą, nes žinote, kiek ir kada reikia rankinių testuotojų.
3. Parašykite testavimo atvejus
Pradėkite rašyti programinės įrangos testavimo atvejus. Testavimo atvejis – tai įvykių, kuriuos atliekate testuodami programinę įrangą, rinkinys, kiekvieną kartą griežtai laikydamiesi šių įvykių, kad įsitikintumėte, jog testas yra teisingas.
Kiekvienu atveju pagalvokite apie konkretų rankinį testą, su kuriuo dirbate, ir įtraukite kuo daugiau informacijos, nes taip sumažinsite tikimybę, kad kas nors nukryps nuo pradinio plano.
4. Peržiūrėkite savo bylas
Parašę visus bandymų atvejus, atlikite išsamią peržiūrą. Tai reiškia, kad testavimo atvejai perduodami vadovaujančio personalo nariui, pageidautina – kokybės užtikrinimo vadovui.
Į korektūros procesą įtraukdami trečiąją šalį padidinsite bandymų atvejų standartą, nes pašalinsite visas galimas klaidas. Vadybininkas gali pasiūlyti patobulinimų, kurie galiausiai padės efektyviau atlikti rankinį testavimą ir padės rasti bet kokias programėlės problemas.
Prieš atlikdami testus įsitikinkite, kad kiekvienas testavimo atvejis yra patikrintas.
5. Atlikti rankinius testus
Vadovui patvirtinus testavimo atvejį, pradėkite vykdyti testus. Laikykitės jų tokia tvarka, kokią nustatėte pačioje proceso pradžioje, kad įsitikintumėte, jog atlikote kiekvieną testą ir užtikrintumėte, kad žmonės testus atlieka lėtai ir atidžiai.
Jei testus atliksite teisingai 100 proc. atvejų, sutaupysite daug laiko, nes kai kurių testų metu padarysite klaidų ir turėsite grįžti atgal ir iš naujo tikrinti, ar rezultatai yra tikslūs.
Įrašykite informaciją, kad sumažintumėte tikimybę pamiršti svarbiausią informaciją.
6. Praneškite apie bet kokias klaidas
Atlikę rankinius testus ir radę klaidų, atlikite ataskaitų teikimo procesą.
Tai reiškia, kad reikia parengti ataskaitą kūrimo komandai, kurioje būtų nurodytos visos klaidos, jų radimo vieta ir veiksmai, kurių ėmėtės joms atkurti. Į bandymus įtraukite visus gautus duomenis.
Atlikdami kokybiškesnius bandymus išsamiai aptarkite programėlės dizainą, visas problemas, su kuriomis susidūrėte, ir galimas pataisas, kurios programėlę padarytų patogesnę naudoti.
Nepamirškite, kad būtent šiame etape rankinis testavimas iš tiesų yra pranašesnis už automatizavimą, nes rankiniai testuotojai gali suteikti kokybinės informacijos, kurios automatizavimas dažnai negali suteikti.
Geriausia rankinio testavimo praktika
Geriausia praktika – tai tam tikri dalykai, kurie yra bendri visų rūšių rankiniam testavimui ir padeda pagerinti testavimo proceso standartus. Geriausios praktikos laikymasis galiausiai reiškia, kad gausite aukštos kokybės testą, kurio rezultatai yra tikslūs ir patikimi.
Atliekant rankinio testavimo procesą, reikėtų nepamiršti šių geriausios praktikos pavyzdžių:
1. Dėmesys aiškumui
Visame rankinio testavimo procese būtina pabrėžti aiškumą.
Kuo aiškesnis aiškinimas sumažina nesusikalbėjimo tarp skyrių ir specialistų tikimybę ir padeda žmonėms sutelkti dėmesį į darbą su tinkamomis programinės įrangos sritimis. Tai ypač svarbu atliekant testavimą rankiniu būdu, nes yra daugiau galimybių interpretuoti instrukcijas.
Tai apima aiškaus testavimo atvejo, kuriuo turi vadovautis testuotojas, rašymą, paprastą ir suprantamą rezultatų užrašymą ir pagalbą visiems organizacijos darbuotojams, kad jie suprastų taikomosios programos reikalavimus.
2. Naudokite nuolatinę peržiūrą
Kuo dažniau peržiūrėkite viską, kas susiję su testavimo procesu.
Veiksmingas peržiūros procesas apima dėmesį į tai, kaip darbuotojai atlieka savo darbą, testavimo atvejų peržiūrą siekiant patikrinti, ar jie vis dar veikia taip, kaip tikitės, ir pačios programinės įrangos peržiūrą siekiant užtikrinti, kad būtų daroma pažanga.
Stebėdami kiekvieno proceso aspekto kokybę, užtikriname, kad standartai nenukryptų ir kad nuo pradžios iki pabaigos gautumėte pakankamai aukštos kokybės produkciją.
3. Medžiokite ne tik klaidas
Kai kurie žmonės mano, kad pagrindinis programinės įrangos testavimo tikslas – rasti klaidų, tačiau taip toli gražu nėra. Taip pat reikia užtikrinti, kad programa veiktų kokybiškai, būtų nuspėjama ir patogi naudotojui.
Galiausiai, šis patogumas yra pagrindinis rankinio testavimo tikslas, nes jis yra beveik „neautomatinis”.
Jei vykdydami testavimo atvejį randate klaidų, įtraukite jas į savo ataskaitą, tačiau išėję iš kelio ir ieškodami klaidų, kurios nesusijusios su testavimu, galite suklaidinti kūrėjus ir atsilikti nuo proceso.
Rankinio testo rezultatų tipai
Atliekant rankinį testą galima gauti kelių skirtingų tipų išvesties duomenis, iš kurių kiekvienas suteikia unikalią informaciją apie tai, kaip veikia programa.
Rankiniu būdu atliekamų testų rezultatai gali būti tokie:
1. Defektų žurnalas
Defektų žurnalas – tai sąrašas arba dokumentas, kuriame nurodomos visos programinės įrangos testavimo metu iškilusios problemos. Kuo ilgesnis defektų žurnalas, tuo daugiau problemų, kurias reikia taisyti programinėje įrangoje.
Jie gali būti automatiniai arba rankiniu būdu parašyti rankinio testuotojo, o rankiniai testuotojai atlieka šią užduotį, susijusią su kokybiškesniais programos aspektais, nes automatizavimo platformos negali susidaryti nuomonės apie programinės įrangos kokybę ir tiesiog generuoja metrikas.
2. Kokybiniai duomenys
Tai reiškia žodinius ir rašytinius atsiliepimus, kuriuos rankinio testavimo specialistas pateikia kūrimo komandai, paprastai po to, kai atlieka tam tikrą testavimą, pvz., naudotojo priėmimo testą.
Atliekant UAT daugiausia dėmesio skiriama tam, kad įsitikintumėte, jog vidutiniam naudotojui patiks programinė įranga ir jis ja naudosis taip, kaip tikimasi, t. y., palyginti su tokiais aspektais, kaip funkcijų testavimas, dėmesys skiriasi.
Kokybiniai duomenys gaunami diskusijų su kūrėju arba ilgos rašytinės ataskaitos forma.
3. Klaidų pranešimai
Klaidų pranešimai – tai trumpos teksto eilutės, kuriose nurodoma, ar programinės įrangos pakete įvyko klaida, o jei įvyko, koks jos pobūdis.
Dauguma kūrėjų sukuria išsamią sistemą, kurioje aprašoma, kokia yra problema ir kodėl ji kyla, o problemos nustatymui naudojami klaidų kodai. Užrašydamas bet kokius programinės įrangos klaidų pranešimus, kūrėjas iš karto sužino iškilusios problemos priežastį ir žino, kokių veiksmų galima imtis, kad ją išspręstų.
Rankinių testų pavyzdžiai
Sužinoję daugiau apie tai, kaip atlikti rankinį testavimą, rasite keletą rankinio testavimo pavyzdžių. Kiekviena iš jų yra specifinė testavimo disciplina, atliekama tam tikrame kūrimo ciklo etape, todėl kūrėjams suteikiama daugiau informacijos ir patarimų, kaip tobulinti savo produktą.
Keletas rankinių testų formatų pavyzdžių:
1. Vieneto testavimas
Vieneto testavimas – tai procesas, kurio metu įsitikinama, kad kiekvienas atskiras programinės įrangos paketo vienetas veikia taip, kaip galima tikėtis. Vienetas arba modulis – tai atskira funkcija, kuri koduojama savarankiškai, o proceso pabaigoje sukompiliavus į vieną didesnį programinės įrangos paketą.
Pavyzdžiui, duomenų bazėje, kai kas nors gali išbandyti „SORT” funkciją, kad įsitikintų, jog ji tinkamai organizuoja duomenis, prieš integruojant ją į platesnį paketą.
Pagrindinė nauda, gauta atlikus vienetų testavimą, yra ta, kad suprantate, jog visos sistemos tinkamai veikia atskirai, o vėlesniuose etapuose kylančios problemos kyla dėl to, kaip visos funkcijos integruojamos viena su kita.
Ne mažiau svarbu šiuos testus atlikti rankiniu būdu, nes taip sutaupoma laiko, kuris būtų sugaištas sudėtingiems automatizuotiems testavimo atvejams koduoti.
2. Galutinis testavimas
„End-to-end” testavimas – tai visos programėlės testavimas nuo pirmojo programinės įrangos atidarymo momento iki visų jos funkcijų atlikimo.
Geras „end-to-end” testavimo pavyzdys – mobilioji programėlė, apskaičiuojanti, kiek mokesčių uždirbate, kai testuotojas parsisiunčia programėlę ir atlieka visas funkcijas, kad gautų galutinį apskaičiavimą. Testuotojas pažymi visas problemas, su kuriomis susidūrė, ir perduoda jas kūrėjams.
Kūrėjams naudinga, kad šią testavimo formą visų pirma atliktų rankiniai testuotojai, nes tai galimybė pamatyti, kaip visi programinės įrangos vienetai veikia kartu, o šis vėlyvasis testavimo etapas užtikrina, kad visa programa veiktų tinkamai.
„End-to-end” testavimas skiriasi nuo naudotojo priėmimo testavimo, nes „end-to-end” testavimas visų pirma yra vidinis procesas, o ne išorinis, su visuomene susijęs naudotojo priėmimo testavimo procesas.
3. Vartotojo priėmimo testavimas
Vartotojo priėmimo testavimas yra paskutinis programinės įrangos testavimo proceso etapas, kurio metu įsitikinama, kad produktas yra tinkamas numatytai produkto klientų grupei. Be kita ko, potencialiems klientams suteikiama prieiga prie programos, kad jie galėtų ja naudotis ir pateikti atsiliepimus.
Vienas dažniausių šiuolaikinės programinės įrangos kūrimo naudotojų priimtinumo testavimo pavyzdžių yra vaizdo žaidimų alfa ir beta testavimas, kai žaidėjai gali žaisti žaidimą ir pranešti apie visas jame esančias problemas.
Pagrindinė naudotojo priėmimo testavimo nauda yra ta, kad gaunate išorinį požiūrį į savo produktą, o ne pasikliaujate žmonių, aktyviai dalyvavusių kuriant produktą, požiūriu, todėl testavimas gali būti šališkas. Rankinis testavimas yra būtinas, nes automatizavimo sistema negali tiksliai atkartoti klientų nuotaikų.
Rankinio testavimo metu aptiktų klaidų ir klaidų tipai, kurių automatinis testavimas nepastebi
Atliekant rankinį testavimą, kaip ir atliekant automatinį testavimą, randama įvairių klaidų, klaidų ir problemų. Tačiau yra tam tikrų programinės įrangos problemų, kurias rankiniu būdu atliekamas testavimas puikiai atskleidžia, o automatizavimas jų neatskleistų.
Kai kurie pagrindiniai rankinio testavimo klaidų tipai yra šie:
1. Prasta darbo eiga
„Darbo eiga” – tai kelias, kuriuo naudotojas eina, kad pasiektų tam tikrą programos vietą ir užbaigtų procesą. Nors kai kurios darbo eigos gali būti techniškai netvarkingos, jos vis tiek gali kelti problemų, nes nespecialistui gali būti nesuprantamas jų kelias.
Tokiais atvejais rankinis testuotojas informuos kūrėją apie problemas, susijusias su dizainu, ir rekomenduos pakeitimus, taip padėdamas naudotojams patogiau ir geriau susipažinti su programėle taip, kaip automatinės sistemos to nesuprastų.
2. Grafiniai klausimai
Interneto programos veikia įvairiuose įrenginiuose, o monitoriaus skiriamoji geba ir dydis nuolat kinta priklausomai nuo naudotojo turimo telefono, planšetinio kompiuterio ar ekrano.
Prastai optimizuotose programėlėse turtas gali būti ištemptas ir blogiau atrodyti rečiau naudojamuose įrenginiuose, o automatizavimo įrankiai tiesiog seka meniu ir to nepastebi.
Naudodami įvairius prietaisus, rankiniai testuotojai gali rasti grafinių trūkumų, kuriuos ištaisius, naudotojams bus geriau naudotis programinės įrangos paketu.
3. Netikslios nuorodos
Kai kuriose svetainėse ar programose nuorodos į socialinės žiniasklaidos svetaines pateikiamos naudojant mygtukus ir įterptąsias nuorodas. Tačiau dėl spausdinimo klaidos ar klaidos kūrimo procese jos ne visada gali būti nukreiptos į reikiamą vietą, o automatinė sistema tai nebūtinai nustatys.
Nuorodos, nukreiptos ne ten, kur reikia, gali sukelti painiavą ir labai pakenkti išsaugojimui. Rankiniu būdu testuojantys asmenys patikrina visas programos nuorodas ir užtikrina, kad jos vestų į reikiamą vietą, taip padėdami galutiniams naudotojams patekti ten, kur jie nori, o ne būti suklaidintiems dėl problemos.
Bendrosios rankinio testavimo metrikos
Metrikos – tai paprastos ir išmatuojamos skaitinės reikšmės, kurios parodo kažką po bandymo pabaigos. Visi šie rodikliai yra kiekybinio pobūdžio, todėl juos lengviau įvertinti iš kūrėjo perspektyvos.
Keletas dažniausių rankinio testavimo metrikų, kurias naudoja testuotojai, yra šios:
1. Defektai
Defektų rodiklis yra gana paprastas ir reiškia programinės įrangos pakete esančių klaidų arba klaidų skaičių. Defektas – tai bet koks atvejis, kai programinė įranga neveikia taip, kaip tikėtasi, pradedant programinės įrangos funkcijomis ir baigiant grafikos veikimu. defektų kaip rodiklio analizė yra gana paprasta, nes daugiau defektų reiškia didesnę problemą įmonei.
Stebėdami, ar defektų skaičius didėja, ar mažėja nuo iteracijos iki iteracijos, galite geriau suprasti, ar programinės įrangos kokybė keičiasi tinkama linkme, nes ji nuolat atnaujinama.
2. Defektai per bandymo valandą
Defektai per bandymo valandą – tai defektų metrika, kurią papildome dar smulkesne informacija, padalydami defektų skaičių iš valandų, kurias testuotojai praleido su programine įranga, skaičiaus.
Pavyzdžiui, paprastas žiniatinklio įrankis su penkiais defektais, kuriam paleisti reikia dviejų minučių, atrodys geriau nei įrankis su dešimčia defektų, kurį naudojant bazinę metriką naudojate valandą.
Atlikę šiuos papildomus skaičiavimus, rankiniu būdu dirbantys testuotojai geriau supranta defektų tankį, supranta, kaip dažnai naudotojas gali susidurti su defektais ir ar tai daro didelę įtaką jo naudojimosi programa laikui.
Defektų ir taikomosios programos dydžio santykis visada yra naudingas, kad būtų galima įvertinti problemas.
3. Išspręstų testo atvejų procentinė dalis
Kai kurie testavimo atvejai atliekami pagal paprastą įveikimo/neįveikimo principą, o šis rodiklis parodo procentinę testavimo atvejų, kurie įveikiami, dalį. Kuo didesnis išlaikytų testų procentas, tuo geriau veikia programa.
Kai įmanoma, bandykite naudoti išlaikytą testavimo atvejo procentą pagal kiekvieną funkciją atskirai, o ne nagrinėdami visą programą. Taip gaunama išsamesnė informacija apie tai, kas veikia ir kas neveikia, todėl kūrėjai gali atlikti pakeitimus ten, kur jų reikia, o ne atlikti papildomą tyrimą, kad tiksliai nustatytų, kur yra problema. Kuo greičiau rasite problemos priežastį, tuo geriau.
7 klaidos ir spąstai įgyvendinant rankinius testus
Programinės įrangos testavimo pramonėje dažnai daromos kelios klaidos, kurių kiekviena gali lemti tai, kad klaidos nerandamos, o testavimas trunka ilgiau nei tikėtasi ir kainuoja brangiau.
Keletas pagrindinių klaidų ir spąstų, į kuriuos reikia atkreipti dėmesį ir kurių reikia vengti atliekant rankinį testavimą:
1. Pats ištaisyti klaidą
Kai kuriuose kūrimo proceso etapuose programuotojas yra asmuo, atsakingas ir už kodo testavimą, ir už problemos ištaisymą. Dėl to jie gali bandyti patys spręsti programinės įrangos problemas, nors gali būti, kad ne iki galo supranta problemos priežastį.
Jei įmanoma, pasistenkite, kad testuotojas ir sprendimą koduojantis asmuo būtų aiškiai atskirti. Tai atskirdami sumažinsite tikimybę, kad pernelyg susitelksite į konkrečios aptiktos klaidos taisymą, užuot atsižvelgę į likusią programinės įrangos dalį.
Visada paskirstykite darbą, jei tai įmanoma, kad gautumėte platesnę kompetenciją tam tikru klausimu.
2. Skubus testų atlikimas
Kai kurių programinės įrangos dalių išleidimo terminai yra labai trumpi, todėl testuotojai gali sutelkti dėmesį į greitesnį testų atlikimą, kad būtų pasiekta numatyta data. Tai rimta klaida, nes kyla pavojus, kad gali patekti daug klaidų. Rankinis testavimas gali dar labiau paaštrinti šią problemą, nes žmonės jaučia spaudimą ir aktyviai skuba atlikti užduotis.
Stenkitės kuo daugiau laiko skirti testavimo atvejams, atidžiai atlikdami kiekvieną žingsnį ir kruopščiau užsirašydami duomenis. Net jei teks šiek tiek atidėti išleidimą, geriau pristatyti išbaigtą produktą nei tokį, kuriuo naudotojai nesinaudos dėl prastų standartų.
3. Prastas bendravimas
Bendravimas komandoje yra labai svarbus bet kokiame programinės įrangos kūrimo projekte, nes žmonės turi gauti kuo daugiau informacijos iš savo kolegų ir panaudoti ją produktui tobulinti. Tai pasakytina apie nuolatinį pokalbį tarp skyrių ir viename skyriuje.
Kuo efektyviau QA komanda bendrauja su kūrėjais, tuo geresnes gaires jie gauna kurdami atnaujinimus, o visi kartu gauna naudos iš to, kad išleidžiamas aukščiausio lygio produktas.
Rankinis testavimas leidžia geriau bendrauti, nes testuotojas turi pilną patirties supratimą, todėl yra aiškesnis ir išsamesnis.
4. Bandymas be paruošimo
Pasirengimas skatina tobulumą, ir tai galioja visoje programinės įrangos testavimo srityje. Rankinio testavimo atveju tai reiškia, kad reikia skirti laiko programinei įrangai suprasti, išmokti trumpą informaciją ir sukurti testavimo atvejus, kurie būtų tinkamas iššūkis visiems šiems tikslams.
Neskubėdami galėsite atlikti bandymus pagal savo, kaip kūrėjo, poreikius, todėl yra daug didesnė tikimybė, kad rasite visas svarbiausias sistemos klaidas. Tai taip pat padeda testuotojams aiškiau perskaityti testavimo atvejus ir tiksliau juos atlikti.
5. Instinktų ignoravimas
Kai įmonė pradeda testuoti rankiniu būdu, ji tai daro dėl kelių priežasčių, įskaitant tai, kad nori, jog testuotojas prisitaikytų ir vadovautųsi žmogaus instinktais. Testuodami programinę įrangą galite pastebėti, kad kažkas atrodo keistai, nors tai nėra testavimo atvejo dalis, ir tai paskatins jus neatlikti jokių pakeitimų ar tolesnio tyrimo. Tai klaida.
Visada pasiduokite smalsumui ir klausykite, ką jums sako nuojauta, nes tai padeda rasti problemas, kurių automatinis testavimo atvejis negali rasti. Rankiniu būdu dirbantys testuotojai pasirenkami dėl jų intelekto ir patirties, todėl veikdami pagal šias savybes maksimaliai išnaudojame testo potencialą.
6. Klaidų baimė
Kiekvienas žmogus daro klaidų, nepriklausomai nuo to, kokį darbą atliekate. Tačiau geriausia tai pripažinti, o ne pradėti procesą baiminantis, kad galite padaryti klaidą. Dėl to patirsite dar daugiau streso ir tikėtina, kad kils problemų atliekant bandymus. Automatizavimas neturi šios problemos, o rankiniu būdu dirbantys testuotojai yra jautresni spaudimui.
Į užduotis žiūrėkite natūraliai, o jei suklydote, stenkitės kuo greičiau jas ištaisyti. Programinės įrangos testavimas – tai etapas, kurio metu aptinkate ir taisote problemas, o retkarčiais pasitaikanti testavimo problema galutiniam naudotojui nesugadins programinės įrangos, jei ją ištaisysite.
7. Pertraukų nedarymas
Atliekant rankinį testavimą reikia skirti daug dėmesio kiekvienai detalei, o tai gali varginti testuotoją. Nepaisant to, kai kurie testuotojai ir įmonės stengiasi, kad testuotojai dirbtų visą dieną be jokių papildomų pertraukų dėl nuovargio ar susikaupimo sutrikimų.
Tai didelė klaida. Visą dieną suteikite testavimo darbuotojams pertraukas, nes taip sumažinsite problemų atsiradimo tikimybę ir užtikrinsite, kad testavimas būtų kuo tikslesnis. Jei pats esate testuotojas, stenkitės bendradarbiauti su vadovais ir aktyviai rūpintis savo ir aplinkinių psichikos sveikata.
Geriausi rankinio testavimo įrankiai
Atlikdami rankinį testavimą, neprivalote patys atlikti visų darbo dalių. Kai kuriais atvejais testavimo valdymui ir kuo sklandesniam procesui užtikrinti puikiai tinka įrankis. Jei esate testuotojas ir galvojate, kaip patobulinti savo standartus, įrankių analizė gali būti puiki pradžia.
5 geriausi nemokami rankinio testavimo įrankiai
Pradėdami naudoti bet kokią naują programinės įrangos testavimo priemonę, norite įsitikinti, kad jūsų investicijos bus tinkamai panaudotos. Tai reiškia, kiek laiko investuojate į programinę įrangą ir kiek pinigų išleidžiate licencijai įsigyti.
Naudojant nemokamas rankinio testavimo priemones, kur kas paprasčiau gauti vertę už pinigus ir nekentėti dėl pirkėjo gailesčio, jei tai nepasiteisina.
Keletas geriausių nemokamų rankinio testavimo įrankių, prieinamų kokybės užtikrinimo komandoms, yra šie:
1. JIRA
„JIRA” yra programinės įrangos testavimo dokumentacijos priemonė, kuri leidžia programuotojams kurti bilietus bet kokioms klaidoms, problemoms ar pataisymams, kuriems reikia pagalbos. Šioje platformoje taip pat yra prioritetų nustatymo įrankiai, todėl tobulindama savo programą kūrimo komanda gali pirmiausia išspręsti svarbiausias problemas.
2. LoadRunner
„LoadRunner”, suderinama su įvairiomis programavimo priemonėmis, padeda atlikti našumo bandymus įvairiais nustatymais, generuodama sudėtingus našumo bandymų duomenis. Įrankis taip pat padeda suskirstyti kai kurias pagrindines našumo problemų priežastis, dėl kurių kūrėjas siekia padidinti našumą.
3. SonarQube
Palaiko įvairias programavimo kalbas atliekant rankinio testavimo darbus, stebi matavimus laikui bėgant, kad sumažintų ataskaitų, kurias rankiniai testuotojai turi pildyti patys, kiekį. Labai lengvai pritaikoma ir veiksmingai integruojama su įvairiomis pagrindinėmis trečiųjų šalių programomis.
4. Trac
„Trac”, sukurtas „Python” kalba, yra projekto valdymo įrankis, kuriame pateikiama peržiūros istorija, kodas ir visi pakeitimai, kad matytumėte pakeitimus, atliktus tarp bandymų. Derinant per „Trac” taip pat naudojama bilietų valdymo sistema, todėl supaprastėja naudotojo problemos radimo ir taisymo procesas.
5. NUnit
„NUnit” yra visiškai atviro kodo įrankis, pagrįstas „JUnit”, palaikantis į duomenis orientuotus testus ir veiksmingai integruojamas su įvairiomis platformomis. Kiekybinius duomenis galite gauti net ir atlikę rankinius testus, todėl kūrėjai, norintys ištaisyti bet kokias problemas, turi daugiau informacijos.
5 geriausi nemokami automatizavimo testavimo įrankiai
Nors rankinis testavimas turi daug privalumų, tačiau kartais idealus būdas yraautomatizuoti testavimo procesus.
Tai padeda pašalinti kai kuriuos trūkumus, susijusius su rankiniu testavimu, ir tuo pat metu gerai apžvelgti programinę įrangą. Norint pradėti automatizuoti, reikia tam tikrų įrankių, todėl daugelis kūrėjų, pradėdami dirbti ir susipažindami su platforma, mieliau renkasi nemokamus įrankius.
Vieni geriausių nemokamų automatinio testavimo įrankių yra šie:
1. „ZAPTEST” NEMOKAMAS LEIDIMAS
„ZAPTEST Free Edition” sukurta siekiant padėti testuotojams integruoti automatizavimą į savo darbą, daugiausia dėmesio skiriant įvairioms platformoms ir siekiant, kad naudotojai automatizavimą įdiegtų taip, kad jis tinkamai palaikytų rankinį testavimą. Pagrindinis privalumas – bet kokios užduoties automatizavimas, nes visus programinės įrangos aspektus galima automatizuoti naudojant „ZAPTEST Free Edition”.
2. Appium
Tai atvirojo kodo testavimo automatizavimo sistema, kurioje daugiausia dėmesio skiriama mobiliųjų įrenginių automatizavimui programoms, veikiančioms interneto parduotuvėse. „Appium” veikia su įvairiomis API ir operacinėmis sistemomis, įskaitant „iOS”, „Windows”, mobiliąsias, žiniatinklio ir ” Android”.
3. Katalono platforma
„Katalon” yra nekoduotas sprendimas, padedantis testuotojams, neturintiems kodavimo patirties, atlikti geresnį automatinio testavimo darbą. Šioje platformoje yra parduotuvė su įvairiais plėtiniais, tačiau tai reiškia, kad, norėdami maksimaliai išnaudoti testavimo programinę įrangą, greičiausiai turėsite skirti daug laiko ir galbūt pinigų, kad pritaikytumėte ją savo poreikiams.
4. Robotium
Atvirojo kodo įrankis, skirtas specialiai „Android” testavimui ir leidžiantis atlikti naudotojo priėmimo ir pilkosios dėžės testavimą. Nors ši programa veikia pagal aukštus standartus, naudotojams kyla tam tikra rizika, nes skirtingų platformų programas vis tiek reikės išbandyti visose kitose platformose.
5. Loadster
„Loadster” yra įrankis, skirtas padėti įmonėms, dirbančioms su programėlėmis, turinčiomis dideles naudotojų bazes. Naudodamiesi šia priemone kūrėjai gali pasiruošti didesniems duomenų srauto pikams ir užtikrinti optimalų veikimą net ir esant dideliam įmonės serverių apkrovimui. „Loadster” ne tik padeda atlikti rankinį testavimą, bet ir gali automatizuoti kai kurias testuotojo užduotis, pvz., apkrovos atkūrimą.
Išvada
Apibendrinant galima teigti, kad rankinis testavimas yra naudingas bet kuriai organizacijai. Testuotojai gali aptikti kitaip nepastebėtų problemų ir pateikti išsamią informaciją apie taikomąją programą, kurios automatizavimas paprasčiausiai negali pateikti.
Nors rankinis testavimas turi tam tikrų trūkumų, pažangios įmonės vis dažniau naudoja hibridinę rankinio ir automatinio testavimo sistemą, kuri padeda atsižvelgti į abiejų testų trūkumus ir išnaudoti abiejų testų privalumus.
Rankinis testavimas yra geresnio programinės įrangos kūrimo pagrindas, o tinkamas jo naudojimas gali labai pakeisti jūsų rezultatus.
DUK ir ištekliai
Rankinis testavimas gali būti sudėtinga tema, todėl suprantama, kad jums gali kilti daugiau klausimų apie jo veikimą. Peržiūrėkite dažniausiai užduodamus klausimus apie rankinį testavimą ir išteklius, kuriais galėsite pasinaudoti, kai laikui bėgant išmoksite tapti geresniu rankinio testavimo specialistu.
1. Geriausi rankinio testavimo automatizavimo kursai
– „Testavimo automatizavimo pagrindai” – „Udemy
– „Testavimo automatizavimo mokymo kursai” – NobleProg
– „Rankinio testavimo mokymai – Jungtinė Karalystė” – The Knowledge Academy
– „Rankinis ir automatinis testavimas” – IT Talentų centras
2. Kokie yra 5 svarbiausi interviu klausimai apie rankinį testavimą?
– „Ar turite rankinio testavimo patirties?” – Nustatoma, ar kandidatas turi daug patirties dirbant testavimo aplinkoje.
– „Kuo skiriasi rankinis testavimas nuo testavimo automatizavimo?” – Nustato, ar kandidatas turi pagrindinių techninių žinių apie testavimo procesus.
– „Kaip įveikėte iššūkius programinės įrangos testavimo aplinkoje?” – Įvertinami kandidato turimi problemų sprendimo įgūdžiai rankinio testavimo srityje.
– „Koks yra idealus įrankis, padedantis atlikti rankinį testavimą?” – Sudaro geresnį vaizdą apie kandidato naudojamą darbo eigą ir ar ji tinka įmonei.
– „Ar jums patogu dirbti komandoje?” – Leiskite pokalbio vedėjui sužinoti, ar kandidatas gali dirbti didesnėje grupėje.
3. Geriausios „Youtube” pamokos apie rankinį testavimą
– „Rankinis testavimas (visas kursas)” – SDET – QA automatizavimo technikos specialistas
– „PROGRAMINĖS ĮRANGA TESTING TUTORIAL – Master programinės įrangos testavimas ir Crack Darbas Testavimas” – Programinės įrangos testavimas Mentor
– „Kas yra rankinis testavimas? | Manual Testing Tutorial For Beginners | Edureka” – edureka!
– „Rankinio testavimo (funkcinio) koncepcijos” – Naveen AutomationLabs
– „Manual Testing Tutorials” – Programinės įrangos testavimo akademija
4. Kaip išlaikyti rankinius testus?
Yra keletas dalykų, kuriuos galite padaryti, kad išlaikytumėte rankiniu būdu atliekamus testus, pirmiausia – pasirūpinti testuotojais. Testavimo procesų centre – gerovė, todėl galite užtikrinti, kad visi būtų tinkamos būklės, kad galėtų sutelkti dėmesį ir pasiekti geriausių rezultatų.
Be to, daugiausia dėmesio skirkite geroms paramos struktūroms. Tai reiškia, kad vadovai prižiūri, ar testavimas yra nuoseklus ir ar jo rezultatai yra tikslūs, kai tik įmanoma.
Nėra jokios griežtos mechaninės ar automatizuotos priežiūros, tačiau rūpinimasis žmonėmis yra tam tikra testavimo priežiūros forma.
