Această întrebare are deja răspunsuri aici :
Răspuns
Cel mai aproape de o aplicație fără erori, mai scump devine. Este ca și cum ai viza 100% acoperirea codului: cheltuiți aceeași cantitate de timp și bani obținând de la 0% la 95%, de la 95% la 99% și de la 99% la 99,9%.
Aveți nevoie de acest supliment de 0,1% din acoperirea sau calitatea codului? Probabil da, dacă lucrați la un produs software care controlează sistemul de răcire al unui reactor nuclear. Probabil că nu dacă lucrați la o aplicație comercială.
De asemenea, pentru a crea software de înaltă calitate este nevoie de o abordare foarte diferită . Nu puteți solicita doar unei echipe de dezvoltatori care și-au petrecut viața scriind aplicații de afaceri să creeze o aplicație aproape fără erori. Software-ul de înaltă calitate necesită diferite tehnici, cum ar fi dovadă formală , ceva ce cu siguranță nu doriți să utilizați într-o aplicație de afaceri, din cauza costului extrem de ridicat pe care îl reprezintă.
După cum am explicat în unul dintre articolele mele :
-
Aplicațiile de afaceri nu trebuie să vizeze calitatea necesară pentru software-ul critic pentru viață, deoarece dacă acele aplicații de afaceri eșuează din când în când, nu o fac ” Nu contează. Am văzut erori și perioade de nefuncționare pe site-urile probabil ale fiecărei mari corporații, Amazon fiind singura excepție. Acest timp de nefuncționare și acele bug-uri sunt enervante și poate costa companiei câteva mii de dolari pe lună, dar remedierea acestuia ar fi mult mai scumpă.
-
Costul ar trebui să fie principalul obiectiv, și ar trebui studiată pragmatic. Să ne imaginăm o eroare care afectează 5 000 de clienți și este atât de importantă încât acei clienți vor pleca pentru totdeauna. Este important? Da? Gândiți-vă mai mult. Ce se întâmplă dacă spun că fiecare dintre acești clienți plătește 10 USD pe an și că va plăti? a costat aproape 100 000 USD pentru remedierea erorii? Remedierea erorilor pare acum mult mai puțin interesantă.
Acum, pentru a răspunde în mod specific la întrebări:
de ce sunt raportate erorile chiar și după ce am trecut prin atâta testare? Este problema cerințelor noastre? Clientul nostru nu pare fericit pentru nimic din ce oferim? facem ceva incorect?
O mulțime de lucruri pot merge prost. Prin testare, vrei să spui testarea automată reală? Dacă nu, aceasta este o problemă uriașă. Înțeleg testerii cerințele? Comunicați cu clientul în mod regulat – cel puțin o dată pe iterație, cel mai bine reprezentantul clientului este imediat accesibil la fața locului de către orice membru al echipei dvs. ? Iterațiile dvs. sunt suficient de scurte? Dezvoltatorii își testează propriul cod?
În mod similar cu Ei scriu lucrurile potrivite articol legat mai sus, ia un raport de bug și studiază de ce a apărut în primul rând această eroare și de ce a fost ratată de fiecare tester . Acest lucru vă poate oferi câteva idei despre lacunele din procesul echipei dvs.
Într-un punct important de luat în considerare: clientul dvs. plătește pentru remedierea erorilor? Dacă nu, poate fi încurajat să ia în considerare o mulțime de lucruri fii un bug. Fă-l să plătească pentru timpul petrecut pe bug-uri va reduce considerabil numărul de rapoarte de bug-uri.
A dezvoltat cineva vreo aplicație care a fost fără erori? Care este procesul? De ce nu putem implementa aplicația cu erori minore? Ar trebui să fim perfecționisti?
Eu. „Am scris o aplicație pentru mine în weekendul trecut și nu am găsit nicio eroare până acum.
Erorile sunt doar erori atunci când sunt raportate. Așadar, în teorie, a avea o aplicație fără erori este total posibil: dacă nu este folosit de nimeni, nu va mai fi nimeni care să raporteze erori.
Acum, scrierea unei aplicații pe scară largă care se potrivește perfect cu specificația și s-a dovedit a fi corectă (vezi dovada formală menționată mai sus) este o poveste diferită. Dacă acesta este un proiect critic pentru viață, acesta ar trebui să fie obiectivul tău (ceea ce nu înseamnă că aplicația ta va nu conține erori).
Este scenariul actual procesul corect de dezvoltare și testare? Dacă nu, care este o modalitate eficientă în care dezvoltatorii, testerii și clientul obțin împreună beneficiul maxim?
-
Pentru a ne înțelege reciproc , ar trebui să comunice. Nu asta se întâmplă în majoritatea companiilor pe care le-am văzut. În majoritatea companiilor, managerul de proiect este singurul care vorbește cu clientul (uneori cu un reprezentant).Apoi, împărtășește (uneori parțial) înțelegerea cerințelor cu dezvoltatorii, proiectanții de interacțiuni, arhitecții, DBA și testerii.
Acesta este motivul pentru care este esențial fie pentru client (fie pentru reprezentantul clientului) să să poată fi accesat de oricine din echipă (abordare agilă) sau să aibă mijloace de comunicare formale care autorizează o persoană să comunice numai cu alte câteva persoane dintr-o echipă și să o facă într-un mod în care informațiile să poată fi împărtășite întregii echipe, asigurându-vă că toată lumea are aceleași informații.
-
Există multe procese de realizat și de testat. Fără a cunoaște cu precizie compania și echipa, nu există nicio modalitate de a determina care ar trebui să fie aplicat în cazul dvs. Luați în considerare angajarea unui consultant sau angajarea unui manager de proiect suficient de priceput.
Comentarii
Răspuns
Nu toate erorile sunt create egale, așa că trebuie să sortați grâul din pleavă.
Așteptări
Multe erori sunt ridicate pur și simplu din cauza unei deficiențe a ceea ce face software-ul și a ceea ce se așteaptă utilizatorul final. Această așteptare provine din mai multe domenii: utilizarea altor software-uri, documentație incorectă, personal de vânzări excesiv de zel, modul în care software-ul a funcționat etc etc.
Scop creep
Este de la sine înțeles că cu cât livrați mai mult, cu atât este mai mare potențialul de erori. Multe erori sunt pur și simplu ridicate pe spatele noilor caracteristici. Livrați X & Y, dar clientul spune că pe partea din spate ar trebui să facă și Z.
Înțelegeți domeniul problemei
Multe erori apar din simplul motiv că domeniul problemei a fost prost înțeles. Fiecare client are propriile reguli de afaceri, jargonul și modurile de a face lucrurile. O mare parte din acest lucru nu va fi documentat oriunde – va fi doar în capul oamenilor. Cu cea mai bună voință din lume, nu puteți spera să surprindeți toate acestea dintr-o singură trecere.
Deci … ce să faceți în acest sens.
Teste unitare automate
Multe erori sunt introduse ca efect secundar neașteptat al unor modificări de cod sau altele. aveți teste unitare automate, puteți elimina multe dintre aceste probleme și puteți produce un cod mai bun de la început.
Testele sunt la fel de bune ca datele furnizate – deci asigurați-vă că înțelegeți pe deplin domeniul problemei.
Acoperirea codului
Acest lucru merge mână în mână cu testarea automată a unității. asigurați-vă că este testat cât mai mult cod posibil.
Aflați lecțiile
Nebunia face același lucru din nou și din nou și din nou și așteaptă rezultate diferite
Înțelegeți cauzele ultimului eșec? Nu-i așa? Într-adevăr? Poate că v-ați oprit problema dar care a fost adevărata sursă rădăcină? Date proaste? Eroare de utilizator? Corupția discului? Pană de rețea?
Nimic nu îi enervează pe clienți mai mult decât să întâmpine aceleași probleme din nou și din nou, fără a progresa către o formă de soluționare.
Răspuns
Defecte au existat de la începutul dezvoltării software-ului. Este greu de spus din întrebarea dvs. în ce măsură și ce severitate afectează defectul utilizabilitatea sau funcționalitatea.
Există programe fără defecte, dar aproape orice sistem non-trivial va avea defecte.
Va trebui să decideți un anumit tip de prioritizare și probabil că va trebui să faceți un studiu al cauzei defectelor – unde au fost introduse. Există mult prea multe pentru a discuta despre astfel de lucruri într-un simplu Q & O postare.
Au fost scrise cărți întregi despre analiza cauzală și procesul de remediere pentru o organizație care are probleme de calitate.
Deci, recomandarea mea este să: (fără o ordine specială)
- Implementați un sistem de urmărire a defectelor dacă nu ați găsit deja unul.
- Determinați o modalitate de clasificare a severității defectelor
- Aflați de ce nu îndepliniți așteptările clienților (este vorba de dezvoltatori, QA, client etc.)
- Aflați despre unele exerciții precum „Cinci de ce” și efectuați investigații similare în unele dintre cauzele defectelor dumneavoastră.
Răspuns
Depinde de ceea ce numiți o aplicație.
Dacă vrei să spui, un program interactiv în care trebuie să fii sigur că comportamentul în timp real este exact așa în orice circumstanțe date, atunci este practic imposibil să demonstrezi că nu există erori în ea. Presupun că ar fi posibil dacă ați putea rezolva problema de oprire , dar nu puteți.
Cu toate acestea, dacă vă limitați la o declarație de „o astfel de intrare va produce în cele din urmă o astfel de stare finală”, atunci șansele dvs. de a avea o „dovadă fără erori” sunt mai bune, deoarece puteți utiliza invarianți . Asta și numai asta, permite o definiție a corectitudinii în subprobleme, fiecare dintre care poate fi ușor dovedit a funcționa corect în toate circumstanțele din programul rămas (deși în general nu puteți fi foarte exacți în ceea ce privește cât timp ar putea dura & memorie).
Astfel de tehnici sunt practic posibile în orice limbaj de programare (deși unele esoterice precum Malbolge încearcă să respingă asta !), dar în toate limbajele imperative se încurcă foarte repede, pentru că trebuie să țineți cont meticol de o mulțime de starea implicită a programului. În limbaje funcționale 1 , dovezile tind să arate mult mai frumos ( limbaje pure sau subsetul pur funcțional al unei limbi). Totuși, în special în cazul tipurilor dinamice, va trebui să scrieți o mulțime de cerințe cu privire la ce intrări sunt permise. Acesta este, desigur, unul dintre principalele avantaje ale sistemelor de tip static puternic: cerințele sunt chiar acolo în cod!
Ei bine, în mod ideal, adică. În practică, programele O „Caml sau chiar Haskell tind să conțină funcții netotale , adică funcții care se vor bloca / bloca / arunca pentru anumite intrări, în ciuda tipului corect 2 . Deoarece, deși aceste limbi au sisteme de tip foarte flexibile, uneori nu este încă posibil să îl utilizați pentru a restricționa complet ceva.
Introduceți limbi tipizate în mod dependent ! Acestea pot „calcula” tipurile exact după cum este necesar, astfel încât tot ceea ce definiți poate avea exact semnătura de tip care vă demonstrează tot ce aveți nevoie. Și într-adevăr, limbile tipizate în mod dependent sunt predate în mare parte ca medii de probă . Din păcate, cred că niciunul dintre ei nu este la curent cu scrierea software-ului de producție. Pentru aplicații practice, cred că cel mai aproape de care puteți ajunge complet bug-proof este scrierea în Haskell cu funcții la fel de complete posibil. Asta vă face destul aproape de bug-proof – deși, din nou, numai în ceea ce privește descrierea funcțională. Haskell Modul unic de a gestiona IO cu monade oferă, de asemenea, câteva dovezi foarte utile, dar, în general, nu vă spune nimic despre cât de mult va dura ceva finalizarea. Foarte posibil, ceva ar putea lua un timp exponențial în anumite circumstanțe – din POV-ul utilizatorului, care ar fi probabil o eroare la fel de severă ca și cum programul ar fi blocat complet.
1 Sau mai general, limbaje descriptive . Nu am prea multă experiență cu limbajele logice, dar presupun că pot fi la fel de frumoase ca dovadă salutări.
2 Dacă nu este tipul corect, compilatorul niciodată nu o va permite în aceste limbi; care elimină deja o mulțime de bug-uri. (Și, datorită inferenței de tip Hindley-Milner, de fapt face programele și mai concise!)
Comentarii