Vandamál með sjálfvirkni í prófunum og nútíma QA

Hvað eru nokkur algeng vandamál við próf sjálfvirkni í lipurri og DevOps?

Nútíma hugbúnaðarþróun og QA einbeita sér of mikið að sjálfvirkni prófa og ekki nægilega í rannsóknarpróf.

Erum við að gefa út betri gæðahugbúnað með sjálfvirkari prófunum? Ég held ekki!

Ég rakst nýlega á færslu á samfélagsmiðli sem sagði

Það sem ég sé í flestum prófunum og QA viðburðum í dag er aðallega DevOps, stöðug samþætting og próf sjálfvirkni.

Þó að þetta sé allt mjög fínt sé ég að mörg vitlaus prófdæmi eru sjálfvirk.

Ég sé fáar villur tilkynntar við samþættingarpróf og virknipróf þó þau séu öll sjálfvirk.

Í UAT eru notendur að finna fleiri og fleiri villur vegna þess að prófunarteymin ná ekki að bera kennsl á þá í fyrri áföngum.

Ef við kennum ekki fólki hvernig á að skrifa góð prófdæmi munum við verða með fullkomlega sjálfvirkan ...

Og túlkun mín á ... er „vitleysa“. :-)

Engu að síður, við skulum sjá hvað er virkilega að gerast í heimi nútíma QA og Test Automation.

Vandamál með nútíma QA

Flestir “Próf sjálfvirkni” innan liprar þróunar eru í slæmu ástandi. Hugbúnaðariðnaðurinn hellir inn gríðarlegu fé til að ráða „Test Automation Experts“ aðallega til að öðlast tilfinningu um traust á því að hugbúnaðurinn sem þeir eru að smíða sé í háum gæðaflokki. Samt sem áður finnast áberandi villur og / eða önnur vandamál við UAT eða renna í framleiðsluumhverfi. Svo hvað er í gangi?

Athugið:Með Test Automation er ég aðallega að vísa til LAUKUR Próf sjálfvirkni.

Sjálfvirk prófun er nú kjarninn í hverju nútíma hugbúnaðarþróunarferli. Tilgangur þess er að hjálp afhenda hágæða hugbúnað á endurteknum grundvelli, en er það virkilega?

Prófa prófarar enn?

Sannleikurinn í málinu er sá að í flestum liprum teymum prófa prófarar ekki lengur.

Handvirkt próf hefur misst dyggðina, þökk sé þróunarvenjum og menningu eins og lipur og DevOps , sem hafa skapað klofning í QA rýminu - þeir sem geta kóða og þeir sem ekki geta.

Þú myndir oft heyra hluti eins og „Ég er 100% sjálfvirkniverkfræðingur“ eða „80% sjálfvirkni 20% handbók“, eða jafnvel verra, „Ég hata handvirkar prófanir“. Átakanlegt!

Í DevOps erum við látin trúa því að allt eigi að vera sjálfvirkt. Það er enginn staður fyrir handvirkt inngrip, t.d. handprófun.

Nú á dögum berjast flestir prófendur í lipru teymi við að halda í við „Test Automation“ kröfuna. Þrýstingur er á að gera hverja sögu sjálfvirka á sprettinum og það er ekki nægur tími til ítarlegrar rannsóknarprófunar.

Vandamálið, sérstaklega í Agile þróun, er að QA taka notendasögu og gera sjálfvirkar viðmiðunarreglur hennar. Meðan það er gert er aðaláherslan þeirra eini að glíma við takmarkaða kóðunarhæfileika sína bara til að láta prófið standast.

Auðvitað skapar þetta þröngan fókus þegar þú hefur aðeins áhuga á að gera prófið sjálfvirkt og sjá það fara í byggingarleiðslunni. Þetta sannar aðeins hvað var í samþykkisviðmiðunum - rétt eða rangt - er að virka og þú hefur tilhneigingu til að gleyma stóru myndinni.

Samdráttur í handprófun

Sífellt fleiri „hefðbundnir prófanir“ eru að fara yfir í „lipra próf“ með því að taka smá kóðunarnám og verða tæknilegri.

Ekki misskilja mig; þetta er allt gott. Ég tel að við sem prófunarmenn ættum alltaf að leitast við að læra nýja og nýjar tækni til að vera útsjónarsöm. Við ættum að skilja tæknistafla ef við viljum prófa kerfi í miklum gæðum.

