Menu

Testování posunu doleva: Tajná mantra úspěchu softwaru

shift left testing secret mantra

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Nové testování posunu doleva, mantra DevOps ve vývoji softwaru:

Rychlý Rekapitulace všech videonávodů v DevOps bylo vysvětleno v našem dřívějším tutoriálu. Nyní uvidíme testování Shift left.

Když používám výraz „Shift Left“, možná by vás zajímalo, co mám na mysli v softwaru Shift Left ??

Před 2 a více desítkami let, když jsem zahájil svou kariéru jako tester softwaru, neexistovala žádná samostatná „fáze testování“ pro vývoj softwaru a role testerů nikdy neexistovala. Vývojáři používali k vývoji softwaru, testování a vydávání softwaru.

Další čtení => Informační výukové série DevOps

Koncept Testování softwaru byly zavedeny postupně, když závady z výroby začaly narážet na rozpočet projektu, a proto vstoupilo v platnost „funkční testování“ s velmi štíhlým týmem testerů. V té době jsme byli jen dva testeři proti týmu 20 vývojářů.

Přístup k testování posunu doleva

IT průmysl začal sledovat vodopádový model pro vývoj softwaru, kde, jak všichni víme, životní cyklus vývoje softwaru jde postupně v pořadí Požadavky => Design => Kódování => Testování .

Pokud tedy začnete zleva doprava, fáze testování je zcela vpravo od životního cyklu vývoje softwaru.

Co se naučíte:

Úvod do konceptu posunu doleva

Po určitou dobu si lidé uvědomili důležitost Testování softwaru a dopad udržování „testovací fáze“ zcela vpravo nebo na konci životního cyklu vývoje softwaru. K této realizaci došlo proto, že náklady na chybu identifikovanou směrem k extrémní pravici byly nakonec velmi vysoké a na jejich odstranění bylo zapotřebí obrovské úsilí a příliš mnoho času.

Existovaly případy, kdy po tolik času a úsilí vynaloženého na software kvůli zásadní chybě identifikované na konci nemohl být kriticky důležitý software uveden na trh, což mělo za následek obrovskou ztrátu.

Proto, kvůli identifikace chyby během poslední fáze buď bylo vydání zpožděno, nebo byl software občas vyřazen z zvážení úsilí potřebného k jejich opravě, což opravdu nebylo hodné.

Fáze vývoje softwaru

„Vady jsou méně nákladné, jsou-li chyceny včas“.

Tato realizace a velká poučení přinesly velkou revoluci v softwarovém průmyslu a zrodily nový koncept s názvem „Shift Left“ , což znamená posunout ‚testovací fázi 'doleva zprava nebo zapojit testování v každé fázi a zapojit testery po celou dobu.

Test Shift Left také znamená, že na konci netestujte, ale testujte průběžně.

Fáze SDLC

Přístup Shift doleva

Co je Testování posunu doleva?

Za prvé, zásada „Shift left“ podporuje Testovací tým pro včasnou spolupráci se všemi zúčastněnými stranami ve fázi vývoje softwaru. Proto mohou jasně porozumět požadavkům a navrhnout testovací případy pomoci softwaru „Fail Fast“ a umožnit týmu opravit všechny poruchy co nejdříve.

bezplatná aplikace pro stahování mp3 pro telefon Android

Přístup Shift Left není nic jiného než zapojení testerů mnohem dříve do životního cyklu vývoje softwaru, což by jim zase umožnilo pochopit požadavky, design softwaru, architekturu, kódování a jeho funkčnost, klást těžké otázky zákazníkům, obchodním analytikům a vývojářům , hledat vysvětlení a poskytovat zpětnou vazbu, kdekoli je to možné, aby podpořila tým.

Toto zapojení a porozumění povede testery k získání úplných znalostí o produktu, promyšlení různých scénářů, navrhnutí scénářů v reálném čase na základě chování softwaru, které by týmu pomohly identifikovat vady ještě před provedením kódování.

Jak posunuje vývoj softwaru ovlivňující levici?

Přístup Shift Lift ovlivňuje vývoj softwaru několika způsoby.

Níže je uvedeno několik klíčových bodů o Shift Left:

  • Přístup Shift Left se zaměřuje na zapojení testerů do všech a nejdůležitějších kritických fází programu . To umožňuje testerům odklonit jejich zaměření od detekce defektů k prevenci defektů a řídit obchodní cíle programu.
  • Přístup Shift Left poskytuje, velký význam pro testování s nimiž se nesmírně zvyšuje role a odpovědnost testerů.
  • Se zvyšující se odpovědností za testovací tým se tým prostě nezaměřuje na „Testování softwaru k identifikaci chyb“ , ale proaktivně pracuje s týmem hned od počátečních fází při plánování a budování robustní a efektivní testovací strategie tím, že týmu poskytne skvělé vedení a poradenství v oblasti testování tím, že se zaměří na dlouhodobou vizi produktu, nikoli jen na převzetí odpovědnost za testovací práci.
  • Přístup Shift Left dává příležitost pro testery nejprve navrhnout testy , kde jsou testy zcela zaměřeny na zákaznickou zkušenost a jejich očekávání, což vývojářům zase umožní vyvíjet software na základě těchto testů, a tím vyhovět potřebám zákazníků.
  • Přístup Shift Left nekončí pouze u testerů. Přesun do pronájmu a průběžné provádění testovacích aktivit bude také umožnit vývojářům převzít větší vlastnictví jejich kódu a zvýšit jejich odpovědnost za testování.
  • Přístup Shift Left také podporuje Testeři, aby přijali Behaviorálně řízený vývoj BDD a testovaný vývoj TDD , což pomáhá předcházet indukci defektů v softwaru.
  • Shift Left Testing in Agile: Přístup Shift Left podporuje formování Agilní skrumáž Týmy, které povinně zahrnují testery spolu s dalšími rolemi a zahrnuje testery v pravidelných hovorech, dalších interakcích, kontrolních schůzkách, díky nimž měli testeři více informací souvisejících s programem, a proto jim umožnil dopřát si a zapojit se do podrobné analýzy softwaru a poskytovat rychlá zpětná vazba, která by pomohla předcházet závadám založeným na softwaru.

Celkové testování Shift Left vyžaduje, aby testeři „Zapojte se brzy“ co nejdříve zapojit se do diskuse a spolupracovat na nápadech, požadavcích v každé fázi, kdy výsledek fáze ovlivňuje hodnotu konečného produktu, a také pomoci projektu identifikovat rizika a předem je zmírnit.

Shift doleva

Co by měli testeři dělat při řazení vlevo?

Níže je uvedeno několik klíčových faktorů, v nichž testeři dělají odlišně Shift Left Strategy:

# 1) Testovací tým musí zapojit se brzy v systému hned od zahájení projektu s cílem rozvíjet integraci se zbytkem týmu a obchodem poskytovat užitečné vstupy v každé fázi vývoje softwaru.

#dva) Testovací tým by měl spolupracovat s obchodním a provozním týmem a získat jasnost programu a poskytnout jasný pohled na poptávku a pomoci s efektivním plánováním potřeb zvyšování zdrojů, potřeb školení a požadavků na testovací nástroje v dostatečném předstihu.

# 3) Testovací týmy musí na začátku vývoje softwaru komunikovat se všemi zúčastněnými stranami z podnikání získejte jasnou viditelnost produktu & navrhnout jednotnou strategii testování a plánovat optimalizované úsilí při testování, analyzovat závislost na testovacích prostředích, třetích stranách, stubech atd., připravit robustní strategii a rámec automatizace a vytvořit efektivní plán správy testovacích dat.

# 4) Testovací tým musí při zajišťování spolupracovat se zbytkem týmu skvělé vedení testů a vedení týmu a tím spíše pamatovat na dlouhodobou vizi produktu, než jen převzít odpovědnost za testovací činnosti.

# 5) Požadavky jsou klíčem a základem úspěchu každého programu a dobře definované požadavky definují úspěch projektu. Během fáze plánování požadavků testeři potřeba přezkoumat a analyzovat požadavky pro jakoukoli nejednoznačnost, lepší jasnost, úplnost, testovatelnost, definice kritérií přijetí atd.

Také je třeba identifikovat chybějící požadavky (pokud existují), porozumět závislostem a implementačním strategiím. Clear Requirements pomáhá softwaru „rychle selhat“ a opravit všechny chyby co nejdříve.

# 6) Přineste dostatek jasnosti a přesnosti požadavků tím, že uvedete skutečné příklady které ilustrují používané funkce.

# 7) Testeři potřebují účastnit se schůzek kontroly designu pravidelně a rozumět designu a architektuře produktu a identifikovat nedostatky v designu, navrhovat alternativní možnosti designu, identifikovat mezery a podle toho vytvářet testovací scénáře, které rozbijí designy.

# 8) Testeři potřebují vykonat Statické testování (recenze) v dostatečném předstihu a poskytnout zpětnou vazbu ke klíčovým projektovým dokumentům, aby se zabránilo vadám v uzemnění softwaru a jeho pozdějšímu rozšíření.

# 9) Testovací tým by měl spolupracovat s designovým a vývojovým týmem při poskytování testovacích scénářů předem k vývoji kódu a řešit všechny možné scénáře a obchodní toky v reálném čase.

# 10) Zkušební tým musí navrhnout silné a robustní testovací scénáře takže během testování je identifikováno pouze několik defektů a při vstupu do testovací fáze je zabráněno velkým defektům.

co je port triggering vs port forwarding

#jedenáct) Testeři musí Otestujte co nejdříve , ať už na samostatném nebo místním systému, aby se závada nedostala do pozdějších fází.

Podstatou konceptu „Shift Left“ pro testery je najít defekty co nejdříve všemi možnými prostředky.

Hledání defektů pomocí Shift doleva

Výhody testování řazení vlevo

Přístup Shift Left funguje na základě agilního manifestu a má také několik výhod.

Oni jsou:

  • Jednotlivci a interakce nad procesy a nástroji.
  • Pracovní software přes komplexní dokumentaci.
  • Spolupráce se zákazníky nad vyjednáváním smlouvy.
  • Reakce na změnu nad dodržováním plánu.

Vidíme, že zatímco hodnota je v položkách napravo, máme větší hodnotu pro položky na levé straně.

Shift Left se chystá přinést myšlenku testování dříve v procesu, což povede k lepšímu a efektivnějšímu testování a zlepšení kvality softwaru.

Stručně řečeno, proces Shift Left Testing je:

  • Včasné nalezení vad a tím snížení nákladů na projekt.
  • Znovu a znovu testujeme, abychom na konci snížili počet závad.
  • Automatizovat vše a zlepšit čas uvedení na trh.
  • Zaměřit se na požadavky zákazníků a zlepšit zákaznickou zkušenost.

Posuňte levé zaostření

Závěr

„Shift Left“ koncept přinesl obrovskou transformaci pro celou roli „testování“. Do té doby se testování zaměřovalo pouze na „Detekci defektů“ a nyní je cílem „Shift Left“ z pohledu Testování cesta „Včasné zjištění defektu do Prevence defektů '' .

Shift Left je tedy velkým skokem v softwarovém průmyslu v metodice vývoje softwaru směrem k rychlosti uvedení na trh, zlepšení kvality softwaru a zkrácení doby do uvedení na trh.

O autorovi: Tento článek napsal člen týmu STHGayathri Subrahmanyam. Testování softwaru se věnuje od 90. let, v době, kdy byla v oboru zavedena role testerů. Během své testovací kariéry absolvovala řadu testů TMMI, testovala industrializační práce, nastavení TCOE, kromě zpracování testovacích dodávek a implementovala praxi DevOps pro velké zapojení. Ale podle ní se učení nikdy nezastaví ...

Sdělte nám své myšlenky / návrhy v sekci komentáře níže.

Výukový program PREV | DALŠÍ výuka

Doporučené čtení

^