Meniu

Software de testare manuală Întrebări de interviu pentru profesioniști experimentați

software manual testing interview questions

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Cele mai frecvente întrebări de interviu pentru testarea manuală bazate pe scenarii pentru profesioniști cu experiență, cu răspunsuri detaliate:

Am avut recent această experiență unică de Coaching QA (10 ani de experiență) pentru a participa la un interviu de testare a software-ului clientului cu o companie de divertisment de top din Los Angeles. Site-ul care trebuia testat era un site web simplu orientat către clienți (un fel de canal de televiziune online) care avea atât componente web, cât și mobile.

Software manual Testarea întrebărilor de interviu

O companie de consultanță proiecta profiluri către acest client pentru un tester la fața locului + poziția coordonatorului dar niciunul dintre ei nu a reușit să treacă prin procesul de testare a interviului. Deci, au decis să colecteze Întrebări despre interviu QA de la participanții anteriori și mi-au dat un chestionar.

cum se găsește xpath în crom pentru seleniu

Au vrut să dau răspunsurile următorului candidat și antrenor persoana care va avea succes în interviul de testare QA.

Întrebări de testare manuală pentru interviuri cu experiență

Când am primit lista de întrebări, am fost surprins și „nu-surprins” în același timp. Surprins - pentru că întrebările au fost cu adevărat de bază și un QA cu experiență de 10 ani ar fi trebuit să le poată răspunde cu ușurință. Nu atât de surprins, deoarece QA este domeniul IT care are cele mai multe buruieni în opinia mea - dar să nu intrăm în el.

După ce am terminat exercițiul, m-am gândit că ar fi frumos să împărtășesc această experiență cu cititorii STH. Pentru începători, aceasta va fi o expunere live bună. Pentru alții, va fi o amintire prietenoasă a cât de importantă este fundamentale suntem oricât de experimentați am fi.

Lectură recomandată=> 101+ Test de software Întrebări și răspunsuri la interviu.

Iată ...

Întrebări de testare manuală pentru interviuri cu experiență

Cele mai frecvente 9 întrebări de interviu pentru testarea software-ului QA pentru începători, precum și pentru candidații cu experiență:

#Q 1) Care este procesul de creare a unui script de testare?

Răspuns:

Pasul 1: este de a obține o înțelegere aprofundată a AUT:

  • Acest lucru ar putea fi citind documentele de cerință cu atenție.
  • În absența documentelor, am putea încerca să înțelegem orice punct de referință pe care îl avem - o versiune anterioară a aplicației sau fire-cadre sau capturi de ecran

Pasul 2: După înțelegerea cerințelor, facem o listă cu care sunt domeniile din această aplicație care vor trebui testate. Cu alte cuvinte, identificăm cerințele testului. Accentul din acest pas este de a identifica „Ce” de testat. Rezultatul acestui pas este o listă de Testează scenarii .

Pasul 3: Odată ce avem scenariile de testare, ne concentrăm în continuare pe „Cum” să le testăm. Această fază implică scrierea pașilor detaliați despre cum să testați o anumită caracteristică, ce date să introduceți ( Date de testare ) și care este rezultatul scontat.

Odată finalizați acești 3 pași, suntem pregătiți pentru testare.

#Q 2) Care sunt câmpurile dintr-un raport de erori?

Răspuns: Următoarele câmpuri importante ar trebui incluse în a bun Raport de erori :

  1. Un ID unic
  2. Descrierea defectului: un scurt care descrie ce este bug-ul.
  3. Pași de reproducere: detalii despre cum se ajunge la eroare, date exacte de testare, ora la care a fost găsit defectul (dacă este cazul) mediul: orice informații care vor ajuta la re-întâmpinarea problemei
  4. Modulul / secțiunea aplicației (dacă este cazul)
  5. Severitate
  6. Captură de ecran
  7. QA responsabil: în cazul oricăror întrebări ulterioare cu privire la această problemă

#Q 3) Cum să testați un software orientat către client?

Răspuns: Cu orice aplicație pe care o testăm, încercăm să vedem dacă un anumit set de cerințe sunt îndeplinite de aplicație sau nu. Dar când vine vorba de un site orientat spre utilizator, în afară de concentrarea asupra funcționalității, trebuie să analizăm și câteva caracteristici de utilizare, poate și aspectele de performanță și securitate, într-o anumită măsură.

Primul nivel de testare este : Site-ul își îndeplinește cerințele funcționale.

De exemplu, dacă este un site de gestionare a împrumuturilor, trebuie să ne uităm - dacă noul client este capabil să solicite un împrumut, dacă clientul existent poate accesa informațiile despre împrumut, este corect% din dobândă aplicat la suma împrumutului etc.

Următorul nivel de testare este :cât de ușor este să folosești site-ul, opțiunile au un sens logic și îndeplinesc așteptările utilizatorului sau nu.

De exemplu, dacă utilizatorul trebuie să treacă 3-4 ecrane pentru a trimite informațiile de bază, va fi supărat, astfel încât aceste probleme trebuie să fie soluționate.

O alta exemplu, după introducerea numelui de utilizator și a parolei, utilizatorul poate face clic pe fila - ceea ce înseamnă că controlul ar trebui să meargă la butonul „Conectare”, în schimb, dacă va anula, utilizatorul va fi foarte enervat și experiența de utilizare a site-ului este va fi compromis. Astfel de probleme trebuie surprinse.

Test de performanta în măsura completă s-ar putea să nu fie în domeniu, dar situații simple, cum ar fi, cât durează afișarea rezultatelor căutării și cât timp îi ia sistemului ca să recupereze informații despre client la ora de vârf - acestea sunt câteva exemple de fel de lucruri pe care am vrea să le urmărim.

instrumente de gestionare a cazurilor de testare open source

Securitate - pentru site-urile unde există un login sigur pentru a accesa site-ul, trebuie testată funcționalitatea minimă din jurul acestuia. De exemplu, dacă las site-ul inactiv mai mult de 10 minute, se deconectează automat sau nu. Ar trebui să se concentreze ceva la fel de simplu.

#Q 4) Cum să depășești provocarea de a nu avea documentație de intrare pentru testare?

Răspuns: DACĂ documentația standard detaliată, cum ar fi BRD și FSD, nu sunt disponibile, testerul va trebui să depindă de un anumit punct de referință.

  • Capturi de ecran
  • O versiune anterioară a aplicației
  • Sarme, etc

Un alt factor care ajută enorm este să vorbim cu dezvoltatorii sau cu analiștii de afaceri (atunci când sunt disponibili) pentru a obține o confirmare a înțelegerii noastre sau clarificări în caz de dubii.

Când niciuna dintre aceste situații nu funcționează, putem doar conceptualiza aplicația pe baza experienței noastre anterioare în aplicația IT și să creăm setul de bază de scripturi de testare. Când apare faza de testare, putem configura o parte din timpul ciclului de testare și putem gestiona cazurile de testare (face scripturile deja create perfecte), astfel încât să avem documentul pentru următoarele faze.

#Q 5) Cum se ajunge productivitate maximă de la o echipă offshore?

Răspuns: Cheia este să vă asigurați că toți testerii știu despre toate modulele și că nu există concentrare de cunoștințe într-un singur loc. Implicarea tuturor în revizuirea peer a scripturilor de test, întâlnirile cu defecte și sesiunile KT vor asigura că toată lumea este conștientă de aplicație în cea mai bună măsură posibilă.

De asemenea, încurajând conceptul de lucru în echipă, putem face membrii echipei să colaboreze, să se ajute și să se ajute reciproc pentru o productivitate mai bună.

Întâlnirile periodice de urmărire ajută, de asemenea, procesul foarte mult.

#Q 6) Care sunt rolurile și responsabilitățile unui coordonator la fața locului? Testează și el / ea?

Răspuns: Coordonatorul la fața locului este un punct de contact pentru echipa offshore și pentru client pentru orice informații cu privire la angajamentul de testare.

Acest post include:

cum se deschide .jar pe Windows 10
  • KT de la și către offshore și clienți
  • Pregătirea mediului înconjurător
  • Testarea sănătății, testarea fumului
  • Testarea - funcționalitatea cheie.
  • Revizuirea erorilor - găsită de echipa offshore
  • Alocarea erorilor către dev
  • Prezentarea valorilor
  • Furnizarea semnului

Da, chiar și un coordonator la fața locului trebuie să testeze.

#Q 7) Bug-uri incoerente - De ce la fața locului o poate găsi, dar offshore nu și invers - Cum să gestionăm această situație?

Răspuns: Fiecare eroare trebuie notată și analizată - indiferent dacă este întâlnită la fața locului sau în larg, indiferent dacă este repetabilă sau nu. O valoare adăugată reală la jobul unui tester este atunci când ne implicăm în procesul de analiză a cauzei rădăcinii pentru o eroare, mai degrabă decât să o raportăm pur și simplu.

Unele dintre modalitățile prin care putem face față acestei situații sunt:

  • Toți membrii echipei la fața locului și offshore ar trebui să urmeze un ghid conform căruia capturile de ecran trebuiau luate pentru fiecare eroare pe care o întâlnim - repetabilă sau nu.
  • Dacă există jurnale, fișiere de sistem sau ceva de genul acesta, care ne-ar putea ajuta să găsim dovezi ale problemei - ar trebui să încercăm să o găsim.
  • În ciuda tuturor acestor pași, dacă tot nu putem spune de ce și când apare problema - ar trebui să o raportăm dezvoltatorului la fel - cu cât mai multe informații posibil.

#Q 8) Testare video / audio - Ce include aceasta?

Răspuns: Cum se testează o aplicație care are video sau audio?

Iată ce puncte importante trebuie luate în considerare:

  • Nivele de acces (restricționat sau nu - controlat prin parolă)
  • Diferite tipuri de medii
  • Compatibilitate browser
  • Rezoluții de ecran
  • Viteza conexiunii la internet
  • Opțiunile specifice pentru un videoclip - cum ar fi redare, oprire, mutare etc.
  • Video după dimensiune
  • Răspuns la videoclipuri - comentarii (limitări privind lungimea comentariului și numărul de comentarii pe care le poate lua)
  • Răspunsuri video la videoclipuri
  • Interfață cu site-uri de rețele sociale - Interoperabilitate
  • Viteza de tamponare
  • Încorporarea videoclipului

#Q 9) ​​Testarea aplicațiilor mobile - Ce include pe scurt?

Răspuns: Testarea aplicațiilor mobile Scenarii importante de testare:

  • Verificați dacă aplicația funcționează bine cu mai mulți operatori și dispozitive multiple.
  • Utilizarea caracteristicilor de pe un ecran mobil.
  • Testarea acestuia pe diferite platforme mobile - cum ar fi Android și iOS.
  • Instalări, dezinstalare, lansarea aplicației cu rețea și fără rețea, testarea funcționalității.
  • Conexiuni de rețea –WiFi, 2G etc.
  • Jurnalele de la utilitarul de configurare iPhone pentru Android Monitor.bat pot fi utilizate pentru depanare.

Asta a fost. Acum, nu era atât de simplu.

Ca o notă finală, reiterez filosofia de la STH - cunoașteți bine elementele de bază, restul urmează automat.

Închei, sperând că acest efort va fi benefic și semnificativ pentru cititorii noștri. Vă rugăm să ne informați mai jos în secțiunea de comentarii despre cum am făcut-o.

Autor: Această postare este scrisă de Swati Seela, membru al echipei noastre STH.

Lectură recomandată

^