Menu

Čo je technický dlh a prečo by sa ho testéri QA mali obávať?

what is technical debt

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Technický dlh je metaforická myšlienka, ktorá tvrdí, že rovnako ako človek môže naraziť na problémy s dlhmi vo finančníctve, softvérové ​​organizácie sa stretnú s niečím podobným pri hromadení nedokončenej práce počas minulých projektov a vydaní / sprintov verzií.

Čo je to technický dlh?

Predstavuje úsilie potrebné na odstránenie problémov / chýb, ktoré v kóde zostanú po vydaní aplikácie. Jednoducho povedané - je to rozdiel (v zmysle chýb) medzi tým, čo sa očakáva a čo sa dodá.

Keď je vývojový tím zaneprázdnený prácou na projekte a opravou chýb, objaví sa, bohužiaľ, veľa nových chýb. Mimo tieto, niektoré sú opravené a iné sa líšia pre neskoršie vydanie. Keď sa táto rôznorodosť problémov bude stále zväčšovať, v určitom okamihu je skutočne ťažké produkt včas vydať bez akýchkoľvek problémov. Toto je najhorší dôsledok Technický dlh ak to nebude vyriešené včas.

V tomto článku sa dozviete - čo je to technický dlh, prečo by sa o to mal QA tím starať a čo je najdôležitejšie, ako ho riadiť.

čo je technologický dlh

obrázok zdroj

Ward Cunningham , zakladateľ softvéru wiki, túto myšlienku v 90. rokoch minulého storočia, ktoré sa vyrovnávajú s dopadom nedobytného dlhu na finančný priemysel, a doslova narážajú na nechutnú skúsenosť s platením nadmerných úrokov po nesplácaní úverov.

otázky týkajúce sa oblasti poistenia obchodných analytikov

Výzvu zvyšovania technologického dlhu na šprint je možné vizualizovať na obr.

Tu je potrebné spomenúť, že existuje mierny rozdiel vo význame technického dlhu (tiež známeho ako kódový dlh alebo dizajnérsky dlh) od jeho zodpovedajúcej analógie vo svete financií - prvý je skôr ako abstraktná myšlienka , bez matematických rovníc na vizualizáciu toho, ako sa úrok skutočne hromadí.

zvyšujúci sa technický dlh

Obr: Vizualizácia škálovateľného nárastu technologického dlhu v rámci sprintov

Čo sa dozviete:

Prečo tímy QA najviac trpia kvôli technickému dlhu

Počas typického cyklu návrhu a vývoja softvéru existuje niekoľko vecí, ktoré môžu viesť k technický dlh ”Ako situácia– nesprávna dokumentácia , nedostatočné testovanie a oprava chyby, nedostatok koordinácie medzi tímami, dedičstvo kód a oneskorené refaktorovanie , neprítomnosť nepretržitá integrácia a ďalšie faktory mimo kontroly.

Napríklad, bolo pozorované, že úsilie o duplikáciu kódu môže viesť k čomukoľvek medzi 25 do 35% extra práca.

Oracle pl / sql rozhovor otázky a odpovede

Nikde však nie sú výzvy v dôsledku technického dlhu evidentnejšie ako pri testovaní QA kde testovacie tímy musia dodržať neočakávané termíny a všetko môže byť vyhodené z rýchlosti.

Ako často sa vaši testéri v poslednej chvíli stretli s problémami, keď nečakane prišiel manažér dodávky a povedal im: „Tím! Náš produkt musíme uviesť do života o týždeň, je nám ľúto, že s tým nemôžeme komunikovať včas. Skončite so všetkými testovacími úlohami urgentne, aby sme mohli byť pripravení na ukážku. “

Akékoľvek zmeškané testy alebo prístup „vyriešiť to neskôr“ môže v zásade viesť k problému podobnému technologickému dlhu. Nedostatočné pokrytie testami , nadmerné užívateľské príbehy, krátke šprinty a ďalšie príklady „ostrých zákrut“ kvôli tlaku na doručenie hrajú v praxi QA obrovskú úlohu za hromadením technického dlhu.

Príklad zo skutočného sveta

Americký online maloobchod so značným zastúpením na viacerých weboch a mobilných aplikáciách sa ocitol vo výzve „technického dlhu“ v skutočnom svete, keď sa zložitosť testovacej siete začala spájať s každou novou šprint .

Stalo sa tak kvôli náhlemu nárastu počtu mobilných zariadení, ktoré sa majú testovať, podpore viacerých jazykov a využitiu viac ako pol tucta sociálnych sietí.

S pokrytím automatizácie menej ako 40%, výzva technologického dlhu by sa prejavila nasledujúcimi spôsobmi:

  • Nadmerná spotreba času pri testovaní vydania - S rastom počtu prehliadačov, zariadení a skriptov s každým testovacím šprintom by sa cyklus vydávania stále oneskoroval, čo by malo za následok stratu času uvedenia na trh.
  • Zvyšujúce sa náklady na prenájom - Počet testerov potrebných na podporu projektu sa takmer zdvojnásobil, čo sa premietlo do ďalších 500 000 dolárov
  • Zložitosť projektu - S rastúcou zložitosťou projektu sa sledovanie testovacích prípadov a chýb stalo výzvou
  • Príliš veľa času stráveného prenasledovaním falošných pozitívov - Opäť pokles z dôvodu zvyšovania zložitosti projektu.
  • Zvýšenie úsilia pri vývoji testov až o 60% - Ide to s územím

Správa technického dlhu v postupoch zabezpečovania kvality

Väčšina manažérov QA impulzívne vníma technologický dlh ako rozumný dôsledok zamerania všetkej vašej energie iba na súčasný šprint, čo vedie k dosiahnutiu pokrytia testu nejako manuálnymi prostriedkami, a úplne ignoruje automatizáciu.

