Feature toggle je konfigurační volba, která určuje, zda má být daná funkce ve vašem softwaru vykonána nebo ne. Tento koncept je také známý jako feature flags, flippers, switches, feature bits nebo latentní kód. Wrapping nových funkcí do této konfigurace umožňuje vydání kódu do produkce, aniž by byl dostupný všem uživatelům. Když je toggle vypnutý, kód v tomto toggle není aktivován. Feature toggles mohou také sloužit k skrytí kódu, který ještě není otestovaný nebo dokončený.

Důvod, proč byste chtěli umístit neotestovaný nebo nedokončený kód do produkce, je jednoduchý: v praxi se může stát, že vývojový tým dostane nový úkol na implementaci určité funkce, kterou odhaduje, že dokončí za několik týdnů. Vaše organizace však používá denní cyklus vydání, což znamená, že tým vytvoří feature branch a po dvou týdnech tento kód sloučí zpět do hlavního repozitáře. Celý kód z těchto dvou týdnů je pak okamžitě vydán do produkce. Když však používáte denní cyklus vydání, množství kódu, které se vydává najednou, je relativně velké a zvyšuje riziko. Alternativou je implementovat novou funkci postupně do denního cyklu vydání. Namísto psaní kódu a jeho vydání až po dvou týdnech, kód odesíláte do produkce každý den. Funkce může být stále dokončena za dva týdny, ale její kód je deaktivován pomocí feature toggle. Tímto způsobem je každý vydaný kód malý a snadněji zvládnutelný.

Feature toggles snižují riziko zpřístupnění nových funkcí uživatelům. Uživatelé budou mít přístup k nové funkcionalitě až po určité době, kdy byla tato funkce přítomna v produkci. Vývojový tým a obchodní uživatelé mohou testovat kód s toggle v živém prostředí, aby odhalili problémy. Pokud dojde k nějaké chybě, lze funkci jednoduše vypnout.

Feature toggles jsou často zmiňovány ve spojení s rychlým a kontinuálním vývojem softwaru. Například Google má více než 15 000 inženýrů, kteří commitují změny do jediného trunku, přičemž více než 50 % kódu se mění každý týden. Také Facebook, Amazon, Netflix a Etsy mají podobně rychlé cykly commitů. Feature toggles jsou tedy jedním z nástrojů, které umožňují firmám provádět časté změny bez výrazného rizika.

Před tím, než se rozhodnete, jak testovat toggle, je nutné nejprve porozumět tomu, jak byl implementován. Zjistěte, jaký typ toggle je použit, jaké hodnoty může mít, kolikrát je toggle v kódu zkontrolován a jaký mechanismus se používá pro změnu jeho hodnoty. Pete Hodgson identifikuje čtyři typy togglů:

  • Release toggles: umožňují vydání nedokončených a neotestovaných cest kódu do produkce.

  • Experiment toggles: používají se pro multivariantní nebo A/B testování.

  • Ops toggles: používají se k řízení operačních aspektů chování systému (např. k vypnutí méně kritických funkcí v období vysokého zatížení).

  • Permissioning toggles: mění funkce nebo produktové zkušenosti, které mají určití uživatelé (např. aktivace prémiových funkcí pro odměnu loajality zákazníků).

Každý typ togglu ovlivňuje systém jiným způsobem, a proto je důležité pochopit, kdo a jak tento toggle používá. Například boolean toggle může vyžadovat méně testování než seznam, který může obsahovat více hodnot. Zvažte, jak lze toggle nastavit – může být statický, založený na konfiguraci aplikace, nebo dynamický, založený na pravidlech.

Je nezbytné, aby toggle byly implementovány co nejjednodušeji. Martin Fowler upozorňuje na to, že toggle testy by měly být minimální a zaměřené pouze na klíčové body kódu, které vedou k aktivaci nové funkce. Pokud zjistíte, že vytvoření, údržba nebo odstranění toggle testů zabírá příliš času, znamená to, že jich máte příliš mnoho.

