5 sfaturi pentru a asigura o dezvoltare software fără erori

Aplicația dvs. software are erori? Bineînțeles că da, deoarece fiecare program software disponibil acolo are probleme și povestea software-ului fără erori este un mit. Cu toate acestea, este încă posibil să se minimizeze în mod semnificativ erorile, erorile și problemele de securitate urmând câteva tehnici de reducere livrești, dar practice.

Există multă disciplină atunci când vine vorba de urmărirea erorilor, deoarece necesită încurajarea tuturor să respecte regulile. În special în startup-uri și industriile conduse de creativitate, poate fi destul de dificil să descurajăm orice comunicare informală. De fapt, în multe cazuri, oamenii nu numesc „urmărirea erorilor” drept partea lor cea mai concentrată a unui proiect.

Despre ce este de fapt urmărirea erorilor?

Potrivit Technopedia: „ Urmărirea erorilor este un proces folosit de personalul de asigurare a calității și de programatori pentru a ține evidența problemelor software și a rezoluțiilor. „

Prin urmare, un sistem de urmărire a erorilor gestionează toate informațiile despre erorile raportate și ține evidența stării fiecărei erori. Cu siguranță vedeți nevoia de informații extinse în timp ce urmăriți problemele. Furnizarea de date suficiente nu necesită doar o cantitate imensă de timp, ci și abilități abundente în domeniul dezvoltării software.

Clasificarea erorilor

Există trei tipuri de erori software:

• Specificații incorecte
• Defecte de implementare
• Lipsește specificația

Oricare dintre aceste tipuri de erori poate fi ușor clasificat ca o problemă critică (sau reclasificat ca o îmbunătățire). Mai înainte sunt menționate câteva dintre liniile directoare de reclasificare utilizate de Sam Hatoum, fondatorul Xolv.io.

• Specificarea incorectă ne provoacă o pierdere? De exemplu, specificațiile indică numărul de clicuri de urmărire, când ar trebui să urmărească cheltuielile Reclasificare Bug.
• Poate fi neglijat defectul de implementare? De exemplu, fontul web este instalat atunci când ar trebui să fie încorporat în software.
• Specificația lipsă implică funcții noi? De exemplu, utilizatorii nu pot să partajeze și să editeze detaliile profilului lor pe rețelele sociale.

Miza este ridicată pentru managerii de produs pentru a clasifica eficient erorile, deoarece echipa de dezvoltare este instruită să acorde prioritate erorilor față de orice altă activitate. Dezvoltatorii nu vor funcționa sau nimic altceva până când toate erorile nu vor fi eliminate.

Formarea standardelor de calitate a echipei

Atunci când o echipă de proiectare și dezvoltare decide dacă un virus de aplicație poate fi reclasificat sau nu ca îmbunătățire, acel proces de decizie indică implicit standardele de calitate ale echipei. De exemplu, un proprietar de marcă care pune accent pe imagini de înaltă calitate ar putea avea o toleranță scăzută la discrepanțe de design. În schimb, ar reclasifica aceste probleme ca bug-uri.

Un sistem consistent de reclasificare vă permite să adaptați în mod continuu așteptările față de realitate, menținând în același timp o abordare structurată de livrare care pune standardele de calitate a echipei dumneavoastră pe primul loc.

Eșecuri bug-uri

Studii recente susțin că aproape 40% dintre defecțiunile sistemului sunt cauzate de erori de software, în timp ce alte probleme de securitate și vulnerabilități ale programului reprezintă 60%, cauzate de probleme comune legate de memorie și concurență. Reducerea erorilor software din aplicația dumneavoastră este cea mai bună modalitate de a crește securitatea, stabilitatea și fiabilitatea software-ului dumneavoastră.

Sfaturi pentru a asigura o dezvoltare software fără erori

În timpul dezvoltării instrumentului de înregistrare SmartInspect, dezvoltatorii au folosit multe metode pentru a menține calitatea ridicată a sistemului lor. Lista menționată mai sus conține câteva dintre tehnicile pe care le-au folosit.

1. Crearea spațiului pentru comunicare

