Menu

Wat is technische schuld en waarom zouden QA-testers zich er zorgen over moeten maken?

  • Hoofd
  • Agile Testen
  • Wat is technische schuld en waarom zouden QA-testers zich er zorgen over moeten maken?

what is technical debt

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Technische schuld is een metaforisch idee dat stelt dat software-organisaties, net zoals men in de financiële wereld tegen schuldenproblemen kan aanlopen, iets soortgelijks tegenkomen bij de opbouw van onafgemaakt werk tijdens eerdere projecten en versie-releases / sprints.

Wat is technische schuld?

Het vertegenwoordigt de inspanning die nodig is om de problemen / defecten op te lossen die in de code blijven wanneer een applicatie wordt vrijgegeven. In eenvoudige bewoordingen: het is het verschil (in termen van bugs) tussen wat wordt verwacht en wat wordt geleverd.

Wanneer een ontwikkelteam druk bezig is met het werken aan een project en het oplossen van bugs, verschijnen er helaas veel nieuwe bugs. Uit deze, sommige zijn opgelost en sommige zijn anders voor latere release. Wanneer dit verschil in problemen steeds groter wordt, wordt het op een gegeven moment erg moeilijk om het product zonder problemen op tijd op de markt te brengen. Dit is het ergste gevolg van Technische schuld als het niet op tijd wordt aangepakt.

In dit artikel leert u wat technische schuld is, waarom het QA-team zich er zorgen over moet maken en vooral hoe u deze moet beheren.

wat is technische schuld

beeld bron

Ward Cunningham , de grondlegger van wiki-software, bedacht dit idee al in de jaren negentig, parallellen trekken met de impact van dubieuze debiteuren op de financiële sector, letterlijk verwijzend naar de onsmakelijke ervaring van het moeten betalen van buitensporige rentegeld na het in gebreke blijven van leningen.

beste muziek mp3-download voor Android

De uitdaging van het opbouwen van technische schulden per sprint kan worden gevisualiseerd in figuur 1.

Hier moet echter worden vermeld dat er een klein verschil is in de betekenis van technische schuld (ook bekend als codeschuld of ontwerpschuld) en de overeenkomstige analogie in de financiële wereld - de eerste is meer een abstract idee , zonder wiskundige vergelijkingen om te visualiseren hoe de rente zich werkelijk ophoopt.

oplopende technische schuld

Figuur 1: Visualisatie van de schaalbare toename van technische schulden over sprints heen

Wat je leert:

Waarom QA-teams het meest lijden onder technische schulden

Tijdens een typische software-ontwerp- en ontwikkelingscyclus zijn er verschillende dingen die kunnen leiden tot een ' technische schuld 'Zoals situatie– onjuiste documentatie ​ onvoldoende testen en bugfixes, gebrek aan coordinatie tussen teams, erfenis code en vertraagde refactoring , afwezigheid van continue integratie en andere onbeheerste factoren.

Bijvoorbeeldis waargenomen dat inspanningen voor codeduplicatie kunnen leiden tot alles daartussenin 25 naar 35% extra werk.

world of warcraft privéserver vanille

Nergens zijn de uitdagingen als gevolg van technische schuld duidelijker dan bij QA-testen waar testteams onverwachte deadlines moeten halen en alles uit de hand kan lopen.

Hoe vaak hebben uw testers op het laatste moment met dilemma's te maken gehad toen de bezorgmanager onverwachts kwam en zei: “Team! We moeten ons product over een week uitrollen, sorry dat we dit niet op tijd kunnen communiceren. Rondt u alstublieft af met alle testtaken, zodat we klaar kunnen zijn met de demo. '

Kortom, elke gemiste tests of 'los het later op' -benadering kan leiden tot een technisch schuldachtig probleem. Gebrek aan testdekking , grote gebruikersverhalen, korte sprints en andere voorbeelden van 'bezuinigingen' als gevolg van leveringsdruk spelen een grote rol achter de accumulatie van technische schulden in de QA-praktijk.

Een echt voorbeeld

Een in de VS gevestigde online retailer met een aanzienlijke aanwezigheid op meerdere websites en mobiele apps bevond zich in een echte 'technische schuld'-uitdaging toen de complexiteit van de testmesh zich begon toe te voegen met elke nieuwe sprint ​

Dit gebeurde vanwege de plotselinge toename van het aantal te testen mobiele apparaten, meerdere te ondersteunen talen en meer dan een half dozijn sociale netwerksites die moesten worden gebruikt.

Met een automatiseringsdekking van minder dan 40%, de uitdaging op het gebied van technische schulden zou zich op de volgende manieren voordoen:

  • Overmatig tijdverbruik bij het testen van releases - Met het aantal browsers, apparaten en scripts dat met elke testsprint groeit, zou de release-cyclus blijven vertragen, wat zou leiden tot een verlies van time-to-market.
  • De stijgende kosten van aanwerving - Het aantal testers dat nodig was om het project te ondersteunen, verdubbelde bijna, wat zich vertaalde in $ 500.000 extra kosten
  • Complexiteit in project - Met de groeiende complexiteit van projecten, werd het bijhouden van testcases en bugs een uitdaging
  • Er wordt te veel tijd verspild aan het najagen van false positives - Nogmaals, een uitval van toenemende projectcomplexiteit.
  • Verhoging van de inspanning voor het ontwikkelen van tests met maar liefst 60% - Het hoort bij het territorium

Tech Debt Management in QA-praktijken

