Testautomaasjestrategy foar agile projekten

Dit foarbyld foar testautomatisaasjestrategy giet út fan in trochgeand levermodel mei meardere agile teams.

Yn eardere artikels, in oerkoepeljend Agile teststrategy dokumint likegoed as hoe't jo in QA-funksje ynstelle kinne foar in agile projekt en hoe automatisearre testen ien fan 'e wichtichste items is yn' e earste opset.

Yn dit foarbyld fan 'e testautomaasjestrategy lis ik de wichtichste punten op om te beskôgjen om it measte út it testautomatisaasjebedriuw te heljen.




Executive Gearfetting

Automatiseare testen is in kearnaktiviteit fan elke agile ûntwikkelingsmetodyk. As wy nei trochgeande ynset gean, wurdt testautomatisaasje hieltyd wichtiger fanwegen it rappe feedback-antwurd dat it leveret oan it ûntwikkelteam oer de sûnens fan 'e applikaasje.

Om dizze rappe feedback te krijen, moatte automatyske tests kontinu wurde útfierd, moatte fluch wêze en testresultaten moatte konsekwint en betrouber wêze.


Om dizze te berikken, moat de mearderheid fan 'e ferifikaasjes dien wurde as diel fan' e ûntwikkeling fan nije funksjes. Mei oare wurden, ûntwikkeling en testen moatte in gearhingjende aktiviteit wêze, en kwaliteit moat fanôf it begjin 'ynbakt' wurde troch te soargjen dat wat wurdt ûntwikkele wurket en dat it besteande funksjonaliteit net hat brutsen.

Dit fereasket 'it ynvertearjen fan de testautomatisaasjepyramide' troch GUI-tests omleech te drukken dy't lang duorje om út te fieren, nei legere nivo's bgl. API-laach dy't direkt kin rinne nei ienheidstests as ûnderdiel fan 'e build om it earste nivo fan fertrouwen te leverjen.

Related:



Testautomaasjestrategy oersjoch

Foarkommen ynstee fan opspoaren - hoewol alle ynspanningen moatte wurde bestege oan it foarkommen fan 'e yntroduksje fan defekten yn' e applikaasje yn it earste plak, binne de techniken en metoaden dêrfoar bûten it berik fan dizze post. Hjir wurde de metoaden definieare om flugge opspoaren fan bugs mooglik te meitsjen as se yn it systeem wurde yntrodusearre en feedback foar ûntwikkeling.


Kwaliteit moat wurde favoryt boppe kwantiteit. Yn 'e measte gefallen is it better om mei ien funksje frij te meitsjen dy't rock solid is ynstee fan meardere funksjes dy't flak binne. As minimale útjeftekriterium soe elke nij ûntwikkele funksje gjin regressyfefekten moatte yntrodusearje.

Lykas al neamd, is rappe feedback oer de sûnens fan 'e applikaasje fan grut belang om trochgeande levering te stypjen, dêrom wurdt in proses en in meganisme formulearre wêrmei't wy rap feedback kinne krije.

Ien manier om rappe feedback te krijen is troch it oantal ienheidstests, yntegraasjetests en API-tests te ferheegjen. Dizze testen op leech nivo sille in feiligensnet leverje om derfoar te soargjen dat de koade wurket lykas bedoeld en helpt foarkomme dat mankeminten ûntkomme yn oare lagen fan testen.

Ienheidstests foarmje de basis foar testautomatisaasje op hegere nivo's.


It twadde elemint fan ferbettering is it fieren fan 'e regressionstests faker en ôfstimd op it proses fan trochgeande yntegraasje, sjoch letter. Automatisearringstest moat net sjoen wurde as in isolearre taak, mar earder as in gearhingjende aktiviteit ynbêde yn 'e SDLC.



Definysje fan regressionpakken

Automatiseare regressionstests binne de kearn fan 'e Test Automation Strategy.

Smoke Regression Pack

Regressionpakken tsjinje as ferstânkontrôle dat de applikaasje kin wurde laden en tagong. Ek moatte mar in pear wichtige senario's wurde útfierd om te soargjen dat tapassing noch funksjoneel is.

It doel fan it reekproefpakket is om de meast foar de hân lizzende problemen te fangen, lykas tapassing net laden, of in mienskiplike brûkersstream kin net wurde útfierd; om dizze reden moatte de reekproeven net langer duorje dan 5 minuten om rappe feedback te jaan yn gefal dat wat wichtichs net wurket.


It reekproefpakket rint op elke ynset en kin in mingsel wêze fan API- en / of GUI-tests.

Funksjonele regressionpakken , Dat is bedoeld om de funksjonaliteit fan 'e applikaasje yn mear detail te kontrolearjen dan de reekproef.

Meardere regressionpakken sille foar ferskate doelen bestean. As d'r meardere teams wurkje oan ferskate seksjes fan 'e applikaasje, dan moatte d'r ideaal wêze ferskate regressionpakken dy't kinne wurde rjochte op it gebiet wêr't it team oan wurket.

Dizze pakketten moatte kinne rinne yn elke omjouwing as en as dat nedich is, op betingst dat it gedrach fan 'e funksjes yn' e omjouwings konsekwint bliuwt. Se wurde meardere kearen deis útfierd en moatte net langer dan 15 oant 30 minuten duorje.


Om't dizze funksjonele tests mear detaillearre binne, sille se dêrom langer duorje om te rinnen, it is wichtich om de mearderheid fan funksjonele tests te hawwen by API-laach wêr't tests rapper kinne wurde útfierd, sadat wy binnen de 15 oant 30 minuten tiidgrins.

End-to-End regressionpak, dy't de heule applikaasje as gehiel testet. It doel fan dizze tests is om te soargjen dat ferskate dielen fan 'e applikaasje dy't ferbine mei ferskate databases en applikaasjes fan tredden goed wurkje.

De End-to-End tests binne net bedoeld om alle funksjes te testen, om't dy al binne hifke yn 'e funksjonele regressionpakken, lykwols binne dizze tests 'lichtgewicht' dy't de oergongen fan' e iene steat nei de oare gewoan kontrolearje en in hânfol fan 'e wichtichste senario's of brûkersreizen.

Dizze tests wurde benammen útfierd fia de GUI, om't se kontrolearje hoe't brûkers it systeem brûke soene. De tiid nommen om dizze út te fieren kin ferskille fan 'e iene applikaasje nei de oare, mar se wurde normaal ien kear deis as nacht útfierd.



Testautomaasjestrategy foar meardere agile teams

test_automation_strategy_agile

Automatiseare ienheidstests

Testautomatisaasje begjint op ienheidsnivo. Ienheidstests moatte wurde skreaun troch ûntwikkelders foar elke nije funksje dy't wurdt ûntwikkele. Dizze ienheidstests foarmje de basis fan in gruttere automatisaasjepraktyk dy't oerspant oant de System GUI-tests.

It is de ferantwurdlikens fan 'e ûntwikkelders om te soargjen dat foar elke nije funksje dy't wurdt ûntwikkele, in set fan gearhingjende en solide ienheidstests wurde skreaun om te bewizen dat de koade wurket lykas bedoeld en foldocht oan' e easken.

Ienheidstests leverje it measte ROI oan it team, om't se heul rap rinne, maklik te ûnderhâlden en te wizigjen (om't d'r gjin ôfhinklikheden binne) en as d'r flaters binne yn koade, wurdt it rap weromfierd nei de ûntwikkelder.

Ienheidstests wurde útfierd op 'e masjine fan' e ûntwikkelder en ek op 'e CI-omjouwing.

Automatiseare yntegraasje / API- as servicetests

Wylst ienheidstests binne basearre op it testen fan de funksjes binnen in klasse, foarmje yntegraasjetests it folgjende nivo omheech fan ienheidstests om de klassen te testen dy't it ûnderdiel kollektyf foarmje om in stik funksjonaliteit te leverjen. Dizze tests wurde allinich útfierd as de ienheidstests binne rûn en trochjûn.

