Testų automatikos ir šiuolaikinės kokybės užtikrinimo problemos
Kokios yra bendros testavimo automatizavimo problemos judriose ir „DevOps“ sistemose?
Šiuolaikinės programinės įrangos kūrimas ir kokybės užtikrinimas per daug sutelktas į bandymų automatizavimą, o per mažai - į tiriamuosius.
Ar mes išleidžiame geresnės kokybės programinę įrangą su labiau automatizuotais bandymais? Manau, kad ne!
Neseniai aptikau įrašą socialinių tinklų tinkle, kuriame buvo parašyta
Tai, ką šiandien matau daugumoje bandymų ir kokybės užtikrinimo renginių, yra „DevOps“, nuolatinė integracija ir bandymų automatika.
Nors visa tai yra labai malonu, matau, kad daugybė kraupių bandymų atvejų yra automatizuoti.
Matau nedaug klaidų, apie kurias pranešta atliekant integracijos ir funkcinius bandymus, nors jos visos yra automatizuotos.
UAT vartotojai randa vis daugiau klaidų, nes ankstesnėse fazėse bandymų komandos jų nesugeba nustatyti.
Jei neišmokysime žmonių rašyti gerų bandomųjų atvejų, galų gale turėsime visiškai automatizuotą…
Ir mano ... aiškinimas yra „šūdas“. :-)
Šiaip ar taip, pažiūrėkime, kas yra tikrai vyksta šiuolaikinės kokybės užtikrinimo ir bandymų automatikos pasaulyje.
Šiuolaikinio kokybės užtikrinimo problemos
Didžioji dalis „Test Automation“ yra judrioje programoje. Programinės įrangos pramonė kaupia milžiniškas pinigų sumas, norėdama samdyti „Test Automation Experts“, kad įgytų pasitikėjimo, jog jų kuriama programinė įranga yra aukštos kokybės. Vis dėlto pastebimų klaidų ir (arba) kitų problemų randama UAT metu arba jos patenka į gamybos aplinką. Taigi kas vyksta?
Pastaba:Pagal „Test Automation“ dažniausiai turiu omenyje Svogūnas Testavimo automatika.Automatinis testavimas dabar yra kiekvieno šiuolaikinio programinės įrangos kūrimo proceso esmė. Jo tikslas yra pagalba pateikti aukštos kokybės programinę įrangą pakartotinai, bet ar tikrai?
Ar testuotojai vis dar testuoja?
Tiesa ta, kad daugumoje judrių komandų bandytojai nebetikrina.
Neautomatinis bandymas prarado savo dorybę dėl tokių kūrimo praktikų ir kultūrų kaip judrus ir „DevOps“ , kurie QA erdvėje sukūrė takoskyrą - tie, kurie gali koduoti, ir tie, kurie negali.
Dažnai girdėjote tokius dalykus: „Aš esu 100% automatikos inžinierius“, „80% automatikos, 20% rankinis“, o dar blogiau - „Aš nekenčiu rankinio testavimo“. Šokiruojantis!
„DevOps“ esame įsitikinę, kad viskas turėtų būti automatizuota. Nėra vietos rankiniam įsikišimui, pvz. rankinis bandymas.
Šiais laikais dauguma judrios komandos testuotojų stengiasi neatsilikti nuo „Test Automation“ poreikio. Sprintyje yra spaudimas automatizuoti kiekvieną istoriją ir nėra pakankamai laiko nuodugniems tiriamiesiems bandymams.
Problema, ypač Agile kūrimo srityje, yra ta, kad kokybės užtikrinimo priemonės priima vartotojo istoriją ir automatizuoja jos priėmimo kriterijus. Tai darydamas, jų pagrindinis ir vienintelis tikslas yra kovoti su ribotais kodavimo įgūdžiais, kad tik būtų išlaikytas testas.
Natūralu, kad tai sukuria siaurą dėmesį, kai jus domina tik bandymo automatizavimas ir matote, kad jis praeina statybų vamzdyne. Tai tik įrodo, kas buvo priimtinumo kriterijuose - teisinga ar neteisinga - veikia ir jūs esate linkę pamiršti bendrą vaizdą.
Rankinio testavimo sumažėjimas
Vis daugiau „tradicinių bandytojų“ pereina prie „judriojo testavimo“, lankydami tam tikras kodavimo pamokas ir tampa techniškesni.
Nesupraskite manęs neteisingai; tai viskas gerai. Manau, kad kaip bandytojai visada turėtume stengtis išmokti naujų ir naujų technologijų, kad būtume išradingi. Turėtume suprasti technologijų kaminą, jei norime išbandyti sistemą aukštos kokybės.
Tačiau tikroji priežastis, kodėl dauguma rankinių bandytojų imasi šių iniciatyvų, yra ta, kad yra įprasta manyti, kad „automatinis testavimas“ yra pranašesnis už rankinį bandymą, o, kodavimas yra įdomus, tiesa?
Pastaba:Atlikdamas rankinį bandymą aš NE nuoroda į senosios mokyklos būdą sekti scenarijų ir atlikti veiksmus. Turiu omenyje vadinamuosius „tiriamuosius testuotojus“ - tuos, kurie atlieka tikrąjį testavimą ir yra įdomūs ištirti sistemos elgesį, vykdydami įdomius ir apgalvotus scenarijus.Deja, atrodo, kad tiriamųjų bandytojų rinkoje smarkiai sumažėjo. Tai akivaizdu. Tiesiog atlikite keletą paieškos užklausų „rankinis testeris“ ir „automatikos testeris“ bet kurioje IT darbo vietoje ir patys pamatysite rezultatą.
Testo automatikos problemos
Pažiūrėkime, kodėl dauguma bandomųjų automatizavimo pastangų nesuteikia jokios vertės.
Dažniausios klaidos, kurias matau kartojantis:
- Klaidingai tikiesi automatizuotų testų
- Testų automatizavimas netinkamu sluoksniu, netinkamu laiku ir netinkamų įrankių naudojimas
- Nenaudingų bandymų automatizavimas
- Nepaisydamas svarbių sričių
- Trūksta pagrindinių scenarijų
Klaidingi lūkesčiai
Kurį laiką rašiau tinklaraščio įrašą kodėl norėtumėte automatizuoti testą ? Jei neskaitėte, verta perskaityti.
Šio straipsnio santrauka yra ta, kad jūs automatizuojate testus, kuriuos norite reguliariai vykdyti. Pagal apibrėžimą, tai yra jūsų regresijos testai, kurie patvirtina, kad sistema vis dar veikia.
Tačiau jei automatizuotuose patikrinimuose randama daug regresijos problemų, abejoju kūrėjų įgūdžiais ir kūrimo procesu. Vartotojo sąsajos automatizuoti testai neturėtų būti [laikomi sąskaita] ar [kompensuojami] už varganą kodavimą.
Neteisingas sluoksnis, netinkami įrankiai ir netinkamas laikas
Dauguma judrių komandų „Test Automation Engineers“ žiūri į vartotojo istoriją ir automatizuoja jos priėmimo kriterijus. Dažniausiai tai daroma derinant seleną ir agurką.
Šiuolaikinės žiniatinklio programos dabar aiškiai suskirstytos į vidinę ir išorinę. Pagrindinę programą sudaro daugybė REST žiniatinklio paslaugų arba API su lengvai pasiekiamais galiniais taškais.
Programos logiką galima išbandyti API sluoksnyje. Tačiau dauguma bandomųjų automatikos inžinierių naudojasi sąsajos funkcionalumo patvirtinimu, kuris geriausiu atveju yra sudėtingas.
Yra testavimo įrankių, tokių kaip Karatė ir „Rest-Assured“, kurie supaprastina API testavimą. Kurdami turėtume naudoti šias priemones. Deja, kai kurie bandymų automatikos inžinieriai net nežino HTTP pagrindai , jau nekalbant apie galimybę parašyti API testavimo scenarijus.
Kalbant apie vartotojo sąsajos automatizavimą, Kiparisas yra puiki priemonė. Tai daugiau kaip TDD įrankis, skirtas front-end kūrėjams. Kūrėjai gauna labai greitą atsiliepimą apie naujų vartotojo sąsajos komponentų veikimą.
Tiek „Karate“, tiek „Cypress“ yra „plėtros bandymo priemonės“, t. Y. Priemonės, kuriomis vadovaujamasi ir palaikoma plėtra. Abi yra lengvos, lengvai integruojamos ir gali suteikti pasitikėjimas vystymusi .
Tada mes galime naudoti „Selenium“ arba „Cypress“, kad suprojektuotume tik keletą scenarijų, kurie naudoja sistemą nuo galo iki galo. Šie scenarijai sudaro mūsų lengvą regresijos paketą ir pateikia pasitikėjimas verslo tęstinumu .
Gana dažnai girdžiu tokius dalykus: „Prieš automatizuodami testus, mes laukiame, kol funkcija bus visiškai sukurta ir stabili“. Bet kuris sąmoningas bandytojas žino, kad naujos funkcijos klaidos viršija regresijos klaidas. Yra didesnė tikimybė rasti problemų dėl dabartinės besivystančios funkcijos nei stabili funkcija.
Jei ketinate skirti laiko bandymų automatizavimui, atlikite juos lygiagrečiai su kūrimu, kai jie gali suteikti daugiau vertės.
Nenaudingų bandymų automatizavimas
Negalima automatizuoti kiekvieno „testo“ vien dėl jo. Įtraukite į žaidimą šiek tiek mąstymo proceso. Išnagrinėkite aukšto ir žemo lygio architektūrines diagramas. Paklauskite, kas gali suklysti. Išnagrinėkite integracijos taškus ir ieškokite galimų gedimo taškų.
Laikykitės rizikos požiūriu pagrįsto požiūrio automatizavimo srityje, kaip tai darytumėte (tikiuosi) atlikdami bendrą bandymų metodą. Kokia tikimybė, kad kažkas žlugs, ir koks gedimo poveikis? Jei atsakymas yra didelis, šie scenarijai turėtų būti automatizuoti ir vykdomi kiekviename kūrinyje.
Kiekviename sprinte mes dažnai rašome automatinius testus apie to sprinto vartotojo istorijas ir pamirštame integraciją su kitomis funkcijomis. Integracijos testai yra silpni arba jų nėra.
Atminkite, kad automatizuoti „testus“ reikia laiko. Taip pat turėkite omenyje, kad automatizuodami testą jūs tikrai netestuojate, tik tik patikrinate, ar nagrinėjama funkcija atitinka kai kuriuos priėmimo kriterijus.
Tu negali automatizuoti bandymus, bet galite automatizuoti žinomų faktų tikrinimą.
Todėl kiekvieną kartą, kai praleidžiate „testo“ automatizavimą, pagalvokite apie laiką, kurį sugaištate neišbandę!
Nepaisydamas svarbių sričių
Nuo DevOps kultūros gimimo matau vis daugiau šio aplaidumo.
„DevOps“ programoje tiekimo vamzdynas kartu su diegimo scenarijais yra programinės įrangos kūrimo ir pristatymo stuburas, tačiau jie vargu ar kada bus išbandomi.
Per pastaruosius kelerius metus galėčiau lengvai pasakyti, kad mačiau daug daugiau „aplinkos problemų“ nei funkcinių klaidų. Aplinkos problemos, tokios kaip problemos su CI serveriu, diegimo scenarijais, bandymo aplinka ir kt.
Aplinkos problemos turi rimtą poveikį kūrimo ir bandymo pastangoms. Jie sunaudoja daug kūrėjo ir „DevOps“ laiko ir labai lėtina diegimo procesą, tačiau nėra jokio bandymo išbandyti ir taip užkirsti kelią šioms problemoms.
Mes tiesiog priimame juos kaip šiuolaikinio programinės įrangos pristatymo dalį.
Mes daug pastangų skiriame funkcinio elgesio automatizavimui ir visiškai nepaisome svarbiausių „dalykų“. Dar blogiau yra pasikliauti „Selenium“ testais, kad būtų galima parodyti, ar diegimas veikia, ar ne!
Trūksta pagrindinių scenarijų
Scenarijai yra karalius! Galų gale, būtent scenarijai atskleidžia klaidas.
Dažnai rimta problema nuteka į gamybą, nes niekas negalvojo apie tą konkretų scenarijų. Atliktų automatizuotų testų skaičius neturi reikšmės. Jei scenarijus nebuvo sugalvotas ar išbandytas, sodos įstatymas mums sako, kad ten yra klaida.
Deja, daugelyje judrių kūrimo aplinkų nėra skiriama pakankamai dėmesio šiai visai svarbiai „Scenarijų dirbtuvių“ veiklai.
Proceso problemos
Pažiūrėkime, kaip minėtos problemos pasireiškia tipišku vystymosi scenarijumi:
- Produkto savininkas rašo naudotojų istorijas be jokių priėmimo kriterijų arba minimalių priėmimo kriterijų.
- Nepakanka laiko, skirto istorijos tobulinimo seansams, norint aptarti įvairius vartotojo istorijos scenarijus.
- Priėmimo kriterijai aiškinami kaip priėmimo testai - taip, tarp jų yra skirtumas !
- Testuotojai automatizuoja tik priėmimo kriterijus naudotojų istorijose, dažniausiai naudodami seleną ir (arba) agurką.
- Beveik visada už automatizuotą testavimą atsako „automatikos testuotojai“.
- Kūrėjai neįsivaizduoja, kas yra testų paketuose, arba net nežino, kaip atlikti automatinius testus.
- Automatiniai testai pridedami prie nuolat besiplečiančio „regresijos paketo“, todėl kiekvieną kartą jų vykdymas užtrunka vis ilgiau.
- Vartotojo sąsajos automatiniai funkciniai bandymai yra integruoti į tiesimo vamzdyną, o tai yra gerai, bet…
Kūrėjas paleidžia paprastą pakeitimą ir turi palaukti 30 minučių, kol automatizuoti testai taps ekologiški, kol naująją funkciją ar klaidų taisymą bus galima pritaikyti gamyboje. 30 minučių laukti reikia tik tuo atveju, jei testai praeina pirmą kartą. Jei jie nepavyks dėl kokių nors bandymų ar aplinkos problemų, tai gali užtrukti ilgiau.
Vykstant automatiniams bandymams ir QA tiriant atsitiktines gedimus, kūrėjas ir (arba) produkto savininkas patikrino naują diegimą ir mielai išleido, bet to padaryti negali, nes versija nėra žalia.
Po kurio laiko komponavimas tampa žalias, arba vadovybė nusivilia nepavykusiais bandymais ir vis tiek priima sprendimą išleisti. Tada, BOOM, po kelių minučių gamybos, įvyko 500 serverio klaidų šuolis.
Infrastruktūros gedimai
Panašu, kad nesėkmės rodo panašų modelį
- Nesėkmė integracijos taškuose.
- Nesugebėjimas bendrauti su trečiųjų šalių programomis.
- Žiniatinklio paslaugos nėra „įjungtos“, o API užklausoms nepavyksta pateikti užklausų.
- Neteisinga vieno iš VM ar mazgų konfigūracija, todėl kyla protarpinių problemų.
Vis dėlto nėra jokio proceso, kaip patikrinti šias problemas kaip kūrimo ar pristatymo proceso dalį.
Testų automatikos inžinierių dėmesys skiriamas funkcinių testų automatizavimui. Neskiriama dėmesio našumui, saugumui ar atsparumui. Ir tikrai nėra jokių infrastruktūros bandymų!
Santrauka
Atėjo laikas perkelti dėmesį nuo funkcinių testų automatizavimo, kurie turi mažai galimybių užfiksuoti funkcines problemas, į rimtesnes ir dažniausiai pasitaikančias aplinkos problemas, kurios kankina plėtrą.
„Test Automation“, jei padaryta neteisingai arba be jokio mąstymo proceso , yra laiko švaistymas ir niekam neteikia jokios vertės. Nešvankūs automatizuoti bandymai gali patirti didžiules priežiūros išlaidas ir trukdyti plėtrai. Galų gale vienintelis sprendimas yra išmesti bandymus.
Kuriant šiuolaikinę programinę įrangą, didžioji „Test Automation Engineers“ pastangų dalis tenka kovai su automatikos kodu ir „testų“ veikimui, o ne susitelkimui į tinkamą testavimą ir sistemos tyrimą.
Pažodžiui nėra pakankamai laiko parašyti automatikos kodą ir atlikti tiriamuosius bandymus. Mes automatizuojame istoriją po istorijos ir pamiršome integracijos testus, pamiršome bendrą vaizdą.
Dažnai mes atliekame daugybę automatizuotų bandymų, tačiau tiriamieji bandymai nustato daugumą klaidų. Tada retrospektyviai mes parašome automatinį klaidų, rastų atliekant tiriamąjį bandymą, testą, siekiant užfiksuoti regresijos klaidas.
Turėtume pasirinkti, ką automatizuoti, ir vertinti savo sprendimą pagal riziką. Kas gali suklysti, kokia tikimybė, kad bus blogai, ir koks bus poveikis vartotojui ar verslui, jei jis suklydo?
Jei užsiimate „Test Automation“ veikla, nenaudokite „Selenium“ API ar NS komponentų funkcionalumui išbandyti. Vietoj to, naudokite „Selenium“, kad automatizuotumėte tik keletą naudingų ir kritiškai svarbių scenarijų, kad užtikrintumėte verslo tęstinumą prieš kiekvieną leidimą.
Ir galiausiai, kiekvieną kartą, kai praleidi automatizuodamas „testą“, pagalvok apie laiką, kurį sugaiši neišbandęs!
Papildoma literatūra:
