Meniu

6 abilități de bază pe care ar trebui să le aibă fiecare tester (în principal mai proaspăt)

6 basic skills that every tester should have

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Testarea software-ului sau QA este cea mai bună platformă pentru noii veniți pentru a intra în industria IT, în ciuda concepțiilor greșite că este un loc de muncă mai mic sau mai puțin plătit.

Cea mai importantă abilitate de care are nevoie un tester este capacitatea de a găsi erori . Și, dacă ești genul de persoană care iubește să găsească bug-uri, atunci vei iubi și vei crește în acest domeniu.

Acestea fiind spuse, mai sunt câteva abilități care vă pot ajuta să găsiți erori și să lucrați mai bine cu procesele de asigurare a calității.

Acesta este articolul care va arăta procesul de asigurare a calității, așa cum este urmat în majoritatea companiilor și va oferi clarificărilor noilor testeri cu privire la testare.

În detaliu, veți afla procesul de documentare și standarde, prelucrarea testerului, testarea bazată pe constrângeri, testarea în timpul dezvoltării parțiale și în final procesul de semnare.

abilități de testare de bază

Sa incepem.

Ce veți învăța:

# 1. Documentație

Documentarea este esențială pentru testare. Majoritatea companiilor atribuie această sarcină noilor veniți. Pentru a reuși, ar trebui să aveți vocabular bun deoarece restul lucrurilor, cum ar fi standardele de documentare etc. nu sunt în controlul dvs. și depind de procesele echipei și ale companiei.

De asemenea, asigurați-vă că vedeți valoarea procesului de documentare. Avantajele sunt multe - vă ajută să urmăriți modificările cerințelor, să urmăriți pașii de testare, să vă înregistrați lucrările etc.

Citire recomandată=> De ce este importantă documentarea în testarea software-ului

# 2. Pregatire pentru test

Dintre toate documentele disponibile, următoarele nu pot fi neglijate. Acestea sunt, de asemenea, numite documente livrabile și fac legătura între înțelegerea clientului, dezvoltatorului și testerului.

a) Planul de testare: prezintă fluxul de testare de la început până la sfârșit .

Planul de testare descrie domeniul de aplicare și activitățile fazei de testare. Creată de liderul QA, echipa trebuie să contribuie și să rămână la curent cu tot ceea ce este scris în planul de testare.

Unele echipe au mai multe niveluri de planuri de testare: Master Plan și Planuri de fază.

Un plan de testare trebuie să aibă:

  • Numele și versiunea proiectului
  • Identificatori ai planului de testare - Creator, nr. Schiță, data creării etc.
  • Introducere - Prezentare generală a proiectului, obiectiv și constrângeri
  • Referințe - Lista referințelor utilizate ca intrare (asigurați-vă că utilizați versiunile corecte și cele mai recente)
  • Elemente de testare - Module, versiune, domeniu, în afara domeniului etc.
  • Abordare generală de testare / strategie de testare - Instrumente de utilizat, proces de urmărire a defectelor, niveluri de testare de efectuat etc.
  • Criterii de trecere / nereușită a articolului - Ghid de execuție a testului
  • Criterii de suspendare și reluare
  • Livrabile testelor - Caz de testare, rapoarte de testare, raport de erori, valori de testare etc.
  • Testați detaliile mediului
  • Lista echipei cu informații despre punctul de contact. pentru fiecare modul sau tip de testare
  • Estimări de testare - Timp și efort. Detaliile bugetului sunt confidențiale și nu le veți găsi aici
  • Riscuri și planuri de atenuare
  • Aprobări
  • Alte linii directoare

Citește și=>

b) Scenarii de testare:

Un indiciu de linie cu privire la „ce să testăm” pe baza fiecărei cerințe și, de obicei, documentat și urmărit prin foi de calcul.

Majoritatea conțin:

testați site-ul web în diferite browsere gratuit
  • Numele modulului / componentei / funcției (autentificare, administrator, înregistrare etc.)
  • ID-ul scenariului este pentru referință (de ex .: TS_Login_001)
  • Descrierea scenariului - „Ce să testez” De exemplu: Validați dacă autentificarea permite utilizatorilor cu acreditări valide să se autentifice cu succes
  • Importanța scenariului - A acorda prioritate în caz de timp insuficient - Înalt / mediu / scăzut
  • Cerință ID - Pentru trasabilitate

Lecturi suplimentare=>

c) Cazuri de testare:

Cazurile de testare exacte oferă rezultate exacte ale testelor. Foi de calcul sunt în continuare mediul popular pentru scrierea cazurilor de test, în special pentru începători, chiar dacă unele companii adaptează instrumentele de gestionare a testelor. Baza pentru scrierea cazului de testare este documentul SRS / FRD / Req. Dar, nu este adesea suficient, așa că va trebui să folosiți o mulțime de presupuneri și discuții cu echipele BA / Dev.

Scrierea unor cazuri de testare eficiente este cea mai importantă calificare pe care trebuie să o aibă un tester. De obicei, toate cazurile de testare sunt clasificate ca pozitive / negative. Caz de test pozitiv oferă date valabile și obține rezultate pozitive. Caz de test negativ trimite date nevalide și primește mesajul de eroare exact.

Pentru mai multe informații despre acestea, verificați:

Unele dintre atributele comune pe care le au toate cazurile de testare sunt:

  • ID scenariu - preluat din documentul scenariului de testare
  • ID caz test - Pentru identificare și urmărire unice. De exemplu: TC_login_001
  • Descrierea testului - Scurtă explicație a stării testate testate
  • Pași de executat - Instrucțiuni detaliate pas cu pas cu privire la modul de testare
  • Date de testare - Date furnizate etapelor de testare
  • Rezultatul așteptat - Rezultat așa cum era de așteptat
  • Rezultatul real - Răspunsul AUT când se execută testul
  • Stare - Trecere / Eșec / Fără executare / Incomplet / Blocat - Descrie rezultatul testului
  • Comentarii - Pentru detalii suplimentare
  • Executat de - numele Testerului
  • Data executării - Data la care se execută testul
  • ID defect - Defect înregistrat în cazul testului, în caz de eșec al testului
  • Detalii de configurare - OS, Browser, Platformă, informații despre dispozitiv (opțional)

Citire recomandată=>

# 3. Proces de testare - Ce teste să efectuați?

Există un număr mare de tipuri de testare, dar nu toate pot fi efectuate pe acel AUT. Timpul, bugetul, natura afacerii, natura aplicației și interesul clientului sunt jucătorii cheie în alegerea testelor ce trebuie făcute în aplicație.

De exemplu: Dacă este un portal de comerț online, atunci testarea stresului și testarea sarcinii sunt obligatorii. Cu toate acestea, unele dintre tipurile de test care nu trebuie ratate sunt:

# 4. Testarea în etapa de dezvoltare parțială

În general, cu companii de nivel mediu și cu start-up, există timp și resurse limitate. Testerii de aici ar putea începe procesul de testare înainte de integrarea modulului, ceea ce înseamnă că s-ar putea să facem teste de integrare a unităților și intermediarilor.

Este important să rețineți că rezultatele din aceste etape nu pot fi considerate ca fiind exacte, deci este posibil să fiți nevoit să vă planificați un test general al cutiei negre odată ce totul este gata. Privirea cu privire la această parte s-ar putea dovedi costisitoare și testarea, ineficientă.

# 5. Document de raportare a erorilor

Mâini pe mână, acesta este cel mai critic document QA pe care îl veți realiza vreodată.

Următoarele sunt câmpurile pe care trebuie să le aibă un bun raport de erori:

  • ID defect - De obicei un număr de serie
  • Descrierea defectului - Explicarea unei linii a problemei
  • Locație - Modul / zona AUT în care se găsește problema
  • Numărul versiunii - Versiunea și codul de construire nr.
  • Pași pentru reproducere - Lista pașilor care vă conduc la problemă
  • Severitate - Setați un nivel pentru a descrie gravitatea problemei - Scăzut, mediu, ridicat, blocant etc.
  • Prioritate - Setată de dezvoltatori pentru a determina ordinea în care va fi remediat defectul (P1, P2, P3 etc. P1 - cel mai mare)
  • Atribuit către - Proprietarul defectului în acel moment
  • Raportat de - numele testerului
  • Stare - Stare diferită pentru a reprezenta etapa ciclului de viață al erorilor
    • Nou - Bug-ul este găsit și este raportat
    • Deschis - validat de liderul QA
    • Atribuit - Trimis către liderul de dezvoltare pentru a fi atribuit dezvoltatorului respectiv
    • În curs de desfășurare / Lucrare în curs - Dev a început să lucreze la el
    • Fix / Rezolvat - Dezvoltatorul a terminat lucrul la acesta
    • Verificat / Închis - Echipa QA a retestat și a găsit eroarea remediată
    • Reîncercare - Echipa QA nu este de acord cu rezoluția de la Dev și progresează în continuare cu eroarea pentru reluare
    • Duplicat - Există deja o eroare similară
    • Amânat - Bug valid dar va fi remediat în versiunile ulterioare
    • Invalid - Nu este o eroare sau nu este reproductibil sau nu există suficiente informații

Lecturi suplimentare=>

# 6. Proces de semnare

Ieșire iar trimiterea documentației finale este sarcina conducătorului / managerului QA. Cu toate acestea, echipa trebuie să prezinte documentele de mai sus (scenariu de testare, caz de testare și documentul jurnalului defectelor) pentru verificări finale și audit.

Asigurați-vă că le corectați pe toate și trimiteți versiunile finale.

Citește și=>

Concluzie

Acesta este procesul pe care l-am asistat și am experimentat direct când eram tester și sper că acest lucru v-a oferit câteva indicații utile.

În cele din urmă, o carieră în teste a fost o bucurie absolută pentru mine și sper să fie și pentru tine.

Toate cele bune pentru cariera ta!

Lectură recomandată

^