Am rezolvat bug-uri în mantis, qa

Apel la națiune

în lumea noastră există oameni care pot găsi bug-uri chiar și într-un program scris ideal de tine. Este inutil să fii defensiv împotriva unei astfel de nedreptăți, de aceea este mai bine să ordonăm această chestiune.







Pentru aceasta, sunt utilizate sisteme de management al defectelor precum "Mantis".

  • Da, puteți apela erori de defecte. Principalul lucru nu este în titlu, principalul lucru este că trebuie reparate.

Schema schematică de lucru cu Mantis

Deoarece știm, de asemenea, în numele căruia urmează să fie trimis acest raport și îl indicăm în sistem, statutul noului raport va fi atribuit. Și este foarte cool, la urma urmei:

Ce este o problemă?

Toate intrările din Mantis sunt numite probleme.

Practic, aceasta se traduce ca "subiectul disputei, dezacordului, problemei". De obicei, acest lucru se traduce prin "sarcină".

Trucul este că fiecare problemă poate fi, în orice moment, un "RAPORT DE BAG" și "SARCINA PENTRU DEZVOLTARE".

Dacă am făcut o înregistrare cu un mesaj de defect, este un raport de eroare.

Dacă am constatat că ar fi necesar să se facă funcția de sortare, aceasta este deja o sarcină de dezvoltare.

De obicei, la cinci minute după ce a lucrat cu Mantis, probabilitatea de confuzie dispare. Dovedit în public.

Reguli generale pentru lucrul cu Mantis

Schemă detaliată de lucru cu Mantis

Am rezolvat bug-uri în mantis, qa

Fixarea de bug-uri prin Mantis

Imaginea este foarte detaliată, dar este încă un concept.

Sistemele similare variază de la birou la birou, însă aceasta este tocmai "abordarea principială".

Avertisment: pentru a lucra cu Mantis în acest mod, este necesar să se tinker cu configurarea statusurilor.

Management de proiect prin Mantis

Acest lucru este fantastic. Faptul este că Mantis este creat pentru dezvoltatori. și nu a fost destinată distribuirii sarcinilor și programării progresului.

Dar tipul Mantis de manageri de sistem, cum ar fi faptul că acestea sunt într-un timp ireal pentru a vedea starea fiecărei sarcini separat - este în lucrare, sau are nevoie de mai multe informații, sau este transferată la testul, sau este deja complet închisă. Prin urmare, toți managerii de pe planeta Pământ încearcă să folosească Mantis și ca sistem de gestionare a sarcinilor. Uneori acest lucru este de succes. Uneori nu.

Cu toate acestea, câțiva tovarăși reușesc să creeze un sistem de cronometrare cu Mantis. care a fost cheltuită de dezvoltatorii curajoși pentru a rezolva problemele existente.

Cel de-al doilea și ultimul apel către națiune

Deci, Mantis este un instrument pentru dezvoltatori.

Intrările într-un astfel de sistem ajută la sortarea listei de sarcini care vor fi incluse în următoarea versiune.

Înregistrările într-un astfel de sistem ajută să nu pierdem din vedere unele probleme și / sau sarcini, să nu uităm și să nu ascundem.

Parola de administrator implicită pentru prima dată când instalați Mantis:
Nume utilizator: administrator
Parola: rădăcină







Toate cele de mai sus se referă la lucrul cu trackerele de bug-uri în principiu, nu doar Mantis în special.

Vrei să se întâmple ca în Jira - unde specificați mai întâi ce doriți să creați și apoi să deschideți șablonul corespunzător?

Mantis este, în mod implicit, un tracker de erori, care poate deveni o problemă de urmărire (care este puterea sa).

Ar trebui să adăugați un câmp suplimentar care va determina ce problemă creăm. Acesta va fi afișat pe pagini, precum și în filtrul general de pe pagina Vizualizați problemele.

1)
Dacă acest câmp este necesar în toate proiectele care vor apărea în sistem, atunci mai întâi asigurați-vă că în colțul din dreapta sus sunteți în "Toate proiectele". În caz contrar, schimbarea se va aplica numai proiectului în care vă aflați în prezent.

