Jak migrovat testovací sadu bez přerušení regresního testování
Migrace testovací sady se většinou odkládá z jednoho důvodu. Ne proto, že by nebylo jasné, co je potřeba udělat – ale proto, že si nikdo netroufá na období, během kterého se netestuje.
Představa je taková: stará sada se vypne, tři měsíce se píše nová a mezitím se nasazuje naslepo. Nikdo to nechce podepsat, takže se migrace odloží na příští čtvrtletí. A tak stále dokola, dokud sada nedoslouží sama.
Takto to ale probíhat nemusí.
Běžný problém: během migrace chybí spolehlivá kontrola
Sada není jeden celek, který lze přenést pouze najednou. Je to soubor scénářů a každý z nich má jinou váhu. Nákup a platba vás živí. Ověření textu v patičce ne.
Když se na sadu podíváte tímto způsobem, přestane dávat smysl přenášet ji najednou. Lze ji přenášet po částech – a každá přenesená část začne ihned fungovat. Nemusíte čekat, až bude hotová celá.
Jak zachovat kontrolu během přenosu
Analýza a pořadí. Nejprve zjistíme, co sada reálně pokrývá. Část testů bývá mrtvá – ověřují funkci, která už neexistuje, nebo se dlouhodobě přeskakují. Ty se nepřenášejí vůbec. Zbytek seřadíme podle toho, co nejvíce bolí, když se pokazí.
Pilot na jednom scénáři. Na jedné důležité cestě ověříme architekturu nové sady a její stabilitu – ještě předtím, než se začne přenášet cokoli dalšího. Pokud něco v návrhu nesedí, zjistí se to na jednom testu, ne na dvou stech.
Postupný přenos. Postupujeme scénář po scénáři podle priority. První přenesený scénář se zapojí do pipeline hned, ne až na konci projektu. Hodnotu tak vidíte od začátku, ne až po předání.
Obě sady dočasně běží vedle sebe. Dokud přenos neskončí, stará sada může kontrolovat scénáře, které ještě nebyly přeneseny, a nová ty, které už prošly ověřením. Zachované pokrytí je třeba průběžně potvrzovat mapou scénářů, sledovat stabilitu obou sad a minimalizovat mezery. Neznamená to automaticky, že bude míra jistoty každý den migrace stejná.
Souběh je přitom užitečný i sám o sobě. Když stejný scénář běží ve staré i nové sadě a výsledky se rozcházejí, je třeba prověřit test, data, prostředí, načasování i očekávaný výsledek. Samotný rozdíl ještě neurčuje, která sada je správná.
Vypnutí staré sady. Až když je přeneseno vše podstatné a nová sada běží spolehlivě, stará se vypne. Ne dříve.
Takový postup jsme použili také při nahrazení původního automatizačního řešení, kde stará a nová sada běžely paralelně až do ověření náhrady.
Co vám postupný přenos přinese
Migraci, při které nemusíte plánovaně vypnout všechny regresní kontroly na celou dobu přenosu. Riziko zůstává řízené podle toho, které scénáře jsou ještě ve staré sadě a které už byly ověřeny v nové.
Pokud se priority změní, lze přenos po dokončení rozpracované etapy pozastavit. Přenesené a ověřené scénáře zůstanou v nové sadě, ostatní ve staré. Tým však musí udržovat přehled o vlastnictví scénářů a obou provozovaných základech.
Novou sadu navrhneme pro snazší údržbu, například s vhodnou vrstvou objektů stránek nebo komponent, stabilními identifikátory a oddělenými testovacími daty. Samotná architektura však nenahrazuje průběžnou údržbu při změnách aplikace.
Na co si dát pozor při odhadu
Doba trvání závisí na počtu a složitosti scénářů, stavu původního kódu, závislostech i připravenosti prostředí. Část zastaralých nebo duplicitních testů se nemusí přenášet, zachování dohodnutého pokrytí je však třeba potvrdit mapou scénářů.
Další krok
Ukažte nám, co dnes máte, a řekněte, které cesty mají zůstat průběžně pokryté. Napište nám – navrhneme pořadí přenosu, mapu pokrytí a způsob, jak během migrace minimalizovat mezery.