A venit în minte: 10
Pentru cei care nu știu cine este QA (Asigurarea Calității) este un tester, sau în conformitate cu QC noastre, departamentul de control al calității. Testarea este un detaliu foarte important când se creează aplicații complexe, ceea ce permite evitarea erorilor de aplicație "copil" (și nu numai). Munca de producție compatibilă cu QA cu dezvoltatorii - oferă o aplicație garantată stabilă și bine funcționată.
Cu toate acestea, uneori acești aceiași testeri răzgândesc toate limitele rezonabile (și nerezonabile) și raportează bug-uri care nu au nimic de-a face cu realitatea. Se pare, care este problema - clientul plătește aceiași bani, stai jos pentru a face sarcini inutile. Cu toate acestea, deoarece nu este ciudat, astfel de sarcini provoacă iritare și munca încetează să aducă plăcere.
Motivele pentru apariția acestor bug-uri sunt obișnuite:
Ca și în vremurile sovietice - există un plan care trebuie îndeplinit. Fiecare QA conștiincios ar trebui să se angajeze cel puțin xx bug-uri pe zi, altfel va fi înconjurat de loach pe cer. Dacă pentru timpul acordat pentru testarea erorilor normale nu au fost găsite, va raporta ce se va întâmpla.
Atunci când QA începe să compună tot felul de lucruri mistice despre aplicație. Dar utilizatorul va fi confortabil dacă a întoarce pagina cu susul în jos, să facem asta? Din păcate, nici punctul de vedere al utilizatorului, nici complexitatea punerii în aplicare, nici necesitatea acestor modificări tind avizul testerul nu afectează, și vai pentru dezvoltatori, în cazul în care nu se pot apăra poziția lor - de fapt, va trebui să facă.
Pe unul dintre proiecte, arăta așa. Au fost AC extern la client (probabil A1QA cu sediul Itransition), care au fost, aparent, nu numai pentru numărul de bug-uri, dar, de asemenea, pentru sugestii „sensibile“ pentru optimizarea UI.
Au fost următoarele: QA a împins ușor ideea de a modifica cererea autorităților, după disputele cu dezvoltatorii, au fost făcute schimbări și o săptămână sau două ulterior au revenit la versiunea anterioară a UI.
Dar sedimentul a rămas.
Acești nou-veniți au în general puține idei despre modul în care funcționează sistemul și mediul în care lucrează, pot repara bug-uri cu un comportament normal adecvat.
De exemplu, puteți scrie despre meniul contextual lipsă din browser-ul iPad
În unele cazuri, acestea nu au deschis niciodată o specificație, dar sunt fericite să încerce ca adevărați bubuitori (a se vedea planul de cinci ani pentru trei ani).
Trebuie să remarcăm că trebuie să editez nota pentru a fi complet sinceră.
Există, de asemenea, profesioniști în domeniul testării software. Tipii ăștia înțeleg ce se întâmplă pe proiect, trăiesc proiectul, ca și dezvoltatorii. Ei înțeleg că sarcina lor este de a produce un produs de calitate, și nu de a împinge dezvoltatorii în greșelile lor, dovedind "dizabilitatea" dezvoltatorilor lor. O astfel de asigurare a calității nu spune „nu funcționează toate“ bug-uri și nu scrie „Pagina principală Bad.“ - ca și în interesul lor că dezvoltatorul a făcut un fix cât mai repede posibil, fără a încerca o lungă perioadă de timp pentru a descoperi detalii cu privire la ceea ce este în mod specific nu funcționează.
Mai mult decât atât, tipii ăștia pot deschide sursa și pot spune unde ești. Ei nu se tem de console și autotesturi, nu se tem să-și automatizeze activitatea cu bash și cron. Aceasta este o fiară rară în pădurea noastră, un QA sferic în Vaakuma, care este în esență propriu, mai degrabă un dezvoltator, decât un test.
De fapt, munca lui QA este dură greu și necesară, iar trollingul meu ușor nu reduce nevoia de a produce produse interesante de calitate. Doar trebuie să rămân uman în orice situație. Ne pare rau, se fierbe :)
Trimiteți-le prietenilor: