Algengar ranghugmyndir um sjálfvirkni prófana

Í þessari grein munum við skoða nokkrar af algengustu ranghugmyndum um prófun sjálfvirkni og hvernig þær koma í veg fyrir að stofnanir nái árangri í sjálfvirkni tilrauna.

Það er ekki erfitt að ímynda sér ávinninginn af því að hafa sjálfvirka prófun samhliða vöruþróun - hraðari útgáfur, aukin prófþekja, tíðar framkvæmdir á prófunum, hraðari endurgjöf til þróunarteymisins, bara svo eitthvað sé nefnt, en samt hafa mörg samtök ekki lagt af stað eða eru þola að fjárfesta í sjálfvirkni prófa.

Prófaðu rangfærslur um sjálfvirkni

Hugsanlega erfiðasti og krefjandi þátturinn í allri sjálfvirkni prófa er að skilja takmarkanir sjálfvirkra prófana og setja sér raunhæf markmið og væntingar til að forðast vonbrigði. Með það í huga skulum við sjá nokkrar af algengustu misskilningi og goðsögnum um sjálfvirkni prófa:

Sjálfvirk prófun er betri en handprófun

Með vísan til bloggfærslu Michael Bolton Prófun vs Athugun , sjálfvirkar prófanir eru ekki raunverulega prófanir. Það er að kanna staðreyndir. Þegar við höfum skilning á kerfinu getum við framfylgt þeim skilningi í formi athugana og síðan með því að keyra sjálfvirku athuganirnar staðfestum við skilning okkar. Prófun er hins vegar rannsóknaræfing þar sem við stefnum að því að fá nýjar upplýsingar um kerfið sem verið er að prófa með könnun.

Prófanir krefjast þess að manneskja meti góðan dóm um notagildi kerfisins. Við getum komið auga á frávik þegar við vorum ekki að spá. Við ættum ekki að vera hógvær gagnvart einum eða öðrum, þar sem báðar aðferðir eru nauðsynlegar til að fá innsýn í gæði forritsins.

Ná 100% sjálfvirkri prófun

Rétt eins og það er engin hagnýt leið til að ná 100% prófumfjöllun (vegna endalausra mögulegra umbreytinga), þá á það sama við um sjálfvirkni prófa. Við getum aukið prófþekju með því að keyra sjálfvirkar prófanir með fleiri gögnum, fleiri stillingum, ná yfir allt úrval stýrikerfa, vafra, en að ná 100% er enn óraunhæft markmið. Þegar kemur að sjálfvirkri prófun þýða fleiri próf ekki endilega betri gæði eða betra sjálfstraust. Það veltur allt á því hve gott próf er hannað. Frekar en að stefna að fullri umfjöllun í staðinn, leggðu áherslu á mikilvægasta svið virkni sem skiptir sköpum fyrir fyrirtækið.

Fljótur arðsemi

Þegar verið er að framkvæma sjálfvirkni prófunar eru aðrar tengdar þróunaraðgerðir en bara tilraunir til handrita. Venjulega þarf að þróa umgjörð sem getur stutt við sérsniðnar aðgerðir sem eru gagnlegar og þroskandi fyrir fyrirtækið, svo sem val á prófdæmum, skýrslugerð, gagnastýrð o.s.frv.

Þróun rammans er verkefni út af fyrir sig og krefst hæfra verktaka og tekur tíma að byggja upp. Jafnvel þegar fullkominn hagnýtur rammi er til staðar tekur sjálfkrafa eftirlit upphaflega lengri tíma en að framkvæma sömu próf handvirkt. Þess vegna, þegar við þurfum fljótleg viðbrögð við nýja eiginleikanum sem er nýbúinn að þróa, er yfirleitt fljótlegra að athuga það handvirkt en að gera prófið sjálfvirkt. Hins vegar er arðsemi skilað til lengri tíma litið þegar við þurfum að framkvæma sömu prófanir með reglulegu millibili.

Hærra hlutfall skynjunar galla með sjálfvirkum athugunum

Þrátt fyrir að margar af seljanda og heimabrugguðum prófunar sjálfvirkni lausnum séu mjög háþróaðar og mjög færar í að framkvæma flóknar aðgerðir, munu þeir aldrei geta keppt við greind mannprófara sem getur komið auga á óvæntar frávik í forritinu meðan þeir kanna eða framkvæma sett af forskriftarprófum gegn kerfinu sem verið er að prófa. Það er kaldhæðnislegt að fólk býst við að sjálfvirk próf muni finna fullt af galla vegna meintrar aukinnar prófumfjöllunar, en í raun er þetta ekki raunin.

Satt er að sjálfvirk próf eru góð til að ná afturhvarfsmálum - eftir að nýjum eiginleika hefur verið bætt við núverandi kóðagrunn verðum við að tryggja að við höfum ekki brotið núverandi virkni og við þurfum þessar upplýsingar hratt - en fjöldi aðhvarfsmála, í flestum tilfellum hefur tilhneigingu til að vera mun minna en ný virkni sem verið er að þróa.

Annað sem þarf að hafa í huga er að sjálfvirku athuganirnar athuga aðeins það sem þær hafa verið forritaðar til að kanna af þeim sem skrifaði handritið. Handritin eru eins góð og sá sem skrifaði þau. Allar sjálfvirkar athuganir gætu hamingjusamlega staðist en stórir gallar geta farið framhjá neinum sem geta gefið ranga mynd af gæðum vörunnar. Í grunninn getur athugun sannað tilvist galla en það getur ekki sannað fjarveru þeirra.

Við þurfum aðeins sjálfvirkni prófunar eininga

Svo, ef líkurnar á að finna galla séu meiri við að prófa nýja eiginleika, hvers vegna erum við ekki að keyra sjálfvirku prófin okkar á móti nýju virkni eins og hún er í þróun? Jæja, þetta á nokkuð við um lið sem æfa TDD .

Hönnuðirnir skrifa einingapróf fyrst, horfa á það mistakast og skrifa síðan nóg kóða til að fá einingaprófið og hringrásin er endurtekin þar til ætluð virkni er skilað. Í raun eru þessar sjálfvirku einingaprófanir að athuga nýja virkni og með tímanum mynda þær aðhvarfspakka eininga sem er framkvæmdur ítrekað þegar ný virkni er afhent.

En það er fyrirvari við þetta. Þótt TDD sé mjög hvatt og er mikil þróun í byggingargæðum frá grunni eru einingapróf aðeins góð til að finna forritavillur en ekki bilanir. Það er miklu stærri þáttur í prófunum sem gerist þegar allir íhlutirnir eru bundnir saman og mynda kerfi.

Reyndar hafa mörg samtök meirihluta sjálfvirkra athugana sinna í kerfishnitlaginu. Hins vegar er sjálfvirkt eftirlit með handritum fyrir notendaviðmótið eða kerfið, meðan eiginleikarnir eru í þróun, í besta falli skelfilegt verkefni, þar sem nýja virkni hefur tilhneigingu til að vera sveiflukennd (háð mörgum breytingum) meðan á þróun stendur. Einnig gæti búist við að virkni sé ekki þekkt fyrr en seinna og því er ekki hvatt til að eyða tíma í að gera sjálfvirkan breyting á virkni.

Við þurfum eingöngu sjálfvirkni kerfishönnunar

Það eru gildi í því að keyra sjálfvirkar athuganir á HÍ og kerfisstigi. Við fáum að sjá hvað notandinn upplifir þegar hann hefur samskipti við forritið; við getum prófað end-to-end flow og 3rdflokksaðlögun þegar við gátum ekki prófað annað; við getum líka sýnt prófunum fyrir viðskiptavinum og notendum svo þeir geti fundið fyrir prófumfjöllun. Að treysta eingöngu á sjálfvirku eftirlitið í HÍ laginu hefur þó sín vandamál.

HÍ er stöðugt að breytast til að auka sjónræna hönnun og notagildi og að sjálfvirkar athuganir mistakist vegna breytinga á HÍ og ekki breytingar á virkni geta gefið ranga mynd af stöðu forritsins.

Sjálfvirk athugun HÍ er einnig mun hægari í framkvæmdarhraða en í einingu eða API lagi og vegna þessa er endurgjöfin til liðsins hæg. Það gæti tekið nokkrar klukkustundir áður en galli verður vart og tilkynntur til verktakanna. Og þegar eitthvað fer úrskeiðis tekur rótargreiningin lengri tíma vegna þess að það er ekki auðvelt að sjá hvar gallinn er.

Það er mikilvægt að skilja samhengi hvers prófs og við hvaða lag prófið ætti að vera sjálfvirkt. Sjálfvirkni prófa ætti að vera hluti af þróunarstarfseminni, þannig að allt teymið er ábyrgt fyrir sjálfvirkni prófa, þar sem verktaki skrifar framkvæmd einingaprófa, Hugbúnaðarhönnuðir í prófunarskrifum framkvæma og viðhalda staðfestingarprófum í API og / eða HÍ.

Að missa trúna og treysta á sjálfvirkni tilrauna

Þessi síðasta er ekki goðsögn um sjálfvirkni prófa heldur aukaverkun þegar sjálfvirkni tilrauna fer úrskeiðis. Þú eyðir mörgum klukkustundum í að þróa fullkomna próf sjálfvirkni lausn, með því að nota bestu verkfæri og bestu starfshætti, en ef sjálfvirku eftirlitið hjálpar ekki liðinu er það einskis virði.

Ef teymið hefur hvorki sýnileika né þekkingu á því sem er sjálfvirkt og framkvæmd, sleppa þeir annað hvort með ótta við óþekkt eða tvöfalda viðleitni til að prófa afturför. Ef sjálfvirku athuganirnar eru flökandi, hægar, skila árangri með hléum getur það ruglað liðið meira en að veita öryggisnet og sjálfstraust hvatningu.

Ekki vera hræddur við að fjarlægja sjálfvirkar athuganir sem eru alltaf að mistakast eða skila ósamræmi. Í staðinn skaltu stefna að hreinum og áreiðanlegum prófapakka sem getur gefið réttar vísbendingar um heilsufar forritsins.

Niðurstaða

Test Automation er langtímafjárfesting. Það mun taka tíma og sérþekkingu við að þróa og viðhalda ramma um sjálfvirkni prófana og sjálfvirk handrit. Sjálfvirkni í prófunum er ekki einskipting þar sem þú skilar lausn og lætur hana ganga. Það þarf stöðugt eftirlit og uppfærslu.

Frekar en að stefna að því að skipta um handvirka QA eða búast við að sjálfvirku eftirlitið finni fullt af göllum, ættum við í staðinn að taka á móti þeim kostum sem það hefur í för með sér fyrir liðið, svo sem að frelsa tíma QA fyrir meira rannsóknarpróf þar sem líkurnar á að afhjúpa galla eru hámarkaðar eða nota sjálfvirkan forskriftir til að búa til prófunargögn sem hægt er að nota við handprófanir.

Að skilja takmarkanir og setja raunhæfar væntingar er mikilvægt til að vinna bug á þessum goðsögnum um sjálfvirkni prófa.