Zmínky o shift-left najdeme v poslední době téměř všude. V článcích, podcastech, workshopech a často se objevuje také na diskuzních fórech. Pro mnohé se tento termín stal synonymem pro moderní přístup k testování a řízení kvality softwaru. Ale co to vlastně shift-left znamená? A měli by se testeři bát o svou práci?
Shift-left není žádnou novinkou. Jedná se o přístup k řízení kvality softwaru, který aktivity spojené s testováním a kvalitou rozloží na celý průběh vývoje. Pokud si představíme vývoj softwaru jako časovou osu, kde testování bývalo umístěno na konci (vpravo), shift-left tento proces přesouvá blíže k začátku – tedy doleva. Tento princip je součástí agilních metodologií už dlouho, jen se mu v poslední době dostává větší pozornosti.
Že by testování mělo být přirozenou součástí celého vývojového cyklu, nikoliv samostatnou fází na konci jsem zmiňoval například v článku Přestaňte testovat a začněte vyvíjet.
IT je dynamické odvětví, kde konkurence nutí společnosti rychle reagovat na změny na trhu. Firmy potřebují dodávat software a nové funkce co nejrychleji. Tradiční vodopádový model, kde se požadavky předávají z jedné fáze do druhé, neumožňuje rychlou reakci. Když analytik teprve předává specifikace vývojářům, konkurence už může vydávat aplikaci se stejnou funkcionalitou. V tomto ohledu shift-left umožňuje zefektivnit celý proces tím, že zapojí testování a řízení kvality již od začátku vývoje.
Shift-left přináší změnu v myšlení celého týmu – za kvalitu je odpovědný každý člen týmu, a to od samého začátku, nejen tester na konci vývojového cyklu.
Jak toho dosáhnout? Klíčem je spolupráce a rozšíření kompetencí. Už v agilním přístupu, konkrétně ve Scrumu, se počítá s tím, že každý člen týmu by měl být schopen přispět v jakékoliv fázi vývoje. Shift-left k tomu navíc přidává požadavek, aby každý při vývoji přemýšlel také o kvalitě.
Shift-left může přinést více schůzek a diskuzí, což může na první pohled vypadat jako snížení produktivity a zvýšení nákladů. Ve skutečnosti se ale díky řešení problémů hned na začátku snižuje počet chyb, zkracuje čas finálního testování a snižuje počet oprav, které jsou důsledkem nesprávného zadání nebo špatného pochopení požadavků. Celkově se tedy sníží náklady spojené s vývojem a údržbou softwaru.
Neexistuje univerzální recept na zavedení přístupu shift-left. Vše je o změně přemýšlení členů týmu. Často vidíme týmy, které tvrdí, že používají scrum, ale ve skutečnosti stále pracují podle vodopádového modelu. Prvním krokem by mohlo být zavedení skutečného scrumu, kde je kvalita vnímána jako odpovědnost všech, nikoliv pouze testerů.
Nepomůže násilné zavádění shift-left. Tým nelze změnit externě. Pokud však jeden člen týmu pochopí výhody shift-left a nadchne pro to ostatní, může se celý tým postupně přizpůsobit.
IT je dynamické odvětví, kde konkurence nutí společnosti rychle reagovat na změny na trhu. Firmy potřebují dodávat software a nové funkce co nejrychleji. Tradiční vodopádový model, kde se požadavky předávají z jedné fáze do druhé, neumožňuje rychlou reakci. Když analytik teprve předává specifikace vývojářům, konkurence už může vydávat aplikaci se stejnou funkcionalitou. V tomto ohledu shift-left umožňuje zefektivnit celý proces tím, že zapojí testování a řízení kvality již od začátku vývoje.
Shift-left přináší změnu v myšlení celého týmu – za kvalitu je odpovědný každý člen týmu, a to od samého začátku, nejen tester na konci vývojového cyklu.
Jak toho dosáhnout? Klíčem je spolupráce a rozšíření kompetencí. Už v agilním přístupu, konkrétně ve Scrumu, se počítá s tím, že každý člen týmu by měl být schopen přispět v jakékoliv fázi vývoje. Shift-left k tomu navíc přidává požadavek, aby každý při vývoji přemýšlel také o kvalitě.
Shift-left může přinést více schůzek a diskuzí, což může na první pohled vypadat jako snížení produktivity a zvýšení nákladů. Ve skutečnosti se ale díky řešení problémů hned na začátku snižuje počet chyb, zkracuje čas finálního testování a snižuje počet oprav, které jsou důsledkem nesprávného zadání nebo špatného pochopení požadavků. Celkově se tedy sníží náklady spojené s vývojem a údržbou softwaru.
Neexistuje univerzální recept na zavedení přístupu shift-left. Vše je o změně přemýšlení členů týmu. Často vidíme týmy, které tvrdí, že používají scrum, ale ve skutečnosti stále pracují podle vodopádového modelu. Prvním krokem by mohlo být zavedení skutečného scrumu, kde je kvalita vnímána jako odpovědnost všech, nikoliv pouze testerů.
Nepomůže násilné zavádění shift-left. Tým nelze změnit externě. Pokud však jeden člen týmu pochopí výhody shift-left a nadchne pro to ostatní, může se celý tým postupně přizpůsobit.
