Meny

Hva er teknisk gjeld og hvorfor bør QA-testere være bekymret for det?

  • Hoved
  • Agile Testing
  • Hva er teknisk gjeld og hvorfor bør QA-testere være bekymret for det?

what is technical debt

Prøv Instrumentet Vårt For Å Eliminere Problemer

Teknisk gjeld er en metaforisk idé som argumenterer for at akkurat som man kan støte på gjeldsproblemer i finans, møter programvareorganisasjoner noe lignende i oppbyggingen av uferdig arbeid under tidligere prosjekter og versjonsutgivelser / sprints.

Hva er teknisk gjeld?

Det representerer innsatsen som trengs for å fikse problemene / manglene som er igjen i koden når et program blir utgitt. Med enkle ord - det er forskjellen (når det gjelder feil) mellom det som forventes og det som leveres.

Når et utviklingsteam er opptatt med å jobbe med et prosjekt og fikse feil dessverre, vises det mange nye feil. Ut av disse, noen er faste og andre er forskjellige for senere utgivelse. Når denne forskjellige problemstillingen fortsetter å øke, blir det på et tidspunkt veldig vanskelig å frigjøre produktet i tide uten problemer. Dette er den verste konsekvensen av Teknisk gjeld hvis det ikke blir taklet i tide.

I denne artikkelen vil du lære - hva er teknisk gjeld, hvorfor QA-teamet bør være bekymret for det og viktigst av alt hvordan de skal håndtere det.

hva er teknisk gjeld

bilde kilde

Ward Cunningham , grunnleggeren av wiki-programvare, unnfanget av denne ideen helt tilbake på 1990-tallet, og tegnet paralleller med innvirkningen av dårlig gjeld på finansnæringen, og bokstavelig talt henviste til den usmakelige opplevelsen av å måtte betale for store rentepenger etter mislighold på lån.

java intervju kode spørsmål og svar

Utfordringen med å montere teknisk gjeld per sprint kan visualiseres i figur 1.

Det må imidlertid nevnes her at det er en liten forskjell i betydningen av teknisk gjeld (også kjent som kodegjeld eller designgjeld) fra dens tilsvarende analogi i finansverdenen - den tidligere er mer som en abstrakt idé , uten matematiske ligninger for å visualisere hvordan interessen virkelig akkumuleres.

økende teknisk gjeld

Figur 1: Visualisering av den skalerbare økningen i teknisk gjeld på tvers av sprints

Hva du vil lære:

Hvorfor QA-team lider mest på grunn av teknisk gjeld

I løpet av en typisk programvaredesign og utviklingssyklus er det flere ting som kan føre til en “ teknisk gjeld ”Som situasjon– feil dokumentasjon , utilstrekkelig testing og feilretting, manglende koordinering mellom lagene, arv kode og forsinket refactoring , fravær av kontinuerlig integrering og andre faktorer utenfor kontroll.

For eksempel, det har blitt observert at innsats for duplisering av kode kan føre til noe mellom 25 til 35% ekstra arbeid.

apk filplassering i Android-telefon

Imidlertid er det ingen steder utfordringer på grunn av teknisk gjeld mer tydelig enn i QA-testing der testteamene må overholde uventede tidsfrister, og alt kan bli kastet ut av utstyret.

Hvor ofte har testerne dine møtt vanskeligheter i det siste øyeblikket, da leveringssjefen uventet kom og sa til dem: “Team! Vi må rulle ut produktet om en ukes tid, beklager at vi ikke kan kommunisere dette i tide. Vennligst avslutt med alle testoppgavene, så vi kan være klare med demoen. ”

I utgangspunktet kan eventuelle tapte tester eller 'løse det senere' tilnærming føre til et teknisk gjeldslikt problem. Mangel på testdekning , store brukerhistorier, korte sprints og andre eksempler på 'skjæring av hjørner' på grunn av leveringspress spiller en stor rolle bak akkumuleringen av teknisk gjeld i QA-praksis.

Et ekte verdenseksempel

En amerikanskbasert onlineforhandler med betydelig tilstedeværelse på tvers av flere nettsteder og mobilapper befant seg i en 'teknisk gjeld' -utfordring i virkeligheten da kompleksiteten i testnettet begynte å sammensettes med hver nye sprint .

Dette skjedde på grunn av den plutselige økningen i antall mobile enheter som skal testes, flere språk som skal støttes, og mer enn et halvt dusin sosiale nettverk som skal utnyttes.

Med en automatiseringsdekning mindre enn 40%, den tekniske gjeldsutfordringen ville dukke opp på følgende måter:

  • Overdreven tidsforbruk i utgivelsestesting - Med antall nettlesere, enheter og skript som vokser med hver testsprint, vil utgivelsessyklusen fortsette å bli forsinket, noe som fører til tap av time-to-market.
  • De økende kostnadene ved å ansette - Antallet testere som var nødvendig for å støtte prosjektet, ble nesten fordoblet, noe som medførte $ 500 000 ekstra kostnader
  • Kompleksitet i prosjektet - Med den økende kompleksiteten i prosjektet ble det en utfordring å holde oversikt over testsaker og feil
  • For mye tid bortkastet i å jage falske positive - Igjen, et fall ut av økende prosjektkompleksitet.
  • Økning i testutviklingsinnsats med så mye som 60% - Det går med territoriet

Teknisk gjeldsstyring i QA-praksis

