Meniu

Acest scenariu explică cât de important este să documentați erorile întâlnite frecvent

this scenario explains how important it is document frequently encountered errors

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Credeți că erorile software apar o singură dată și că, la remedierea lor, nu reapar la suprafață? Cred că aproximativ 30% din erori se repetă.

În acest articol, vreau să vă refer la cât de important este să documentați unele dintre erorile întâlnite frecvent.

Mai jos, veți găsi câteva zone comune în care se văd probleme și un șablon pentru a le documenta.

Sper că o veți găsi de ajutor!

Documentarea erorilor întâlnite frecvent

imagine sursă

Scenariul 1

Codul este implementat și gata pentru QA. John, testerul este gata cu testele sale. În parte, prin testare, el întâmpină o problemă. Simte că a fost observat de câteva ori mai devreme, dar John nu știa cum să o rezolve.

Documentarea erorilor 1

Documentarea erorilor 2

Atât John, cât și Sheryl s-au dus să-l caute pe Smith, care văzuse aceeași eroare mai devreme și o rezolvase înainte. Din păcate, Smith a fost în concediu în acea zi.

Ce ar trebui să facă John acum? Ar trebui John să încerce să se adreseze lui Smith pentru a găsi o rezoluție chiar și atunci când Smith nu este disponibil?

Prin urmare, dacă o problemă de mediu este văzută în mod repetat pe mai multe versiuni, este o idee bună să documentați detaliile și plasați-l într-o locație comună. Acest lucru va elimina dependența de orice persoană și îi va ajuta pe toți membrii echipei să găsească singuri o rezoluție atunci când se întâmplă acest lucru.

Scenariul nr. 2

John testează o nouă versiune și întâlnește din nou o eroare cunoscută. De data aceasta, el știe că i-a fost creat un defect într-una dintre versiunile anterioare. Dar întrebarea este: „cum găsesc numărul defectului și alte detalii asociate?”

Și în acest caz, ce crezi că l-ar ajuta pe John?

Acestea sunt posibilități.

În opinia mea, dacă astfel de probleme sunt bine documentate într-o zonă separată și împărtășite cu echipa, aceasta adaugă valoare și economisește timp.

Ce veți învăța:

Unele dintre zonele cu erori frecvente:

1) Fișier parametru - Pe baza experienței mele cu instrumentul Informatica, în multe cazuri am observat că fișierul param indică o conexiune DB incorectă. A dus la aceleași probleme de mai multe ori. Principalul motiv a fost că conexiunea a fost partajată între dev și QA. Deci, fișierul param a trebuit întotdeauna să fie actualizat conform nevoilor pentru a evita eroarea.

2) Adresă URL către DB incorect

3) Probleme de acces - Utilizatorii se confruntă cu probleme atunci când au permisiuni de acces insuficiente sau incorecte la DB sau În acest caz, ar fi foarte util un document care să prezinte pașii de urmat sau persoana / persoanele care trebuie contactate.

4) Probleme de date de testare - Folosirea unui format sau a valorilor incorecte ale datelor va duce de cele mai multe ori la probleme.

5) Probleme DB - Expirarea conexiunii DB este o astfel de problemă obișnuită. O parte din perioadele de nefuncționare sunt temporare, planificate și, uneori, s-ar putea să avem nevoie de asistența DBA. Utilizatorii sunt anunțați în prealabil pentru întreținerea planificată, dar pentru erori temporare și rezolvare, testerii au cu siguranță nevoie

Cele mai multe erori repetate sunt în general probleme de mediu .

In orice caz, probleme de cod nu poate fi ignorat. Discuția de mai sus este generică și nu include probleme de cod deoarece problemele de cod sunt mai specifice aplicației, cadrului, limbajului de programare etc.

cel mai bun software gratuit pentru optimizarea computerului

O mică zonă de defecte ar putea fi, de asemenea introducerea datelor sau greșeala de utilizare umană s .

DescarcaȘabloane pentru a urmări erorile întâlnite frecvent

Format Word

=> Descărcați șablonul de urmărire a erorilor (World)

Format Excel

=> Descărcați șablonul de urmărire a erorilor (Excel)

Avantajele documentării erorilor întâlnite frecvent

1) Elimină dependența - În Scenariul 1, John era dependent de Smith pentru rezolvare. Dacă ar fi existat un document pentru referința lui John, nu ar fi cazul.

2) Redresare mai rapidă - Luați scenariul 2. Un tester nu ar trebui să parcurgă întreaga listă de defecte deja înregistrate dacă ar exista un document dedicat pentru probleme de înaltă frecvență.

3) Ajută noii membri ai echipei să fie autosuficienți

4) Ajută la rezolvarea erorilor umane

Concluzie

Aș spune că este cu siguranță benefic să documentați problemele mai frecvente, deoarece ar face o referință minunată și o valoare adăugată.

Poate deveni obositor să se documenteze în timp ce executarea testului este în desfășurare, dar, ca o bună practică, pot fi luate note brute în timpul executării, care pot fi ulterior rezumate și actualizate în documente partajate.

Lectură recomandată

^