Testování aplikací bývalo technicky náročnou, časově omezenou aktivitou naplánovanou několik dní nebo týdnů před vydáním aplikace. Vývojové týmy dostaly prostor pro kódování až do jedenácté hodiny a testeři, kteří prováděli většinu své práce ručně, neměli jinou možnost, než si vystačit s trochou času, který jim byl dán. Výsledkem bylo, že mnoho aplikací prošlo nestandardním testováním a technologické týmy byly nuceny reagovat na problémy s produkcí a závady eskalované koncovými uživateli a systémy monitorování aplikací.
Devops kontinuální integrační postupy, rámce testování jednotek a postupy automatizace testů toto paradigma vylepšily. Místo provádění kontroly kvality na konci vývojového procesu nyní začíná mnoho testovacích postupů a plně se provádí během kódování, integrace a nasazení. Devops a agilní týmy automatizují testovací skripty a kanály CI / CD volají ke spuštění testů během fází integrace kódu nebo doručování. Čistým výsledkem je, že vývojáři jsou upozorněni, když změny jejich kódu rozbijí sestavení, a mohou podniknout okamžité kroky k řešení nahlášeného problému.
Automatizace testování a integrace testovacích skriptů do kanálů CI / CD se označuje jako testování posunem doleva. Znamená to, že ve fázi vývoje lze provést více postupů zajišťování kvality, aby se problémy zachytily dříve na časové ose vydání. Automatizace testování je jednou z priorit před nasazením pro agilní a vývojové týmy, které chtějí zvýšit frekvenci nasazení.
Při zavedení nové funkcionality vytvořené testovací skripty ověřují nové funkce. Tyto testy lze poté automatizovat a zahrnout do kroků sestavení nebo nasazení. Místo toho, aby inženýři QA spouštěli regresní testy na konci procesu vydání, můžete spustit a ověřit mnoho z těchto testů jako součást vývoje. Tyto testy se posunou doleva z konce procesu vydání do dřívějších fází vývoje a kódování.
Testování vlevo a vlevo umožňuje závazek agilních týmů ke kvalitě
Testování vlevo a dole posouvá nejen účinnost a zlepšuje kvalitu, ale také vytváří významnou změnu kultury v agilním procesu vývoje.
Některé vývojové týmy vnímají zajišťování kvality a testování jako překážku při doručování jejich kódu do výroby. Po celé tvrdé práci při uspokojování agilních vlastníků produktů a dokončení kódu identifikují QA týmoví spolupracovníci seznam chyb vyžadujících nápravu. Pokud QA najde spoustu chyb, může to ovlivnit časovou osu vydání a opravit je. Ještě horší je, když významné části kódu vyžadují nové inženýrství, protože chyby odhalují problémy s logikou, zabezpečením nebo výkonem. V tomto scénáři mohou být vývojáři a inženýři QA ve stejném agilním týmu, ale nejednají jako tým.
Testování vlevo a vlevo umožňuje agilním týmům přesunout odpovědnost za kvalitu na celý tým vývojářů a testerů. Když testování běží jako součást kanálu CI / CD, poskytuje vývojářům lepší příležitost k řešení problémů s kvalitou v okamžiku, kdy pracují na příslušném kódu. Potrubí CI / CD upozorní vývojáře na neúspěšné sestavení a většina samoorganizujících se vývojových týmů vyžaduje okamžité vyřešení těchto problémů.
Testování s klávesou Shift-left také poskytuje vývojářům a technikům QA příležitost automatizovat další testování. Osvědčeným postupem je, aby se týmy rozhodly, kdo implementuje automatizaci, v závislosti na typech testů požadovaných pro vyvinutou funkčnost. Například vývojáři často zodpovídají za automatizaci testů jednotek a API, ale inženýři automatizace QA často vyvíjejí komplexní uživatelské zkušenosti a testy transakcí, které simulují vícestupňové volání API na více služeb.
Kdy použít testování řazení vlevo
Testování levou klávesou Shift funguje nejlépe pro atomové testy na více jednotkách, které mají krátké doby provedení. Je nezbytné, aby se testy prováděly automaticky v potrubí CI / CD a aby se spouštěly vždy, když vývojáři spustí sestavení, provedou se rychle a nezpomalí procesy sestavení.
Složitější a časově náročnější testy, jako jsou end-to-end testy uživatelských zkušeností, testování transakcí, analýza statického kódu a testování zabezpečení, často probíhají lépe mimo kanály CI / CD a na denní nebo častější plány. Tyto testy stále poskytují včasnou zpětnou vazbu vývojářům ohledně problémů s kvalitou, ale jsou automatizovány mimo CI / CD, aby se zabránilo zpomalení nebo zúžení sestavení.
Thomas J. Sweet, viceprezident pro IT služby ve společnosti GM Financial, se mnou sdílel své osobní postřehy o limitech strategií testování na levou směnu. Navrhuje: „Posun doleva je vždy strategie, s výjimkou provádění testování integrace u dodávek třetích stran, protože často nemáte přístup k jejich zdrojovému kódu. I když máte interní aplikace se staršími monolitickými architekturami, můžete začít prosazováním základních zásad pro odbavení, které vyžadují kontrolu kódu a kontrolu zabezpečení. Ověření by mělo být odmítnuto, pokud kontrola obsahuje základní varování a selhání. “
Jedním z možných řešení následného testování s integračními partnery je implementace virtualizace služeb. Tato technika umožňuje vývojovým týmům simulovat reakci navazujícího systému na různé vstupy. Funguje dobře, když jsou navazující systémy dobře definované. Tuto funkci umožňují nástroje od Micro Focus, Tricentis a dalších.
Rob Pociluk, vysoce zkušený manažer zajišťování kvality, je silným zastáncem testování levou směnou v agilním vývoji. "Být připraven a schopen testovat malé části kódu udržuje QA flexibilní a ve smyčce během postupu sprintu." Týmy by se měly i nadále chránit před přílišným používáním shift-left, protože můžete přijít o účel samotného kódu. “
Takže i když týmy plně využívají testování posunu doleva, existují dobré důvody, proč stále naplánovat testovací okno na sestavení dokončeného kódu, které je cílené na vydání. Zajišťuje provedení všech automatizovaných testů na konečném sestavení, ale také umožňuje naplánovat další testování, které vyžaduje plně funkční systém.
Jedním z těchto testů je UAT (uživatelské akceptační testování), kde vybraní koncoví uživatelé a odborníci na předmět ověřují a poskytují zpětnou vazbu. Některé UAT lze provést během vývoje, ale nemusí být snadné přimět lidi k častému provádění tohoto testování nebo pokud funkce není plně připravena.
Předpoklady pro strategii testování řazení vlevo
Testování Shift-left je rostoucí devopsová praxe, ale má své předpoklady a počáteční investice. Jsou vyžadovány některé základní schopnosti a postupy.
- K podpoře počtu sestavení a testů, které běží současně, je potřeba dostatečná testovací kapacita a prostředí.
- Agilní týmy vyžadují sadu nástrojů pro testování produktů, které se snadno integrují do kanálů CI / CD a nástrojů pro plánování úloh a které mohou ověřit funkčnost, kvalitu kódu, zabezpečení a výkon.
- Architekti, specialisté na infosec, vedoucí QA a další vedoucí členové organizace by měli stanovit testovací standardy a cíle na úrovni služeb, které tvoří výchozí kritéria přijetí.
- Když aplikace vyžadují vstup uživatele, testovací týmy potřebují dostatek testovacích dat a vzorů k ověření dostatečného počtu osob, případů použití a vstupních vzorů.
- Při závazku sprintu nebo dříve by scrum týmy, včetně techniků automatizace testů QA, měly stanovit strategii testování, jaké funkce se testují, jaké typy testování se implementují, jaké automatizační procesy se aktualizují a kdo testuje.
- Týmy Devops by měly měřit trvání běhů potrubí CI / CD a označovat, kdy mají kroky automatického testování dopad na produktivitu. Devops týmy často vyžadují další testovací plány mimo potrubí CI / CD k provádění dlouhodobějších testů.
- Týmy by měly pravidelně diskutovat o mezerách ve svých automatizovaných testech, zejména o validacích, které vyžadují odborníky na předmět, UAT nebo testování s partnery. Pokud agilní týmy nemohou tyto mezery vyřešit pomocí automatizace, pak by cykly vydání měly zohlednit režii, aby se snížila rizika a dokončily tyto testy.
A konečně, agilní týmy a devopsové organizace by měly pravidelně měřit a diskutovat o pokrytí svých testů. Zaměstnání testovací strategie posunu doleva nefunguje, pokud vývojové týmy a inženýři automatizace kvality ve skutečnosti neimplementují, automatizují a neintegrují dostatečné testy k zachycení problémů a řešení rizik.
Urychlení cyklů vydání nebo povolení nepřetržitého doručování bez dostatečné automatizace testů může vést k významným problémům s kvalitou, které degradují prostředí pro koncové uživatele. Agilní vývojové týmy tlačí vydání příliš často, než aby investovaly do další a lepší automatizace, místo toho řeší výrobní problémy a defekty.