De fleste QA-ledere ser impulsivt på teknisk gjeld som den rimelige konsekvensen av å fokusere all energien din på den nåværende sprinten alene, noe som fører til å oppnå testdekningen på en eller annen måte gjennom manuelle midler, og ignorerer automatisering fullstendig.

Dette er kjent som rask og skitten tilnærming som har blitt dekket i en blogg av Martin Fowler, forfatteren av teknisk gjeldskvadrant .

Smidige prinsipper tilsier at vi visualiserer teknologisk gjeldsproblem som en manglende evne til å opprettholde og møte QA-referanser .

Faktisk, basert på en undersøkelse av National Institute of Standards and Technology (NIST), koster utilstrekkelige testverktøy og metoder årlig den amerikanske økonomien mellom $ 22,2 og 59,5 milliarder dollar , med omtrent halvparten av disse pengene brukt på ekstra testing av programvareutviklere og rundt halvparten av programvarebrukere for å unngå feil.

I stedet for å reagere på feil når og når hendelsen skjer, vil en proaktiv tilnærming være å identifisere feil etter hver aktivitet eller oppgave som kan måles. Du kan gjøre alt manuelt, men gitt de tusenvis av test case-scenariene for et gjennomsnittlig prosjekt, er automatisert testkontroll en nødvendighet.

Helt klart, effektiv testing kan hjelpe deg med å få alvorlig grunn i krigen mot teknisk gjeld. Så, hva betyr det egentlig? Det betyr hvor godt utstyrt systemet ditt er til å identifisere feil i den generelle applikasjonen.

testing effektivitet

Som ovenstående ligning viser, kan effektiviteten av testtilfeller teoretisk nærme seg til og med 100% hvis antall kunder som ble funnet feil (dvs. feil etter produksjonen) hadde blitt kartlagt nøyaktig til antall feil som ble funnet i hvert trinn i testdekningen.

For å ha et godt designet testleie som nøyaktig kan måle feilene så snart de kryper inn, er automatisering en forutsetning.

Testing av automatisering hjelper deg med å minimere antall skript som blir utført ved å rapportere resultater og sammenligne dem med tidligere testkjøringer. Metoden eller prosessen som brukes til å utføre automatisering kalles en test automasjon rammeverk .

Typiske eksempler vil være kommersielle verktøy eller gratis verktøy som Selenium, MonkeyTalk, roboter , Borland SilkCentral, HP Quality Center og IBM Rational Rose .

Tidligere ble QA / testing ofte sett på av organisasjoner og deres programvareteam som en støtteaktivitet for viktigere forretningsleveranser, og ikke en disiplinert praksis i seg selv som krever kjerne, dedikert fokus. Faktisk er en ikke-kjernetilnærming til QA / testing nettopp det som har ført til den pågående utfordringen med teknisk gjeld i utgangspunktet.

Tatt i betraktning det raske tempoet i evolusjon i QA / testing-ferdigheter som har skjedd i løpet av det siste tiåret, har organisasjoner det vanskelig å oppgradere sine ferdigheter og kompetanse til minimumsnivåene som er ønsket i henhold til gjeldende industristandarder.

Faktisk er det en økende trend i bransjen å nøye seg med intet mindre enn de mest erfarne fagfolk innen testing av automatisering - omtrent som elitekommandoer for testing / QA; de er kjent som programvareingeniører i test ( Siden ) og programvareutviklere i test ( SDiT ). Disse fagpersonene er i høy etterspørsel på grunn av deres store erfaring i en valgt vertikal (f.eks. E-handel) eller en bestemt profesjonell kategori.

nettjenestetesting ved hjelp av spørsmål om soapui-intervju

De fleste programvare- og produktutviklingsselskaper, som vi snakker nå, sliter med å finne de ønskede, kvalifiserte tekniske ressursene i møte med kortere leveringstider. Løsningen på denne utfordringen er å samarbeide med en offshore QA-automatiseringsspiller som kan håndtere mangel på ferdigheter med den rette mengden SDiT / SEiT-ressurser.

Andre ønskede egenskaper hos en outsourcing-spiller i QA / Testing som viser seg nyttige, inkluderer en smidig, disiplinert tilnærming til prosjektgjennomføring, tilstrekkelig bransjeerfaring, inkludert praktisk tilgang til gjenbrukbare automatiseringsrammer og testtilfeller, og sist men ikke minst, en klar hensikt og evne til å takle eksterne teamutfordringer og kulturelle sammenstøt, slik at klienten ikke blir belastet med ekstra arbeid med å administrere entreprenører.

Konklusjon

Som enhver annen gjeld, kan teknisk gjeld vise seg å være bedriftens bedrift, og grunnårsaken til akkumuleringen er manglende implementering av en proaktiv QA-praksis som fjerner alle etterslep i automatisering.

Om forfatter: Dette er gjestepost fra eInfochips-teamet. De har kommet opp med en unik tilnærming kalt Teknisk gjeld null som er en av de mest strukturerte og effektive måtene å gradvis eliminere teknisk gjeld i kvalitets- / automatiseringsaktiviteter. For å vite mer om teknisk gjeld, se denne videoen på en tilnærming for å redusere teknisk avd.

Håper du får den klare ideen om hva som er Teknisk gjeld. Gi oss beskjed hvis du har spørsmål knyttet til det, eller hvordan du håndterer det i praksis.

Anbefalt lesing

^