3)
Creați un câmp nou:

  • Nume. Tipul de sarcină (denumiți-o după cum doriți)
  • Tip. enumerare
  • Valori posibile. Task | Bug | Caracteristică nouă (soluția dvs.)
  • Valoare implicită. Activitate (va apărea în mod implicit în lista derulantă - puneți ceea ce doriți din câmpul "Posibile valori")
  • Adăugați la filtru. + (adică puneți o bifă)
  • Afișare la probleme de raportare. +
  • Necesar la raport. +

4)
Acum când deschideți o nouă problemă, veți selecta valoarea dorită din lista derulantă.

Și apoi sortați în filtru - ce sarcini și ce - bug-uri.

Acum înțeleg. GREȘI MULT. 🙂

Nu înțeleg de ce, atunci când creați o problemă, nu se poate alege un tip precum "Cerere de element", "Modificare solicitare", "Bug", "Informații", după cum spuneți. Ce fac greșit?

Intrarea dvs. în sistem ce drepturi?

Administrator ... Dar am început testul cu "inițiatorul" de drepturi. Se pare că probabil nu înțeleg ceva în sistemul de statut și drepturi?

În principiu, aceasta se traduce ca "subiect de litigiu, dezacord, problemă". De obicei, acest lucru se traduce prin "sarcină".
Aș traduce acest lucru ca un raport, deoarece de fapt Mantis conține rapoarte despre bug-uri sau completări cu descrierea și condițiile ....

prin felul în mantises proaspete există, cu excepția "relații" mai multe tag-uri, de asemenea, sooo ușor de modificat

Există un înțeles profund în a avea conturi pentru dezvoltatori și testere (în mod implicit, nu există testere în Mantis) nu au putut stabili starea de închis. Practic, ar trebui să fie făcut de managerul de proiect. Managerul trebuie să primească întregul ciclu de activitate al dezvoltatorului numai în starea Testat.
aici nu sunt de acord ... de ce managerul ar trebui să închidă rapoartele verificate după luarea deciziei?

Aș traduce acest lucru ca un raport

"Adăugați un nou raport" - sunete?

de ce ar trebui ca managerul să închidă rapoartele verificate după luarea deciziei?

Apoi, starea de eliberare este evaluată de starea unei sarcini încă deschise. „Rapoarte“. Când toate sunt închise, eliberarea este declarată "eliberată". În caz contrar, se presupune că mai trebuie încă ceva de făcut.

"Creați un raport", așa sună, implicit în Mantis "Creați o întrebare" ....

Avem o foaie de parcurs prin care putem evalua stadiul proiectului ... când toate rapoartele despre proiect sunt închise în stare, adică testerul a verificat toate rapoartele și le-a închis, astfel încât proiectul este gata de livrare!

Cel mai sigur lucru este în mantis. Atribuiți o sarcină numele dvs. Specificați lansarea sau construirea și în care va trebui să reveniți la această întrebare. Și la momentul potrivit să se întoarcă la el.

Dacă există timp pentru a specifica anumite detalii, cum ar fi "cum se reproduce" - acesta este doar un plus, deoarece sarcina poate fi transferată cuiva și să se bazeze pe reproducerea sa adecvată.

Viteza corecției defectelor și semnificația ei nu sunt proporționale cu 🙂

Dacă aveți nevoie de mai puțin de 10 secunde pentru a corecta un defect, dar nu trebuie să uitați să testați acest patch în timp, atunci cum mergeți acolo unde este înregistrat?

Instruire excelentă (simplă și amplă). Eu, totuși, trebuie să folosesc JIRA deseori ca un mantis, dar pentru tovarășii cu care folosesc Mantis trebuie să explic că trebuie să explic ceea ce este și de ce este necesar.

Oficial oficial cu privire la companie de testare [Astound Commerce], Kiev (QA Trainer).

Uneori conduc "[Subclase]" pentru testeri.

Mi-am scris [glosarul] de terminologie de testare (numai în limba engleză).

Vorbitor repetat [SQA Days], [QA Fest] și alte conferințe privind testarea software-ului.

Treceți încet la "[Volga GAZ-21]", lansat în 1965.

Eu joc ceva de genul unui blues greu [pe o chitara clasica].

Subclasa. Pentru testarea tinerilor







Trimiteți-le prietenilor: