4. diel - Testovanie v priebehu SDLC po druhej - DevOps a automatizácia Nové

V predchádzajúcej lekcii, Testovanie v priebehu SDLC - Zručnosti a osvedčené postupy , sme si vysvetlili, aké sú základné zručnosti a osvedčené postupy a pozreli sme sa na testovanie v kontexte životného cyklu vývoja softvéru.

V dnešnej lekcii sa pozrieme na test-driven development, vysvetlíme si, čo je DevOps a shift-left prístup. Nakoniec si vysvetlíme retrospektívy a zlepšovanie procesov.

Metodiky testovania

Test-driven development, aceptance test-driven development a behavior-driven development sú metodiky, ktoré využívajú testy ako hlavný nástroj na riadenie vývoja. Uplatňujú princíp včasného testovania a shift-left, čo znamená, že testy sú vytvárané pred samotným písaním kódu a sú ideálne pre iterative development.

Test-driven development

Písanie kódu je riadené pomocou test časov namiesto rozsiahleho návrhu softvéru. Najprv sú spísané testy a až následne kód a to tak, aby týmto testom vyhovoval. Následne môžu byť testy a kód refaktorované. Refaktorovanie znamená úprava a zlepšenie vnútornej štruktúru kódu bez toho, aby sa zmenilo jeho správanie alebo funkčnosť. Cieľom refaktorovania je zlepšiť čitateľnosť a zrozumiteľnosť kódu, zjednodušiť údržbu a uľahčiť budúce úpravy, odstrániť duplicitné časti kódu alebo zbytočné zložitosti. Vývojár pracujúci na funkcii pre prihlásenie používateľov najskôr napíše testy, ktoré overujú, či zadanie správneho používateľského mena a hesla umožní prihlásenie. Až potom napíše samotnú funkciu tak, aby tieto testy úspešne prešli:

Acceptance test-driven development

Acceptance test-driven development odvodzuje testy z aceptance criteria (akceptačných kritérií) ako súčasť procesu návrhu systému. Daná časť aplikácie je vytvorená tak, aby vyhovovala testom napísaným pred samotným vývojom. Pred implementáciou funkcie pre správu objednávok tím najprv spíše aceptance criteria, napríklad, že používateľ musí vidieť potvrdenie objednávky. Na základe týchto kritérií sú napísané testy, ktoré overujú, že aplikácia spĺňa požiadavky, a potom je vytvorený samotný kód:

Behavior-driven development

V behavior-driven development je požadované správanie aplikácie popísané test časmi napísanými v jednoduchej forme prirodzeného jazyka zrozumiteľného pre zainteresované strany. Obvykle je využitý formát Given/When/Then - Vstup/Podmien­ka/Akcia. Test casy sú následne automaticky preložené do spustiteľných testov. Tím popíše funkciu pre výber doručenia z pohľadu používateľa, napríklad keď používateľ vyberie spôsob dopravy, zobrazí sa súhrn objednávky. Tento popis je preložený do automatizovaných testov, ktoré overujú, že systém skutočne funguje podľa týchto pravidiel:

Pre všetky vyššie uvedené prístupy môžu byť testy automatizované s cieľom podporiť kvalitu pri budúcich úpravách alebo refaktoringu.

DevOps a testovanie

DevOps je prístup k vývoju softvéru, ktorý vyžaduje úzku spoluprácu medzi vývojovými, testovacími a prevádzkovými tímami, aby spoločne dosahovali stanovené ciele. Tento prístup mení organizačnú kultúru, prekonáva bariéry medzi tímami a stavia na ich rovnocennom význame. DevOps podporuje tímovú autonómiu, rýchlu spätnú väzbu, využívanie integrovaných nástrojov a techník, ako je continuous integration - CI (priebežná integrácia) a continuous delivery - CD (priebežné dodávanie), čo umožňuje rýchlejšiu tvorbu, testovanie a nasadenie kvalitného kódu prostredníctvom DevOps pipeline:

• Continous integration (priebežná integrácia) je proces, kedy vývojári často odosielajú zmeny kódu do centrálneho úložiska, kde sú tieto zmeny automaticky zostavené a otestované. To zaisťuje, že nový kód neporušuje existujúcu funkcionalitu a problémy sú zachytené čoskoro.
• Continous delivery (priebežné dodávanie) nadväzuje na CI tým, že automatizuje nasadenie kódu do testovacieho alebo produkčného prostredia. Tento proces zaručuje, že akonáhle kód prejde všetkými testami, môže byť bezpečne nasadený do produkcie.
• DevOps pipeline kombinuje CI a CD v automatizovaný proces, ktorý zahŕňa zostavenie, testovanie, nasadenie a monitorovanie kódu. To umožňuje tímu doručovať nové funkcie či opravy rýchlo, bezpečne a bez straty kvality softvéru:

.<>

Výhody DevOps

Z pohľadu testovania má DevOps určité výhody. Poskytuje rýchlu spätnú väzbu o kvalite nového kódu ao nepriaznivom vplyve na doterajšiu funkčnosť systému alebo komponenty. Vďaka CI podporuje prístup shift-left pri testovaní tým, že motivuje vývojárov k písaniu kvalitného kódu podporovaného testovaním komponentov a static analysis (statickou analýzou). Propaguje automatizované spracovanie (napr. CI/CD), ktoré uľahčuje vytváranie stabilných testovacích prostredí. Zvyšuje dôraz na nefunkcionálne charakteristiky kvality ako je výkon alebo spoľahlivosť. Automatizáciou prostredníctvom pipeline znižuje potrebu opakovaného manuálneho testovania. Minimalizuje riziko regresie vďaka rozsahu a miere automatických regression testov.

Riziká a nevýhody DevOps

DevOps má ale aj niektoré riziká a nevýhody. Musí byť definované a zavedené DevOps pipeline. Musia byť zavedené a udržiavané nástroje CI/CD. Automatické testy vyžadujú dodatočné investície a môže byť ťažké ich vytvoriť a udržiavať.

Napriek tomu, že DevOps predpokladá vyšší rozsah automatického testovania, nemožno zabúdať ani na manuálne testovanie, a to najmä z pohľadu koncového užívateľa:

Praktický príklad

Predstavme si tím, ktorý vyvíja aplikáciu na správu skladových zásob pomocou DevOps prístupu. Vývojári pravidelne odosielajú nové verzie kódu do centrálneho úložiska. Každá zmena spúšťa automatizovanú CI/CD pipeline, ktorá zahŕňa spustenie automatizovaných testov. Pre novú funkciu, ktorá umožňuje automatické pridávanie tovaru na sklad po prijatí dodávky, tím napíše automated regression tests. Automatizované nástroje zhromažďujú údaje o výkonnosti a stabilite, ako napríklad čas odozvy pri aktualizácii zásob. Ak sa objavia problémy, tím okamžite dostane spätnú väzbu a môže vykonať opravy.

Prístup shift-left

Princíp včasného testovania, známy ako shift-left, posúva testovanie do skorších fáz SDLC. Tento prístup odporúča začať testovať čo najskôr, ale nezanedbáva význam testovania v neskorších fázach.

Existujú niektoré osvedčené postupy, na ktorých je možné demonštrovať aplikáciu tohto prístupu:

• Revidovanie špecifikácií z pohľadu testovania, ktoré nachádzajú potenciálne defekty ako sú nejednoznačnosti, neúplnosti a nezrovnalosti.
• Písanie test cases pred napísaním kódu a spustenie kódu v sade testovacieho vybavenia počas vývoja kódu.
• Používanie CI alebo lepšie CD, pretože prichádza s rýchlou spätnou väzbou a automated component tests (automatizovanými testami komponentov), ktoré sú spoločne s kódom uložené do repozitára.
• Spúšťanie static analysis zdrojového kódu pred dynamic testingom alebo ako súčasť daného automatizovaného procesu.
• Vykonávanie nefunkcionálnych testov hneď v úrovni testovania komponentov. Ide tiež o formu prístupu shift-left, pretože obvykle sú tieto typy testov vykonávané v neskorších fázach SDLC, kedy je k dispozícii kompletný systém a zodpovedajúce testovacie prostredie.

Aj keď zavedenie shift-left môže spočiatku zvýšiť náklady, napríklad na školenie tímu, v dlhodobom horizonte šetrí čas aj peniaze. Dôležité je, aby všetci zúčastnení uznávali jeho prínosy a aktívne ho podporovali.

Retrospektívy a zlepšovanie procesov

Retrospektívy, známe tiež ako po-projektové schôdzky, sa obvykle konajú na konci projektu, iterácie, míľnika alebo podľa potreby. Načasovanie závisí od modelu SDLC a účastníkmi sú testeri, vývojári, architekti, vlastníci produktov a biznisoví analytici. Hlavným cieľom retrospektívy je prebrať nasledujúce otázky:

• Čo bolo úspešné a malo by sa zachovať?
• Čo sa nepodarilo a dalo by sa zlepšiť?
• Ako implementovať návrhy na zlepšenie a zabezpečiť v budúcnosti trvalú úspešnosť?

Výstupy retrospektív by mali byť zaznamenané a zahrnuté do súhrnného reportu z testovania. Sú kľúčové pre kontinuálne zlepšovanie, a preto je dôležité ich dôsledné dodržiavanie. Medzi typické výhody retrospektív z pohľadu testovania patrí zvyšovanie efektivity a účinnosti testov, zvyšovanie kvality testwaru, stmeľovanie tímu a vzájomné učenie, zlepšovanie kvality testovacej bázy a zlepšovanie spolupráce medzi vývojom a testovaním.

Zdrojom tejto lekcie sú Učebné osnovy - Certifikovaný tester základnej úrovne ver. 4.0. Copyright © 2023 autori verzie 4.0: Renzo Cerquozzi, Wim Decouter, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michael Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (predseda) Stapp, Stephanie Ulrich (podpredseda), Eshraka Zakaria

V budúcej lekcii, Úrovne testovania , si rozlíšime rôzne úrovne testovania a rôzne typy testov a nakoniec si zhrnieme konfirmačné a regresné testovanie.