Hins vegar er raunverulega ástæðan fyrir því að flestir handprófendur taka þessar aðgerðir að það er almenn trú á að „sjálfvirkar prófanir“ séu betri en handprófanir og hey, kóðun er skemmtileg, ekki satt?

Athugið:Með handvirkum prófunum er ég það EKKI vísað til gamla skólans leiðar til að fylgja handriti og framkvæma skrefin. Ég er að vísa til svonefndra „könnunarprófara“ - þeir sem gera raunverulegar prófanir og eru forvitnir að skoða hegðun kerfisins með því að æfa áhugaverðar og ígrundaðar aðstæður.

Því miður virðist vera mikill samdráttur á markaði fyrir rannsóknarprófara. Þetta er alveg augljóst. Keyrðu bara nokkrar leitarfyrirspurnir fyrir „handprófunartæki“ og „sjálfvirkni prófanir“ á hvaða upplýsingatæknisíðu sem er og sjáðu niðurstöðurnar sjálf.

Vandamál með sjálfvirkni í prófunum

Nú skulum við sjá af hverju mest af sjálfvirkni prófsins skilar ekki neinu gildi.

Algeng mistök sem ég sé gerast ítrekað:

  • Að hafa rangar væntingar um sjálfvirkar prófanir
  • Sjálfvirkar prófanir á röngu lagi, á röngum tíma og nota röng verkfæri
  • Sjálfvirk gagnslaus próf
  • Að vanrækja mikilvæg svæði
  • Lykilatburðarás vantar

Rangar væntingar

Fyrir stuttu skrifaði ég bloggfærslu á af hverju viltu gera sjálfvirkan prófun ? Ef þú hefur ekki lesið það er það þess virði að lesa það.

Samantekt þeirrar greinar er sú að þú gerir sjálfvirkar prófanir sem þú vilt keyra reglulega. Samkvæmt skilgreiningu eru þetta aðhvarfspróf sem staðfesta að kerfið virkar enn.

Hins vegar, ef sjálfvirkar athuganir finna mikið af afturförarmálum, myndi ég efast um færni verktaki og þróunarferlið. Sjálfvirk próf HÍ eiga ekki að vera [haldin á kostnað] eða [bætt] fyrir ömurlega kóðun.

Rangt lag, rangt verkfæri og rangur tími

Meirihluti „Test Automation Engineers“ í liprum teymum, skoða notendasögu og gera sjálfvirkni viðmiðunar viðurkenningar hennar. Oftast er þetta gert með blöndu af seleni og agúrku.

Nútíma vefforrit eru nú greinilega skipt á milli bakenda og framenda. Bakendinn er aðallega samsettur úr fjölda REST vefþjónustu eða API með auðvelt aðgengilegum endapunktum.

Rökfræði forritsins er hægt að prófa með API laginu. Flestir prófunar sjálfvirkir verkfræðingar grípa hins vegar til að sannreyna virkni í HÍ laginu sem er í besta falli þunglamalegt.

Það eru prófunartæki þarna úti, svo sem Karate og vera viss um að einfalda API prófanir. Við ættum að nota þessi tæki meðan á þróun stendur. Því miður, sumir próf sjálfvirkni verkfræðingar vita ekki einu sinni grunnatriði HTTP , hvað þá að geta skrifað API prófunaraðstæður.

Hvað varðar sjálfvirkni prófunar HÍ, Cypress er frábært tæki. Það er meira eins og TDD tól fyrir framhlið verktaki. Hönnuðirnir fá mjög fljótleg viðbrögð við hegðun nýju HÍ íhlutanna.

Bæði Karate og Cypress þjóna sem „þróunarprófunartæki“, þ.e.a.s. verkfæri sem leiðbeina og styðja þróun. Báðir eru léttir, auðvelt að samþætta og geta veitt traust á þróun .

Við getum þá notað Selenium eða Cypress til að hanna aðeins handfylli sviðsmynda sem æfa kerfið frá enda til enda. Þessar sviðsmyndir mynda létta aðhvarfspakka okkar og veita traust á samfellu í viðskiptum .

Oft heyri ég hluti eins og „við bíðum þar til eiginleikinn er fullþróaður og stöðugur, áður en prófanir verða sjálfvirkar“. Sérhver meðvitaður prófanir kannast við að nýjungagallarnir eru fleiri en aðhvarfsgalla. Meiri líkur eru á að finna vandamál með núverandi þróunaraðgerð en stöðugan eiginleika.