De meeste QA-managers beschouwen technische schulden impulsief als het redelijke gevolg van het besteden van al je energie aan de huidige sprint alleen, wat ertoe leidt dat je de testdekking op de een of andere manier handmatig bereikt en automatisering volledig negeert.

Dit staat bekend als de snelle en vuile aanpak die is behandeld in een blog van Martin Fowler, de auteur van de technische schuldkwadrant ​

Agile-principes schrijven voor dat we het technische schuldenprobleem visualiseren als een onvermogen om hoog te houden en eraan te voldoen QA-benchmarks ​

Eigenlijk, op basis van een enquête door het National Institute of Standards and Technology (NIST) kosten onvoldoende testtools en -methoden jaarlijks de Amerikaanse economie tussen $ 22,2 en $ 59,5 miljard , waarbij ongeveer de helft van dit geld wordt besteed aan extra testen door softwareontwikkelaars en ongeveer de helft door softwaregebruikers om storingen te voorkomen.

In plaats van te reageren op storingen als en wanneer het incident zich voordoet, zou een proactieve benadering erin bestaan ​​om defecten te identificeren na elke activiteit of taak die kan worden gemeten. U kunt het allemaal handmatig doen, maar gezien de duizenden testcasescenario's voor een gemiddeld project, is geautomatiseerde testcontrole een noodzaak.

Duidelijk, effectief testen kan u helpen serieus terrein te winnen in de strijd tegen technische schulden. Dus, wat betekent het eigenlijk? Het betekent hoe goed uw systeem is uitgerust om defecten in de algehele toepassing te identificeren.

effectiviteit testen

Zoals de bovenstaande vergelijking laat zien, kan de effectiviteit van testcases theoretisch zelfs de 100% benaderen als het aantal door de klant gevonden defecten (d.w.z. postproductiedefecten) precies in kaart was gebracht op het aantal defecten dat in elke testfase werd gevonden.

Om een ​​goed ontworpen testbed te hebben dat de defecten nauwkeurig kan meten zodra ze binnensluipen, is automatisering een vereiste.

Automatisering testen helpt u het aantal scripts dat wordt uitgevoerd te minimaliseren door resultaten te rapporteren en deze te vergelijken met eerdere testruns. De methode of het proces dat wordt gebruikt om automatisering uit te voeren, wordt een test genoemd automatisering kader ​

Typische voorbeelden zijn in de handel verkrijgbare of gratis tools zoals Selenium, MonkeyTalk, robots , Borland SilkCentral, HP Quality Center en IBM Rational Rose ​

hoe je een e-mailadres kunt vervalsen

In het verleden werd QA / testen door organisaties en hun softwareteams vaak gezien als een ondersteunende activiteit voor belangrijkere bedrijfsresultaten, en niet als een gedisciplineerde praktijk op zich die een kerngerichte, toegewijde focus zou vereisen. In feite is een niet-kernbenadering van QA / testen precies wat heeft geleid tot de voortdurende uitdaging van technische schulden in de eerste plaats.

Gezien de snelle evolutie in QA / testvaardigheden die zich de afgelopen tien jaar hebben voorgedaan, hebben organisaties het erg moeilijk om hun vaardigheden en competenties te upgraden naar de gewenste minimumniveaus volgens de huidige benchmarks in de branche.

In feite is er een groeiende trend in de branche om het te doen met niets minder dan de meest ervaren professionals in het testen van automatisering - een beetje zoals de elite commando's van testen / QA; ze staan ​​bekend als software-ingenieurs in test ( Sinds ) en softwareontwikkelaars in test ( SDiT ​Er is veel vraag naar deze professionals vanwege hun uitgebreide ervaring in een gekozen branche (bijv. E-commerce) of een bepaalde beroepscategorie.

De meeste software- en productontwikkelingsbedrijven worstelen op dit moment met het vinden van de gewenste, gekwalificeerde technische middelen in het licht van kortere levertijden. De oplossing voor deze uitdaging is om samen te werken met een offshore QA-automatiseringsspeler die uw vaardigheidstekort kan aanpakken met de juiste pool van SDiT / SEiT-middelen.

Andere gewenste eigenschappen van een outsourcing-speler in QA / Testing die nuttig blijken te zijn, zijn onder meer een Agile, gedisciplineerde benadering van projectuitvoering, voldoende branche-ervaring inclusief hands-on toegang tot herbruikbare automatiseringsframeworks en testcases, en last but not least, een duidelijke intentie en het vermogen om teamuitdagingen en culturele conflicten op afstand aan te pakken, zodat de klant niet wordt belast met extra werk bij het managen van aannemers.

Gevolgtrekking

Net als elke andere schuld kan technische schuld de vloek van ondernemingen blijken te zijn en de hoofdoorzaak van de accumulatie ervan is het niet implementeren van een proactieve QA-praktijk die alle achterstanden in automatisering wegneemt.

Over de auteur: Dit is een gastpost van het eInfochips-team. Ze hebben een unieke aanpak bedacht, genaamd Tech schuld nul wat een van de meest gestructureerde en efficiënte manieren is om geleidelijk technische schulden bij QA / automatiseringsactiviteiten weg te werken. Om meer te weten over technische schulden, Bekijk deze video over een aanpak om de technische afdeling te verminderen.

Ik hoop dat je een duidelijk idee krijgt van wat technische schuld is. Laat het ons weten als u hier vragen over heeft of hoe u deze in de praktijk kunt aanpakken.

Aanbevolen literatuur

^