what is technical debt
Tehnički dug je metaforična ideja koja tvrdi da, baš kao što netko može naići na probleme s dugom u financijama, softverske organizacije nailaze na nešto slično u nakupljanju nedovršenih radova tijekom prošlih projekata i izdanja / sprinta verzija.
Što je tehnički dug?
Predstavlja napor potreban za ispravljanje problema / nedostataka koji ostaju u kodu kada se aplikacija pusti. Jednostavnim riječima - to je razlika (u smislu grešaka) između očekivanog i isporučenog.
Kad je razvojni tim zauzet radom na projektu i ispravljanjem programskih pogrešaka, nažalost, pojavljuju se mnoge nove pogreške. Od ove su neke ispravljene, a neke se razlikuju za kasnije izdanje. Kada se ovo različito izdanje povećava, u jednom trenutku postaje stvarno teško na vrijeme pustiti proizvod bez ikakvih problema. To je najgora posljedica Tehnički dug ako se ne riješi na vrijeme.
U ovom ćete članku naučiti - što je tehnički dug, zašto bi QA tim trebao biti zabrinut zbog toga i najvažnije kako njime upravljati.
slika izvor
Ward Cunningham , osnivač wiki softvera, zamišljen od ove ideje još 1990-ih povlačeći paralele s utjecajem lošeg duga na financijsku industriju, doslovno aludirajući na neukusno iskustvo plaćanja novca od prekomjernih kamata nakon neplaćanja zajmova.
otvaranje dat datoteke na mac
Izazov povećanja tehnološkog duga po sprintu može se prikazati na slici 1.
Ovdje treba spomenuti da postoji mala razlika u značenju tehničkog duga (također poznatog kao kodni dug ili dug dizajna) od njegove odgovarajuće analogije u svijetu financija - prva je više poput apstraktna ideja , bez matematičkih jednadžbi koje bi mogle vizualizirati kako se kamata stvarno akumulira.
Sl. 1: Vizualizacija skalabilnog povećanja tehnološkog duga u sprintima
Što ćete naučiti:
- Zašto QA timovi najviše pate zbog tehničkog duga
- Primjer iz stvarnog svijeta
- Tehničko upravljanje dugom u praksama osiguranja kvalitete
- Zaključak
- Preporučena literatura
Zašto QA timovi najviše pate zbog tehničkog duga
Tijekom tipičnog ciklusa dizajna i razvoja softvera postoji nekoliko stvari koje mogu dovesti do „ tehnički dug ”Poput situacije– nepravilna dokumentacija , neadekvatno testiranje i ispravljanje programskih pogrešaka, nedostatak koordinacije između timova, baština kod i odgođena refaktorizacija , odsustvo kontinuirana integracija i drugi faktori izvan kontrole.
Na primjer, primijećeno je da napori dupliciranja koda mogu dovesti do bilo čega između 25 do 35% dodatni rad.
kako stvoriti java projekt u eclipse - u
Međutim, nigdje ih nema izazovi zbog tehničkog duga očigledniji nego u QA testiranju gdje se ispitni timovi moraju pridržavati neočekivanih rokova i sve može biti izbačeno iz opreme.
Koliko često su se vaši testeri suočili s nedoumicama u posljednjem trenutku kada je neočekivano došao voditelj dostave i rekao im: „Tim! Svoj proizvod moramo predstaviti za tjedan dana, žao nam je što to nismo uspjeli na vrijeme priopćiti. Molimo vas da hitno završite sa svim testnim zadacima kako bismo mogli biti spremni s demonstracijom. '
U osnovi, bilo koji propušteni test ili pristup „riješi to kasnije“ može dovesti do problema poput tehnološkog duga. Nedostatak pokrivenosti testom , prevelike korisničke priče, kratki sprint i drugi primjeri 'presijecanja uglova' zbog pritiska isporuke igraju veliku ulogu u nakupljanju tehničkog duga u praksi osiguranja kvalitete.
Primjer iz stvarnog svijeta
Američki mrežni prodavač sa značajnom prisutnošću na više web stranica i mobilnih aplikacija našao se u stvarnom izazovu 'tehničkog duga' kada se složenost mreže testiranja sa svakim novim složila sprint .
To se dogodilo zbog naglog skoka u broju mobilnih uređaja koji će se testirati, podržanih više jezika i više od pola tuceta web lokacija za društvene mreže.
S pokrivenošću automatizacije manjom od 40%, izazov tehnološkog duga pojavio bi se na sljedeće načine:
- Pretjerana potrošnja vremena u ispitivanju puštanja u rad - S rastom broja preglednika, uređaja i skripti sa svakim testnim sprintom, ciklus izdavanja nastavio bi se odgađati što bi dovelo do gubitka vremena za izlazak na tržište.
- Sve veći troškovi zapošljavanja - Broj testera potrebnih za podršku projektu gotovo se udvostručio, što je dovelo do dodatnih 500 tisuća dolara
- Složenost projekta - S rastućom složenošću projekta, praćenje test slučajeva i grešaka postajalo je izazov
- Previše vremena izgubljeno je u progonu lažnih pozitivnih rezultata - Opet, ispad sve veće složenosti projekata.
- Povećanje napora u razvoju testa za čak 60% - To ide uz teritorij
Tehničko upravljanje dugom u praksama osiguranja kvalitete
Većina QA menadžera impulsivno gleda na tehnološki dug kao na razumnu posljedicu usmjeravanja sve svoje energije samo na trenutni sprint, što dovodi do pokrivanja testova nekako ručno, a potpuno zanemaruju automatizaciju.
Ovo je poznato kao brzi i prljavi pristup koji je u blogu obradio Martin Fowler, autor knjige kvadrant tehničkog duga .
Agilna načela nalažu da problem tehnološkog duga vizualiziramo kao nemogućnost održavanja i ispunjenja Mjerila osiguranja kvalitete .
Zapravo, na temelju ankete Nacionalnog instituta za standarde i tehnologiju (NIST), nedovoljni alati i metode ispitivanja godišnje koštaju američko gospodarstvo 22,2 USD i 59,5 milijardi dolara , s otprilike polovicom ovog novca koji su programeri softvera potrošili na dodatno testiranje, a oko polovice korisnici softvera kako bi izbjegli kvarove.
Umjesto da se reagira na kvarove kako i kada se incident dogodi, proaktivni pristup bio bi prepoznavanje nedostataka nakon svake aktivnosti ili zadatka koji se mogu izmjeriti. Sve to možete učiniti ručno, ali s obzirom na tisuće scenarija testnih slučajeva za prosječni projekt, automatizirana kontrola testiranja je nužna.
Jasno, učinkovito ispitivanje može vam pomoći da steknete ozbiljan temelj u ratu zbog tehničkog duga. Pa, što to u osnovi znači? To znači koliko je vaš sustav dobro opremljen u prepoznavanju nedostataka u cjelokupnoj aplikaciji.
Kao što pokazuje gornja jednadžba, učinkovitost testnog slučaja može se teoretski približiti čak 100% da je broj pronađenih nedostataka kupaca (tj. Postprodukcijskih nedostataka) točno mapiran na broj otkrivenih nedostataka u svakoj fazi pokrivenosti ispitivanja.
Da bi se imao dobro dizajniran ispitni ležaj koji može točno izmjeriti nedostatke čim se uvuku, automatizacija je preduvjet.
Automatizacija ispitivanja pomaže vam da smanjite broj izvršenih skripti izvještavanjem o rezultatima i njihovom usporedbom s ranijim probnim pokretanjem. Metoda ili postupak koji se koristi za izvršavanje automatizacije naziva se test automatizacija okvir .
Tipični primjeri bili bi komercijalni gotovi ili besplatni alati kao što su Selenium, MonkeyTalk, roboti , Borland SilkCentral, HP centar za kvalitetu i IBM Rational Rose .
U prošlosti su organizacije i njihovi softverski timovi QA / testiranje često doživljavali kao pomoćnu aktivnost važnijim poslovnim rezultatima, a ne kao discipliniranu praksu koja bi zahtijevala temeljni, posvećeni fokus. U stvari, nesuštinski pristup QA / testiranju upravo je ono što je uopće dovelo do stalnog izazova tehničkog duga.
Uzimajući u obzir brzi tempo evolucije QA / vještina testiranja koji se dogodio u posljednjem desetljeću, organizacije stvarno teško nadograđuju svoje vještine i kompetencije na minimalne razine željene prema trenutnim mjerilima u industriji.
Zapravo, postoji rastući trend u industriji da se zadovolji sa ništa manje od najiskusnijih profesionalaca u automatizaciji testiranja - otprilike poput elitnih komandosa testiranja / osiguranja kvalitete; poznati su kao softverski inženjeri u testu ( Od ) i programeri softvera u testu ( SDiT ). Ovi su profesionalci vrlo traženi zbog svog velikog iskustva u odabranoj vertikali (npr. E-trgovina) ili određenoj profesionalnoj kategoriji.
Većina tvrtki za razvoj softvera i proizvoda, kako sada govorimo, trudi se pronaći željene, kvalificirane tehničke resurse uslijed kraćih rokova isporuke. Rješenje ovog izazova je partnerstvo s off-shore QA automatskim uređajem za rješavanje problema s nedostatkom vaših vještina pomoću odgovarajuće baze SDiT / SEiT resursa.
Ostali željeni atributi outsourcing igrača u osiguranju kvalitete / testiranju koji se pokazuju korisnim uključuju okretan, discipliniran pristup izvršenju projekata, dovoljno industrijskog iskustva, uključujući praktični pristup višekratno korištenim okvirima automatizacije i test slučajevima, i na kraju, ali ne najmanje važno, jasnu namjeru i sposobnost rješavanja izazova s udaljenim timovima i kulturnih sukoba kako klijent ne bi bio opterećen dodatnim poslom u upravljanju dobavljačima.
kako otvoriti .swf datoteke na Windowsima
Zaključak
Kao i bilo koji drugi dug, i tehnički dug može se pokazati kao prokletstvo poduzeća, a osnovni uzrok njegovog nakupljanja je neuspjeh u provođenju proaktivne prakse osiguranja kvalitete koja uklanja sve zaostale dijelove automatizacije.
O autoru: Ovo je gost eInfochips tima. Oni su smislili jedinstveni pristup tzv Tehnički dug nula što je jedan od najstrukturiranijih i najučinkovitijih načina za postupno uklanjanje tehničkog duga u aktivnostima osiguranja kvalitete / automatizacije. Da biste saznali više o tehnološkom dugu, Pogledaj ovaj video na pristupu smanjenju tehnološkog odjela.
Nadam se da ćete dobiti jasnu ideju o tome što je tehnički dug. Javite nam ako imate bilo kakvih pitanja vezanih uz to ili kako to riješiti u praksi.
Preporučena literatura
- Testiranje softvera Posao pisca tehničkog sadržaja Posao slobodnjaka
- Globalno testiranje softvera uskoro će doseći 28,8 milijardi dolara
- Savjeti za testiranje softvera za novake
- Kako održati motivaciju živom u ispitivačima softvera?
- Zen i umijeće testiranja softvera
- Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)
- Najbolji članci o testiranju softvera iz 2008
- Posao za QA pomoćnika za testiranje softvera