Testování toggle je specifické, protože s jedním toggle se vám může vyplatit testovat pouze několik konfigurací, nikoliv všechny možné kombinace. Například je důležité testovat konfiguraci, která by měla být aktivní v produkci, tedy aktuální produkční konfiguraci plus jakékoli toggle, které mají být zapnuté. Také je užitečné testovat záložní konfiguraci, kde jsou toggles vypnuté.

Ve chvíli, kdy máte více toggle, může to vést k explozivnímu nárůstu počtu kombinací, které je potřeba otestovat. To může být výzvou pro týmy, které se zaměřují na testování, avšak většina feature toggle nebude vzájemně interagovat, a většina vydání nebude mít více než jednu změnu v konfiguraci. Důležité je, že byste měli testovat konfigurace, které se skutečně dostanou do produkce.

Také je nutné mít na paměti, že feature toggle není pouze nástrojem pro vývojáře, ale je to i nástroj pro celkovou správu rizik a postupné zavádění nových funkcí do produkce. Použití toggle může zásadně zlepšit stabilitu a rychlost nasazení nových verzí, ale vyžaduje pečlivé plánování a správu. Veškeré změny by měly být dobře dokumentovány, aby bylo možné snadno sledovat, jaké funkce jsou aktivní a kdy byly přidány nebo deaktivovány.

Jaké faktory ovlivňují změny v týmu testování a jaké mají důsledky pro kvalitu softwaru?

Změny v týmech testování v rámci vývoje softwaru nejsou nikdy jednoduché a mohou mít dalekosáhlé důsledky pro celkové fungování organizace, její kulturu i pro samotnou kvalitu výsledného produktu. Je důležité zvážit několik klíčových aspektů, které ovlivní, jak taková změna probíhá a jaký bude její dopad. Mezi tyto faktory patří kontext mimo samotný tým, podpora pro kvalitu, dynamika týmu, měření úspěšnosti změn a přítomnost biasu, který může zkreslit výsledky rozhodování.

Kontext mimo tým

Před jakoukoliv změnou je nezbytné zvážit širší kontext, který ovlivní, jak bude změna přijata. Měníte tým v důsledku růstu společnosti? Je změna odpovědí na změny v povaze práce nebo je zaměřena na zlepšení zdraví kódu? Jaký bude dlouhodobý dopad této změny na tým a jeho okolí? Tyto faktory mohou výrazně ovlivnit, jak zaměstnanci reagují a jak se přizpůsobí novým podmínkám. Zvlášť pokud jde o testování, kde může být klíčové, zda tým je připravený na určité změny v rámci testovacích procesů. Je důležité vědět, zda změna týmu bude mít podporu z ostatních týmů a jak se na ni dívají rozhodující osoby, například ti, kteří schvalují změny v produkci.

Podpora pro kvalitu

Kvalita produktu nevzniká pouze díky testování. Existuje celá řada aktivit, které přispívají k vytváření kvalitního softwaru. Představitelé týmu by měli přemýšlet o tom, jaké procesy a praktiky podporují kvalitu v rámci týmu. Jaký je stav automatizovaných testů? Jsou tyto testy pravidelně prováděny, udržovány a aktivně integrovány do vývojového cyklu? Dále je důležité zhodnotit, jaké další aktivity přispívají k kvalitě, jako jsou pair programming, revize kódu, kontinuální integrace nebo sledování produkce. Ačkoli to nejsou přímo testovací aktivity, mají přímý vliv na celkovou kvalitu produktu. Kromě toho je třeba se zaměřit na to, jaký vliv bude mít změna na interakce uvnitř týmu a jaký bude důraz na produktovou znalost a zákaznický přístup.

Dynamika týmu

Zmínka o tom, že změna týmu znamená více než jen odebrání testera, ale v podstatě odebrání osoby s jedinečnými schopnostmi, ukazuje na důležitost personálních aspektů změny. Jaká je aktuální dynamika týmu? Odebíráte jediného testera nebo role testování zaniká jako taková? Pokud se tester přesouvá do jiného týmu, jaké to bude mít důsledky pro tým, do kterého se přesouvá? Jak budou jeho dovednosti odpovídat novému prostředí a jaký dopad to bude mít na produktivitu a efektivitu týmu, ve kterém bude působit? Zároveň je třeba přemýšlet o tom, jak změna ovlivní tým, který testera opustí – jak se tým přizpůsobí absenci testování a co bude třeba udělat pro zajištění odpovídající kvality.

Měření a sledování úspěšnosti

Každá změna, ať už v rámci testovacího týmu nebo širšího vývojového procesu, by měla být podpořena metrikami, které umožní posoudit její úspěšnost. Jakým způsobem měříme kvalitu produktu? Jaké metriky používáme pro měření úspěšnosti testování a jak určujeme, kdy je kvalita dostatečná? Jaké metriky sledují zdraví týmu? Pokles produktivity nebo morálky může mít vážné důsledky pro celé oddělení, a je nutné mít nastavený systém, který nám pomůže včas identifikovat problémy.

Bias a zaujímání různých perspektiv

Posledním, ale neméně důležitým faktorem, který je třeba zvážit při rozhodování o změnách v týmu, je bias, tedy osobní zkreslení názorů a rozhodování. Manažer, který není přímo zapojen do každodenní práce týmu, může mít jiný pohled na důsledky změny než samotní členové týmu. Důležité je, aby všechny zúčastněné strany, včetně testera, který změnu zažívá, měly možnost vyjádřit své názory a obavy. Tento proces by měl být kolektivní a zahrnovat všechny relevantní hlasy, aby rozhodnutí bylo co nejvíce objektivní a zohlednilo všechny potenciální dopady.

Dokumentace a sdílení strategie

V prostředí DevOps, kde je testování považováno za kolektivní úkol, by měla být strategie testování spíše součástí širší komunikace než jednostranným dokumentem. Historicky byla strategie testování podrobně dokumentována, aby informovala ostatní o rozsahu a pokrytí testování. V moderním vývojovém prostředí však je mnohem efektivnější zaměřit se na vytváření společného porozumění mezi všemi členy týmu, než na vytváření komplexních a rychle zastarávajících dokumentů. Místo dlouhých textů by měla vzniknout vizuální prezentace, která zachytí klíčové diskuse a společné porozumění, které vzniklo mezi jednotlivými účastníky.

Endtext

Jak vytvářet silné komunikační cesty mezi týmy a disciplínami

Cesty, které vytváříme, jsou na začátku křehké, protože jsou formovány mezi dvěma jednotlivci. Pokud by někdo z jedné strany odešel, cesta by byla zcela přerušena. Další kroky v budování cesty však tuto spojitost zpevňují tím, že do ní zapojují další osoby a směrují ji k vícekolaborativní výměně informací mezi různými disciplínami. Cílem je rozšířit publikum pro sdílení znalostí a tím umožnit lepší porozumění mezi jednotlivými týmy. Po navázání vztahu s jednou osobou v týmu, kdy jste jí předali něco užitečného, můžete uspořádat sezení, kde stejné informace budete sdílet i s jejími kolegy. Pokud oni sdílí něco hodnotného s vámi, požádejte je, aby uspořádali podobné setkání pro váš tým. Místo pro tuto výměnu by mělo být označeno, aby si každý mohl najít vlastní cestu. Tento přístup pomůže nejen aktuálním členům týmu, ale i těm, kteří se k týmu připojí v budoucnu, a rovněž zájemcům z jiných týmů.

Důležité je také zaznamenávat předávané znalosti, aby k nim bylo možné v budoucnu přistupovat. Může to být jednoduché ukládání prezentací do sdílené složky, nebo videozáznamy z přednášek a školení, které zachytí jak vizuální, tak verbální prvky sdílené informace. Ti, kdo mají více času, mohou vytvořit vzdělávací materiály navržené pro samostatnou konzumaci, jako například ucelené vzdělávací trasy, online kurzy nebo knihy.