Detectarea și raportarea erorilor necesită abilitățile de identificare a informațiilor relevante care sunt apoi adăugate în fiecare raport de problemă. Există multe instrumente de urmărire a erorilor și de asigurare a calității, cum ar fi Usersnap, care oferă posibilitatea de a atașa automat informațiile necesare. Cu toate acestea, va exista întotdeauna loc pentru lipsa sau înțelegerea greșită a informațiilor, ceea ce duce la necesitatea unei comunicări adecvate.

În anumite scenarii de testare, nu există loc pentru acest tip de dezvăluire între dezvoltatori și testeri. Întrebări precum: „Cum pot lua legătura cu experții responsabili?” sau „Este în regulă să ceri feedback prin telefon sau e-mail?” trebuie să fie răspuns la începutul procesului de urmărire a erorilor.

Pentru a evita neînțelegerile din partea testatorilor și dezvoltatorilor, încercați să aduceți pe toată lumea pe aceeași pagină și să creați o cultură orientată spre feedback, în care munca ambelor părți este respectată în același mod.

2. Păstrați-l unul la unu

Evitați să discutați despre erori într-o întâlnire de proiect. Acum nu mă înțelege greșit. Nu este nimic rău în lucrul în echipă, reproducerea și remedierea erorilor. Dar nu discutați problemele în ședințele prelungite cu întregul cabinet. Potrivit lui Thomas Peham, un tech-blogger la Usersnap.com, raportarea erorilor și apoi discutarea lor în următoarea fază de „retestare” de dezvoltare este o abordare destul de lentă.

Este, într-adevăr, mult mai eficient să-l păstrezi unul la unu. Așa cum a scris Yegor în articolul său despre cele 5 principii ale urmăririi erorilor, fiecare raport de eroare este legat între două persoane - specificatorul și soluționarea problemelor. Indiferent de câte persoane sunt implicate în proces, există doar 2 responsabilități principale (cu două roluri diferite) pentru rezolvarea unei probleme raportate.

3. Asigurați-vă un buy-in din partea echipei dvs

Dacă întreaga ta echipă nu îl folosește, o bază de date bună de urmărire a erorilor ar fi ineficientă. Cel mai bine este să începeți prin a determina toate părțile interesate (serviciul clienți, asigurarea calității, manageri de proiect și dezvoltatori) să evalueze instrumentele și să încerce să ia o decizie împreună; înregistrarea și abordarea defectelor într-o manieră consecventă prin utilizarea aceluiași sistem.

Dacă te lupți să aduci oameni la bord, iată ce poți face;

Pentru dezvoltatori, stabiliți legea acceptării rapoartelor de erori prin baze de date individuale și nu prin orice altă metodă. Când testerii vă trimit e-mailuri cu feedback, pur și simplu cereți-le să arunce rapoartele în sistemul de informații. Pe lângă faptul că se asigură că lucrurile rămân organizate, acest lucru ajută și la raportare, oferind toate informațiile necesare și definind câmpurile necesare.

O altă modalitate de a crea un proces mai eficient este să ai QA sau să ai suport pentru verificarea erorilor de la clienți și să adaugi pașii exacti în baza de date înainte ca dezvoltatorii să fie notificați. Urmărirea eficientă a problemelor software este unul dintre cele mai esențiale aspecte ale unui cadru de management de proiect fiabil și consistent.

• Un depanator bun

Dacă utilizați sisteme precum Visual Studio sau Delphi, aveți deja acces la un depanator extrem de puternic pe care ar trebui să îl utilizați. În cazul unui mediu de scripting în care dezvoltatorii încearcă adesea să elimine erorile prin încercare și eroare, procesul nu numai că devine o modalitate greoaie de identificare și rezolvare a problemelor, dar este și foarte periculos dacă nu înțelegeți pe deplin codul dvs. și nu puteți parcurge-l cu un depanator. Fă-ți o favoare obținând o platformă bună de depanare pentru echipa ta - există aplicații de depanare pentru aproape orice.

4. Aflați ce înseamnă o eroare „închisă”.

Ați fost vreodată implicat într-o discuție despre închiderea unei erori? Ei bine, felicitări, ați fost în cea mai proastă situație posibilă de urmărire a erorilor care ar putea avea loc vreodată.

Dacă vă aflați într-o discuție despre „starea erorii”, luați în considerare să faceți un pas înapoi și să vă puneți următoarele întrebări:

• A cui este responsabilitatea de a accepta rezultatele?
• Care sunt criteriile de acceptare?
• Cine este responsabil pentru darea ordinului?

Aruncă o privire la sensul cuvântului „închis”. În majoritatea echipelor de dezvoltare, o eroare este închisă de persoana care a remediat eroarea. Peham recomandă închiderea raportului de eroare de către persoana care a raportat problema. Odată ce soluția pentru o anumită eroare este prezentată de dezvoltator, reporterul ar trebui să fie rugat să închidă raportul. Acest lucru ar asigura că feedback-ul este o soluție suficientă pentru încurcăturile software.

5. Mașini virtuale

Pentru a testa software-ul pentru erori pe mai multe sisteme de operare și medii diferite, ar trebui să utilizați mașini virtuale cu instrumente precum Virtual PC sau alt software de virtualizare disponibil. Puteți economisi tone de timp prin această metodă, deoarece puteți copia, partaja și reseta cu ușurință mașinile virtuale, permițându-vă să testați software-ul pe tot felul de configurații.

Este întotdeauna de preferat să creați diferite imagini standard pentru toate sistemele de operare pe care le testați în mod regulat și să le puneți pe un server de fișiere. Când aveți nevoie de o configurație foarte specifică pentru a testa ceva, puteți începe cu una dintre imaginile de bază fără a instala sistemul de operare, software-ul și driverele necesare și așa mai departe.

Nu este un concept nou

Când Hatoum a venit cu acest concept, a aflat că ideea de software Zero-Bug nu este una nouă. De fapt, există încă din anii 1960, ca multe dintre filozofiile uitate ale școlii vechi.

Legendarul expert în calitate, Phillip Crosby, a inventat termenul Zero-Defect în timp ce lucra la Martin Company sau așa cum este cunoscută în prezent „Lockheed Martin”, unde s-a raportat că au obținut „o reducere cu 54% a defectelor hardware în cadrul auditului guvernamental”.

Inițial, tehnica Zero-Defect a fost folosită în producția aerospațială în anii 60, iar apoi a fost aplicată în producția de automobile în anii 1990. Există multe asemănări între industria de producție și livrarea de software.

Populara modalitate de management agil Kanban, de exemplu, a apărut din sistemul de producție Toyota. Ceea ce ne spune, practic, este că putem analiza cu ușurință aceste procese de producție pentru inspirație tehnologică în dezvoltarea de software sau aplicații, iar Zero-Bug este una dintre acele inspirații.

Costul extrem de îndeplinire a standardului este însă o critică majoră la adresa abordării Zero-Defect. Și dacă este implementat incorect, acest lucru poate fi într-adevăr adevărat. În abordarea Zero-Bug, Hatoum s-a ocupat direct de această problemă prin reclasificarea erorilor în funcții și îmbunătățiri semnificative, permițând controlul costului prin standardele de calitate ale echipei.

Începe azi

În calitate de utilizatori de tehnologie și dezvoltatori, puteți începe să parcurgeți toate erorile existente și să le clasificați utilizând sistemul menționat mai sus. Dacă credeți că aveți sute de mii de probleme, acesta ar putea fi un moment bun pentru a le întârzia și a începe din nou. Nu vă faceți griji, puteți oricând să mutați erorile din arhive în domeniul curent după cum aveți nevoie.

Echipa de dezvoltare nu trebuie neapărat să aștepte până la finalizarea întregului exercițiu de clasificare înainte de a începe să elimine bug-urile; pot începe imediat ce câteva erori sunt clasificate. Echipa nu trebuie să înceapă să lucreze la alte elemente din stoc până când toate articolele sunt „eliberate de erori” sau reclasificate. Tocmai această regulă îi obligă pe managerii de produs să prioritizeze corect noile lucrări.

Rezumând

Fiecare eroare raportată într-un proiect necesită timp suplimentar pentru a fi remediată. Urmărirea erorilor necesită, prin urmare, abilități mari de comunicare din partea persoanelor care urmăresc erorile, precum și sensibilitate din partea celor care le repară. Cu ajutorul hackurilor de urmărire menționate mai sus, echipa dvs. poate încerca să fie mai productivă în timp ce raportează orice fel de obstacol tehnologic sau de securitate.