Meny

Vad är teknisk skuld och varför QA-testare borde oroa sig för det?

  • Huvud
  • Agile Testing
  • Vad är teknisk skuld och varför QA-testare borde oroa sig för det?

what is technical debt

Prova Vårt Instrument För Att Eliminera Problem

Teknisk skuld är en metaforisk idé som argumenterar för att precis som man kan stöta på skuldproblem inom ekonomi, stöter programvaruorganisationer på något liknande i uppbyggnaden av oavslutat arbete under tidigare projekt och versioner / sprints.

Vad är teknisk skuld?

Det representerar den ansträngning som krävs för att åtgärda de problem / defekter som finns kvar i koden när en applikation släpps. Med enkla ord - det är skillnaden (i termer av buggar) mellan vad som förväntas och vad som levereras.

När ett utvecklingsteam är upptagen med att arbeta med ett projekt och fixa buggar tyvärr visas många nya buggar. Ut ur dessa, vissa är fixade och andra skiljer sig åt för senare release. När denna olikartade fråga fortsätter att öka blir det vid ett tillfälle riktigt svårt att släppa produkten i tid utan några problem. Detta är den värsta konsekvensen av Teknisk skuld om det inte hanteras i tid.

I den här artikeln kommer du att lära dig - vad är teknisk skuld, varför QA-teamet bör vara bekymrad över det och viktigast av allt hur man hanterar det.

vad är teknisk skuld

bild källa

Ward Cunningham , grundaren av wiki-programvaran, tänkt på denna idé långt tillbaka på 1990-talet och drar paralleller med effekterna av osäkra fordringar på finansbranschen, vilket bokstavligen hänvisar till den otrevliga upplevelsen av att behöva betala för stora räntepengar efter att ha förfallit på lån.

bevisa det c # test svar

Utmaningen med att montera teknisk skuld per sprint kan visualiseras i figur 1.

Det måste dock nämnas här att det finns en liten skillnad i betydelsen av teknisk skuld (även känd som kodskuld eller designskuld) från motsvarande analogi i finansvärlden - den förra är mer som en abstrakt idé , utan matematiska ekvationer för att visualisera hur intresset verkligen ackumuleras.

ökande teknisk skuld

Figur 1: Visualisering av den skalbara ökningen av tekniska skulder över sprints

Vad du kommer att lära dig:

Varför QA-team lider mest på grund av teknisk skuld

Under en typisk programvarudesign och utvecklingscykel finns det flera saker som kan leda till en ” teknisk skuld ”Som situation– felaktig dokumentation , otillräcklig testning och bug fixing, brist på samordning mellan lag, arv kod och försenad refactoring , frånvaro av fortsatt integration och andra utom kontrollfaktorer.

Till exempelhar det observerats att insatser med koddublisering kan leda till allt mellan 25 till 35% extraarbete.

urval sorteringskod c ++

Det finns dock ingenstans utmaningar på grund av tekniska skulder tydligare än i QA-test där testteam måste uppfylla oväntade tidsfrister och allt kan slängas ur växeln.

Hur ofta har dina testare mött svårigheter i sista stund när leveranschefen oväntat kom och sa till dem: ”Team! Vi måste lansera vår produkt om en vecka, tyvärr att vi inte kan kommunicera detta i tid. Avsluta med alla testuppgifter omgående så att vi kan vara redo med demo. ”

I grund och botten kan alla missade tester eller 'lösa det senare' -metoden leda till ett tekniskt skuldliknande problem. Brist på testtäckning , överdimensionerade användarberättelser, korta sprintar och andra exempel på 'skärande hörn' på grund av leveranspress spelar en stor roll bakom ackumuleringen av teknisk skuld i QA-praxis.

Ett riktigt världsexempel

En USA-baserad online-återförsäljare med betydande närvaro på flera webbplatser och mobilappar befann sig i en verklig “teknisk skuld” -utmaning när komplexiteten i testnätet började förenas med varje ny sprinta .

Detta hände på grund av den plötsliga ökningen av antalet mobila enheter som skulle testas, flera språk som skulle stödjas och mer än ett halvt dussin sociala nätverkssajter som skulle utnyttjas.

Med en automatiseringstäckning mindre än 40%, den tekniska skuldutmaningen skulle dyka upp på följande sätt:

  • Överdriven tidsförbrukning vid släpptestning - Med antalet webbläsare, enheter och skript som växer med varje testsprint, kommer släppcykeln att fortsätta att fördröjas och leda till förlust av time-to-market.
  • De ökande kostnaderna för att anställa - Antalet testare som behövdes för att stödja projektet fördubblades nästan vilket innebar ytterligare 500 000 USD
  • Komplexitet i projektet - Med den växande komplexiteten i projektet blev det en utmaning att hålla reda på testfall och buggar
  • För mycket tid slösas bort i att jaga falska positiva resultat - Återigen ett fall av ökande projektkomplexiteter.
  • Ökning av testutvecklingsinsatsen med så mycket som 60% - Det går med territoriet

Teknik skuldhantering i QA-praxis

De flesta QA-chefer ser impulsivt på teknisk skuld som den rimliga konsekvensen av att fokusera all din energi på den aktuella sprinten ensam, vilket leder till att testtäckningen på något sätt uppnås på manuellt sätt och helt ignorerar automatisering.

Detta är känt som snabbt och smutsigt tillvägagångssätt som har behandlats i en blogg av Martin Fowler, författaren till teknisk skuldkvadrant .

Agila principer dikterar att vi visualiserar tekniska skuldproblem som en oförmåga att upprätthålla och möta QA-riktmärken .

Faktiskt, baserat på en undersökning av National Institute of Standards and Technology (NIST) kostar otillräckliga testverktyg och metoder årligen den amerikanska ekonomin mellan 22,2 $ och 59,5 miljarder dollar , med ungefär hälften av dessa pengar spenderade på extra test av programutvecklare och ungefär hälften av programanvändare för att undvika fel.

Istället för att reagera på fel när och när händelsen inträffar, skulle en proaktiv metod vara att identifiera defekter efter varje aktivitet eller uppgift som kan mätas. Du kan göra allt manuellt men med tanke på tusentals testfallsscenarier för ett genomsnittligt projekt är automatiserad testkontroll en nödvändighet.

Klart, effektiv testning kan hjälpa dig att få allvarlig mark i kriget mot teknisk skuld. Så, vad betyder det egentligen? Det betyder hur välutrustat ditt system är för att identifiera fel i den totala applikationen.

testningseffektivitet

Som ovanstående ekvation visar kan testfallets effektivitet teoretiskt närma sig till och med 100% om antalet kunder som hittat defekter (dvs. efterproduktionsfel) hade kartlagts exakt till antalet defekter som hittades i varje steg av testtäckningen.

För att ha en väldesignad testbädd som exakt kan mäta defekterna så snart de kryper in, är automatisering en förutsättning.

Testa automatisering hjälper dig att minimera antalet skript som körs genom att rapportera resultat och jämföra dem med tidigare testkörningar. Metoden eller processen som används för att utföra automatisering kallas ett test automatisering ramverk .

Typiska exempel är kommersiella hantverks- eller gratisverktyg som Selen, MonkeyTalk, robotar , Borland SilkCentral, HP Quality Center och IBM Rational Rose .

Tidigare sågs ofta kvalitetsbedömning / testning av organisationer och deras programvaruteam som en stödaktivitet för viktigare affärsleveranser, och inte en disciplinerad praxis i sig som kräver grundläggande, dedikerat fokus. I själva verket är en icke-kärna metod för QA / testning precis vad som har lett till den pågående utmaningen av teknisk skuld i första hand.

Med tanke på den snabba utvecklingen i QA / testkunskaper som har inträffat under det senaste decenniet har organisationer svårt att uppgradera sina färdigheter och kompetenser till de miniminivåer som önskas enligt nuvarande branschindex.

I själva verket finns det en växande branschtrend att nöja sig med inget mindre än de mest erfarna proffs som testar automatisering - ungefär som elitkommandon för test / QA; de är kända som mjukvaruutvecklare i test ( Eftersom ) och mjukvaruutvecklare i test ( SDiT ). Dessa yrkesverksamma är mycket efterfrågade på grund av sin stora erfarenhet av en vald vertikal (t.ex. e-handel) eller en viss yrkeskategori.

De flesta programvaru- och produktutvecklingsföretag, som vi talar nu, kämpar för att hitta de önskade, kvalificerade tekniska resurserna inför kortare leveranstider. Lösningen på denna utmaning är att samarbeta med en offshore QA-automationsspelare som kan hantera din kompetensbrist med rätt pool av SDiT / SEiT-resurser.

Andra önskade egenskaper hos en outsourcing-spelare i QA / Testing som visar sig vara användbara inkluderar en smidig, disciplinerad strategi för projektgenomförande, tillräcklig branscherfarenhet inklusive praktisk tillgång till återanvändbara automatiseringsramar och testfall, och sist men inte minst, en tydlig avsikt och förmåga att ta itu med avlägsna teamutmaningar och kulturella konflikter så att klienten inte belastas med extra arbete med att hantera entreprenörer.

Slutsats

Precis som alla andra skulder kan tekniska skulder visa sig vara företagets banor och grundorsaken till dess ackumulering är misslyckande med att genomföra en proaktiv QA-praxis som tar bort alla eftersläpningar inom automatisering.

intervjufrågor och svar på nätutvecklare

Om författare: Detta är ett gästinlägg av eInfochips-teamet. De har kommit med ett unikt tillvägagångssätt som kallas Tech Skuld noll vilket är ett av de mest strukturerade och effektiva sätten att gradvis eliminera teknisk skuld i kvalitets- / automatiseringsaktiviteter. Om du vill veta mer om teknisk skuld, kolla på denna videon om en metod för att minska teknisk avd.

Hoppas du får en klar uppfattning om vad som är teknisk skuld. Låt oss veta om du har några frågor relaterade till det eller hur du hanterar det i praktiken.

Rekommenderad läsning

^