cosmetic functional bugs what has be treated
Există întotdeauna responsabilități uriașe impuse testerului pentru a descoperi orice fel de eroare pe care o are software-ul. Indiferent de funcționalitate și interfața cu utilizatorul, testerii pot ridica erori oriunde există o neconformitate.
Acest articol ajută la înțelegerea importanței bugurilor funcționale și cosmetice. În plus, factorii care trebuie luați în considerare în stabilirea priorităților lor sunt, de asemenea, explicați aici într-un mod ușor de înțeles cu câteva exemple vii pentru ilustrații .
tutorial microsoft Dynamics AX 2012 pentru începători
Ce veți învăța:
Importanța bugurilor funcționale și cosmetice
Bugurile sunt inevitabile în dezvoltarea de software. Prin urmare, este întotdeauna foarte important să efectuați testarea amănunțită a software-ului înainte de a putea fi utilizat live. Testarea software-ului pot deveni mai esențiale pe măsură ce ajută la identificarea bug-uri ratate de dezvoltatori .
Aceste bug-uri neidentificate pot deveni foarte costisitoare în direct. Prin urmare, un plan de testare adecvat și testarea trebuie efectuate pentru a îmbunătăți calitatea software-ului.
Fig 1:
Figura de mai sus trebuie să încarce un fișier imagine pe care software-ul nu a reușit să îl afișeze. Aceasta este o problemă gravă care poate provoca serios impactul asupra afacerii.
Bug-uri cosmetice și importanța lor semnificativă
Cerințele cosmetice nu sunt altceva decât interfața cu utilizatorul sau doar aspectul frontal al software-ului. De cele mai multe ori se întâmplă să se schimbe continuu între diferite versiuni.
Acest lucru se întâmplă mai ales în proiectele în care se urmărește metodologia agilă. Lansările au loc aici sub formă de sprinturi. Prin urmare, acestea sunt denumite de obicei Sprint sau doar SR-xx, unde „xx” se referă la numărul lansării.
Fiecare versiune poate avea un anumit set de cerințe. În general, clienții se pregătesc să solicite modificări în interfața cu utilizatorul sau doar în interfața de utilizare foarte des.
Iată câteva exemple de cerințe cosmetice:
- Meniurile trebuie să fie disponibile cu font Calibri și.
- Caseta text A trebuie să fie de 1,2 inci
- Toate rapoartele generate trebuie să aibă titlul cu dimensiunea H1 cu culoarea „002522”.
Cele de mai sus sunt câteva exemple de cerințe cosmetice care pot apărea. Acestea sunt cerințele vizate în principal improvizând utilizabilitatea software-ului . Un alt motiv care stă la baza cerințelor cosmetice este optimizarea software-ului și proiectarea acestuia în scopul afacerii.
Fig 2
În figura de mai sus, există atât probleme funcționale, cât și probleme cosmetice. O problemă funcțională precum caseta de selectare nu este afișată pentru opțiunea „Utilizați DeathByCaptcha”.
Problema cosmetică poate fi văzută aici ca și cum nu ar fi fost utilizat un font uniform.
Factor de prioritate pentru erorile cosmetice sau nevoile clienților
Nevoile cosmetice sunt marcate un pic esențiale de către clienți. Acest lucru se datorează îngrijorării față de necesitatea de a face interacțiunea software-ului foarte simplă și în același timp eficientă, astfel încât realizarea obiectivelor să aibă loc cu ușurință. În cazul în care există probleme cu interfața cu utilizatorul, clienții ajung la furnizori cu o eroare cu prioritate redusă.
Așa cum se întâmplă în general, aspectele funcționale ale software-ului sunt preocupate de dezvoltatori decât aspectele cosmetice, deoarece acestea sunt în mare parte zone cu impact redus.
Testerii de software doresc ca toate cerințele menționate de clienți să fie disponibile în software-ul care nu reușește, ceea ce creează în mod natural o eroare. Și aici decolează toate. Prioritatea stabilită de tester apare ca rezultat al sugestiei clientului. Viziunea dezvoltatorilor este puțin diferită de ceea ce privesc testerii. Se uită întotdeauna dacă eroarea poate provoca o întrerupere a funcționalității.
Iată câteva discuții recurente și rezultatul acesteia poate face ca recomandările echipei de testare să se întâmple la un moment dat. Dacă nu în versiunea curentă, se poate întâmpla în versiunea următoare.
Exemplu real # 1)
Clientul a solicitat ca logo-ul companiei să apară pe pagina principală în cadrul titlului, împreună cu o funcție de încărcare rapidă. Vânzătorul a livrat software-ul în care logo-ul companiei necesită timp pentru încărcare, iar clienții cu sentimentul că logo-ul nu se încarcă continuă să ridice o problemă live a clientului.
Prin urmare, acest lucru a făcut mai multe daune vânzătorilor. Cauza principală a problemei ar putea fi dimensiunea imaginii sau natura imaginii sau orice altceva. Deși acest lucru nu are pauze funcționale, acest lucru a fost pus ca o problemă live.
Bug-uri funcționale - Factori critici și prioritari
În general, bug-urile sunt considerate prioritare pe baza priorității stabilite de clienți și a impactului potențial pe care îl pot lăsa în afaceri. Convingerea generală a dezvoltatorilor este că trebuie rezolvate problemele cu critici foarte ridicate. Acest lucru este mai evident, deoarece bug-urile funcționale sunt ceva care le suprima munca.
Și pe baza priorității, clienții doresc să acorde prioritate câteva bug-uri funcționale și cosmetice din aceeași versiune. Factorul de criticitate depinde de impactul sau de impactul potențial pe care bug-ul îl poate lăsa. Factorul prioritar se bazează exclusiv pe client și pe nevoile acestuia.
În ceea ce privește criticitatea, bug-urile funcționale sunt semnificativ necesare pentru a fi remediate fără întârzieri. Pentru bug-urile cosmetice, acestea pot merge cu deciziile luate de clienți
Fig. 3
În figura de mai sus, există probleme funcționale precum probleme de proiectare și suprapunere a textului și probleme cosmetice, cum ar fi problema fontului.
Exemplu real # 2)
Clientul din exemplul nr. 1 a avut mai multe versiuni de la același furnizor. Clienții sunt mulțumiți de livrabilele furnizate de furnizori. Acum, dintr-o dată, există puține scenarii de afaceri pe care clienții le-au identificat că nu funcționează împreună cu alte câteva liste de probleme de afișare. Deoarece problemele cu impact funcțional sunt considerate a fi critice pentru clienți, au cerut furnizorilor să le remedieze cât mai curând posibil.
Și întrucât problemele de afișare aveau semne de a lăsa un grad mai mic de impact, clienții le-au acordat prioritate în mai multe versiuni. Clienții erau gata să intre în direct cu remedieri pentru câteva dintre problemele de afișare și majoritatea problemelor funcționale. Acest lucru se datorează faptului că toate funcțiile pot avea impact asupra afacerii, iar puținele probleme de afișare au potențialul de a crea impacturi.
Impactul afacerii
Toate erorile pot duce la o anumită neconformitate în software cu cerințele clientului. Când vine vorba de impactul în afaceri, cu siguranță bug-urile funcționale merită să provoace un impact sever asupra afacerii. Deoarece bug-urile cosmetice se conformează problemei cu designul și aspectul UI, acestea pot crea probleme cu utilizabilitatea și aspectul în rândul utilizatorilor.
Cu alte cuvinte, acestea sunt mai bine numite îmbunătățiri cosmetice decât bug-uri. Deși acestea nu pot avea un impact sever asupra afacerii într-o manieră mai mare, ele pot aduce unele dificultăți în rândul utilizatorilor în timpul utilizării software-ului.
Exemplu real # 3)
Furnizorii au livrat o nouă versiune a aplicației software într-o versiune mobilă. Există puține caracteristici în aplicațiile mobile care au impus utilizatorului să facă clic mai des pe un link. Acest lucru a creat un sentiment de utilizare degradată în rândul utilizatorilor. Furnizorii trebuie să reconsidere proiectarea și fluxul în aplicație. După schimbarea fluxului, aplicația a început să îi folosească pe mai mulți utilizatori.
Utilizarea are rolul principal în numeroase astfel de aplicații. Deși nu au existat modificări funcționale, au existat puține schimbări în produsele cosmetice care au făcut ca aplicațiile să devină mai puternice
Implementarea listei c ++ legată dublu
Studiu comparativ între erorile cosmetice și erorile funcționale
Pot exista o serie de variații între clasificările bug-urilor, cum ar fi cele funcționale și cele cosmetice, din mai multe aspecte în ciclul de viață al testării software-ului. Puține dintre ele sunt formulate și tabelate ca diferență între ambele tipuri:
| Zona de comparație | Bug-uri funcționale | Bug-uri cosmetice |
|---|---|---|
| Cauze potențiale | Pot exista mai multe cauze: 1. Probleme de codificare 2. Probleme de sincronizare 3. Probleme de aplicații dependente | Următoarele pot cauza problema: 1. Probleme de proiectare 2. Problemă de fișier neacceptată |
| Gradul de recreere | Recreerea erorilor funcționale poate fi făcută fie de testeri, fie de clienți înșiși | Bugurile cosmetice necesită un efort minim în recreere, deoarece acestea sunt identificate în principal la nivelul UI |
| Criticitate | Acestea sunt în mare parte critice, deoarece defalcarea funcțională poate afecta afacerea într-o formă severă | Pot deveni critici în foarte puține ocazii. |
| Prioritate | Prioritatea este definită de clienți | Prioritatea este definită de clienți |
| Impact potențial | Defalcarea funcțională poate cauza probleme grave în afacerea clienților | Deși nu pot crea impact direct, pot prelua și impactul potențial. |
| Considerații privind îmbunătățirile | Aceste erori nu pot fi niciodată recomandate sau considerate ca îmbunătățiri | Aceste bug-uri pot fi sau considerate ca îmbunătățiri |
| Costuri atunci când nu sunt fixate | Cost ridicat atunci când problema este găsită pe software-ul live | Nu costă mult |
Ilustrații de insecte cosmetice
Bug-ul cosmetic poate avea un impact în unele locuri în care există sigle ale companiei sau imaginile parteneriatelor pe software, dar nu se încarcă corect. Deși sunt erori nefuncționale, ele pot deveni severe. Să înțelegem următoarele ilustrații pentru a înțelege importanța insectelor cosmetice și rolul lor semnificativ.
Studiu de caz
Software-ul A este dezvoltat de furnizorul B. Modul de livrări către client se prezintă sub formă de eliminare a codului o dată în fiecare lună, după lansarea versiunii de bază. Din produsul livrat, clienții vor enumera toate problemele, erorile, îmbunătățirile pe baza criticității și priorității lor.
Prioritatea merge la fel P1, P2, P3 și P4.
Criticalitatea merge la fel Sever, major, înalt și scăzut.
Acum, clienții se așteaptă ca toate erorile severe, majore, P1 să fie remediate în săptămâna 30. În mod similar, erorile mari, P2 în săptămâna 35. Scăzute, remedierile bug-urilor P3 sunt așteptate în săptămâna 40. În cele din urmă, erorile P4 sunt așteptate în săptămâna 30. 40. Între toate lansările de corecții, clientul blochează perioada de timp tampon de 3 zile.
Acum următoarea observație devine foarte critică:
- Deoarece a fost planificat ca un mod de conducte, orice întârziere va avea un impact mai mare asupra planurilor ulterioare.
- Prioritățile sunt formate de clienți și, prin urmare, intenționează să le elibereze în perioada dorită
- Întârzierea bug-urilor cu prioritate redusă are potențialul de a-și actualiza prioritatea de la prioritate redusă la superioară.
- Întârzierile minore pot provoca efecte grave asupra companiei, lăsând erorile mici și minore să devină majore.
Testerii și dezvoltatorii se întâlnesc
„Nu numărați ouăle înainte ca acestea să fie eclozionate” - Această linie se aplică atât dezvoltatorilor, cât și testerelor. Când software-ul a fost dezvoltat și gata de testare, testerii tind să se gândească la liniile de mai sus. După testare, este acum rândul dezvoltatorilor să scrie literele către testeri. Următoarele sunt gândurile care curg între ele:
- Testerii spun dezvoltatorilor că există atât de multe erori pe care le putem prinde în software-ul dvs. Prin urmare, munca ta nu s-a terminat.
- După finalizarea fazei de testare și după o mulțime de erori, dezvoltatorii spun că nu cred că ați ridicat mai multe erori, vom găsi motivul adecvat pentru a respinge majoritatea erorilor pe care le-ați ridicat, care nu sunt autentice.
Prin urmare, este întotdeauna un fel de abordare argumentativă care merge între testeri și dezvoltatori. Pentru a vă asigura că toate livrabilele proiectului sunt sincronizate, este esențial ca o persoană intermediară (manager de proiect) care să poată rezolva controversele, astfel încât livrabilele să fie optimizate și absolute, fără scurgeri de defecte.
Concluzie
Articolele de mai sus trebuie să fi explicat toate aspecte inevitabile și importante ale bug-urilor cosmetice și cum poate fi comparat cu bug-urile funcționale . Articolul de mai sus explică, de asemenea, modul în care bugurile cosmetice pot fi tratate în comparație cu bugurile funcționale.
Deși criticitățile bug-urilor funcționale sunt mai mari decât cele ale bug-urilor cosmetice, acestea din urmă își rezervă propriul loc în obținerea priorităților de la clienți. Pentru a echilibra software-ul cu rezoluții pentru toate erorile, în general, este recomandat să tratați erorile înțelegând criticitatea, prioritatea și recomandarea clientului.
Despre autor: Acesta este un articol scris de Nagarajan. Lucrează ca șef de testare cu peste 6 ani de experiență în testări în diverse domenii funcționale, cum ar fi bancar, linii aeriene, telecomunicații, atât în ceea ce privește manualul, cât și automatizarea.
Ce părere ai despre bug-urile cosmetice și funcționale? Aș vrea să vă văd gândurile mai jos.
Lectură recomandată
- Bias cognitiv în testarea software-ului: de ce testerilor le lipsesc erorile?
- De ce software-ul are erori?
- Cum să vă rezolvați toate erorile fără eticheta „Eroare nevalidă”?
- Testarea funcțională vs. Testarea performanței: ar trebui să se facă simultan?
- 10 motive pentru care erorile tale sunt respinse și ce poți face pentru asta ca tester!
- Ce este testarea longevității? Cum să prinzi erorile înainte ca clientul să le găsească
- Arta de raportare a erorilor: Cum să comercializați și să vă remediați erorile?
- Top 30 instrumente de testare funcțională în 2021