Ef þú ætlar að eyða tíma í sjálfvirkan próf, gerðu þau samhliða þróun þegar þau geta veitt meira gildi.

Sjálfvirk gagnslaus próf

Ekki gera sjálfvirkt öll „próf“ bara vegna þess. Settu eitthvað hugsunarferli í leikinn. Rannsakaðu byggingarmyndir á háu og lágu stigi. Spurðu hvað getur mögulega farið úrskeiðis. Athugaðu samþættingarpunktana og leitaðu að hugsanlegum bilunarstöðum.

Taktu áhættumiðaða nálgun í sjálfvirkni eins og þú myndir (vonandi) gera með prófunaraðferðinni þinni. Hverjar eru líkurnar á að eitthvað bresti og hver eru áhrifin af biluninni? Ef svarið er hátt, þá ættu þessar sviðsmyndir að vera sjálfvirkar og framkvæmdar í hverri byggingu.

Í hverjum spretti endum við oft með því að skrifa sjálfvirk próf í kringum notendasögur fyrir þann sprett og gleyma samþættingu við aðra eiginleika. Það eru annaðhvort veik eða engin samþættingarpróf.

Mundu að sjálfvirk „próf“ tekur tíma. Hafðu einnig í huga að með því að gera sjálfvirkt próf ertu ekki í raun að prófa, þú ert aðeins að athuga hvort viðkomandi eiginleiki uppfylli nokkur viðmiðunarskilyrði.

Þú getur ekki gera sjálfvirkan próf, en þú getur sjálfvirkt athugað þekktar staðreyndir.

Þess vegna skaltu hugsa um tímann sem þú ert að eyða með því að prófa ekki í hvert skipti sem þú notar sjálfvirkt „próf“.

Vanræksla mikilvægra svæða

Ég sé meira og meira af þessu gáleysi frá fæðingu DevOps menningarinnar.

Í DevOps er afhendingarleiðslan ásamt útfærsluforskriftunum hryggurinn í hugbúnaðarþróun og afhendingu, en þeir láta varla reyna sig.

Undanfarin ár gæti ég auðveldlega sagt að ég hef séð miklu meira „umhverfismál“ en virkar villur. Umhverfismál eins og vandamál við CI netþjóninn, dreifingarforritin, prófunarumhverfið og svo framvegis.

Umhverfismál hafa alvarleg áhrif á þróun og prófanir. Þeir neyta mikils verktaka og DevOps tíma og hægja mjög á dreifingarferlinu, en það er engin umhugsun um að prófa og koma þannig í veg fyrir þessi mál.

Við tökum bara á móti þeim sem hluta af nútíma afhendingu hugbúnaðar.

Við leggjum mikið upp úr því að gera hagnýta hegðun sjálfvirkan og virðum að engu þá „hluti“ sem mestu máli skipta. Enn verra er að þurfa að reiða sig á Selen-próf ​​til að gefa til kynna hvort dreifing virkar eða ekki!

Lykilatburðarás vantar

Sviðsmyndir eru kóngur! Þegar öllu er á botninn hvolft eru það sviðsmyndirnar sem afhjúpa villur.

Alveg oft lekur alvarlegt mál í framleiðslu vegna þess að enginn hugsaði um þessa tilteknu atburðarás. Fjöldi framkvæmdra sjálfvirku prófa skiptir ekki máli. Ef atburðarás var ekki hugsuð eða prófuð segja lögin um gos okkur að það sé galla þarna inni.

Því miður, í flestum lipru þróunarumhverfi, er ekki nægjanleg hollusta lögð fyrir alla þessa mikilvægu „Atburðarásverkstæði“.

Vandamál við ferlið

Við skulum sjá hvernig ofangreind vandamál koma fram í dæmigerðri atburðarás:

  • Vörueigandi skrifar notendasögur með annaðhvort engum eða lágmarks viðmiðunarskilyrðum.
  • Ekki nægur tími sem varið er til að betrumbæta sögur til að ræða ýmsar aðstæður fyrir notendasögu.
  • Samþykkisviðmið eru túlkuð sem samþykkispróf - Já, það er munur á þessu tvennu !
  • Prófarar gera sjálfvirkt viðmiðanir um samþykki í notendasögunum eingöngu með því að nota selen og / eða agúrku.
  • Sjálfvirk próf eru næstum alltaf á ábyrgð „sjálfvirkni prófunaraðila“.
  • Hönnuðir hafa ekki hugmynd um hvað er fjallað í prófunarpökkunum eða vita ekki einu sinni hvernig á að framkvæma sjálfvirku prófin.
  • Sjálfvirku prófunum er bætt við sístækkandi „aðhvarfspakka“ og tekur því lengri tíma að hlaupa í hvert skipti.
  • Sjálfvirku virkni prófanir HÍ eru samþættar byggingarleiðslunni, sem er gott en ...

