Menu

Hvad er teknisk gæld, og hvorfor bør QA-testere bekymre sig om det?

  • Vigtigste
  • Agil Test
  • Hvad er teknisk gæld, og hvorfor bør QA-testere bekymre sig om det?

what is technical debt

Prøv Vores Instrument Til At Fjerne Problemer

Teknisk gæld er en metaforisk idé, der hævder, at ligesom man kan støde på gældsproblemer inden for økonomi, støder softwareorganisationer på noget lignende i opbygningen af ​​ufærdigt arbejde under tidligere projekter og versionudgivelser / sprints.

Hvad er teknisk gæld?

Det repræsenterer den nødvendige indsats for at løse de problemer / mangler, der er tilbage i koden, når en applikation frigives. Med enkle ord - det er forskellen (i form af bugs) mellem hvad der forventes og hvad der leveres.

Når et udviklingsteam er optaget af at arbejde på et projekt og reparere fejl desværre, vises der mange nye fejl. Ud af disse, nogle er faste, og andre adskiller sig til senere udgivelse. Når denne forskellige problematik fortsætter med at stige, bliver det på et tidspunkt virkelig svært at frigive produktet til tiden uden problemer. Dette er den værste konsekvens af Teknisk gæld hvis det ikke tackles til tiden.

I denne artikel lærer du - hvad der er teknisk gæld, hvorfor QA-teamet skal være bekymret for det og vigtigst af alt, hvordan man styrer det.

hvad er teknisk gæld

billede kilde

Ward Cunningham , grundlæggeren af ​​wiki-software, udtænkt af denne idé langt tilbage i 1990'erne og tegner sig paralleller med virkningen af ​​dårlig gæld på den finansielle sektor, idet det bogstaveligt talt henvises til den usmagelige oplevelse af at skulle betale for store renter efter misligholdelse af lån.

bedste python editor mac os x

Udfordringen med at montere teknisk gæld pr. Sprint kan visualiseres i figur 1.

Det skal dog nævnes her, at der er en lille forskel i betydningen af ​​teknisk gæld (også kendt som kodegæld eller designgæld) fra dens tilsvarende analogi i finansverdenen - den tidligere er mere som en abstrakt idé uden matematiske ligninger til at visualisere, hvordan interessen virkelig akkumuleres.

stigende teknisk gæld

Fig. 1: Visualisering af den skalerbare stigning i teknisk gæld på tværs af sprints

Hvad du vil lære:

Hvorfor QA-hold lider mest på grund af teknisk gæld

Under en typisk softwaredesign og udviklingscyklus er der flere ting, der kan føre til en “ teknisk gæld ”Lignende situation– forkert dokumentation , utilstrækkelig test og fejlrettelse, manglende koordination mellem holdene eftermæle kode og forsinket refactoring , fravær af kontinuerlig integration og andre ude af kontrolfaktorer.

For eksempel, er det blevet observeret, at indsættelse af kodekopiering kan føre til alt imellem 25 til 35% ekstra arbejde.

youtube til mp3 converter gratis sikker

Imidlertid er det ingen steder udfordringer på grund af teknisk gæld mere tydeligt end i QA-test hvor testhold skal overholde uventede deadlines, og alt kan blive kastet ud af udstyr.

Hvor ofte har dine testere stødt på vanskeligheder i sidste øjeblik, da leveringschefen uventet kom og fortalte dem, ”Team! Vi er nødt til at rulle vores produkt ud om en uges tid, undskyld for ikke at kunne kommunikere dette i tide. Afslut med alle testopgaver hurtigst muligt, så vi kan være klar med demoen. ”

Dybest set kan enhver ubesvaret test eller 'løse det senere' tilgang føre til et teknisk gældslignende problem. Manglende testdækning , overdimensionerede brugerhistorier, korte sprints og andre eksempler på 'skarpe hjørner' på grund af leveringstryk spiller en stor rolle bag akkumuleringen af ​​teknisk gæld i QA-praksis.

Et rigtigt verdenseksempel

En amerikansk-baseret onlineforhandler med betydelig tilstedeværelse på tværs af flere websteder og mobilapps befandt sig i en reel 'teknisk gæld' -udfordring, da kompleksiteten af ​​testnettet begyndte at sammensætte sig med hver nye sprint .

Dette skete på grund af den pludselige stigning i antallet af mobile enheder, der skal testes, flere sprog, der skal understøttes, og mere end et halvt dusin sociale netværkssider, der skal udnyttes.

Med en automatiseringsdækning mindre end 40%, den tekniske gældsudfordring ville dukke op på følgende måder:

  • Overdreven tidsforbrug i frigivelsestest - Med antallet af browsere, enheder og scripts, der vokser med hver testsprint, vil frigivelsescyklussen blive forsinket, hvilket fører til tab af time-to-market.
  • De stigende omkostninger ved ansættelse - Antallet af testere, der var nødvendige for at støtte projektet, blev næsten fordoblet, hvilket svarer til $ 500.000 ekstra omkostninger
  • Kompleksitet i projektet - Med den voksende kompleksitet i projektet var det en udfordring at holde styr på testsager og fejl
  • For meget tid spildt i at jagte falske positive - Igen et udfald af stigende projektkompleksiteter.
  • Forøgelse af testudviklingsindsatsen med så meget som 60% - Det følger med territoriet