Servicetests wurde natuerlik útfierd op API-laach sûnder yntervinsje fan 'e GUI-webinterface; dêrfandinne testen soene funksjonaliteit yn in suvere foarm kinne ferifiearje en om't de tests direkt mei de komponinten prate, binne se rap út te fieren en sille diel wêze fan 'e bouw.

As it nedich is, spotten lykas wiremock sil wurde brûkt om de ôfhinklikens fan oare 3 út te rekkenjenrdpartysystemen en as de streamôfwertsystemen net beskikber binne om de gegevens te leverjen dy't nedich binne foar testen.

Yntegraasje-tests en / as servicetests kinne ek wurde útfierd op 'e masjine fan' e ûntwikkelders en diel útmeitsje fan 'e bouw, mar as se in lange tiid begjinne, dan is it it bêste om te rinnen op' e CI-omjouwing.

Ark lykas SoapUI kinne brûkt wurde foar servicetests.

Applikaasjetest

In typyske e-commerce-tapassing kin wurde splitst yn ferskate applikaasjes as 'apps' dy't ferskate funksjes leverje. It konsept fan 'App Testing' is wêr't in groep tests dy't de funksjonaliteit fan in App testen tegearre binne organisearre en draait tsjin de winske App. Dit pakket sil nuttich wêze yn gefallen as in team in yndividuele app frijlitte wol en wol witte oft it goed funksjoneart.

Applikaasjetests fereaskje typysk in ynterface foar ynteraksje mei de ferskillende komponinten, dêrom wurdt ferwachte dat dizze tests wurde útfierd fia in browser op 'e GUI.

It doel fan App Testing is om te soargjen dat funksjes fan 'e applikaasje funksjoneel korrekt binne. Om't de tests op in manier binne organisearre om fertrouwen te leverjen yn 'e sûnens fan in bepaalde app, wurde dizze tests normaalwei fertikale tests neamd, om't se in bepaalde app 'down' útfiere. De tests binne heul yngeand en dekking is grut.

Selenium WebDriver koe wurde brûkt om dizze automatyske tests tsjin de browser út te fieren. Dit ark is it populêrst foar browserautomatisaasjetests en leveret in rike API om komplekse ferifikaasjes mooglik te meitsjen.

Ein-oan-ein senario testen

De automatyske GUI-tests dy't tsjin it systeem wurde útfierd, tsjinje as typyske brûkersstreamingen, reizen as ein-oan-ein-senario's. Fanwegen problemen mei dit soarte testen (hjirûnder besprutsen) wurde dizze oant in minimum beheind. De ein-oan-ein-senario's binne opnommen yn it nachtlike regressionpak.



De testautomatisaasjepyramide omkeare

As ûnderdiel fan 'e testautomaasjestrategy moatte wy derfoar soargje dat it oantal automatisearre tests dat wurdt útfierd op GUI-laach minimalisearje.

Wylst it útfieren fan automatyske tests fia de GUI goede en betsjuttende tests leveret yn termen fan simulaasje fan de ynteraksje fan in brûker mei de applikaasje, is it gefoelich foar in protte problemen lykas hjirûnder neamd:

Bros

Om't de tests fertrouwe op 'e HTML-lokators om web-eleminten te identifisearjen om mei te kommunisearjen, falle de tests, sadra't in id is feroare, dêrom drage se in soad ûnderhâldskosten.

Beheinde testen

De GUI koe de mooglikheid fan 'e tester beheine om in funksje folslein te ferifiearjen, om't de GUI miskien net alle details fan' e webreaksje befettet om ferifikaasje mooglik te meitsjen.

Stadich

Om't tests wurde útfierd fia de GUI, kinne de laden tiden fan 'e pagina de totale testtiid signifikant ferheegje en as sadanich is de feedback oan' e ûntwikkelders relatyf stadich.

Minste ROI

Fanwegen de hjirboppe neamde problemen leverje de automatyske testen fan GUI de minste ROI.

De Browser-automatisaasjetests wurde minimaal hâlden en wurde brûkt om it gedrach fan in brûker te simulearjen mei algemiene brûkersstreamingen en end-to-end-senario's wêr't it systeem as gehiel wurdt útoefene.