În înregistrarea "De asemenea, nu trebuie introduse bug-uri", a fost descris un caz mai mult sau mai puțin ideal de "a deveni testere" prin introducerea tuturor "nu bug-uri" în bugtracker.
Colegul lui Olga scrie observația corectă:
acest lucru nu funcționează pe proiecte mari. Dacă proiectul este mare, testerii adesea pur și simplu nu au timp să citească toate bug-urile existente, fizic. Acest lucru este greșit, dar viața este viața.
Pentru bug-uri care nu sunt bug-uri, nimeni nu va lăuda testerul (se spune încet).
Un tovarăș de șanțuri zmei arată corect că pseudo-bug-urile din tracker nu vor aduce nimănui nici un beneficiu decât "asistentele medicale".
"Nu bug-uri" nu beneficiază în totalitate dezvoltatorii 🙂 Aceasta este bucătăria internă a testerilor. În plus, depinde de fiecare tester individual. Le accept. Alții nu.
În majoritatea cazurilor, astfel de probleme sunt rezolvate la nivelul legendelor intra-proverbiale, care nu sunt documentate, transmise oral sau prin intermediul unui mesager intern, după cum este necesar. Nu am întâlnit încă un set destul de bine pregătit de "caracteristici" care nu sunt bug-uri, proiectate corporativ și puse pe un server intern. Dar la nivelul "privirea în baghetă" - sa întâlnit în repetate rânduri. Orice tracker este atât un instrument de lucru cât și un sistem de stocare pentru erorile produse, deci de ce să nu-l utilizați ca sistem wiki?
Mai multe argumente fără greutate
Există mai multe motive pentru stocarea "fără bug-uri", care sunt evidente foștilor participanți la războaie mici, non-interne "pentru calitate".
Într-un proiect mare, alcătuit din mai multe funcții, se folosesc simultan forțele multor testeri. Se întâmplă foarte rar ca toate aceste forțe să se specializeze cu atenție la funcțiile individuale. Ei bine, liderii de echipă se pot specializa mai mult sau mai puțin în ceva. Restul acelorași membri ai "echipei mari și prietenoase", autoritățile transferă cu ușurință de la un front al muncii la altul.
Exemplu pentru manager: în Excel există o funcție de căutare. Și există o funcție pentru desenarea diagramelor. Și există o funcție pentru afișarea anumitor fonturi. Să presupunem că totul a fost deja dezvoltat și eliberat "în oameni". Oamenii raportează treptat despre erorile pe care le-au găsit și cer, de asemenea, o îmbunătățire a funcționalității. Există schimbări în unele funcții.
Deci, trebuie să verificați modificările din funcția de căutare și cinci zile mai târziu promiteți să ajustați modificările din funcția grafică.
Este mai rezonabil să trimitem astăzi testarea "căutării" tuturor persoanelor "gratuite" decât să crească specialiști care au văzut tot felul de căutări în sicrie, deoarece testează doar diagramele ...
Mâine va fi o altă zi, mâine vom verifica funcția "Salvați ca ..." și va fi mult mai rezonabil ca toți "liberi" să trimită pentru testare "salvați es".
Acum, imaginați-vă că încă mai "așezam" pe diagrame, și v-am văzut "esque esque" doar în sicrie. Dar pentru ziua de azi trebuie să verificăm corectitudinea muncii unei funcții matematice Excel - RANDBETWEEN.
Funcția are o descriere: Returnează un număr întreg aleator între numerele pe care le specificați. Descriere excelentă, înțeleg toate lacunele și toate cuvintele în mod individual. Dacă nu ar exista cazuri de testare, aș fi trebuit să petrec mai multe ore cu documentația proiectului și ar trebui să adresez multe întrebări altora. Este aceasta reală, în special în cadrul proiectului BIG?
De aceea, sunt necesare cazuri de testare. De aceea trebuie să scrieți totul în detaliu. Fă ceea ce este scris și nu-ți păcăli capul / capul.
Prezentăm în continuare: simultan cu mine, această funcție este testată de colegii mei - și testată în alte medii. De exemplu, în combinație cu alte versiuni de Excel, alte versiuni de Windows (există multe dintre ele, dacă cineva nu știe), alte versiuni ale IE ... Sunt găsite "bug-urile" lor care sunt înregistrate pe tracker.
Um, transpiră. Bine, să presupunem că atunci când faceți clic pe butonul Anulare, funcția nu mai funcționează, dar șterge câmpurile la care am introdus datele de intrare.
Argumentăm după cum urmează: dacă am anula operația, atunci voi specifica alte valori de intrare. Și am nevoie de cei vechi să nu conducă din nou toate numerele. Prin urmare, NU ar trebui să fie șterse când faceți clic pe Anulați. Raționamentul logic? Da. Un bug? Da, acesta este un bug (rezultatul nu corespunde așteptărilor și chiar se comportă "neconfortabil").
Acum, imaginați-vă că acest bug, care nu este un bug, este redat în toate versiunile de Windows. Și toți testerele "de pe proiect" vor să o pună în "bugtracker". Ce, documentația "îi va spune" că nu este "un bug"?
Prin urmare - doar bugtracker, și numai "nu bug-uri" ...
Mai târziu, când vom actualiza cazurile de testare și de a efectua bagchekingi, acest bug-ul se va transforma într-un caz test complet: alerga, dintr-o dată faceți clic pe Cancel, confirmă că funcția a încetat să funcționeze și câmpul de introducere șterse.
Există cunoștințe generale și concepte despre interfețe
Sfârșitul pauzei de muzică. Mergem mai departe.
În urma articolului „Nu există bug-uri“, de asemenea, trebuie să fie introduse în bug tracker „Am fost dat o alegorie câteva incorecte despre porcul - pentru că orice persoană este clar că nările unui porc doar două. Există, de asemenea, cunoștințe generale și concepte despre interfețele în cele din urmă ...
Da, toată lumea știe câte nări au un porc adecvat și rezonabil. Dar acum, folosind funcția RANDBETWEEN ca exemplu, încercați să aplicați "Ei bine, mănâncă, bate". Ei bine, nu este clar că a treia nară nu este o nară? “...
Inevitabilitate: "nu apar bug-uri".
Uzurparea identității postulat inevitabilului: să presupunem că un programator care a lucrat la RANDBETWEEN caracteristică, toată viața sa pus pe dezvoltarea acestei funcții ... El știe toate mișcările ei, răspunsurile ei, el știe totul, la fel cum știm că că trei nări de porc nu se întâmplă.
Și eu, testerul, nu știu nimic despre această funcție. Cu curiozitatea și deschiderea copilului, mă răsucesc și răsucesc această funcție. Și pot să găsesc "a treia nară" ...
Ar trebui să clarific faptul că termenul de "tester lipsit de experiență" NU înseamnă "utilizator putrezit care este frică de computer"? Mai ales având în vedere cele de mai sus.
Ei bine ... În testare, astfel de situații sunt foarte frecvente (doar nu știu despre aceasta pentru clienții care testează).
În aceste condiții, apariția a tot felul de "bug-uri" de la testeri neexperimentați este inevitabilă. Este necesar doar să se reducă probabilitatea de detectare a acestora de către programatori. Și pentru a spori posibilitatea ca testerul să se familiarizeze cu toate mutațiile și acțiunile probabile ale acestei funcții. Documentația poate să nu ajute, deoarece documentația descrie modul în care ar trebui să funcționeze funcția. Și vedem cum funcționează în realitate, arătând miracole, care nu sunt descrise în documentație și nu ar trebui să fie descrise și niciodată nu va fi ...
Cum altfel să documentați erorile, cu excepția unui bugtracker? Ei bine, ceea ce deja există vreun wiki pentru toate documentele (cerințe, planuri, cazuri yuz, specificații tehnologice și așa mai departe)? Descrierile erorilor și "nici un bug" sunt deja în trackerul de erori. Ei bine, lăsați-i să se întindă, veniți la îndemână.
Axiom: un proiect mare este destul de aprovizionat cu documentație. Documentarea proiectului, ca și revelațiile apostolice, conține întregul adevăr al vieții pe care un tester de orice grad trebuie să-l cunoască.
Experiența mea este că cei care citesc documentația proiectului încă mai au șanse mai mari să se mute de la junior la management superior.
Mai mult, experiența mea nu este bună: persoana care ia testul de juniori nu vede sau nu aude această documentație. Ce, membrii mai tineri sunt invitați să se familiarizeze cu arhitectura aplicației și cu relația fascinantă "Client-Server"? Mai multe informații pe această temă, vă rog ...
Există o mulțime de documente. Dar ... "nu vor apărea bug-uri" în tracker, iar proiectul din ce în ce mai complex va apărea din ce în ce mai mult aceste "bug-uri":
- noi oameni vin la proiect care nu sunt familiarizați cu specificațiile și cerințele
- "Bătrânii" pleacă, purtând cu ei cunoștințe "nedocumentate" despre caracteristici, specificații și cerințe
- Funcționalitatea este verificată de unii testeri, apoi de alții
- cuceritorii experimentați devin nebuni
Problema este rezolvată în următorii termeni parlamentari:
Cum poți testa ceva ce nu înțelegi?
O întrebare bună: cum puteți testa ceva ce nu înțelegeți? Cum pot avea încredere în verificarea funcției RANDBETWEEN pentru o persoană care nici măcar nu știa despre existența ei?
Sincer, este posibil să testați orice funcție din Excel, fără a înțelege complet ce și cum funcționează această funcție. Cunoștințele generale despre interfața Excel și comenzile de bază pentru lucrul cu meniurile și funcțiile de apelare sunt suficiente și, de asemenea, citim în detaliu cazurile de testare scrise. Iar aceste cazuri de testare sunt scrise de oameni experimentați. De exemplu, dezvoltatorul. Sau managerul de produs. Sau un alt tester care sa mutat deja într-o lume mai bună (în Oracle sau Google), și mai mult cu noi nu funcționează.
Acum, dacă această funcție este responsabilă pentru viața unui astronaut sau a unui pacient conectat la un aparat de respirație artificială, atunci da ... Dar atunci nu li se va oferi să o testeze nimănui altcuiva decât experții în domeniu.
În loc de epilog: "nici un bug" ar trebui să fie stocate în bugtracker, nu le transfera la programatori.
Articole similare
Trimiteți-le prietenilor: