Menu

Co je to technický dluh a proč by se jich měli zabývat testeři QA?

what is technical debt

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

Technický dluh je metaforická myšlenka, která tvrdí, že stejně jako člověk může narazit na dluhové problémy ve financích, softwarové organizace se setkají s něčím podobným při hromadění nedokončené práce během minulých projektů a vydání / sprintů verzí.

Co je to technický dluh?

Představuje úsilí potřebné k vyřešení problémů / defektů, které zůstanou v kódu při vydání aplikace. Jednoduše řečeno - je to rozdíl (co se týká chyb) mezi tím, co se očekává a co se doručí.

Když je vývojový tým zaneprázdněn prací na projektu a opravou chyb, objeví se bohužel mnoho nových chyb. Mimo některé jsou opravené a jiné se pro pozdější vydání liší. Když se tento rozdíl v problémech stále zvyšuje, v jednom okamžiku je opravdu obtížné produkt včas vydat bez problémů. To je nejhorší důsledek Technický dluh pokud to není řešeno včas.

V tomto článku se dozvíte - co je to technický dluh, proč by tým QA měl být znepokojen a co je nejdůležitější, jak jej spravovat.

co je to technologický dluh

obraz zdroj

Ward Cunningham , zakladatel wiki softwaru, pojal tuto myšlenku v 90. letech minulého století, které se vyrovnaly dopadu nedobytných pohledávek na finanční průmysl, doslova narážející na nechutnou zkušenost s nutností platit nadměrné úroky po nesplácení půjček.

to, co je .swf soubor?

Výzvu zvyšování technologického dluhu na sprint lze vizualizovat na obr.1.

Zde je třeba zmínit, že existuje malý rozdíl ve smyslu technického dluhu (také známého jako kódový dluh nebo návrhový dluh) od jeho odpovídající analogie ve světě financí - ten první je spíše jako abstraktní myšlenka , bez matematických rovnic pro vizualizaci toho, jak se úrok skutečně hromadí.

rostoucí technický dluh

Obr. 1: Vizualizace škálovatelného nárůstu technologického dluhu napříč sprinty

Co se naučíte:

Proč týmy QA nejvíce trpí kvůli technickému dluhu

Během typického cyklu návrhu a vývoje softwaru existuje několik věcí, které mohou vést k „ technický dluh „Jako situace - nesprávná dokumentace , nedostatečné testování a oprava chyb, nedostatek koordinace mezi týmy, dědictví kód a opožděné refaktorování , nepřítomnost kontinuální integrace a další mimo kontrolní faktory.

NapříkladBylo pozorováno, že úsilí o duplikaci kódu může vést k čemukoli mezi tím 25 na 35% práce navíc.

jaké programy používají c ++

Nikde však nejsou výzvy v důsledku technického dluhu zřetelnější než v QA testování kde testovací týmy musí dodržet neočekávané termíny a všechno může být vyhozeno z rychlosti.

Jak často se vaši testeři v poslední chvíli potýkali s problémy, když nečekaně přišel doručovatel a řekl jim: „Tým! Náš produkt musíme uvést do provozu za týden, omlouváme se, že s tím nebudeme schopni včas komunikovat. Ukončete prosím urgentně všechny testovací úkoly, abychom mohli být připraveni na ukázku. “

Jakékoli zmeškané testy nebo přístup „vyřešit později“ mohou v zásadě vést k problému podobnému technologickému dluhu. Nedostatečné pokrytí testů , nadměrné uživatelské příběhy, krátké sprinty a další příklady „průlomů“ kvůli tlaku na doručování hrají v praxi QA obrovskou roli za hromaděním technického dluhu.

Příklad ze skutečného světa

Americký online prodejce s významným zastoupením na různých webech a mobilních aplikacích se ocitl ve výzvě „technického dluhu“ v reálném světě, když se složitost testovací sítě začala spojovat s každým novým sprint .

Stalo se to kvůli náhlému nárůstu počtu testovaných mobilních zařízení, podpoře více jazyků a využití více než půl tuctu sociálních sítí.

S pokrytím automatizace méně než 40%, výzva technologického dluhu by se projevila následujícími způsoby:

  • Nadměrná spotřeba času při testování vydání - S počtem prohlížečů, zařízení a skriptů rostoucích s každým testovacím sprintem by se cyklus vydání stále zpozdil, což by vedlo ke ztrátě času na uvedení na trh.
  • Rostoucí náklady na pronájem - Počet testerů potřebných k podpoře projektu se téměř zdvojnásobil, což se promítlo do dalších 500 000 $
  • Složitost projektu - S rostoucí složitostí projektu se sledování testovacích případů a chyb stalo výzvou
  • Příliš mnoho času promarněného pronásledováním falešných pozitivů - Opět, pokles rostoucí složitosti projektu.
  • Zvýšení úsilí při vývoji testů až o 60% - Jde to s územím

Správa technického dluhu v praktikách QA

Většina manažerů QA impulzivně považuje technologický dluh za rozumný důsledek soustředění veškeré vaší energie pouze na aktuální sprint, což vede k dosažení pokrytí testu nějakým způsobem manuálními prostředky a zcela ignoruje automatizaci.

Toto je známé jako rychlý a špinavý přístup kterému se v blogu zabýval Martin Fowler, autor časopisu technický dluhový kvadrant .

Agilní principy diktují, že vizualizujeme problém technologického dluhu jako neschopnost udržet a setkat se Referenční hodnoty QA .

Ve skutečnosti, na základě průzkumu nedostatek testovacích nástrojů a metod ročně stojí americkou ekonomiku mezi 22,2 $ a 59,5 miliard $ , přičemž zhruba polovina těchto peněz byla vynaložena na další testování vývojáři softwaru a přibližně polovina uživatelů softwaru, aby se předešlo selhání.

Proaktivní přístup by místo reakce na selhání, jakmile dojde k incidentu, spočíval v identifikaci defektů po každé aktivitě nebo úkolu, který lze měřit. Můžete to udělat všechno ručně, ale vzhledem k tisícům scénářů testovacích případů pro průměrný projekt je automatická kontrola testování nutností.

Jasně, efektivní testování vám pomůže získat vážnou pozici ve válce o technický dluh. Co to tedy v podstatě znamená? Znamená to, jak dobře je váš systém schopen identifikovat vady celkové aplikace.

účinnost testování

Jak ukazuje výše uvedená rovnice, účinnost testovacích případů se může teoreticky přiblížit i 100%, pokud by byl počet vad zjištěných zákazníkem (tj. Vady po výrobě) přesně mapován na počet vad nalezených v každé fázi pokrytí testováním.

Aby bylo k dispozici dobře navržené testovací zařízení, které dokáže přesně měřit defekty, jakmile se vklouznou dovnitř, je nezbytnou podmínkou automatizace.

Automatizace testování pomáhá minimalizovat počet spuštěných skriptů pomocí hlášení výsledků a jejich porovnání s dřívějšími testovacími běhy. Metoda nebo proces používaný k provedení automatizace se nazývá test automatizace rámec .

Typickými příklady by byly komerčně dostupné nebo bezplatné nástroje jako Selenium, MonkeyTalk, roboti , Borland SilkCentral, HP Quality Center a IBM Rational Rose .

V minulosti byly QA / testování často vnímány organizacemi a jejich softwarovými týmy jako podpůrná aktivita k důležitějším obchodním výsledkům, a ne jako disciplinovaná praxe sama o sobě, která by vyžadovala základní, specializované zaměření. Nejdůležitější přístup k QA / testování je ve skutečnosti přesně to, co vedlo k přetrvávající výzvě technického dluhu.

co je jednostránková aplikace v angularjs

Vzhledem k rychlému tempu vývoje QA / testovacích dovedností, ke kterému došlo v posledním desetiletí, se organizace opravdu těžko zdokonalují ve svých dovednostech a kompetencích na minimální požadované úrovně podle současných průmyslových měřítek.

Ve skutečnosti existuje rostoucí průmyslový trend, který si vystačí s ničím menším než nejzkušenějšími profesionály v automatizaci testování - něco jako elitní komanda testování / QA; jsou známí jako softwaroví inženýři v testu ( Od té doby ) a vývojáři softwaru v testu ( SDiT ). Tito profesionálové jsou velmi žádaní díky svým rozsáhlým zkušenostem s vybraným oborem (např. Elektronický obchod) nebo konkrétní profesní kategorií.

Většina společností zabývajících se vývojem softwaru a produktů, jak nyní hovoříme, se snaží najít požadované kvalifikované technické zdroje tváří v tvář kratším dodacím lhůtám. Řešením této výzvy je partnerství s offshore automatizačním přehrávačem QA, který dokáže vyřešit nedostatek vašich dovedností se správným zdrojem SDiT / SEiT zdrojů.

Mezi další požadované atributy outsourcingového hráče v QA / Testování, které se osvědčily, patří agilní, disciplinovaný přístup k realizaci projektu, dostatečné průmyslové zkušenosti včetně praktického přístupu k opakovaně použitelným automatizačním rámcům a testovacím případům a v neposlední řadě jasný záměr a schopnost řešit vzdálené týmové výzvy a kulturní střety tak, aby klient nebyl zatížen prací navíc při správě dodavatelů.

Závěr

Stejně jako jakýkoli jiný dluh se může technický dluh prokázat jako prokletí podniků a hlavní příčinou jeho akumulace je selhání v implementaci proaktivní praxe QA, která odstraňuje všechny nevyřízené položky v automatizaci.

O autorovi: Toto je příspěvek od týmu eInfochips. Vymysleli jedinečný přístup Tech Debt Zero což je jeden z nejstrukturovanějších a nejúčinnějších způsobů, jak postupně eliminovat technický dluh v činnostech QA / automatizace. Chcete-li vědět více o technologickém dluhu, podívej se na tohle video o přístupu ke snížení technologického oddělení

Doufám, že máte jasnou představu o tom, co je technický dluh. Dejte nám vědět, pokud máte nějaké dotazy týkající se toho nebo jak to v praxi spravovat.

Doporučené čtení

^