Teknisk gældsstyring i QA-praksis

De fleste QA-ledere ser impulsivt på tech-gæld som den rimelige konsekvens af at fokusere al din energi på den nuværende sprint alene, hvilket fører til at opnå testdækningen på en eller anden måde ved manuelle midler og ignorere automatisering fuldstændigt.

Dette er kendt som hurtig og beskidt tilgang som er blevet dækket i en blog af Martin Fowler, forfatteren af teknisk gældskvadrant .

Agile principper dikterer, at vi visualiserer teknologisk gældsproblem som en manglende evne til at opretholde og mødes QA-benchmarks .

Faktisk, baseret på en undersøgelse af National Institute of Standards and Technology (NIST) koster utilstrækkelige testværktøjer og metoder årligt den amerikanske økonomi mellem 22,2 $ og 59,5 milliarder dollars , med ca. halvdelen af ​​disse penge brugt på ekstra test af softwareudviklere og ca. halvdelen af ​​softwarebrugere for at undgå fejl.

I stedet for at reagere på fejl, når og når hændelsen sker, ville en proaktiv tilgang være at identificere mangler efter hver aktivitet eller opgave, der kan måles. Du kan gøre det hele manuelt, men i betragtning af de tusindvis af test case-scenarier for et gennemsnitligt projekt er automatiseret testkontrol en nødvendighed.

Klart, effektiv test kan hjælpe dig med at få seriøs grund i krigen mod teknisk gæld. Så hvad betyder det grundlæggende? Det betyder, hvor godt udstyret dit system er til at identificere fejl i den samlede applikation.

test effektivitet

Som ovenstående ligning viser, kan testcases effektivitet teoretisk nærme sig 100%, hvis antallet af fundne kunder (dvs. defekter efter produktionen) var blevet kortlagt nøjagtigt til antallet af defekter, der blev fundet på hvert trin i testdækningen.

For at have et veldesignet testleje, der nøjagtigt kan måle defekterne, så snart de kryber ind, er automatisering en forudsætning.

Test af automatisering hjælper dig med at minimere antallet af scripts, der udføres ved at rapportere resultater og sammenligne dem med tidligere testkørsler. Metoden eller processen, der bruges til at udføre automatisering, kaldes en test automatisering ramme .

Typiske eksempler ville være kommercielle ordinære eller gratis værktøjer såsom Selen, MonkeyTalk, robotter , Borland SilkCentral, HP Quality Center og IBM Rational Rose .

Tidligere blev QA / test ofte set af organisationer og deres softwareteams som en supportaktivitet til vigtigere forretningsleverancer og ikke en disciplineret praksis i sig selv, der ville kræve kernetilpasset fokus. Faktisk er en ikke-kernetilgang til QA / test nøjagtigt det, der i første omgang har ført til den løbende udfordring af teknisk gæld.

I betragtning af det hurtige tempo i udviklingen af ​​kvalifikationer inden for kvalitetssikring / test, der har fundet sted i det sidste årti, har organisationer en virkelig hård tid på at opgradere deres færdigheder og kompetencer til de ønskede minimumsniveauer pr.

Faktisk er der en voksende branchetendens til at klare sig med intet mindre end de mest erfarne fagfolk inden for test af automatisering - ligesom elitekommandoer til test / QA; de er kendt som softwareingeniører i test ( Siden ) og softwareudviklere i test ( SDiT ). Disse fagfolk er i høj efterspørgsel på grund af deres store erfaring i en valgt vertikal (f.eks. E-handel) eller en bestemt professionel kategori.

De fleste software- og produktudviklingsfirmaer, som vi taler nu, kæmper for at finde de ønskede, kvalificerede tekniske ressourcer i lyset af kortere leveringstider. Løsningen på denne udfordring er at samarbejde med en offshore QA-automatiseringsafspiller, der kan løse din mangel på færdigheder med den rigtige pool af SDiT / SEiT-ressourcer.

Andre ønskede egenskaber hos en outsourcing-spiller i QA / Testing, der viser sig nyttige, inkluderer en agil, disciplineret tilgang til projektudførelse, tilstrækkelig brancheerfaring inklusive praktisk adgang til genanvendelige automatiseringsrammer og testcases og sidst men ikke mindst en klar hensigt og evne til at tackle eksterne teamudfordringer og kulturelle sammenstød, så kunden ikke belastes med ekstra arbejde med at styre entreprenører.

Konklusion

Som enhver anden gæld kan teknisk gæld vise sig at være bane for virksomheder, og grundårsagen til dens ophobning er manglende gennemførelse af en proaktiv QA-praksis, der fjerner alle efterslæb inden for automatisering.

stadier af softwareudviklingens livscyklus

Om forfatter: Dette er gæstepost fra eInfochips-teamet. De er kommet med en unik tilgang kaldet Teknisk gæld nul som er en af ​​de mest strukturerede og effektive måder til gradvist at eliminere teknisk gæld i kvalitets- / automatiseringsaktiviteter. For at vide mere om teknisk gæld, se denne video om en tilgang til reduktion af teknologisk afd.

Håber du får den klare idé om, hvad der er teknisk gæld. Fortæl os, hvis du har spørgsmål relateret til det, eller hvordan du administrerer det i praksis.

Anbefalet læsning

^