Framkvæmdaraðili ýtir undir einfalda breytingu og þarf að bíða í 30 mínútur eftir að sjálfvirku prófin fari grænt áður en hægt er að dreifa nýju aðgerðinni eða villuleiðréttingunni til framleiðslu. 30 mínútna bið er aðeins ef prófin standast í fyrsta skipti. Ef þau mistakast vegna einhverra prófana eða umhverfismála getur það tekið lengri tíma.

Þar sem sjálfvirku prófin eru í gangi og QA er að kanna tilviljanakennda bilanir hefur verktaki og / eða vörueigandi staðfest nýja útfærslu og er fús til að gefa út, en þeir geta það ekki vegna þess að byggingin er ekki græn.

Eftir smá tíma verður byggingin græn eða að stjórnendur verða svekktir yfir prófunum sem falla og taka ákvörðun um að sleppa engu að síður. Síðan, BOOM, eftir nokkrar mínútur í framleiðslu, er aukning í 500 netþjónavillum.

Innviðauppbrot

Bilanirnar virðast sýna svipað mynstur

  • Bilun í samþættingarstöðum.
  • Bilun í samskiptum við forrit þriðja aðila.
  • Vefþjónusta er ekki „uppi“ og beiðnir um API-endapunkta mistakast.
  • Röng stilling á einum af tölvum eða hnútum, sem leiðir til hléum á vandamálum.

Og samt er ekkert ferli í gangi til að kanna þessi mál sem hluta af þróunar- eða afhendingarferlinu.

Fókus sjálfvirkni verkfræðinga er að gera sjálfvirkni próf. Engin áhersla er lögð á frammistöðu, öryggi eða seiglu. Og það er vissulega engin prófun á innviðum!

Yfirlit

Tími er kominn til að breyta áherslum okkar frá sjálfvirkum hagnýtingarprófum sem hafa litla möguleika á að ná hagnýtum málum yfir í alvarlegri og algengari umhverfismál sem hrjá þróunina.

Próf sjálfvirkni, ef gert er vitlaust eða án hugsunarferlis , er sóun á tíma og veitir engum gildi. Vitlaus sjálfvirk próf geta haft í för með sér mikla viðhaldskostnað og hindrað þróun. Að lokum er eina lausnin að hylja prófin.

Í nútíma hugbúnaðarþróun er mest af áreynslu „Test Automation Engineers“ varið í að berjast við sjálfvirknikóða og fá „prófin“ til að virka frekar en að einbeita sér að réttum prófum og kanna kerfið.

Það er bókstaflega ekki nægur tími til að skrifa sjálfvirknikóða og framkvæma rannsóknarpróf. Við gerum sjálfvirkan sögu eftir sögu og gleymum samþættingarprófunum, gleymum stóru myndinni.

Oft endum við með því að framkvæma tonn af sjálfvirkum prófum, en enn finnur rannsóknarpróf meirihluta galla. Síðan skrifum við afturvirkt próf fyrir galla sem fundust með rannsóknarprófum til að ná afturhvarfsgalla.

Við ættum að vera sértæk um hvað eigi að gera sjálfvirkan og dæma ákvörðun okkar út frá áhættu. Hvað getur farið úrskeiðis, hverjar eru líkurnar á að það fari úrskeiðis og hver munu áhrifin hafa á notandann eða fyrirtækið ef það fór úrskeiðis?

Ef þú ert að vinna með „Test Automation“ skaltu ekki nota Selen til að prófa virkni APIs eða UI íhluta. Notaðu í staðinn Selen til að gera aðeins handfylli af gagnlegum og viðskiptalegum atburðarás sjálfvirkan til að veita traust á viðskiptasamfellu fyrir hverja útgáfu.

Og að síðustu, í hvert skipti sem þú eyðir sjálfvirkri „prófun“, hugsaðu þá tíma sem þú ert að eyða með því að prófa ekki!

Frekari lestur: