Algemiene misferstannen foar testautomatisaasje

Yn dit artikel sille wy guon fan 'e meast foarkommende misferstannen fan testautomatisaasje ûndersykje en hoe't dizze foarkomme dat organisaasjes slagje yn testautomatisaasje.

It is net dreech om de foardielen foar te stellen fan automatyske testen neist produktûntwikkeling - rappere releases, ferhege testdekking, faak testútfiering, rapper feedback oan it ûntwikkelteam, om mar in pear te neamen, doch hawwe in protte organisaasjes de stap net makke of binne resistint yn ynvestearjen yn testautomatisaasje.



Test Automatisearring Misferstannen

Mooglik is it heulste en útdaagjendste aspekt fan elke testautomatisaasje besykje de beheiningen fan automatisearre testen te begripen en realistyske doelen en ferwachtingen yn te stellen om teloarstellingen te foarkommen. Mei dat yn gedachten, litte wy guon fan 'e meast foarkommende misferstannen en myten oer testautomaasje sjen:


Automatisearre testen is better dan hânmjittich testen

Ferwizend nei de blogpost fan Michael Bolton Testen tsjin kontrolearje , automatisearre testen is net echt testen. It is kontrolearjen fan feiten. As wy ferstân hawwe fan it systeem, kinne wy ​​dat begryp twinge yn foarmen fan kontrôles en dan troch de automatyske kontrôles út te fieren, befestigje wy ús begryp. Testen, oan 'e oare kant, is in ûndersyksoefening wêr't wy fan doel binne nije ynformaasje te krijen oer it systeem dat test wurdt fia eksploraasje.

Testen fereasket in minske in sûn oardiel te meitsjen oer de brûkberens fan it systeem. Wy kinne anomalies fine as wy net ferwachte. Wy moatte net linich wêze tsjin it ien of it oare, om't beide metoaden ferplicht binne om ynsjoch te krijen yn 'e kwaliteit fan' e applikaasje.


Berikke 100% automatisearre testen

Krekt as d'r gjin praktyske manier is om 100% testdekking te berikken (troch einleaze mooglike permutaasjes), jildt itselde foar testautomatisaasje. Wy kinne testdekking ferheegje troch automatyske tests te fieren mei mear gegevens, mear konfiguraasjes, in heul ferskaat oan bestjoeringssystemen, browsers, mar it berikken fan 100% is noch in unrealistysk doel. As it giet om automatisearre testen betsjutte mear tests net needsaaklikerwize bettere kwaliteit as better fertrouwen. It hinget allegear ôf fan hoe goed in test is ûntwurpen. Yn stee fan te stribjen nei folsleine dekking ynstee, rjochtsje jo jo op it wichtichste funksjoneel gebiet dat krúsjaal is foar it bedriuw.

Fluch ROI

By it ymplementearjen fan in oplossing foar testautomatisaasje binne d'r oare ûnderling relatearre ûntwikkelingsaktiviteiten dan allinich skripttestgefallen. Normaal moat in kader ûntwikkele wurde dat op maat operearen kinne stypje dy't nuttich en sinfol binne foar it bedriuw, lykas seleksje fan testkas, rapportaazjes, datastjoerd, ensfh.

De ûntwikkeling fan it kader is in projekt op himsels en fereasket betûfte ûntwikkelers en nimt tiid om te bouwen. Sels as in folslein funksjoneel kader is te plak, duorret skripting automatyske kontrôles yn earste ynstânsje langer dan deselde test mei de hân útfiere. Dêrom as wy rappe feedback nedich binne oer de nije funksje dy't krekt ûntwikkele is, is it manuell kontrolearjen normaal rapper dan de test automatisearje. De ROI wurdt lykwols op 'e lange termyn weromjûn as wy deselde tests mei regelmjittige yntervallen moatte útfiere.

Heger taryf fan opspoaren fan defekten fia automatyske kontrôles

Hoewol in protte fan 'e troch leveransier levere en thúsbrouwen testautomatisearingsoplossingen binne heul ferfine en heul yn steat om komplekse operaasjes út te fieren, sille se nea kinne konkurrearje mei de yntelliginsje fan in minsklike tester dy't ûnferwachte anomalies yn' e applikaasje kinne besjen by it ûndersiikjen of in set skripttests útfiere tsjin it systeem dat test wurdt. Iroanysk ferwachtsje minsken dat automatyske testen in soad bugs sille fine fanwegen sabeare ferhege testdekking, mar yn werklikheid is dit net it gefal.


Wier, automatyske tests binne goed by it fangen fan regressionproblemen - nei't in nije funksje is tafoege oan besteande koadebasis, moatte wy derfoar soargje dat wy de hjoeddeistige funksjonaliteit net hawwe brutsen en wy hawwe dizze ynformaasje fluch nedich - mar it oantal regressionproblemen, yn 'e measte gefallen hat de oanstriid folle minder te wêzen dan nije funksjonaliteit dy't wurdt ûntwikkele.

In oar punt om yn gedachten te hâlden is dat de automatyske kontrôles allinich kontrolearje wat se binne programmearre om te kontrolearjen troch de persoan dy't it skript skreau. De skripts binne like goed as de persoan dy't se skreau. Alle automatyske kontrôles koenen lokkich trochgean, mar grutte gebreken kinne net opmurken wurde, wat in falske yndruk kinne jaan fan 'e kwaliteit fan it produkt. Yn essinsje kin kontrôle it bestean fan defekten bewize, mar it kin har ôfwêzigens net bewize.

Wy fereaskje allinich ienheidstestautomatisaasje

Dus, as de wikseling fan defekten grutter is by it testen fan nije funksjes, wêrom rinne wy ​​dan net ús automatyske tests tsjin de nije funksjonaliteit sa't it wurdt ûntwikkele? No, dit is wat it gefal foar teams dy't oefenje TDD ,

De ûntwikkelders skriuwe earst in ienheidstest, sjogge it mislearje en skriuwe dan genôch koade om de ienheidstest troch te krijen en de syklus wurdt werhelle oant de beëage funksjonaliteit wurdt levere. Yn essinsje kontrolearje dizze automatyske ienheidstests nije funksjonaliteit en yn 'e rin fan' e tiid foarmje se it regressionpakket foar ienheden dat werhelle wurdt útfierd as nije funksjonaliteit wurdt levere.


Mar, hjir is in behertiging oan. Wylst TDD tige oanmoedige is en in sterke ûntwikkelingspraktyk is yn it bouwen fan kwaliteit fanôf grûngebiet, binne ienheidstests allinich goed by it finen fan fouten fan programmeurs, net mislearrings. D'r is in folle grutter aspekt fan testen dat bart as alle komponinten byinoar binne bûn en in systeem foarmje.

Eins hawwe in protte organisaasjes de mearderheid fan har automatyske kontrôles by de systeem UI-laach. Skripting automatyske kontrôles foar de UI of it systeem, wylst de funksjes wurde ûntwikkele, is lykwols op syn bêst in ôfgryslike taak, om't de nije funksjonaliteit yn 'e ûntwikkeling flechtich is (ûnderwerp fan in soad feroaringen). Ek kin de ferwachte funksjonaliteit pas letter bekend wêze, dus tiid trochbringe om in feroarjende funksjonaliteit te automatisearjen wurdt net oanmoedige.

Wy fereaskje allinich systeem-UI-automatisearring

D'r binne wearden yn it útfieren fan automatyske kontrôles op UI en systeemnivo. Wy krije te sjen wat de brûker ûnderfynt by ynteraksje mei de applikaasje; wy kinne ein-oan-ein streamingen en 3 testenrdpartijyntegraasje doe't wy oars net koene testen; wy kinne de tests ek demonstrearje oan kliïnten en ein-brûkers, sadat se in gefoel krije kinne fan testdekking. It allinich fertrouwe op 'e automatyske kontrôles by de UI-laach hat lykwols syn eigen problemen.

UI feroaret konstant om fisueel ûntwerp en brûkberens te ferbetterjen en automatyske kontrôles te falen troch de UI-feroaringen en net feroaringen yn 'e funksjonaliteit kinne in falske yndruk jaan fan' e tastân fan 'e applikaasje.


UI automatyske kontrôles binne ek folle stadiger yn 'e snelheid fan útfiering dan by ienheid as API-laach en dêrom is de feedback-loop nei it team stadich. It kin in pear oeren duorje foardat in defekt wurdt sjoen en rapporteare oan 'e ûntwikkelders. En as der wat mis giet, duorret de analyse fan 'e oarsaak langer, om't it net maklik dúdlik is wêr't de flater is.

It begripen fan 'e kontekst fan elke test en op hokker laach de test automatysk moat wurde is wichtich. Testautomatisaasje moat diel útmeitsje fan 'e ûntwikkelingsaktiviteit, dus it heule team is ferantwurdlik foar testautomatisaasje, mei ûntwikkelers dy't ienheidstests skriuwe, Software-ûntwikkelders yn test-skriuwen dy't akseptaasjetests útfiere en ûnderhâlde by API en / of UI.

Leauwe en fertrouwen ferlieze yn testautomatisaasje

Dizze lêste is gjin myte oer testautomatisaasje, mar in side-effekt as testautomaasje ferkeard giet. Jo besteegje in protte oeren oan it ûntwikkeljen fan in perfekte testautomatisearingsoplossing, mei de bêste ark en best practices, mar as de automatyske kontrôles it team net helpe, is it weardeleas.

As it team gjin sichtberens of kennis hat oer wat automatysk is en útfiert, freegje se of mei eangst foar ûnbekend of duplisearje har ynspanningen foar regressionstests. As de automatyske kontrôles flakkerich, stadich binne, intermitterende resultaten jouwe, dan kin it it team mear betiizje dan it leverjen fan in feiligensnet en in fertrouwensbooster.


Wês net bang foar it fuortheljen fan automatyske kontrôles dy't altyd falle of inkonsistente resultaten jouwe. Doel ynstee foar in skjinne en betroubere suite fan tests dy't krekte oanwizings kinne jaan foar de sûnens fan 'e applikaasje.



Konklúzje

Testautomatisaasje is in lange termyn ynvestearring. It sil tiid en saakkundigens nimme by it ûntwikkeljen en ûnderhâlden fan kaders foar automatisearring fan testen en automatyske skripts. Testautomatisaasje is gjin ienmalige ynspanning wêr't jo in oplossing leverje en litte rinne. It hat konstante kontrôle en aktualisaasje nedich.

Ynstee fan fan doel manuele QA's te ferfangen of te ferwachtsjen dat de automatyske kontrôles in soad mankeminten fine, moatte wy ynstee de foardielen omearmje dy't it foar it team bringt, lykas QA's tiid befrijje foar mear ferkennend testen wêr't kânsen op it iepenbierjen fan defekten maksimale wurde, of automatysk brûke skripts om testgegevens te meitsjen dy't kinne wurde brûkt foar hantliedingstests.

Begripen fan de beheiningen en it ynstellen fan realistyske ferwachtingen is wichtich by it oerwinnen fan dizze myten fan testautomatisaasje.