Toto je známe ako rýchly a špinavý prístup ktorej sa v blogu venoval Martin Fowler, autor publikácie technický kvadrant dlhu .

Agilné princípy nám diktujú, aby sme problém technologického dlhu vizualizovali ako neschopnosť udržať a stretnúť sa Referenčné hodnoty QA .

V skutočnosti, na základe prieskumu nedostatkom nástrojov a metód testovania ročne stojí americkú ekonomiku medzi 22,2 USD a 59,5 miliárd dolárov , pričom zhruba polovica z týchto peňazí sa vynaložila na ďalšie testovanie vývojármi softvéru a približne polovica používateľmi softvéru, aby sa zabránilo zlyhaniam.

Proaktívnym prístupom by bolo namiesto reakcie na zlyhanie, keď dôjde k incidentu, identifikácia chýb po každej aktivite alebo úlohe, ktorú je možné merať. Môžete to urobiť všetko manuálne, ale vzhľadom na tisíce scenárov testovacích prípadov priemerného projektu je automatická kontrola testovania nevyhnutnosťou.

Jasne, efektívne testovanie vám pomôže získať vážnu pozíciu vo vojne o technický dlh. Čo to teda v podstate znamená? Znamená to, ako dobre je váš systém schopný identifikovať chyby v celkovej aplikácii.

účinnosť testovania

testovanie softvéru obnovuje vzorky 2 roky skúseností

Ako ukazuje vyššie uvedená rovnica, účinnosť testovacích prípadov sa môže teoreticky priblížiť až k 100%, ak bol počet chýb zistených zákazníkom (t. J. Postprodukčné chyby) presne namapovaný na počet chýb zistených v každej fáze pokrytia testovaním.

Aby bolo k dispozícii dobre navrhnuté testovacie lôžko, ktoré dokáže presne zmerať chyby, akonáhle sa vkradnú, je nevyhnutným predpokladom automatizácia.

Automatizácia testovania pomáha vám minimalizovať počet spustených skriptov hlásením výsledkov a ich porovnaním s predchádzajúcimi testovacími chodmi. Metóda alebo proces používaný na vykonávanie automatizácie sa nazýva test automatizácia rámec .

Typickými príkladmi by boli komerčne dostupné alebo bezplatné nástroje ako Selenium, MonkeyTalk, roboty , Borland SilkCentral, stredisko kvality HP a IBM Rational Rose .

V minulosti boli QA / testovanie často vnímané organizáciami a ich softvérovými tímami ako podporná činnosť k dôležitejším obchodným produktom a nie ako disciplinovaná samostatná prax, ktorá by si vyžadovala základné a špeciálne zameranie. V skutočnosti je vedľajší prístup k QA / testovaniu presne to, čo viedlo k pretrvávajúcej výzve technického dlhu.

Ak vezmeme do úvahy rýchle tempo vývoja zručností v oblasti QA / testovania, ku ktorému došlo za posledné desaťročie, organizácie skutočne ťažko zdokonaľujú svoje zručnosti a kompetencie na minimálne požadované úrovne podľa súčasných priemyselných štandardov.

V skutočnosti existuje rastúci priemyselný trend, ktorý si vystačí s ničím menším než s najskúsenejšími profesionálmi v oblasti automatizácie testovania - podobne ako elitné komando pre testovanie / QA; sú známe ako softvéroví inžinieri v teste ( Odkedy ) a testovaní vývojári softvéru ( SDiT ). Títo odborníci sú veľmi žiadaní kvôli svojim rozsiahlym skúsenostiam vo vybranej vertikále (napr. Elektronický obchod) alebo v konkrétnej profesionálnej kategórii.

Väčšina spoločností zaoberajúcich sa vývojom softvéru a produktov, ako teraz hovoríme, má problémy s hľadaním požadovaných kvalifikovaných technických zdrojov z dôvodu kratších dodacích lehôt. Riešením tejto výzvy je partnerstvo s offshore automatizačným hráčom QA, ktorý dokáže vyriešiť nedostatok vašich schopností pomocou správnej skupiny zdrojov SDiT / SEiT.

Medzi ďalšie požadované atribúty outsourcingového hráča v oblasti QA / Testovania, ktoré sa ukážu ako užitočné, patrí agilný a disciplinovaný prístup k realizácii projektu, dostatočné skúsenosti v odbore vrátane praktického prístupu k opakovane použiteľným automatizačným rámcom a testovacím prípadom a v neposlednom rade jasný zámer. a schopnosť riešiť vzdialené tímové výzvy a kultúrne konflikty, aby klient nebol zaťažený prácou navyše pri riadení dodávateľov.

Záver

Ako každý iný dlh, aj technický dlh sa môže ukázať ako poľom pre podniky a hlavnou príčinou jeho akumulácie je zlyhanie pri implementácii proaktívneho postupu QA, ktorý odstraňuje všetky nevybavené položky v automatizácii.

O autorovi: Toto je príspevok od tímu eInfochips. Prišli s jedinečným prístupom tzv Technický dlh nula čo je jeden z najštruktúrovanejších a najefektívnejších spôsobov, ako postupne eliminovať technický dlh v činnostiach QA / automatizácie. Ak sa chcete dozvedieť viac o technologickom dlhu, pozri si toto video o prístupe k zníženiu technologického odboru

Dúfam, že získate jasnú predstavu o tom, čo je technický dlh. Dajte nám vedieť, ak máte nejaké otázky týkajúce sa tejto otázky alebo ako to v praxi zvládnuť.

Odporúčané čítanie

^