Meniu

Ce este datoria tehnică și de ce ar trebui să fie îngrijorați testerii de calitate?

what is technical debt

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Datoria tehnică este o idee metaforică care susține că, la fel cum s-ar putea întâmpina probleme legate de datorii în finanțe, organizațiile software se confruntă cu ceva similar în acumularea de lucrări neterminate în timpul proiectelor anterioare și a lansărilor / sprinturilor de versiuni.

Ce este datoria tehnică?

Reprezintă efortul necesar pentru a remedia problemele / defectele care rămân în cod la lansarea unei aplicații. Cu cuvinte simple - este diferența (în termeni de bug-uri) între ceea ce este de așteptat și ceea ce este livrat.

Când, din păcate, o echipă de dezvoltare este ocupată să lucreze la un proiect și să remedieze erorile, apar multe erori noi. Din acestea, unele sunt fixe, iar altele sunt diferite pentru lansare ulterioară. Când diferențierea problemelor crește, la un moment dat devine cu adevărat dificil să eliberați produsul la timp, fără probleme. Aceasta este cea mai gravă consecință a Datoria tehnică dacă nu este abordat la timp.

În acest articol, veți afla - ce este datoria tehnică, de ce echipa de asigurare a calității ar trebui să fie preocupată de aceasta și cel mai important cum să o gestionați.

ce este datoria tehnologică

imagine sursă

Ward Cunningham , fondatorul software-ului wiki, conceput de această idee înapoi în anii 1990, făcând paralele cu impactul datoriei neperformante asupra industriei financiare, făcând literalmente aluzie la experiența neplăcută a faptului că trebuie să plătești bani excesivi ai dobânzii după neîndeplinirea obligațiilor la împrumuturi.

care dintre următoarele nu este o condiție care descrie un caz de testare?

Provocarea creșterii datoriei tehnice pe sprint poate fi vizualizată în Fig.1.

Totuși, trebuie menționat aici că există o ușoară diferență în semnificația datoriei tehnice (cunoscută și sub numele de datorie de cod sau datorie de proiectare) de analogia sa corespunzătoare în lumea finanțelor - prima este mai degrabă o idee abstractă , fără ecuații matematice care să vizualizeze modul în care se acumulează cu adevărat interesul.

montarea datoriei tehnice

Fig 1: Vizualizarea creșterii scalabile a datoriilor tehnologice între sprinturi

Ce veți învăța:

De ce suferă cel mai mult echipele QA din cauza datoriei tehnice

În timpul unui ciclu tipic de proiectare și dezvoltare software, există mai multe lucruri care pot duce la un „ datorii tehnice „Ca situație– documentare necorespunzătoare , testare inadecvată și remedierea erorilor, lipsa de coordonare între echipe, moştenire cod și refactorizarea întârziată , absență integrare continuă și alți factori în afara controlului.

De exemplu, s-a observat că eforturile de duplicare a codului pot duce la orice între 25 la 35% muncă în plus.

cea mai bună descărcare a convertorului YouTube în mp3

Cu toate acestea, nicăieri nu sunt provocări datorate datoriei tehnice mai evidente decât în ​​testarea controlului calității unde echipele de testare trebuie să respecte termenele neașteptate și totul poate fi aruncat din echipament.

Cât de des s-au confruntat testerii dvs. în ultimul moment când în mod neașteptat, managerul de livrare a venit și le-a spus: „Echipă! Trebuie să lansăm produsul peste o săptămână, ne pare rău că nu putem comunica acest lucru la timp. Vă rugăm să terminați urgent toate sarcinile de testare, astfel încât să putem fi gata cu demo-ul. ”

Practic, orice test ratat sau abordarea „rezolvă-l mai târziu” poate duce la o problemă de tip datoriile tehnologice. Lipsa acoperirii testelor , poveștile utilizatorilor supradimensionate, sprintele scurte și alte exemple de „tăiere a colțurilor” din cauza presiunii de livrare joacă un rol imens în spatele acumulării de datorii tehnice în practica QA.

Un exemplu real din lume

Un comerciant cu amănuntul online cu sediul în SUA, cu prezență semnificativă pe mai multe site-uri web și aplicații mobile, s-a trezit într-o provocare de „datorie tehnică” din lumea reală, atunci când complexitatea rețelei de testare a început să se compună cu fiecare nou sprint .

Acest lucru s-a întâmplat din cauza apariției bruște a numărului de dispozitive mobile care urmează să fie testate, a mai multor limbi care să fie acceptate și a mai mult de jumătate de duzină de site-uri de rețele sociale care să fie valorificate.

Cu o acoperire de automatizare mai mică de 40%, provocarea datoriei tehnologice ar apărea în următoarele moduri:

  • Consum excesiv de timp în testarea eliberării - Odată cu creșterea numărului de browsere, dispozitive și scripturi cu fiecare sprint de testare, ciclul de lansare va continua să întârzie, ducând la pierderea timpului de lansare pe piață.
  • Costul tot mai mare al angajării - Numărul testerilor necesari pentru susținerea proiectului aproape s-a dublat, ceea ce s-a tradus în costuri suplimentare de 500.000 USD
  • Complexitate în proiect - Odată cu complexitatea tot mai mare a proiectului, urmărirea cazurilor de testare și a erorilor devenea o provocare
  • Prea mult timp pierdut în urmărirea falselor pozitive - Din nou, o scădere a complexității proiectului în creștere.
  • Creșterea efortului de dezvoltare a testului cu până la 60% - Merge cu teritoriul

Managementul datoriilor tehnice în practicile QA

Majoritatea managerilor de asigurare a calității consideră impulsiv datoria tehnologiei ca fiind consecința rezonabilă a concentrării întregii energii asupra sprintului actual, ceea ce duce la realizarea acoperirii testului cumva prin mijloace manuale și ignoră complet automatizarea.

Acest lucru este cunoscut sub numele de abordare rapidă și murdară care a fost acoperit într - un blog de Martin Fowler, autorul cadranul datoriei tehnice .

Principiile agile dictează faptul că vizualizăm problema datoriilor tehnologice ca fiind o incapacitate de a susține și a ne întâlni Puncte de referință QA .

De fapt, pe baza unui sondaj de către Institutul Național de Standarde și Tehnologie (NIST), instrumentele și metodele de testare insuficiente costă anual economia SUA între 22,2 dolari și 59,5 miliarde de dolari , cu aproximativ jumătate din acești bani cheltuiți pentru testări suplimentare de către dezvoltatorii de software și aproximativ jumătate din utilizatorii de software pentru a evita eșecurile.

În loc să reacționăm la eșecuri pe măsură ce se întâmplă incidentul, o abordare proactivă ar fi identificarea defectelor după fiecare activitate sau sarcină care poate fi măsurată. Puteți face totul manual, dar având în vedere mii de scenarii de testare pentru un proiect mediu, controlul automatizat al testării este o necesitate.

Clar, testarea eficientă vă poate ajuta să câștigați teren serios în războiul datoriei tehnice. Deci, ce înseamnă practic? Înseamnă cât de bine echipat este sistemul dvs. pentru a identifica defectele din aplicația generală.

eficacitatea testării

Așa cum arată ecuația de mai sus, eficacitatea cazurilor de testare se poate apropia teoretic chiar de 100% dacă numărul defectelor găsite de clienți (adică defecte post-producție) ar fi fost mapat exact la numărul de defecte găsite în fiecare etapă a acoperirii testării.

Pentru a avea un pat de testare bine conceput, care poate măsura cu precizie defectele de îndată ce se strecoară, automatizarea este o condiție prealabilă.

Automatizarea testării vă ajută să minimizați numărul de scripturi executate raportând rezultatele și comparându-le cu testele anterioare. Metoda sau procesul utilizat pentru a executa automatizarea se numește test automatizare cadru .

Exemple tipice ar fi instrumente comerciale de vânzare sau gratuite, cum ar fi Selenium, MonkeyTalk, roboți , Borland SilkCentral, HP Quality Center și IBM Rational Rose .

În trecut, testarea QA / testarea a fost adesea văzută de organizații și de echipele lor de software ca o activitate de sprijin pentru livrabile de afaceri mai importante și nu o practică disciplinată în sine, care ar necesita o concentrare de bază dedicată. De fapt, o abordare non-core a QA / testare este tocmai ceea ce a condus la provocarea continuă a datoriilor tehnice, în primul rând.

Având în vedere ritmul rapid de evoluție a abilităților de QA / testare care a avut loc în ultimul deceniu, organizațiilor le este foarte greu să-și actualizeze abilitățile și competențele la nivelurile minime dorite conform punctelor de referință actuale ale industriei.

De fapt, există o tendință în creștere a industriei de a face față cu nimic mai puțin decât cei mai experimentați profesioniști în automatizarea testelor - un fel de comanda de elită de testare / QA; sunt cunoscuți ca ingineri de software în test ( De cand ) și dezvoltatorii de software în test ( SDiT ). Acești profesioniști sunt foarte solicitați datorită experienței lor vaste într-o verticală aleasă (de exemplu, comerț electronic) sau unei anumite categorii profesionale.

Majoritatea companiilor de dezvoltare de software și produse, așa cum vorbim acum, se luptă să găsească resursele tehnice dorite și calificate în fața unor termene de livrare mai scurte. Soluția la această provocare este de a fi partener cu un jucător de automatizare QA offshore care poate rezolva deficitul de abilități cu rezerva corectă de resurse SDiT / SEiT.

anime tv toate gratuite pentru tine

Alte atribute dorite ale unui jucător de externalizare în QA / Testare care se dovedesc utile includ o abordare agilă și disciplinată a execuției proiectului, o experiență suficientă din industrie, inclusiv accesul practic la cadrele de automatizare reutilizabile și la cazurile de testare și, nu în ultimul rând, o intenție clară și capacitatea de a aborda provocările la distanță ale echipei și ciocnirile culturale, astfel încât clientul să nu fie împovărat cu muncă suplimentară în gestionarea contractanților.

Concluzie

La fel ca orice altă datorie, datoria tehnică se poate dovedi a fi pierderea întreprinderilor, iar cauza principală a acumulării acesteia este eșecul de a implementa o practică de QA proactivă care elimină toate restanțele din automatizare.

Despre autor: Aceasta este o postare invitată de echipa eInfochips. Au venit cu o abordare unică numită Datorie tehnică zero care este una dintre cele mai structurate și eficiente modalități de eliminare treptată a datoriei tehnice în activitățile de asigurare a calității / automatizare. Pentru a afla mai multe despre datoria tehnologică, vizionați acest videoclip pe o abordare de reducere a departamentului de tehnologie.

Sper că veți avea o idee clară despre ceea ce este datoria tehnică. Spuneți-ne dacă aveți întrebări legate de acesta sau cum să îl gestionați în practică.

Lectură recomandată

^