Dalším krokem je širší pozvání různých perspektiv k účasti na této cestě. V rámci organizace to může zahrnovat: pozvání jiných k prezentování jejich znalostí, zapojení odborníků z jiných disciplín do peer review nebo debriefingových aktivit, párování odborníků z různých oblastí, nebo mezitýmovou spolupráci na úkolech prostřednictvím mobbingu. Cestu lze dále rozšířit i pozváním lidí na průmyslové prezentace nebo konference zaměřené na oblasti mimo jejich obvyklou disciplínu.

Základní kroky pro vytvoření silné komunikační cesty lze shrnout jako identifikovat, spojit, pozvat, označit a rozšířit.

Když aplikujeme teorii komunikačních cest na vytváření vztahů mezi týmy a disciplínami v oblasti testování, je prvním krokem identifikace. Začněte přemýšlet o osobách, které znáte a které pracují v oblastech jako je provoz, podpora, business intelligence, analytika nebo call centrum – jakýchkoli odděleních, která mají nějaký vztah k tomu, co vaše vývojová tým dodává. Tato aktivita vám může ukázat vaše stávající profesní sítě. Pokud máte problém vzpomenout si na jména, máte buď špatnou paměť, nebo je třeba více pracovat na rozšiřování vaší sítě. Požádejte svůj tým nebo manažera, aby vám pomohli seznam rozšířit. V rozsáhlé organizaci si můžete prohlédnout firemní adresář nebo diagramy struktury, abyste našli lidi, jejichž pracovní pozice by vás mohla zajímat. Netřeba se bát hodně rozšířit okruh. Jakmile začnete mluvit s lidmi, přirozeně se začne filtrovat, které cesty vám nabídnou největší příležitosti.

Druhým krokem je spojení. Jakmile máte svůj seznam, pokuste se navázat kontakt s každou z těchto osob individuálně. Pokud máte štěstí, může se na seznamu objevit někdo, s kým už máte dobrý vztah – bývalý kolega, přítel, nebo někdo, s kým se setkáváte mimo pracovní prostředí. Pokud nemáte s některou osobou přímou interakci, stačí začít několika obecným dotazem: Co děláte každý den? Jaké nástroje používáte? S kým se nejčastěji setkáváte? Co víte o mé roli? Jak si myslíte, že bych vám mohl pomoci? Tento přístup může působit trochu neobvykle, ale otázky mohou sloužit jako katalyzátor pro navázání vztahu.

Zajímavým způsobem, jak navázat kontakt, je i změna způsobu, jakým popisujeme svou práci ostatním. Pokud například v agilních prostředích neexistuje dostatečná transparentnost, může být užitečné být konkrétní při popisu toho, co vlastně děláte. Například místo obecného tvrzení: „Testuji tuto funkcionalitu,“ je lepší říci: „Testuji příběh 19574 a ověřuji, zda splňuje všechny akceptační kritéria.“ Tento konkrétní popis činností ukáže ostatním, na čem skutečně pracujete, a umožní jim rozpoznat, kde mohou přispět. I když se osoba, kterou chcete oslovit, neúčastní vašich stand-up schůzek, je stále užitečné pravidelně cvičit popisování své práce s dostatečnou podrobností, aby bylo možné tuto informaci předat i lidem mimo váš tým.

V podobném duchu lze použít vizualizaci informací, která může přitáhnout pozornost ostatních. Záznamy, které ukazují společné porozumění, mohou pozvat k interakci ty, kdo se o ně budou zajímat. Účast na vizualizaci informací může být pozvánkou k dalšímu zapojení a spolupráci.

Jak se efektivně učit německy za 12 týdnů: Klíčové principy a tipy pro úspěšné ovládnutí jazyka
Jak manipulace a zlá povaha mohou ovlivnit vztahy
Jak válka ovlivňuje každodenní život a vztahy v těžkých časech?
Jak si připravit přírodní hnojivo z kopřivy a kostivalu pro vaši zahradu